Physical Standby Automatic Archivelog Deletion / Maintenance

Selamlar,

Genelde yazılarımın başlıklarını Türkçe, içeriği Türkçe ve mümkün olan bütün kelimeleri de yine Türkçe yazmaya özen ve dikkat gösteriyorum. Ancak bu sefer başlığı İngilizce yazmamın nedeni birçok insanın İngilizce olarak arama yapması ancak Türkçe bulduğu zaman daha işlerine yaramasını sağlayabilmek. Etiket olarakta ayrıca ekledim.

Geçtiğimiz gün tarafıma iletilen bir soru üzerine çözüm ürettim ancak ürettiğim çözümün internet üzerinde, bu başlık ile ilişkilendirilmediğini gördüm. Konu şu; bir fiziksel veritabanımız var ve veritabanınızın v$archived_log fixed view'ını görüntülediğiniz zaman "applied" başlığı altındaki en güncel archivelog'un, fiziksel veritabanınıza işlendiğini gördünüz. v$dataguard_status view'ında da işler yolunda gidiyor. Peki bu oluşan archivelog'lar neden silinmiyor? Buradaki önemli sorulardan birisi budur aslında. Archivelog'ların bakımı (silinmesi, yedeklenmesi) ile ilgili inanılmaz boyutlarda soru - cevap internet üzerinde mevcut ancak data guard söz konusu olunca işler değişiyor.

Bunu sağlayabilmenin iki tane yolu var. Archivelog'ları Oracle'a otomatik olarak sildirtebilirsiniz ya da yedeği alınırken silinebilir. Her iki yolu da anlatacağım.

1) Archivelog'ların Oracle Tarafından Otomatik Olarak Silinmesi:

Bunu sağlayabilmek için 2 tane parametre tanımlamamız gerekiyor. Bir tanesi db_recovery_file_dest ve diğeri de db_recovery_file_dest_size. Bu parametreleri 10g için SGA_TARGET, 11g için MEMORY_TARGET gibi düşünebilirsiniz (mantık aynı, görevleri farklı). Oracle oluşan archivelog'ları tanımlamış olduğunuz db_recovery_file_dest alanına;

/db_recovery_file_dest/ORACLE_SID/archivelog/DATE/%arc_%s_%t şeklinde tanımlar. Buradaki archivelog formatını ise log_archive_format parametresi belirler. Oracle oluşan archivelog'ları gün gün ayırır, silinmesi gerekenleri siler. Silinmesi gerekenler nedir? db_recovery_file_dest_size parametresine tanımladığınız bilgi eğer %100'e yaklaşmış ise size uyarıda bulunur. Tepki vermezseniz kendisi otomatik olarak siler! Bu arada bu iki parametreyi de eğer spfile kullanıyorsanız dinamik olarak tanımlayabilirsiniz. (alter system ... scope=both);

Bu uyarının çıktısı ise şöyle olacaktır;

Errors in file /usr/ORACLE/u01/oracle/admin/smstby/udump/smstby_rfs_18686.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 1073741824 bytes is 97.09% used, and has 31258624 remaining bytes available.
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************

Uyarının nedeni db_recovery_file_dest_size'ın neredeyse dolmuş olması. Yukarıdaki örnekte %97 dolu durumda gözüküyor. Peki bu 4 maddeyi yapmazsanız Oracle ne yapıyor? O da aşağıda;

Wed Jun 30 09:31:40 2010
RFS[13]: Archived Log: '/usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48375_62oqpf58_.arc'
Primary database is in MAXIMUM PERFORMANCE mode
Deleted Oracle managed file /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48372_62on259d_.arc
Deleted Oracle managed file /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48373_62oojwrq_.arc

Veritbanının devamlılığını sağlayabilmek için bu archivelog dosyalarını otomatik olarak siliyor.

