Rman Restore – Recover Operasyonuna Canlı Bir Ornek (restore – recover – resetlogs)

Birkaç gün önce production database’ lerinden birinde tablonun biri yanlışlıkla silinmişti. Kayıtları farklı bir ortamdan getirecekleri veya aynı kayıtları bir şekilde tekrar oluşturacakları düşüncesiyle  aksiyon almamıştık. Ancak bugün, belirttiğim bu işlemlerin yapılamadığı ve ayın 07’ sindeki kayıtlara mutlaka ulaşılması gerektiği söylenildi. Database’ in protection’ ı 7 gün olduğu için rman backuplarımız vardı. Yaklaşık 600 gb’ lık bir db için farklı bir ortam oluşturarak buraya backupı döndük ve verileri  kurtardık. Aslında bununla ilgili olarak geçen sene Aralık ayında bu işlemin nasıl yapılması gerektiği ile ilgili bir yazı yazmıştım. Dolayısıyla konuya antremanlı olduğumuzdan çok sürpriz olmadı.  (http://www.kamilturkyilmaz.com/2010/12/07/rman-catalog-database%e2%80%99-i-kullanarak-kartusa-alinan-backupi-farkli-bir-sunucuya-donme-1/)  

Örnek olması açısından bugün yaptığımız işlemleride anlatacağım. Başlamadan önce Continue reading

ORA-01122: database file 9 failed verification check (ora-01110 – ora-01208)

Arkadaşlar, bugün şirkette yaşadığımız bir disaster probleminin ortaya çıkışından ve soruna nasıl bir çözüm bulduğumuza varan uzun bir operasyonun üzerimizde yarattığı stresden bahsetmek istiyorum. Aslına haftaya güzel başlamıştık taki disaster tarafındaki standby database’ lerimizin kurulumu ile ilgilenen bir arkadaşımızın bizim için çok kritik olan bir production database’ ine ait 3 datafile’ i olduğu lokasyonda ziplemeye başlamasına kadar 🙂 Sorunlar silsilesi tam bu noktada başlıyor, 3 tane dbf file’ ınız .gz olduğundan artık yok, ayrıca disk üzerinde aynı partitionda çalışan bir gzip procesi’ nin düzgün kill edilememesinden dolayı diskin doluluk oranı %100 olmuş durumda, kullanılabilir alan sıfır 🙂 Database açık, database’ in toplam buyutu 500 gb (aslında bu tarz kritik database’ lerimiz arasında en ufak olanı bu olduğundan dolayıda biraz şanslıyız 🙂 ziplenen 3 dbf’ in bağlı bulunduğu tablespace’ in büyüklüğü 260 gb, ve tablespace’ a ait tüm datafile’ ler begin backup modda. Aslında tüm niyetimiz database’ i kapatmadan soruna çözüm üretmekti ancak arka tarafda neler yapıldığınıda tam olarak kestiremiyorduk yani disk full dolu tam bu esnada yapılan gzip operasyonu, gzip bile düzgün tamamlanmış olmayabilirdi, byte mertebesinde dosyada olabilecek bir corruption tüm senaryonuyu değiştirmek için yeterli bir nedendi. Yaptığımız bir takım tespitlerden sonra system admini arkadaşlardan disk üzerinde yeterli büyüklükte bir partition alarak gece alınmış olan rman backupdan dönmeye karar verdik. (%100 dolmuş olan alanı farklı bir isimle unmount ettik, yeni aldğımız alanıda kullanılan eski isimle mount ettik) 500 gb backupın 480 gb okuduğu esnada (ki bu süreç tam 01:50 dak. kadar sürdü) yani sonuna gelmişken restore operasyonumuz HPUX-ia64 Error: 27: File too large hatasıyla fail oldu 🙂 (system admini arkadaşımız diski verirken large file parametresine dikkat etmeden verdiği için yüksek size’ lı dbf’ leri kopyalarken hata fail oldu) Sonrasında yeni bir rman restore işine girişmeden tüm archive loglarımız olduğundan dolayı archive logları kullanarak ilgili datafile’ leri recover etmeye karar verdik. Ve bu şekilde tüm datafile’ lerimizi recover etmeyi başardık. Sonuç bizim açımızdan başarılıydı. Bunu aslında biraz da bu tarz operasyonların kritikliğinden bahsetmek için yazdım. Yapmış olduğumuz işlemlerin veya kontrollerin bir kısmından burda bahsettim. Asıl zor olan, bir disaster durumunda başınızda onlarca kişi toplanmışken ve her bir kafadan ayrı bir ses çıkıyorken sorunu iyi analiz edip, en kısa yoldan çözüm üretebilen bu işde ciddi şekilde başarılı oluyor diye düşünüyorum. Bu tarz koşullarda soğukkanlılığınızı, sakinliğinizi kaybetmeden paniklemeden çalışabiliyorsanız, bence bir dba’ in mutlaka sahip olması gereken bu vasıflarına sahipsiniz demektir. Bunların üzerine deneyim ve tecrübelerinizi de eklediğinizde işte o zaman ortaya kaliteniz çıkıyor. Disaster’ sız günlerde görüşmek üzere 🙂

Flashback drop ile devam etmeye çalışacağım. 
İyi geceler.

Rman Catalog Database’ i Kullanarak, Kartuşa Alınan Backupı Farklı bir Sunucuya Dönme -2

kaldığımız yerden devam ediyoruz ;

  • Sıra datafile’ leri restore/recover etmeye geldi ;

 

Pathler backupı alınan database’ deki pathler ile aynı olmadığından öncelikle bu değişikliği yapmamız gerekiyor.

Aşağıdaki script ile datafile’ leri bizim belirttiğimiz yeni lokasyonlarına restore ediyoruz.
Continue reading

Rman Catalog Database’ i Kullanarak, Kartuşa Alınan Backupı Farklı bir Sunucuya Dönme -1

Belli dönemlerde prod database’ lerinden alınan backupları farklı sunucular üzerine dönme testleri yapma zorunluluğumuz var. Bu testlerden birinde yaptığım işleme ait  detayları aşağıda anlatmaya çalıştım.

Rman ile bir database’ i farklı bir sunucu üzerine taşımak başlıklı yazımda rman backup diske alındığında nasıl restore edileceğinden bahsetmiştik. Orada catalog database’ ini aslında kullanmamıştık çünkü alınan rman backupı, restore yapılacak sunucu üzerinde rman’ in istemiş olduğu path’lere kopyalamıştık dolayısıyla orada işimiz daha kolaydı.
Continue reading