29 Ocak 2011 Cumartesi

DEFERRED_SEGMENT_CREATION

Merhaba,

Oracle veritabanı 11gR2 versiyonu ile aramıza katılan DEFERRED_SEGMENT_CREATION parametresinin bana göre oldukça önemli bir görevi bulunmakta. Kurulumda varsayılan olarak "TRUE" yani açık olarak gelen bu parametrenin amacı bir tablespace üzerinde yaratılacak segment'lerin, ilk insert operasyonu geldiği zaman yaratılmasını sağlar. CREATE TABLE komutu ile yaratılması beklenen tablo segment'i, bu parametre TRUE iken yaratılmaz. Yalnızca tablo yaratılır ve bilgisi data dictionary'e yazılır. CREATE TABLE hakkı olan kişiler bir başka tablespace üzerinde tablo yaratabilir ancak kotası olmadan bir giriş yapmak isterse ilk segment tahsisi sırasında size hata verecektir. 11gR2'den önce -ki buna 11gR1'de dahil- CREATE TABLE veya CREATE INDEX komutlarını gönderdiğiniz zaman yaratılacak tablo veya indeks segmentleri anında tahsis edilir ve yaratılırdı.


Bu parametrenin amacı disk alanından daha fazla kazanmaktır. Dilediğiniz zaman FALSE'a getirerek eskisi gibi davranılmasını sağlayabilirsiniz.


Dikkat etmeniz gereken bir başka konu ise export sırasında ortaya çıkıyor. Tabloyu yalnızca yaratıp bırakırsanız, EXP komutu ile tablonun yedeğini almak istediğiniz zaman bulamayacaktır. 


İyi çalışmalar.


Ogan

26 Ocak 2011 Çarşamba

Oracle Recovery Manager (RMAN) - Recovery Catalog Database

ORACLE RECOVERY MANAGER (RMAN)

Recovery Manager (RMAN) ile ilgili olarak daha önce bir yazı yazmıştım. Burada biraz daha detaylı olarak RMAN kullanımını göstermeye çalışacağım. Bunun yanında recovery catalog nedir ve hangi durumlarda kullanır gibi konuları da inceleyeceğiz. 

Konuyu dağıtmadan ve örnekleri ile anlatmaya çalışacağım.

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 sys/password@orcl

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 bckuser/password@orcl_cat
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 sys/password@orcl catalog bckuser/password@orcl_cat

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 catalog/password@cat_db [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 AUTOBACKUP ON;

Bu komut ile yalnızca kontrol dosyasının değil, spfile'ın da yedeği alınmaktadır. Peki ne zaman bu parametre devreye girer?

1) RUN script'inin sonunda.
2) RMAN repository'sine başarılı bir yedek kayıt edildiği zaman.
3) DDL operasyonlarından sonra.

Bu kontrol dosyasının yerini ve formatını da belirleyebiliriz;

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/home/oracle/control_auto_%F';

Kontrol dosyasının otomatik yedeklenmiş dosyaları aksi ifade edilmediği sürece Fast Recovery Area'da tutulacaktır. 

Bir yedeğin paralel olarak alınmasını sağlayabilirsiniz. Örnek olarak bir media manager düşünün ve bunun da 3 tane kaset ünitesi olduğunu. Paralellik derecesini 3 olarak belirlersek 3 tane kanal açılacak ve farklı kollardan yazma işlemi yapılabilecek. Tek bir dizine veya kaset ünitesine yedekleme yapılırken birden fazla paralellik anlamsız olacaktır. Varsayılan olarak 1 gelmektedir. 

RMAN> CONFIGURE DEVICE TYPE PARALLELISM ;

Buradaki rakam paralellik derecesini sembolize etmektedir. CLEAR komutu ile varsayılan ayarlara geri dönülebilir.

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP CLEAR;

Media Manager Kullanımı

Kaset ünitesine yedek almak için Oracle Secure Backup veya MML(media management library) kullanmak gerekmektedir. Amacı veritabanını yedekleme, restore etme ya da kurtarma işlemini yerine getirmektir. Disk üzerinde bir alanı yedekleme yaparken MML library'sini çağırmaya gerek yoktur. MML kullanmadan kaset ünitesine yedek alamazsınız. Dolayısıyla media manager'ı önce kurmak ve ardından RMAN ile konuşturmak gerekmektedir. Aşağıdaki aşamalardan geçebiliriz;

