Oracle Data Guard Mimarisi ve Kurulumu
Data Guard Mimarisi
Data Guard, Oracle tarafından geliştirilmiş olan felaket kurtarma (disaster recovery) çözümüdür. Veri tabanını felaketlerden ve veri bozulmalarından kurtarmak için kullanılan bir sistemdir. Veriler ana veri tabanından standby veri tabanına sürekli aktarıldığından dolayı; ana veri tabanında herhangi bir problem olması durumunda, hızlı bir şekilde yedek veri tabanına geçiş yapılır. Kısaca Data Guard bir veri tabanının, başka bir veri tabanına anlık olarak kopyasının alınması ve herhangi bir arıza veya felaket durumunda kopya veri tabanının “production” olarak kullanılması şeklinde tanımlanır. Oracle veri tabanı uzmanlığı ile hazırladığımız bu yazımızda Oracle Data Guard Mimarisi ve kurulum aşaması hakkında bilgi verdik.
Data Guard; canlı veri tabanı dediğimiz primary veri tabanında oluşan redo kayıtlarını, yedek veri tabanı dediğimiz standby veri tabanına taşır ve taşınan bu redo veriler, standby veri tabanına “apply” edilerek primary veri tabanının güncel yedeğini oluşturur.
Redo verisi dediğimiz veri; primary veri tabanında meydana gelen “transactionlar” bütünüdür (Insert, Update, Delete, Create, Alter vb.). Primary veri tabanına gelen transactionların standby’a taşınıp, “apply” edilmesi demek; aynı transactionların standby tarafında da çalışması demektir.
LNS (Log Network Service); SGA (System Global Area) ’daki redo buffer alanındaki redo verilerini, ONS (Oracle Net Service) standby veri tabanına iletmek üzere gönderir. Gönderilen redo veriler, standby veri tabanında RFS (Remote File Service) background servisi tarafından alınır ve standby redo log dosyalarına işlenir. Bu dosyalar da redo apply işlemi ile standby veri tabanına işlenir.
Data Guard çalışma şekli, bir transaction üzerinden aşağıda belirtildiği üzere iki farklı madde halinde açıklanabilir.
Synchronous (Senkron) Data Guard
- Veri tabanında bir transaction başlatıldığı zaman; bu işlem öncellikle redo buffer alanına yazılır. Kullanıcı ilgili transaction’ı “commit” ettiği zaman; LGWR (Log Writer) process’i redo buffer alanındaki redo verilerini online redo log’lara yazar ve LNS process’i, redo verilerinin standby veri tabanına yazıldığına ilişkin doğrulama bekler.
(**Redo Log Buffer** Veri tabanı üzerideki bütün değişikliklerin saklandığı alandır ve en geç 3 saniyede bir verileri Online Redo Log dosyalarına yazar.)
(**Online redo log** Beklenmedik durumlar karşısında veri kaybını önlemek ve veri tabanını yeniden oluşturmakiçin veri tabanında olan değişikliklerin kaydını tutar. Bir veri tabanına en az 2 redo log gereklidir.)
(**LGWR (Log Writer)** Redo Log Buffer’daki bilgileri online redo log’lara yazmakla görevli background process’tir.)
- LNS (Log Network Service) process’i ise; aynı redo verilerini redo buffer alanından okur ve ONS (Oracle Net Service) üzerinden RFS (Remote File Service) process’ine bildirir. LNS process’i ilgili redo verilerine redo buffer’dan erişemezse otomatik olarak primary veri tabanının online redo log’larını okur.
- RFS Process’i ise aldığı redo verilerini standby redo log’larına yazar.
- MRP (Managed Recovery Process) process’i standby redo log’larında bulunan redo verilerini standby
- veri tabanına “apply” eder.
- Son olarak RFS process’i gönderilen redo verilerinin başarılı bir şekilde standby’a yazıldığının bilgisini LNS işlemine gönderir, LNS ise bu mesajı LGWR process’ine aktarır ve artık kullanıcıya “commit” işleminin başarılı olduğu bilgisi verilir..
Asynchronous (Asenkron) Data Guard
- Veri tabanında bir “transaction” başlatıldığı zaman bu işlem öncellikle redo buffer alanına yazılır. Bu “transaction” “commit” edildiği zaman; LGWR (Log Writer) process’i redo buffer alanındaki redo verilerini online redo log’larına yazar.
- LNS (Log Network Service) process’i ise; aynı redo verilerini redo buffer alanından okur ve ONS (Oracle Net Service) üzerinden RFS (Remote File Service) process’ine bildirir. LNS process’i, ilgili redo verilerine redo buffer’dan erişemezse otomatik olarak primary veri tabanının online redo log’larını okur.
- RFS process’i ise; aldığı redo verilerini standby redo log’larına yazar.
- Son aşamada ise MRP (Managed Recovery Process) process’i standby redo log’larında bulunan redo verilerini standby veri tabanına “apply” eder.
Asenkron Data Guard yönteminde; RFS işleminde redo verilerinin başarılı bir şekilde işlendiği bilgisi LNS’e gönderilmez. Bu yüzden Asenkron Data Guard yönteminde “sıfır veri kaybı” durumu yoktur, ve en az veri kaybı ile verilerin kurtarılması sağlanır.
Senkron Data Guard yönteminde ise; “commit” edilen tüm verilerin standby tarafına gönderildiği ve “apply” olduğu garanti edildiği için bu yöntemde “sıfır veri kaybı” durumu vardır.
Senkron Data Guard yönteminin, Asenkron Data Guard yöntemine göre bazı dezavantajları vardır. Bunlardan bir tanesi; Senkron Data Guard yönteminin, Asenkron Data Guard yöntemine göre daha az performanslı çalışmasıdır., Çünkü Senkron Data Guard yönteminde LGWR process’i her zaman LNS process’inden doğrulama bilgisi bekler; bu da süre kaybına yol açar. Ancak çok kritik verilerin bulunduğu veri tabanlarında, “sıfır veri kaybı” çözümüyle Asenkron Data Guard yöntemine göre avantajlıdır.
Hem primary hem de standby’da ortak kullanılan parametreler ve işlevleri aşağıdaki gibidir;
DB_UNIQUE_NAME: Veri tabanının “unique” namedir. “DB_NAME” parametresi her iki taraf için aynı olacaktır, fakat “DB_UNIQUE_NAME”ler farklı olmalıdır.
CONTROL_FILES: Burada veri tabanının fiziksel yapısı ile ilgili bilgiler (veri tabanının adı, veri dosyaları ve redo log dosyalarının yerleri ve adları, vb.) tutulur. Bir veri tabanı en az bir “control files” içerir. Bu değer primary’de primary veri tabanının, standby’da standby veri tabanın “control file” lokasyonunu gösterir.
LOG_ARCHIVE_CONFIG: Data Guard konfigürasyonu için seçilen veri tabanlarının “db_unique_name”lerinin belirtildiği parametredir. İlk olarak primary veri tabanının, ardından standby veri tabanının “db_unique_name”i yazılır.
LOG_ARCHIVE_DEST_n: Bu parametre primary veri tabanı için kullanılan önemli bir parametredir. Primary veri tabanından standby veri tabanına redo verisi göndermek için gerekli bir parametredir. “n” değeri bu parametre için 0’dan31’e kadardır. “Log_archive_dest_1” parametresi primary veri tabanının arşiv log’larının yerini gösterir, ve bundan sonraki “Log_archive_dest_2”den sonra gelen parametreler standby için konfigüre edilir.
LOG_ARCHIVE_MAX_PROCESSES: Data Guard konfigürasyonu için önemli parametrelerden birisidir. Veri tabanının bu işlem sırasında kullanabileceği maksimum ARCH process (Archiver Process)’inin sayısını belirler. Default’ta; 2 maksimum değeri 30’dur.
FAL_SERVER: Primary ile standby veri tabanı arasında redo GAP oluştuğu zaman arşiv log’larının hangi server’dan alınacağı bu parametre ile belirlenir.
Data Guard Kurulumu
Temel Data Guard Konfigürasyonu
Oracle Data Guard kurulumu yapabilmek için gereken şartlar aşağıdaki gibidir:
- Oracle veri tabanının “enterprise” sürüm olması
- İki sunucunun da işletim sistemi aynı olmalıdır.
- İki sunucunun içindeki “Oracle Software” aynı sürüm olmalıdır.
Şimdi sizlere RMAN (Recovery Manager ) backup restore yöntemiyle Oracle Data Guard kurulumunu anlatalım.
Primary tarafı; production tarafını ifade ediyorken, standby tarafı ise; kuracağımız 2.veri tabanı ortamı olan Data Guard’ı ifade ediyor. Her 2 tarafta da yaptığımız adımları ayrı ayrı aşağıda belirttik.
Öncelikle standby sunucuya “Oracle Software” kurulur. Daha sonra “netca” kullanılarak listener servisi oluşturulup başlatılır.
Primary Tarafta Yapılması Gerekenler
Primary ve Standby veri tabanlarındaki “/etc/hosts” dosyasına sunucuların bilgileri yazılır.
| $ vi /etc/hosts | ||
| 192.168.56.8 | orcl.localdomain | orcl |
| 192.168.56.12 | standby.localdomain | standby |
Primary veri tabanının arşiv log modu açık olmalıdır. Veri tabanı bütün aktiviteleri log’lamalıdır. Aşağıdaki komutla arşiv log modunun açık olup olmadığı kontrol edilir. “Disable” yani kapalı ise açılır.
SQL> select log_mode from v$database;
LOG_MODE
NOARCHIVELOG
Eğer veri tabanı arşiv mod’da değilse, veri tabanı kapatılır ve mount mod’da açılır. Veri tabanı arşiv mod’a alınır ve veri tabanı tekrar açılır.
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database arhivelog;
SQL> alter database open;
Veri tabanındaki bütün işlemlerin aşağıdaki komutla log’lanması sağlanır.
SQL> alter database force logging;
Standby veri tabanımız için standby redo log’larını oluşturuyoruz. Oluşturulacak olan standby redo log’ların boyutlarının mevcut online redo log’ların boyutlarıyla aynı olması gerekmektedir. Standby redo log’lar standby veri tabanlarında çalışırlar. Primary veri tabınında oluşturulması şartı yoktur. Fakat primary ve standby veri tabanlarının yer değiştirilmesi (switchover) işlemlerinden sonra düzgün çalışılabilmesi için; aynı şekilde standby redo log’larının primary veri tabanında da oluşturulması yararlı olacaktır.
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ‘/u01/app/oracle/ORCLDG/standby01.log’ size 50m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ‘/u01/app/oracle/ORCLDG/standby02.log’ size 50m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ‘/u01/app/oracle/ORCLDG/standby03.log’ size 50m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ‘/u01/app/oracle/ORCLDG/standby04.log’ size 50m;
Data Guard için parametreleri “set” edilerek, konfigürasyon işlemlerine başlanır. “LOG_ARCHIVE_CONFIG” parametresine ayarlanır. İlk olarak Primary veri tabanı “DB_UNIQUE_NAME”i yazılır ve ardından standby veri tabanı “DB_UNIQUE_NAME”i yazılır.
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG= DG_CONFIG=(ORCL,ORCLSTBY)’ scope=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=’SERVICE=ORCLSTBY LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCLSTBY’ SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
Veri tabanında “LOG_ARCHIVE_FORMAT”, “LOG_ARCHIVE_MAX_PROCESSES”, “REMOTE_LOGIN_PASSWORDFILE” parametreleri aşağıdaki gibi ayarlanır.
ALTER SYSTEM SET LOG_ARCHIVE_FORMAT=’%T_%S_%R.ARC’ SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30 SCOPE=BOTH;
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;
“Switchover” durumu düşünülerek veri tabanının geçişe hazır olması için aşağıdaki parametreler “set”lenir ve daha sonra veri tabanı yeniden başlatılır(Zorunlu değildir. “Switchover” yapılacaksa “set” edilir).
ALTER SYSTEM SET FAL_SERVER=ORCL_STBY SCOPE=BOTH;
ALTER SYSTEM SET FAL_CLIENT=ORCL SCOPE=BOTH;
connect target / run{
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH2 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH3 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH4 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH5 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH6 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH7 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH8 DEVICE TYPE DISK;
BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT ‘/u01/oracle/backup/FULL_%d_%u_%s_%T.bkp’;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL not backed up 1 times FORMAT ‘/u01/oracle/backup/Archivelogs_%d_%u_%s_%T.bkp’;
BACKUP CURRENT CONTROLFILE FORMAT ‘/u01/oracle/backup/CONTROLFILE%d_%u_%s_%T.bkp’;
RELEASE CHANNEL CH1;
RELEASE CHANNEL CH2;
RELEASE CHANNEL CH3;
RELEASE CHANNEL CH4;
RELEASE CHANNEL CH5;
RELEASE CHANNEL CH6;
RELEASE CHANNEL CH7;
RELEASE CHANNEL CH8;
Primary veri tabanından “FULL backup” alınır ve standby tarafına kopyalanr.
Standby veri tabanını nomount mod’da açmak için production veri tabanından pfile yaratılır. Yine standby veri tabanımız için control file oluşturulur. Oluşturulan control file, pfile ve file scp kullanılarak primary sunucusundan alınan; “rman backup” ve arşiv log’lar, standby sunucusuna kopyalanır.
SQL> create pfile=’/tmp/initorcl_stby.ora’ from spfile;
SQL> alter database create standby controlfile as ‘/tmp/orcl_stby.ctl’;
pfile
scp /tmp/initorcl_stby.ora oracle@192.168.56.12:/u01/app/oracle/product/19.0.0/dbhome_1/dbs/initorcl_stby.ora
#Password File
scp /u01/app/oracle/product/19.0.0/dbhome_1/dbs/orapwORCL oracle@192.168.56.12:/u01/app/oracle/product/19.0.0/dbhome_1/dbs/orapwORCLSTBY
#Rman Backup
scp -r /u01/oracle/backup/ oracle@192.168.56.12:/u01/app/oracle/backup
#Control File
scp /tmp/orclstby.ctl oracle@192.168.56.12:/u01/app/oracle/oradata/ORCL_STBY/controlfile/control01.ctl
Hem primary hem de standby sunucusunda “tnsnames.ora” dosyası düzenlenir. Primary sunucusuna standby, standby sunucusuna primary sunucu bilgileri eklenir.
$> vi $ORACLE_HOME/network/admin/tnsnames.ora
ORCL = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orcl.localdomain)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
)
)
ORCL_STBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby.localdomain)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
)
)
“Tnsping” ile kontrol edilir sorun yoksa devam edilir.
Yaratılan “initorcl_stby.ora (pfile)” dosyasında standby veri tabanı için düzenlemeler yapılır. Data Guard kurulumu için “DB_UNIQUE_NAME” parametresi eklenir ve “db_name”e farklı bir isim verilir. Eksik directoryler “create” edilir.
$> vi /tmp/initorcl_stby.ora
*.db_name=’orclstby’
*.db_unique_name=’ORCL_STBY’
*.fal_server=’ORCL’
*.log_archive_dest_1=’SERVICE=orcl ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=ORCL’
Standby Tarafında Yapılması Gerekenler
Primary’dan alınan pfile dosyası düzenlenir. Özellikle Data Guard kurulumu için “db_unique_name”parametresi eklenir ve “db_name”e farklı bir isim verilir. Eksik olan dizinler yaratılır.
$> mkdir -p /u01/app/oracle/oradata/ORCL_STBY
$> mkdir -p /u01/app/oracle/fast_recovery_area/ORCL_STBY/
$> mkdir -p $ORACLE_BASE/admin/$ORACLE_SID/adump
Listener yeniden başlatılır.
$> lsnrctl stop
$> lsnrctl start
YA DA
$> lsnrctl reload
Bash profile düzenlenir.
Primary veri tabanından alınıp kopyalanan veri yedeklenir.
SQL> startup nomount pfile=’pfile.ora’
Primary’den alınan standby control file “restore” edilerek, Standby veri tabanı mount mod’a getirilir. Backup’lar “catalog start with” ile veri tabanına tanıtılır, ardından veri tabanı “restore” edilir.
$> rman target /
RMAN> restore standby controlfile from ‘/u01/oracle/backup/standbycontrol.ctl’;
RMAN> alter database mount;
RMAN> catalog start with ‘/u01/oracle/backup/’;
connect target /
run{
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH2 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH3 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH4 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH5 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH6 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH7 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH8 DEVICE TYPE DISK;
restore database;
RELEASE CHANNEL CH1;
RELEASE CHANNEL CH2;
RELEASE CHANNEL CH3;
RELEASE CHANNEL CH4;
RELEASE CHANNEL CH5;
RELEASE CHANNEL CH6;
RELEASE CHANNEL CH7;
RELEASE CHANNEL CH8;
}
Standby veri tabanı için MRP (Managed Recovery Process) process’i başlatılır ve log’ların işlenmesi sağlanır.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Data Guard sağlıklı çalışıyor mu kontrol edelir.
Primary Veri Tabanında;
SQL> SELECT DATABASE_ROLE, OPEN_MODE, SWITCHOVER_STATUS FROM V$DATABASE;
Standby Veri Tabanında;
SQL> SELECT DATABASE_ROLE, OPEN_MODE, SWITCHOVER_STATUS FROM V$DATABASE;
Primary tarafında;
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
PROCESS
DGRD
ARCH
DGRD
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
PROCESS
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
PROCESS
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
LNS
PROCESS
DGRD
LNS
STATUS
ALLOCATED
CLOSING
ALLOCATED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
STATUS
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
STATUS
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CLOSING
CONNECTED
CONNECTED
CONNECTED
CONNECTED
OPENING
STATUS
ALLOCATED
WRITING
Standby tarafında;
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
PROCESS
RFS
ARCH
DGRD
DGRD
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
PROCESS
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
PROCESS
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
LNS
PROCESS
RFS
MRP0
RFS
STATUS
IDLE
CONNECTED
ALLOCATED
ALLOCATED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
STATUS
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
STATUS
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
STATUS
IDLE
APPLYING_LOG
IDLE
Standby veri tabanına arşiv log dosyalarının “apply” edilip edilmediği, aşağıdaki Scriptle Data Guard “monitor” edilerek anlaşılır.
SQL> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#;
Oracle Data Guard Mimarisi hakkında bilgi vererek, kurulumunu detaylı bir şekilde anlattık. Konu hakkında detaylı bilgi almak için Türkiye’nin en yetkin Oracle sertifikalı ekibimize ulaşabilirsiniz.
Yazar:
Gökhan Kalem, GTech Sistem ve Veri Tabanı Yönetimi Teknik Danışmanı
