Primary Olarak Aktif Edilmiş Standby Veritabanını, Flashback ile Geri Alma

Merhaba Arkadaşlar,

Primary veritabanımız ulaşılamaz duruma geldiğinde standby veritabanımızı primary olarak aktif edip hayatımıza devam etmek isteyebiliriz. Bu durumda mutlaka flashback database özelliğini enable yapıp yola devam etmek büyük fayda sağlayabilir.

Örneğin tam standby veritabanını primary olarak aktif ettiniz ve bu esnada da önceki primary veritabanındaki problem çözüldü ve açıldı. Yönetimde önceki primary veritabanı ile devam etme kararı aldığını varsayalım. Bu durumda aktif ettiğimiz standby veritabanını eski haline yani standby veritabanına geri çevirmemiz lazım. Bunun için flashback database özelliğini kullanacağız.

Önce aktif edilen standby veritabanında aşağıdaki sorgu ile standby ‘ın aktif edilme anındaki SCN numarasını öğrenelim;

SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

Aktif edilen standby veritabanını kapatıp mount modunda açalım. Ve yukarıdaki gibi öğrendiğimiz SCN numarasına flashback yapalım.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;

Aşağıdaki komutla primary olarak aktif edilen standby veritabanı tekrar standby veritabanına çevirelim.

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Redo transferini başlatmak için aşağıdaki kontrolleri yapalım.

Arşiv gönderilme hedefinin son durumuna aşağıdaki gibi bakalım.

SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

Bu arşiv hedefi enable değilse, aşağıdaki gibi enable yapalım.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;

Redo ‘nun başarılı iletilip iletilmediğinden emin olduktan sonra, Standby veritabanında redo apply işlemini aşağıdaki gibi başlatabiliriz.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Redo apply işlemi role geçişi esnasında oluşan redoya geldiğinde durabilir. Bu durumda paniklemeye gerek yok. Redo apply işlemini, standby ‘ın primary olarak aktif edilme anını geçene kadar bir kaç kere başlatmak gerekebilir.

Reklamlar

PHYSICAL STANDBY VERİTABANI SWITCHOVER & FAILOVER İŞLEMLERİ

SWITCHOVER:
 
Daha önce yazmış olduğum makalede RMAN ile aktif veritabanı üzerinden standby veritabanı kurulumunu örnek bir senaryo üzerinde incelemiştik. Bu yazımda, önceki makalemdeki senaryo üzerinden switchover nasıl yapıldığını anlatacağım.
 
Kısaca switchover, planlı rol değişimidir. Yani, canlı (primary) veritabanının standby rolüne, yedek (standby) veritabanının ise canlı (primary) rolüne geçmesidir. Yedek veritabanımızın çalışabilirliğini test etmek, canlı (primary) veritabanımızda bakım işleri yapmak, v.s gibi işler için switchover yapıyor olabiliriz. Switchover işlemi Enterprise manager, Data Guard Broker gibi GUI arayüzüyle yapılabildiği gibi sqlplus üzerinden de manuel yapılabilmektedir. Bu makalemde sqlplus üzerinden manuel switch yöntemini kullanacağım. İlerleyen yazılarımda Data Guard Broker, Enterprise manager üzerinden nasıl yapacağımızı da paylaşacağım. Aşağıda her işlem adımından önce komutları hangi sunucu üzerinde çalıştıracağımızı [sunucu] ismiyle sizlere hatırlatacağım.
 
1.   [istanbul] Canlı (primary) veritabanımızda tüm loglarımızın taşınması için logfile switch yapıyorum.

SQL>alter system switch logfile;

2.   [istanbul] Switchover yapmadan önce veritabanımızın switchover durumunu görelim.

SQL>select switchover_status from v$database;

“TO_STANDBY” şeklinde çıktı almamız gerekiyor.
3.   [istanbul] Şimdi canlı (primary) veritabanımızı standby veritabanı olarak switch edelim.

SQL>alter database commit to switchover to physical standby with session shutdown;

SQL>shutdown immediate;

SQL>startup nomount;

SQL>alter database mount standby database;

4.   [istanbul] Log larımızı apply için veritabanımızı bekletmemiz gerekiyor. Çünkü [baku] standby veritabanımızı henüz primary olarak set etmedik.

SQL>alter system set log_archive_dest_state_2=defer;

