Oracle Veritabanı Yedekleme / RMAN - Oracle Secure Backup

Merhabalar,

Günlük tutmaya başladığım ilk zamanlardan kalma bir recovery manager (rman) yazım var ancak ben biraz daha işi rman'den önce yedeklemenin ne olduğunu, nasıl alındığını ve neden bir veritabanının yedeğini almamız gerektiğinden bahsedeceğim.

3 çeşit yedekleme bulunmaktadır.

1) Recovery Manager
2) Oracle Secure Backup
3) Kullanıcı Tarafından Alınan Yedekler

Oracle tarafından tavsiye edilen yöntem recovery manager'dır ancak tabii ki diğer metodların da kullanılabileceği bir gerçektir. Recovery Manager'ın yanında da veritabanınızın archivelog modda olması gerekmektedir.

Oracle Secure Backup ise yedeklerin kaset (tape) ünitesine alınmasını ve yönetilmesini sağlayan bir Oracle ürünüdür. Kullanım alanı her ne kadar geniş olmasa da ciddi bir ek fonksiyonalite katmaktadır.

Kullanıcı tarafından alınan yedeklerde ise DBA'in bir script yazması ve bunu uygulaması gerekmektedir. Son yıllarda kategori dışında kalan bu yöntem hala devam ettirilebilmektedir.

Oracle Secure Backup

OSB ve RMAN ile birlikte, Oracle veritabanları için sağlam ve kesin yedekleme hizmeti sunabilmektedir. Kaset ünitesine yedek alınması için "media management layer (library)" entegrasyonunu yapmaktadır. Normal şartlar altında bu katmanı ayarlamanız ve kaset ünitesinin yönetimini tanımlamanız gerekmektedir. Tanımlama yapmak için üçüncü bir parti ürün almanız gerekmektedir. Bunun yanı sıra, OSB yalnızca Oracle veritabanını korumakla kalmıyor ve veritabanına ait olmayan işletim sistemi dosyalarını da koruyarak, uçtan uca ve güvenli bir sonuç sağlamaktadır. Bu sayede bütün Oracle envanteri korunabilmektedir.

Kullanıcının yani veritabanı yöneticisinin alabileceği yedekler için birkaç yardımcı dinamik performans görüntüleri bulunmaktadır;

V$DATAFILE, V$LOGFILE, V$CONTROLFILE, V$BACKUP.

Bu görüntüler sorgulanarak veritabanı yöneticisi hangi datafile'ın yedeğinin alınması gerektiğini veya redolog'ların durumunu, kontrol dosyasının son halini ve tablespace'lerle ilgili bilgileri toplayabilmektedir.

Yedekleme Stratejileri

Bir veritabanı yöneticisinin asli görevlerinden birisi de veritabanının korunması ve içerisindeki verilerin de yedeklenmesidir. Veri kaybının açıklanabileceği durumla dışında kalan durumlar için sistemi açık, optimum ve korunmasının garanti altına alınmasın sağlanması şarttır. Bu stratejiler veritabanının tamamını veya bir kısmını kapsayabilir. Elbette ki elimizde bulunan veri ambarının her gün tam yedeğinin alınması gibi bir durum söz konusu olmayabilir. Bu şartlar altında veritabanındaki bütün blokların yedeklenmesi yerine yalnızca tam olarak alınmış yedek (bütün bloklar) ve sonradan alınan yedek arasındaki blokların yedeklenmesi gerekmektedir (incremental). Bir yedekleme modu iki tipten oluşabilir.

1) Offline (tutarlı, soğuk)
2) Online (tutarsız, sıcak)

Burada açıklamam gereken nokta ise neden online alınan bir yedeğin tutarsız olarak adlandırılması. Neden tutarsız, aslında en sağlam olan bu yedekleme tipi). Bunu açıklamaya başlamadan önce -ki aslında en kritik nokta bu- diğer konuya geçeceğim.

