27 Nisan 2011 Çarşamba

11gR1 Parametresi - DIAGNOSTIC_DEST

DIAGNOSTIC_DEST

Oracle 11g versiyonunun birinci sürümü (11gR1) ile aramıza katılan ve bünyesinde birkaç alt dizin barındıran bu yeni parametre hakkında konuşacağım.

"String" yani karakter tipindeki bu parametre, bir dizin yapısını kayıt altına alır. Normal şartlar altında $ORACLE_BASE ortam değişkenini kaydeder ancak tanımlanmadığı durumlarda $ORACLE_HOME kullanılır. Bu iki parametreye birer örnek verelim;


#echo $ORACLE_BASE
/oracle/product/11.1.0
#echo $ORACLE_HOME
/oracle/product/11.1.0/db_1

ALTER SYSTEM komutu ile varsayılan değerini dilediğiniz gibi değiştirebilirsiniz.

SQL> alter system set DIAGNOSTIC_DEST = '/home/oracle/yeni_lokasyon';
System altered.

Oracle RAC sistemlerinde, her bir instance için ayrı ayrı tanımlanabilir ancak Oracle'ın tavsiyesine göre bu parametreyi her instance için aynı tutmak ve lokasyonuda paylaşılan bir disk alanında bulundurmaktır. Diagnostic dest'in parametre dizin yapısı ise aşağıdadır;

diagnostic_dest/diag/rdbms/veritabanı_adı/instance_adı

Yukarıdaki lokasyon, dizin aynı zaman ADR (Automaic Diagnostic Repository) ana lokasyonu olarak tanımlanmaktadır. Instance'la ilgili dosyaların saklandığı dizinler ise;

- Trace Dosyaları: adr-home/trace
- Alert Log: adr-home/alert. Bu lokasyonda bulunan alert.xml dosyası, xml formatındadır ve Oracle ARB loglama standartlarını kapsamaktadır. alert.log dosyasını takip etmek isterseniz (text olan) trace dosyalarının olduğu dizine gitmeniz gerekmektedir. Bu durum, OCA - OCP sertifikasyon sınavlarında soru olarak karşınıza çıkabilir.
- Core Dosyaları: adr-home/cdump
- Incident (Olay) Dosyaları: adr-home/incident/incdir#. ORA-600, ORA-7445 gibi içsel hatalar veya bug'lar birer olaydır ve olay dosyası üretirler. Bu tipte dosyaları bu dizin altında bulabilirsiniz.

10g versiyonu ile karşılaştırmasına bakarsak;

10g ---> 11g
USER_DUMP_DEST ---> adr-home/trace
BACKGROUND_DUMP_DEST ---> adr-home/trace , adr-home/alert
CORE_DUMP_DEST ---> adr-home/cdump
USER/BACKGROUND_DUMP_DEST ---> adr-home/incident/incdir#

SQL> show parameter diagnostic_dest


NAME                          TYPE          VALUE
------------------------ ------- -----------------------
Diagnostic_dest              string          /oracle/product/11.1.0

İyi çalışmalar.

Ogan

26 Nisan 2011 Salı

Veritabanının Çoğaltılması (Database Duplication / Replication)

Veritabanının Çoğaltılması (Database Duplication / Replication)

Bir kaynak veritabanının, başka bir yere kopyasının oluşturulmasına, çoğaltılmasına veritabanı çoğaltılması denmektedir ve kahraman komutumuzun adı 'DUPLICATE'dir. Çoğaltılan veritabanına da kaynak veritabanından RMAN aracılığı ve DUPLICATE komutu ile replike edilmiş veritabanı denmektedir. Bu yazımda DUPLICATE komutunu ve 11g ile birlikte gelen müthiş farklılıklardan bahsediyor olacağım.

Bir veritabanının çoğaltılmasını en basit anlamıyla test amacı için isteyebiliriz. Çoğaltılmış bir veritabanında aşağıdaki fonksiyonları yerine getirebilmekteyiz;

- Yedekleme ve yedekten dönme operasyonlarının test edilmesi.
- Yeni bir Oracle veritabanı sürümünün yükseltilmesi çalışması ve bu çalışmanın test edilmesi.
- Kurulumunu yaptığınız uygulamanın ana veritabanı üzerinde oluşturabileceği potansiyel yükün izlenmesi.
- Yedek veritabanı yaratmak için (Bkz. Oracle Data Guard / Fast Start Failover - Observer - Broker , Data Guard)
- Rapor çekilmesi ve oluşturulması.

