10gR1, 10gR2 ve 11g database’ lerinde Recyclebin Özelliğini Disable Etmek

10gR1 de recyclebin özelliği default olarak enable olarak gelir. 10gR1 içinde bu değeri diasble yapabiliriz.

SELECT a.ksppinm, b.ksppstvl, b.ksppstdf
FROM x$ksppi a, x$ksppcv b
WHERE a.indx = b.indx
AND a.ksppinm like ‘_recycle%’
ORDER BY a.ksppinm;
Continue reading

Tablo Seviyesinde Yapılan Flashback Operasyonları – 2 (Flashback Drop)

Flashback konusunda sadece flashback drop ve flashback database konularımız kaldı. Bu konuya başlamışken bu bölümdeki tüm konulara burada değinmek istiyorum. En azından birileri merak ederse tüm konulara tek link üzerinden ulaşabilme şansı olmuş olur. Flashback drop konusu ile ilgili olarak da Ogan kardeşim de kendi sayfasında yer verdi. İlham kaynağı olarak da beni referans göstermiş, bu konuda birilerine referans olabildiysem ne mutlu bana :)  bu vesileyle burdan oganada teşekkür etmek isterim, çünkü blog oluşturma fikrinin oluşmasında oda bana ilham kaynağı olmuştu :)
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.

Tablo Seviyesinde Yapılan Flashback Operasyonları

Flashback table ile tablonun geçmiş bir andaki durumuna dönülebilir. Bu işlem online ve çok hızlı yapıldığından dolayı, tablonun önceden alınmış olan bir backupından faydalanarak yapılması ile karşılaştırılamayacak derecede dba’ lere zaman kazandırmaktadır. Tablonun flashback drop ile tekrar kazanılması sırasında tablo üzerinde yer alan index,triggger, constraintlerde tablo ile birlikte tekrar kazanılmaktadır. Bu komutun çalıştırılabilmesi için bir takım gereksimler bulunmaktadır. Bunlar ;
Continue reading

Satır Seviyesinde Flashback Operasyonları

Satır bazında yapılan flashback 3 şekilde yapılabilir; 

Flashback Query ; Bir tabloda ki verilerin geçmiş bir zamandaki durumunlarını select etmek için kullanırız. Örneğin, bir tablo üzerinde yanlışlıkla yapılan ve commit edilen bir update işlemi sonrasında, update öncesindeki değerlerin neler olduğunu görebilmemizi sağlar. 

Flashback Versions Query ; Version query, bir kaydın, belirlenen iki zaman aralığındaki almış olduğu değerleri select eder. Yani a personelinin 2010, 1 Aralık saat 09:00 tarihindeki maaşı ile 2010 1 Kasım saat 09:00 daki maaşlarını karşılaştırabilirsiniz. 
Continue reading