5.   [Baku] Standby veritabanımızı primary olarak switch edebiliriz. Switch etmeden önce switchover durumumuzu görelim.

SQL>select switchover_status from v$database;

“TO_PRIMARY” şeklinde çıktı almamız gerekiyor.

SQL>alter database commit to switchover to primary;

SQL>shutdown immediate;

SQL>startup;

Artık [Istanbul] sunucusu standby veritabanı, [Baku] sunucusu ise primary veritabanlarımızı barındırmaktadır.
6.   [Istanbul] Standby veritabanımızda real-time redo log appy işlemini başlatabiliriz.

SQL>recover managed standby database using current logfile disconnect;

Son olarak veritabanımızı “Read Only with Apply” olarak açalım. Böylelikle rapor kullanıcılarımız redo apply esnasında sorgulama yapabileceklerdir.

SQL>recover managed standby database cancel;

SQL>alter database open;

SQL>recover managed standby database using current logfile disconnect;

FAILOVER:
Kısaca failover, canlı (primary) veritabanının bozulması durumunda yede (standby) veritabanının primary olarak aktif edilmesidir. Geri dönüşü yoktur. Aktif edildiğinde, standby veritabanı yeniden oluşturmalıdır. Failover durumunda yapılması gerekenler:
(Önemli hatırlatma: Istanbul primary sunucu, Baku ise standby sunucudur)
1.   [Istanbul] Eğer primary veritabanına ulaşılabilir durumda ve çalışıyorsa, redo buffer standby veritabanına gönderilmesi sağlanır ve son arşivler oluşturulur.

SQL> alter system flush redo to standby_db_name;

SQL>alter system archive log current;

Hata alınmaz ise 5. Adım ile devam edebilirsiniz. Bu durumda sıfır veri kaybı ile sistem açılabilir. Hata alırsanız, en az veri kaybı ile sistemimizi açabilmek için 2. Adım ile devam ediyoruz.
2.   [Baku] Standby veritabanımızda aşağıdaki sorguyu çalıştırarak apply edilen son arşiv sıra numarasını redo thread numarsına göre öğrenmemiz gerekiyor.

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

3.   [Istanbul’dan Baku’ye] Eğer arşiv loglara ulaşılabiliyorsa, copyalanmamış logları standby veritabanına kopyala. Kopyalama işleminden sonra arşiv log dosyaları standby veritabanına aşağıdaki gibi register edilmelidir. Bu işlem her thread için uygulanmalıdır.

SQL> alter database register physical logfile '/oracle/ora11g/dbs/arch/ TALIP_991834413_1_102.arc ';

4.   [Baku] Standby veritabanında redo gap olup olmadığı kontrol edilmelidir. Varsa ilgili arşiv log dosyaları primary sunucudan standby sunucuya kopyalanıp register edilmelidir.

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

SQL> alter database register physical logfile '/oracle/ora11g/dbs/arch/ TALIP_991834413_1_101.arc ';

Yukarıdaki sorgu sonucu sıfır dönene kadar 4. Adımdaki log taşıma ve register etme işlemi yapılmalıdır.
5.   [Baku] Standby veritabanında redo apply işlemi durdurulur.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

6.   [Baku] Primary den kopyaladığımız bütün arşivlerin apply edilmesi sona erdirilir.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

Hata alacak olursanız, apply edilmemiş redolarınız var demektir. 2 ve 4. Adımları tekrar gözden geçirmek gerekecektir. Yinede redo kaybını göze alıp devam etmek isterseniz;

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

Bu durumda veritabanınızı 8. Adımdaki gibi direk açabilirsiniz. Hata almazsanız 7. Adımla devam edebilirsiniz.
7.   [Baku] Standby veritabanı, primary veritabanı olarak switch edilir.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

8.   [Baku] Veritabanı açılır.

SQL> ALTER DATABASE OPEN;

Failover ile Standby veritabanı primary olarak açıldığında mutlaka full yedek alınmalıdır. Ve en kısa sürede yeni bir sunucuyu standby veritabanı olarak konfigüre etmeniz gerekir. Unutmayın verilerimiz bizim için çok kıymetlidir 🙂

Talip Hakan Öztürk

DATA GUARD Hakkında kısa kısa merak ettiklerimiz

Merhaba Arkadaşlar,

Bu makalemde Oracle ın felaket kurtarma (disaster recovery) çözümü olan Data Guard temel terminolojisi hakkında kısa kısa bilgi vereceğim.

