ORACLE DATA GUARD MİMARİSİ

Herkese merhaba,

Bu yazımda Oracle Data Guard teknolojisinin mimarisini anlatmaya çalıştım.

Keyifli okumalar dilerim.

Oracle Data Guard Mimarisi

• Oracle Data Guard, Felaket Kurtarma (Disaster Recovery) durumlarında iş kritik veritabanlarında en iyi veri koruma ve veri sürekliliği sağlayan felaket kurtarma çözümüdür.
• Disaster Recovery çözümlerini uygularken şu iki bileşeni göz önünde bulundurmamız gerekiyor.

RPO (Recovery Point Objective) — Ne kadar veri kaybetmeyi göze alabiliriz?

RTO (Recovery Time Objective) — Veri erişimi olmadan ne kadar süre ayakta durabiliriz?

• Data Guard, Canlı (Primary) veritabanında oluşan redo verilerini yedek (standby) veritabanına taşır ve taşınan redo verilerini apply eder.
• Data Guard, sadece redo veri transferi yapmaz. Aynı zamanda taşınan redo verisini standby veritabanına apply etmeden önce blok bozulmasına karşı kontrol eder.
• Redo kayıtları, veritabanına yapılan değişiklikleri tekrar oluşturmak için gerekli bütün bilgileri içerir.
• Redo kayıtları ilk olarak bellek üzerinde SGA alanında bulunan redo log buffer alanına yazılır.
• Üretilen bu redo kayıtları LGWR background process’i ile redo log buffer alanından sıralı olarak disk üzerindeki online redo log dosyalarına yazılır.
• Böylelikle LGWR background process’i üretilen her redo verisini bize geri döndürmeyi garanti altına alır.
• Data Guard çalışma yapısı basit olarak aşağıdaki görsel üzerinden anlaşılabilir.

Oracle Data Guard Yapısı

REDO TAŞIMA SERVİSLERİ

• Redo taşıma servisleri, redo verilerini primary veritabanından standby veritabanına taşımakla görevlidir.
• Redo taşıma işlemi gerçekleşirken, primary veritabanında LGWR background process’i online redo log dosyalarına yazmaya devam eder.
• LNS (Log Network Server) process’i SGA alanındaki redo buffer alanından okuduğu redo verilerini ONS (Oracle Net Service) servisine standby veritabanına iletmek üzere gönderir.
• Gönderilen redo verileri standby veritabanında RFS (Remote File Server) background process’i tarafından alınır ve Standby Redo Log (SRL) dosyasına işlenir.
• Eşzamanlı (SYNC) ve Eşzamansız (ASYNC) olarak iki tür redo taşıma yöntemi vardır.
• Bir primary veritabanının 11g R2 öncesine kadar maksimum 9 adet standby veritabanı olabiliyordu. 11g R2 ile birlikte 9 dan fazla standby veritabanı oluşturabiliyoruz.
• Birden fazla standby veritabanına redo gönderimi yapan bir primary veritabanında her standby veritabanı için ayrı çalışan LNS background process’i bulunur.

1. Eşzamanlı (SYNC) Redo Taşıma

• Bu yöntemde LNS background process’i gönderilen redo verilerini standby veritabanı tarafında diske yazıldığını doğrulamadan LGWR process’i son kullanıcıya commit bilgisini dönmez.
• Yani commit edilen her veri standby veritabanında garanti altına alınır.
• Bu özelliğinden dolayı bu yöntem “sıfır veri kaybı” olarak da bilinir.
• Bu yöntemde LGWR process’i her zaman LNS process’inden doğrulama bilgisi bekler. Bu bekleme süresi uzun olduğu zaman performansı düşürebilir.
• Bu yöntemde koruma modları olarak Maksimum kullanılabilirlik ve Maksimum Koruma modu kullanılabilir.
• Eşzamanlı redo taşıma yöntemini aşağıdaki görsel üzerinden daha iyi anlayabiliriz.

