Merhaba Arkadaşlar,
Bu yazımda sizlere Oracle Data Guard ile Fiziksel standby kurulumunu anlatacağım bir önceki yazımda Oracle Data Guard a giriş yaptığım için bu yazımda genel kavramlardan bahsetmeyeceğim.
Oracle Data Guard teknolojisi ile veritabanlarımızda Physical ve Logical Standby lar oluşturabiliriz ben bu yazımda en çok kullanılan Physical Standby konfigürasyonunu ve kurulumunu Linux sunucu üzerindeki Oracle 11.2.0.3 veritabanını kullanarak anlatacağım.
Yazıya başlamadan önce bu kısımdan sonra Primary veritabanımız için önceki yazımda da belirttiğim TESTDB adını kullanacağım. TESTDB Primary veritabanım için oluşturacağım Physical Standby ( Disaster Recovery ) database in adı da TESTDBFKM olacaktır. Physical Standby kurulumu için Konfigürasyon ve kurulumu adım adım ilerleyeceğim.
1- Standby veritabanı sunucusunda Primary veritabanı ile software ve Patchset versiyonları aynı olacak bir Oracle Software kurulmalıdır. ( DBCA ile Veritabanı OLUŞTURULMAMALI. Ör: Primary veritabanınız 11.2.0.3 ise Standby veritabanıda 11.2.0.3 olmalıdır )
2- Standby veritabanı sunucusunda Oracle Software ile beraber NETCA ile oluşturulacak olan Physical standby ı dinleyecek bir Listener oluşturulmalı.
3- Primary veritabanı mutlak surette Archivelog modunda olması gerekiyor. Archivelog modu için ayrıntılı bilgiyi ilgili şu yazımdan okuyabilirsiniz. Database in arşiv modunda olup olmadığını aşağıdaki sorguyla öğrenebilirsiniz.
SELECT log_mode FROM v$database; LOG_MODE ------------ ARCHIVELOG SQL>
Benim kurulumu yaptığım Test veritabanım Arşiv modunda, sorgu sonucu NOARCHIVELOG dönenler yukardaki linkteki yazıdan database lerini arşiv moduna alabilirler.
4- Primary veritabanında meydana gelen ( TEMP Tablespace i dışındaki ) tüm değişikliklerin loglanıp Standby a işlenmesi gerekmektedir. Primary veritabanındaki tüm değişiklerin loglanabilmesi için aşağıdaki komut Primary de çalıştırılmalıdır.
SQL> alter database force logging; Database altered.
5- Primary veritabanında Data Guard için gerekli bazı parametreleri set ediyoruz bu parametrelerin ne olduğunu önceki yazımda anlattığım için burda tekrar anlatmayıp sadece ilgili değişikliklerin nasıl olduğunu aşağıda vereceğim. Aşağıdaki parametre değişikliğini yaptıktan sonra statik parametrelerden dolayı veritabanı kapatılıp açılmalıdır. Veritabanını kapatıp açmayı bilmeyenler ilgili şu yazımı okuyabilirler.
SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(TESTDB,TESTDBFKM)'; System altered. SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=TESTDBFKM LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=TESTDBFKM'; System altered. SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=/oracle/DATA/TESTDB/ARCH/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=TESTDB'; System altered. SQL> alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE; System altered. SQL> alter system set FAL_SERVER=TESTDBFKM; System altered. SQL> alter system set FAL_CLIENT=TESTDB; System altered. SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=20; System altered. SQL> ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE; System altered. SQL> alter system set DB_FILE_NAME_CONVERT='/oracle/DATA/TESTDBFKM/TESTDBFKM','/oracle/DATA/TESTDB/TESTDB' scope=spfile; System altered. SQL> alter system set LOG_FILE_NAME_CONVERT='/oracle/DATA/TESTDBFKM/TESTDBFKM','/oracle/DATA/TESTDB/TESTDB' scope=spfile; System altered.
6-Her iki databasede de tnsnames.ora dosyasına ilgili veritabanlarının tns adresleri aşağıdaki gibi girilir ve tnsping işlemi uygulanır. Tnsnames.ora dosyası linux sunucularda $ORACLE_HOME/network/admin dizini altında bulunur.
TESTDB = (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=192.168.2.10) (PORT=1521) ) (CONNECT_DATA= (SERVER=dedicated) (SID=TESTDB) ) ) TESTDBFKM = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.11)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = TESTDBFKM)) ) bash-4.1$ tnsping TESTDBFKM bash-4.1$ tnsping TESTDB
7- Primary veritabanının password dosyası Standby tarafına standby adıyla aşağıdaki gibi kopyalanır.
bash-4.1$ scp orapwTESTDB oracle@192.168.2.11:/oracle/product/11.2.0/db/dbs/orapwTESTDBFKM
8-Standby veritabanında adump isimli klasörü aşağıdaki gibi manuel olarak oluşturuyorum. Veritabanı açılışta bu dosyayı göremezse hata alır.
bash-4.1$ mkdir $ORACLE_BASE/admin/$ORACLE_SID/adump
9- Şimdi son olarak Standby sunucusunda Standby veritabanı için bir pfile oluşturup henüz olmayan veritabanını nomount modda ayağa kaldırmaya çalışıyoruz 🙂 Burda aslında nomount modda instance ayağa kalkıp background process leri sadece çalışacak. bundan sonraki adımlarda database i Primary den duplicate edeceğiz.
bash-4.1$ vi initTESTDBFKM.ora
Bu adımda istersek pfile ın içine aşağıdaki 3 parametreyi ekleyip geri kalan parametreleri rman duplicate başlatırken ekleyip başlatırız istersekte pfile ın içine bu parametreleri yazıp rman duplicate de sadece duplicate işlemini başlatırız. Ben pfile dosyasına aşağıdaki 3 parametreyip ekleyip Oracle Instance sını nomount moduyla aşağıdaki gibi açıyorum.
*.DB_NAME=TESTDB *.DB_UNIQUE_NAME=TESTDBFKM *.DB_BLOCK_SIZE=8192
Sunucu üzerinden profile dosyası set edildikten sonra Instance sı nomount modda başlatıyoruz.
bash-4.1$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 12 13:09:39 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to an idle instance. SQL> startup nomount ORACLE instance started. Total System Global Area 659730432 bytes Fixed Size 2231272 bytes Variable Size 394265624 bytes Database Buffers 255852544 bytes Redo Buffers 7380992 bytes SQL>
10- Son olarak Primary database i üzerinden RMAN toolu ile duplicate işlemini aşağıdaki gibi başlatıyoruz.
bash-4.1$ rman target sys/sys@TESTDB auxiliary sys/sys@TESTDBFKM
Her iki tarafın RMAN ine bağlandıktan sonra duplicate işlemini aşağıdaki script ile başlatıyorum.
RMAN> run{
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate channel prmy3 type disk;
allocate channel prmy4 type disk;
allocate auxiliary channel stby type disk;
duplicate target database for standby from active database
spfile
parameter_value_convert 'TESTDB','TESTDBFKM'
set db_unique_name='TESTDBFKM'
set db_file_name_convert='/oracle/DATA/TESTDB/TESTDB','/oracle/DATA/TESTDBFKM/TESTDBFKM'
set log_file_name_convert='/oracle/DATA/TESTDB/TESTDB','/oracle/DATA/TESTDBFKM/TESTDBFKM'
set control_files='/oracle/DATA/TESTDBFKM/TESTDBFKM/control01.ctl'
set log_archive_max_processes='5'
set fal_client='TESTDBFKM'
set fal_server='TESTDB'
set standby_file_management='AUTO'
set log_archive_config='dg_config=(TESTDB,TESTDBFKM)'
set log_archive_dest_2='service=TESTDB ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=TESTDB';
}
Yukardaki RMAN Duplicate scripti çok fazla çıktı üretecektir isterseniz bunu bir log dosyasına yazdırıp her adımını inceleyebilirsiniz. Karşılaştırmanız açısından son kısmının çıktısını aşağıda veriyorum çıktı bu şekilde değilde error lar vermişse eğer muhtemelen bir hata yada eksiklik yapmışsınızdır.
. . . datafile 1 switched to datafile copy input datafile copy RECID=2 STAMP=837509470 file name=/oracle/data/POCDBFKM/system01.dbf datafile 2 switched to datafile copy input datafile copy RECID=3 STAMP=837509470 file name=/oracle/data/POCDBFKM/sysaux01.dbf datafile 3 switched to datafile copy input datafile copy RECID=4 STAMP=837509470 file name=/oracle/data/POCDBFKM/undotbs01.dbf datafile 4 switched to datafile copy input datafile copy RECID=5 STAMP=837509470 file name=/oracle/data/POCDBFKM/users01.dbf datafile 5 switched to datafile copy input datafile copy RECID=6 STAMP=837509470 file name=/oracle/data/POCDBFKM/example01.dbf Finished Duplicate Db at 12-JUN-14 RMAN>
Bu işlemin sonucunda Standby database ine bağlanıp MRP (Managed Recovery Process) process ini başlatıp ilgili logların işlenmesini başlatıyorum.
bash-4.1$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 12 16:57:40 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> select instance_name from v$instance; INSTANCE_NAME ---------------- TESTDBFKM SQL> alter database recover managed standby database disconnect from session; Database altered. SQL>
Duplicate işlemi başarılı bir şekilde gerçekleştikten sonra her iki sunucunun rolünü ve logların işlenip işlenmediği ilgili process lerin ayakta olup olmadığını aşağıdaki gibi sorgulayıp Dataguard kurulumunun başarılı olup olmadığını teyit ediyoruz.
Primary Veritabanı -------------- bash-4.1$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Sat Jul 12 17:00:26 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> select instance_name from v$instance; INSTANCE_NAME ---------------- POCDB SQL> select switchover_status,database_role from v$database; SWITCHOVER_STATUS DATABASE_ROLE -------------------- ---------------- TO STANDBY PRIMARY SQL> Standby Veritabanı ------------------- bash-4.1$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Sat Jul 12 17:02:26 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> select instance_name from v$instance; INSTANCE_NAME ---------------- POCDBFKM SQL> select switchover_status,database_role from v$database; SWITCHOVER_STATUS DATABASE_ROLE -------------------- ---------------- NOT ALLOWED PHYSICAL STANDBY SQL> SQL> select process, client_process,thread#,sequence#,status from v$managed_standby; PROCESS CLIENT_P THREAD# SEQUENCE# STATUS --------- -------- ---------- ---------- ------------ ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED MRP0 N/A 1 17 WAIT_FOR_LOG RFS UNKNOWN 0 0 IDLE RFS UNKNOWN 0 0 IDLE ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED PROCESS CLIENT_P THREAD# SEQUENCE# STATUS --------- -------- ---------- ---------- ------------ ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED ARCH ARCH 0 0 CONNECTED RFS UNKNOWN 0 0 IDLE RFS UNKNOWN 0 0 IDLE RFS UNKNOWN 0 0 IDLE RFS LGWR 1 17 IDLE PROCESS CLIENT_P THREAD# SEQUENCE# STATUS --------- -------- ---------- ---------- ------------ RFS UNKNOWN 0 0 IDLE RFS UNKNOWN 0 0 IDLE RFS UNKNOWN 0 0 IDLE RFS UNKNOWN 0 0 IDLE RFS UNKNOWN 0 0 IDLE RFS ARCH 0 0 IDLE 28 rows selected. SQL>
Yukarıda her bir veritabanının Dataguard daki rolünü ve background process lerle işlemin başarılı bir şekilde gerçekleştiğini teyit ettim. Böylece örnek bir senaryo üzerinden Primary database imin Disaster Recovery veritabanını oluşturmuş olduk. Bir sonraki yazıda görüşmek dileğiyle esen kalın..
Oracle Exadata SQL Server Goldengate Weblogic EBS ve Linux konusunda aşağıdaki konularda 7×24 Uzman Danışmanlara yada Eğitimlere mi İhtiyacınız var mehmet.deveci@gridgroup.com.tr adresine mail atarak Bizimle iletişime geçebilirsiniz.
– Oracle Veritabanı Danışmanlığı
– Oracle Veritabanı Bakım ve Destek
– Exadata Danışmanlığı
– Exadata Bakım ve Destek
– SQL Server Veritabanı Danışmanlığı
– SQL Server Veritabanı Bakım ve Destek
– Goldengate Danışmanlığı
– Goldengate Bakım ve Destek
– Linux Danışmanlığı
– Linux Bakım ve Destek
– Oracle EBS Danışmanlığı
– Oracle EBS Bakım ve Destek
– Weblogic Danışmanlığı
– Weblogic Bakım ve Destek
– Oracle Veritabanı Eğitimleri
– Oracle VM Server Danışmanlığı
– Oracle VM Server Bakım ve Destek
– Oracle EPPM Danışmanlığı
– Oracle EPPM Bakım ve Destek
– Oracle Primavera Danışmanlığı
– Oracle Primavera Bakım ve Destek
– Oracle Eğitimleri
– SQL Server Eğitimleri
– Goldengate Eğitimleri
– Exadata Eğitimleri
– Linux Eğitimleri
– Oracle EBS Eğitimleri
– Oracle VM Server Eğitimleri
– Weblogic Eğitimleri
– Oracle EPPM Eğitimleri
– Oracle Primavera Eğitimleri