Öncelikle Felaket(Disaster) kelimesini anlamaya çalışalım. Televizyon, radio, gazete v.s. medya aracılığı ile dünyanın bir çok yerinde bazı felaketlerin meydana geldiğini hepimiz görmekteyiz. Endonezyadaki tsunami, Amerikadaki kasırga ve hortumlar, yakın geçmişte yaşadığımız 1999 depremi bunlardan bazılarıdır. İşte bu gibi olaylara felaket (disaster), diğer bir söylemle afet diyoruz. Doğal afetler sonucu veri merkezimizi (datacenter) kaybedecek olursak, bunun bize olan bedeli eminim ki çok ağır olacaktır. Verilerimiz bizim için çok değerlidir hatta şirketimizin hazinesidir diyebiliriz. Sadece doğal afetler değil, anlık elektrik kesintisi, disk arızaları ve kullanıcı hataları gibi olaylarda verilerimizi kaybetmeye sebebiyet verebilmektedir.

Bizler veri yöneticileri olarak tüm bu felaketler oluşmadan gerekli aksiyonları almakla yükümlüyüz. Gerekli aksiyonları alırken de göz önünde bulundurmamız gereken önemli bileşenler vardır. Bu bileşenler;

RPO (Recovery Point Objective) – Ne kadar veri kaybetmeyi göze alabilirsiniz?

RTO (Recovery Time Objective) – Veri erişimi olmadan kaç dakika ayakta durabilirsiniz ?

Bu sorulara vereceğimiz mantıklık cevaplara göre hızlıca yedek sistemimizi kuruyor olmalıyız. Sistemimizi sadece kurmakla yetinmeyip, canlı verilerimizle yedek sistemimizi besmeli ve bu beslemeyide sıkı takip ediyor olmalıyız.

Şimdi ORACLE ın bu konudaki güzel çözümü Data Guard ı tanıyalım.

Data Guard ORACLE ın felaket kurtarma (disaster recovery) çözümüdür. Canlı (production) veritabanınızı felaketlerden korur, üzerindeki iş yükünü azaltır ve daha efektif kullanılmasını sağlar. Teknoloji,  ilk olarak Oracle 7 ile manuel standby veritabanı oluştururarak kullanılmaya başlandı. Oracle 8i ile Data Guard olarak karşımıza çıktı. Geçmişten günümüze Data Guard a gelen özellikeleri inceleyecek olursak; 

 ORACLE 8i

 Read-Only Standby Veritabanı

 Managed recovery

 Redo Log dosyalarını Uzak(Remote) arşivlenmesi

 ORALCE 9i

 “Zero Data Loss” Entegrasyonu

 Data Guard Broker ve Data Guard Manager GUI

 Swithcover ve Failover işlemleri

 Otomatik senkronizasyon

 Logical Standby Veritabanı

 Maximum Protection

 ORACLE 10g

 Real-Time Apply

 RAC için güçlendirilmiş destek

 Fast-Start Failover

 Asenkron redo transferi

 Data Guard switchover karşı Flashback Database

 ORACLE 11g

 Active Standby Veritabanı(Active Data Guard)

 Snapshot Standby

 Heterojen platform desteği (Production –Linux, Standby – Windows)

 Özellikleri ile zaman içinde gelişerek bugünkü halini almıştır. Bugün 11g ile sağladığı özellikler bakımından DBA lerin vazgeçemediği bir sistemdir.

 DATA GUARD 11g PROCESS MİMARİSİ SENKRON REDO TRANSFERİ (SYNC)-SIFIR VERİ KAYBI (ZERO DATA LOSS)

İşlem akışı kısaca;

1 – Kullanıcı bir transaction başlatır. Bu transaction redo buffer a yazılır. Kullanıcı transaction ı commit ettiğinde LGWR process Redo Log dosyaya yazar

2 –  LNS (LogWriter Network Service) commitlenmiş redoyu RFS (Remote File Service) bildirir. RFS standby redo log dosyaya yazar. Physical standby kullanıyorsak MRP (Managed Recovery Process) standby veritabanına apply eder. Logical Standby kullanıyorsak bu işlemi LSP (Logical Standby Process) yapar.

3 – RFS verinin başarılı işlendiği bilgisini LNS e gönderir. LNS bu bilgiyi LGWR a aktarır. Son olarak kullanıcıya başlatmış olduğu işlemin (transaction) commit edildiği bilgisi gönderilir.

