Bu yazıyla RMAN hakkında konuşmaya devam edeceğiz ve bu konuyu burada bitireceğiz. Bu yazıda blok bozulması ve RMAN'ın list-advice-repair özelliklerine değinmek istiyorum. Hemen RMAN'ı dolayısıyla Oracle'ı özel yapan neymiş bir bakalım:
LIST-ADVICE-REPAIR FAILURE
Önceki yazıda bilindiği gibi kaybolan veya bozulan bir veri dosyasının nasıl geri getirileceğini öğrendik. Bu yol biraz karmaşık gelmiş olabilir. Bunun Oracle'ın RMAN'da kendi çözümleriyle yapılıyor olması büyük avantaj. Yani aslında yapılması gereken adımları RMAN sizden önce hesaplıyor ve size sunuyor. Arkasından sizin yapmanız gereken tek şey "Bunları uygula!" demek oluyor. Bu üç adım bize bunu ifade ediyor aslında.
- List Failure: Var olan hatalı sistemleri tespit ederek bir kurtarma işlemine ihtiyaç duyuluyorsa bunu size belirtir.
- Advice Failure: Bulunan hatalarla ilişkili olan optimum çözümü ve buna ait komutları size sunar.
- Repair Failure: Bu adım da sunulan çözümün onaylanarak veritabanına uygulanmasını içerir.
Bununla ilgili olarak bir block corruption durumunda neler yapılabilir diye bakmadan önce bir block corruption'un ne olduğuna bakalım:
BLOCK CORRUPTION
Veri bloğu: Veritabanındaki verilerin saklandığı en küçük mantıksal birimdir.
Bazen yapılan değişiklikler esnasında tek veya birden fazla veri bloğunda problemler oluşabilir. Bu durumda bir veri dosyasının bozulmasından daha fazla risk vardır. Zira veri dosyasının bozulduğu hemen anlaşılabilir. Ancak veri bloğunun bozulmasında müşteri o veriye erişmeden o bloğun hatalı olduğu anlaşılmaz. Mesela bu sıkıntı bir marketteki kredi kartı ödemesi sırasında yada havale esnasında gerçekleşebilir. RMAN'ın ayrıca tercih edilmesinin sebebi back-up alınmadan önce tüm veri dosyalarını tarayarak corrupt olmuş veri bloklarını tespit eder ve size buralarda sıkıntı var diyerek haber verir. Bu da DBA'a ve şirkete büyük avantaj sağlar.
Block Corruption Çözümü:
Öncelikle çözüm için bir block corruption oluşturmamız gerekiyor. Bunun için önceki yazıda oluşturduğumuz 3 veri içeren tek sütunlu tablomuzu kullanalım. Bunun için bu tablonun hangi veri dosyasında saklanıyor olduğunu bilmemiz gerekiyor. Bunu önceki yazıda keşfettik. Ancak nokta atışı yapmak için blok numarasını da öğrenmemiz gerekmekte. Bunun için şöyle bir fonksiyon kullanılıyor:
SQL> SELECT dbms_rowid.rowid_block_number(rowid) BLOCKNO, id FROM A WHERE id = 3
Bu sorgunun sonucunda aşağıdaki gibi bir sonuç dönsün;
BLOCKNO id
------- ---
168 3
Bunu öğrendikten sonra veri dosyasının içeriği açılıp o blok manuel olarak bozulabilir. Tabi normal olarak bu tarz bir bozma işlemini hiç kimse yapmıyor. Şimdi böyle bir corruption durumunda neler yapılacak onlara bakalım:
Hemen RMAN ile yukarıda saydığımız adımları uygulamalıyız:
RMAN> list failure;
Önümüze yukarıda oluşturduğumuz block corruption getirilecektir.
RMAN> advice failure;
"Bu durumdan nasıl kurtulabiliriz" sorusunun yanıtı sunulur.
RMAN> repaire failure preview;
Toplamda uygulanacak olan script bu şekilde görüntülenip incelenebilir.
RMAN> repaire failure;
Ve son olarak script gerçekten veritabanına uygulanır ve corruption tamir edilir.
Sadece 3 küçük ifadeyle büyük bir problemden kurtulmak ancak bu kadar keyifli olabilir...
Başka bir konudan daha bahsedecek olursak;
Veritabanındaki back-up'lar silindiği zaman RMAN bu back-up'ların silindiğini anlayamaz. Çünkü RMAN daima kontrol dosyalarını baz alarak çalışır. Bir back-up alınması anında bu back-up kontrol dosyasına yazılır. Eğer manuel olarak silinirse kontrol dosyasında var olarak görünen bir back-up aslında fiziksel olarak yoktur. Bu durum iyi sonuçlanmayabilir. Bu yüzden kontrol dosyasındaki tutarsız veriler temizlenmelidir. RMAN bunun için de bazı çözümler getirmiş:
RMAN> crosscheck backup of kontroldosyaismi
Bununla "ismi verilen kontrol dosyası gerçekten fiziksel olarak var mı" sorusu sorulur. Eğer silinmişse bu dosya RMAN tarafından EXPIRED olarak işaretlenir.
RMAN> delete noprount expired backup of kontroldosyaismi
Böylelikle de anlamsız bilgi olan bu EXPIRED bilgi temizlenmiş olur. Buradaki noprount ise onay gerektirmeden silme işleminin yapılması içindir.
Image Copy Back-up ve Back-up Set
Çok bilinen ve çok kullanılan bu iki tür back-up işleminin ne olduğuna bakalım. Aslında bizim bir önceki yazıda yaptığımız Back-up Set'e bir örnekti. Bakalım bunlar neymiş:
Image Copy Backup: Her veri dosyasının ayrı ayrı kopyasını alır. Örneğin 4 adet veri dosyası varsa 4 adet back-up veri dosyası oluşturulur. Back-up işlemi oldukça hızlı gerçekleşir. Çünkü yapılan sadece veritabanının yönünü değiştirmekten ibarettir. Yani var olan dosyaların bire bir kopyası alınır. Üzerinde bir işlem yapılmaz. Dezavantajı şudur ki; veritabanına ayrılan boyut 1 TB ise ve bu 1 TB'ın az bir kısmı kullanılıyor olsa dahi back-up'ın boyutu da 1 TB olur. Bunun için aşağıdaki komut kullanılır:
RMAN> backup as copy database;
Recovery işlemi için de;
RMAN> switch database to copy;
Backup Set: Veri dosyaları tek bir dosya şeklinde yedeklenir. Avantajı sadece kullanılan alanın back-up'ını alır ve bu da boyutunu küçültür. Bu back-up işleminde ayrıca back-up dosyasını sıkıştırmak mümkündür. Ayrıca bir avantajı daha vardır ki: Alınan back-up'ı disk üzerinde saklamadan bir tape'e kaydetmek mümkündür. Ancak diğer yönteme göre daha uzun sürer.
Elbette hangi yöntemin kullanılacağına şirket politikasıyla ve veritabanının kritik durumuyla değerlendirilerek karar verilir.
Böylelikle bu konuyu noktalıyoruz. Umarım öğrendiklerimi aktarabilmişimdir. İyi çalışmalar!
Hiç yorum yok:
Yorum Gönder