Örneğin elinizde iki adet unix makine var. Bir tanesinde birincil veritabanınız bulunmakta ve üzerinde 7/24 çalışmakta olan bir uygulama bulunmakta. Bu uygulamayı çok fazla sarsmadan, ikinci unix makinesine DUPLICATE komutu ile bir replike veritabanı yaratabilirsiniz. Bu yarattığınız veritabanında da yukarıda gösterdiğim aksiyonları alabilirsiniz. Bu sayede birincil veritabanınızdaki uygulama direkt olarak etkilenmemiş olacaktır (Veritabanının, RMAN ile yedeklemesini yaparken ve DUPLICATE komutu koşarken Large Pool kullanılabileceği için performans açısından birincil veritabanına etkisi olacaktır. Benin tavsiye gece çalışmasıdır).

Burada bahsettiğim konu sonuçta bir replikasyon, kopyalama olduğu için birincil veritabanının ismi, yani DBID'si replikasyonu yapılmış kopya veritabanı ile aynı olacaktır. Bunu da sağlayan yine DUPLICATE komutudur. Kopyalanmış veritabanının DBID'sini değiştirmek ve bir recovery catalog'a tanımlamak isterseniz DBNEWID Oracle aracını kullanarak, DBID'sini değiştirebilirsiniz (# nid TARGET=SYS DBNAME=ORCL).

DUPLICATE komutu bize bütün bir kopya oluşturabilir veya fiziksel yedek veritabanı yaratabilir. Kopya veritabanının özelliklerini fiziksel yedek veritabanı için ya da fiziksel yedek veritabanına ait özellikleri, kopya veritabanı için kullanamazsınız. İkisi birbirinden başka amaçlara hizmet etmektedir.

11g ile aramıza katılan "Active Database Duplication" yani Aktif Veritabanı Çoğaltılması özelliğinden bahsetmek istiyorum. Bir veritabanı çoğaltabilmek için iki yolumuz var artık. Birincisi eski yöntem ve hala geçerli olan yöntem RMAN yedeğinin taşınması ile yapılan çoğaltma işlemi, diğeri de aktif veritabanı çoğaltılması operasyonu.


Yukarıdaki şemada gördüğünüz gibi aktif veritabanından DUPLICATE koştuğumuzda ve 11g özelliğinden faydalandığımızda bir başka aşamaya ihtiyacımız bulunmuyor. Yedeklerle uğraşmak isterseniz iki aşamalı bir yol yine sizi bekliyor olacaktır.

11g Yeni Özellik: Aktif Veritabanı Çoğaltılması 
(Active Database Duplication)

Bir ağ üzerinden gerçekleştirilen replikasyon işlemine aktif veritabanı çoğaltılması denmektedir. Bu yöntemde RMAN yedeği ile uğraşmanıza gerek kalmamaktadır.


RMAN arayüzü ile bağlandığımız hedef (target) ve uzak (auxiliary) veritabanlarını ve aralarındaki ilişkiyi yukarıdaki şemada görebilirsiniz. Aktif veritabanı coğaltılması tek bir komuta baktığı için aslında yedek bazlı çoğaltma işleminin çok ufak bir parçasını kapsamaktadır. Buradan sonra yedek bazlı veritabanı çoğaltılması işlemine detaylı olarak bakacağız.

Yedek Bazlı Veritabanı Çoğaltılması (Backup-Based Duplication)

Bu çoğaltma işleminde RMAN, önceden aldığımız bir ana veritabanı yedeğini kullanarak DUPLICATE işlemini gerçekleştirmektedir. Bu tekniğin kullanılabilmesi için 3 farklı seçeneğimiz ve yolumuz bulunmaktadır. Bunlar;

a) Hedef veritabanı bağlantısı olmadan gerçekleştirilen çoğaltma operasyonu. Recovery catalog veritabanı kullanılarak RMAN yedek bilgileri elde edilmektedir.