Bütün veritabanının yedeklenmesi, yani bütün datafile'ların ve en az bir tane kontrol dosyasının yedeklenmesi demektir. Hatırlatmam gerekirse, bir veritabanını yalnız bir kontrol dosyası ile açabildiğimiz gibi, birden çok kontrol dosyasına da sahip olabiliriz. Oracle bize birden çok kontrol dosyamızın olması gerektiğini tavsiye etmektedir.
Kısmi veritabanı yedeklemesi, sıfır, bir veya birden fazla tablespace, datafile veya kontrol dosyası içeren veritabanı yedekleme türleridir.
Tam veritabanı yedeklemesi, veritabanı seviyesindeki bütün veri içeren blokların yedeklenmesine denmektedir. Veri içermeyen bloklar yedeklenmemektedir ancak tanımladığınız yedekleme tipi "image copy" değilse.
Artımlı (incremental) veritabanı yedeklemesi, bir önceki yedek ile alınan zaman arasında değişen bütün veri bloklarının yedeğinin alınmasıdır. Oracle veritabanı iki seviyede artımlı yedekleme desteklemektedir. Sıfır ve birinci seviye olarak ikiye ayrılan yedekleme tipleri bu stratejinin bir parçasıdır ve level 0'ı artımlı yedeklemenin tam, level 1'i de artımlı yedeklemenin tam ile level 1 arasında kalan kısmını temsil etmektedir. "Cumulative" veya "differential" olarak alınabilen bu artımlı yedeklemenin kümülatif, yani level 0'dan sonra alınan her level 1'in, level 0 ile arasındaki farkın takip edilmesi, ayrımsalda ise her level 1 arasındaki blok değişiklikleri tutulmaktadır.
Offline yedeklemede (bir diğer adı ise tutarlı ve soğuk) veritabanı kapalı olmalıdır. Veritabanı kapalıyken alınmasının nedeni kontrol dosyasındaki SCN ile datafile blok başlıklarındaki SCN'nin eşit olması gerekmektedir.
Online yedeklemede (bir diğer adı ise tutarsız ve sıcak) veritabanı açıkken yedekleme yapılabilir. Tutarsız olmasının sebebi ise kontrol dosyası ile datafile blok başlıklarının senkronize olamayacağıdır. Olmasının da bir garantisi yoktur fakat oladabilir.

İmaj Kopyaları ve Yedek Grupları (Image Copies & Backup sets)

İşletim sistemindeki kopyalamaya benzeyen imaj kopyalarının kullanım alanı ve avantajları, yedek gruplarına göre daha azdır ve nadiren tercih edilmektedir. İmaj kopyalarında veri ve archivelog'lar kopyalanmaktadır.

Yedek gruplarında birden çok dosya bulunabilir ve bunların içinde datafile, kontrol dosyası, spfile veya archivelog'lar olabilir. Yedek grupları ile kullanılmayan veri blokları yedeklenmez. Bu şekilde veritabanının toplam boyutundan daha düşük boyutlarda yedekleme sağlanmaktadır. Bunun yanı sıra yedek grupları bir sıkıştırma algoritması ile sıkıştırılabilir ve disk veya kaset sistemi üzerinde daha az yer kaplayabilir. Burada belirtmem gerekiyor ki imaj kopyalarını kaset üzerine alamıyoruz, yalnızca diskte olması gerekiyor ancak yedek gruplarını hem diske hem de kasede alabiliyoruz. Veritabanlarının genelinde (istisnalar tabiiki olabilir) %20 oranında veri blokları kullanılmamaktadır ve sadece bu durum bile yedek gruplarını tercih etmemiz için bir neden olabilir.

Recovery Manager (RMAN)

Oracle veritabanının kurulumu ile birlikte otomatik olarak yüklenen araçlardan birisi olan recovery manager, veritabanının açıkken yedeklenmesi, yedekten dönülmesini ve 11g ile birlikte aramıza katılan "Data Recovery Advisor" aracının kullanılmasını sağlayan bir fonksiyonalitedir. Bana göre Oracle'ın geliştirdiği en güçlü ürünlerden birisidir ve görev kritikliği açısından son derece önem arz eden veritabanlarının ve dolayısıyla sizin de hayatınızı kurtarabilir. Hiçbir zaman kullanmak zorunda kalmıyorsanız problem ancak hep kullanıp, ürettiğiniz yedekleri kullanmak zorunda kalmıyorsanız biraz şans, biraz da sizin başarınız demektir.

Recovery Manager tutarlı ve aynı zamanda tutarsız yedek alınmasını sağlamaktadır. Bununla birlikte tam veya artımlı yedeklemenin önünü açmaktadır. Enterprise Manager'da da RMAN'in kontrolü için kullanılmaktadır. İleri düzey RMAN script'leri ve kontrol üniteleri komut satırından yapılıyor olsa da bir yedekleme zamanlamak veya yedekleme script'i yaratmak için son derece kullanışlıdır. Recovery Manager ile ilgili olarak sayfalarca yazı yazılabilir ancak burada yalnızca genel hatları ile yazıyor olacağım.

Recovery Manager'a bağlanabilmek için;

# RMAN TARGET /

Tanımlı RMAN konfigürasyonlarını görmek içinse;

RMAN> SHOW ALL;

