Oracle’ ın dataguard ürünü disaster recovery senaryolarında önemli bir yer tutmaktadır. Dataguard basit mantıkla sizin productiondaki database’ inizin (belli kriterler altında) birebir eşleniğinin tutulmasını sağlar. Buda size production database’inizde bir problem olduğunda veya productionda yapacağınız bir patch geçişi veya upgrade operasyonunda kesintiye gerek bırakmadan işlem yapabilme imkanı sağlar. Dataguard kurulumlarında oracle versiyonlarındaki farklardan kaynaklanan bir takım farklılıklar olabilmektedir. Dolayısıyla bu tarz installion guide’ ları oluştururken versiyon bilgisi önemlidir.  Bu yazımda 10gR2 kurulu bir production sistemimiz üzerine physical standby database’ i nasıl kurabileceğimizden bahsedeceğim. Sonrasında da ayrı bir yazı ile aynı işlemi  11gR2 de içinde yazmayı planlıyorum.

Öncelikle dataguard kurabilmemiz için (10g için kıstlardan bahsediyoruz, 11g için kısıtlarda ciddi değişimler oldu) ön koşullar nedir ondan biraz bahsedelim. Kısıtlarımızı iki başlık altında toplayabiliriz. Hardware and Operating sistem & Software açısından kısıtlar.

Sunucu ve İşletim Sistemi Öngereksinimleri ;

• Production ve standby ortamların operating sistemleri aynı olmadır. Örneğin production 32 bit linux ise, dataguard kurulması planlanan ortamda 32 bit Linux olmalıdır.
• Her iki sunucu arasında donanım farklılıkları olabilir.  (cpu sayısı, disk büyüklükleri, ram sayıları farklı olabilir)  Burada şöyle bir problem olabilir, standby tarafındaki donanımlar primary sunucundan daha düşük kalır ise, herhangi bir failover durumunda standby tarafına geçilmesi gerektiğinde, performans anlamında bir sıkıntı yaşanabilir.
• Her iki sunucu üzerindeki işletim sistemi directory’ i yapısı aynı olmalıdır.  İşletim sistemleri versiyonlarının aynı olması gerekmez. Ek olarak, standby database’ inin veritabanı na ait directory yapısı primary database’ den farklı olabilir.

Oracle Software Gereksinimleri ;

• Dataguard kurulumun yapılabilmesi için primary sunucu mutlaka enterprise edition olmalıdır. Standart edition dataguardı desteklememektedir. Aynı oracle versiyonları her iki tarafa da kurulmuş olmalıdır.
• Compatible parametresi tüm database’ lerde aynı olmalıdır.
• Primary dayabase’ imiz mutlaka arhive modda olmalıdır.
• Primary database single instance olabileceği gibi Rac’ da olabilir.
• Her primary ve standby database’ in kendi control file’ i olmalıdır.
• Primary ve standby database’ lerini yönetmek için sysdba yetkilerine sahip olmalıdır.

Dataguard recovery operasyonlarında online redo log, archive log ve standby redo loglar kritik önem taşırlar.  Primary  database den iletilen redo dataları, standby da çalışan RFS process’i tarafından log arşiv dosyalarına veya standby redo log dosyalarına yazılmak üzere alınır. Bunlardan biraz bahsedetmek gerekirse;

Online Redo Logs;

Tüm primary ve logical standby database kurulumu, olası bir kurulum bozulmasına karşı korumak için online redo logları vardır. Fiziksel standby database kurulumları; I/O yu okuma veya yazma modunda açılmadığından online redo logları kullanmazlar. Değişimler physical standby database’ inde uygulanmaz dolayısıyla redo datası oluşturmazlar.

Archive Redo Logs;

Redo log arşivleri, standby ve primary databaseleri işlem (transaction) bazında tutarlı tutabilmek için gereklidir. Primary database’ ler, physical ve logical standby databaseler arşiv redo loglarını kullanırlar. Defaultta oracle database’leri  Archive modda çalışacak şekilde set edilmelidir böylece archiver processleri arşivlenmesi gereken redo datalarının kopyasını alarak arşive çıkartırlar.

Standby Redo Logs;

Standby redo loglar, online redo loglara sadece başka bir database’in  redo datalarını tutmaları dışında benzerdirler.

Physical ve Logical olmak üzere iki farklı şekilde Dataguard kurulumu bulunmaktadır. Bu yöntemler ve yapabilirlikleri ;

Physical Standby Database ;

