12 Şubat 2008 Salı

RMAN ile Backup/Restore/Recover

Selamlar,


Öncelikle bu yazının çok daha kapsamlı halini aşağıdaki bağlantıya tıklayarak bulabilirsiniz;



Oracle Recovery Manager (RMAN) - Recovery Catalog Database



RMAN yani Recovery Manager, Oracle veritabanının yedeğinin alınmasını ve yedekten dönülebilmesini sağlar. Temel olarak aslında bu işe yarar. Bunun dışında bir sysdba'in RMAN kullanmasının sebepleri şu şekilde sıralanabilir:
RMAN,


1) Hot(online) yedekleme ve artımlı (incremental) yedekleme yapabilir.
2) Partial(PIT-Point in Time) veya bütün kurtarma (complete recovery) yapabilir.
3) Herhangi bir kısmi yedek (incomplete backup) ile karşılaşılırsa, tamamlayabilir.
4) Spfile ve controlfile'ların yedeğini alabilir.

5) Kaset veya Oracle Secure Backup ünitesine yedekleme yapabilir.
6) Blok tamiri yapabilir.

Rman dışındaki yedekleme sistemlerinde ve tekniklerinde (Cold backup, export/import, data pump) çalışan (online) veritabanının yedeğini sağlıklı bir şekilde asla alamayız. Evet, "tutarlı" olacaktır zira veritabanı kapalıyken ve kapatılırken de normal, transactional veya immediate seçenekleri ile kapatılmış ise kontrol dosyasının, redolog'ların, datafile blok başlıklarının gösterdiği SCN numaraları aynı olacaktır ve bu da veritabanının alınması planlanan yedeğini tutarlı kılmaktadır.
Öncelikle RMAN ile sağlıklı bir şekilde yedek alabilmemiz için, veritabanımızın ARCHIVELOG modunda olması gerekmektedir. Bu esnada konuda biraz uzaklaşıp, archivelog nedir ona bakalım.
Archivelog, veritabanımızda gerçekleşen transaction hareketlerinin geçmişlerini tutan bir log dosyasıdır. Online redolog dosyalarının yedeğidir. Veritabanımıza ait redologların dolmasının ardından diğer redo log'a geçiş yapılırken, geçiş yapılmadan önce kullandığımız redo log'un archivelog'u alınır. Eğer sistemde 3 adet redo log varsa, hepsi bir tur döndükten sonra ilk baştaki veri geçmişinin üzerine yazılmaya başlanır. Archivelog'lu veritabanında bu sıkıntı ile karşılaşılmaz. Redo log grupları dönmeye devam ederken, hepsinin geçmişleri tutulur. Ancak dikkate alınması şart olan husus archivelog'ların tanımlandığı alanların (DB_RECOVERY_FILE_DEST veya LOG_ARCHIVE_DEST_n (1-10 arası)) dolmaması. Eğer bu alanlar dolarsa, redolog'lara yazım, archivelog yazması tamamlanmadığı sürece yapılamayacak ve veritabanı askıya alınacaktır. Veritabanı instance'ı bir arka plan görevinin zorlaması ile sonlandırılmayacak ancak veritabanı üzerindeki hiçbir kullanıcı işlem (transaction) yapamayacaktır.
Veritabanımızı archivelog'a geçirelim (Destination kısmını Oracle default olarak düşünelim).
Veritabanımızın mount modunda açılmış olmasına dikkat edelim.



SQL> shutdown [normal | transactional | immediate];
SQL> startup mount;
SQL> alter database archivelog;

SQL> alter database open;
SQL> archive log list;

Evet bu andan itibaren redo log'larımızın geçmişleri tutuluyor. Artık RMAN ile archivelog yedeği alabiliriz. Bir deneme yapmak istiyorsanız eğer;



SQL> alter system switch logfile;
SQL> archive log list;

Komut satırında veya terminalde iken:


 # rman target username/password (yetkili kullanıcı ile) bağlanalım.


RMAN> BACKUP DATABASE;


dediğimiz anda veritabanımızın online olarak yedeği alınır. Bu yedeğe archiveloglarıda eklemek istersek;

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;


yazmamız gerekir. Bu sayede veritabanımızın yedeği ve bütün archivelogların yedeği alınır. Yedeği alınmış archivelogları, yedek alınırken silmek istersek;


RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;


yazmamız gerekir. Bu sayede bütün veritabanının ve archivelogların yedeği alınır, yedeği alınmış ve artık yer kaplayan duruma gelmiş archiveloglar RMAN tarafından silinir.


Bu sırada archivelog dosyaları elle silinmiş ise (yer problemlerinden dolayı veritabanındaki geçici askıya alınma durumunu gidermek için silinmiş olabilir) şu komutu çalıştırmalıyız;