1) Hedef makineye media manager'ın yazılımını kurmalıyız. Herhangi bir RMAN entegrasyonu bu noktada gerekmemektedir.
2) Media Manager'ın dokümantasyonunu inceleyerek RMAN entegrasyonunun nasıl yapılabileceğini inceleyiniz.
3) Üçüncü parti media management modülünün entegrasyonunu yapınız. Bu modülde gerekli library'ler bulunmaktadır ve Oracle veritabanı ile konuşulmasını sağlar.

Media Manager Kullanımı ile Yedekleme ve Restorasyon

RMAN> RUN { ALLOCATE CHANNEL chan1 DEVICE TYPE sbt; BACKUP TABLESPACE "TEST"; }

Bu komut ile Oracle veritabanına kaset ünitesine bir yedek almak istediğimiz bilgisini ve bir kanal tahsisi talebinde bulunduğumuzu ilettik. Oracle ise media management cihazına istekte bulunarak gerekenin yapılmasını talep eder. Media manager'ın özelliği bünyesinde bulunan kaset ünitelerinde neler bulunduğu bilgisine sahip olmasıdır. Bu sayede restorasyon işlemlerinde Oracle'a yardımcı olmaktadır;

1) Oracle veritabanı gerekli dosyanın restorasyonu için talepte bulunur.
2) Media Manager hangi dosyanın istendiğini görür ve bunun hangi kaset ünitesinde olduğunu tanımlar.
3) Media Manager bu bilgiyi Oracle veritabanına iletir. 
4) Oracle veritabanı ilgili dosyayı diske yazmaya başlar ve restorasyon da başlamış olur.

Yedekleme Lokasyonu Belirlemek

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO TAPE;

Disk veya kaset ünitesine yazılmasını bir özel olarak belirtmezsek, bu komut nereye yazması gerektiğini bilecektir. Bir not, RUN bloğu içerisinde olan bütün tanımlamalar o blok için geçerlidir ve varsayılan cihaz olarak disk tanımlamış olsak ve run bloğu içerisinde TAPE'e yedek alacağız ve kanal tahsis edeceğiz dersek RMAN onu dinler. Bununla birlikte FORMAT ifadesini kullanarak sabit bir yedek ismi de belirleyebiliriz.

Kanal Tahsisi ve Konfigürasyonları

RMAN> CONFIGURE DEVICE TYPE sbt;
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt;

Bu komutların amacı aslında aynı. Kaset ünitesine yedeklemenin yapılmasını talep etmekteyiz ve kanal tahsisinin nasıl ve nereden olacağını göstermekteyiz. RUN bloğu içerisinde de kanal açabiliriz;

RMAN> RUN { ALLOCATE CHANNEL chan2 DEVICE TYPE DISK; BACKUP DATABASE PLUS ARCHIVELOG; }

Yukarıdaki komutları arka arkaya girdiğimizi düşünürsek ilk olarak tanımladığımız kaset ünitesi tahsis konfigürasyonları RUN bloğu için devre dışı kaldı ama tabii ki bir defaya mahsus.

RMAN arka arkaya 4 tane yedek kopyası oluşturabilir. Yedekleme sırasında oluşan yedek dosyalarının bazen başka lokasyonlara da kopyalanmasını isteyebilirsiniz. Alınan ve üretilen her kopyanın kendine özel benzersiz bir ismi bulunmaktadır. Bunu ya yedek alırken ya da CONFIGURE komutu ile yapabiliriz.

RMAN> BACKUP ... COPIES ;
RMAN> CONFIGURE ... BACKUP COPIES;

Bu arada kopyalama veya çoğaltma işlemi yalnızca backup set'ler için yapılabilmektedir. İmaj kopyaları için geçerli değildir. Bu durum genelde kaset ünitelerine alınan yedekler için geçerli olabilir. Bir örnek ile devam etmem gerekirse;

RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
RMAN> CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
RMAN> BACKUP DEVICE TYPE DISK AS COPY DATABASE;

