25 Nisan 2011 Pazartesi

Oracle Data Guard / Fast Start Failover - Observer - Broker

Oracle Data Guard / Fast Start Failover - Observer - Broker

Selamlar,

Bu yazıma başlamadan önce birinci TROUG gününü organize eden, sponsor olan, sunum yapan ve katılan, kısacası katkıda bulunan herkese teşekkür ederim. Gerçekten çok güzel bir gün geçirdim.

Birinci TROUG gününde çok kısa da olsa Data Guard yapılandırması, fast start failover, observer ve broker'dan bahsetmiştim. Şimdi ise biraz daha detaylı olarak yazacağım ve konuyla ilgili yaptığım sunum dışında Türkçe kaynağı da Oracle topluluğuna katkıda bulunacağım. İlk olarak anlatacağım konu aslında Data Guard'ın kendisi. Nedir, ne zaman kullanılması gerekir, hangi amaçlara hizmet eder gibi sorulara yanıtlar arayacağız. Yazacaklarım tamamen teorik bilgi içerecektir ve Türk Oracle topluluğun kullanması için Türkçe olacaktır.

Oracle Data Guard

Oracle'ın 7.3 versiyonlarından beri aramızda olan, birkaç defa adı değişmiş olan ve şu andaki ismi ile "Data Guard" olarak bilinen Oracle aracının amacı, yüksek erişilebilirliğin, operasyonunun sürekliliğinin ve veri güvenliğinin sağlanmasıdır. Bir Oracle veritabanı ile diğer bir Oracle veritabanı arasındaki senkron veya asenkron archivelog bağlantısı yardımı ile genel senkronizasyonu sağlayarak, olası bir felaket anında uzakta bulunan veritabanına güvenli geçişi sağlar. Oracle Data Guard bir felaketten kurtarma aracıdır ancak güncel versiyonlarla birlikte oldukça etkili bir raporlama aracına da dönüştürülmüştür. Oracle versiyonları ile birlikte yapılan birkaç önemli değişikliği aşağıda listelemek isterim;

9iR1: Physical Standby Database (Fiziksel Yedek Veritabanı)
9iR2: Logical Standby Database (Mantıksal Yedek Veritabanı)
10gR2: Fast Start Failover
11gR1: Snapshot Standby Database (Enstantane Yedek Veritabanı)
11gR1: Active Data Guard
11gR1: Aktif Veritabanından Yedek Veritabanı Oluşturma

Bir Data Guard yapılandırmasında toplam 30 adet yedek veritabanı olabiliyor. 30 olmasının nedenlerinden birisi LOG_ARCHIVE_DEST_n parametresidir. Bu parametre şu an 1-31 arasında bir "n" değeri alabiliyor ve archivelog'lar bu lokasyonlara aktarılabiliyor. Yalnız buradaki en önemli nokta, 1-11 arasında kalan değerlerin 11g öncesinde bulunuyor ve 12-31 arasında kalan değerlerin sonradan geliştirilmiş olmasıdır. Bu durumda, 10'dan fazla yedek veritabanı yaratmak isterseniz, COMPATIBLE parametresini 11.2.0.0 olarak tanımlamanız gerekiyor. 

Oracle Data Guard Yapılandırması

Bir Oracle Data Guard yapılandırmasında;

1) 2 adet rol bulunmaktadır (primary, standby)
2) 3 adet veritabanı tipi bulunmaktadır (physical, logical, snapshot)
3) 1 adet broker yapılandırması bulunmaktadır (1 x primary <----> 1 x standby)
4) 1 adet Fast Start Failover geçişi tanımlanabilir ve yapılandırılabilir

Yapılandırma çerçevesinde yer alacak birincil (primary) ve yedek (standby) veritabanlarının lokasyonları önemli değildir. Yani birincil ve yedek veritabanı veya veritabanları aynı sunucu üzerinde yer alabilirler. Operasyonel anlamda çok fazla mantıklı olmasa da test anlamında geçerli bir kullanıma sahiptir. Bu bağlamda Oracle Data Guard yapılandırması lokasyon bağımsızdır.

Yapılandırmanızı üç şekilde kurabilir ve yönetebilirsiniz;

1) SQL 
2) DGMGRL (Data Guard komut satır arayüzü) - Broker
3) Enterprise Manager