RMAN> CROSSCHECK ARCHIVELOG ALL;


Bu sistem bizim RMAN ile yapabildiğimiz level 0 yani bütün veritabanı yedeklemesidir. Rman'in bir başka özelliği ise artımlı yedek alabilmesidir. Bu tamamen bir stratejidir ve gerekli durumlarda kullanılabilir.


RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;


bu komut tam yedekleme yapılmasını sağlar. Farkı ise catalog oluşturarak, sonra ki incremental level'ları için bir çeşit flag tutulmasını sağlar. Bunun yanı sıra RMAN, blok sıkıştırma yöntemi ile yedekleme sırasında farkettiği kullanılmayan blokları önce sıkıştırır ve ardından yedeğe dahil edilmesini engeller.


RMAN>BACKUP INCREMENTAL LEVEL 1 DATABASE;


bu komut ile level'lar arasındaki farkın yedeğini almış oluruz. Geliştirilen stratejiye göre seviyeler değiştirlebilir.


Özet olarak bu şekilde veritabanımızın sağlıklı yedeğini alabiliriz. Bu yedeğin düzgün alınıp alınmadığını ise;


RMAN> RESTORE DATABASE VALIDATE;


komutu ile anlayabiliriz.



RMAN> LIST BACKUP;


Yukarıda komut ile de aldığımız yedek(ler) hakkında bilgi elde edebiliriz.

Rman'in çeşitli restore/recover senaryoları vardır. Eğer controlfile'larımız ile ilgili problem yaşadıysak incomplete recovery yapmamız gerekir. Incomplete recovery yapıldığı zaman redo loglardaki tutulan sayılar ile önceden yedeği alınmış controlfile'ların sayıları tutmayacağı için redo log'larımızı resetlememiz, yani sekanslarını sıfırlamamız, içlerini tamamen boşaltmamız ve veritabanını resetlogs komutu ile açmamız gerekir.


Eğer datafile'larımız kayıpsa, sadece restore ve recover database komutları ile veritabanını ayağa kaldırabiliriz.


Rman ile point in time recovery yapılabilir. İstediğimiz bir saate veya istediğimiz bir SCN(system change number)'a dönebiliriz. Bunuda rman, yedeğimizin üzerine archivelog'ları uygulayarak yapar.

Bu noktada en önemli nokta, RMAN yedeğinin mutlaka aynı işletim sistemi ve aynı Oracle versiyonlarında ayağa kaldırılmısı gerektiği. Veriyonu ve işletim sistemi farklı bir sistemde yapılabilecek en mantıklı yedekten dönme export/import olacaktır.

Rman'in yedekleme yapısı ise şöyledir.
Veritabanının ve arşivlerin yedeği alınır,
Backup, veritabanına işlenir,
Üzerine veritabanının yedeğinin alındığı zamandan bu zamana oluşan arşivler uygulanır,
En son commit'e kadar veritabanı getirilir. Tabii bu senaryoda redolog dosyalarının olduğunu veya hiçbir redolog grubundaki üyelerin tamamen yok olmadığını düşünüyoruz. Aksi halde en son yapılan commit'e kadar veritabanını getirmenin imkanı yoktur. Veri kaybı kaçınılmazdır.

Son olarak, archivelog'a alınmamış bir veritabanının %100 sağlıklı ve kullanılabilir yedeğinin alınması kesinkle doğru değildir. Mutlaka RMAN ile yedekleme stratejilerinin geliştirilmesi gerekmektedir. Bu şekilde olası veri kayıplarından veritabanımızı büyük ölçüde korumuş oluruz ve veritabanının çöktüğü anlarda çabuk dönüş gerçekleştirebiliriz.


İyi çalışmalar,

Ogan

4 yorum:

Adsız dedi ki...

Emeğinize sağlık, anlaşılır bir şekilde anlatmışsınız. Çok faydalı bir çalışma olmuş. Teşekkür ediyorum herkes adına.

Adsız dedi ki...

complate recovery yapabilmek için her zaman
1. En son bir "rman> backup database"
2. düzgün yedeklenmiş "archive loglar"
2. Redolog grouplarına tanımlanmış ikincil yedek memberlar(redolog01b.log, vb.)

alınması gerekmektedir.

Adsız dedi ki...

Yazı çok güzel olmuş teşekkürler. Ancak sanırım,

alter system archivelog;
yerine
alter database archivelog;
olması gerekiyor.

İyi çalışmalar,

Ogan Ozdogan dedi ki...

doğru alter database archivelog komutu ile archivelog'u devreye alıyoruz. Örnek biraz eski olduğu için sanırım gözümden kaçmış, teşekkür ederim. şu anda düzelttim.

Takip et: @oganozdogan