Oracle Redo Log yönetimi

Önceki Yazımızda Redo Log mimarisi ve işleyişi hakkında konuşmuştuk. Şimdi Redo log eklenmesi silinmesi kısaca yönetimi hakkında konuşalım.

Redo loglar aynı diskte durduğu gibi farklı disklerde de durabilir. Bir Instance en az 2 log file istediğini daha önce söylemiştik. Aynı member(elemanların) oluşturduğu kümeye redo log grup denir. Ayrıntılı anlatırsak Bir problem çıkma ihtimâline karşı redo log dosyalarını çoklamak (multiplexing) mümkündür. Birinci redo log dosyası demek yerine, birinci redo log grubu denerek, bu gruba birden fazla redo log dosyası eleman/üye (member) olarak atanır. Grup içindeki redo log dosyalarının hepsi de aynıdır.

SQL> select GROUP#,THREAD#,SEQUENCE#,BYTES,MEMBERS,STATUS from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS STATUS

---------- ---------- ---------- ---------- ---------- ----------------

         1          1       1351   52428800          1 INACTIVE

         2          1       1352   52428800          1 CURRENT

         3          1       1350   52428800          1 INACTIVE

SQL>

Redo Log dosyalarını oluşabilecek olağan dışı durumlara karşı çoklu (multiplexing) hale getirirsek o kadar güvenli olmuş oluruz. Öncekiyazımızda Redo Log mimarisinde işleyişi anlatmıştık. LGWR, bir sonraki grup elemanları arşivlenmediği için erişemiyorsa, Grup elemanları arşive çıkılana ve kullanım için uygun hâle gelene kadar, işlem durdurulur.

Yine başka bir senaryo da Sıradaki grubun bütün elemanlarına donanım kaynaklı bir problemden erişilemiyorsa, Oracle hata döndürür ve veritabanı kapatılır. Bu durumda, bir online redo log’un olmayışı nedeniyle recover işlemi yapmanız gerekebilir.

Bu sebeple Multiplexing yapılan elemanların farklı disklere yazılması veri önemlidir.

Şimdi Redo Log dosyaları ile neler yapabileceğimize bakalım

Redo Log’lara Grup/Eleman Ekleme/Çıkartma Boyut değiştirme / Yeniden adlandırma vs...

Öncelikle durumuna bakalım

SELECT F.MEMBER, L.* FROM V$LOGFILE F, V$LOG L WHERE F.GROUP# = L.GROUP#

Yeni Redo Log eklenmes: (ADD NEW ONLINE REDO LOG);

Şimdi  basit ilerleyelim ve hazırda bulunan 3. Online Redo Log file group için 4. File ekleyelim.

SQL> ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/denizgyotst/redo04.log ') SIZE 50M;

Database altered.

Ayni anda iki elemanli yeni bir grup eklemek:

SQL> ALTER DATABASE ADD LOGFILE GROUP 5 ('/u01/app/oracle/oradata/denizgyotst/redo51.log', '/u01/app/oracle/oradata/denizgyotst/redo52.log' ) SIZE 50M;

Kontrol edelim

Drop edip, Boyut değiştirme :

Redo log gruplarını mümkün olduğunca birbiriyle aynı şekilde tutmak önemlidir.  Bazı durumlarda mevcut redolog fillerın size ni eşitlemek isteriz. Şimdi bu duruma yönelik bir çalışma yapalım

 Tabi önce durumuna bir bakalım.

Şayet işlem yapacağımız Redo Log aktif ise switch etmemiz gerekecek. (2. Redo group için)

SQL> alter system switch logfile;

System altered.

SQL>

Şimdi tekrar durumlarına bakalım

SELECT F.MEMBER, L.* FROM V$LOGFILE F, V$LOG L WHERE F.GROUP# = L.GROUP#

Gördüğünüz gibi 2.Log file Active, 3.Log file current duruma geçti. Yani LGWR daha önce 2.Log’a yazarken şimdi 3.Log’a yazmaya başladı. LGWR bunun yanında DBWR ‘a 2.Log için mesaj verdi. 2.Log sistem check point atana kadar active statusünde kalacak.  (Bu konuyu önceki konumuzda detaylı behsetmiştik )

Eğer sistemin check pointi ni beklemek istemiyorsak manuel checkpoint atarız.

SQL> alter system checkpoint;

System altered.

Şimdi yeniden bakalım.

Evet artık Inactive grup silinebilir yeniden boytlandırılabilir işlem yapılabilir.

SQL> alter database drop logfile group 2;

Database altered.

SQL>

Şimdi yeniden ekleyelim!

SQL> alter database add logfile group 2 size 50M;

Database altered.

SQL>

Kontrol ettiğimizde görüyoruz ki UNUSED durumda hemen switch ediyorum..

SQL> alter system switch logfile;

System altered.

SQL>

Ve Current duruma geçtiğini görüyorum..

Bu işlemi boyutunu değiştirmek istediğimiz redo log grupları için yapabiliriz. Yeniden eklediğim 2.Grup içinde aynı boyutu verdim.

Drop log member:

Redo log gruplarını mümkün olduğunca birbiriyle aynı şekilde tutmak önemlidir demiştik. Yani bir

grubu 2 elemanlı yaratırken, diğer grubun 4 elemanlı olması tasarım açısından güzel

gözükmeyecektir.

SQL> ALTER DATABASE DROP LOGFILE MEMBER '/u01/app/oracle/oradata/denizgyotst/redo52.log';

Database altered.

Bu arada DROP edilen redo log nesneleri aslında silinmezler. Ancak bir daha kullanılamazlar.

İyi çalışmalar diliyorum

Usta.. 

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.