Blog ' da Ara

Loading

17 Şubat 2012

Log File Sync & Log File Parallel Write Wait Event

                Analiz ve Çözüm Yöntemleri

                Oracle Veritabanında bir user commit işlemi çalıştırdığında, user’a ait session bilgileri memory den alınıp diske yazılmak üzere redolog dosyalarına yazılır. Commit işlemi sırasında session LGWR prosessine geçip log buffer içeriğini redolog dosyalarına  yazacaktır.

Log buffer sessiona ait commitlenmiş ancak redolog dosyalarına henüz yazılamamış bilgiler içerir. LGWR prosesi redolog dosyalarına yazma işlemini tamamladığında işlem bitmiş olacaktır. Redolog dosyalarına yazma sırasında LGWR prosesesini beklerken kaybedilen zamana “Log File Sync” denir.

                Ayrıca “log file sync” yaşanırken başka sessionlarda eğer commit işlemi çalıştırıyorsa aynı şekilde “log file sync” wait event göreceklerdir.

                Log File Sync Wait Event yüksek olmasının sebebi nedir?

                Bekleme; kullanıcılar tarafından onaylanan işlemlerin (commits) log buffer dan diske yazılmasına kadar her an da gerçekleşebilir. Ancak bir genelleme yapılacak olursa log file sync beklemelerinin 3 ana sebebi vardır;



                1-LGWR I/O Performans.

                2-Uygulama tarafından sürekli commit işleminin gerçekleşmesi.

                3-Yazılım tarafından aşırı Cpu kaynak tüketimi.



                LGWR I/O Performans

                Log writer process diske yazma hızı yavaşmıdır? sorusuna cevap aramak gereklidir. Eğer “log file sync”  de alınan ortalama bekleme süresi, “log file parallel write” da alınan ortalama bekleme süresinden büyükse; log buffer dan redo bilgilerinin log switch yapılması esnasında bekleme yaşandığını gösterir. “log file parallel write “ event yüksek gözüküyorsa redo bilgilerinin diske yazılmada bekletildiğini düşünebiliriz.

                Burada “log file sync” log buffer yani memory birimi ile alakalı olduğu , “log file parallel write” da diske yazma hızı yani storage kalitesi ile alakalı olduğu görülebilir.

                Normal sistemlerde avg wait time (ms) “log file sync” zamanı 3 den büyük olmamaıs gerekir. Yine avg wait time (ms) “log file parallel write değeride” 10 dan büyük olmaması gerekir. Aşağıdaki şekilde açıkça sorun yaşanan bir sistem görülmektedir.



Şekil 1: log file sync ile log file parallel write karşılaştırılması


Peki bu sistemde performans iyileştirme için neler yapılabilir.

·         Öncelikle Sistem admin ile görüşüp redolog file lerin üzerinde bulunduğu disklerin hızı kontrol edilmelidir.Redolog dosyalarının bulunduğu diskler RAID 5 olmamalıdır. RAID 0 genelde tercih edilir. RAID 0 en hızlı disk sistemidir.

·         Tüm redolog dosyaları aynı disk üzerinde olmamalıdır. Bu durumda band genişliği yeterli olmadığı için bekleme yaşanabilir.

·         Log Buffer memory alanı çok büyük olmamalıdır. Bu durumda  ters etki gözlemlenecektir. Yani log buffer dolması beklenecek ve disklere yazma işlemi için beklenecektir.

LGWR proses tarafından üretilen trace file “Warning: log write time 540ms, size…

Eğer LGWR proses tarafından üretilen trace filelerde ilgili satırı görüyorsanız disklerin hızın ve OS tarafından bir anormallik olup olmadığını kontrol edebilirsiniz. Eğer donanım ve OS tarafından herşey normal gözüküyorsa sorun yok demekdir. İlgili alarmı dikkate almayabilirsiniz.



Redolog File Sizelarının Kontrol Edilmesi

“Log file sync” olayı  daha öncede bahsettiğimiz gibi log switch yapma esnasındaki beklemedir. Standar t olarak logswitch işlemlerinin ortalama 15-20 dk. Da bir meydana gelmesi beklenir. Bu süreyi  alert.log dosyasında görebilirsiniz. Ayrıca  awr raporlarındada görmeniz mümkündür.

Şekil 2: Avg redolog switch time : Alert log
Şekil 3: Avg redolog switch time :AWR


