進行各種配置之後，我們就可以進行duplicate過程了。

7、RMAN進行duplicate操作

構建physical standby的方法，歷代Oracle版本是有不同的方法，而且這些方法是向下相容的。也就是說，舊版本standby構建方法在新版本下是可以的。而且，一些方法還有比較強的實用場景。

11g Oracle推出了使用RMAN進行active database的構建方法，在主庫不停機的情況下也能進行持續的standby構建。傳統需要單獨準備的引數檔案和控制檔案，也可以透過指令碼方法方式進行整理。

在standby例項啟動的時候，我們只是設定了db_name引數。其他Data Guard相關的引數，是需要在RMAN執行過程中進行配置的。在過去的版本中，這些引數是需要手工設定的。

準備指令碼程式：

run {

duplicate target database for standby from active database

spfile

parameter_value_convert 'ora11g','ora11gsy'

set db_unique_name='ora11gsy'

set control_files='/u01/app/oradata/ORA11GSY/controlfile/ora11gsby01.ctl'

set db_file_name_convert='ORA11G','ORA11GSY'

set log_file_name_convert='ORA11G','ORA11GSY'

set log_archive_max_processes='5'

set fal_client='ora11gsy'

set fal_server='ora11g'

set standby_file_management='AUTO'

set log_archive_config='dg_config=(ora11g,ora11gsy)'

set log_archive_dest_2='service=ora11g async valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=ora11g';

}

這裡有一些注意點：control_files是必須加入的，表示standby資料庫的控制檔案方法。其他DG相關引數在指令碼中都有所涉及。Log_archive_dest_2中配置的valid_for專案，表示資料庫在primary_role角色的時候才會向主庫ora11g傳遞日誌的。

將指令碼儲存為檔案，cr_standby_script。

[oracle@SimpleLinux dbs]$ ls -l | grep cr

-rw-r--r--. 1 oracle oinstall 653 Apr 13 13:31 cr_standby_script

啟動RMAN進行duplicate，連線target和auxiliary。

[oracle@SimpleLinux dbs]$ rman nocatalog

Recovery Manager: Release 11.2.0.4.0 - Production on Sun Apr 13 13:32:18 2014

RMAN> connect target sys/oracle@ora11g

connected to target database: ORA11G (DBID=4239941846)

using target database control file instead of recovery catalog

RMAN> connect auxiliary sys/oracle@ora11gsy

connected to auxiliary database: ORA11GSY (not mounted)

執行指令碼：

RMAN> @cr_standby_script

RMAN> run {

2> duplicate target database for standby from active database

3> spfile

4> parameter_value_convert 'ora11g','ora11gsy'

5> set db_unique_name='ora11gsy'

6> set control_files='/u01/app/oradata/ORA11GSY/controlfile/ora11gsby01.ctl'

7> set db_file_name_convert='ORA11G','ORA11GSY'

8> set log_file_name_convert='ORA11G','ORA11GSY'

9> set log_archive_max_processes='5'

10> set fal_client='ora11gsy'

11> set fal_server='ora11g'

12> set standby_file_management='AUTO'

13> set log_archive_config='dg_config=(ora11g,ora11gsy)'

14> set log_archive_dest_2='service=ora11g async valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=ora11g';

15> }

Starting Duplicate Db at 13-APR-14

allocated channel: ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: SID=19 device type=DISK

（篇幅原因，有省略……）

input datafile copy RECID=3 STAMP=844781878 file name=/u01/app/oradata/ORA11GSY/datafile/o1_mf_undotbs1_9mnjs068_.dbf

datafile 4 switched to datafile copy

input datafile copy RECID=4 STAMP=844781878 file name=/u01/app/oradata/ORA11GSY/datafile/o1_mf_users_9mnjs074_.dbf

Finished Duplicate Db at 13-APR-14

RMAN> **end-of-file**

指令碼沒有報錯，執行成功。

8、DG測試

下面，我們檢查一下安裝DG效果。在standby端，可以登入資料庫檢查狀態。

[oracle@SimpleLinux dbs]$ env | grep ORACLE_SID

ORACLE_SID=ora11gsy

SQL> select name, open_mode, database_role from v$database;

NAME OPEN_MODE DATABASE_ROLE

--------- -------------------- ----------------

ORA11G MOUNTED PHYSICAL STANDBY

Standby預設情況下，是維持mounted狀態。主庫此時狀態如下：

SQL> select name, open_mode, database_role from v$database;

NAME OPEN_MODE DATABASE_ROLE

--------- -------------------- ----------------

ORA11G READ WRITE PRIMARY

注意：我們修改主庫資料，是在scope=spfile基礎上。重啟主庫：