1) Kullanıcı bir transaction başlattığı zaman, bu işlem redo buffer alanına yazılır. Kullanıcı işlemi commit ettiğinde LGWR process’i redo buffer alanındaki redo verilerini online redo log dosyalarına yazar ve LNS process’i redo verilerinin standby veritabanına yazıldığına dair doğrulama bekler.

2) LNS process’i aynı redo verilerini redo buffer alanından okur ve ONS (Oracle Network Service) üzerinden RFS (Remote File Service) process’ine bildirir. LNS process’i ilgili Redo verilerine Redo Buffer alanından erişemezse otomatik olarak Primary veritabanının Online redo log dosyalarından okur.

3) RFS process’i aldığı redo verilerini standby redo log dosyalarına yazar.

4) Fiziksel standby kullanıyorsak MRP (Managed Recovery Process) ile standby veritabanına apply eder. Logical standby kullanıyorsak apply işlemini LSP (Logical Standby Process) process’i gerçekleştirir.

5) Son olarak RFS process’i redo verisini başarılı apply edildiği bilgisini LNS process’ine gönderir. LNS bu bilgiyi LGWR process’ine aktarır ve kullanıcıya commit işleminin başarılı olduğu bilgisi gönderilir.

2. Eşzamansız (ASYNC) Redo Taşıma

• Eşzamanlı redo taşıma yönteminin tam tersine LGWR işlemi LNS process’inden redo verisinin standby redo log dosyasına başarılı yazıldığına dair herhangi bir doğrulama beklemez.
• Eşzamansız redo taşıma yönteminde sıfır veri kaybı yaklaşımı yoktur. Problem anında en az veri kaybı ile veritabanımızı kurtarır.
• Redo taşıma sırasında herhangi bir bekleme söz konusu olmadığı için primary-standby arasındaki mesafeye bakmaksızın daha performanslı çalışır.
• Maksimum Performans koruma modunu kullanır.

Otomatik GAP Çözümü

• Primary veritabanında bazen yoğun commit işlemleri olduğu zaman LNS process’i üretilen redo verilerini zamanında standby veritabanına iletemediği zaman redo GAP oluşur.
• Aynı zamanda standby veritabanı kapandığında veya ağ kesintisi oluştuğunda da redo GAP oluşabilir.
• Redo GAP oluştuğunda LGWR process’i online redo log dosyalarına yazmaya ve redo log dolduğunda bir sonraki redo log dosyasına switch etmeye devam eder.
• Her switch işlemi sırasında ARCH process’i arşiv log dosyası üretmeye devam eder.
• Primary veritabanında çalışan ARCH process’i, kesinti boyunca standby veritabanına ping göndererek ayakta olup olmadığını kontrol eder.
• Problem düzeldiğinde primary veritabanındaki ARCH process’i, standby veritabanındaki RFS işlemi üzerinden standby control dosyasını sorgulayarak son alınan log dosyalarını kontrol eder. Aradaki farkı Archive Log dosyalarını işleyerek kapatmaya çalışır.

BEKLEME (STANDBY) VERİTABANLARI

• Standby veritabanı primary veritabanının yedek kopyasından oluşturulmuş, canlı veritabanının işlemsel olarak tutarlı kopyasıdır.
• Standby veritabanı bir kere oluşturulduktan sonra Data Guard tarafından otomatik olarak redo verileri ile beslenir.
• Bir primary veritabanının aynı anda birden fazla standby veritabanı olabilir.
• Standby veritabanları 3 türde olabilir. Bunlar; Fiziksel Standby, Mantıksal Standby ve Snapshot Standby veritabanlarıdır.

1. Fiziksel Standby Veritabanı

• Fiziksel standby veritabanı, primary veritabanın blok/blok birebir kopyasıdır.
• Redo Apply yöntemi ile çalışır.
• Oracle Active Data Guard lisansı ile redo verileri apply edilirken Read-Only modunda açılabilmektedir.
• Fiziksel standby veritabanımızı oluşturmadan önce Data Guard yapılandırmamızı hangi ara yüzle yapacağımıza karar vermeliyiz.
• Çünkü Data Guard yapılandırmasını hangi arayüzle gerçekleştirirsek Data Guard yönetimini de seçtiğimiz arayüz ile yapmak zorundayız.
• Bu ara yüzler: OEM Grid Control, Data Guard Broker ve SQL * Plus’dır.