Genelde kullanılan yöntem SQL aracılığı ile yönetmektir ancak Broker'ın faydalarından da bahsedeceğim.

Birincil veritabanı; bir yapılandırmanın içerisinde sadece bir tane bulunabilir. Bu veritabanı tek bir instance'dan veya birden fazla node'u olan bir RAC sistemden oluşabilir. Gündelik işlemlerin gerçekleştiği ve raporlamanın, sorgulamanın vb. işlemlerin yerine getirildiği veritabanı rolü olarak da kullanılmaktadır.

Yedek veritabanı; bir yapılandırmanın içerisinde bir veya birden fazla, en fazla 30 olacak şekilde oluşturulabilir, yönetilebilir ve üzerinde işlemler gerçekleştirilebilir. Birincil veritabanının tutarlı kopyasıdır. Oracle Data Guard, Redo'larda oluşan DML ve DDL'ler aracılığı ile veri senkronizasyonunu, birincil veritabanında oluşan archivelog'ların transferi ile yerine getirmektedir. Bu sayede birincil ile yedek veritabanları sürekli senkronize edilmekte ve olası bir felaket durumunda veri kaybı asgariye indirilmektedir ve hiç veri kaybı olmaması hedeflenmektedir. Bu konuyla ilgili de Data Guard koruma modları kısmında detaylı olarak bahsedeceğim.

3 adet yedek veritabanı tipi bulunmaktadır. Fiziksel, mantıksal ve snapshot (enstantane olarak çevirmek nedense çok garip geliyor) veritabanları. Genelde fiziksel yedek veritabanı seçeneği kullanılmaktadır zira Oracle Data Guard bir felaketten kurtarma aracı olduğundan, felaket anında geçişini yaptığınız veritabanının, birincil veritabanı ile birebir aynı olmasını isteyebilirsiniz -ki genelde de böyle oluyor-. Bu yedek veritabanı tiplerini açıklamam gerekirse;

Fiziksel yedek veritabanı, birincil veritabanının blok bazlı, birebir ve disk yapısı itibariyle kopyasıdır. Veritabanı kullanıcısı (şeması) ve indeksler tamamen aynıdır. Bir fiziksel yedek veritabanı, birincil veritabanı ile yine archivelog transferi sayesinde senkron halde tutulur. Bu senkronizasyon işlemi sırasında, birincil veritabanı "open" modunda iken, fiziksel yedek veritabanı "mount" modunda beklemektedir. Mount modunda olmasının nedeni ise MRP olarak adlandırdığımız (media veya managed recovery process) arka plan görevinin 11gR1 öncesinde sadece mount modda redo uygulamasını fiziksel yedeğe yapabiliyor olmasıdır. Bir fiziksel yedek veritabanı read only, yani yalnızca okuma modunda açık hale getirilebilir ancak bu süreçte birincil veritabanından gelecek archivelog'ların akışı ve fiziksel yedek veritabanına uygulanması duracaktır. 11gR1 ile birlikte geliştirilen "Active Data Guard" özelliği ile -ki bu paralı bir Oracle ürünüdür- fiziksel yedek veritabanları "read only" modunda açılmışken bir yandan MRP, birincil veritabanından aktarılan archivelog'ları fiziksel yedeğe işlemeye devam etmektedir. Bu sayede fiziksel yedek veritabanı hem raporlama için hem de olası bir felaket anında, birincil veritabanının kaybedilmesiyle ana veritabanı rolünü üstlenebilmektedir. Bu bakımdan bir Oracle Data Guard yapılandırmasında sıklıkla tercih edilmekte olan bir yedek veritabanı tipidir.

Mantıksal yedek veritabanında ise birincil veritabanı ile senkronizasyon yine esastır ancak blok bazlı bir eşleşme söz konusu olmayabilir. Mantıksal veritabanı daha çok raporlama ve bir takım materialized view'ların denenmesi için kullanılmaktadır. Mantıksal veritabanı, fiziksel olduğu şekli ile senkron tutulmamaktadır. "SQL Apply" ismi verilen başka bir yöntem ile, redo bilgileri önce SQL sorgularına dönüştürülür ardından mantıksal veritabanına işletilir. Hiçbir zaman kaybı yaşanmadan, veritabanlarınızın yama yükseltmesini gerçekleştirebilirsiniz.

