- 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.
- http://manishnashikkar.blogspot.com/2014/08/removing-fatal-ni-connect-error-12170.html
- http://martinmeyer.blogspot.com/
- https://oraganism.wordpress.com/tag/_system_trig_enabled/
- https://oraganism.wordpress.com/2015/08/26/non-working-logon-trigger-on-data-guard-standby-database/
- https://www.linkedin.com/pulse/how-recover-archive-gaps-standby-database-using-2-methods-kumar
- https://oracle-base.com/articles/11g/data-guard-setup-11gr2
- http://www.nazmulhuda.info/shutdown-standby-database-for-maintenance-work
- http://quickdbasupport.com/most_used_dataguard.php
- 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
- http://logic.edchen.org/how-to-resolve-ora-16055-fal-request-rejected/