Burada dikkat edilmesi gereken durum, ilk yedekleme komutu ile kaset ünitesi üzerinde 2 tane backup set kopyası oluşturuluyor. Kaset ünitesinde olmasının nedeni ise önceden tanımladığımız iki tane CONFIGURE komutu. İkinci yedekleme komutunda ise disk üzerine veritabanının bir imaj kopyası oluşturuluyor ancak tek bir yedek dosyası ile ve COPIES ifadesinden etkilenmiyor. Bu operasyondan sonra aşağıdaki komut ile aldığınız yedekleri görebilirsiniz;

RMAN> LIST BACKUP;
RMAN> LIST COPY;

Yedekleme Optimizasyonu (Backup Optimization)

Yedekleme optimizasyonu aşağıdaki komut ile aktive edilir çünkü varsayılan olarak OFF tanımlanır.

RMAN> CONFIGURE BACKUP OPTIMIZATION ON;

Yedekleme optimizasyonu sayesinde daha önceden yedeği alınmış ve sonraki yedekte bir değişikliğe uğramamış olan objeler dışarıda kalır.

RMAN> BACKUP DEVICE TYPE DISK BACKUPSET ALL FORCE;

FORCE komutu ile optimizasyon devre dışı kalır ve RMAN BACKUP OPTIMIZATION ON veya OFF olmasına bakmadan OFF gibi davranır. Eğer RMAN bir dosyanın daha önceki yedeği ile birebir aynı olduğunu fark ederse bu dosya geçilebilir. Geçilir diyemiyorum çünkü bu ikisinin aynı olduğu ilk etapta fark edilirse başka bir algoritma devreye girer ve RMAN'in koruma şartı (retention policy) ve yedek çoğaltma parametreleri de kontrol edilir. Bu durumda elde yeterli yedek olduğu ve bu dosyanın geçilebileceğine karar verilirse dosya yedeğin içerisine dahil edilmez.

Kullanılmayan Blok Sıkıştırması

RMAN belirli tipte blokları gözardı ederek yedeklemesine devam edebilir. Yani HWM üzerinde kalan bloklardan bahsediyoruz. Bu şekilde Oracle yedekleme dosyaları için yerden tasarruf etmiş olacaktır. RMAN ayrıca bir sıkıştırma algoritması uygulayabilir ve bu özellik 11g ile birlikte gelmiştir. Tanımlama yapabilmek aşağıdaki komutu koşabiliriz;

RMAN> CONFIGURE COMPRESSION ALGORITHM 'HIGH/MEDIUM/LOW/BASIC';

veya

RMAN> RUN { SET COMPRESSION ALGORITHM 'HIGH/MEDIUM/LOW/BASIC'; }

Commit edilmiş veriye ait undo verisi yedek için gerekmemektedir ve yedekleme dışında tutulur. Bunun sebebi transaction'ın kurtarılması için artık bir neden yoktur çünkü kullanıcı commit etmiştir. Bu optimizasyon RMAN tarafından otomatik olarak yapılmaktadır. Binary sıkıştırma ile yedeği alınacak verinin belirli boyutlarda sıkıştırma yapılabilir. Sıkıştırılmış bir yedeğin restorasyonunu yapabilmek için hiçbir ek komuta ihtiyaç duyulmamaktadır. Tabii sıkıştırma algoritmasının derecesine göre CPU tüketimi artabilir. CPU'dan kazanırken yerden fedakarlık etmek veya CPU'yu daha fazla kullanarak yerden kazanmak mümkün olabilmektedir. Söylediğim gibi bu komut 10g'de bulunmamaktadır. 

Yedeklerin Şifrelenmesi

İki tip şifreleme bulunmaktadır. "Wallet" kullanımı -ki owm ile kontrol altında tutulmaktadır- kullanılabilir veya normal bir parola atanarak da koruma yapılabilir. Ayrıca ikisi birlikte de kullanılabilir. Oluşturduğumuz wallet dosyasını sistem üzerinde tutmak mantıklı olmadığından bir başka lokasyonda saklayabilir ve gerekli olduğu zaman kayıt altına alınan lokasyona tekrar kopyalanabilir.

RMAN ile Yedeklerin Alınması

Recovery Manager için 3 tip yedek bulunmaktadır. 

