Private strand flush not complete / Checkpoint not complete

Selamlar,

Başlığı okuyan ve konuyu biraz bilen ya da bilmese bile veritabanlarının alert.log dosyasında gören insanların tüylerinin diken diken olduğunu görür gibiyim.

"private strand flush not complete" ve "checkpoint not complete" alert.log dosyasında yazan ve her online redolog değişiminde, belirli parametrelere bağlı olarak yazılma ihtimali olan bilgi mesajlarıdır. İki mesajında amacı aynı sayılırken yazılma nedenleri biraz farklıdır. Her iki mesaj da redo log değişiminden kaynaklanmaktadır. Bu iki mesajın en büyük özelliği ise gerçekten çok fazla aratılan ve merak edilen parametreler olmalarıdır. Internet üzerinde ciddi boyutlarda makale bulunmaktadır.

Google'da arama yaptığınız zaman, bu mesajların çok önemli olmadığını hatta kimi yerde ki gayet ciddi olduğunu düşündüğüm makalelerde ise ciddiye dahi alınmaması gerektiği yazmaktadır. Bu yorumlar ve bilgilendirmeler kesinlikle gerçeği yansıtmamaktadır. Bu mesajları gördüğünüz zaman alert.log dosyanızdan silmek için çalışmanız gerektiğini düşünüyorum zira çok yüksek transaction'ı ve bu transaction'ların yükü fazla olan veritabanlarında çok ciddi bekleme olaylarına neden olmaktadırlar.

Bu mesajları gördüğünüz zaman temel olarak şunu düşünebilirsiniz; LGWR yeni bir redo log geçişinden sonra sırada online redolog grubuna veri yazmak ister ancak sıradaki redo log henüz üzerine yazılması için hazır değildir. Yani bir checkpoint başlamıştır ancak redo log içerisinde bilgilerin fiziksel veri dosyalarına yazımı tamamlanamamıştır. Kimi uzman bu durumu gidermek için büyük boyutlu online redo log dosyaları kullanılmasını önermektedir ancak bana göre ne büyük ne de küçük, önemli olan bunun dengesini oturtmak. Çok küçük boyutlarda olduğu zaman fazla log geçişi olacağından bu hataları görme olasılığınız artabilecek iken çok büyük boyutlarda olduğu zaman bu hataları görmeyecek olsanız bile bu durumda da büyük log file yavaş yazma istatistiği ve eğer bir data guard kurulumunuz varsa da geç archivelog yaratılması ve senkronizasyon problemlerine kadar gider.

"private strand flush not complete" ve "checkpoint not complete" mesajlarını veritabanınızda görmek istiyorsanız eğer çok basit bir deneme yapabilirsiniz. 2 adet redolog grubu yaratın ve boyutlarını da 2GB kadar büyük tanımlayın. Arka arkaya "ALTER SYSTEM SWITCH LOGFILE" komutunu gönderin ve herhangi bir CKPT tetikleyici unsura başvurmayın. Eğer log_checkpoint_interval ve log_checkpoint_timeout parametleri tanımlıysa da bunları 0'a ayarlayın. Ardından alert.log dosyanıza bakın ve ilgili mesajlara rastlayacaksınız. Bunun dışında v$log görüntüsünden de redo log'un statüsünün "ACTIVE" olduğunu da gözlemlerseniz eğer LGWR henüz aktif olan ve DBWR arkaplan görevinin kullanmakta olduğu redo log'u yeniden kullanmak isteyecek ancak kullanabilmesi için biraz beklemesi gerekecek. İşte bu beklemelerin neden olduğu yavaşlığı gerçekten acil olarak çözmeniz gerekebilir çünkü bütün veritabanının genel performansını negatif yönde etkileyecektir.

Peki ne gibi çözümler önerilmektedir?