b) Hedef veritabanı bağlantısı ile birlikte bir recovery catalog bağlantısı olmadan gerçekleştirilen çoğaltma operasyonu. Yedek lokasyonundan alınan RMAN metadata bilgisi ile hareket edilmektedir.



c) Hedef veritabanı bağlantısı varken gerçekleştirilen çoğaltma operasyonu ise üçüncü metottur. RMAN, yedeklere ait metadata bilgisini ya hedef veritabanının controlfile'ınından ya da recovery catalog veritabanından elde etmektedir.



RMAN'in gerçekleştirdiği çoğaltma operasyonu sırasında uyguladığı aşamalar aşağıdadır;

1) Uzaktaki instance için bir spfile yaratır ancak bunu yapabilmesi işin aşağıdaki koşulların gerçekleşmemiş olması gerekmektedir.
a) Yedek veritabanı replikasyonu.
b) spfile replikasyonu.
c) Uzak instance'ın bir spfile ile başlatılmış olması.
2) Bir yedekten veya image copy'den aldığı bilgileri, en son controlfile ile birlikte restore etmesi.
3) Uzak veritabanını mount konumuna getirmesi.
4) RMAN repository'sini kullanarak, uzak veritabanı için işlenecek ve restore edilecek yedeklerin, image copy'lerin ve datafile'ların belirlenmesi. Bu aşama yalnızca yedek bazlı çoğaltma işlemi için geçerlidir.
5) Çoğaltılacak datafile'ların restore ve recover operasyonlarının gerçekleştirilmesi.
6) Uzak veritabanını kapatır ve nomount modunda yeniden açar.
7) Yeni bir controlfile yaratır, ardından datafile'ların içerisinde bu yeni DBID'yi işler.
8) Çoğaltılmış veritabanını RESETLOGS opsiyonu ile açar ve online redolog'larını oluşturur.

Birkaç örnek vermek istiyorum;

DUPLICATE TARGET DATABASE TO duplicate_database1
FROM ACTIVE DATABASE
PASSWORD FILE
SPFILE
PARAMETER VALUE CONVERT '/u01', '/u02'
SET DB_FILE_NAME_CONVERT '/u01', '/u02'
SET DB_LOG_FILE_NAME_CONVERT '/u01', '/u02'
SET SGA_MAX_SIZE 24G
SET SGA_TARGET 20G; 


DUPLICATE TARGET DATABASE 'ORCL' TO 'duplicate_database1' NOFILENAMECHECK;


RUN
{
SET NEWNAME FOR DATABASE TO '/u01/%b'^;
DUPLICATE TARGET DATABASE TO duplicate_database1
LOGFILE
GROUP 1 ('/u02/logs01.log', '/u02/logs02.log') SIZE 100M REUSE,
GROUP 2 ('/u03/logs03.log', '/u03/logs04.log') SIZE 100M REUSE;
}

Veritabanı Çoğaltılmasının Temel Adımları

1) Veritabanı çoğaltılması işlemi için hazırlıkların yapılması.
2) RMAN'nin başlatılması ve ilgili veritabanı instance'larına bağlantının sağlanması.
3) Kaynak (hedef) veritabanını geçerli aşamaya çekmek.
4) RMAN kanallarının ayarlanması ve yapılandırılması.
5) Çoğaltma işleminin gerçekleştirilmesi.

Yukarıda bahsettiğim 5 adet aşamayı sırasıyla inceleyelim.

1) Bu aşamada ilk olarak bir replikasyon tekniği ve yol haritası çıkartmamız gerekiyor. İşletmeniz ve operasyonunuz için en iyi çözümün ve yolun hangisi olduğuna karar vermelisiniz. Bunu yapabilmek için kendinize şu soruları sorabilirsiniz;

- Veritabanı çoğaltma tekniklerini ve gereksinimlerini biliyor muyum?
- Kaynak (hedef) veritabanına ait RMAN yedeklerini aldım mı ya da alıyor muyum?
- Bir recovery catalog veritabanına sahip miyim?
- Sunucular üzerinde yeterli disk alanı olduğunu biliyor muyum?
- İlgili sunucular ne tipte bir ağ bağlantı yapısına sahip (LAN, WAN)?
- Veritabanı çoğaltma işlemini ne zamana planlamak istiyorsunuz?

