Redolog Yaratmak, Taşımak, Silmek, Boyutlandırmak

Selamlar,

Bu yazımda veritabanında nasıl redolog boyutlandırabiliriz, taşıyabiliriz, silebiliriz ve nasıl yeniden yaratabiliriz, bu konuyu ele almak istiyorum.

Öncelikle neden redolog'larımıza bu işkenceyi yapmak isteyelim? Cevabı o kadar basit ki, "performans". Evet, performanstır bu sorunun cevabı zira "private strand flush not complete" veya aynı mantıkla "Checkpoint not complete" hatalarını alert.log dosyasında gördüğünüz zaman, "Configuration, Commit ya da Concurrency" başlığı altında bekleme olaylarını göremeye ve veritabanı çok yavaşladı, ne yapıyorsun gibi yorumları da almaya hazır olun.

Bu durumda yukarıda bahsettiğim hatalarla başlayalım. Bu hatalar nedir ve alındığı zaman nelere sebep olmaktadır?

1) Veritabanında "wait event" (bekleme olayı) yaratarak, genel veritabanı performansını negatif yönde etkiLEYEBİLİR. Kalın olarak belirtmemin sebebi ise kimi durumlarda da göz ardı edilebilir. Bu durumlar, veritabanında "commit ya da rollback" işlemlerinin yoğun olmadığı ancak logfile'ların çok hızlı değiştirildiği durumlar.
2) Genel veritabanı performansını ciddi ölçüde etkileyerek, diğer uygulamaların, sorguların ve işlemlerin de çalışmasını olumsuz yönde etkiLEYEBİLİR.

Örnek;

Günde 200 - 250 gigabyte archivelog'un oluştuğu bir veritabanınız var ve redolog boyutlandırmasını çok büyük ve grup adedini de az yaptınız diyelim. Başınıza gelecek felaketleri anlamak için yukarıda yazdıklarımı yeniden okuyunuz. Asıl sebep ne olabilir?

Bu durumun gerçek sebebi ise LGWR işleminin, henüz aktif olarak kullanılmakta olan online redolog'ları yeniden kullanmak istemesi ve DBWR'ın buna "engel" olması. Bildiğiniz gibi checkpoint dediğimiz bir yapı bulunmakta ve redolog dosyalarındaki verilerin, fiziksel datafile'lara yazılmasını sağlamakta. Ancak o kadar çok commit işlemi yapılıyor ve o kadar çok redo üretiliyor ki, DBWR, LGWR'ın hızına bir türlü yetişemiyor. Bu durumlarda da "Configuration" veya "Commit" hatta "Concurrency" bekleme olayları başlıkları altında ciddi zamanlar kaybedersiniz.

Peki gelelim redolog'ları nasıl değiştirebileceğimize. Aslında bu konu ile yukarıda yazdığım hataların konusu biraz birbiri ile alakalı zira bir redolog'u öncelikle veritabanından silebilmeniz için;

1) İlgili redolog'un statüsünün "INACTIVE" olması gerekiyor.
2) İlgili redolog'un mutlaka archivelog'unun oluşması gerekiyor.

Unutmadan, redolog'ları yeniden yaratmak için ya da boyutlandırmak için veritabanını kapatmanıza gerek yoktur. Bazı veritabanı yöneticileri redolog'ları taşımak için veritabanını kapatıyorlar ama aslında buna hiç, hiç gerek yok.

Adımları sırası ile yazalım;

1) V$LOG fixed görüntüsünü sorgulayalım. STATUS sütunu "INACTIVE" ve "ARCHIVED" sütunu "YES" olan bir redolog görüyorsanız eğer hemen düşürebilirsiniz. YALNIZ eğer redolog gruplarınızın adedi iki ise, drop ederken hata alırsınız çünkü bir veritabanında en az 2 adet online redolog grup bulunması şart.

a) Eğer iki adet redolog grup bulunuyorsa istenilen boyuttaki yeni log grubunu ekleyelim;

SQL> ALTER DATABASE ADD LOGFILE GROUP 3 ('/db/oracle/redo05.log','/db/oracle/redo06.log') SIZE 500M [REUSE];

Yukarıdaki komut, 3ncü bir redolog grubu yaratacak ve redo05 ve redo06 isimlerinde, toplam 500 megabyte boyutunda olacaktır. redo05 ve redo06 redolog'ları önceden yaratılmış ve verdiğimiz lokasyonda bulunmakta ise REUSE komutunu da sorgunun sonuna eklememiz gerekiyor.

b) Eğer iki adet redolog grup'tan fazlası bulunuyorsa;

SQL> ALTER DATABASE ADD LOGFILE GROUP 7 ('/db/oracle/redo10.log','/db/oracle/redo11.log') SIZE 500M [REUSE];

Eklerken yine bir problem ile karşılaşmadık. Ancak şimdi ise düşürmek isteyelim;

