Standby Database Archive Apply Hatası (ORA-00308: cannot open archived log)

Şirket  bünyesinde kullanmakta olduğumuz önemli bir database’ imizin eşleniği prod ortamdan çıkan archiveların disaster tarafına manuel olarak apply edilmesi ise tutuluyor.  Hafta sonu yaptığımız prod database’ in upgrade’ i (10gR1 den 11gR2 ye) öncesinde disasterdaki bu ortamıda son çıkan archive’ ı apply ederek herhangi bir olumsuz durumda ayağa kaldıracak şekilde hazır tutmaktı.  Ancak disaster tarafındaki bu standby database’ imiz son archive’ ları apply ederken bir anda  ORA-00308: cannot open archived log hatası verip sonrasında 1,5 sene önceki bir archive’ ı isteyerek hata verdi. Sonrasında konuyu biraz araştırdıkdan sonra benzer sorunların control file dosyasında oluşan corruption dan kaynaklanabileceğini tespit ettik. Control file dosyası içerisinde  database tarafından üretilen archive’ ler ile ilgili bilgilerde tutulduğundan prod ortamdan standby control file create edip, disaster tarafındaki control file’ leri ezerek yenilerini prod ortamdan tekrar atmış oluşturmuş olduk. Yapılan bu işlemler ile ilgili scriptler ve adımlara ait detayları aşağıdaki adım adım anlatmaya çalıştım.
Continue reading

ORA-30036: unable to extend segment by 8 in undo tablespace

Zaman zaman database’ de tablolara yüklü miktarda insert işlemleri olur. Özellikle bahsettiğimiz bir raporlama database’  ise bu işlem kaçınılmaz olur ve yapılan işlemin boyutu undo tablespace’ inizin boyutundan fazla olduğunda (undo tbs autoextend olmadığını varsayarsak)   “ORA-30036: unable to extend segment by 8 in undo tablespace ‘UNDOTBS2’  hatasını almanız kaçınılmaz olacaktır.  Ora-30036 hatasının önüne geçmek için yapılan insert işlemini parçalamak ve daha ufak bölümlerde yapmak sizin için kaçınılmaz bir çözüm olacaktır. Bu işlemi de yaparken tablo içerisindeki bir alana göre bir den fazla where conditionı ile sorgu yazmak yerine tek sorgu ile ama belirli sayıda data üzerinde sırayla işlem yaparak undo’ ya fazla yüklenmeden tabiri caizse patlatmadan işleminizi gerçekleştirebilirsiniz. Örnek olması açısından şöyle bir bilgi verebilirim, raporlama database’ lerimizden birinde yer alan 54 gb bir datayı farklı bir schema altına aşağıdaki script ile yaklaşık 1 saat gibi bir sürede taşımıştım. (Aşağıda belirtmiş olduğum tuning yöntemlerinden hiçbirini kullanmadan) Tabi bu süreyi etkileyen diğer faktörleride göz önünde bulundurmak lazım. (işlemin yapıldığı andaki database deki yoğunluk, kullanılan server’ ın kapasitesi, taşınan tablespace’ lere ait dbf’ ler üzerindeki o anki i/o durumu vs.)
Continue reading