Physical Standby database, primary database’ in  fiziksel olarak aynısıdır. Disk üzerindeki database yapılarıda primary database ile block bazında aynıdır. Database schema’ ları indexleri içerir ve bunlarda primary ile aynıdır.Dataguard, Physical standby  database’ in performansını Redo Apply ile sağlar.  Primary database’ inden gelen redo bilgileri mount modda apply edilir. Bu database’ i read only modda açmak isterseniz redo apply’ ini durdurmanız gerekmektedir. Physical standby’ı read write açmak isterseniz de database in Flashback modda olması gerekmektedir ki, sonrasında flashback database ile açıldığı noktaya tekrar dönmeniz gerekecektir.

Physical standby database,  tüm data type’ larını , ddl ve dml komutlarını desteklediğinden kullanımda en çok tercih edilen yöntem olduğunu söyleyebiliriz.

Physical standby database, sağlam ve verimli bir disaster recovery imkanıyla birlikte yüksek kullanılabilirliğe sahip olduğunu söyleyebiliriz.

Physical standby database, Primary ve physical standby database’ i arasında switchover ve failover operasyonlarını kolaylıkla yöneterek planlı ve plansız kesinti sürelerini en aza indirir.

Physical standby database, primary database’ i üzerindeki iş yükünü azaltmak amacıyla da kullanılabilir. Rman’ le alınan online backuplar buradan alınabilir. Read only açılabildiği durumlarda çok fazla cpu ve i/o kullanan query’ ler buraya kayrılabilir.

Logical Standby Database ;

Logical standby database, başlangıçta primary database’ in birebir kopyası olarak oluşturulur, fakat sonra farklı bir yapıda olacak şekilde değiştirilebilir.  Logical standby database sql komutlarının (primary den gelen) çalıştırılması ile update olur.  Sql apply işlemi veritabanı açıkken yapılamaktadır. Dolayısıyla buda kullanıcılara standby database’ den query ve raporlarlarını alabilmeleri için olanak sağlar. Logical standby database tüm data type’ larını desteklememektedir. Support etmediği data type’ları ; BFILE, Collections (including VARRAYS and nested tables), Encrypted columns, Multimedia data types (including Spatial, Image, and Context), ROWID, UROWID, User-defined types,  XMLType.

Dataguard kurulumu ile birlikte seçmemiz gereken bir data protection metodu olacaktır. Data protection mode 3 tanedir. Bundan da kısaca bahsettikden sonra kuruluma geçebiliriz.

• Maximum Protection ;

Bu modde sıfır veri kaybı hedeflenmektedir. Şöyleki primary database’ inde yapılan her bir değişilik standby tarafına anında uygulanır ve commit  edilinceye kadar beklenilir. Primary tarafında atılan her commit aynı anda standby tarafında atılmış demektir, primary tarafındaki commit’ in succes olması standby tarafında da succes olmasına bağlıdır. Eğer herhangi bir problem dolayı standby tarafında işlem başarısız olursa primary database’ i otomatik olarak down olur. Performans anlamında standby’ a bağlı olduğundan zaman zaman sıkıntılar yaşanması olası bir mode’ dur. Ancak verileriniz sizin için son derece kritik ise bu mode kullanılabilir.

• Maximum Availability ;

Bu mode aslında maximum protection ve maximum performance’ ın birleşimi gibi düşünülebilir. Burada da hedef öncelikli olarak sıfır veri kaybıdır. Ancak maximum protection’ dan farkı standy tarafında herhangi bir neden den dolayı problem çıkarsa primary kapanmıyor, protection mode’ ı değiştiriyor ve maximum performance’ a geçiyor.

• Maximum Performans ;

Her iki mode’ dan farklı olarak burada asıl önemli olan performans’ dır. Varsayılan pretection mode’ da maximum performansdır. Primary database tarafında yapılan işlemlerin sonrasında standby tarafındaki durumu ile ilgilenilmez. Yani iki sunucu veya database arasındaki problemlerden primary sunucu etkilenmez. Standby tarafında bir problem olsa dahi sorun giderildiğinde kaldığı yerden archive’ ları apply işlemine devam eder.

Bu özet bilgilerden sonra physical standby database’ imizi create etmeye başlayabiliriz ;

• Primary database’ imizi force logging moda alıyoruz;

Alter database force logging

Database altered

Bu komut ile daha önce nologging moda alınmış olan bir nesne var ise (log üretilmeyen) onlar geçerliliğini yitirecektir. Böylelikle yapılan her işleme ait log üretilmesi sağlanmaktadır. Kontrol etmek için ;