Bu sürenin daha kısa olması mesela aşağıdaki örnekteki gibi 2-3 dakikada bir olması redolog dosyalarının olması gerekenden daha küçük size da olduğunu gösterir. Dolayısıyla redolog dosylarını biraz büyütmeli yada daha fazla redolog group ve member eklemeniz gerekmektedir.

Redolog File Eklenmesi

Aşağıdaki sql ile redolog dosyalarının bilgilerini görebilirsiniz.

  SELECT l.group#,

         l.thread#,

         f.MEMBER,

         l.archived,

         l.status,

         (bytes / 1024 / 1024) Size_MB

    FROM v$log l, v$logfile f

   WHERE f.group# = l.group#

ORDER BY 1, 2

Yeni redolog grubu aşağıdaki scriptle eklenebilir.Burada dikkat edilmesi gereken redolog gruplara ait redolog memberların farklı diskler üzerinde olmasıdır.

ALTER DATABASE ADD LOGFILE group group_number ('/log01A.dbf', '/log01B.dbf ') SIZE 1024M;

Bu işlemden sonra yukarıdaki sql i yeniden açlıştırdığımızda eklediğimiz gurub gözlemleyebiliriz.

Redolog Grup Silinmesi

Redolog grup silebilmeniz için alter database hakkına sahip olmanız gerekir.

Sistemde en az iki redo log grup bulunması gerekir.

Bir redlog grup ancak INACTIVE ise silinebilir.Silmek istediğiniz redolog grup inaltif değilse “ALTER SYSTEM SWITCH LOGFILE” komutunu çalıştırdıktan sonra ilgili sql ilede redolog grup statusunu kontrol edip “ALTER DATABASE DROP LOGFILE GROUP group_number;” şeklinde silebilirsiniz.Silme işlemi başarılı bir şekilde tamamlandı ise OS tarafında dosyayı silebilirsiniz.

Redolog grup eklem yada redo log file size değiştirme işlemlerini RAC ortamında yapıyorsanız her iki instance dada yapmanız gerekir.Normal olan aynı size ve grup sayış belirlemenizdir.

Optimum Redolog Size Nasıl Belirlenir

                10g den itibaren SELECT OPTIMAL_LOGFILE_SIZE FROM V$INSTANCE_RECOVERY; querisi ile optimal redolog member sizesini MB olarak görebilirsiniz.Burada görülen değer instance recover time olan FAST_START_MTTR_TARGET süresine göre belirlenir. Eğer gördüğünüz OPTIMAL_LOGFILE_SIZE değeri sizing log file member’lardan büyükse bu durumda redolog file member larınız en az bu değere kadar büyütmeniz gerekmektedir.

Uygulamanın aşırı sıklıkta commit çalıştırması

Eğer uygulama aşırı sıklıkta commit işlemi yapıyorsa log buffer daki redo bilgisinin redolog dosyalarına aktarılması sağlanacağı için bu işlem de “log file sync” wait evente sebep olabilir.Eğer avg wait time “log file sync”, avg wait time “log file parallel write” dan çok fazla ise bu durumda redoların yazılmasında yavaşlığın sebebinin I/O hızı ile alakalı olmadığını ve commitlerden kaynaklandığını söyleyebiliriz.Aynı şekilde avg wait time “log file sync” düşük olmasına rağmen bekleme sayısı fazla ise yine uygulamanın çok sık commit yaptığını söyleyebiliriz.

Şekil 4 : User calls / user commit (average user calls / commit)

AWR raporlarında user calls / user commit değeri 30 dan küçükse uygulamanın çok sık commit yaptığını söyleyebiliriz.Şekil 4 de ortalama 5 use call için bir commit işlemi çalıştırıldığı gözükmektedir.Bu durumda “log file sync” wait eventi commit sıklığından dolayı görülecektir.

Bu durumda uygulamaya ait transactionlar guruplanabilirliğine bakmak gerekir.Böylece commit sayısını azaltmak iyi bir etki gösterecektir.

Uygun olan batch processler için commit nowait kullanımı faydalı olabilir.Çünkü nowait opsiyonu ile beklemeden diske yazma işlemi yapacaktır.Ancak bunu kullanırken dikkatli olmak gerekir.


                                                                                                Özcan YILDIRIM

0 YORUM:

Yorum Gönder

"Sorularınız ve Eleştirileriniz Değerlidir"