Burada çok önemli bir noktaya değinmek isterim. CONFIGURE CONTROLFILE AUTOBACKUP OFF varsayılan olarak kurulumla birlikte ayarlanır. Bu parametrenin ON olarak ayarlanması bana göre önemlidir ve ON olduğu durumda kontrol dosyasının ve spfile'ın yedekleri de, veritabanı yedeği ile alınır. Bununla birlikte veritabanı üzerinde yapısal bir değişiklik olduğu zaman (örneğin bir tablespace'e datafile eklemek gibi) değişiklik arz eden kontrol dosyası, FRA (fast recovery area) alanına kaydedilir. 11g'nin burada 10g'den farkı, 10g her değişiklikte bu yedeği alırken, 11g belirli bir süre bekleyerek, mükerrer kontrol dosyası yedeklerinin alınmasını önlemektedir.

Kontrol Dosyasının Yedeklenmesi (Backup Control File to Trace)

Bütün kontrol dosyalarının kaybolması ne tip hatadır? Hepsi kaybolursa ne olur, bir tanesi kaybolursa ne olur? Kontrol dosyasının bir anda yok olması ile veritabanı anlık olarak kapanmaz ancak ne zaman CKPT bir yazma işlemi yapmak isterse (checkpoint position veya incremental checkpoint) ilgili kontrol dosyasını bulamayacak ve işte problemler burada başlayacak. Bir tane kontrol dosyasını kaybettiğimiz zaman eğer elimizde eş kopyaları bulunmakta ise spfile'da CONTROL_FILES parametresini güncelleyerek, diğer kontrol dosyalarından devam edebilirsiniz veya veritabanını kapatıp kontrol dosyasını kopyalayıp, yolunuza devam edebilirsiniz. Bütün kontrol dosyalarının uçtuğu durumda da aşağıdaki komutun önceden çalıştırılması işinize yarayabilir;

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Yukarıdaki komut ile Oracle otomatik olarak bir trace dosyasını yani kontrol dosyasının yeniden yaratılmasını sağlayan bilgileri içeren veriyi, DIAGNOSTIC_DEST parametresinin "trace" dizinine yazacaktır.

Alınan Yedeklerin Yönetilmesi

Veritabanı yedeklerinin bilgisi varsayılan olarak kontrol dosyasının içerisinde tutulmaktadır. Bunun yanında bir katalog tablespace'i içerisinde ve başka bir veritabanında da tutulabilmektedir. Bu tip bilgiler RMAN ile kılavuz niteliğindedir ve olmadan RMAN yedeklerinin nerede olacağını bilemez. İleri düzey ve kritik veritabanlarında kontrol dosyası yerine katalog kullanımı yaygındır.

RMAN bütün yedekleri ve archivelog'ları yönetebilmektedir. Silebilir, süresini doldurup geçersiz kılabilir ve kontrol altında tutabilir. Bunu yaparken CROSSCHECK komutunu kullanmaktadır. Crosscheck bir tip işaretlemedir ve RMAN'in bilgisi dışında olup biten neler olduğunu, RMAN'e göstermenin yoludur. RMAN'in aklında olan (kontrol dosyası veya katalog tablespace) yedeklerin veya archivelog değişimlerinin yerli yerinde durup durmadığına bakılır;

CROSSCHECK ALL;

RMAN kullanmadan bir yedeği elle silerseniz, RMAN bunun otomatik olarak farkına varamaz. Olası bir kurtarma durumlarında elle silinen yedeği arayabilir ve olmayan bir otomatik yedeklemeden kontrol dosyası çıkartmaya çalışabilir.

Recovery Manager'ın hafızasının sınırsız olmasını veya limitlendirilmesini sağlayabilirsiniz. Teknik olarak sınırsız olamayacağı varsayılırsa sahip olduğunuz yedeklerin belirli bir süre ile tutulmasının gerektiğini ifade edebilirim. Buna "retention policy" denir ve varsayılan olarak REDUNDANCY 1 tanımlı gelir. Bu, alınan ikinci veritabanı yedeği ile ilkinin "obsolete" yani geçersiz kılınmasına neden olur. Elle silinen yedekler "expired" olarak işaretlenirler, obsolete olarak değil. Hem geçersiz kılınmış hem de süresi dolmuş veya elle silinmiş yedekleri RMAN hafızasından atabilir veya atılmasının emrini verebilir.

Konuya burada bir nokta koymak ve gerçek olan soruya geçmek istiyorum; "Neden archivelog, neden online yedekleme?"

NOARCHIVELOG bir veritabanında olası bir datafile kaybında, eğer datafile sizin için önemli değilse ve kaybı geçerli kılınabilirse, ait olduğu tablespace'i düşürüp yolunuza devam edebilirsiniz. Sizin için önemli olduğu durumda ise;

