
Bu yazımızda Oracle RMAN Backup and Recovery işlemleri hakkında detaylı bilgiler paylaşacağım.
Veritabanı yönetimi denildiğinde akla gelmesi gereken en kritik konulardan biri de yedekleme (backup) ve kurtarma (restore) süreçleridir. Felaket anında veri kaybını önlemek ve sistem sürekliliğini sağlamak için alınan yedeklerin doğru şekilde yönetilmesi hayati öneme sahiptir.
Oracle’ın sunduğu RMAN (Recovery Manager) aracı, bu ihtiyaca doğrudan cevap veren entegre ve güçlü bir yedekleme çözümüdür. RMAN ile fiziksel ve mantıksal yedekleme işlemlerini otomatikleştirip, PITR (Point-In-Time Recovery) gibi ileri düzey kurtarma senaryoları uygulanabilmektedir.
RMAN (Recovery Manager), Oracle veritabanlarının yedeklenmesi, kurtarılması ve klonlanması için kullanılan komut satırı tabanlı bir yedekleme aracıdır. Redo log, archive log, kontrol dosyası ve SPFILE gibi kritik bileşenlerin yedeğini alır. Yedekleme katalogları ile geçmiş yedekleri takip eder.
RMAN Yedekleme Türleri:

1.Full Backup (Tam Yedek)
Veri tabanının tamamının fiziksel yedeğini alır. Incremental yedekleme zincirinin parçası değildir. Tek başına restore edilmektedir.
BACKUP DATABASE;
2.Incremental Backup (Artımlı Yedek)
Sadece değişen veri bloklarını yedekleyerek disk alanı ve süre tasarrufu sağlar. İki seviyeye ayrılır:
2.1.Level 0 Backup
- Tüm veri bloklarını yedekler. Aslında bir tam (full) yedektir, ama incremental backup zincirinin başlangıcı olarak kullanılmaktadır.
- Daha sonra alınacak Level 1 yedekler, bu yedekle kıyaslanarak değişen bloklar yedeklenir.
BACKUP INCREMENTAL LEVEL 0 DATABASE;
2.2. Level 1 Backup
Level 0 yedeğe göre değişmiş blokları yedekler. İki seviye vardır:
2.2.1.Differential Level 1
Level 0’dan bu yana değişen blokları yedekler. En sık kullanılan ve default level 1 incremental yöntemidir.
BACKUP INCREMENTAL LEVEL 1 DIFFERENTIAL DATABASE;
2.2.2. Cumulative Level 1
Level 0’dan itibaren tüm değişiklikleri kapsar. Restore işlemi daha kolay ancak daha fazla veri yedeklenmektedir.
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
3.Archive Log Backup
Archive log dosyalarının yedeğini alır. PITR gibi işlemlerde restore için gereklidir.
BACKUP ARCHIVELOG ALL;
4.Control File ve SPFILE Backup
Control File dosyası ve sunucu parametre dosyasının (SPFILE) yedeğini alır:
BACKUP CURRENT CONTROLFILE;
BACKUP SPFILE;
Full backup incremental backup in bir parçası değildir. Bu sebeple PITR işlemini archive loglar ile sağlar. Level 0 ise database in full backup nı alır ve
incremental in bir parçası olduğu için level 1 ve archive loglar ile PITR işlemi sağlanır. Bu sebeple en yaygın ve kullanışlı yöntem olarak level 0 ve level 1 kullanılmaktadır.
RMAN Backup and Recovery için aşağıdaki görselde örnek bir backup planı üzerinden çalışma mantığını inceleyelim. Bu plana göre pazar günü level 0 full backup Pazartesi, Salı, Perşembe, Cuma, Cumartesi günleri level 1 incremental differantial backup, Çarşamba günü de level 1 cumulative backup alacak şekilde bir planımız olduğunu varsayalım. Ayrıca saatte bir de archive log backup alacak şekilde bir backup planımız olduğunu düşünürsek.

