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.