Merhaba ardaşlar bu yazımda Oracle Standby(Data Guard) teknolojisinden bahsedecegim

Standby(Data Guard) Oracle’ın felaket kurtarma(disaster recovery) çözümüdür.

Nedir bu felaket kurtarma,bunu örneklerle açıklayacak olursak veritabanımızın bulunduğu ortamın bir şekilde zarar görmesi(yangın,deprem,sel vb.) sonucu sıfır veri kaybı veya çok az bir veri kaybı ile hızlı bir şekilde veritatabanımızı ayağa kaldırmamızı sağlar.Peki bunu nasıl sağlar ;Bunu da veritabanımızın bire bir kopya (replice)’ sını başka bir lokasyon da bekleterek sağlar.

Oracle standby kullanabilmek için Oracle’ın Enterprise sürümünü kullanıyor olmamız gerekir.Standby teknolojisi  Oracle 7 ile manuel standby veritabanı oluştururarak kullanılmaya başlandı ve her versiyon da yeni özellikler getirildi.

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)

Oracle 12c

  • Far Sync

Physical Standby

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. Genel de primary ile standby farklı lokasyonlardadır.

İ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.

Logical Standby

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;

Snapshot Standby

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.

Data Guard Mimarisi

Data guard’ın çalışma mantığında primary veritabanın da oluşan redo verilerini standby veritabanına taşır ve taşınan redo verilerini apply eder.Redo verileri veritabanı işlemlerini(transaction) kurtarmak için gerekli olan tüm verileri içerir.

Data guard primary veritabanını corruption’a karşı da korur.Taşınan redo verisini standby veritabanına işlemeden(apply) önce blok corruption’a karşı kontrol eder.

Bir primary veritabanının 11gR2 öncesine kadar 9 adet standby veritabanı bulunabilmekteydi.11gR2 ile birlikte 32 farklı yere log yazabilme özelliği gelmiştir.Her standby veritabanı için LNS background prosesi bulunmaktadır.

NOT : Standby veritabanına gönderilen redo verilerinin işlenmesi için 2 yöntem vardır.Redo apply(physical standby) ve Sql apply(logical standby).

Yukarıda ki resimden de anlaşıldığı gibi LNS(Log Network Server) background prosesi SGA alanında ki redo buffer alanından okuduğu redo verilerini ONS(Oracle Net Service) servisine standby veritabanına iletmek üzere gönderir.Gönderilen redo verilerini standby veritabanında RFS(Remeto File Server) background prosesi tarafından alınır.Alınan redo verileri RFS background prosesi ile SRL(Standby Redo Log) dosyasına işlenir.

NOT : Data Guard ın Synchronous ve Asynchronous olmak üzere 2 farklı çalışma şekli vardır.

Synchronous Redo Taşıma

Synchronous Redo Taşıma felaket durumunda sıfır veri kaybı sağlaması ile avantajlıdır.Bunun sebebi olarak da LNS background prosesine gönderilen redo verilerinin standby veritabanı tarafında diske yazıldığını doğrulamadan LGWR işlemi son kullanıcıya COMMIT bilgisini dönmüyor.Bu şekilde de COMMIT edilen her veri standby veritabanında garanti altına alınmış oluyor.

Ama bu yöntemin de performans açısından bazı dezavantajları vardır.Çünkü LGWR işlemi her zaman LNS background prosesinden doğrulama bilgisi bekler.LNS background prosesinin doğrulama yapma süresi de standby daki I/O performansı,primary-standby arasında ki hız gibi bazı işlemlere bağlıdır.

Asynchronous Redo Taşıma

Asynchronous Redo Taşıma da LGWR background prosesi LNS background prosesinden redo verisinin standby redo log dosyasına başarılı yazıldığına ilişkin herhangi bir doğrulama beklemez.

Dolayısı ile daha performanslı çalışır.Bu yöntemin dezavantajı ise sıfır veri kaybı garantisi veremiyor olmasıdır.

NOT : Asynchronous Redo Taşıma yaparken sıkıştırma özelliğini kullanabiliriz.Bu bize network açısından avantaj sağlar.

NOT : Oracle Dataguard teknolojisi bize verilerimizin korunması için farklı seçeneklere göre 3 koruma modu sunar.

  • Maximum Performance
  • Maximum Availability
  • Maximum Protection

Maximum Performance

Bu modda primary veritabanının performansı ön plandadır.ASYNC redo taşıma yöntemi kullanılır. Yani LGWR processi standby veritabanından gönderilen Redo verilerinin apply edildiği bilgisini beklemeden kullanıcıya commit bilgisini gönderir.Varsayılan koruma modudur.

Maximum Availability