1) Backup set (yedek seti)
2) Compressed Backup set (sıkıştırılmış yedek seti)
3) Image Copy (imaj kopyası)

RMAN> BACKUP AS BACKUPSET FORMAT '/home/oracle/full_db.dbf' TABLESPACE "TEST";

Backup set'ler ise backup piece'lerden (parça) oluşmaktadır. Bu parçalar bir veya birden çok veritabanı dosyasından oluşabilir.

RMAN> BACKUP AS COPY DATAFILE '/home/oracle/test01.dbf';

Bir imaj kopyası verdiğimiz dosyasının birebir aynısıdır (bit-by-bit). Daha önce bahsettiğim sıkıştırma algoritmaları veya kullanılmayan blok sıkıştırması algoritması kullanılmaz ve direkt olarak bir imaj oluşturulur. Bir imaj kopyası yalnızca disk üzerine alınabilir, kaset ünitesine imaj kopyası alınamaz. İmaj kopyasının müthiş bir özelliği bulunmaktadır ve SWITCH komutu kullanılarak yapılabilir. SWITCH komutu veritabanının ALTER DATABASE RENAME FILE komutuna eşdeğerdir. Bir imaj kopyası bir objenin birebir aynısı olduğuna göre veritabanındaki bir datafile ile bu kopyanın yerini değiştirmek, neden olmasın? Yalnız bunu yaparken yine de RECOVER komutunu kullanmalıyız çünkü imaj kopyasını aldığımız yedek ile SWITCH komutu arasında transaction'lar vardı ve bunların ilgili datafile'a işlenmesi gerekmektedir aksi halde bu datafile online konumuna getirilemez (datafile blok başlığındaki SCN ile kontrol dosyasındaki SCN tutmaz). Bu noktadayken bir örnek göstermek istiyorum.

RMAN> sql 'alter database datafile '/home/oracle/test01.dbf' offline immediate';
RMAN> SWITCH datafile '/home/oracle/test01.dbf' TO COPY;
RMAN> recover datafile '/home/oracle/test01.dbf';
RMAN> sql 'alter database datafile '/home/oracle/test01.dbf' online;

Bir diğer örnek ise bu şekilde tek tek uğraşmak yerine yapılabilecek bir durum;

RMAN> RUN { 
ALLOCATE CHANNEL chan1 DEVICE TYPE TO DISK;
SQL 'ALTER TABLESPACE "TEST" OFFLINE IMMEDIATE';
SET NEWNAME FOR DATAFILE '/home/oracle/test01.dbf' TO '/home/oracle/test02.dbf';
RESTORE TABLESPACE "TEST";
SWITCH DATAFILE ALL;
RECOVER TABLESPACE "TEST";
SQL 'ALTER TABLESPACE "TEST" ONLINE';
}

Bütün veritabanının da yedeğini alabiliyoruz. Bu yedeğin adına "whole database backup" denmektedir;

RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
RMAN> BACKUP COPY OF DATABASE;

RMAN Yedekleme Tipleri

Daha önce de bahsettiğim gibi 3 tip RMAN yedekleme tipleri bulunmaktadır. Tam, artımlı sıfırıncı seviye ve artımlı birinci seviye. Oracle RMAN sıfırıncı ve birinci seviyeyi kabul etmektedir ve buna artımlı yedekleme (incremental backup) denmektedir. Birkaç örnek göstermem gerekirse;

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

"Cumulative" yazmadığımız zaman her artımlı birinci seviye veritabanı "differential"dır yani bir önceki birinci seviye ile arasındaki değişiklikler yedeklenir. Kümülatifte ise en son sıfırıncı seviye tam yedek ile arasındaki bütün farklar yedeklenir. Artımlı seviye sıfır veritabanı yedeği tam veritabanı yedeğine eşittir ve bu strateji için kullanılmaktadır. Bir dip not, noarchivelog modunda olan bir veritabanının da tam ya da artımlı yedeği alınabilir ama veritabanının kapalı olması gerekmektedir (STARTUP MOUNT seviyesi). Tekrar hatırlatmam gerekirse bir veritabanını ancak ARCHIVELOG modda iken son commit işlemine kadar getirebilmek mümkündür. 

Hızlı Artımlı Yedekleme Stratejisi (Block Change Tracking)

