ORACLE Redo log mimarisi

En kısa anlatım ile, redo loglar oracle'de yapilan islemlerin datafilelere yazilmadan önce tutuldugu dosyalardir diyebiliriz. 

Böylelikle eğer veri dosyalarına yapılan degişiklikler yazılmadan sistem de bir hata oluşursa bu durumda redo log dosyalarına yazılan veriler kullanılarak, yapılan degişikliklerin kaybolması önlenmiş olur. Aynı zamanda Bunun yanında redo log System Change Number (SCN) bilgisini de tutar.

Instance ler en az iki tane redo log grubu isterler. Bunun sebebi ise bir döngü mimarisi ile bir tanesi işlemlerin detayını tutarken diğerinin de yapılan işlemleri data dosyalarına yazmaya çalıştığı içindir. 

Detayına inersek, LGWR, bir sonraki redo log dosyasına geçtiğinde, bir önceki redo log dosyasının durumunu controlfile içinde CURRENT’ten ACTIVE’e çevirir. Akabinde DBWR (Database Writer) işlemini durumdan haberdar ederek, bir önceki redo log dosyasında checkpoint işlemi yapmasını gerektiğini belirtir. DBWR tarafından checkpoint işlemi tamamlanıp, redo log’daki değişiklikler veritabanı dosyalarına yazıldığında CKPT process’i çağrılır. CKPT işlemi veritabanı dosyalarının header bilgilerini ve check point bilgisini (sadece) controlfile içerisinde günceller. (CKPT tarafından yapılan güncelleme bilgisi v$datafile_header tablosundaki checkpoint_change# ve checkpoint_time bilgileriyle ilgilidir.) Burada dikkat edilmesi gereken, CKPT’in redo log bilgisine dair bir güncelleme yapmamasıdır. isminden de belli olacağı gibi sadece checkpoint işlemiyle ilgilenir. CKPT işlemi tamamlandığında, LGWR işlemi çağrılarak controlfile içerisinde redo log bilgisini ACTIVE’den INACTIVE’e çeker. (Bu güncelleme, v$log status bilgisini sağlar.) Bu değişiklik düşük önceliklidir, çünkü bu konuyla tek ilgilenen process LGWR’in kendisidir. Buradaki status bilgisine göre, LGWR redo log dosyasının tekrar kullanılıp kullanılmayacağına karar verir. (Eğer redo log dosyası ACTIVE durumdaysa, checkpoint işleminin sonuçlanması bekleniyor demektir.)

Burada hemen yeri gelmişken önemli bir noktaya değinelim. Active durumdaki redologun datafilelere aktarılması işlemi bitmeden current durumdaki redolog dosyasının dolması durumunda oracle “Thread 1 cannot allocate new log, sequence “ hatasını döndürür.  Bu durumdan kurtulmak için redolog dosyalarımızın sayısını ve boyutunu iyi belirlemeliyiz.

Yukarıda altını çizerek anlatıığımız LGWR’nin redo log dosyaklarının statüsünü güncellemesinden yetersiz bulup değiştirmek istiyorsak

SQL> ALTER SYSTEM CHECKPOINT;
ile checkpoint atarız

Yada

LOG_CHECKPOINT_TIMEOUT Parametresinin timeout süresini sistemimize uygun olarak set ederiz.

SQL> SHOW PARAMETER LOG_CHECKPOINT_TIMEOUT;

SQL> ALTER SYSTEM SET LOG_CHECKPOINT_TIMEOUT=1800 SCOPE=BOTH;

Active durumdaki redologların yarım saatte bir check point edilerik datafilelere yazılması gerektiğini söylüyoruz.

Eğer redo log için yapılan checkpoint işlemini takip edip Alert log dosyasına yazdırmak istiyorsak

SQL> SHOW PARAMETER LOG_CHECKPOINTS_TO_ALERT;

SQL> ALTER SYSTEM SET LOG_CHECKPOINTS_TO_ALERT=TRUE SCOPE=BOTH; System switch log altered.

Redo Log Dosyalarının Durumları

a. CURRENT : Redo log dosyasının kullanımda olduğunu gösterir.

b. ACTIVE :  Current redo log dosyası değişmiştir. Ancak daha önce kullanımda olan redo log dosyasının içeriği henüz veritabanına aktarılmamıştır. Yazma işlemi devam etmektedir. LGWR tarafından active’lik durumu bir süre sonra, INACTIVE’e çekilir. Checkpoint komutuyla, yazma işleminin yapılmasını tetiklemek mümkündür.

c. INACTIVE : Kullanımda olmayan redo log dosyalarını ifade eder.

d. UNUSED : ilgili redo log dosyasının henüz hiç kullanmadığını gösterir. Yeni eklenen redo log dosyalarını, unused olarak görürsünüz.

e. INVALID : Dosyanın erişilemez (ya da bozuk) olduğunu işaret eder.

f. STALE : Dosya tamamlanmamıştır. ABORT ile ya da beklenmeyen ani veritabanı kapanmalarından kaynaklanmaktadır. 

Aşağıdaki viewlar ile online redo log dosyalarına ait bilgiler görebiliriz.

select * from gv$log order by inst_id, group#;

select * from gv$logfile;

select * from gv$log_history order by recid desc;

Redo log fillerın değiştirilmesi, gruplanması silinmesi gibi yapılan operasyonları ayrı bir konu ile anlatıyor olacağız.