c) Veritabanından bir redolog grubu silmek istersek;

SQL> ALTER DATABASE DROP LOGFILE GROUP 6;

Alacağınız muhtemel sonuçlar ise;

1) Düşürmek istediğiniz redolog grubunun statüsü ACTIVE ise hata alırsınız (V$LOG --> STATUS).
2) Düşürmek istediğiniz redolog grubunun archivelog'u henüz oluşturulmamış ise yine hata alırsınız (V$LOG --> ARCHIVED).
3) Düşürmek istediğiniz redolog grubunun statüsü INACTIVE ve archivelog'u oluşturulmuş ise gönderdiğiniz drop logfile komutu başarılı olacaktır.

Bu redolog'ların yeniden yaratılması işini bir temp algoritması gibi de düşünebilirsiniz. Eğer 2 tane redolog grubunuz varsa ve bu redolog gruplarının sadece boyutunu arttırmak istiyorsanız eğer ve diyorsanız ki redo isimleri de aynı kalsın, sıradan bir redolog grubu yaratarak işe başlayabilirsiniz. Ardından bu geçici süre ile yarattığınız üçüncü redolog grubuna gelene kadar;

SQL> ALTER SYSTEM SWITCH LOGFILE;

komutunu gönderirsiniz. V$LOG görüntüsü size, üçüncü redolog grubunun aktif olduğunu söylediği zamansa birinci redolog grubunu düşürebilirsiniz FAKAT yine bahsettiğim gibi bu redolog grubu henüz ACTIVE ve archivelog'u üretilmemiş ise göndereceğiniz komut şudur;

SQL> ALTER SYSTEM CHECKPOINT;

Bu noktada hemen belirtmem gerekiyor. ALTER SYSTEM SWITCH LOGFILE komutu, bir sonraki redolog grubuna geçmemizi sağlar. Sonuçları ne olursa olsun veritabanı, yeni bir redolog grubunu kullanmaya zorlanmaktadır. ALTER SYSTEM CHECKPOINT komutu ise veritabanını bir checkpoint yapmaya zorlamaktadır ve commit edilmiş, redolog'larda bulunan bütün transaction'lar fiziksel datafile'lara yazılmak için ayrıca zorlanmaktadır. Bu komutun GLOBAL ve LOCAL ekleri de bulunmakta ancak bu ekler sadece real application cluster node'ları için geçerlidir, tek node'lu çalışan bir veritabanın da gözardı edilecektir ama komutunuz yine de çalışacak ve checkpoint gönderilecektir.

Yukarıdaki ilk komutu gönderdik ve geçici olarak yarattığımız redolog grubunu CURRENT olarak belirledik (V$LOG --> STATUS). Current bilgisini gördüğünüz zaman o redolog kullanılmata demektir. LGWR şu anda aktif olarak bu redolog'lara, commit edilen transaction'ların verilerini yazmaktadır. İkinci komutu göndermemizin nedeni ise hala ACTIVE olarak gözüken redolog gruplarının, checkpoint'i beklemeden checkpoint'e zorlanarak, statüsünü INACTIVE'e çekmektir. ARCH görevi ise bu esnada, ilgili redolog'un bir archivelog'unu üretmekle meşguldür. Archivelog'u üretilen ve statüsü INACTIVE'e geçen birinci redolog grubumuzu düşürelim;

SQL> ALTER DATABASE DROP LOGFILE GROUP 1;

Şimdi de yeniden yaratalım. Ancak bu sefer reuse komutunu kullanmazsak yine bir ORA hatası almaya hazır olmamız gerekiyor çünkü ilgili redolog'ları henüz fiziksel olarak silmedik.

SQL> ALTER DATABASE ADD LOGFILE GROUP 1 ('/db/oracle/redo01.log','/db/oracle/redo02.log') SIZE 750M REUSE;

İkinci redolog grubunu da değiştirmek için yine bu yolu izleyebilirsiniz.

Şimdiye kadar bir redolog grubu nasıl boyutlandırılır, nasıl silinebilir bu konuları inceledik. Redolog'u taşımak içinse yapmanız gereken tek şey, yeniden yaratırken lokasyonunu değiştirmek!

Yukarıdaki aşamalarda alınabilecek hata kodlarını merak eden okuyucular olabilir. Alabileceğiniz hata kodlarından hatırladığım, ORA-00350 hatası bulunmakta. Diğeri ise ORA-01624. Alert.log dosyanızda ise şu şekilde bir satır yazacaktır;

ORA-1624 signalled during: ALTER DATABASE (Statüsü ACTIVE olan redolog grubunu düşürmek isterseniz alacağınız hata).
ORA-350 signalled during: ALTER DATABASE (Archivelog'u henüz oluşmamış olan redolog grubunu düşürmek isterseniz alacağınız hata).

İyi çalışmalar dilerim.

Ogan