1) Veritabanı en son alınan yedeğe döndürülür.
2) Bütün datafile'lar restore edilir ve redolog'lar silinir.
3) En son alınan yedekten sonra yapılmış bütün değişikliklerin kullanıcılara işlettirilmesi önerilir.
4) Buz gibi bir su içebilirsiniz.

Archivelog modunda olan bir veritabanına ait bir datafile kaybolduğu zaman, ona yapılan en son değişikliğe kadar archivelog'ların yardımı ile gelinebilir. Veritabanı açıkken de işlem yapabiliriz çünkü sadece system ve undo tablespace'ine ait bir datafile giderse kritik durum olur bunun dışında kalan durum ise majördür.

Her veritabanı archivelog modda olmayabilir. İşletme nedenleri gereği archivelog moda alınmayacak durumda olan bir veritabanı da olabilir. Bu konu hakkında çok detaylı bir tartışma bulunmaktadır. Belki ilginizi çekebilir;

http://forums.oracle.com/forums/thread.jspa?threadID=2159711&tstart=0

İyi çalışmalar.

Ogan

RMAN ile Unix Üzerinden Yedekleme (Crontab)

Merhaba,

Oracle OTN forumlarını karıştırırken şu şekilde bir soru ile karşılaştım;

"
Linux crontab'ında RMAN yedekleme zamanlamak istiyorum, nasıl yapabilirim?
"

Soru özel olarak crontab'a yönelik olduğu için nasıl yapılabileceğini paylaşacağım. Tabii crontab dışında da yedekleme şansınız bulunmakta;

Öncelikle kendimize bir shell script hazırlamamız gerekiyor. Aşağıdaki şekilde olduğunu varsayalım;


$ cat /backup/RMAN/backup_full.sh
connect target sys/password@opttest
backup incremental level 0 database format '/backup/DB_FULL_%d_%t_%s';
backup archivelog all delete all input format '/backup/ARC_%d_%t_%s';
exit;
$

1) Veritabanına giriş yaptık.

2) Level 0, yani bir full yedekleme işlemi yapmak istediğimizi gösterdik ve bunu yaparken formatının da nasıl şekilleceğini de belirttik.

3) Veritabanının oluşturduğu archivelog'ların da yedeklenmesini istedik ve formatının nasıl olması gerektiğini de gösterdik.

4) Çıkış talebinde bulunduk.

Bu script'i tanımladıktan sonra crontab'da ne yapmamız gerektiğine bakalım ama bunu yapmadan önce crontab'daki meşhur rakamların ne anlama geldiğini hatırlayalım;

$ man crontab

           minute         The minute of the hour, 0-59

           hour           The hour of the day, 0-23

           monthday       The day of the month, 1-31

           month          The month of the year, 1-12

           weekday        The day of the week, 0-6, 0=Sunday

Crontab işlemlerinden önceki 5 rakam veya sayının anlamının Türkçeleri;

1) Dakika

2) Saat

3) Gün

4) Ay

5) Hafta Günü

Şimdi ise crontab'da nasıl konumlandığını göstereceğim;

$ crontab -l

# ORACLE BACKUP JOBS #

######################

0 1 * * 0 export LD_LIBRARY_PATH=/opt/oracle/product/10.2.0/db_1/lib:/usr/dt/lib:/usr/lib ; export ORACLE_HOME=/opt/oracle/product/10.2.0/db_1/ ; /opt/oracle/product/10.2.0/db_1/bin/rman cmdfile /backup/RMAN/backup_full.sh log /backup/RMAN/backup_full.log

Yukarıdaki görüntüyü sırasıyla açıklamam gerekirse;

Veritabanının yedeği her Pazar günü ( 0 1 * * 0 ), gece saat 01:00'de ( 0 1 * * 0 ) alınacaktır. Recovery Manager'a bir shell script'ini gönderirken cmdfile komutunu kullanıyoruz, log işlemesini de istiyorsak log bilgisini de ekliyoruz. Crontab işe ne zaman başlayacağını ve gerekli library dosyalarını nerede bulacağını ve ORACLE_HOME parametresinin ne olduğunu artık biliyor (LD_LIBRARY_PATH, ORACLE_HOME). RMAN ise ne yapması gerektiğini artık biliyor (cmdfile, log).

Son olarak yukarıdaki yedeğin nasıl bir log dosyası üretmiş olabileceğine bakalım;

$ cat /backup/RMAN/backup_full.log

Recovery Manager: Release 10.2.0.4.0 - Production on Sun Dec 26 01:00:01 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

RMAN> connect target *