select force_logging from v$database;

• Primary database’ in archive modda olması gerekiyor.

Aşağıdaki script ile kontrol edebilirsiniz. Sonuç NOARCHIVELOG dönerse aşağıdaki adımları takip ederek archive moda alabilirsiniz.

select log_mode from v$database  ;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

• Primary database’ inde yok ise bir password file create edilir;

orapwd file=PWDist.ora password=oracle entries=5 force=Y

• Primary Database’ ine Standby Redo logların create ve configure edilmesi ;

Burada önerilen, primary database’ deki redo logların size’ ı ile standby için create edilecek redo log’ ların size’ larının aynı olmasıdır.  Kaç tane oluşturulacağını şu şekilde hesaplayabiliriz ;

Create Edilecek Standby Redo Log Sayısı = (maximum number of logfiles for each thread + 1) * maximum number of threads

Bir örnekle açıklayalım ;

Primary database’ indeki redo loglarımız,

SQL> select group#,THREAD#,BYTES,status from v$log;

GROUP#    THREAD#      BYTES STATUS

———- ———- ———- —————-

1          1   52428800 INACTIVE

2          1   52428800 INACTIVE

3          1   52428800 CURRENT

thread başına düşen log sayısı = 3

maximum number of thread = 1

Dolayısıyla create edilecek log sayısı = (3+1)*1 = 4

Bu örnek benim primary database’ im deki ile aynı dolayısıyla bende 4 tane standby redo logları create ediyorum.

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 (‘c:\oracle10g\standby_redo\standby_redo04.log’) SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 (‘c:\oracle10g\standby_redo\standby_redo05.log’) SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 (‘c:\oracle10g\standby_redo\standby_redo06.log’) SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 (‘c:\oracle10g\standby_redo\standby_redo07.log’) SIZE 50M

Database altered

Buradaki Group noları önemli, sıra ile devam etmesi gerekiyor, aralarda atlamalar olmayacak.

Primary database’ ine standby redolog ları neden oluşturuyoruz sorusuna, dataguard kurulumunda aslında buna gerek yok ama kurulumdan sonra herhangi bir zamanda switchover yapılmasında bu tarafında standby olarak hayatına devam edebilmesi için gereklidir.

Standby redologlar create edildikden sonra aşağıdaki sorgu ile kontrol edebiliriz ;

SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG

GROUP#    THREAD#        SEQUENCE#    ARCHIVED       STATUS

——          ——-               ———                        ——–              ———-

4           0                      0                      YES                  UNASSIGNED

5           0                      0                      YES                  UNASSIGNED

6           0                      0                      YES                  UNASSIGNED

7           0                      0                      YES                  UNASSIGNED

4 rows selected

• Primary database’ in initial parametrelerinin düzenlenmesi  ;

Redo logların transferi için primary database üzerinde bazı initial parametrelerinin düzenlenmesi gerekmektedir. Bunun yanısıra yine olası bir switchover durumunda hata alınmaması için (standby gibi davranabilmesi için)  bazı eklemelerinde yapılması faydalı olacaktır.

Bilmemiz gerekenler şunlar;

Primary database’ imin                           db_unique_name = dguard

Net_service_name = dguard

Standby database’ imin               db_unique_name = dguard1

Net_service_name = dguard1

Pfile’ de yapılacak olan değişiklerin bir kısmı zaten şu anki pfile’ inizde olan parametreler, kontrol etmeniz yeterli olacaktır.

DB_NAME, CONTROL_FILES, REMOTE_LOGIN_PASSWORDFILE  (exclusive olması gerekiyor), LOG_ARCHIVE_FORMAT (db archive modda olduğunda bu parametrede pfile’ inizde olacaktır.)

Aşağıdaki parametreleri ekliyoruz.

DB_UNIQUE_NAME=dguard

LOG_ARCHIVE_CONFIG=’DG_CONFIG=(dguard,dguard1)’

LOG_ARCHIVE_DEST_1=’location=D:\arch\ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dguard’

LOG_ARCHIVE_DEST_2=’SERVICE=dguard1 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dguard1′

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

LOG_ARCHIVE_MAX_PROCESSES=30

FAL_SERVER=dguard1

FAL_CLIENT=dguard

DB_FILE_NAME_CONVERT=’dguard1′,’dguard’

LOG_FILE_NAME_CONVERT=’ D:\arch \standby_arch’,’ D:\arch ‘

