Bu yazımızda oracle yedekleme ve kurtarma yapabilemk için bilinmesi gereken temel bilgiler, kavramlar, terimler üzerinde duracağız.Böylelikle yedekleme ve kurtarmanın mantığının daha iyi anlaşılacağını düşünüyorum.
Yedekleme ve kurtarma senaryoları oluşturma, veritababının düzenli yedeklerinin alınması ve olası bir hata karşısında kurtarma yapabilme bir dba' nın temel görevlerindendir.Burda önemli olan tabiki bu işleri yapabilmekten ziyade veritabanının gereken en kısa zamanda tekrar ayağa kaldırılması önemlidir.Mesela banka yada Telekom gibi sektörlerde ki bir veritabanı için bu süre bazen 1 dk. bile olsa kabul edilemezdir.Hiç hata almaz mı? Tabiki alabilir ancak kesintisiz servis ayrı bir uzmanlıktır ve ilerleyen yazılarımızda açıklamaya çalışacağız.Şimdi yedeklem ve kurtarma temelleri nelerdir açıklamaya çalışalım.
Öncelikle ne için yedekleme yapıyoruz yada ne zaman ve neölçüde kurtarma yapmalıyız sorusuna karşılaşabileceğimiz hata tiplerini açıklamakla başlayabiliriz.
· Statement Failure :DML ve DDL queryleri çalışırken alınana hatadır.
· User proces Failure : Bir sessiona yada kullnıcıya dair alınan hatadır.
· Network Failure: Database erişiminin kesilnmesidir.
· User Error: Kullnıcının mesela tablo silmek gibi bir işlemi başarı ile tamamladığı halde işlmein hatalı sayılmasıdır.
· Instance Failure :Database instance nin beklenmedik bir anda kapanması gibi sıradışı instance hatalarıdır.
· Media Failure:DAta file lerden bir yada daha fazlasının kullanılamaz hale gelmesidir.
Şimdi bu hata tiplerine ait muhtemel problemler ve çözümleri hakkında açıklamalar yapalım.
Statement Failure
Tablo 1 de statement failure hakkında olası problemler ve çözümleri listelenmiştir.
Genel Failure Tipleri | Muhtemel Çözümler |
Tabloya hatalı veri girilmesi | Tablo özellikleri incelenmeli ve doğru data seçilmelidir. |
Yetkiler Yetersiz | Yapılan işlem uygunsa gereken yetki verilmeldir. |
Yer Hatası | Kullnıcıya kota sınırı artırılmalı veya yer eklenmeli veya kullanıcıya ilgili yetki verilmelidir. |
Uygulamadaki mantık hatası | Mantık hataları analizi için LogMiner(EM>Availability>View and Manage Transactions) kullanılabilir.Developer ile birlikte çözüm aranmalıdır |
Tablo 1 : Statement Failure Tipleri ve Çözümleri
User Process Failure
Tablo 2 de Kullnıcı işlemlerindeki hatalara değinilmiştir.
Genel Failure Tipleri | Muhtemel Çözümler |
Kullanıcının bağlantısının anormal bir şekilde kopması | İlgili Durumlarda Dba için bir kurtarma genelde söz konusu deildir. |
Kullanıcının bağlantısın anormal bir şekilde sonlandırılması | Çünkü İnstance commitlenmemeiş verileri |
Kullanıcının kullandığı başya programlardan solayı bağlantısının sonlanması | bu gibi durumlardarolback yapar. |
Tablo 2: User Process Failure tipleri ve olası çözümleri
Network Failure
Tablo 3 de Network failure genel problemeleri ve olası çözümler belirtilmiştir.
Genel Failure Tipleri | Muhtemel Çözümler |
Listener fail olma durumu | Listener 'a ait backup oluşturulmalı, gerekirse işleme konulmaldır. |
Network İnterface Card | Birden çok Network card kullanılması doğru olnadır. |
Network bağlantı hatası | Network bağlantısına ait gerekli backuplar alınmalıdır. |
Tablo 3: Network failure tipleri ve olası çözümler
User Error
Tablo 4 de Kullanıcı hataları ve muhtemel çözümlerinden bahsedilmiştir.
Genel Failure Tipleri | Muhtemel Çözümler |
Kullanıcının sildiği yada değiştirdiği data | Eğer commitlenmemişse rollback yapılabilir. |
Tablo silinmesi | Tablo recycle bin içerisinden geri alınabilir.Ağer recycle bin temizlenmiş ise tablo pint-in-time-recovery (PITR) kullanılarak geri alınabilir ancak oracle'ınbuna uygun şekilde configurasyonu gereklidir. |
Tablo 4 : Kullanıcı hataları ve muhtemel çözümleri
Genel belli bir kısım datayı geri getirmek yada silinen tabloları geri getirmek için Flashback teknolojisi kullanılır.Flashback Teknolojisi silinmiş yada herhangi bir sebepler değiştirilmiş ve commitlenmiş verilerin geçmiş durumunu izlemek ve geri getirmek için kullanılır.Flashback teknolojisinin kullanım alanları aşağıda basitçe sıralanmıştır.Flashback kullanımı hakkında daha detaylı yazımızı ilerde yazacağız ancak şimdilik konsept olarak açıklama yapalım.
Flashback Query:Commitleniş bir datanın geçmiş durmunu AS OF kelimleri ile select query yazıp SCN numarasına göre yada timestamp noktasına göre izlemek ve bu datayı insert select metodu ile geri getirmektir.
Flashback Version Query;Belli bir zaman aralığı verilerek commitlenmiş verinin değişimi incelenebilir.
Flashback Transaction Query; FLASHBACK_TRANSACTION_QUERY tablosunda tutulan transaction bilgilerinden yola çıkılarak istenmeyen değişikler geri alınabilir.
Flashback Transactio backout;Flashback transaction backout ile bir transaction sonucunda istenirse bu transaction öncesine data geri döndüüreliebilir.Ancak bu özelliğin kullanılabilmesi için aşağıdaki ayarların daha önce yapılmış olması gerekir.
ALTER DATABASE add supplemental log data;
ALTER DATABASE add supplemental log data (primary key) columns;
Flashback Table: Bir tablo daha önceki bir tarihine yada SCN denilen system change number değerine döndürelebilir.
Flashbach Drop:Db objelerini drop edildikten sonra recycle bin den geri alabilirisiniz. Instance Failure Tablo 5 de instance hataları ve muhtemel çözümlerinden bahsedilmiştir.Genel Failure Tipleri | Muhtemel Çözümler |
Güç Kesintisi | İnstance startup komutu ile tekrar açılır.Bu işlem sırasında instance recover otomatik olarak yapılır ve aynı zamanda redologlardaki değişimler korunur ve commitlenmemiş değişiklikler roll back yapılır.Hata alert log ve trace den incelenir. |
Donanım Hatası | |
Backgroud proces hatası | |
Acil kapatılma işlemi |
Tablo 5 : Instance hataları ve muhtemel çözümleri Tablodan görüleceği üzere instance recovery işlemi restart sırasında otoamtik olarak yapılır.Peki oracle instance recovery işlemini nasıl otomatik olarak yapar. 1-Checkpoint Process:Checkpoint işlemi aslında oracle taraından her 3 sn de bir yada daha sık olarak database writer işlemi tarafından SGA dana diske yazdırılan değişien block ların bilgisinin kontrol file içinde depolanması dır.Checkpoint işleminin amacı instance recover işleminin başalatılacağı redolog file ların içindeki konumu belirlemektir.Buna Checkpoint Poisition denir. Ayrıca checkpoint işlemi log switch olayında checkpoint bilgilerini data filelerin header kısmına yazar.Checkpoint işlemi aşağıdaki sebeplere bağlı olarak yapılır.· Değişen data blockların memory den diske düzenli bir biçimde yazıldığından emin olmak için, Böylece instance yada database hatası meydan gelirse data kaybı önlenmiş olur.
· Instance recovery (instance kurtarma) işlemi için için gerekli olan zaman azaltılmış olur.
· Shutdown işlemi sırasında commitlenmiş tüm verilerin diske yazıldığından emin olmak için.
Özetle checkpoint bilgleri checkpoint process tarafından kontrol filelerin içerisine yazılır.Çünkü oracle başlatıldığından kontrol filelerden gerekli bilgileri okur.Ayrıca checkpoint işlemlerinin önemli içeriklerini özetlemek gerekirse;,SCN number(System change number), recover işleminin başlatılacağı redo log filelerin içerisindeki konum, log bilgileri.2-Redo log file ve log writer;Şekil 1 de redo log file ve log file arasındaki ilişki sembolize edilmiştir.Redolog file değişimleri database için kaydeder ve sayısı ve boyutu kayıp riskini azaltmak için çoklanabilir.Log writer ise Redolog buffer alanı adı verilen memory parçasındaki dataları redolog dosyalarına yazar.
Log writer;o redolog gruplarından biri dolduğunda,
o commit sırasında,
o Database writerdan önce
o ve yada her 3 saniyede bir çalışır.
**Mümkünse herbir redolog group farklı disk üzerinde depolanması yerinde olur.  |
Şekil 1 : Redo-log dosyaları ve logwriter |
Instance kurtarma işlemi adım adım ve sembolize olarak şekil 2 de gösterilmiştir. |
Şekil 2 : instance recover (kurtarma) adımları |
Instance Recovery Tuning Instance kurtarma işleminin hızlandırılması için checkpoint position ile redolog dosyasının son konumu arasındaki farkın azaltılması gerekmektedir.Bu fark şekil 3 de sembolize edilmiştir.Bu farkın azaltılması MTTR (Mean Time To Recover) ayarının dba tarafından yapılması gerekir.Bu ayar redo log dosyalarının boyutları ilede alakalıdır.Örneğin 2 redo log gurubu için aradaki farkın en küçük redolog gurubun %90 'ınından daha büyük olmamalıdır.MTTR ayarı MTTR advisor dan yardım alınarak da yapılabilir. |
Şekil 3 : Instance recovery Tuning |
Media Failure Oracle tarafından tanımlanan media failure, veri kayıplarına neden olabilecek her türlü hata tipidir.Media failure tipleri ve muhtemel çözümler tablo 6 da listelenmiştir. Genel Failure Tipleri | Muhtemel Çözümler |
Disklerin bozulması | 1.Etkilenen dosya backupdan yüklenir.2.Eğer gerekli ise yeni veri dosyaları için başka bir konum belirlenir. 3.Eğer gerekli ise redo log bilgilerinden dosya kurtarılır. |
Disk kontrol ünitelerinin bozulması | |
Database dosyalarının silinmesi yada bozulması |
Tablo 6: Media Bozuklukları ve genel çözümleri Oracle yedekleme ve kurtarma içeriği hakkında belli bir sınıflandırma yaparak hata tiplerini açıklamaya çalışıp çözümlerinide tablo şeklinde sembolize ettik.Hata ne olursa olsun önemli olan veri kaybetmeden en kısa zamandan kurtarma işleminin yapılmasıdır.Bu amaca uygun olarak oracle veritabanı konfigürasyonu sağlanabilir.· Düzenli backupların alınması,
· Control File dosyalarının çoklanması,
· Redolog dosyalarının çoklanması,
· Redolog dosyalarının arşiv kopyalarının bulundurulması.
Control File dosyalarının çoklanması; Cotrol file dosyaları veritabanının durumunun saklandığı ve açılması yada veri dosyalarının mount edilmesi gibi olaylarda ulaşılabilir olması gerekir.Eğer bir control file bozulmuşsa yenisinin oluşturulması gerekir.Control file dosyalarından biri kopyalanarak control bile ler çoklanmış olur.Bu işlem aşağıdaki gibi yapılabilir. Benim kendi sanal makinamda kurulu oracle için baktığımda bir adet kontrol file bulunmaktadır.Control file dosyaları default olarak oradata klasöründedir. [oracle@vmora vmora]$ ls -ltrhtotal 1.5G-rw-r----- 1 oracle oinstall 21M Sep 6 15:02 temp01.dbf-rw-r----- 1 oracle oinstall 5.1M Sep 6 15:28 users01.dbf-rw-r----- 1 oracle oinstall 51M Sep 6 15:28 undotbs01.dbf-rw-r----- 1 oracle oinstall 681M Sep 6 15:28 system01.dbf-rw-r----- 1 oracle oinstall 501M Sep 6 15:28 sysaux01.dbf-rw-r----- 1 oracle oinstall 51M Sep 6 15:28 redo02.log-rw-r----- 1 oracle oinstall 51M Sep 6 15:28 redo01.log-rw-r----- 1 oracle oinstall 101M Sep 6 15:28 example01.dbf-rw-r----- 1 oracle oinstall 9.3M Sep 6 15:32 control01.ctl-rw-r----- 1 oracle oinstall 51M Sep 6 15:32 redo03.log Görüldüğü üzere aynı klasörde birçok datafile lar var.Biz burada konumuz itibarı ile control fileler ve redolog fileler ile ilgileneceğiz.Kontrol fileler çoğaltmak için aşağıdaki prosedür uygulanabilir. 1-System'e eklenecek control filelerin tutulacağı konum spfile içerisine yazılır. alter system set control_files =
'/oracle/oradata/vmora/control01.ctl',
'/oracle/oradata/vmora/control02.ctl',
'/oracle/oradata/vmora/control03.ctl' SCOPE=SPFILE;
2-Oracle Shutdown edilir.SQL> shutdown immediate;Database closed.Database dismounted.ORACLE instance shut down.3-İşletim sistem üzerinden varolan control file dosyası kopyalanarak çoğullanır.[oracle@vmora vmora]$ cp control01.ctl control02.ctl[oracle@vmora vmora]$ cp control01.ctl control03.ctl4-Veritabanı açılır ve işlem tamamlanmış olur.SQL> startupORACLE instance started.Total System Global Area 849530880 bytesFixed Size 1339824 bytesVariable Size 499125840 bytesDatabase Buffers 343932928 bytesRedo Buffers 5132288 bytesDatabase mounted.Database opened.Eklenen dosyaları V$CONTROLFILE Viewdan takip edebilirsiniz.RedoLog File dosyalarının çoklanması; Redolog file dosyaları hakkında daha öncede bahsettiğimiz gibi commitlenen veriler diske yazılmadan önce redolog dosyalarına yazılır.Bunun en önemli sebebi performanstır.Çünkü diske yazmak seri logdosyalarıbna yazmaktan çok daha maliyetli ve zaman alan bir işlemdir.Ancak redolog dosyalarının bulunduğu redolog guruplarından kurtarma açısından optimal durumu farklı diskler üzerine olması ve herbir gurupta en az 2 adet redolog member (redolog dosyası) olmasıdır. Redolog gurupları yada dosyaları enterprise manager üzerinde server>storage>redolog groups tabında yapılabileceği gibi script ilede yapılabilir. Redolog group eklemek için;ALTER DATABASE ADD LOGFILE GROUP 4 ( '/oracle/oradata/vmora/redo4.log') SIZE 51200K;
Redolog gruba member eklemek için;ALTER DATABASE ADD LOGFILE MEMBER '/oracle/oradata/vmora/redo4_1.log' TO GROUP 4;
Eklenen yeni redo dosyasının durumuna V$LOGFILE dan kontrol ettiğinizde invalid olarak görürsünüz.Bunun sebebi henuz eklenmiş olan redolog dosyasına veri yazılamamış olamsıdır.Eğer log switch olayı meydana gelir ve log dosyası kullanılmaya başlanırsa Durmunun diğerleri null konumuna çekildiğini farkedeceksiniz. Archive Log Dosyaları; Archive Log dosyaları, pasif konumda olan redolog dosyalarının kopyalanması olarak nitelendirilebilir.Bir veritabanı eğer NOARCHIVELOG modda çalışıyorsa redolog do syaları arşivlenmez.Redolog dosyalarının kopyalanması için veritabanının ARCHIVELOG modda çalışıyor olması gerekir.Redolog dosyalarına online log dosyaları da denir.Online log dosyalarınını kopyalayan yani archive log dosyaları yapan oracle background process'e archive process (ARCHn) denir.Şekil 4 de archive process sembolize edilmiştir.Archiver process opsiyoneldir.Yani devre dışı bırakılabilir.Ama maximum derecede kurtarılabilir bir veritabanı modeli istiyorsanız veritabanı archive modda çalışmalıdır. |
Şekil 4 : Archiver process |
Eğer online log gruplarından biri dolarsa oracle instance diğer log gurubuna yazma işlemini başlatır.Bu olaya log switch denir.İşte archiver process herbir log switch olayında devreye girer ve dolmuş olan online log dosyasının kopyalanmasını sağlar.Bu sayede eğer disk zarar görürse aynı noktada kurtarma işlemi başlatılabilir.Eğer veritabanı archive log modda çalışmıyorsa dolan log gurupları tekrar kullanılmaya başlatıldığında üzerindeki bilgiler yani yazılan bilgiler için ezilir.Ancak archive alınırsa dolan log gurupları kopyalandığı için redolog dosyalarındaki bilgilerin kaybedilmesi gibi bir risk ortadan kalkmış olur. Arşiv log dosyaları aşağıdaki gibi isimlendirme yapılabilir. %s:dosyaya ait log sequence numarası. %t: " threat numarası. %r: " reset log ID (herbir arşiv log isminin uniq olması için). %d: " database ID. Archive dosyalarının yazılacağı default directory DB_RECOVERY_FILE_DEST dir.Ancak bu değiştirilebilir.Değiştirmek için Enterprise Manager > Availability > Recovery settings kısmından yada init.ora dosyasındaki DB_RECOVERY_FILE_DEST parametresini değiştirerek değiştrebilirsiniz.Yada aşağıdaki komut ilede bu işlem yapılabilir.ALTER SYSTEM SET DB_RECOVERY_FILE_DEST ='/oracle/flash_recovery_area' SCOPE = SPFILE;
Oracle Archive log moda nasıl alınır? Oracle veritabanını archive log moda yanlızca mount konumunda açarak alabiliriz.Bunun için aşağıdaki adımları izlemeliyiz.SQL> archive log list;Database log mode No Archive ModeAutomatic archival DisabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 8Current log sequence 10SQL> shutdown immediate;
Database closed.Database dismounted.ORACLE instance shut down.SQL> startup mount;ORACLE instance started.Total System Global Area 849530880 bytesFixed Size 1339824 bytesVariable Size 520097360 bytesDatabase Buffers 322961408 bytesRedo Buffers 5132288 bytesDatabase mounted.SQL> alter database ARCHIVELOG;Database altered.SQL> alter database open;Database altered.SQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 8Next log sequence to archive 10Current log sequence 10 Bu yazımızın sonuna geldik.Özetle bu yazımızda oracle yedekleme ve kurtarma hakkında bilgiler ve açıklamalar sunmaya çalıştık.Bu sayede yedekleme ve kurtarma sırasında çalışan processler ve oracle bizlere neler sunar açıklamaya çalışıp, konu konseptini yazmaya çalıştık.Sonraki yazılarımızda yedekleme ve kurtarma nasıl yapılır ve RMAN hakkında bilgiler sunmaya çalışacağız.Faydalı olmasını dilerim. Özcan YILDIRIM
0 YORUM:
Yorum Gönder
"Sorularınız ve Eleştirileriniz Değerlidir"