进行各种配置之后，我们就可以进行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
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
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
Copyright (c) 1982, 2013, Oracle. All rights reserved.
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是我们必须掌握的能力。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17203031/viewspace-1142885/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/17203031/viewspace-1142885/
199
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
