Rman üzerinden backupları nasıl alabileceğimizden, alınan bu backupların nasıl validate edileceğinden bahsetmiştik. Rman ile yapılan backup dan dönme işlemlerinde bence en önemli kısım recover operasyonunun yapıldığı kısımdır. Elinizde hangi güne ait bir backup var ise bir şekilde restore komutu ile bunu açabiliyorsunuz ama esas problem açılan bu backupın son ana veya belli bir zamana recover edilmesi noktasında problemlerle karşılaşma olasılığının yüksekliğidir. Buradaki problemde örneğin until time göre bir recover işlemi yapmamız gerekiyorsa ve zamanı olması gerekenden ileri bir zaman dilimine veriyor isek hata alıp tekrar denemek durumunda kalacağız demektir. Tam bu noktada oracle bize şöyle bir imkan sunuyor;
Continue reading
Yearly Archives: 2011
Alınan Backupların Sağlamlığını Nasıl Test Edebiliriz
Database’ de bir recover restore yapmak istediğimizde almış olduğumuz backuplardan hangisini kullanacağımızı nasıl tespit edebileceğimizden bahsetmiştik. (http://www.kamilturkyilmaz.com/2011/10/22/restore-icin-gerekli-olan-backuplari-nasil-tespit-edebiliriz/) Şimdi ise tespit ettiğimiz bu backupda problem olup olmadığını nasıl tespit edeceğimizden bahsetmek istiyorum. Sektörde şöyle bir eksiklik olduğunu düşünüyorum. Oracle kullanan hemen hemen tüm firmalar bir şekilde backuplarını alıyorlar. Ancak alınan bu backupların sağlam olup olmadığına, bir disaster durumunda bu backupların kullanılabilir durumda olup olmadığına bir çok firma dönüp bakmıyor dolayısıyla bir problem olduğunda backuplarda kullanılamadığında beraberinde cevaplanması gereken birçok soru getiriyor. Yani her durumda sıkıntılı bir süreçle karşı karşıya kalınıyor diyebiliriz. İşte bu tarz durumların önüne geçmek için zaman zaman ki bence belli periyotlarla backuplarımızı kontrol etmemiz faydalı olacaktır. Bu işlemi nasıl yapabiliriz kısmına gelirsek ;
Continue reading
Restore-Recover için Gerekli Olan Backupları Nasıl Tespit Edebiliriz
Restore – recover yapmadan önce, hangi backuplara ihtiyacımız olduğunu nasıl tespit edebiliriz’ den bahsetmek istiyorum. Bu işlem için rman komutlarından preview komutunu kullanıyoruz. Syntaxında restore – recover komutu yer aldığından dolayı şu soru akla gelebilir database’ de bir restore – recover işlemimi gerçekleştirip mi bu bilgiye ulaşıyor? Şeklinde ancak hemen belirteyim ki Preview komutu database’ de fiili olarak bu tarz bir operasyona girmeden mevcut backuplar arasından istenilen komutu gerçekleştirmek için kullanacağı backupset veya backuplar ile ilgili bilgiyi bize sunuyor.
Bu işlemi yaparkende de 3 farklı moddan birini kullabiliriz ;
• Normal
• Summarized
• Recall
Continue reading
ORA-03114: end-of-file on communication channel
Ora-03114 hatası da aslında dba’ lerin ora-600 gibi çokda hoşlanmadıkları hatalardan biridir aslında, hatanın nedeni kullanılan oracle ürünlerine, komponentlerine ve hata alınmadan önce yapılmaya çalışılan işlem ile ilgili olarak çok değişik nedenlerden dolayı alınıyor olabilir. Ben pyhsical standbyı olan bir sistemi restart etmek isterken bu hata alındığında neden kaynaklandığından ve çözümünden bahsediyor olacağım. Bu tarz bir hata alındığında hatanın tam olarak olarak neden kaynaklandığını görmek için mutlaka alert loga bakmamız gerekiyor. Çünkü önyüze yansıyan hata ile ilgili olarak ihtiyaç duyacağımız detay bilgiye ancak buradan ulaşabiliyor oluruz.
Standby database’ler kurulurken daha öncede detayından bahsetmiş olduğumuz gibi 3 tane kullanabileceğimiz protection modu bulunmaktadır. Bunlardan maximum protection ve maximum availability modeları birbirlerine yakın kullanım tipleridir. Burada önemli olan nokta şu; size bu iki protection yönteminden biriniz seçmis iseniz ve dataguardınız da senkron olarak çalışıyor ise standby tarafında yaşanılacak olası problemlerden etkileniyor olacaksınız demektir. Üzerinde konuştuğumuz her iki modun da ortak özelliği;
Continue reading
Rman Backup’ ın Kaldığı Yerden Tekrar Başlatılması (Backup’ ın Tamamlanmadan Sonlanması Durumunda)
Bu bahsetmiş olduğum durum aslında hemen hemen herkesin başına mutlaka gelmiştir. Özellikle size anlamında ciddi boyutlardaki database’ lerin backuplarının da nispeten uzun sürdüğünü söyleyebiliriz. Bir örnekle açıklamaya çalışalım, production database inizden backup alıyorsunuz ve backupınız yaklaşık 10 saatte tamamlanıyor. Backup başlatıkdan 9 saat sonra (yani bitmesine çok az bir zaman kalmışken) database’ de yaşanan bir problem den dolayı sistem down oluyor ve sizin backuplar da haliyle fail olmuş oluyor. Bu tarz bir durumda karşılaşıldığında ne yapabiliriz sorusuna cevap vermeye çalışacağım. Şöyle bir senaryoylada karşılabiliriz. Kritik bir işlem öncesinde database’ in full backupını almak istiyorsunuz ve backup sonrasında da hemen işleme başlamanız gerekiyor. Backup bir şekilde fail olduğunda tekrar başlatma şansımız yoksa ne yapabiliriz. Backupımız olmadan işleme başlamak da istemiyoruz. BU gibi durumlarda backupı kaldığı yerden tekrar başlatabiliriz. Backupın fail olduğu noktaya kadar almış olduğu tüm backupları skip ettirerek kaldığı yerden devam etmesini sağlayabiliriz. Yine bir örnek üzerinden gitmeye çalışalım.
Aşağıdaki komutla database’ in archiveloglar dahil tüm backupını almaya çalışıyorum.
Continue reading