STANDBY_FILE_MANAGEMENT=AUTO

Log_archive_process’ si 30 olarak set ettim ben, oracle’ ın standby için önermiş olduğu process sayısı 30’ dır. Daha azda yapabilirsiniz.

• Primary database’ indeki dbf’ leri standby tarafına kopyalıyoruz. (bu işlemi rman’ i kullanarakda yapabilirsiniz  veya primary database’ i shutdown edip OS komutları ile diğer standby tarafına taşıyabilirsiniz.  Sadece datafile’ leri taşımanız yeterli olacaktır.

• Standby’ da kullanılmak üzere Primary database’ den standby control file create ediyoruz.

Shutdown immediate;

Startup mount

ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘c:\dguard1.ctl’;

ALTER DATABASE OPEN;

• Standby database’ i için primary database’ inden pfile create ediyoruz.

CREATE PFILE=’c:\initdguard1.ora’ FROM SPFILE;

• Standby tarafı için oluşturmuş olduğumuz pfile’ imizi aşağıdaki şekilde düzenliyoruz.

LOG_ARCHIVE_CONFIG=’DG_CONFIG=(dguard,dguard1)’

LOG_ARCHIVE_DEST_1=’LOCATION=D:\arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dguard1′

LOG_ARCHIVE_DEST_2=’SERVICE=dguard LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dguard’

STANDBY_FILE_MANAGEMENT=’AUTO’

remote_login_passwordfile=’EXCLUSIVE’

LOG_ARCHIVE_MAX_PROCESSES=30

LOG_FILE_NAME_CONVERT=’D:\arch’,’D:\arch\standby_arch’

LOG_ARCHIVE_DEST_STATE_1=’ENABLE’

LOG_ARCHIVE_DEST_STATE_2=’ENABLE’

log_archive_format=’arch_%t_%s_%r_.arc’

DB_UNIQUE_NAME=’dguard1′

FAL_CLIENT=’dguard1′

FAL_SERVER=’dguard’

DB_FILE_NAME_CONVERT=’dguard’,’dguard1′

db_name=’dguard’

• Primary ve standby sunucuların tns’ lerine her iki database’ in tns bilgilerinide ekliyoruz. (primary de standby’ ın tns bilgiside olması gerekiyor)  Listener dosyasına da primary için, standby database’ inin bilgilerini, standby içinde primary db’ in bilgilerini ekliyoruz.  Sonrasında her iki node üzerindeki listerları restart ediyoruz.

lsnrctl stop

Lsnrctl start

• Eğer windows bir sunucu üzerine dataguardımızı kurmaya çalışıyor isek, servis olarak yeni SID’ yi aşağıdaki gibi tanıtmamız gerekiyor. Diğer işletim sistemlerinde bu tarz bir işleme gerek yok.

oradim -NEW -SID DGUARD1 -INTPWD oracle1 -STARTMODE manual

• Standby sunucu üzerinde password file create ediyoruz.

orapwd file=PWDdguard1.ora password=oracle entries=5 force=Y

• Standby sunucumuz üzerinde üzerinde değişilik yapmış olduğumuz pfile’ den spfile create ediyoruz.

CREATE SPFILE FROM PFILE=’initDGUARD1.ora’;

Standby database’ imizi artık açabiliriz.

Startup mount

Apply’ ı başlatmak için;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Disconnect from session komutu tekrar sql satırına düşmenizi ve apply işleminin arka tarafda çalışmasını sağlar.

Aslında dataguard kurulumlarında bizim örneğimizde olduğu gibi standby database’ in SID’ si genelde primary ile aynı verilir. (ki bir disaster durumunda tekrar tüm kullanıcıların tns dosyalarını değiştirmeleri gerekmesin diye,  sadace standby’ ın ip’ si farklı olduğundan network ekibi tarafından ip yönlendirmesi –natlama- yapılır. )

Create ettiğimiz dataguardın çalışıp çalışmadığını test etmemiz gerekiyor. Bunun için primary database’i ndeki archive loglara bakıp, bunların standby tarafındaki durumlarını kontrol edebiliriz.

— Çıkan logları kontrol etmek için;

SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

FROM V$ARCHIVED_LOG

ORDER BY SEQUENCE#;

— Standby tarafında çıkan logların durumunu kontrol etmek için;

SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

Bu sorgu sonucunda Applied alanı YES olanlar primary database’ inden çıkmış olan redo verilerinin standby’ a apply edildiği anlamına gelmektedir.