Enstantane (ilginç oldu biliyorum) yedek veritabanı ise sonradan aramıza katılan bir yedek veritabanı türüdür ve tamamen güncellenebilir bir yedek veritabanıdır. Enstantane yedek veritabanı, yine mantıksalda ve fizikselde olduğu gibi karşıdan archivelog'ları (redo bilgisini) alır ancak diğerleri gibi uygulama kısmına geçilmez. Bu süreçte her türlü deneme, güncelleme ve kontrolünüzü gerçekleştirebilirsiniz. Ne zaman ki enstantane yedek veritabanı, bir fiziksel yedek veritabanına dönüştürüldü, o zaman redo bilgisinin uygulanması başlatılır. Bu süreç uzadıkça çevirme işlemi de uzayacaktır çünkü çok daha fazla redo bilgisinin işletilmesi gerekecektir. 

Bir Oracle Data Guard uygulamasının nasıl ilerlediğini diyagram olarak göstermem gerekirse;


Oracle Data Guard Servisleri

Oracle Data Guard'ın 3 adet servisi bulunmaktadır ve bunlar; redo gönderim, uygulama ve role değişikliği servisleridir. Kısaca bu servislerin ne işe yaradıklarından da bahsetmek istiyorum.

Redo gönderim (Transport) servisi; archivelog lokasyonlarına redo bilgilerinin aktarılmasından sorumlu servistir. Oracle Data Guard yapılandırmasında yer alan bütün yedek sistemlere, birincil veritabanından gelen redo bilgilerini aktarır. Herhangi bir ağ iletişim sorunundan ortaya çıkan redo taşıma aralığını (gap) bu  servis kapatmaya çalışmaktadır. Aslında redo gönderim servisinin benim en beğendiğim özelliği ise, kayıp veya bozuk archivelog'ları tespit eder ve birincil veritabanından ya da Oracle Data Guard yapılandırmasına dahil herhangi bir yedek veritabanından bu archivelog(ları) temin eder. 

Uygulama (Apply) servisi; birincil veritabanından gelen redo bilgileri, yedek veritabanının standby redolog'larına yazılır. Uygulama servisleri, yedek veritabanına ait olan standby redolog'lara yazılan DML ve DDL'lerin yedek veritabanına işletilmesini (uygulanmasını) sağlamaktadır. Bahsettiğimiz gibi, birincil veritabanı ile yedek veritabanlarının senkron olması gerekiyordu. Bu senkronizasyonun sürdürülebilirliğini sağlayan bir diğer serviste, işlediği redo bilgileriyle uygulama servisidir. Şimdi ise size çok önemli 2 diyagram göstereceğim. Genelde gelen sorulara bir nevi yanıt olacak. Bu sorulardan "Fiziksel ve mantıksal yedek veritabanları arasındaki fark nedir?" İşte bu sorunun cevaplarından birisi şu olabilir; fiziksel yedek veritabanında "Redo Apply" servisi çalışmaktayken, mantıksal veritabanında ise "SQL Apply" servisi çalışmaktadır.

Fiziksel Yedek Veritabanının Otomatik Olarak Güncellenmesi



Mantıksal Yedek Veritabanının Otomatik Olarak Güncellenmesi


Diğer bir Oracle Data Guard servisi rol değişimleridir. Yine bu yazımda gösterdiğim rollerin (birincil, yedek) değiştirilmesine izin verilmektedir. Bu iki rolün değiştirilmesi içinse yine 2 adet yöntem bulunmaktadır. Bu yöntemlerden birincisi "switchover" ikincisi "failover"dır. 

Switchover; işleminde birincil veritabanı ile Oracle Data Guard yapılandırmasına dahil herhangi bir yedek veritabanının, veritabanı rollerinin değiştirilmesi işlemidir. Bu işlemden sonra birincil veritabanı, yeni yedek; yedek veritabanı ise yeni birincil veritabanı rollerini üstlenmektedir. Çok kısaca rol değişikliği, SQL ile nasıl yapılır göstermek istiyorum;

Aşama 1 (Birincil Veritabanı)

– SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

Aşama 2 (Birincil Veritabanı)

– SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
WITH SESSION SHUTDOWN;

Aşama 3 (Birincil Veritabanı)

– SQL> SHUTDOWN ABORT;
– SQL> STARTUP MOUNT;

Aşama 4 (Yedek Veritabanı)

– SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

Aşama 5 (Yedek Veritabanı)

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

Aşama 6 (Yeni Birincil Veritabanı)

– SQL> ALTER DATABASE OPEN;

Aşama 7 (Yeni Yedek Veritabanı)

– SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING
CURRENT LOGFILE DISCONNECT FROM SESSION;

Yukarıdaki işlem tamamlandığı zaman, yedek veritabanımız artık yeni birincil veritabanımız olmuştur. Veritabanı open moddadır ve eski birincil ile arasında bir fark bulunmamaktadır. 

Failover; durumu birincil veritabanı tamamen kapalı olduğunda ve erişilemediği, başarısız olduğu durumda gerçekleştirilen bir işlemdir. Switchover genelde planlanan bir deneme geçişi olacaktır zira bir felaket anında, felaketin olduğu birincil veritabanı lokasyonuna erişim tamamen kesilecek ve bu durum Oracle Data Guard için bir failover işlemi haline dönecektir. Failover gerçekleştiği zaman yedek veritabanının rolü, switchover işleminde olduğu gibi birincil veritabanı rolüne geçirilecektir. Her iki rol geçişindeki esas amaç veritabanlarının rollerini, dolayısıyla kullanım alan ve amaçlarını değiştirmektir.

Oracle Data Guard Broker

"Broker", Oracle Data Guard yapılandırmasının yönetimsel arayüzüdür ve yapılandırma işlemini, bakımı ve Data Guard yapılandırmasını otomatize etmektedir. Enterprise Manager veya Oracle Data Guard komut satır arayüzü kullanarak (DGMGRL) aşağıdaki işlemleri yerine getirebilirsiniz;

- Oracle Data Guard yapılandırmasının kurulması. Bu kuruluma redo gönderim ve uygulama servisleri dahildir.
- Yapılandırma sisteminde bulunan herhangi bir makineden Oracle Data Guard yapılandırmasının yönetilmesi.
- Oracle RAC sistemine sahip bir veritabanının Oracle Data Guard yapılandırmasının yönetilmesi ve izlenmesi.
- Tek bir anahtar kelime, komut ile switchover ve failover rol geçiş işlemlerinin kolaylaştırılması. 
- Fast Start Failover görevinin aktif hale getirilmesi ve geçişi yapılacak birincil ve geçiş yapılacak yedek veritabanlarının belirlenmesi işlemi. Fast Start Failover'la ilgili daha detaylı olarak bu yazının ilerleyen bölümlerinde yazıyor olacağım.

Yukarıdaki operasyonlara ek olarak EM kullanarak;

- Birincil veritabanından alınan yedekle fiziksel ve/veya mantıksal yedek veritabanlarının kurulması ve ayarlanması.
- Varolan Oracle Data Guard yapılandırmasına yeni yedek veritabanlarının eklenmesi.
- Redolog uygulama hızlarının gözlemlenmesi.

Oracle Data Guard Broker'ına 11gR1 ve 11gR2 ile gelen yeni özellikleri listelemem gerekirse;

11gR2

- Oracle Data Guard Broker, Oracle Real Application Clusters One Node ile tamamen entegre edildi.
- Bir broker yapılandırmasının birincil veritabanı dahil, toplam 30 adet yedek veritabanı olabiliyor.
- Instance'a özel özelliklerin tek bir komut ile rahatlıkla değiştirilebilmesi.
- Redo gönderim sıkıştırması (compression) artık sadece archivelog boşlukları olduğunda değil, bütün gönderimi yapılan log dosyaları için geçerli kılındı.
- SHOW CONFIGURATION ve SHOW DATABASE komutlarının çıktılarının zenginleştirilmesi.
- StaticConnectIdentifier isminde yeni bir özellik eklendi ve bu özellik sayesinde DGMGRL'nin veritabanı instance'larını yeniden başlatması sağlanabiliyor.
- Oracle Data Recovery Advisor artık Oracle Data Guard'ı kullanarak, düzeltme seçeneklerini sunmaktadır. 
- Maximum Availability koruma modundan Maximum Protection koruma moduna geçerken veritabanının yeniden başlatılmasına artık gerek yok.