Belki de birçok insanın (artımlı yedekleme stratejisi ile çalışan) oldukça iyi bildiği "block change tracking" özelliği ile ilgili konuşmak istiyorum. Bu bir log dosyasıdır ve en son yedekten bu yana hangi bloğun değiştiği bilgisini tutar. Peki neden tutmak isteyebiliriz? Normal artımlı yedeklemelerde veritabanı bütün blokları tek tek inceler ve neyin artımlı yedek içerisinde bulunması gerektiğine karar verir. Halbuki bu log dosyasına bakarak, bu bilgiye inanılmaz hızlı bir şekilde ulaşabilir. Bu durumda yalnızca artımlı yedekleme stratejisi için mantıklı olacaktır ama devreye almak için artımlı yedek almamıza gerek yoktur. Tanımlamayı yaptığımız zaman CTWR arka plan işlemi bu yazma görevini üstlenmektedir (Change Tracking WRiter). Redo oluştuğu zaman yazma işlemi devam eder ve transaction'ların neden olduğu blok değişikliklerinin adresleri saklanır. 

Bu özelliği devreye alabilmek için Enterprise Manager kullanılabilir veya komutla da devreye alınabilir. 

SQL> ALTER DATABASE { ENABLE | DISABLE } BLOCK CHANGE TRACKING USING FILE '/home/oracle/bctracking.log';

Bu durumu takip edebilmek için birkaç dinamik performans görüntüsü bulunmaktadır ve bunlar V$BLOCK_CHANGE_TRACKING ve V$BACKUP_DATAFILE olabilir. 

SQL> SELECT filename, status, bytes
2 FROM v$block_change_tracking;

SQL> SELECT file#, avg(datafile_blocks), avg(blocks_read), avg(blocks_read/datafile_blocks) * 100 "Yedekleme Yüzdesi", avg(blocks)
2 FROM v$backup_datafile
3 WHERE used_change_tracking = 'YES'
4 AND incremental_level > 0
5 GROUP BY file#;

Read-Only Tablespace'lerin Yedeklenmesi

Yedekleme optimizasyonun ON olduğu durumlarda normalde yedeği alınmayacak olan read-only tablespace'in yedeği alınabilir. Eğer bu tipte bir tablespace'i read/write (okuma/yazma) konumuna alırsanız hemen yedeğini alın. SKIP READONLY komutunu BACKUP komutu içerisinde kullanarak RMAN'in read-only tablespace'leri yedek dışarısında tutmasını sağlayabilirsiniz. 

RMAN'de SECTION SIZE isminde bir parametre bulunmaktadır. Bu, paralel olarak yazma yapılırken ayrılabilecek parçaların boyutlarını göstermekte veya veriyi kümeleyerek yedeklenmesini sağlamakta kullanılabilir. Örnek;

RMAN> BACKUP DATABASE SECTION SIZE = 10G TAG = '10gbsectionsize';

Bu yedekleme sırasında her 10g'lik blok adetlerinin sırasıyla parçalanarak yedeklendiği bilgisini de görebilirsiniz.

Yedeklerin Yönetilmesi ve Listelenmesi

LIST, REPORT, REPORT NEED BACKUP, REPORT OBSOLETE gibi komutlar kullanılarak alınmış yedeklerin veya yedeğinin alınmasına ihtiyaç duyulan yedeklerin neler olduğunu görebilirsiniz.

RMAN> LIST BACKUPSET 5;
RMAN> REPORT OBSOLETE;

"REPORT NEED BACKUP" komutu öncelikle "retention policy"yi kontrol eder ve örneğin redundancy 2 olarak tanımlamışsak ve elimizdeki objenin bir yedeği, yedek setlerinde 1 tane bulunmuş ise yedeklenmesi gerektiğine karar verilir ve bu datafile bilgi olarak gösterilir. Dinamik olarak redundancy'yi 1'e çekersek ve REPORT NEED BACKUP dersek artık bu datafile'ı çıktılarda görmeyiz.

"REPORT OBSOLETE" ise retention policy menzilinde kalan yedekleri gösterir. Bunlar kullanılamaz diye bir şey yok ancak FRA tarafından ilk olarak silinecekler listesine girmiştir. Kullanılabilecek dinamik performans görüntüleri ise;