Maksimum veri koruması için bir koruma yöntemidir, dataguard bu modda kullanıcıya sıfır veri kaybı (Zero Data loss) özelliği sağlar.SYNC (Senkron) Dataguard konfigürasyonudur.Bu modda kullanıcı başlattığı bir transaction için commit koyduğu anda başlatılan transaction Standby a apply edilmeden kullanıcıya Commit edildiği bilgisi dönmez.

Bu modda Primary veritabanı ile Standby veritabanı arasında Networksel yada herhangi bir iletişim sorunu yaşandığında belirli bir süre beklenir bu süre zarfında iletişim sağlanamazsa LGWR process i LNS process i ile olan connection ı keser se kullanıcıya commit edildiği bilgisini döner. Belirli bir süre için veritabanının belirlediği parametre ise NET_TIMEOUT parametresidir. Bu parametre sayesinde Veritabanının hang olmaması sağlanır.

Maximum Protection

Bu modda Maximum Availability moda benzer SYNC Dataguard konfigürasyonunu kullanır. Aralarında tek bir fark vardır o da bu modda NET_TIMEOUT parametresi kullanılmaz yani LGWR process i LNS process inden Redo verilerinin Standby a Apply edildiği bilgisini bekler eğer Apply edilmemişse kullanıcıya Commit bilgiside dönmez.

Bu modda primary veritabanı sürekli olarak Standby dan bilgi beklediği için bir süre sonra hang durumuna düşebilir bu durumu önlemek için genellikle bu modu kullananlar birden fazla Standby veritabanı oluştururlar. Primary veritabanı göndermiş olduğu Redo verilerinin herhangi bir tane veritabanına ulaştığının ve apply edildiğinin bilgisini alması yeterlidir. Bu yöntemde Birden fazla Standby kullanılması Primary açısından önemlidir çünkü Hang olma olasılığı böylece azaltılmış olur.

A.Rol Bagımsız(Role-Independent) Parametreler

DB_UNIQUE_NAME : Benzersiz veritabanı ,smini belirler.DB_NAME parametresi ile belirlenen veritabanı adı hem primary hem de standby veritabanın da aynı olmalıdır.Bu durum da DB_UNIQUE_NAME parametresinde ki isimler primary ve standby veritabanları için farklı olacaktır.DB_UNIQUE_NAME ser edilmezse varsayılan olarak DB_NAME parametresi ile belirtilen isim set edilir.

db_unique_name='ORCL'

LOG_ARCHİVE_CONFIG : Dataguard konfigürasyonu için seçilen veritabanlarının DB_UNIQUE_NAME lerinin belirtildiği parametredir. İlk olarak Primary veritabanı DB_UNIQUE_NAME i yazılır ardından standby lar dizilir.

log_archive_config= 'dg_config=(ORCL,ORCLSTBY)'

CONTROL_FILES : Veritabanlarımızın beyni olan Control file larının yerini gösteren parametredir. Bu değer Primary de Primary veritabanının, Standby da Standby veritabanın Control file Location ını gösterir.

control_files='/u01/app/oracle/oradata/ORCL/control01.ctl'

LOG_ARCHIVE_PROCESSES : Dataguard konfigürasyonu için önemli parametrelerden birisidir. Adındanda anlaşıldığı gibi Veritabanının bu işlem sırasında kullanabileceği maksimum ARCH process inin sayısını belirler. Default olarak ilk kurulumda bu sayı 2 dir yani 2 adet ARCH process i aktif olarak çalışır ve bu process lerden 1 tanesi sadece dolan Online Redolog dosyalarının Arşivlemesini sağlar ve bunun için assign edilmiştir. Bundan dolayı ilk kurulumda gelen 2 adet ARCH process i Canlıdaki veritabanımız için çok yetersizdir. Yetersiz olmasının nedeni ARCH process i hem Dolan Online Redo logların Arşivler hemde Primary ve Standby arasında Redo Gap oluştuğu zaman ARCH process i Primary veritabanının Arşiv log larını kullanarak Standby veritabanını besler. Bu parametrenin maksimum değeri 30 dur.

log_archive_max_processes='4'

DB_CREATE_FILE_DEST : Data guard’a özel bir parameter degildir.Standby veritabanın da Oracle ASM kullanıyorsak bu parametreyi set etmemiz gerekiyor.

B.Primary Veritabanı Parametreleri

LOG_ARCHIVE_DEST_n : Data Guard redo veri gönderimi için önemli bir parametredir.Bu parametreyi local arşivleme yaparken de kullanmaktayız.Bu parameter 11gR2 ile birlikte 0-31 arası farklı hedef yerleri verilebilmektedir.Örnegin LOG_ARCHIVE_DEST_1 lokal arşiv dizinine işaret ederken, LOG_ARCHIVE_DEST_2 standby veritabanına işaret edebilmektedir.Bu parametrenin 17 alt özniteliği vardır.

