Recovery Manager (RMAN)
RMAN Oracle'ın kurulumu sırasında yüklenen bir yedekleme, yedekten dönme ve kurtarma aracıdır. Online, tutarlı ve sıcak yedek almak istiyorsanız recovery manager'ı kullanmalısınız. Bunun yanında veritabanınızın ARCHIVELOG modunda olaması gerekmektedir. RMAN online ve offline olmak üzere iki tip yedekleme yapabilir. Online alacağı yedeği veritabanını kapatmadan alabilirsiniz. Offline yedek içinse veritabanının kapalı (mount modda) olması gerekmektedir.
Yedekleme / Kurtarma Amacı
Bir veritabanının yedekleme ve kurtarma aracına birkaç nedenden dolayı ihtiyacı olabilir.
1) Veri Koruması
a) Medya Başarısızlığı (Disk yanması, veri dosyası bozulmaları gibi)
b) Kullanıcı hataları (tablo truncate, drop tablespace gibi)
c) Uygulama hataları
2) Verinin saklanması ve geçmişinin tutulması
3) Veri transferinin gerçekleştirilmesi
Archivelog modda olan bir veritabanının en önemli avantajı geçmişte bir zamana geri dönebilme imkanını bize sağlamasıdır (point-in-time recovery).
Geleneksel Yedekleme / Kurtarma Senaryoları ve Görevleri
Bir veritabanında oluşabilecek yukarıda belirttiğim hatalara karşı yalnızca yedekleme yapmayabilirsiniz. Başka birkaç aksiyon alarak da yedeklemenin yanında koruma sağlayabilirsiniz. Bunlar;
1) Yedekleme Konfigürasyonu: Bu konfigürasyona yedekleme stratejileri, yedeklemenin alınacağı günler, yedeklerin korunma ve elde tutulma periyotları, yedeklerin tutulacağı lokasyonlar ve yedeklerin şifrelenmesi (encryption) dahil edilebilir.
2) Zamanlama: Yedek alınması gereken tarih ve saati belirlemelisiniz ve bunun en yoğun anlarda gerçekleşmemesi gerekmektedir.
3) Sınama: Yedeklerinizi ve yedekleme stratejilerini eğer mümkün ise belirli periyotlarla sınamanızda fayda olacaktır.
4) Gözlemleme: Yedekleme operasyonunun tükettiği kaynakların gözlemlenmesi ve gerekiyorsa optimize edilmesi.
5) Restorasyon: Bozulmuş bir datafile'ın alınan yedekten çıkartılarak restorasyonunun yerine getirilmesidir.
6) Kurtarma: Veritabanındaki restorasyon operasyonundan sonra archive ve redo logların kullanılarak veritabanının ileriye sarılması işlemine denmektedir.
Yedekleme ve Kurtarma Çözümleri
1) Recovery Manager
a) Blok Kurtarma: Bir veriye ait spesifik bir bloğun kurtarılması işlemini yerine getirebilir.
b) Kullanılmayan Blokların Sıkıştırılması: Veritabanında tahsis edilmiş olarak gözüken ancak kullanılmayan blokları RMAN yedekleme sırasında sıkıştırır ve ardından yedekleme dosyasının içerisine dahil etmez.
c) Binary Sıkıştırma: Bilinen algoritmalar kullanılarak alınacak yedeğin boyutunun azaltılması yani sıkıştırılması sağlanabilir. Sıkıştırma derecesine göre CPU kullanımı artacak anlak yedeğin kaplayacağı alan azalacaktır.
ç) Yedek Şifrelemesi: İki çeşit şifreleme bulunmaktadır. "Wallet" ve şifre ile korunan yedekler. Amacı yedeklerinizi korumaktır.
d) Tam Yedekleme: İçerisinde veri bulunan bütün blokların yedeklenmesine denmektedir.
e) Artımlı Yedekleme: Bir önceki yedek ile şimdi alınan yedek arasındaki farkların yedeklenmesine denmektedir. İki seviyesi bulunmaktadır, 0 ve 1. 1nci seviye artımlı yedeklemenin iki tipi bulunmaktadır ve bunlar kümülatif ve farklar olmak üzere iki tanedir (cumulative, differential). Kümülatif yedekleme ile her zaman 0ncı seviyeye göre artımlı yedek alınırken, farklarda ise 1nci seviye farkları yedeklenmektedir.
Buraya kadar genel olarak nasıl yedekleme başlatılır veya RMAN kullanılırı incelemeye başlamadık, yalnızca yedekleme stratejileri üzerinde konuştuk. Şimdi ise RMAN'in önce yüzeysel olarak anlatımı ve ardından daha detaylı olarak işlenmesi ile devam edeceğim.
Recovery Manager Kullanımı
RMAN'e aşağıdaki komut ile bağlanabilirsiniz;
# rman target /
# rman target
Target ile ana veritabanının hangisi olacağını RMAN'e söylerken; catalog, auxiliary, nocatalog, cmdfile ve log gibi ek komutlarla da bağlantı biçimini ifade edebiliyoruz. Catalog, hangi katalog veritabanına bağlanacağımızı gösterir ve varsayılan olarak nocatalog komutu gönderilir. cmdfile ise RMAN'in çalıştıracağı komutların olduğu script'i, log ifadesi ise cmdfile içerisindeki işlemlerden sonra üretilecek log dosyasını gösterir.
# rman target / cmdfile = /home/oracle/db_full.sh log = /home/oracle/db_full.log
RMAN'in diğer komutları ile ilgili ilerleyen bölümlerde bahsedeceğim.
Oracle'ın bize tavsiyesi Archivelog modda çalışmakta idi. Bununla birlikte bize başka bir tavsiyede de bulunmaktadır. 11g'de yeni ismi ile "Fast Recovery Area", eski ismi ile "Flash Recovery Area" kullanmaktır. Yönetim açısından daha dinamik bir yönetimi vardır ve hatırlayalım, FRA içerisinde control file kopyaları ve redolog grup üyeleri her zaman tutulmakta iken kalan dosyaların silinme, ezilme durumları vardır. Bu, tanımladığımız alana ve yapılan operasyonların (yedekleme) sıklığına ve yedek koruma süresine bağlıdır.
Archivelog Mod
Veritabanı üzerinde transaction'ların neden olduğu bütün değişikliklerin kaydı online redolog'larda tutulmaktadır. Archivelog'lar ise sürekli değişen ve dönüşümü olan online redolog'ların yedekleridir. Veritabanında olup biten her şeyin geçmiş bilgisini içermektedir. Bir online redolog dolduğu zaman bir diğer redolog grubuna geçiş sağlanır ve ARCn görevi(leri) geçişi yapılmış önceki redolog'dan bir archivelog üretir.
Bir veritabanını archivelog moduna alabilmek için birkaç aşamadan geçmeniz gerekmektedir. Bu aşamaları elle yapabilirsiniz veya Enterprise Manager'ı kullanabilirsiniz. Buradaki önemli nokta veritabanını mutlaka tutarlı olacak şekilde kapatmanız gerekmektedir çünkü archivelog moduna alacağımız veritabanını abort ile kapatırsanız daha SMON devreye girmeden tutarsız bir veritabanında archivelog'a alma işlemini yapacağınız için hata alırsınız. Aşamalar ise;
SQL> SHU IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
SQL> ARCHIVE LOG LIST;
NOARCHIVELOG modunda olan bir veritabanının yedeğini RMAN ile alabileceğinizi ifade etmiştim. İleriki bir zamanda herhangi bir nedenden dolayı bu yedeğe dönmek isterseniz, yalnızca bu yedeğe dönebilirsiniz ve bundan sonraki bütün değişiklikler kaybolacaktır. Veritabanınızı archivelog moda aldıktan sonra mutlaka bir tam yedeğini alınız.
Archivelog üremesi ile ilgili olarak genelde birden fazla alanda üretilmesi tavsiyesi verilir. Bunun nedeni ise tek bir alan tamamen dolar ve daha fazla yazıma yer kalmaz ise veritabanı duracaktır, askıya alınacaktır. Bu durumda kullanabileceğiniz parametre LOG_ARCHIVE_DEST_n'dir. n, 1 ile 10 arasındır ve ARCn işlemleri 1 ile 10 arasındaki dizinlere yazım yapar. LOG_ARCHIVE_DEST_n belirtilmemiş olabilir, o zaman archivelog'lar FRA içerisinde üremeye başlar (USE_DB_RECOVERY_FILE_DEST).
SQL> alter system set LOG_ARCHIVE_DEST_1 = 'LOCATION=/u01/arch';
Uzak bir veritabanı tanımlamak isterseniz SERVICE ifadesini kullanmalısınız;
SQL> alter system set LOG_ARCHIVE_DEST_6 = 'SERVICE=stbydb';
Archivelog'ların üremesinin ve yazılmasının, verilen dizinler için garanti altına alınmasını sağlayabilirsiniz. Bunu sağlayan parametre LOG_ARCHIVE_MIN_SUCCEED_DEST'dir. Bu parametre tutana kadar online redolog'lar kullanılamayacaktır. Örneğin 3 tane LOG_ARCHIVE_DEST_n parametresi tanımladığınız ve bu parametreye de 1 verdiniz. Bu durumda 2 tane dizine archivelog yazması dursa bile 1 tanesine yazılmaya devam edildiği sürece bir problem olmayacaktır. Bunu kullanmak yerine opsiyonel olarak MANDATORY ifadesini de kullanabilirsiniz. Varsayılanı OPTIONAL olan bu parametrenin kullanım örneği ise aşağıdadır;
SQL> alter system set LOG_ARCHIVE_DEST_1 = 'LOCATION=/home/oracle/arch MANDATORY';
Mandatory yani zorunlu olan dizinde bir problem olduğu zaman da online redolog'lar kullanılmaz. Online redolog dosyalarının yeniden yazılması işlemine izin verilmez.
Koruma Süresi ve Tipine Karar Vermek
Sahip olduğumuz yedeklerin korunması yani Oracle tarafından silinmemesi ile ilgili bir ayarlama yapabiliriz ya da yedekleme stratejisinin bir parçası olarak da kullanabiliriz. RMAN'de aşağıdaki komutu çalıştırdığımız zaman korumanın nasıl ayarlanmış olduğuna bakabiliriz;
RMAN> show all;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
Kurulumlarda varsayılan olarak "redundancy 1" olarak tanımlanır. RMAN bir tane yedeğimizin elimizde durması gerektiğini bilir ve bir ikincisi aldığı zaman bu yedeği "OBSOLOTE" olarak işaretler ve silinebilecekler arasında tutar. FRA'nın dolması durumunda yedeklemenin devam etmesi için OBSOLETE olan yedekler sillinir. Bir diğer strateji ise koruma şartını verilen bir gün ile belirlemektir. Buna "recovery window" denmektedir. Bu günü tanımlayarak, veritabanımızın kaç gün geriye kadar dönülebileceğini yedekleme sistemi olan RMAN'e söyleriz. Diyelim 7 gün olarak belirledik;
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
10 gün önce bir tam veritabanı yedeğimiz bulunmakta. Aynı şekilde 8nci ve 3ncü günlerde de bir yedek almışız. Bu durumda 10ncü gün alınan yedek OBSOLETE olacak, 8nci ve 3ncü gün alınan tam veritabanı yedekleri ise "AVAILABLE" olarak (kullanılabilir halde) işaretlenecektir. Bunun nedeni ise 7 gün öncesine dönmek istersek 3nü gün aldığımız yedeği kullanamayacağız ve 8nci gün aldığımız yedeğin üzerine 1 günlük archivelog işleterek istediğimiz güne gelebiliriz. Bu sebepten dolayı RMAN 8nci gün aldığımız yedeği henüz OBSOLETE olarak işaretlemez. Aradan 5 gün geçerse ve hiç tam veritabanı yedeği almazsak bu durumda daha önceden 8nci gün aldığımız yedek de OBSOLETE olarak işaretlenecektir. Dinamik olarak değiştirilen koruma şartları ile RMAN'in OBSOLETE anlayışı da değişebilmektedir. Koruma şartını tamamen devre dışı da bırakabilirsiniz. Bunu yapmanızın nedeni yedeklerinizi bir başka sistem (tape - kaset) üzerinde tutmak isteyebileceğinizdir.
RMAN> CONFIGURE RETENTION POLICY TO NONE;
Fast Recovery Area
FRA bir birleşik alandır ve kurtarma ile ilgili olabilecek bütün dosyalar burada bulunmaktadır. Burada bulunan dosyalar iki tiptedir, kalıcı ve geçici. Kalıcı dosyalar çoğaltılmış kontrol dosyaları ve redolog üyeleridir. Geçici dosyalar içinde, archivelog'lar, flashback log'ları, kontrol dosyası otomatik yedekleri, datafile kopyaları (datafile image copies) ve RMAN dosyaları bulunmaktadır.
FRA'yı Enterprise Manager üzerinden de tanımlayabilirsiniz veya 2 parametreyi ayarlayarak da işleme alabilirsiniz. Bunlar, DB_RECOVERY_FILE_DEST_SIZE ve DB_RECOVERY_FILE_DEST parametreleridir. FRA için tanımladığınız dizin ve bir boyut ile Oracle ne yapması gerektiğini bilecektir. Örneğin tanımladığınız boyut 100GB ise ve içerideki dosyaların boyutları toplamı 85GB olmuş ise bir metric aracılığı ile size uyarı gelecek ve FRA'nın üzerinde baskı oluşmaya başlayacaktır. Aynı şekilde devam ederse ve %97 olursa da bu bir kritik eşik seviyesidir ve Oracle silebileceği ve yukarıda belirttiğim geçici tipte olan dosyalara bakacaktır. Oracle durumun kritik olduğunu gördüğü zaman alert.log dosyasına durumu açıklayan bir yazı basacak ve OBSOLETE olan yedeklerden silmeye başlayacaktır. Sildiği her yedek için alert.log dosyasına bir bilgi mesajı da basacaktır. %85'lik ve %97'lik eşik değerlerini FRA için değiştirmek mümkün değildir. Hatalarla ilgili bilgiye ise DBA_OUTSTANDING_ALERTS data dictionary görüntüsünden bakabilirsiniz. Bu durumda yeni bir disk eklemek, FRA içinde bulunan dosyaların yedeğini almak, RMAN aracılığı ile silmek veya RMAN koruma tipini değiştirmek sorunu çözebilir.
FRA'daki alanın boşaltılması için archivelog'ların yedeğini başka bir lokasyona alabilirsiniz ve sonrasında da silebilirsiniz;
RMAN> backup archivelog all delete all input;
veya
RMAN> backup database plus archivelog delete all input;
Bununla birlikte archivelog'ların silinmesi için bir şart da RMAN'e tanımlayabilirsiniz. Burada önemli bir noktaya değinmek isterim. 10g ile 11g arasında bu parametre ile ilgili ciddi bir çalışma yerine getirildi ve 11gR1'de değiştirildi;
10g:
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO [NONE | APPLIED ON STANDBY];
11g
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO [NONE | APPLIED ON STANDBY];
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY [CLEAR | TO APPLIED ON ALL STANDBY | BACKED UP integer TIMES TO DEVICE TYPE DISK <> SBT | NONE | SHIPPED TO ALL STANDBY]
CROSSCHECK ve DELETE RMAN komutları ile de FRA için daha fazla yer tahsisi gerçekleştirilebilir. Oracle şiddetle FRA kullanmamızı tavsiye etmektedir.
Recovery Catalog
RMAN'in beyni, bütün yedeklerinin bilgisi, kısacası meta verisi kontrol dosyasında tutulmaktadır. Buna ek ve opsiyonel olarak aynı bilgilerin bir katalog veritabanında tutulması da sağlanabilir. Sadece katalog veritabanında tutmak gibi bir durum söz konusu değildir, her zaman kontrol dosyası içerisinde bu bilgiler bulundurulur.
Kurtarma kataloğunun en büyük avantajı ilgili veritabanında bir kontrol dosyası kaybı olduğu zaman kullanılabilmesidir. Kontrol dosyası gittiğine göre artık yedekleri bilen obje de ortadan kaybolacağı için kurtarma kataloğuna danışılabilir. Kurtarma kataloğu ayrıca RMAN script'lerini de tutabilmektedir. Bir diğer avantajı ise çok daha uzun ve geçmişe ait yedek bilgilerini kontrol dosyasında tutamazsınız ama kurtarma kataloğu tutabilir. KEEP FOREVER ile kayıt altına aldığınız bir yedeğin bilgisi de her zaman katalog veritabanında tutulacaktır. Çok kısıtlı bir veritabanınız varsa ve bir veya iki tane veritabanını yönetiyorsanız Oracle kontrol dosyasını kullanmanızı yine de tavsiye etmektedir. Çok fazla veritabanının olduğu bir alanda yönetim yapıyorsanız ve her şey çok fazla kritik ise Oracle kurtarma katalog veritabanı kullanmanızı tavsiye etmektedir.
RMAN tarafından saklanmış script'leri kullanmak istiyorsanız, saklamak ve kullanmak için de kurtarma kataloğu kullanmak zorundasınız. Katalog ile ilgili bilgilere ise RC_ ile başlayan görüntülerden bulabilirsiniz. Eğer bir kurtarma kataloğunuz yoksa ve kontrol dosyasını yedek bilgilerini saklamak için kullanıyorsanız her bir veritabanına gidip V$ görüntülerini incelemeniz gerekmektedir.
Recovery Catalog Kullanıcısının ve Tablespace'inin Yaratılması
1) Kurtarma kataloğunu tanımlayacağınız veritabanını ayarlayınız.
2) Kurtarma kataloğu sahibini yaratınız.
3) Kurtarma kataloğunu yaratınız.
İlk önce bir veritabanı seçmelisiniz ve bu yedeklerini alacağınız veritabanı veya veritabanlarından farklı bir veritabanı olmalıdır (doğal olarak). Ardından bir tablespace yaratmanız gerekmektedir;
SQL> create tablespace rman_repository datafile '/home/oracle/rman_repo01.dbf' size 20M;
SQL> create user bckuser identified by password;
SQL> grant recovery_catalog_owner to bckuser;
SQL> alter user bckuser default tablespace rman_repository;
SQL> alter user bckuser quota unlimited on rman_repository;
Yukarıdaki tanımlamaları katalog veritabanında yaptıktan sonra artık kataloğumuza bağlanabilir ve katalog tablolarımızı ilgili tablespace'de yaratabiliriz.
# rman catalog
RMAN> create catalog;
Bu kataloğumuza istediğimiz veritabanlarını tanıtarak (register) yolumuza devam edebiliriz. Bir veritabanı tanımlamadığımız zaman kurtarma kataloğu ile hedef veritabanının kontrol dosyası arasında bir bağ bulunmayacaktır. Burada nedense aklıma Avatar filmindeki bağ kurma işlemi geldi :) Teorik olarak o şekilde bir işlem gibi düşünebiliriz.
# rman target
RMAN> register database;
Enterprise Manager aracılığı ile register edilmiş bir veritabanını ancak yine EM kullanarak unregister edebilirsiniz, unutmayınız.
RMAN> unregister database;
Bu komut ile hedef veritabanına ait bütün meta bilgileri kurtarma kataloğunun tablolarından silinecektir. Şimdi, diyelim daha önceden bir yedek aldınız ve bu yedeğin bilgisi kontrol dosyasında bulunmakta. Sonradan bir kurtarma kataloğu yarattınız ve bu yedek bilgilerini de kataloğa işlemek istiyorsunuz. Bu durumda CATALOG komutunu kullanabilir ve aşağıdaki tipte dosyalar için geçerlidir.
RMAN> CATALOG CONTROLFILECOPY
RMAN> CATALOG DATAFILECOPY
RMAN> CATALOG ARCHIVELOG
RMAN> CATALOG BACKUPPIECE
Bütün FRA içerisindeki dosyaları kataloglamak isterseniz;
RMAN> CATALOG RECOVERY AREA NOPROMPT;
Bu komutun dışında CATALOG START WITH ile de bir dizin altındaki belirli tipte dosyaları kataloglayabilirsiniz.
RMAN> CATALOG START WITH '/home/oracle/arch';
RMAN> CATALOG START WITH '/home/oracle/';
Yukarıdaki iki komut arasında bir fark bulunmaktadır. Üstteki /home/oracle dizini altında yer alan bütün arch ile başlayan dosyaları, alttaki komut ise /home/oracle dizini altındaki bütün dosyaları kataloglayacaktır.
Kurtarma kataloğu bir yeniden senkronizasyon yapmaktadır ve hedef veritabanı ile katalogdaki bilgileri kıyaslamaktadır. İki tip senkronizasyon bulunmaktadır, yarım ve tam senkronizasyon. Kısmi senkronizasyonda bir karşılaştırma yapılır ve bir meta değişikliği varsa bu güncelleme yerine getirilir. Tam senkronizasyonda da RMAN ilk olarak bir snapshot (tam Türkçe karşılığı enstantane, gerçi pek Türkçe değil ama) kontrol dosyası yaratır. Bu, yalnızca kontrol dosyasının geçici bir kopyasıdır. Kısmi senkronizasyonun yaptığına ek olarak veritabanındaki yapısal değişiklikleri de günceller. Bir örnek olarak şema değişiklikleri ve yeni tablespace yaratma durumları gösterilebilir. Bunlar yapısal değişikliklerdir ve kontrol dosyası direkt olarak güncellenir. Peki kısmi ve tam senkronizasyon ne zaman gerçekleşir?
Kısmi: CONTROL_FILE_RECORD_KEEP_TIME parametresi ile değişen meta bilgileri sırasında kısmi senkronizasyon gerçekleşir.
Tam: RESYNC CATALOG komutu ile tamamlanır.
RMAN> RESYNC CATALOG;
Saklanmış RMAN Script'leri
Lokal ve global olmak üzere iki tip script bulunmaktadır. Script'ler kısaca RMAN komutlar topluluğudur ve sonraki kullanımlar için saklanabilir.
RMAN> create script { RMAN komutları };
RMAN> create global script { RMAN komutları };
RMAN> create global script { RMAN komutları } from file 'dosya adı';
Bu script'leri çalıştırmak içinse;
RMAN> RUN { execute script ; }
RMAN> RUN { execute global script ; }
Script'leri görüntülemek, içeriğini görmek, silmek ve değiştirmek için;
RMAN> print [global] script ;
RMAN> print [global] script to file 'dosya adı';
print içerikleri gösterir ve list yalnızca isimleri gösterir.
RMAN> list [global] script names;
RMAN> replace [global] script { RMAN komutları };
RMAN> replace [global] script from file 'dosya adı';
Bir script'i silmek için;
RMAN> delete [global] script ;
Recovery Catalog Yedeklenmesi
Bir veritabanının kontrol dosyalarını nasıl korumakta isek elimizdeki kurtarma kataloğunu da korumamız ve yedeğini almamız gerekmektedir. En klasik yöntem olarak export'unu alabiliriz veya disk'e ya da kaset ünitesine kaydedebiliriz. Kurtarma kataloğunu aynı veritabanında bulundurmak veya yedeğini, diğer veritabanı yedekleri ile aynı lokasyonda saklamak pek mantıklı olmadığından Oracle da tavsiye etmemektedir. Kurtarma kataloğu için tavsiye edilen bir başka yöntem ise otomatik alınan kontrol dosyası yedeğinin açık olması;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Varsayılan olarak OFF yani kapalı olarak ayarlanan bu parametrenin ON yani açık olması, veritabanında yapısal bir değişiklik olduğu zaman kısmi senkronizasyon gerçekleştirmekte ve bunu her yapısal değişiklikte yapmaktadır (tablespace'e datafile eklemek gibi).
Katalog'un sürümünü yükseltmek ya da düşürmek veya import etmek için;
RMAN> UPGRADE CATALOG;
RMAN> DROP CATALOG;
RMAN> IMPORT CATALOG [DBID=A1,A2,A3]
Kurtarma kataloğu, Recovery Catalog ile ilgili olarak bunları bahsettikten sonra yedekleme konfigürasyonları ve yedekleme operasyonları ile devam edebiliriz.
RMAN Konfigürasyonları, Değiştirmek ve Görüntülemek
RMAN'in kayıtlı konfigürasyon ayarlarını görüntüleyebilmek için SHOW ALL komutunu çalıştırabilirsiniz veya V$RMAN_CONFIGURATION dinamik performans görüntüsünü sorgulayabiliriz.
Kontrol Dosyası Otomatik Yedekleme
Kontrol dosyasının otomatik olarak yedeklenmesinin bize sağlayacağı avantaj yalnızca kurtarma kataloğunun güncellenmesi için değil, aynı zamanda olası bir kontrol dosyası kaybının da rahatlıkla tolare edilebilmesini sağlamasıdır.
RMAN> CONFIGURE CONTROLFILE AUTOBA