Oracle Active Data Guard = Fiziksel standby veritabanına redo apply işlemi gerçek zamanlı devam ederken read/only erişim imkanı sağlamaktadır. Yani gerçek zamanlı raporlama yapılırken aynı zamanda da redo apply işlemi yapılabilmektedir.

2. Mantıksal Standby Veritabanı

• Primary veritabanının kopyası olarak oluşturulan daha sonra farklı bir yapıya sahip olacak şekilde değiştirilebilen veritabanıdır.
• SQL apply yöntemi ile SQL cümlelerini standby veritabanında çalıştırarak güncellenir.
• Read/write modunda açılabilir ancak Data Guard tarafından işlem görülen tablolar hala read-only durumundadır.
• Her veri tipi desteklenmemektedir. Desteklenmeyen tablolardaki değişiklikler standby veritabanına yansımayacağı için dikkatli olmalıyız.

3. Snapshot Standby Veritabanı

• Primary veritabanı için tam veri koruması sağlayan güncellenebilir standby veritabanıdır.
• Oracle 11g ile gelen bir standby veritabanıdır.
• Primary veritabanından gönderilen redo verilerini alır ve arşivler. Daha sonra arşivlenen redo verileri, snapshot standby veritabanı fiziksel standby veritabanına dönüştürüldüğünde apply işlemi gerçekleşir.
• Genellikle test ve geliştirme yapmak için oluşturulan bir standby veritabanıdır.
• Fiziksel standby veritabanımızı Read/Write modunda açamadığımız için veritabanımız üzerinde herhangi bir değişiklik yapamayız. Bu nedenler Fiziksel standby veritabanımızı test etmek istediğimizde Read/Write modunda açıp sanpshot standby veritabanına çevirip yapmak istediğimiz işlemleri yaparız daha sonra tekrar fiziksel standby veritabanına döneririz.

Data Guard Koruma Modları

• Primary-Standby arasında bir problem yaşandığında, LGWR process’i LNS process’inden doğrulama bilgisi alamayacağı için son kullanıcıya commit bilgisine dönmez veya geç döner. Böyle durumlarda primary veritabanının hang (cevap verememe) olmasını yol açabilir.
• Data Guard, hem sıfır veri kaybı olsun hem de herhangi bir ağ kesintisi gibi bir durumda primary veritabanımızın hang olmasını önlemek için farklı koruma modlarını çözüm olarak sunar.

1. Maksimum Performans:

• Primary veritabanının performansı ön plandadır.
• ASYNC redo taşıma yöntemini kullanır.
• Default koruma modudur.
• LGWR process’i standby veritabanı tarafından herhangi bir bilgi beklemediği için Primary-Standby arasındaki problem, primary veritabanının performansını etkilemez.

2. Maksimum Kullanılabilirlik:

• SYNC redo taşıma yöntemini kullanır.
• Sıfır veri kaybı ile veri koruma özelliği sağlar.
• Primary-Standby arasında iletişim problemi yaşandığında NET_TIMEOUT parametresinin saniye cinsinden değeri kadar beklenir.
• Süre dolduğunda LGWR işlemi LNS process’i ile bağlantısını koparır ve commit bilgisini kullanıcıya döner. Böylelikle primary veritabanının hang olmasını önlenir.
• Primary-Standby arasındaki problem düzeldiğinde Data Guard archive log lar üzerinden otomatik olarak tekrar eşleme işlemine başlar.

3. Maksimum Koruma:

• Maksimum veri koruması ön plandadır.
• SYNC redo taşıma yöntemini kullanır.
• Bu modda NET_TIMEOUT parametresi yoktur.
• Bu yüzden Primary-Standby arasında problem olduğunda primary veritabanının hang olmasına neden olur.
• Bu durumun önüne geçmek için bu modda Data Guard kullanacaksak birden fazla standby veritabanı kullanmamız gerekecek.
• Böylelikle standby veritabanlarından birisi ulaşılamaz duruma düştüğünde primary veritabanının hang olması engellenir.

LOG APPLY SERVİSLERİ

• Standby veritabanına gönderilen redo verileri 2 yöntemle apply edilir.

1. Redo Apply (Fiziksel Standby Veritabanı)

2. SQL Apply (Mantıksal Standby Veritabanı)

• İki yöntemin de temel amacı veri sürekliliğini, yüksek kullanılabilirliği ve veri korumayı sağlamaktır.

1. Redo Apply:

• Primary veritabanının blok/blok birebir fiziksel kopyasının oluşturulmasını sağlar.
• Redo apply, “Media Recovery” kullanarak standby redo log dosyasından okuduğu redo verilerini bellek alanına yazar ve değişen verileri doğrudan standby veritabanına işler.
• Birden fazla çalışan apply işlemi ve apply işlemlerini yöneten MRP (Media Recovery Process) işlemi ile paralel kurtarma işlemini gerçekleştirir.
• Redo Apply, standby veritabanı sunucusundaki işlemci sayısına bağlı olarak apply işlemlerini otomatik yapılandırır.
• Redo Apply, primary veritabanını blok bozulmalarına karşı korur.
• Data Guard, redo verilerini standby veritabanına apply etmeden önce blok bozulmasına karşı doğrulama işlemini gerçekleştirir.
• Blok bozulmalarını tespit etme ve koruma için primary veritabanında DB_ULTRA_SAFE parametresi set edilir.
• Standby veritabanında ise DB_BLOCK_CHECKSUM=FULL ve DB_LOST_WRITE_PROTECT=TYPICAL parametreleri set edilir.
• Redo Apply, standby veritabanında bozulmuş redo verisi tespit ederse, Data Guard otomatik olarak ilgili redo verileri arşiv log dosyalarından okuyarak düzeltmeye çalışır.

2. SQL Apply:

• SQL Apply, redo kayıtlarını SQL olarak işlenmesi ile standby veritabanına apply edilmesidir.
• Bu yöntemde bütün veri tipleri desteklenmez. Avantajı ise SQL cümleleri standby veritabanına işlenirken, standby veritabanı read/write modunda açılabilmektedir.
• Mantıksal standby veritabanında SQL Apply kullanılır.
• Apply işlemi gerçekleşirken birtakım background process’ler kullanılır. Bu background process’leri açıklayacak olursak;

SQL Apply

Reader process’i, standby redo log dosyası veya arşiv log dosyalarını okur.

Preparer process’i, blok değişikliklerini LCR (Logical Change Records) kayıtlarına dönüştürür. LCR kayıtları SGA alanında LCR ön belleğinde tutulur.

Builder process’i, LCR kayıtlarını transaction seti olarak gruplar.

Analyzer process’i farklı transaction ların bağımlılıklarını tanımlar.

Coordinator process’i, işlemleri farklı işleyicilere dağıtır ve işleyiciler arasındaki işlem bağımlılıklarını denetler.

Applier process’i, coordinator işleminden aldığı transaction ları mantıksal standby veritabanına apply eder.

Data Guard Parametreleri

Rol Bağımsız Parametreler:

1. DB_UNIQUE_NAME

• Veritabanımızın benzersiz (unique) adını belirler.
• DB_ UNIQUE_NAME parametresindeki isimler hem primary veritabanında hemde standby veritabanlarında farklı olmalıdır.

2. LOG_ARCHIVE_CONFIG

• Data Guard yapılandırması için seçilen veritabanlarının DB_UNIQUE_NAME parametresindeki geçerli isim listesini belirler.
• Primary veritabanının adı her zaman en önde olur.

Örnek:

log_archive_config=’dg_config=(oracledb,oracledbtest)’

3. CONTROL_FILES