Bu veritabanı için db_recovery_file_dest parametresini /usr/ORACLE/archive/SMSTBY/ olarak tanımladım ancak Oracle archivelog'ları /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/ altında oluşturdu. Bu da kendisinin yönettiğini gösteriyor. Bunu da yapabilmek için ilgili dizinde Oracle kullanıcısının (unix) okuma ve yazma hakkının olması gerekiyor. Bu bilgiyi işletim sistemi yöneticisinden alabilirsiniz.

2) RMAN ile Archivelog'ların Silinmesi:

Bir diğer yöntem ise her zaman geçerli olan Recovery Manager ile archivelog'ların yedeklenmesi. Bu başlıkta kendi içerisinde ikiye ayrılabilir. Birincisi kişinin *nix üzerinde oluşan archivelog'ları elle silmesi, diğer de bu log'ları RETENTION PERIOD belirleyerek "obsolete" hale getirerek Recovery Manager tarafından sildirmesi. Ben ikinci yolu her zaman daha olumlu buluyorum çünkü elle silindiği zaman ek işler ve masraf devreye giriyor.

Elle sildiğimiz zaman bunu Oracle'a bildirmek zorundayız. Oracle otomatik olarak bu archivelog'ların silindiğini anlayamaz. Yedekleme yaparken hata alırsınız ve yedeklemeye çalışır sonra da bulamıyorum der. Bunun için;

RMAN> crosscheck archivelog all;

Komutunu amacı archivelog'ları Oracle'a göstertmek ve varlığını öğretmek. Crosscheck komutundan sonra "obsolete" archivelog'ları silebilmek için;

RMAN> delete noprompt obsolete;

Bu yöntemler eski archivelog'lardan kurtulabilirsiniz. Diğer yöntemde ise recovery catalog değil de control dosyasını yedek listelemede kullandığınızı varsayıyorum. Control dosyasının yedek bilgilerini tuttuğunu ve aşağıdaki parametreye göre bakımını yapması gerektiğini söyleyebilirim;

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

Yukarıdaki komut aldığınız yedeklerin, archivelog'ların vb. 7 gün boyunca "expired" ya da "obsolete" olmayacağını garanti eder.

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 5;

Yukarıdaki komut ise aldığınız 5 tane veritabanı yedeğinden sonraki 6ncı ile birlikte, 1ncinin "expired" yani aslında kullanılamaz olarak etiketlenmesini sağlar.

Peki bu komutların standby archivelog'ları ile ne ilgisi var? Bir diğer parametrenin tanımlanması ile;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Varsayılan değeri NONE olan yukarıdaki parametreyi APPLIED ON STANDBY ile değiştirirseniz eğer "obsolete" olan archivelog'lar yedekleme sırasında standby veritabanından silinecektir.

Eğer yedekleme işlemini birincil veritabanında yapıyorsanız;

Birincil veritabanında;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

Yedek veritabanında;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Eğer yedeklemeyi yedek veritabanında yapıyorsanız;

Birincil veritabanında;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Yedek veritabanında;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

Oracle dokümantasyonuna göre (11g) yedekleme işlemine gerek kalmadan, APPLIED ON STANDBY derseniz mantıksal ya da fiziksel yedeğin archivelog'ları silinecektir.

Yukarıdaki genel bilgiler ışığında benim tercih ettiğim method ilk olarak anlattığım. "Flash recovery area" bilgisinin tanımlanmış olması önemli bir kriter zira birçok veritabanı archivelog'ların şişmesi ve eksik bakım yapıldığından çökebiliyor. Ölümcül bir hata değil, veritabanı bir süre daha varlığını devam ettirebiliyor ancak bir süre sonra ARCHn görevi ölüyor ve archive alınması işlemini veritabanı terk ediyor. Bu durumda veritabanını kapatmanız, archivelog'ların artık bulunmadığını Oracle'a öğretmeniz (eğer elle silmişseniz) ve veritabanını yeniden açmanız gerekecektir.

İyi çalışmalar,

Ogan