Kategori: Bilgisayar

• Oracle Enterprise Manager’da fiziksel yedeğe logların gitmediğine dair bir uyarı gördüm. Availability kategorisinde bas bağıran bir uyarı vardı. Hatalar arasında neler vardı neler?
  – ORA-16055: FAL request rejected
  – ORA-16191: Primary log shipping client not logged on standby
• Ne olmuştu da yolunda giden log shipping işinde bu sorun çıkmaya başlamıştı?
  – eşitlenen taraflardan birinde etkileyen hesaplarda parola değişikliği olmuş ise, ondan kaynaklı olabilir yazıyordu
  – log lokasyonlarında alan kalmamış olabilir yazıyordu
• Bendeki durumda değiştirilen bir hesap şifresi yoktu. Birincil sistemden ikincil sisteme taşıma yapan sürecin karşılaştığı hata ile ilgili trace dosyasına bakmak gerekiyordu. Bu trace dosyasına bakmak o kadar kolay değil, o kısım için diag açılıp, trace dosyası incelendiğinde, eşitlemeyi yapan kısmın karşıya oradaki bir trigger yüzünden oturum açamadığı görüldü
• Bir şekilde birincil sistemde oturum açılmasını engelleyen bir tetikleyici oluşturulmuştu ve bu tetikleyici fiziksel yedeğe taşınmıştı
• Fiziksel yedeğe bu hain tetikleyici gönderildikten sonra birincil sistemin ikincil sisteme log taşımasını sağlayan mekanizma logon hataları vermeye başladı.
• Yapılan yüzeysel ilk kontrolde en başta yazdığım hatalar göründü, ve o hataların en yaygın olduğu düşünülen çözüm adımları.
• Şöyle dikkatli bir şekilde düşününce Oracle tarafından önerilen çözüm adımlarının yaşanan durumu yansıtmadığı görüldü. O yüzden o adımları uygulayıp, onların oluşturacağı riskler hiç göz önüne alınmadı.
• alert.log dosyasına konuyla ilgili daha detaylı açıklama düşmesi için trace açıldı, arkasından düşen hata fiziksel yedekte bir trigger tarafından logon işleminin engellenmiş olduğunu bariz gösteriyordu.
• Log taşınmasının devam etmesi için logon olması gerekiyordu, trigger öyle bir trigger idi ki sys kullanıcısının bile bağlantısını engelleyebiliyordu. Yazmak istesen yazamazsın.
• Sorunla uğraşırken birincil sistemde bu trigger duruyor mu diye kontrol edildi, ne görüldü bilin bakalım: trigger yoktu, silinmişti, ama fiziksel yedekte duruyordu ve data guard mekanizmasının işleyişini engelliyordu.
• Bir şekilde fiziksel yedekte bu trigger kapatılmalıydı, fiziksel yedek read only olduğu için doğrudan o kapatılamıyordu
• Tek yapılabilecek tüm sistem tetikleyicilerinin kapatılmasıydı, fiziksel yedekte sistem tetikleyicilerini kapattık
• fiziksel yedeği yeniden başlattık. bir süre sonra logon gerçekleşti ve loglar birincil sistemden fiziksel yedeğe geçmeye başladılar.
• fiziksel yedeğe log taşındığının görülmesinden sonra halen o tetikleyicinin durup durmadığını kontrol ettik
• fiziksel yedekten o zararlı tetikleyicinin silindiğini gördükten sonra sistem tetikleyicilerini etkinleştirdik.

Lafın özü, başka yolla çözülebilir miydi, belki çözülebilirdi, birincil sistemden ikincil sisteme gitmesi gereken loglar scp gibi bir komutla fiziksel yedeğe taşınıp o loglar ile fiziksel yedeğin başlaması sağlanabilir, tetikleyicinin olmadığı görülünce normal işleyişe döndürülebilirdi.

1. http://manishnashikkar.blogspot.com/2014/08/removing-fatal-ni-connect-error-12170.html
2. http://martinmeyer.blogspot.com/
3. https://oraganism.wordpress.com/tag/_system_trig_enabled/
4. https://oraganism.wordpress.com/2015/08/26/non-working-logon-trigger-on-data-guard-standby-database/
5. https://www.linkedin.com/pulse/how-recover-archive-gaps-standby-database-using-2-methods-kumar
6. https://oracle-base.com/articles/11g/data-guard-setup-11gr2
7. http://www.nazmulhuda.info/shutdown-standby-database-for-maintenance-work
8. http://quickdbasupport.com/most_used_dataguard.php
9. http://webcache.googleusercontent.com/search?q=cache:da-nbzblJo8J:www.oracledistilled.com/oracle-database/troubleshooting/data-guard-standby-archive-destination-full/+&cd=11&hl=tr&ct=clnk&gl=tr
10. http://logic.edchen.org/how-to-resolve-ora-16055-fal-request-rejected/