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

Birden fazla MRP?

Merhaba,

Geçtiğimiz günlerde şu şekilde bir soru ile karşılaşmıştım;

"Data Guard replikasyonu ve senkronizasyonu için birden fazla MRP görevi çalıştırılabilir mi?"

Kişisel yorumum hayır, çalıştırılamaz. Açıkçası ben hiç MRP1, MRP2 gibi görevlere rastlamadım. Bir veritabanını açarken, media recovery sırasında parallel işlem yaptırabilirsiniz;

SQL> RECOVER DATABASE PARALLEL X;

Parallel işlemler devreye girerek, media recovery yapacaktır ancak bu işlemler sırasında göreceğiniz Oracle görevi muhtemelen P001 gibi bir isimle yer alacaktır, MRP1.. değil.

Hatta bu konunun tartışıldığı bir forum bulunmakta ve ben de birkaç cümle yazmıştım. Umarım okuyanlar için faydalı olur;

ora_p000_process

Recovery_parallelism parametresi ile MRP arasında hiçbir ilişki bulunmuyor, MRP görevlerinin sayısını da arttırmıyor. P ile başlayan görevler parallel işlem yapmakta olan görevlerdir. data guard replikasyonu için kullanılan görev MRP'dir, P ile başlayan parallel görevler değildir.

Media Recovery Process (MRP) bir komut ile devreye alınıp, yine bir komut ile devreden çıkarılabilir;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; --> MRP görevi sonlandırılır ve media recovery devam etmez.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE [USING CURRENT LOGFILE] DISCONNECT FROM SESSION; --> Eğer bir standby redo log grubunuz varsa using current logfile diyerek, MRP görevini bu komut ile yeniden başlatabilirsiniz.

Dip not: Fiziksel beklemede bulunan bir veritabanını "read only", yani sadece okuma modunda açabilmek için MRP görevini öncelikle sonlandırmanız gerekmektedir. 11g'de bile bunu yapmadan read only olarak veritabanını açamazsınız, sorgu koşamazsınız ve raporlama yapamazsınız.

İyi geceler.

Ogan

Physical Standby Automatic Archivelog Deletion / Maintenance

Selamlar,

Genelde yazılarımın başlıklarını Türkçe, içeriği Türkçe ve mümkün olan bütün kelimeleri de yine Türkçe yazmaya özen ve dikkat gösteriyorum. Ancak bu sefer başlığı İngilizce yazmamın nedeni birçok insanın İngilizce olarak arama yapması ancak Türkçe bulduğu zaman daha işlerine yaramasını sağlayabilmek. Etiket olarakta ayrıca ekledim.

Geçtiğimiz gün tarafıma iletilen bir soru üzerine çözüm ürettim ancak ürettiğim çözümün internet üzerinde, bu başlık ile ilişkilendirilmediğini gördüm. Konu şu; bir fiziksel veritabanımız var ve veritabanınızın v$archived_log fixed view'ını görüntülediğiniz zaman "applied" başlığı altındaki en güncel archivelog'un, fiziksel veritabanınıza işlendiğini gördünüz. v$dataguard_status view'ında da işler yolunda gidiyor. Peki bu oluşan archivelog'lar neden silinmiyor? Buradaki önemli sorulardan birisi budur aslında. Archivelog'ların bakımı (silinmesi, yedeklenmesi) ile ilgili inanılmaz boyutlarda soru - cevap internet üzerinde mevcut ancak data guard söz konusu olunca işler değişiyor.

Bunu sağlayabilmenin iki tane yolu var. Archivelog'ları Oracle'a otomatik olarak sildirtebilirsiniz ya da yedeği alınırken silinebilir. Her iki yolu da anlatacağım.

1) Archivelog'ların Oracle Tarafından Otomatik Olarak Silinmesi:

Bunu sağlayabilmek için 2 tane parametre tanımlamamız gerekiyor. Bir tanesi db_recovery_file_dest ve diğeri de db_recovery_file_dest_size. Bu parametreleri 10g için SGA_TARGET, 11g için MEMORY_TARGET gibi düşünebilirsiniz (mantık aynı, görevleri farklı). Oracle oluşan archivelog'ları tanımlamış olduğunuz db_recovery_file_dest alanına;

/db_recovery_file_dest/ORACLE_SID/archivelog/DATE/%arc_%s_%t şeklinde tanımlar. Buradaki archivelog formatını ise log_archive_format parametresi belirler. Oracle oluşan archivelog'ları gün gün ayırır, silinmesi gerekenleri siler. Silinmesi gerekenler nedir? db_recovery_file_dest_size parametresine tanımladığınız bilgi eğer %100'e yaklaşmış ise size uyarıda bulunur. Tepki vermezseniz kendisi otomatik olarak siler! Bu arada bu iki parametreyi de eğer spfile kullanıyorsanız dinamik olarak tanımlayabilirsiniz. (alter system ... scope=both);