Senkron redo transferi ile veri transferi garanti altına alınır. Ama bir dezavatajı vardır. canlı veritabanı (Primary) ile yedek veritabanı (Standby) arasında bir network kesintisi oluşursa veya bir şekilde Primary veritabanı standby veritabanına erişemezse, primary veritabanı standby veritabanı cevap verene kadar hang olur. Yani hizmet veremez duruma düşer. Böyle bir durum oluşmaması için “NET_TIMEOUT” parametresi kullanılması bence en mantıklı olanıdır. Bu parametre ile timeout süresi belirleyebiliriz. Kesinti durumunda primary timeout süresi kadar bekler ve bu süre dolduğunda hizmet vermeye devam eder. Data Guard 10g de bu parametre varsayılan 180 sn iken, Data Guard 11g de varsayılan 30 sndir.

DATA GUARD 11g PROCESS MİMARİSİ ASENKRON REDO TRANSFERİ (ASYNC)

Asenkron redo transferinde işlem akışı;

1 – Kullanıcı bir işlem (transaction) başlatır. Bu transaction redo buffer a yazılır. Kullanıcı transaction ı commit ettiğinde LGWR process Redo Log dosyaya yazar.

2 – LNS (LogWriter Network Service) commit edilmiş redoyu RFS (Remote File Service) bildirir. RFS standby redo log dosyaya yazar. Physical standby kullanıyorsak MRP (Managed Recovery Process) standby veritabanına apply eder. Logical Standby kullanıyorsak bu işlemi LSP (Logical Standby Process) yapar.

3 – Redo Buffer bir şekilde recycle edilirse LNS otomatik olarak redo log dosyalarını okur ve redoları buradan göndermeye başlar.

RFS verinin başarılı işlendiği (commit) hakkında LNS e geri bildirimde bulunmaz.

En çok kullanılan process mimarisidir. Asenkron redo transferi sıfır veri kaybını garanti altına almaz. Sistem en az veri kaybı ile kurtarılabilir durumdadır.

DATA GUARD KORUMAN(PROTECTION) MODLARI

3 koruma (protection) modu vardır. Aşağıdaki tablo ile özetleyebiliriz.

Mode Veri kaybı riski Transfer şekli Primary durumu
Maximum Protection Sıfır veri kaybı – İki taraflı koruma SYNC Verinin ulaştığı bilgisi beklenir,cevap gelmezse primary hang olur
Maximum Availability Sıfır veri kaybı – Tek taraflı koruma SYNC Verinin ulaştığı bilgisi beklenir,cevap gelmezse primary timeout parametresi kadar bekler. (NET_TIMEOUT)
Maximum Performance En az veri kaybı ASYNC primary hiçbirzaman verinin ulaştığına dair bilgi beklemez

 PHYSICAL STANDBY – REDO APPLY

Physical Standby Database, canlı (primary) veritabanının blok-blok  kopyasıdır. Değişiklikleri uygulamak için Veritabanı Kurtarma Fonksiyonunu kullanır. Redo Apply aktifken, raporlama ve sorgu için read-only modda açılabilir(Active Data Guard -11g ile gelen bir özellik). Canlı (Primary) veritabanına ekstra yük bindirmemek için backup işlemlerinde kullanılabilir. Read-Write modda açılabilmesi için veritabanını flashbacklog modu açık olmalıdır. Flashbacklog aktif edildikten sonra restore point oluşturularak read-write modda açılabilir. Ve tekrar restore pointe geri dönülerek standby olarak çalışması sağlanabilmektedir. Yukarıda açıklamış olduğum modlardan istenilen bir tanesi ile redo transferi yapılabilir.  Bir sonraki yazacağım makalede RMAN ile aktif veritabanı üzerinden physical standby veritabanı kurulumunu detaylı olarak sizlere anlatıyor olacağım.

İsteğe bağlı olarak primary veritabanından standby veritabanına taşınan redo kayıtları gecikmeli olarak stanby veritabanına uygulanabilir. Mesela standby veritabanımızın 2 saat arkadan gelmesini sağlayabiliriz. Böylelikle canlı (primary) veritabanımızda 2 saat içinde meydana gelebilecek kullanıcı hatalarını standby veritabanımızdan çok hızlı bir şekilde kurtarabiliriz. Gecikmeli apply aktif edildiğinde real-time apply doğal olarak devre dışı kalacaktır. Real-time apply aşağıdaki gibi aktif edilebilir.