V$BACKUP_SET
V$BACKUP_PIECE
V$DATAFILE_COPY
V$BACKUP_FILES

Yedeklerimizi silmek istersek ne yapmalıyız? Sistem üzerinden gidip elle silersek ne olur, RMAN ile silersek ne değişir? Bir defa böyle bir durumda eğer çok ekstrem bir durum oluşur ve elle silmemiz gerekirse, RMAN bunun farkına varamaz. Varmak içinse otomatik olarak bir çabada bulunmaz. Bunu, ona bizim söylememiz gerekmektedir.

RMAN> CROSSCHECK ARCHIVELOG ALL;

Yukarıdaki komut ile RMAN'in, bütün archivelog'ların varlığını kontrol etmesini istemekteyiz. Eğer elle silinmiş bir archivelog varsa RMAN bunu "EXPIRED" olarak, retention policy tarafından süresi geçmiş bir archivelog varsa da bunu "OBSOLETE" olarak işaretler.

RMAN> DELETE EXPIRED;
RMAN> DELETE OBSOLETE;

Yedekleme ve yedeklerin kontrol edilmesi ve konfigürasyonun yapılması ile ilgili konuştuk. Şimdi ise sırada restorasyon ve kurtarma işlemleri var.

RMAN Restorasyonu ve Kurtarması (Restore & Recover)

Öncelikle restorasyon nedir, kurtarma nedir bunu açıklamak isterim. Restorasyon, alınan yedek içerisinden fiziksel dosyaların, ilgili lokasyon üzerinde yeniden oluşturulmasıdır. Kurtarma ise oluşturulan bu datafile'ların, online redolog'lar ve archivelog'lar aracılığı ile en son commit veya istediğimiz SCN ya da zamana kadar ilerletilmesi işlemidir.

Bir de hangi durumun kritik hangi durumun kritik olmayan olduğunu açıklamam gerekiyor. Kritik hatalar veritabanının işleyişini durduran hatalardır. Örneğin SYSTEM veya UNDO tablespace'ine ait bir datafile'ın uçması gibi. Kritik olmayan ve veritabanını durdurma noktasına gelmeyen hata ise herhangi bir tablespace'e ait datafile'ın yok olması, spfile'ın kaybolması veya password file'ın bozulması gibi.

Evet, TEMP tablespace ile ilgili bahsetmemiş olduğumun farkına vardım. Öncelikle TEMP tablespace'inin en az kritik olan tablespace'lerden olduğunu ve yedekleme operasyonuna dahil edilmediğini ifade edebilirim. Hatırlayalım, bir sorgunun order by, group by yapılabilmesi için önce PGA, PGA alanı yetmez ise TEMP tablespace'sini kullanıyorduk. Peki, temp tablespace'ine ait bir datafile'ı ben bilerek silersem ne olur?

RMAN> SELECT * from hr.employees
2 ORDER BY 1,2,3,4,5,6 ASC,7 DESC;

ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory

Oracle instance'ı TEMPFILE olmadan da yoluna devam eder ve gönderdiğiniz STARTUP komutu başarısız olmaz. Hatta TEMPFILE'ı otomatik olarak yeniden yaratmaya çalışır ve aşağıdaki bilgiyi verir;

"Re-creating tempfile /home/oracle/temp01.dbf"

Kendiniz de bozulmuş ya da yok olmuş datafile'ı yaratabilirsiniz;

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/home/oracle/temp02.dbf' SIZE 100M;
SQL> ALTER TABLESPACE TEMP DROP TEMPFILE '/home/oracle/temp01.dbf';

Online Redolog Grup Statüsü

Bana göre bilinmesi gereken en kritik noktalardan birisi online redolog'ların grup statüleridir. Sebebi ise Oracle redolog grubunun tamamının gitmesi durumunu karşılaşabileceğiniz en ciddi media başarısızlığı olarak görmesidir. İşte bu noktada devreye online redolog'ların statülerinin önemi devreye girmektedir. Bir redo sırası ile önce;

1) CURRENT
2) ACTIVE
3) INACTIVE 

olabilir. 

