19 Ocak 2011 Çarşamba

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

Hiç yorum yok:

Takip et: @oganozdogan