Block Checking sayesinde corrupt block'ları fark edebiliriz. Corrupt block'lar bizim data okuyamamıza veya data kaybımıza neden olabilir.
Corrupt Block'lar Logical veya Physical şekilde olabilir. Bu block'lar keşfedildikleri durumda rman'le kolayca düzenlenebilirler.
SQL>alter system set db_block_checking = true scope=both; Scope=both diyerek hem session bazlı hem de kalıcı olarak parametremizi set ederiz. Bu parametrenin set edilmesi demek database'imizin zaman zaman block'ların checksum'ını kontrol etmesi demektir. Bu da bizim sistemimizde performans artışlarına neden olabilir.
2- Rman Backup'ları için Block Tracking Özelliğinin Açılması:
Rman backup'larında en son alınan backup'takine göre değişmiş olan blokların backuplanmasını sağlar. Bu işlemde backup alımındaki zamanı azaltırken yine performansta bir düşüşe neden olabilir.
Rman'de backup set alınırken zaten boş block'lar backup'lanmazken sadece dolu olanlar backup'lanmaktaydı. Bu özelliği kullanırsak bu dolu olanlardan da sadece en son backup'a göre değişmiş olanları backup'larız. Bu sayede backup size'ları önemli oranda değişebilir.
SQL>alter database enable block change tracking using file '/u01/tracking/change_tracking';Yukarıdaki komutumuzda Linux işletim sistemizde bulunan bir dosyada saklanmak üzere block tracking işlemini gerçekleştiririz.
3- Log Gruplarının ve Üyelerinin Çiftleştirilmesi ve Archive Log Destination Parametresinin Arttırılması:
Log dosyalarının çoğaltılması işlemleri archivelogların corrupted olması, onların bulunduğu disk'lerin çökmesi durumunda bize geri dönüş için bir seçenek oluşturur.
SQL> alter system set log_archive_dest_2='location=+ARCHLOG2' scope=both;
SQL> alter database add logfile member '+ARCHLOG2/redo21.log' to group 1; Buradaki örneğimizde hem log grubumuzu çoğaltırız hem de gruplarımıza ekstra bir eleman ekleriz.
Log yönetimi 1 ve log yönetimi 2 yazılarımızdan daha fazla bilgi edinebiliriz.
4- Database Backup'ı Gerçekleştirilirken "Check Logical" Paramtresi Kullanılmalı:
Bu parametre aşırı önemlidir. Genelde backup örneklerinde çok rastlanılmaz. Bu parametrenin kullanılması mantıksal olarak block corruption aramasını gerçekleştirir. Böylece aldığımız bir backup'ın başarılı olduğundan emin olabiliriz çünkü backup'lar completed olsalar bile logical corruption içerebilirler.
RMAN>backup check logical database plus archivelog delete input; Bu örneğimizde database'in archivelog ile beraber bir backup'ı alınırken backup'ın corruption'lara karşı bir check'i gerçekleştirilir. Ayrıca archivelog'lar backup'landıktan sonra kopyalar diskten silinir ve diskten yer açılır.
5- Backup'ların Test Edilmesi:
Backup'ımızın tamamen kullanılabilir olmasının test edilmesi validate komutuyla olur. "Validate" komutunun birden fazla kullanım yöntemi vardır.
İlkinde Rman'e girip backupları validate edebiliriz.
RMAN> VALIDATE DATABASE;
RMAN> VALIDATE BACKUPSET 22;
RMAN> VALIDATE DATAFILE 1 BLOCK 10; İkinci komutumuzu "Backup Validate"'dir. Bu komut'da gerçekten backup alınmaz. Sadece backup alınması durumunda herhangi bir sorunla karşılaşılıp karşılaşılmayacağını kontrol eder.
Hem physical hem de logical block check yapan ve corruption arayan komut aşağıdaki gibidir.
RMAN> BACKUP VALIDATE
CHECK LOGICAL
DATABASE
ARCHIVELOG ALL; Üçüncü komutumuz "Restore Validate"'dir. Bu komutumuzda da aldığımız backup'ı geri dönmeden önce validate ederiz. Bu komutla gerçekten restore etmeyiz. Restore edilmesi durumunda çıkacak sorunlar için kontrol yaparız.
RMAN> RESTORE DATABASE VALIDATE;
RMAN> RESTORE ARCHIVELOG ALL VALIDATE; 6- Her Backup Piece'de Sadece Bir Datafile Bulunması
Her backup piece'te bir tane datafile bulunması demek full restore yapmadığımız zamanlar için bize kolaylık sağlar. Partial Recovery yapıldığında database recovery yapılacak datafile'a ihtiyaç duyar. Eğer biz o partial recovery yapılacak datafile'ını birden fazla parçaya bölersek bu durumda recovery daha uzun sürer.
RMAN>backup database filesperset 1 plus archivelog delete input; 7- Rman Catalog'unun Yönetilmesi
Rman Backup'ları Catalog'a kaydedilerek yönetilir. Catalog'dan ise merkezi bir politika oluşturabiliriz. (Rman Catalog Nedir?)
Peki Merkezi Olarak Ne Yapabiliriz?
Öncelikle düzenli olarak "Delete Obsolete;" komutunu çalıştırırız. Bu şekilde retention policy dışında kalan backupları sileriz ve yer kazanırız.
RMAN>Delete Obsolete; Rman backup'ları crosscheck edebiliriz. Crosscheck işlemi rman catalog ile controlfile kayıtlarını karşılıklı olarak eşler. Eğer arada eksik varsa o kayıt expired olarak isimlendirilir. Expired backup'ları aşağıdaki komut ile silebiliriz.
RMAN> crosscheck backup;
RMAN> delete expired backup; Retention Policy to Redundancy seçeneğini ayarlayarak backup'ların tutulma süresini ayarlayabiliriz.
RMAN>show retention policy
RMAN>CONFIGURE RETENTION POLICY TO REDUNDANCY 2; Ancak bu ayarı ayarladıktan sonra mutlaka control file record keep time parametresini de set etmeliyiz. Yoksa bazı backup'ların redundancy durumu geçebilir. O yüzden iki ayarında birbiri ile aynı olduğunu kontrol etmeliyiz.
SQL> alter system set control_file_record_keep_time=21 scope=both;8- Recovery'nin Test Edilmesi:
Yukarıda 5. adımda restore, backup normal olarak database'in validate edilmesinden bahsetmiştik. Bir başka doğruluk kontrolünü recovery aşamasında da yapabiliriz. Bu işlemde de gerçekten recovery yapılmaz. Sadece yapılması durumunda neler olacağını inceler.
RMAN> recover database test; 9- Controlfile Autobackup'ının Set Edilmesi:
Bu aksiyonda controlfile'ın kaybedilmesinin önüne geçilebilir. Controlfile'ın backup'ı backup işleminin sonunda gerçekleştirilir.
RMAN> configure controlfile autobackup on; 
Hiç yorum yok:
Yorum Gönder