CURRENT: Bu statüye sahip online redo'lara LGWR tarafından yazma işlemi devam etmektedir ve geçerli redolog grubudur. Veritabanındaki güncel bütün transaction'lar bu gruba yazılmaktadır ve ARCn henüz bu grubu oluşturmaya başlamamıştır. Eğer bu gruba bir şey olursa, geçmişler olsun veri kaybınız kaçınılmazdır.
ACTIVE: İlgili redolog grubu hala instance recovery için gerekli redo bilgisi içermektedir. Aktif olarak anılmasının nedeni checkpoint henüz redolog'ların içerisindeki veri değişikliklerini fiziksel datafile'lara yazdırmamıştır. LGWR, DBWn'e göre çok daha hızlı bir görevdir.
INACTIVE:. CKPT görevini tamamlamıştır ve ilgili redolog grubu artık instance recovery için gerekmemektedir. Bu redolog grubu artık CURRENT statüsüne gelmek için hazırdır. 

Eğer inactive durumda olan bir redolog grubunu tamamen kaybederseniz, panik yapmayın ve media başarısızlığını düzeltmeye çalışın. Eğer media hatası düzeltilemiyorsa ilgili redolog grubunu temizleyin (clear logfile). 

Eğer active durumda olan bir redolog grubunu tamamen kaybederseniz, panik yapmaya başlayın ve bir checkpoint gönderin. CKPT düzgün çalışır ve bu redolog grubu bir şekilde inactive konumuna gelirse yukarıdaki işlemi uygulayabilirsiniz. CKPT düzgün çalışmaz ise cancel-based PITR yapmanız gerekecektir. 

Eğer current durumda olan bir redolog grubunu tamamen kaybederseniz LGWR instance'ı sonlandıracaktır. Bu durumda yine cancel-based PITR yapmak zorundasınız ve veritabanını RESETLOGS opsiyonu ile açmalısınız.

Bir redolog dosyasını temizlemek için;

SQL> ALTER DATABASE CLEAR [UNARCHIVED] LOGFILE GROUP [UNRECOVERABLE DATAFILE];

Peki gelelim bir indeks içeren tablespace'i kaybettiğiniz duruma. Hiç restore ile uğraşmamanızı tavsiye ederim çünkü indeks'ler restore etseniz de rebuild olacak ve yeniden yaratılacaktır. Bunun yerine ilgili tablespace'i düşürerek, yeniden yaratabilir ve indeks'lerin mantıksal bloklarının yeniden düzenlenmesini sağlayabilirsiniz.

SQL> CREATE INDEX ogan_indeks
2 ON hr.employees (employee_id)
3 PARALLEL 2;

Paralel komutu ile iki koldan işin ilerlemesini istediğimizi Oracle sunucusuna ilettik. 

Password file giderse ne yapabiliriz? Veritabanı kesinlikle kapanmaz zira password file uzaktan bağlanan SYSDBA'lerin kontrol edilmesi ve yeni bir SYSDBA yaratılacağı zaman ilgili kullanıcının kaydedilmesi için gerekir.

# rm orapworcl.ora
# sqlplus / as sysdba
SQL> GRANT SYSDBA TO ogan;
grant sysdba to ogan
*
ERROR at line 1:
ORA-01994: GRANT failed: password file missing or disabled

ORAPWD aracını kullanarak kaybettiğimiz password dosyasını yeniden yaratabiliriz;

# orapwd file=$ORACLE_HOME/dbs/orapworcl password=password entries=10

Kontrol Dosyasının Kaybolması ve Kurtarılması

Kimi durumlarda bütün kontrol dosyalarını kaybetme ihtimalimiz bulunmaktadır. Bu tarz durumlarda kontrol dosyasını yedekten çıkartarak, RESETLOGS opsiyonu ile (kontrol dosyası uçtuğu zaman bu komut yardımı ile onlie redolog'ların seviyelerini eşitlemek zorundayız) veritabanını açabiliriz.

RMAN> SQL 'STARTUP NOMOUNT';
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> SQL 'ALTER DATABASE MOUNT';
RMAN> RECOVER DATABASE;
RMAN> SQL 'ALTER DATABASE OPEN RESETLOGS';

RESTORE ve RECOVER Komutlarının Kullanımı

Restore ve Recover komutlarının aslında ne işimize yaradığından biraz bahsetmiştim. Öncelikle kullanımları ile ilgili bir örnek vermek istiyorum;

RMAN> RESTORE [DATABASE | TABLESPACE | DATAFILE];
RMAN> RECOVER [DATABASE | TABLESPACE | DATAFILE];

Archivelog modda olan bir veritabanındaki SYSTEM veya UNDO dışında kalan bir tablespace'e ait datafile'ın uçması durumunda veritabanını kapatmadan, ilgili datafile'ı en son commit'e kadar getirebilirsiniz. Bu işlemi EM üzerinden de yapabilir veya komut satırını tercih edebilir ya da DRA'yı (Data Recovery Advisor'ı) kullanabilirsiniz. Bunu yapabilmek için öncelikle datafile ile Oracle arasındaki ilişkinin kopması gerekmektedir;