Soruların cevapları sizde varsa konumuza devam edelim. Bir veritabanı çoğaltılması sırasında RMAN, controlfile'lara, datafile'lara, tempfile'lara ve online redolog'lara isimleri vermektedir. Bu durumda isimlendirme için de bir stratejinizin olması gerekmektedir. Oracle'ın tavsiyesini dinlemek isterseniz derler ki; kaynak veritabanı ile çoğaltılacak uzak veritabanının bu tipte dosyalarının isimlerinin değiştirilmeden çoğaltma işleminin yerine getirilmesi. Bu işleme devam edebilmeniz içinse aşağıdaki gereksinimlerin yerine getirilmiş olması şarttır;

- Eğer kaynak veritabanı bir ASM diskgroup kullanmaktaysa, çoğaltılacak uzak veritabanının da bir ASM disk group kullanması.
- Eğer kaynak veritabanı OMF (Oracle Managed File) kullanmaktaysa, çoğaltılacak uzak veritabanındaki DB_FILE_CREATE_DEST parametresinin kaynak veritabanındaki lokasyonu ile aynı olması.
- Eğer replikasyonu yapacağınız ortamda bir Oracle RAC yapılandırması geçerli ise, ORACLE_SID parametresinin, hem kaynak hem de ilgili uzak veritabanınları için aynı olması.
- Eğer kaynak veritabanındaki datafile'lar bir dizin içermekteyse (/u01/oradata/datafiles... gibi) o zaman bu dizin yapısının çoğaltılacak uzak veritabanında da aynı olması.

Şimdi bahsedeceğim aşamayı eğer aktif veritabanı çoğaltması operasyonu yapıyorsanız geçebilirsiniz fakat yedek bazlı çoğaltma işlemini anlattığım için yine de belirtiyor olacağım. Bir replikasyon operasyonunun başarılı olabilmesi için RMAN'in DUPLICATE komutunun ilgili yedekleri görebiliyor ve uygulayabiliyor olması gerekmektedir. Bildiğiniz gibi bunu yapabilmenin birkaç yolu bulunmaktadır. Bu yolları yukarıda diyagramlarla ifade etmeye çalıştım (3 yol). RMAN yedeklerine ait metadatanın ilk oluştuğu ve doğduğu yer controlfile'dır. Genelde yapılan uygulama bir recovery catalog veritabanı kurmaktır ve metadata bilgilerini burada saklamaktır. Bunun en büyük nedeni ise controlfile'in aklında tutabileceği metadata bilgisi sınırlıyken, saklanabilecek yedek miktarı ve yedeklerin geçerlilik süreleri (retention period) oldukça değişken ve uzun vadeli olabilmektedir. Bu bağlamda hem metadata bilgisine hem de fiziksel olarak restore ve recover edilecek yedeklere ihtiyacımız vardır. Bu yedekler bir disk'te veya SBT'de (kaste, tape ünite) tutuluyor olabilir. Eğer yedekleriniz bir kaset ünitesinde bulunmaktaysa ilk bakacağınız yer erişim noktalarıdır. Kaset ünitesinden okunabilirliği incelemek durumundasınız.

Bu aşamadan sonra spfile ve passwordfile gibi Oracle instance'ına ait dosyaların kontrolünü tamamlamamız gerekiyor. Bu aşamayı RMAN'e bırakabilirsiniz ancak devri tamamlamadan önce bakılması gereken bir diğer nokta ise aradaki bağlantının sağlanıp sağlanmadığı. Bunu yapabilmek için bir listener oluşturmanız ve tns bilgilerini tanımlamanız gerekmektedir.

2) İkinci aşamada kontrol edeceğimiz nokta kaynak ve çoğaltılacak uzak veritabanının durumlarıdır (nomount, mount, open). Eğer kaynak veritabanı açık değilse mount veya open moduna alıyoruz. Burada aktiv veritabanı çoğaltması opsiyonu ile devam etmek istiyorsak; kaynak veritabanı open aşamasında ise archivelog modunda olmalıdır. Kaynak veritabanı open aşamasında değilse bir instance recovery işlemine gerek yoktur.

RMAN'in çalıştırılmasıyla devam edecek olursak tek yapmamız gereken aşağıdaki komutu, unix ortamında koşmaktır (geçerli Oracle kullanıcısı ile tabii).

