LGWR, CKPT, DBWR ve LOG_BUFFER

Merhaba,

Bir oracle veritabanı arka plan görevi olan LGWR'ın (log writer) amacı log buffer'daki bulunan ve online redo log'lara yazılmayı bekleyen bilgileri online redo log'lara aktarmaktır.

LGWR görevi bu işlemi 4 farklı aşama tetiklendiği zaman gerçekleştirmektedir;

1) Her 3 saniyede bir redo log buffer'ı,
2) Redo log buffer'ın 1/3'ü dolduğu zaman,
3) Redo log buffer 1 megabyte olduğu zaman,
4) Herhangi biri "commit" ederse,

Redo log buffer boşaltılır ve online redo log'lara veriler aktarılır. Online redo log gruplarının boyutlandırması ne kadar önemli ise redo log buffer'ın da boyutlandırılması o kadar önemlidir. Hatalı boyutlandırıldıkları durumlarda veritabanın bekleme olayları meydana gelmektedir.

Aslında DBWR ve LGWR birbiri ile senkronize çalışmaktadır diyebiliriz zira bir transaction içerisinde iken devreye ilk giren görev LGWR'dır. LGWR'ın online redo log'lara yazdığı transaction kayıtları CKPT görevinin tetiklenmesi ve DBWR aracılığı ile fiziksel veri dosyalarına yazılmaktadır. Dolayısıyla bu döngü içerisinde bir aksama meydana geliyorsa, diğerleri de mutlaka etkilenecek demektir.

LGWR'ı CKPT ve DBWR'dan ayıran bir özellik ise yukarı saydığım 4 maddenin değiştirilemez ve değiştirilmesi de teklif edilemez olmasıdır :) Bu işleyişe log writer'ın kendine özel hareketleri de diyebiliriz ancak CKPT ve DBWR için aynı şey geçerli değildir. CKPT ve DBWR görevlerinin tuning'i yapılabilir ve belirli durumlarda da yapılması gerekmektedir.

Örneğin CKPT görevini elle çalıştırabilirsiniz;

SQL> ALTER SYSTEM CHECKPOINT [GLOBAL];

Aynı şekilde bir veritabanı üzerinde ne kadar DBWR çalışabileceğini sisteme gösterebilirsiniz;

SQL> ALTER SYSTEM SET DB_WRITER_PROCESSES=CPU_COUNT/8 SCOPE=SPFILE;

Veritabanının üzerinde bulunduğu sistemin CPU adedi bölü 8 bize kaç adet DBWR görevi olabileceğini göstermektedir. Bu sayıdan fazla da DBWR görevi tanımlanabilir.

İyi çalışmalar.

Ogan

LOG FILE SYNC

Selamlar,

Birçoğunuza "log file sync" yazısı yabancı gelmeyecektir. Bu bir çeşit veritabanı bekleme olayıdır ve veritabanı üzerinde koşmakta olan bağlantıların takılabileceği bir olaydır. Bu beklemenin sebeplerini ve neler yapılması gerektiğini aşağıda belirteceğim yalnız şunu da eklemem gerekiyor ki; AWR raporundaki "Top 5 Wait Events" alanında bu olayı görüyorsanız eğer aksiyon almanız gerekebilir diyebilirim.

Bu kullanıcı commit ya da rollback komutunu gönderdiği zaman bu bağlantının redo bilgisi LGWR tarafından redo log dosyasına yazılır. Bu durumda veritabanı commit ya da rollback beklemeleri ile bu redo log'a yazma işlemini tamamlar.

Eğer log file sync bekleme olayı önemli ölçüde beklemeyi sistem üzerinde yaratmış ise ortalama beklemeyi gözlemlemek gerekmektedir. Eğer ortalama bekleme düşük ancak bekleyen bağlantı adedi fazla ise bu durumda uygulamanın her insert komutu ardından commit ettiğini söyleyebiliriz. Uygulama mantığı böyle bir yapı gerekiyor olabilir ancak transaction'ın atomik bir yapısı olduğunu ve bu yapı içerisindeki commit ya da rollback işlemlerinin ciddi anlamda önemli olduğunu da eklemek zorundayım. Bir bankacılık sisteminde paranın bir hesaptan diğerine aktarılırken kaybolması gibi birşey söz konusu olamaz ve buradaki en önemli ve sihirli kelime "commit" olacaktır. Sonuç olarak uygulama da bu bekleme adetlerini, her satırdan sonra commit etmek yerine 50-100 satır sonra commit ederekte çözebilir. Bu tamamen uygulamanın nasıl geliştirildiğine bağlıdır aslında.

Bu gözlemlemenin sonucunda eğer bekleme ciddi boyutlarda ise "log writer" bekleme olaylarını ayrı ayrı incelemek gerekmektedir. Bunun yanında, yukarıda özetlediğim durumun aksine, ortalama bekleme süresi yüksek ve I/O da yüksek ise aşağıdaki aşamaları sınamak gerekebilir;

1) Redo log'ların olduğu disk'ler üzerindeki aktiviteleri azaltın ya da redo log için ayrı bir disk kullanın.
2) Redo log lokasyonları için kullanacağınız başka disk'ler archiver'ın log writer üzerindeki etkisini minimize edecektir.
3) Redo log'ları daha hızlı disk'lere taşıyabilirsiniz. Örneğin RAID 5 disk'ten RAID 1 disk'e taşımak gibi.
4) "Raw device" kullanmayı, yazma işlemini hızlandırmak için düşünebilirsiniz.
5) Uygulamanın cinsine ve yapısına göre işlenen COMMIT'leri her N adet satır için yapmayı tercih edebilirsiniz. Her satır girişinden sonra yapılan commit, daha fazla log file sync beklemelerine sebep olabilirken, commit'leri biraz azaltmak daha az log file sync beklemelerine sebep olabilir.

İyi çalışmalar.

Ogan