Önerilen en büyük çözüm redo log dosyalarınızı daha hızlı ve fiziksel veri dosyalarından ayrı olacak şekilde konumlandırmanız. Bu şekilde akış ayrı yerlerden paralel olarak devam edecek, redo log dosyalarına yazım gücünüz artacaktır. Bununla birlikte daha hızlı disk konfigürasyonları kullanmanız da yararlı olacaktır. Örneğin RAID5 yerine RAID1 diskler kullanmak gibi. Eğer AWR raporlarında ya da enterprise manager'da "log file sync" bekleme olaylarına da rastlamakta iseniz bu değişiklikler birlikte log_buffer'ı da arttırmayı düşünebilirsiniz. Redo log'lardaki sorunlarınızı giderebilmenin bir diğer yolu ise ağır kalan CKPT görevinin tetiklenmesini sağlamak. Yalnız bunu tek başına yapmak ne yazık ki problemi ve bekleme olaylarını çözmeyebilir. Bir redo log geçişinden sonra tetiklenen checkpoint'i, parametrelerle de sağlamanız mümkün değil, bunu şu anlamda söylüyorum; alert.log dosyasında "Completed checkpoint" ve "Incremental checkpoint" bilgilerini görürseniz EĞER log_checkpoint_to_alert parametreniz "true" ise. Complete bilgisi redo log geçişlerinden sonra gelir ancak incremental checkpoint, yani geçiş ya da ara checkpoint işleri log_checkpoint_timeout ve log_checkpoint_interval parametreleri ile kontrol edilebilir. log_checkpoint_interval'ın aldığı değer OS blok değeridir ve redo log'larla ilgili biraz karmaşık bir parametredir. Bu parametre tanımlandığı zaman mttr tavsiyesi devre dışı kalabilir. Bununla birlikte log_checkpoint_timeout parametresi ise saniye cinsindendir ve örneğin 40 değerini verirsek her 40 saniyede bir incremental checkpoint tetiklenecektir. Yanılmıyorsam 8i versiyonu ile bu parametrenin varsayılan değeri 1800 saniye olarak atanmıştır. Internet üzerinde okuduğum yorumların arasında "neden sık sık checkpoint yapmak isteyim?" gibi yorumlar geliyor. Checkpoint zaten biz istesekte istemesekte olması zorunlu bir ilerleyiştir. Redo log'lara transaction'ların commit ederek yazdığı verilerin bir yerde saklanması gerekmektedir. Burada bizim söylediğimiz sadece bunun hızlandırılabiliyor ya da insan tarafından kontrol edilebiliyor olmasıdır.

Bu noktada akla gelebilecek bir soru bütün bu parametrelerin varsayılan ve genelde bütün veritabanları için sabit sayılabilecek değerlerinin olup olmadığıdır. Hayır, böyle birşey söz konusudu kesinlike değildir. Her veritabanının yapısı ve transaction mantığı, adedi ve boyutu farklıdır. Yalnız herşey de olduğu gibi burada da heryeşin fazlası zarardır görüşü geçerlidir. Bir veritabanında nasıl çok hızlı ve fazla redo log grup geçişi zararlı olabiliyorsa 4 saatte bir yapılan redo log geçişleri de o kadar kötüdür. Bunun en muhtemel nedeni ise olası redo log kaybından 3 saat 54 dakikanın elinizden kaybolabileceği gerçeğidir, tabii standby redo log'lu bir data guard kurulumunuz yoksa :)

Alert.log dosyanızı eğer *nix kullanmakta iseniz "tail -f" komutu ile izleyin ve bu mesajları gördüğünüz zaman ki sequence numarasına bakın. Örneğin mesajın geldiği zamanki numara 68500 ama geçmesi gereken yeni sequence numarası 68501. 68501'e geçemediğini, daha doğrusu geçemediğini göreceksiniz. Ardından belirli bir zaman sonra 68501'e geçtiğini göreceksiniz. Bunu da ek bir bilgi olarak saklayabilirsiniz.

İyi geceler.

Ogan