SQL> startup force

ORACLE instance started.

Total System Global Area 372449280 bytes

Fixed Size 1364732 bytes

Variable Size 301993220 bytes

Database Buffers 62914560 bytes

Redo Buffers 6176768 bytes

Database mounted.

Database opened.

檢查資料庫DG傳遞，首先檢查log_archive_dest狀態。如果顯示valid，就表示已經聯通。

SQL> select dest_id, dest_name, status, binding, archiver, destination from v$archive_dest;

DEST_ID DEST_NAME STATUS BINDING ARCHIVER DESTINATION

---------- -------------------- --------- --------- ---------- ---------------------------

1 LOG_ARCHIVE_DEST_1 VALID MANDATORY ARCH USE_DB_RECOVERY_FILE_DEST

2 LOG_ARCHIVE_DEST_2 VALID OPTIONAL LGWR ora11gsy

同步情況，透過v$archived_log檢視中檢視，注意其中的applied列。如果傳遞到standby端，並且應用上apply，資料為Yes。

SQL> select sequence#, name, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where standby_dest='YES' order by sequence#;

SEQUENCE# NAME STANDBY_DEST ARCHIVED APPLIED

---------- ---------- ------------ -------- ---------

6 ora11gsy YES YES NO

7 ora11gsy YES YES NO

8 ora11gsy YES YES NO

啟動同步，要在standby資料庫中啟動操作。Apply是一個持續的過程，我們啟動連線操作一定要加入disconnect from session命令，這樣就可以在後臺進行應用執行動作。

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered

主庫各歸檔日誌應用情況如下：

SQL> select sequence#, name, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where standby_dest='YES' order by sequence#;

SEQUENCE# NAME STANDBY_DEST ARCHIVED APPLIED

---------- ---------- ------------ -------- ---------

6 ora11gsy YES YES YES

7 ora11gsy YES YES YES

8 ora11gsy YES YES YES

9 ora11gsy YES YES NO

Standby端中的歸檔日誌，也可以看到應用過程。

SQL> select sequence#, name, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log order by sequence#;

SEQUENCE# NAME STANDBY_DEST ARCHIVED APPLIED

---------- -------------------------------------------------------------------------------- ------------ -------- ---------

6 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_13/o1_mf_1_6_9nn99r20_.a NO YES YES

7 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_13/o1_mf_1_7_9nn99k17_.a NO YES YES

8 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_13/o1_mf_1_8_9nn99qff_.a NO YES YES

9 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_13/o1_mf_1_9_9nn9zxyx_.a NO YES IN-MEMORY

同步成功！

9、同步測試

下面我們透過一個簡單實驗來驗證資料庫同步動作。在scott使用者下建立一個資料庫表。

SQL> conn scott/tiger@ora11g

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.4.0

Connected as scott

SQL> create table t_psby as select * from dba_objects;

Table created

SQL> select count(*) from t_psby;

COUNT(*)

----------

86032

切換到standby庫，在mount狀態中是不能讀取的，需要首次的open資料庫。但是實驗室失敗的。

[oracle@SimpleLinux ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Sun Apr 13 14:05:26 2014

SQL> conn / as sysdba

Connected.

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-10456: cannot open standby database; media recovery session may be in

Progress

當前我們在應用日誌同步的狀態。在進行同步的時候，是不能open的。我們需要首先將這個日誌同步動作cancel中。

SQL> conn / as sysdba

Connected.

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> alter database open;

Database altered.

Scott使用者資料表建立。

SQL> conn scott/tiger@ora11gsy

Connected.

SQL> select count(*) from t_psby;

COUNT(*)

----------

86032

主庫資料表新增資料，進行修改。

SQL> insert into t_psby select * from dba_objects;

86032 rows inserted

SQL> commit;

Commit complete

SQL> select count(*) from t_psby;

COUNT(*)

----------

172064

此時standby庫，並沒有同步。因為我們剛剛關閉cancel同步。下面啟動同步過程，接受新的資料。

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

SQL> select open_mode from v$database;

OPEN_MODE

--------------------

READ ONLY WITH APPLY

SQL> select count(*) from scott.t_psby;

COUNT(*)

----------

172064

同步成功！注意：在11g中，READ ONLY WITH APPLY狀態表示在同步同時，也可以應用資料庫Redo Log。如果是之前的版本，資料庫需要恢復到mount狀態。這個也就是11g中Advanced

10、結論

Oracle 11g Data Guard被稱為Active Data Guard，是一個重要的升級版本。對我們而言，DG是一種最簡單的HA策略。用好DG是我們必須掌握的能力。

Oracle 11gR2 Active DataGuard配置Step By Step（三）

相關文章