Bu uyarının çıktısı ise şöyle olacaktır;

Errors in file /usr/ORACLE/u01/oracle/admin/smstby/udump/smstby_rfs_18686.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 1073741824 bytes is 97.09% used, and has 31258624 remaining bytes available.
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************

Uyarının nedeni db_recovery_file_dest_size'ın neredeyse dolmuş olması. Yukarıdaki örnekte %97 dolu durumda gözüküyor. Peki bu 4 maddeyi yapmazsanız Oracle ne yapıyor? O da aşağıda;

Wed Jun 30 09:31:40 2010
RFS[13]: Archived Log: '/usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48375_62oqpf58_.arc'
Primary database is in MAXIMUM PERFORMANCE mode
Deleted Oracle managed file /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48372_62on259d_.arc
Deleted Oracle managed file /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48373_62oojwrq_.arc

Veritbanının devamlılığını sağlayabilmek için bu archivelog dosyalarını otomatik olarak siliyor.

Bu veritabanı için db_recovery_file_dest parametresini /usr/ORACLE/archive/SMSTBY/ olarak tanımladım ancak Oracle archivelog'ları /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/ altında oluşturdu. Bu da kendisinin yönettiğini gösteriyor. Bunu da yapabilmek için ilgili dizinde Oracle kullanıcısının (unix) okuma ve yazma hakkının olması gerekiyor. Bu bilgiyi işletim sistemi yöneticisinden alabilirsiniz.

2) RMAN ile Archivelog'ların Silinmesi:

Bir diğer yöntem ise her zaman geçerli olan Recovery Manager ile archivelog'ların yedeklenmesi. Bu başlıkta kendi içerisinde ikiye ayrılabilir. Birincisi kişinin *nix üzerinde oluşan archivelog'ları elle silmesi, diğer de bu log'ları RETENTION PERIOD belirleyerek "obsolete" hale getirerek Recovery Manager tarafından sildirmesi. Ben ikinci yolu her zaman daha olumlu buluyorum çünkü elle silindiği zaman ek işler ve masraf devreye giriyor.

Elle sildiğimiz zaman bunu Oracle'a bildirmek zorundayız. Oracle otomatik olarak bu archivelog'ların silindiğini anlayamaz. Yedekleme yaparken hata alırsınız ve yedeklemeye çalışır sonra da bulamıyorum der. Bunun için;

RMAN> crosscheck archivelog all;

Komutunu amacı archivelog'ları Oracle'a göstertmek ve varlığını öğretmek. Crosscheck komutundan sonra "obsolete" archivelog'ları silebilmek için;

RMAN> delete noprompt obsolete;

Bu yöntemler eski archivelog'lardan kurtulabilirsiniz. Diğer yöntemde ise recovery catalog değil de control dosyasını yedek listelemede kullandığınızı varsayıyorum. Control dosyasının yedek bilgilerini tuttuğunu ve aşağıdaki parametreye göre bakımını yapması gerektiğini söyleyebilirim;

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

Yukarıdaki komut aldığınız yedeklerin, archivelog'ların vb. 7 gün boyunca "expired" ya da "obsolete" olmayacağını garanti eder.

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 5;

Yukarıdaki komut ise aldığınız 5 tane veritabanı yedeğinden sonraki 6ncı ile birlikte, 1ncinin "expired" yani aslında kullanılamaz olarak etiketlenmesini sağlar.

Peki bu komutların standby archivelog'ları ile ne ilgisi var? Bir diğer parametrenin tanımlanması ile;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Varsayılan değeri NONE olan yukarıdaki parametreyi APPLIED ON STANDBY ile değiştirirseniz eğer "obsolete" olan archivelog'lar yedekleme sırasında standby veritabanından silinecektir.

Eğer yedekleme işlemini birincil veritabanında yapıyorsanız;

Birincil veritabanında;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

Yedek veritabanında;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Eğer yedeklemeyi yedek veritabanında yapıyorsanız;

Birincil veritabanında;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Yedek veritabanında;

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

Oracle dokümantasyonuna göre (11g) yedekleme işlemine gerek kalmadan, APPLIED ON STANDBY derseniz mantıksal ya da fiziksel yedeğin archivelog'ları silinecektir.

Yukarıdaki genel bilgiler ışığında benim tercih ettiğim method ilk olarak anlattığım. "Flash recovery area" bilgisinin tanımlanmış olması önemli bir kriter zira birçok veritabanı archivelog'ların şişmesi ve eksik bakım yapıldığından çökebiliyor. Ölümcül bir hata değil, veritabanı bir süre daha varlığını devam ettirebiliyor ancak bir süre sonra ARCHn görevi ölüyor ve archive alınması işlemini veritabanı terk ediyor. Bu durumda veritabanını kapatmanız, archivelog'ların artık bulunmadığını Oracle'a öğretmeniz (eğer elle silmişseniz) ve veritabanını yeniden açmanız gerekecektir.

İyi çalışmalar,

Ogan