2> backup incremental level 0 database format '/backup/DB_FULL_%d_%t_%s';

3> backup archivelog all delete all input format '/backup/ARC_%d_%t_%s';

4> exit;

connected to target database: OPTTEST (DBID=750193206)

Starting backup at 26-DEC-10

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=1386 devtype=DISK

channel ORA_DISK_1: starting compressed incremental level 0 datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00002 name=/db/OPTIMA/oradata/opttest/opttest/UNDOTBS1.dbf

input datafile fno=00341 name=/db/OPTIMA/oradata/opttest/data/NORS_OWCTTS_D_02.dbf

input datafile fno=00369 name=/db/OPTIMA/oradata/opttest/data/NORS_ISUP_GROUP_D_03.dbf

input datafile fno=00307 name=/db/OPTIMA/oradata/opttest/data/NORS_TONES_D_02.dbf

input datafile fno=00311 name=/db/OPTIMA/oradata/opttest/data/NORS_SINGLE_UNIT_PM_D_02.dbf

input datafile fno=00313 name=/db/OPTIMA/oradata/opttest/data/NORS_PM_D_02.dbf

input datafile fno=00318 name=/db/OPTIMA/oradata/opttest/data/NORS_RTLTSUM_D_02.dbf

input datafile fno=00319 name=/db/OPTIMA/oradata/opttest/data/NORS_SOTS_D_02.dbf

input datafile fno=00320 name=/db/OPTIMA/oradata/opttest/data/NORS_SYSPERF_D_02.dbf

input datafile fno=00328 name=/db/OPTIMA/oradata/opttest/data/NORS_TREATMENT_D_02.dbf

channel ORA_DISK_1: starting piece 1 at 26-DEC-10

channel ORA_DISK_1: finished piece 1 at 26-DEC-10

piece handle=/backup/DB_FULL_OPTTEST_738731834_4120 tag=TAG20101226T010021 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:08:46

Finished backup at 26-DEC-10

Starting Control File and SPFILE Autobackup at 26-DEC-10

piece handle=/backup/c-750193206-20101226-00 comment=NONE

Finished Control File and SPFILE Autobackup at 26-DEC-10

Starting backup at 26-DEC-10

current log archived

using channel ORA_DISK_1

channel ORA_DISK_1: starting compressed archive log backupset

channel ORA_DISK_1: specifying archive log(s) in backup set

input archive log thread=1 sequence=546 recid=7882 stamp=738451102

input archive log thread=1 sequence=547 recid=7883 stamp=738532873

input archive log thread=1 sequence=548 recid=7884 stamp=738550821

input archive log thread=1 sequence=549 recid=7885 stamp=738622852

input archive log thread=1 sequence=550 recid=7886 stamp=738646398

input archive log thread=1 sequence=551 recid=7887 stamp=738714019

input archive log thread=1 sequence=552 recid=7888 stamp=738732388

channel ORA_DISK_1: starting piece 1 at 26-DEC-10

channel ORA_DISK_1: finished piece 1 at 26-DEC-10

piece handle=/backup/ARC_OPTTEST_738732389_4122 tag=TAG20101226T032628 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:02:36

channel ORA_DISK_1: deleting archive log(s)

archive log filename=/backup/OPTTEST/archivelog/2010_12_22/o1_mf_1_546_6k4mqk7w_.arc recid=7882 stamp=738451102

archive log filename=/backup/OPTTEST/archivelog/2010_12_23/o1_mf_1_547_6k73lz3b_.arc recid=7883 stamp=738532873

archive log filename=/backup/OPTTEST/archivelog/2010_12_24/o1_mf_1_548_6k7o3th2_.arc recid=7884 stamp=738550821

archive log filename=/backup/OPTTEST/archivelog/2010_12_24/o1_mf_1_549_6k9vgs5q_.arc recid=7885 stamp=738622852

archive log filename=/backup/OPTTEST/archivelog/2010_12_25/o1_mf_1_550_6kblgot5_.arc recid=7886 stamp=738646398

archive log filename=/backup/OPTTEST/archivelog/2010_12_25/o1_mf_1_551_6kdnhqyo_.arc recid=7887 stamp=738714019

archive log filename=/backup/OPTTEST/archivelog/2010_12_26/o1_mf_1_552_6kf6fx5w_.arc recid=7888 stamp=738732388

Finished backup at 26-DEC-10

Starting Control File and SPFILE Autobackup at 26-DEC-10

piece handle=/backup/c-750193206-20101226-01 comment=NONE

Finished Control File and SPFILE Autobackup at 26-DEC-10

Recovery Manager complete.

İyi çalışmalar.

Ogan