DATA GUARD MİMARİSİ

En basit tanımıyla bir veritabanının, başka bir veritabanına anlık olarak kopyasının alınması ve herhangi bir arıza, felaket durumunda kopya veritabanının production olarak kullanılması olarak tanımlanabilir.

Mimaride bir adet primary veritabanı olmalı, bir veya birden fazlada standby veritabanı olmalıdır.

Redolog lar bir veritabanında yapılan tüm değişikleri tekrardan oluşturmak için gerekli tüm bilgileri içermektedir. LGWR background prosessi SGA üzerindeki redo kayıtlarını disk üzerindeki redo log dosyalarına yazar.

REDO TRANSPORT SERVISLERI

LNS (Log Network Service) SGA deki Redo buffer alanındaki redo verilerini ONS (Oracle Net Service) Standby veritabanına iletmek üzere gönderir. Gönderilen redo verileri Standby Veritabanında RFS (Remote File Service) background servisi tarafından alınır ve Standby Redo Log dosyalarına işlenir. Bu dosyalar da Redo apply işlemi ile Standby veritanabınına işlenir.

İki tür Redo taşıma yöntemi vardır Syncronous (SYNC) ve Asyncronous (ASYNC)

1. SYSNC Redo Transfer

Bu yöntemde LNS background process Standby veritabanından redo log apply bilgisini almadan transaction commit bilgisini dönmez. Yani primary veritabanındaki her değişiklik standby veritabanında garanti altına alınmalınır.

SYNC ile redo aktarımının performans olarak bazı handikapları vardır. Primary ile Standby arasındaki Network, I/O vb. problemler Primary veritabanında ciddi performans sorunları oluşturabilir.

2. ASYNC Redo Transport :

LGWR process Standby veritabanından herhangi bir doğrulama beklemeden transaction commit değerini döndürür, dolayısıyla Primary veritabanında herhangi bir performans kaybı görülmez.

GAP : Bazen LNS (Log Network Service) redo log verilerini zamanında standby tarafına iletemeyebilir, bu durumda redo GAP oluşur, bu sırada primary veritabanında işler normal rutininde yürümektedir; LGWR online redo log dosyalarına yazmaya, redo log dosyalarında switch işlemi oldukçada ARCH processi Archive log üretmeye devam eder. Primary tarafında ARCH processi, kesinti boyunca standby veritabanını kontrol eder (ping) ve problem düzeldiğinde data Guard standby control file dan son işlenen log dosyalarını kontrol ederek aradaki farkı Archive log dosyalarını işleyerek kapatır.

LOG APPLY SERVİSLERİ

İki türü vardır İlki Redo Apply ikincisi ise Sql Apply

1. Redo Apply :

Redo apply primary veritabanının blok/blok birebir fiziksel kopyasının oluşturulmasını sağlar. Redo apply yötemi primary veritabanı blok bozulmalarına karşı korur (data guard redo verilerini standby veritabanına apply yapmadan önce bir doğrulama yapar).

2. SQL Apply :

Redo kayıtları 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 tarafında işlenirken standby veritabanı read/write modda açılabilmektedir.

DATA GUARD KORUMA MODLARI

1. Maximum Performans : Varsayılan moddur. Primary veritabanının performansı ön plandadır. ASYNC redo taşıma yöntemi kullanılır. Primary ile Standby arasındaki iletiişim problemi primary veritabanının performanısını etkilemez.
2. Maksimum Erişebilirlik : SYNC redo taşıma kullanır ancak NET_TIMEOUT parametresi ile sayesinde primary ile standby arasında bir kopukluk olduğunda bu parametre kadar beklenir sonrasında primary veritabanı transaction commit ederek kendi işlemlerine devam eder standby veritabanını belklemez ve hang duruma düşmez. aradaki bağlantı problemi giderildiğinde Data Duard archive log lar üzerinden eşitleme yaparak tekrar işlemine devam eder.
3. Maximum Koruma: SYNC modda redo taşıması yapılır burada NET_TIMEOUT parametresi yoktur dolayısıyla primary ile standby arasındaki kopukluk primary veritabanının hang olmasına neden olur. Bu durumun önüne geçmek için bu modda data guard kullanmak isteyenler birden fazla standby veritabanı kullanırlar bir standby ile bağlantı kopsada diğer standby veritabanları ile bağlantı sürdüğü sürece primary veritabanı hang olamayacaktır.