SQL>alter database recover managed standby database using current logfile disconnect;

Redolar yukarıdaki şekilde olduğu gibi direk standby redo log dosyasından okunarak MRP veya LSP prosesine bildirilir. Gecikmeli apply ise aşağıdaki gibi aktif edilebilir. Ve redolar arşiv log dosyalarından okunarak MRP veya LSP prosesine bildirilir.

SQL> alter database recover managed standby database delay 10;

 SNAPSHOT STANDBY(11g)

Read-write modda açılabilen ve tekrar physical standby veritabanına dönüştürülebilinen standby veritabanıdır. 11g ile aramıza katılmıştır ve oldukça kulanışlıdır. Snapshot standby aktif edildiğinde redo apply durdurulur ve arşiv log olarak yedeklenir. Physical standby a geri dönüldüğünde apply kaldığı yerden arşiv log dosyalarını apply ederek devam eder. Read-write modda açılarak test, patch, v.s gibi işlemler test edilebilir.

 LOGICAL STANDBY – SQL APPLY

 Logical Standby veritabanı  açık, aktif ve bağımsız olan bir veritabanıdır. Canlı (Primary) veritabanı ile aynı mantıksal bilgilere (row) sahiptir. Redo verileri SQL olarak apply edilirken raporlama amaçlıda kullanılabilir. Veritabanı read-write modda açık olabilir. Primary veritabanından replica olan tablolarda değişikliklere izin vermez. Logical standby veritabanının bazı kısıtlamaları vardır. LONG, LONG RAW, BFILE, ROWID, kullanıcı tanımlı tippler (user-defined types) veri tipli tablolar üzerinde yapılan işlemler apply edilememektedir. Desteklenmeyen tabloları görmek için aşağıdaki sorguları çalıştırabilirsiniz.

 select * from DBA_LOGSTDBY_UNSUPPORTED;

 select * from LOGSTDBY_UNSUPPORTED_TABLES;

 ACTIVE DATA GUARD (11g)

11g ile gelen bu özellik sayesinde redo apply edilirken standby veritabanı read-only modda açık olabilmektedir (Read-Only with Apply). Bundan dolayı Active Standby Veritabanı adı verilmiştir. Active data guard ın bize sağladığı avantajlar açısından bakacak olursak; Real-time raporlama (redo apply devam ederken), yedek alma gibi işlemlerimizi active standby veritabanı üzerinden yapabilir durumdayız. Böylelikle Canlı(production) veritabanımız üzerindeki raporlama,yedek alma gibi işlem yükünü azaltmış olacağız. Canlı veritabanımız müşterilerimize daha efektif olarak hizmet verecektir.

11g R2 ile gelen diğer bir güzelliğide sizlerle paylaşmadan yapamayacağım 🙂 g R2 öncesine kadar canlı (primary) veritabanımızın aynı anda maksimum 9 standby veritabanı olabilmekteydi. Bu rakam 11g R2 ile 32 ye çıkarılmıştır. Yukarıdaki şeklimize göre canlı veritabanımız 4 standby veritabanına real-time redo apply edebilmekte ve aynı anda rapor kullanıcılarımız real-time raporlama yapabilmektedirler. 

SWITCHOVER  & FAILOVER

Son olarak  Switchover ve Failover terimlerinden kısaca bahsetmek istiyorum. Switchover, planlı role değişimidir.  Yani canlı (primary) veritabanının standby olarak, standby veritabanının ise primary olarak hizmet vermesidir. Tekrar yeni bir veritabanı kurulumu gerektirmez. OS ve hardware bakımı, standby veritabanının çalışabilirliğini test etmek için kullanılabilir. Failover ise manuel olarak SQL ile veya basit bir GUI arayüzüyle (Data Guard Broker, Enterprise Manager) aktifleşebilen, canlı (Primary) veritabanının plansız bozulmasıdır. Böyle bir durumda standby veritabanının yeniden oluşturulması gerekir. Switchover için yapılması gereken işlem adımlarını ilerleyen makalelerimde sizlere anlatıyor olacağım.

 Resimler için kullandığım kaynaklar:

http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/toc.htm

Oracle Data Guard 11g Handbook – Charles Kim

Talip Hakan Öztürk