11gR1

- Fast Start Failover özelliği bu versiyona kadar Maximum Availabiliy ile çalışmaktayken, bu versiyon ve sürüm ile Maximum Performance koruma modunu da kabul etmektedir.
- DBMS_DG paketi eklendi.
- Enstantane yedek veritabanı desteği sağlandı.
- Yeni DGMGRL komutları eklendi; 
CONVERT DATABASE TO [SNAPSHOT | PHYSICAL] STANDBY;
DISABLE FAST_START FAILOVER CONDITION
ENABLE FAST_START FAILOVER CONDITION
SHOW FAST_START FAILOVER

Oracle Data Guard Broker Yönetim Modeli

Aşağıdaki diyagram, Oracle Data Guard Broker yönetim modelini açıklamaktadır;



Broker yapılandırması tanımlandığı zaman, her yapılandırma veritabanında DMON (Data Guard Monitor) arka plan görevi oluşmaktadır. Oracle Data Guard Broker'ı çalıştırıldığı anda bu görev de çalışmaya başlamaktadır ve Oracle Data Guard'ın gözlemlenmesi ve izlenmesi içindir. Sunucu tarafında oluşan bir görevdir.


Oracle, Oracle Data Guard Broker'ın kullanmasını tavsiye etmektedir çünkü yönetim maliyetlerini düşürürken, kontrol mekanizmalarını geliştirmektedir. Bu yazımın birkaç bölüm gerisinde elle switchover operasyonunu göstermiştir. Broker yapılandırmanız olduğu zaman bu işlemi tek bir komut ile yapabilmeniz mümkün;

DGMGRL> SWITCHOVER TO ;

Oracle Data Guard Koruma Modları

Bir Oracle Data Guard yapılandırmasının 3 farklı veri koruma modu olabilmektedir. Veri koruma modları, Oracle Data Guard'ın koruma işlemini nasıl gerçekleştireceğini göstermektedir. Bazı durumlarda felaket anında veri kaybı çok az derece kabul edilebilirken, bazı durumlarda ise hiç kabul edilmemektedir. Kimi zamansa en optimum düzeyi hedeflenmektedir. İşletmenin bu ihtiyaçlarının adreslenmesi içinse 3 adet koruma modu geliştirilmiştir.

Maximum Availability

Birincil veritabanının erişilebilirliğini devre dışı bırakmadan, gerçekleştirilebilecek en yüksek derecede veri güvenliği sağlanmaktadır. Birincil veritabanındaki hiçbir transaction, birincil veritabanındaki bütün redo bilgileri, yedek veritabanındaki redo bilgileri ile senkron olmadığı sürece commit edilmeyecektir. Eğer birincil veritabanındaki redo akışı bir ağ probleminden dolayı, yedek veritabanı yönünde kesilirse maximum performance modu gibi çalışılacak ve birincil veritabanının operasyonu direkt olarak etkilenmeyecektir. Redo akışı yeniden tesis edildiği zaman uygulama kaldığı yerden bu modda devam edecektir.

Maximum Protection

Bu koruma modunda, birincil veritabanı başarısız olduğu zaman sıfır veri kaybı hedeflenmektedir. Bir transaction'ı kurtarmak için gerekli olan redo bilgisinin hem birincil veritabanının online redolog dosyasına hem de ilgili yedek veritabanının standby redolog dosyasına yazılmış olması gerekmektedir. Aksi halde hiçbir transaction commit etmeyecektir. Senkronize olan bir yedek veritabanına, birincil veritabanından redo bilgisi akışı kesilirse, akışın geri gelmesinin beklenmesi yerine birincil veritabanı kapatılacak ve hiçbir transaction'ın gerçekleştirilmesine izin verilmeyecektir. Bu durumda ise birincil veritabanının erişilebilirliği negaitf olarak etkilenecektir.

Maximum Performance