Service : Standby veritabanımıza ulaşmayı sağlayan TNS alias adını belirler.

SYNC : Synchronous redo taşıma yöntemini kullanacağımızı belirler.

ASYNC : Asynchronous redo taşıma yöntemini kullanacağımızı belirler.Varsayılan özniteliktir.Maximum Performance için gereklidir.

NET_TIMEOUT : Primary-Standby veritabanları arasın da bir problem yaşandığında.LGWR işleminin LNS işleminden kaç saniye cevap bekleyeceğini belirler.Varsayılan değeri 30 saniyedir.Belirtilen saniye kadar bekledikten sonra LNS işleminden cevap gelmezse LGWR işlemi son kullanıcıya commit cevabını iletir.

REOPEN : Primary veritabanının ne kadar süre sonra standby veritabanı ile tekrar iletişime geçeceğini belirler.Varsayılan değeri 300 saniyedir.Yani primary-standby arasındaki bağlantı problemi olduktan 5 dakika sonra primary veritabanı standby veritabanını tekrar sorgular.

DB_UNIQUE_NAME : Bu parametreyi de öznitelik olarak kullanabiliriz.

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

Redo log dosya türü için ;

  • ONLINE_LOGILE : Sadece online redo log dosyalarını arşivlerken geçerlidir.
  • STANDBY_ LOGILE : Sadece standby redo log dosyalarını arşivlerken geçerlidir.
  • ALL_LOGFILES : Redo log dosya türüne bakmaksızın hepsinde geçerlidir.

Rol değerleri için ;

  • PRIMARY_ROLE : Veritabanı primary rolünde çalışırken geçerlidir.
  • STANDBY_ROLE : Veritabanı standby rolünde çalışırken geçerlidir.
  • ALL_ROLES : Veritabanımızın çalışma rolüne bakmaksızın hepsinde geçerlidir.

Yukarıda ki nitelikler Data Guard yapılandırmamız için gerekli olan niteliklerdir.Birde isteğe bağlı nitelikler vardır.

AFFIRM : SYNC redo taşıma yöntemleri için varsayılandır.LNS işlemi başarılı mesajı dönmeden önce RFS işleminin standby redo log dosyasında doğrudan I/O gerçekleştirilmesi için bekler.

NOAFFIRM : ASYNC redo taşıma yöntemi için varsayılandır.

COMPRESSION : Gönderilen redo verilerini sıkıştırmak için kullanabiliriz.

DELAY : Standby veritabanımıza gönderilen reo verilerin işlenilmeden önce kaç saniye bekleyeceğini belirler.

ALTERNATE : Online redo log dosyalarımızın arşivlendiği disk dolarsa sıkıntı yaşarız.Bunun için alternatif dizinler tanımlayabiliriz.

LOCATION : Üretilen archive log dosyalarının hangi dizinde saklanacağını işaret eder.

MANDATORY : Primary veritabanından gönderilen redo verileri bu nitelik ile belirtilen dizine mutlaka gönderilmelidir.

MAX_FAILURE : Primary-Standby arasında problem yaşandığında LGWR işleminin kaç kere yeniden bağlanmaya çalışacağını belirler.Bu bir süre olmaktan siyade log switch işlemi ile bağlıdır.Yani bu nitelik 3 set edilmişse,3 log switch işlemi gerçekleşene kadar her log switch işleminde bağlanmaya çalışır.

C.Standby Veritabanı Parametreleri

DB_FILE_NAME_CONVERT : Standby veritabanında bu parametre data file’lerin primary veritabanında ki yerlerinden standby veritabanında ki yerlerine mantıksal olarak taşır.Disk yapısı primary ve standby veritabanlarında farklı ise kullanılan bir parametredir.

db_file_name_convert=’/ORCL/’,’/ORCLSTBY/’

LOG_FILE_NAME_CONVERT : Yukarıda olduğu gibi buradada redo log dosyaları için mantıksal taşıma yapılır.

log_file_name_convert=’/ORCL/’,’/ORCLSTBY/’

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

FAL_CLIENT : FAL_SERVER parametresi ile belirlenen servislerden istekte bulunan istemci servisi belirler.

STANDBY_FILE_MANAGEMENT : Bu parameternin değeri AUTO yapıldığında primary veritabanına yeni bir datafile eklendiğinde ve silindigindeotomatik olarak standby veritabanına da yansır.
Yararlı olması Dilegiyle …
Yazar : Mustafa Bektaş Tepe

Kaynaklar ; 
www.taliphakanozturk.wordpress.com(Oracle Database 11g R2 İleri Veritabanı Yönetimi)
http://www.oracle.com/pls/db112/portal.portal_db?selected=14

Loading