- Pazar günü saat 12:00 ye restore etmek istediğimiz de level 0 + Archive backuplar recovery edilip restore işlemi tamamlanacaktır.
- Çarşamaba günü saat 12:00 ye restore etmek istediğimiz de level 0 + level 1 cumulative + Archive backuplar recovery edilip restore işlemi tamamlanacaktır.
- Perşembe günü saat 12:00 ye restore etmek istediğimiz de level 0+level 1 cumulative+ level 1 differantial + Archive backuplar recovery edilip restore işlemi tamamlanacaktır.
RMAN Backup and Recovery süreçlerimizi yönetmek için RMAN de configuration parametrelerimizin ayarlanması gerekmektedir. Bu ayarlar database boyutu,disk yapısı ve yoğunluk durumlarına göre değişebilmektedir. Aşağıda default configuration ve ortalama bir sistem için set edilebilecek ayarlar verilmiştir.
“rman target/” yazıp giriş yaptıktan sonra show all ile parametreler listeliyoruz.
[oracle@rac1 tmp]$ rman target/
Recovery Manager: Release 19.0.0.0.0 - Production on Wed Feb 16 17:29:04 2022
Version 19.3.0.0.0
connected to target database: ORAMV (DBID=1908156382, not open)
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name ORAMV are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF;
CONFIGURE ENCRYPTION ALGORITHM 'AES128';
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS;
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/snapcf_ORAMV.f'; # default
RMAN Konfigürasyon Parametrelerinin Açıklamaları:
- CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
Alınan backuplardan son kaç backup ın restore edilebileceği ile ilgili parametredir. Yukarıdaki gibi defaultta yalnızca bir adet backup seti saklanmaktadır. Daha önce alınan yedekler OBSOLETE sayılır ve silinmeye aday olur. Gün olarak da saklanabilecek backup seti tanımlanabilir. Aşağıda son 30 güne kadar geri dönebilecek şekilde backupları saklaması için retention policy tanımlıyoruz.
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;
- CONFIGURE BACKUP OPTIMIZATION OFF;
Bu parametre ile daha önce yedeklenmiş ve değişmemiş dosyalar tekrar yedeklenmez. Özellikle incremental yedeklerde zaman kazandırır.
CONFIGURE BACKUP OPTIMIZATION ON;
- CONFIGURE DEFAULT DEVICE TYPE TO DISK;
Yedeklerin varsayılan olarak disk ortamına alınacağını belirtir. Tape cihazı kullanılacaksa: TO SBT_TAPE parametresi set edilmelidir.
- CONFIGURE CONTROLFILE AUTOBACKUP ON;
Bu parametre ile her yedekleme sonrası control file ve SPFILE otomatik olarak yedeklenmektedir. Felaket senaryoları için hayati önem taşır.
- CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’;
Control file yedeklerinin benzersiz formatta (%F) isimlendirilmesini sağlar.
- CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
Backup alırken parallel olarak backup almasını sağlayabiliriz. Backup alacağımız disk ve database sunucumuzun özelliklerine göre parallel sayısı set ediyoruz.
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET;
- CONFIGURE DATAFILE / ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
Veri dosyası ve arşiv loglarının kaç adet kopyasının saklanacağı bilgisi ayarlanır.
- CONFIGURE MAXSETSIZE TO UNLIMITED;
Bu parametre, bir backup set dosyasının alabileceği maksimum boyutu belirler.
UNLIMITED: RMAN, backup set dosyalarını sınırsız boyutta oluşturabilir. Örneğin, bir full backup’ta tüm veri dosyaları tek bir büyük backup set içinde olabilir.Disk alanı yönetimi ve yedekleme medyası (özellikle tape) için sınır koymak gerekir.
CONFIGURE MAXSETSIZE TO 32G;
- CONFIGURE ENCRYPTION FOR DATABASE OFF; & ENCRYPTION ALGORITHM ‘AES128’;
Encryption özelliği şu anda devre dışıdır. Aktif edilirse AES128 algoritması kullanılacağını belirmektedir.
- CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE;
RMAN yedeklerini sıkıştırmak için kullanılan algoritmayı ve optimizasyon ayarını belirtir.
- CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS;
RMAN’in ürettiği log, backup kayıtları, LIST BACKUP ve REPORT gibi komut çıktılarının kaç gün saklanacağını belirler. RMAN recovery catalog veya control file üzerinden backup meta verilerinin tutulma süresini etkiler. Özellikle LIST, REPORT, CROSSCHECK gibi komutlarda eski verilerin gözüküp gözükmeyeceğini belirler.
- CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
RMAN hiçbir zaman archivelog dosyalarını otomatik olarak silmemektedir. DELETE OBSOLETE komutu çalıştırıldığında bile archivelog’lara slmez. FRA (Fast Recovery Area) alanı dolarsa, manuel müdahale gerekir. Bu ayar, özellikle standby veritabanı olmayan sistemlerde güvenli başlangıç ayarıdır. Aşağıdaki gibi set edilirse RMAN, archivelog’ları yalnızca tüm standby veri tabanlarında apply edildiğinde siler.
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
Alternatif olarak aşağıdaki gibi set edilirse archivelog’ları, yalnızca en az 1 defa diske yedeklendiğinde siler (archivelog policy).
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;
Eğer ARCHIVELOG DELETION POLICY TO NONE ise, DELETE OBSOLETE komutu çalışsa bile archive log’lar silinmez. Bu yüzden özellikle FRA doluluk riski varsa, silme politikası tanımlanmalıdır. Özetle bu parametre için Standby DB varsa APPLIED ON ALL STANDBY yoksa BACKED UP 1 TIMES TO DISK set edilmesi gerekmektedir.
- CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/u01/app/oracle/…/snapcf_ORAMV.f’;
RMAN bazı işlemler (özellikle BACKUP, RESYNC, CATALOG) sırasında, control file’ın bir kopyasını alır: bu bir snapshot control file’dır.Control file’a aynı anda başka işlemler de erişiyor olabilir. Snapshot, bu çatışmaları önler. Özellikle RMAN recovery catalog kullanıldığında zorunludur. Bu parametre, snapshot dosyasının fiziksel konumunu belirtir.
Backup alma işlemleri
Buraya kadar parametrelerimizi anlattıktan sonra backup alıp restore adımlarına geçebiliriz. Aşağıda örneklerle Level 0, Level 1 differantial ve cumulative backup alıp restore edilebilmesi için scriptler verilmiştir.
- Level 0 backup scripti:
Aşağıdaki script ile veritabanının tam (L0) yedeğini 4 channel ile alır. Control file ve SPFILE yedeklerini ayrıca alır. Son olarak, artık geçerli olmayan eski yedekleri silerek disk alanı tasarrufu sağlar.
run
{
allocate channel ch01 device type disk format '/backup/FULL/FULL_%U';
allocate channel ch02 device type disk format '/backup/FULL/FULL_%U';
allocate channel ch03 device type disk format '/backup/FULL/FULL_%U';
allocate channel ch04 device type disk format '/backup/FULL/FULL_%U';
backup as backupset incremental level 0 section size 32g database tag 'RMAN/FULLBACKUP_L0' plus archivelog not backed up 2 times;
#control file backup
allocate channel ch_cntl device type disk format '/backup/CONTROLFILE/cf_%U';
backup as backupset CURRENT CONTROLFILE channel ch_cntl;
#spfile backup
allocate channel ch_sp device type disk format '/backup/SPFILE/sp_%U';
backup as backupset SPFILE channel ch_sp;
DELETE NOPROMPT OBSOLETE;
}
- Level 1 differantial backup scripti:
Aşağıdaki script ile 4 channel ile Level 1 Differantial yedek alır. Son olarak geçerliliğini yitirmiş (obsolete) yedekleri temizler.
run
{
allocate channel ch01 device type disk format '/backup/INCR/INC_%U';
allocate channel ch02 device type disk format '/backup/INCR/INC_%U';
allocate channel ch03 device type disk format '/backup/INCR/INC_%U';
allocate channel ch04 device type disk format '/backup/INCR/INC_%U';
backup as backupset incremental level 1 section size 32g database tag 'RMAN/INCBACKUPSET_L1' plus archivelog not backed up 2 times;
DELETE NOPROMPT OBSOLETE;
}
- Level 1 cumulative backup scripti:
Aşağıdaki script ile 4 channel ile Level 1 cumulative incremental backup alır. Archivelog dosyalarını da yedekler ve eski (obsolete) yedekleri temizler.
run
{
allocate channel ch01 device type disk format '/backup/INCR/INC_%U';
allocate channel ch02 device type disk format '/backup/INCR/INC_%U';
allocate channel ch03 device type disk format '/backup/INCR/INC_%U';
allocate channel ch04 device type disk format '/backup/INCR/INC_%U';
backup as backupset incremental level 1 cumulative section size 32g database tag 'RMAN/INCBACKUPSET_L1' plus archivelog not backed up 2 times;
DELETE NOPROMPT OBSOLETE;
}
- Archive log backup scripti:
Aşağıdaki script ile henüz yeterli sayıda yedeklenmemiş archivelog dosyalarını yedekler. 30 günden eski archivelog’ları siler.
run
{
allocate channel ch01 device type disk format '/backup/ARCH/ARCH_%U';
allocate channel ch02 device type disk format '/backup/ARCH/ARCH_%U';
allocate channel ch03 device type disk format '/backup/ARCH/ARCH_%U';
allocate channel ch04 device type disk format '/backup/ARCH/ARCH_%U';
backup archivelog all not backed up 2 times;
delete noprompt archivelog until time '(sysdate-30)';
}
Yukarıdaki scriptler ile database sistemlerimiz için belirlenecek en uygun zamanda backup politikası oluşturulabilir. Bu scriptler ile sh oluşturup crontab schedule ile backup alma işlemleri yapılabilir.
Restore işlemleri:
Backuplarımızı aldıktan sonra database restore işlemleri için aşağıdaki adımları takip ediyoruz.
Eğer RMAN yedeklerini yeni bir sunucuda (disaster recovery ortamı gibi) restore edilecekse veya control file bozuksa öncelikle , control file restore edilmelidir. Bu işlemler için öncelikle database nomount modda açılıp controlfile restore edilmelidir.
SQL>startup nomount;
[oracle@rac1 tmp]$ rman target/
RMAN> RESTORE controlfile from '/backup/CONTROLFILE/cf_XXXX';
Control file ı restore etmek istemiyorsanız aşağıdaki gibi Database mount modda açılıp restore işlemleri yapıyoruz.
[oracle@rac1 ~]$ . db.env
[oracle@rac1 ~]$ sqlplus / as sysdba
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 3070227080 bytes
Fixed Size 8901256 bytes
Variable Size 721420288 bytes
Database Buffers 2332033024 bytes
Redo Buffers 7872512 bytes
Database mounted.
rman target ile bağlanıp kullanılabilir backupları kontrol ediyoruz.
[oracle@rac1 tmp]$ rman target/
RMAN> list backup;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2 Full 18.89M DISK 00:00:01 16-FEB-22
BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20220216T164149
Piece Name: /u01/app/oracle/product/19c/db_1/dbs/c-1908156382-20220216-00
SPFILE Included: Modification time: 16-FEB-22
SPFILE db_unique_name: ORAMV
Control File Included: Ckp SCN: 3527387 Ckp time: 16-FEB-22
.
.
Daha sonra aşağıdaki gibi restore ediyoruz.
RMAN> restore database;
Starting restore at 16-FEB-22
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to +DATA_DISK/ORAMV/DATAFILE/system.257.1095182347
channel ORA_DISK_1: restoring datafile 00003 to +DATA_DISK/ORAMV/DATAFILE/sysaux.258.1095182591
channel ORA_DISK_1: restoring datafile 00004 to +DATA_DISK/ORAMV/DATAFILE/undotbs1.259.1095182667
channel ORA_DISK_1: restoring datafile 00005 to +DATA_DISK/ORAMV/DATAFILE/undotbs2.265.1095184307
channel ORA_DISK_1: restoring datafile 00007 to +DATA_DISK/ORAMV/DATAFILE/users.260.1095182667
channel ORA_DISK_1: reading from backup piece /tmp/backup/backup_060m0b9i_1_1
channel ORA_DISK_1: piece handle=/tmp/backup/backup_060m0b9i_1_1 tag=TAG20220216T164746
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
Finished restore at 16-FEB-22
RMAN> recover database;
Starting recover at 16-FEB-22
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:07
Finished recover at 16-FEB-22
Yukarıdaki script ile restore işleminde tek channel ile restore işlemini yapıp en son backup ve archive log a recovery eder. Eğer restore edilmek istenilen bir zaman dilimi ve parallel olarak yapılmak istenirse için aşağıdaki gibi kullanılmaktadır.
run
{
allocate channel ch01 device type disk;
allocate channel ch02 device type disk;
allocate channel ch03 device type disk;
allocate channel ch04 device type disk;
set until time "to_date('2022-08-02:08:00:00', 'yyyy-mm-dd:hh24:mi:ss')";
restore database;
recover database;
release channel ch01;
release channel ch02;
release channel ch03;
release channel ch04;
}
Restore işlemi tamamlandıktan sonra database i resetlogs ile açıyoruz. Resetlogs Redo log dosyalarının SCN numaralarını sıfırlar. Yeni bir incarnation başlatır (veritabanı kimliği). Aşağıdaki durumlarda resetlogs kullanılmaktadır.
- Incomplete Recovery (Eksik Kurtarma) sonrası: Eğer full backup alındıktan sonra sadece belirli bir tarihe (Point-In-Time Recovery – PITR) kadar recovery yapılmışsa, log zinciri artık geçmişiyle tutarlı değildir. Bu yüzden Resetlogs gerekir.
- Control File kaybı veya recreate edilmesi sonrası: Control file yedeğinden restore ettiğinizde veya CREATE CONTROLFILE ile yeniden oluşturduğunuzda da geçmiş log zinciriyle ilişki kopar. RESETLOGS bu yeni zinciri başlatmak için gereklidir.
SQL> alter database open resetlogs;
Database sorunsuz olarak açıldıktan sonra restore işlemlerini tamamlamış oluyoruz.
Bu yazımızda Oracle RMAN Backup and Recovery konusunda detaylı olarak adımlarını tamamlamış olduk. Bu sayade database backup süreçlerimiz ve veri güvenliğimiz için RMAN ile backup yönetimini kullanabilirsiniz.
Oracle ile ilgili diğer yazılarımız için tıklayınız.
Oracle resmi dokümantasyon için tıklayınız.
https://shorturl.fm/wzkt2