Bu koruma modu varsayılan koruma modudur ve v$database dinamik performans görüntüsü sorgulandığı zaman görülebilmektedir. Mümkün olan en yüksek veri koruması sağlanmaktadır ancak birincil veritabanı ani olarak başarısız olduğu anda veri kaybı olabilmektedir. Bu koruma modunun amacı birincil veritabanının performansını çok fazla etkilemeden redo akışının ve uygulamasının sağlanmasını sağlamaktır. Birincil veritabanının online redolog'larına redo bilgilerinin yazılması, transaction'ların commit edilmesi için yeterli bir sebeptir ve herhangi bir yedek veritabanına yazılıp yazılmadığı kontrol edilmediği gibi asenkron redo bilgisi akışı sağlanmaktadır.

Oracle Data Guard Fast Start Failover ve Observer

Fast Start Failover özelliği ile önceden seçilmiş bir yedek veritabanına, birincil veritabanına ulaşılamadığı durumlarda Broker yapılandırması tarafından otomatik geçiş sağlanmaktadır. Hiçbir elle gerçekleştirilecek operasyona veya veritabanı yöneticisi müdahalesine gerek olmadan birincil veritabanı ile ilgili yedek veritabanının rolleri güvenli bir şekilde otomatik olarak değiştirilir. DGMGRL veya EM aracılığı ile yapılandırması yapılabilmektedir. Maximum availability veya maximum performance modları ile birlikte kullanılabiliyorken, maximum protection ile kullanılamamaktadır. Maximum availability modundan sıfır veri kaybı garanti edilirken, maximum performance modunda FastStartFailoverLagLimit parametresine göre bir miktar veri kaybı görülebilir. Bu parametre ile tahammül sınırı belirlenir ve veri kaybında eşik değeri aşıldığı zaman otomatik failover işlemini, Fast Start Failover özelliği Broker aracılığı ile başlatır. Bu parametre veritabanı koruma modu maximum performance olarak ayarlandığı zaman kullanılabilir. Diğer koruma modu için geçiş işlemi direkt olarak başlatılacaktır.

Bu bölümde hem Fast Start Failover'dan hem de Observer'dan bahsediyor olacağım. Observer dediğimiz arkadaşımız ise Fast Start Failover'ın takipçisidir ve onun muhbiridir. Veritabanlarını (birincil ve geçerli yedek) sürekli olarak kontrol eder ve olağandışı bir kesinti anında Fast Start Failover'a ve Broker yapılandırmasına bilgi aktarır. Observer'ın birincil ve failover anında geçişi yapılacak olan yedek veritabanının olmadığı bir yerde yapılandırılması gerekmektedir. Observer için bir Oracle Client gerekmektedir. Fast Start Failover ortamındaki Observer'ın diyagramını aşağıda görebilirsiniz;


Bir Oracle Data Guard yapılandırmasında birden fazla observer olamaz. Yapılandırmak ve yaratmak isterseniz aşağıdaki hatayı alırsınız;

ORA-16647: could not start more than one observer

Bir observer'ı çalıştırabilmek için SYSDBA olarak DGMGRL'ye bağlanmanız gerekmektedir.

DGMGRL> START OBSERVER;
DGMGRL> STOP OBSERVER;

Yukarıdaki komutlarla Oracle Data Guard komut satır arayüzünden observer'ı başlatabilir ve durdurabilirsiniz. Bu arada observer'ı yine birincil veritabanının ya da yedek veritabanının olduğu sunucuya kurabilirsiniz ancak mantıksal açıdan pek faydalı olmayacaktır. Oracle buna da izin tanımaktadır.

Fast Start Failover'dan önce birincil veritabanı redo bilgilerini aktarmaya ve failover'ın gerçekleşeceği yedek veritabanı ise bu bilgileri almaya ve uygulamaya devam etmektedir. Observer ise bu iki veritabanının durumunu yakından incelemektedir. Diyelim herhangi bir t zamanında birincil veritabanının bulunduğu lokasyonda bir felaket gerçekleşti ve iletişim tamamen kesildi. Bu durumu observer fark ettiği zaman birincil veritabanı ile iletişimi yeniden kurmaya çalışmaktadır. Bu durumda kullanılacak bir parametre vardır ve adı FastStartFailoverThreshold'dur. Bu parametre, yani eşik değeri aşıldığı zaman failover işleminin otomatik olarak gerçekleştirilmesi tetiklenmektedir. Fast Start Failover'ın gerçekleşmesine müteakip hedef yedek veritabanı artık birincil rolü üstlenecektir. Eski birincil veritabanına olan bağlantının, observer farkına vardığı zaman, yeni birincil yani eski yedek veritabanından redo akışının, eski birincil yani yeni yedek veritabanına gerçekleştirilmesi tetiklenmektedir. Birincil ve yedek veritabanı ile observer arasındaki ilişkinin görüntüsü aşağıdadır;


