Bugün bir Workshop çalışmasında Talip Hakan ÖZTÜRK ile geçirdiğimiz faydalı bir çalışmayı sizlerle anlaşılır bir dille paylaşmak istiyorum. Bilindiği üzere veritabanlarında verilerin güvenliği üst düzeyde tutulmalıdır. Yani herhangi bir veri dosyasının bozulması, bir veri bloğunun anlamını yitirmesi veya tablo uzayının kaybedilmesi gibi durumlarda geri dönüşü mümkün kılan veritabanı teknolojileri tercih edilmelidir. Tabi ki bu konuda da Oracle'ın mucizevi çözümleri mevcut. Bunlardan bahsedelim:
Ama buna geçmeden önce blogumda daha önce yayınladığım Oracle fiziksel ve mantıksal mimarisi konularını okumanız çok faydalı olabilir. Yine de kısaca bunlardan bahsederek bir hatırlatma yapalım:
Oracle Instance: SGA ve proseslerden oluşan bir yapıdır. Her işlem Oracle Instance ile sağlanır. SGA; Oracle'ı Oracle yapan bir önbellek mantığıdır. SGA'da 3 temel yapı vardır:
Database Buffer Cache: Burada sık ve en son kullanılan SQL sorgularından dönen veriler tutulur. Yeni veriler geldikçe sınırlı alan olması nedeniyle en eski ve en az ulaşılan veriler silinirler. Buraya alınan veriler DBWR prosesi ile periyodik olarak Veri Dosyalarına yazılırlar.
Shared SQL Area: Burada SQL çalışma planları saklanır. Tekrar aynı SQL'e erişilmesi durumunda avantaj sağlar.
Redo Log Buffer: Burada da SQL komutlarının kendileri saklanır. (DML komutları) LGWR prosesi belli zamanlarda devreye girerek buradaki log verilerini Online Redo Log File'a yazar. ARCH prosesi de dolan Redo Log dosyalarını Arşivlenmiş Redo Log Dosyalarına kopyalar. Bir arşivin saklanması elbette bir sonra ki back-up işlemine kadar anlamlı olur. Ancak şirket politikasına göre bu arşivler daha uzun süre saklanırlar. Genelde 3 adet Online Redo Log Dosyası olmakla birlikte daha fazla da kullanılabilir. 1. Dosya dolduğu anda kopyası alınarak 2. Dosyaya yazma işlemi başlar. Daha sonra 3'e geçilir ve 3 dolduktan sonra tekrar başa dönülür. Eğer her dosya dolma işleminden sonra arşivlenmezse ilk dosyadaki veriler üstüne yazma işleminden dolayı kaybolur. Bu yüzden Log Dosyalarını arşivlemek back-up işlemleri için hayati önem taşır.
Şimdi de ihtiyaç duyacağımız kadar Oracle'ın mantıksal mimarisine değinelim. Bir bina düşünelim. Bu bina bizim veritabanımızı temsil etsin. Bu binanın her katı tablespace'leri temsil etsin. Yani bir veritabanında birden fazla tablo uzayı olur. Her kattaki odalar da segmentleri temsil etsin. Yani tablo uzayları aslında segmentlerden meydana gelir. Yine bir odadaki duvarlar da extend'leri temsil etsin. Bu duvara ait tuğlalar da data block'larını oluştursun. Bu yapıya göre binadaki data blocklarının yani tuğlaların boyutları değişmese de duvarları yani extendleri ileri alarak segmentlerin(odaların) boyutlarını artırıp azaltabiliriz. Ancak segmentler katın(tablo uzayı) kendisi kadar büyüyebilir. Özetlersek veri blokları extendleri, extendler segmentleri, segmentler tablo uzaylarını ve nihayet veritabanını oluşturur.
Bir bankamatikten havale işlemi yaptığımızı düşünelim. Tüm bilgileri girip gönder dediğimizde aslında arka planda DML işlemleri insert-update-delete sorgularını çalıştırarak karşılıklı iki tabloyu günceller. Fakat bizim karşımıza yeni bi uyarı penceresi çıkar. Bilgileri doğrulamamız istenir. Tekrar doğrularsak COMMIT ifadesi ile veritabanındaki değişiklikler kalıcı hale getirilir. Eğer onayı geri alırsak ROLLBACK ile son DML komutları geri alınır. Zaten daha önce bahsettiğimiz transaction yönetimi içerikli yazıda tüm bunlar mevcuttu.
RMAN'ı daha iyi anlamak için Oracle'ın açılma-kapanma mantığını anlamamız gerekiyor. Oracle 4 basamaklı bir merdiveni tırmanır gibi açılır. Bu işlemler aşağıdaki şekilde sembolize ediliyor:
Nomount: Görüldüğü gibi nomount adımında instance başlatılır. Bu adımda Oracle spfile.ora'yı okur. Bu dosya binary içerikli bir dosyadır ve içini açıp bakmak olanaksızdır. Bu bir parametre dosyasıdır ve Oracle'a ait önemli bilgiler burada tutulur. Kontrol dosyalarına buraya bakarak erişilebilir çünkü kontrol dosyalarının yeri pfile ile elde edilir. Spfile'ı kullanarak içini açıp okuyabileceğimiz ve değiştirebileceğimiz pfile'lar oluşturabiliriz. Bu Oracle'a sysdba olarak bağlanıp
$> Create pfile from spfile
komutunu uygulamak ile sağlanır. Böylelikle init.ora dosyası oluşur ve içeriğini okumak mümkündür.
Mount: Bu adımda bir önceki adımdan elde edilen bilgiyle kontrol dosyasına erişilir. Açılan Instance, veritabanına ait bilgilere erişir. Bu adımda veritabanının kurtarma işlemleri gerçekleştirilebilir. Çünkü veri dosyası ve diğer fiziksel dosyaların yolları ve adlarına erişilmiştir. Bu dosyaların isimleri de değiştirilebilir. Oracle'da varsayılan olarak 2 kontrol dosyası vardır ve bunlar tamamen birbirinin aynısı olan iki dosyadır. Bu dosyaların ismi control01.ctl ve control02.ctl'dir. Her değişiklikte bu dosyaların back-up'ını almak bizim için avantajdır. Çünkü yapılan değişiklikler bu dosyalarda korunurlar. Burada fiziksel dosyaların path'leri tutulur. Bu aşamada herhangi bir SELECT sorgusu çalıştırılamaz. Zira veri dosyaları hala kapalıdır.
Open: Nihayet SELECT işlemlerinizi gerçekleştirebilirsiniz. Veri dosyaları artık erişilebilir konumdadır. Şunu da belirtelim ki veri dosyalarının uzantıları .dbf dir.
Görüldüğü gibi bu sistematik açılış ve kapanış mantığı Oracle'a ekstra güvenlik sağlar. Tüm bu bilgileri hazmettiysek artık RMAN'a geçebiliriz. Ancak şunu belirteyim ki RMAN bir iki yazıyla anlatılacak bir araç değildir. Aksine kitap olabilecek bir konudur ve bambaşka bir dünyadır. Fakat en çok kullanılan opsiyonlarını burada bize anlatıldığı şekliyle anlatacağım.
RMAN diğer adıyla Recovery Manager en başta sıraladığımız veri dosyası kaybı, veri bloğu arızası gibi durumlarda imdadımıza yetişen ve neredeyse konuşma diliyle karşılıklı muhabbet edilebilen bir araçtır.
Öncelikle veritabanımız arşiv modda mı değil mi bunu kontrol etmeliyiz:
SQL*PLUS açılır;
SQL> startup
komutu ile veritabanının 4 basamağı tırmanarak açılması sağlanır. SGA alanı tahsis edilerek prosesler devreye sokulur. Yani instance aktif hale gelir.
SQL> select log_mode, open_mode from v$database;
komutundan dönen değer NOARCHIVELOG ise arşiv mod kapalı demektir. Bunu açmak için veritabanını mount basamağında açmak gerekir.
Arşiv modunu açmamızın sebebini daha önceden açıkladık. Veritabanını mount olarak kullanmamız ise veritabanının arşivi bu moddayken alınır.
Bunun için iki dosya oluşturduk. Birisi arşivler için, diğeri de backup dosyaları için. Bu komutları işletim sistemine ait komut satırında yapmalısınız:
$> mkdir arc_Coshtan
$> mkdir back_Coshtan
gibi isimlerle dosya açılır. Daha sonra açtığımız bu dosyaya ait path'i kontrol dosyasına tanıtmamız gerekmektedir. Bunu da aşağıdaki komutla yaparız;
SQL> alter system set LOG_ARCHIEVE_DEST_1='Path'i buraya yazıyoruz' scope=both;
Daha sonra veritabanını kapatıp arşiv mod için aşağıdaki gibi açarız:
SQL> startup mount
SQL> alter database archievelog;
komutuyla veritabanını arşiv moda almış oluruz. Bu moddayken (mount) veri dosyalarına erişim olmadığını söylemiştik. Atılan bir SELECT sorgusu başarısızlıkla sonuçlanacaktır.
SQL> alter database open;
SQL> alter system switch logfile;
komutları ile oluşturduğumuz arc_Coshtan klasörü içerisinde artık log dosyalarının arşivi için bir dosya oluşturulur. Ayrıca bu dosyaya ait ikinci bir kopya da alınmış olur.
Böylelikle RMAN ile backup işlemlerini gerçekleştirmeye nihayet hazırız. Bu işlemlerden sonra RMAN'ın kullanımına yeni bir yazıda göz atacağız. Bu işlemler bir DBA'ın adı gibi bilmesi gereken ve işletim sistemi ile de alakalı olan (OEL) standart komutlardır. Bu yüzden herşeyden önce Linux komutlarını en azından temel seviyede bilmek yapılan işlemlere anlam vermeyi kolaylaştırır.
İyi çalışmalar!
Hiç yorum yok:
Yorum Gönder