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

 

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.

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.

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.

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.

Yorum Yapabilmek İçin Üye Girişi Yapmanız Gerekmektedir.

data guard hakkında kısa kısa merak ettiklerimiz