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