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 11gR1 ve 11gR2 de
yapmak istediğimizdeki farklara değinmeyi 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;
-- archive ile ilgili iki
önemli parametreyi set ediyoruz.
ALTER SYSTEM SET log_archive_format='arch_%t_%s_%r_.arc' SCOPE=spfile
ALTER SYSTEM SET log_archive_dest_1='location=D:\arch' SCOPE=spfile
·
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
tarafına da standby redologları eklememiz gerekiyor.
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
·
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 o
archive’ in standby’ a apply edildiği anlamına gelmektedir.
Hiç yorum yok:
Yorum Gönder