Fast Start Failover'ı aktif hale getirmeden önce uygulanması gereken birkaç işlem vardır. Bunlardan ilki veritabanının maximum availability veya maximum performance koruma modlarından herhangi birinde olmasıdır. LogXptMode parametresinin ayarlanmış olması gerekmektedir. SYNC olarak ayarlarsanız maximum availability, ASYNC olarak ayarlarsanız maximum performance olarak çalışacaktır. Fast Start Failover'ın gerçekleşeceği veritabanını seçmek için FastStartFailoverTarget parametresinin ayarlanmış olması gerekmektedir ancak bu parametre kurulum için ön şart değildir. Birkaç örnekle devam edelim;

---------------------------------------Maximum Availability------------------------------------------

DGMGRL> EDIT DATABASE 'ORCL' SET PROPERTY LogXptMode = SYNC;
DGMGRL> EDIT DATABASE 'ORCL_YDK' SET PROPERTY LogXptMode = SYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;

--------------------------------------Maximum Performance-----------------------------------------


DGMGRL> EDIT DATABASE 'ORCL' SET PROPERTY LogXptMode = ASYNC;
DGMGRL> EDIT DATABASE 'ORCL_YDK' SET PROPERTY LogXptMode = ASYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxPerformance;
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit = 60;

Observer için ayarlanacak eşik değerinin ayarlanması içinse aşağıdaki komutu gidiyoruz ancak girebilmek için Fast Start Failover'ın aktif hale getirilmesi gerekmektedir.

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 60;

DGMGRL> ENABLE FAST_START FAILOVER;
DGMGRL> START OBSERVER;


Tamamlayıcı Oracle Data Guard Teknolojileri ve Teknikleri

İşletmenin akışının daha güvenli bir şekilde devam edebilmesi için Oracle Data Guard yanında kullanılabilecek birkaç başka teknoloji bulunmaktadır. Bunlar Oracle RAC, Flashback Database ve Recovery Manager (RMAN) teknolojileridir.

Oracle Data Guard'ın Yararları

Oracle Data Guard kullanımının sağlayabileceği birkaç faydadan bahsetmek istiyorum;

- Felaket kurtarma, veri güvenliği ve yüksek erişilebilirliğin sağlanması.
- Tam veri koruması ve sıfır veri kaybı.
- Sistem kaynaklarının efektif olarak kullanılması ve paylaştırılması.
- Performans / güvenlik arasındaki dengeli veri koruma seviyeleri.
- Otomatik olarak saptanan ve çözümlenen redo transfer ve uygulama boşlukları.
- Merkezileştirilmiş ve otomatize edilmiş yapılandırma yönetimi ve gözlemlenmesi.
- Oracle Enterprise Edition ile birlikte, Oracle veritabanına entegre edilebilen kolay kurulum.
- Otomatik rol geçiş özellikleri.

Bu yazımda Oracle Data Guard, Fast Start Failover, Observer ve Broker'dan ve kavramlarından bahsetmeye çalıştım. Umarım faydalı olmuştur.

İyi çalışmalar.

Ogan

5 yorum:

ömer arslan dedi ki...

teşekkürler, çok açıklayıcı ve anlaşılır olmuş

muhammet can dedi ki...

teşekkürler baya işimize yaradı, elinize sağlık...

Ogan Özdoğan dedi ki...

Faydalı olduğuna sevindim. İyi çalışmalar dilerim.

heredot_umit dedi ki...

Gerçekten çok yararlı bir makele okudum, elinize emeğinize sağlık.

ertugrulaslan dedi ki...

Emeginiz icin cok tesekkur ederim Hocam Ogan Hocam.. Sizin gibi bilgilerini bizlerle Turkce paylasan degerli hocamlarimizin sayisi gun gectikce artiyor. Yazilarinizin devamini bekliyoruz

Takip et: @oganozdogan