2013年（350）
分类： Oracle
2013-04-28 10:09:07
为了贯彻优化地干活这一中心思想，三思决定通过的duplicate命令执行standby数据库的创建，在本节中你可以看到，只要一切配置OK，创建的操作简单到只需执行一条命令，是的，只有一条~~~~
不过，操作前其它的配置环节，工作还是必不可少的~~
要启动Standby端的实例，需要相应的初始化参数文件，这里我们可以通过Primary spfile创建出Standby的pfile，操作方法不需要多说了吧，最后修改的standby端pfile内容如下(注意确保相关路径的正确哟)：
*.audit_file_dest=¨/data/ora10g/admin/jssstd/adump¨
*.background_dump_dest=¨/data/ora10g/admin/jssstd/bdump¨
*.compatible=¨10.2.0.1.0¨
*.control_files=¨/data1/jssstd/control01.ctl¨,¨/data1/jssstd/control02.ctl¨,¨/data1/jssstd/control03.ctl¨
*.core_dump_dest=¨/data/ora10g/admin/jssstd/cdump¨
*.db_block_size=8192
*.db_domain=¨¨
*.db_file_multiblock_read_count=16
*.db_name=¨jssdb¨
*.db_unique_name=¨jssstd¨
*.job_queue_processes=10
*.log_archive_dest_1=¨location=/data1/jssstd/arclog valid_for=(all_logfiles,all_roles) db_unique_name=jssstd¨
*.open_cursors=300
*.pga_aggregate_target=94371840
*.processes=150
*.remote_login_passwordfile=¨exclusive¨
*.sga_target=283115520
*.undo_management=¨AUTO¨
*.undo_tablespace=¨UNDOTBS1¨
*.user_dump_dest=¨/data/ora10g/admin/jssstd/udump¨
提示一点，此时尚未添加任何与相关的初始化参数，接下来就要对此进行处理，增加参数如下：
*.log_archive_config=¨dg_config=(jssdb,jssstd)¨
*.standby_file_management=¨AUTO¨
*.db_file_name_convert=¨+ASMDISK1/jssdb/datafile¨,¨/data1/jssstd¨,¨+ASMDISK1/jssdb/tempfile¨,¨/data1/jssstd¨
*.log_file_name_convert=¨+ASMDISK1/jssdb/onlinelog¨,¨/data1/jssstd¨
*.fal_server=jssdb
*.fal_client=jssstd由于asm存储文件时自动进行了分目录处理，因此这里在设置db_file_name_convert参数时，也要注意设置相应的转换，否则可能导致文件创建时出错的，切记切记。
客户端初始化参数文件创建之后，就可以通过它创建Standby数据库的spfile，并启动实例了，如下：
SQL> create spfile from pfile=¨/data/ora10g/admin/jssstd/pfile/jssstd.ora¨;
File created.
SQL> startup nomount
ORACLE instance started.
Total System Global Area 285212672 bytes
Fixed Size 2083368 bytes
Variable Size 88081880 bytes
Database Buffers 188743680 bytes
Redo Buffers 6303744 bytes复制文件，包括Primary端创建的最新、Standby控制文件。最好是能在复制到Standby端时，保持与Primary端相同的目录结构，这样在恢复操作时会更简单一些，否则的话，再执行恢复前，还需要先用catalog注册这些备份，否则恢复时可能会提供找不到必要的备份。
密钥文件的密钥注意要保持与Primary端完全相同，或者直接复制Primary端的密钥文件过来，注意复制的话一定是要复制到standby端$ORACLE_HOME/dbs目录下，并注意按照命名规则修改名称！
重头戏来了，创建Standby数据库！这里三思不是通过备份恢复哟，而是决定通过rman的duplicate命令来实施创建，操作相当简单！
我们在Primary端执行创建，连接到RMAN命令行模式，执行命令如下：
[oracle@jssdbn2 ~]$ rman target / auxiliary sys/123456@jssstd
Recovery Manager: Release 10.2.0.4.0 - Production on Thu Apr 15 13:59:51 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: JSSDB (DBID=953576437)
connected to auxiliary database: JSSDB (not mounted)接下来只需要一条命令：
RMAN> duplicate target database for standby;
Starting Duplicate Db at 15-APR-10
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=156 devtype=DISK
allocated channel: ORA_AUX_DISK_2
channel ORA_AUX_DISK_2: sid=155 devtype=DISK
contents of Memory Script.
{
restore clone standby controlfile;
sql clone ¨alter database mount standby database¨;
}
executing Memory Script.
Starting restore at 15-APR-10
using channel ORA_AUX_DISK_1
using channel ORA_AUX_DISK_2
channel ORA_AUX_DISK_1: starting datafile backupset restore
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: reading from backup piece /data/backup/0glb6gts_1_1
channel ORA_AUX_DISK_1: restored backup piece 1
piece handle=/data/backup/0glb6gts_1_1 tag=TAG20100415T133555
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:05
output filename=/data1/jssstd/control01.ctl
output filename=/data1/jssstd/control02.ctl
output filename=/data1/jssstd/control03.ctl
Finished restore at 15-APR-10
sql statement: alter database mount standby database
released channel: ORA_AUX_DISK_1
released channel: ORA_AUX_DISK_2
contents of Memory Script.
{
set newname for tempfile 1 to
"/data1/jssstd/temp.265.703671701";
switch clone tempfile all;
set newname for datafile 1 to
"/data1/jssstd/system.260.703671683";
set newname for datafile 2 to
"/data1/jssstd/undotbs1.259.703671695";
set newname for datafile 3 to
"/data1/jssstd/sysaux.266.703671697";
set newname for datafile 4 to
"/data1/jssstd/undotbs2.258.703671705";
set newname for datafile 5 to
"/data1/jssstd/users.257.703671709";
set newname for datafile 6 to
"/data1/jssstd/jsstbs.269.703779631";
restore
check readonly
clone database
;
}
executing Memory Script.
executing command: SET NEWNAME
renamed temporary file 1 to /data1/jssstd/temp.265.703671701 in control file
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 15-APR-10
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=155 devtype=DISK
allocated channel: ORA_AUX_DISK_2
channel ORA_AUX_DISK_2: sid=156 devtype=DISK
channel ORA_AUX_DISK_1: starting datafile backupset restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /data1/jssstd/system.260.703671683
restoring datafile 00002 to /data1/jssstd/undotbs1.259.703671695
restoring datafile 00006 to /data1/jssstd/jsstbs.269.703779631
channel ORA_AUX_DISK_1: reading from backup piece /data/backup/0alb5tv2_1_1
channel ORA_AUX_DISK_2: starting datafile backupset restore
channel ORA_AUX_DISK_2: specifying datafile(s) to restore from backup set
restoring datafile 00003 to /data1/jssstd/sysaux.266.703671697
restoring datafile 00004 to /data1/jssstd/undotbs2.258.703671705
restoring datafile 00005 to /data1/jssstd/users.257.703671709
channel ORA_AUX_DISK_2: reading from backup piece /data/backup/0blb5tvj_1_1
channel ORA_AUX_DISK_1: restored backup piece 1
piece handle=/data/backup/0alb5tv2_1_1 tag=TAG20100415T081218
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:01:05
channel ORA_AUX_DISK_2: restored backup piece 1
piece handle=/data/backup/0blb5tvj_1_1 tag=TAG20100415T081218
channel ORA_AUX_DISK_2: restore complete, elapsed time: 00:01:09
Finished restore at 15-APR-10
contents of Memory Script.
{
switch clone datafile all;
}
executing Memory Script.
datafile 1 switched to datafile copy
input datafile copy recid=7 stamp=716401106 filename=/data1/jssstd/system.260.703671683
datafile 2 switched to datafile copy
input datafile copy recid=8 stamp=716401106 filename=/data1/jssstd/undotbs1.259.703671695
datafile 3 switched to datafile copy
input datafile copy recid=9 stamp=716401106 filename=/data1/jssstd/sysaux.266.703671697
datafile 4 switched to datafile copy
input datafile copy recid=10 stamp=716401106 filename=/data1/jssstd/undotbs2.258.703671705
datafile 5 switched to datafile copy
input datafile copy recid=11 stamp=716401106 filename=/data1/jssstd/users.257.703671709
datafile 6 switched to datafile copy
input datafile copy recid=12 stamp=716401106 filename=/data1/jssstd/jsstbs.269.703779631
Finished Duplicate Db at 15-APR-10Standby 创建完成！注意，我说的是Standby创建完成，没说Dataguard配置完成哟！接下来还有工作要做，首先要做的是检查Standby数据库的状态，开个sqlplus连接到Standby数据库，此时Standby应已处于mount模式：
[oracle@jssnode1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Apr 15 16:22:07 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> set line 150 pages 1000
SQL> select database_role,protection_level,open_mode from v$database;
DATABASE_ROLE PROTECTION_LEVEL OPEN_MODE
---------------- -------------------- ----------
PHYSICAL STANDBY MAXIMUM PERFORMANCE MOUNTED
SQL> select name from v$datafile;
NAME
------------------------------------------------------------------------------------------------------------------------------------------------------
/data1/jssstd/system.260.703671683
/data1/jssstd/undotbs1.259.703671695
/data1/jssstd/sysaux.266.703671697
/data1/jssstd/undotbs2.258.703671705
/data1/jssstd/users.257.703671709
/data1/jssstd/jsstbs.269.703779631
6 rows selected.
SQL> select name from v$tempfile;
NAME
------------------------------------------------------------------------------------------------------------------------------------------------------
/data1/jssstd/temp.265.703671701
SQL> select member from v$logfile;
MEMBER
------------------------------------------------------------------------------------------------------------------------------------------------------
/data1/jssstd/group_1.263.703671679
/data1/jssstd/group_2.261.703671681
/data1/jssstd/group_3.256.703672257
/data1/jssstd/group_4.268.703672257可上述结果可以看出，文件路径也均已被转换，其实这个结果从duplicate的日志就可以被得知，执行的查询更坚定的证实了这一点。对于正式环境，建议创建适当组数的standby redolog，以提高日志的应用效率。Standby redolog的创建和方式在一步一步学Dataguard中有详细描述，这里不再举例说明。
接下来要修改Primary数据库，以发送日志到Standby端，具体操作如下，连接到任意结点，然后执行下列语句：
SQL> alter system set log_archive_config=¨dg_config=(jssdb,jssstd)¨;
System altered.
SQL> alter system set log_archive_dest_2=¨service=jssstd lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=jssstd¨;
System altered.Primary 端切换一下日志：
SQL> alter system switch logfile;
System altered.
SQL> select thread#,max(sequence#) from v$archived_log group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 295
2 127转到Standby端执行查询：
SQL> select thread#,max(sequence#) from v$archived_log group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
2 127
SQL> select process,status,client_process,thread#,sequence# from v$managed_standby;
PROCESS STATUS CLIENT_P THREAD# SEQUENCE#
--------- ------------ -------- ---------- ----------
ARCH CONNECTED ARCH 0 0
ARCH CONNECTED ARCH 0 0
RFS IDLE UNKNOWN 0 0
RFS IDLE LGWR 2 128尝试启动应用，然后再次执行查询：
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> select process,status,client_process,thread#,sequence# from v$managed_standby;
PROCESS STATUS CLIENT_P THREAD# SEQUENCE#
--------- ------------ -------- ---------- ----------
ARCH CONNECTED ARCH 0 0
ARCH CONNECTED ARCH 0 0
RFS IDLE UNKNOWN 0 0
RFS IDLE LGWR 2 128
MRP0 WAIT_FOR_LOG N/A 1 291稍等片刻，standby即会开始寻找日志，就缺少的日志文件向主库请求获取，并逐个应用了！
SQL> select process,status,client_process,thread#,sequence# from v$managed_standby;
PROCESS STATUS CLIENT_P THREAD# SEQUENCE#
--------- ------------ -------- ---------- ----------
ARCH CONNECTED ARCH 0 0
ARCH CONNECTED ARCH 0 0
RFS IDLE UNKNOWN 0 0
RFS IDLE LGWR 2 128
MRP0 APPLYING_LOG N/A 1 292
RFS IDLE LGWR 1 296
RFS IDLE UNKNOWN 0 0Ok ，至此RAC数据库的Standby算是弄起来了，当然，这只是一个雏形，如果是生产环境，接下来需要考虑的因素还比较多，比如容灾策略、备份策略、归档发送策略等等。