SQL> ALTER DATABASE DATAFILE '/home/oracle/ogan01.dbf' OFFLINE IMMEDIATE;
RMAN> RESTORE DATAFILE 6;
RMAN> RECOVER DATAFILE 6;
SQL> ALTER DATABASE DATAFILE '/home/oracle/ogan01.dbf' ONLINE;

System, Sysaux veya Undo tablespace'ine ait bir datafile'ın uçması durumunda ise ne yazık ki öncelikle veritabanını kapatmamız gerekmektedir çünkü normal şartlar altında bu tablespace'leri offline konumuna getiremeyiz. Bunu yapabilmek için önce SHUTDOWN ABORT komutunu göndermek ve ardından veritabanını MOUNT moduna çekmemiz gerekir. MOUNT modunda olan bir veritabanına ait system datafile'ını restore ettikten sonra yine recover ediyoruz ve ardından veritabanını açıyoruz. Burada eğer online redolog'larımıza bir şey olmadı ise RESETLOGS komutunu eklememeliyiz.

Point-In-Time Recovery Gerçekleştirmek

Neden zaman içerisinde bir recovery işlemi yapmak isteyelim? Diyelim elimizde 5 gün öncesine ait bir tam yedek va ve 10 dakika önce bir tablo truncate edildi. Truncate operasyonunu geri alabilmek için bütün veritabanını 10 dakika öncesine dönmeniz gerekebilir. Bunu da yalnızca recover'a "10 dakika öncesine kadar redo'ları ve archivelog'ları işle" demenizi gerektirir.

RMAN> RUN {
SET UNTIL TIME '26/01/2011 00:02:10';
RESTORE DATABASE;
RECOVER DATABASE;
}

Burada veritabanını açmadan önce READ ONLY olarak açarak neler olduğuna bakınız. Okuma/yazma modunda açarsanız eğer yaptığınız bu restore - recover'ı commit etmiş olacaksınız.

SQL> ALTER DATABASE OPEN READ ONLY;

Baktınız işler yolunda, truncate edilmiş tablonun verisi yerli yerinde;

SQL> ALTER DATABASE OPEN RESETLOGS;

Neden resetlogs? Çünkü bir bir incomplete recovery (PITR) yapıyoruz. 

SPFILE'ı tamamen kaybettiğimiz durumlarda FROM MEMORY ifadesini kullanarak müthiş hızlı ve kesinlikle net bir spfile veya pfile oluşturabiliriz. 

SQL> CREATE [SPFILE | PFILE]
2 FROM [SPFILE | PFILE] | MEMORY;

Daha önce de belirtmiştim, kontrol dosyası ile birlikte spfile'ın da yedeği alınmaktaydı, yani autobackup'ta aslında benim spfile'ım bulunmakta.

SQL> STARTUP FORCE NOMOUNT;
SQL> RESTORE SPFILE FROM AUTOBACKUP;
SQL> STARTUP FORCE;

Yeni spfile'ımız hazır ve kontrol etmek istiyoruz;

SQL> show parameter SPFILE;

Buraya kadar umarım her şey açıktır. Çok kısa da olsa özetlemeye çalıştım ancak Recovery Manager ile ilgili olarak daha birçok şey yazılabilir. Burada yalnızca genel olarak aklınızda bir fikir oluşmasını ve RMAN'in aslında ne olduğunu anlamanızı hedefledim.

İyi çalışmalar dilerim.

Ogan
Takip et: @oganozdogan