• Control dosyalarımızın yerini gösteren parametredir.
• Standby veritabanlarında standby control dosyasının yerini gösterir.

4. LOG_ARCHIVE_MAX_PROCESSES

• ARCH process’in sayısını belirler. Default değeri 2 dir.
• ARCH process’i online redo log dosyası dolduğu zaman arşivlemeyi sağladığı gibi redo GAP oluştuğunda da problem çözülene kadar standby veritabanını archive log dosyalarını kullanarak besler.
• Bu nedenle ARCH process’in default değeri genelikle yetersiz kalmaktadır.
• Bu parametrenin maksimum değeri 30 dur.

Örnek:

LOG_ARCHIVE_MAX_PROCESSES=’4’

2.Primary Veritabanı Parametreleri:

LOG_ARCHIVE_DEST_n

• Data Guard redo veri gönderimi için önemli bir parametredir.
• Bu parametre ile 0–31 arası farklı hedef yerleri verilebilmektedir.
• LOG_ARCHIVE_DEST_1 primary veritabanının local arşiv dizinine işaret eder. LOG_ARCHIVE_DEST_2 ve sonrası standby veritabanını işaret eder.
• Bu parametrenin bazı öznitelikleri şu şekildedir;

SERVICE:

Standby veritabanına ulaşmayı sağlayan TNS alias adını belirler.

SYNC:

Eş zamanlı redo taşıma yöntemini kullanacağımızı belirler.

ASYNC:

Eşzamansız redo taşıma yöntemini kullanacağımızı belirler ve varsayılan özniteliktir.

NET_TIMEOUT:

Primary ve standby veritabanları arasında bir problem yaşandığında LGWR işleminin LNS işleminden kaç saniye cevap bekleyeceğini belirler. Default değeri 30 saniyedir.

REOPEN:

Primary-Standby arasında bağlantı problemi olduğunda primary veritabanının ne kadar süre sonra standby veritabanı ile tekrar iletişime geçeceğini belirler. Default değeri 300 saniyedir (5 dk).

VALID_FOR:

Hangi redo log dosya türünde ve LOG_ARCHIVE_DEST_n parametresinin ne zaman kullanılacağını belirler.

DELAY: Standby veritabanımıza gönderilen redo verilerinin apply etmeden önce kaç saniye bekleyeceğini belirler. Geciktirilmiş İşleme (Delayed Apply) olarak da bilinir.

3.Standby Veritabanı Parametreleri:

1. DB_FILE_NAME_CONVERT: Standby veritabanındaki datafile’lar primary veritabanındaki datafile’ların lokasyonundan farklı ise kullanılan bir parametredir.

Örnek:

Db_file_name_convert=’/oradata/”,/veridatadb/’

2. LOG_FILE_NAME_CONVERT: Bu parametrede de redo log dosyalarının convert edilmesi için kullanılır.

3. FAL_SERVER: Redo GAP oluştuğunda arşiv log dosyalarının hangi veritabanından alınacağını belirler.

Standby veritabanını oluşturmadan önce bazı ön gereksinimleri tamamlamış olmalıyız. Bu öz gereksinimleri şu şekilde listeleyebiliriz.

• Primary veritabanımız arşiv log modda olmalıdır.
• Standby veritabanında primary veritabanı ile aynı sürüme sahip Oracle Software yüklenmelidir.
• ASM kullanılacaksa, ASM yapılandırılması yapılmalıdır.
• Standby veritabanı için gerekli dizin yapısı oluşturulmalıdır.
• Primary ve standby veritabanlarına karşılıklı birbirlerini görecek şekilde TNS alias bilgileri tnsnames.ora dosyasına eklenmelidir.
• İki sunucunun da işletim sistemi aynı olmalıdır.

Böylelikle bir yazımın daha sonuna geldik. Bir sonraki yazılarımda görüşmek üzere.

Yazımı incelediğiniz için teşekkürler.

LinkedIn hesabımdan bana ulaşabilirsiniz. HARUN ERDİNÇ