Bazı Data Guard Konfigurasyon Parametreleri

• LOG_ARCHIVE_CONFIG Bu parametre Data Guard yapılanmasında DB_UNIQ_NAME parametresindeki geçerli isim listesini belirler.
  • SQL> alter system set log_archive_config='DG_CONFIG=(frkdb,frkdbstb)';
• LOG_ARCHIVE_DEST_n parametresinin ayarlanması
  • Bu parametreyi RMAN den biliyoruz aslında LOG_ARCHIVE_DEST_1 parametresi local archive yerini belirtir, LOG_ARCHIVE_DEST_2 parametresi de standby veritabanına işaret etmektedir. Bu parametrenin 17 alt parametresi vardır. Bunlardan bazıları ;
    • SERVICE –> Standby veritabanımıza ulaşmamızı sağlacak olan TNS alias adıdır.
    • SYNC
    • ASYNC
    • NET_TIMEOUT
    • DB_UNIQUE_NAME
    • VALID_FOR Data Guard için önemli parametrelerdendir. Alt özellikleri şu şekildedir
      • ONLINE_LOGFILE–>Sadece Online Redo log dosyalarını arşivlerken geçerlidir
      • STANDBY_LOGFILE–> Sadece standby redo log dosyalarını arşivlerken geçerlidir.
      • ALL_LOGFILES–> Türüne bakılmaksızın tüm redolarda geçerlidir.
      • PRIMARY_ROLE–> Veritabanı primary rolde çalışırken geçerlidir
      • STANDBY_ROLE–> Veritabanı standby rolünde çalışırken geçerlidir.
      • ALL_ROLES –> Hepsi için geçerlidir
    • SQL> alter system set log_archive_dest_2='SERVICE=frkdbstb NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=frkdb';
    • Buraya kadar olan nitelikler zorunluydu bundan sonraki nitelikler isteğe bağlıdır.
    • REOPEN Bir problem sonrasında Primary veritabanının ne kadar süre sonra standby veritabanı ile iletişime geçeceğini belirler. Varsayılan değeri 300 sn dir.
    • NOAFFIRM Max Performance için kullanılır.
    • COMPRESSION
    • DELAY Standby veritabanımıza gönderilen redo verilerinin işlenmeden önce kaç saniye bekleyeceğini belirtir.
    • MAX_FAILURE Primary standby arasında problem yaşandığında LGWR işleminin kaç defa yeniden bağlanmaya çalışacağını belirler
• FAL_SERVER  Standby tarafı için önemlidir, Primary ile Standby arasında Redo GAP oluştuğu zaman Arşiv log larının hangi Server dan alınacağını bu parametre ile belirleriz
• DB_FILE_NAME_CONVERT Standby veritabanı ile primary veri dosyaları konumları farklı ise farklı ise bu parametre standby veritabanı için set edilir. Örneğin primary için /data_frkdb altında standby da ise /data_frkdbstb altında ise parametremiz
  • alter system set db_file_name_convert='/datafrkdb/','/data_frkdbstb/'; olarak set edilir
• LOG_FILE_NAME_CONVERT : DB_FILE_NAME_CONVERT parametresinin archivelog dosyaları için olan şeklidir :))
• STANDBY_FILE_MANAGEMENT : Sadece standby veritabanın da kullanılan bir parametredir. Bu parametre AUTO yapıldığında, primary veritabanından bir dosya drop edilir veya create edilirse standby veritabanında da aynı dosya DB_FILE_NAME_CONVERT parametresinin işaret ettiği yerde drop veya create edilir.

Data Guard 2 yazımızda kurulum ve konfigurasyonlarını yapacağız.