# rman

CONNECT, TARGET ve AUXILIARY argümanlarını sıklıkla kullanıyor olacağız. Madem RMAN'i başlattık, şimdi de gerekli veritabanlarına ve recovery catalog'a bağlanabiliriz.

RMAN> CONNECT TARGET SYS/password@ORCL     --> Kaynak veritabanı 
connected to target database: ORCL (DBID=23041923)



RMAN> CONNECT AUXILIARY SYS/password@duplicate_database1     --> Uzak veritabanı
connected to target database: DUPLICATE_DATABASE1 (DBID=29101923)

RMAN> CONNECT CATALOG SYS/password@ORCL_CAT     --> Recovery catalog veritabanı
connected to target database: ORCL_CAT (DBID=19031984)

3) Üçüncü aşamada RMAN kanallarının yapılandırılması ve akışa hazır hale getirilmesi gelmektedir. Uzak veritabanındaki kanallar yedeğin restore işlemine yardımcı olan akış kanallarıdır. Bu kanalların nasıl ve ne kadar kullanılacağı sizin replikasyon tekniğinize ve sistemine yapısına bağlıdır.

CONFIGURE komutu ile kanalların yapılandırmasını gerçekleştirebiliriz.

RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT;

5) Beşinci ve son aşamada ise uzak veritabanının çoğaltılması işlemini açıklayacağım. Bütün bir veritabanının nasıl replike edildiğini göstermeye çalışacağım. DUPLICATE isminde oldukça sihirli bir komuta sahibiz.

DUPLICATE TARGET DATABASE TO duplicate_database2
FROM ACTIVE DATABASE
PASSWORD FILE
SPFILE
NOFILENAMECHECK;

Yukarıdaki komutla çoğaltılacak uzak veritabanına ait dizin yapısının aynı olduğunu ve geçirilecek, restore ve recover edilecek veritabanı parçalarının (datafile, controlfile) aynı isimle kalacağını gösteriyoruz. Passwordfile ve spfile opsiyonlarını kullanarak bu dosyaların da geçirilmesini, kopyalanmasını istediğimizi belirtiyoruz. Son noktada, bütün işlemler gerçekleştiği anda kopyalanan veritabanı RESETLOGS opsiyonu ile yeniden açılıyor. Buradaki en önemli nokta FROM ACTIVE DATABASE argümanının kullanılmasıdır. Bu argümanla birlikte RMAN'e aktif veritabanı çoğaltma işlemini yapacağımızı gösteriyoruz. Aksini yapmak istersek;

DUPLICATE TARGET DATABASE ORCL TO duplicate_database3
DBID 19031984     --> Kaynak veritabanının DBID'si
UNTIL TIME "TO_DATE('25/04/2011', 'DD/MM/YYYY')"
SPFILE
NOFILENAMECHECK;

DBID argümanını vermemizin nedenini şöyle açıklayabilirim; ORCL veritabanı adı bu operasyonu gerçekleştirdiğimiz recovery catalog içerisinde tekil değil. Bu sebepten dolayı hangi ORCL'den bahsettiğimizi göstermek zorundayız. NOFILENAMECHECK argümanını da birincil veritabanı ile uzak çoğaltılacak veritabanı arasında isimsel bir ilişki sorunu oluşmaması için yazdık. Bu şekilde bütün isimlendirmeler aynı olarak replikasyon gerçekleştirilecektir.

DUPLICATE komutu ile yalnızca bütün veritabanının taşınmasını değil, TABLESPACE argümanını vererek de hangi tablespace'leri kopyalamak istediğimizi gösterebilmekteyiz.

İyi çalışmalar dilerim.

Ogan

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

9 Nisan 2011 Cumartesi

TROUG Day 2011 - Program

Merhaba,

21 Nisan 2011'de Bahçeşehir Üniversitesi Beşiktaş kampüsünde gerçekleştirilecek birinci TROUG gününün programı ve sunumları belli oldu. O gün aramızda Jonathan Lewis de olacak.

Benim de Data Guard konusunda teknik bir sunum yapacağım günün ayrıntılarını buraya tıklayarak görebilirsiniz.

21 Nisan'da görüşmek dileğiyle!

İyi çalışmalar.

Ogan
Takip et: @oganozdogan