这几天在搭建10g DG Windows 2008 R2的测试环境，主要是明天要去给一客户重新搭建一套生产库的DG，其中发现一些问题，特此记录一下

由于将要部署到生产环境，所以考虑在线搭建DG的方案，即不停库的情况下，而问题主要就是出在不停库时，用RAMN创建STANDBY的时候

通常在线搭建DG，主要是下面几个步骤：

1. 确保主库开启归档，并开启force logging模式

2. 主库在线修改spifle，alter system set .... scope=both;并创建pfile

首先要确保所需修改的参支持在线修改，可以查看视图v$parameter

SQL> select distinct issys_modifiable from v$parameter;


ISSYS_MODIFIABLE
---------------------------
DEFERRED
FALSE
IMMEDIATE

说明：
DFERRED：动态参数，修改后对当前活跃的session无效
FALSE：静态参数，修改后需重启数据库
IMMEDIATE：动态参数，修改后立即对所有session生效

SQL> select name,issys_modifiable,value from v$parameter where name='xxxx'; xxxx为要修改的参数名

在需要改的几个参数中，只有db_unique_name不支持在线修改

SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(ora10gpd,ora10gst)' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ora10gpd' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=ora10gst LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ora10gst' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_STATE_2=ENABLE scope=both;
SQL> alter system set FAL_SERVER=ora10gst scope=both;
SQL> alter system set FAL_CLIENT=ora10gpd scope=both;
SQL> alter system set STANDBY_FILE_MANAGEMENT='AUTO' scope=both;

所以如果生产库想不停库搭建DG的话，那么就要使用原有的db_unique_name，通常和db_name是同一个名字

修改完spfile以后，用它创建一个pfile，供备库使用，create pfile from spfile;

3. 主库创建standby redo logfile，alter database add standby logfile group # datafile ('xxxx') size 50M; xxxx指定路径和文件名

4.创建listener.ora和tnsnames.ora，把生成的文件复制到备库相应位置并修改

5. 主库创建备库控制文件、数据文件、归档日志文件备份集

rman target /
RMAN> backup full database format 'c:\backup\full_%d_%I_%U' include current controlfile for standby plus archivelog format 'c:\backup\arc_%d_%I_%U';
或者：
run
{
allocate channel d1 type disk;
backup format 'C:\backup\df_%d_%I_%U' database;
sql 'alter system archive log current';
backup format 'C:\backup\al_%d_%I_%U' archivelog all;
backup current controlfile for standby format 'C:\backup\cf_%d_%I_%U';
release channel d1;
}

6. 把pfile参数文件，密码文件，拷贝到备库%ORACLE_HOME%\database\下

7. 创建备库实例(ora10g)及相关目录

C:\Users\Administrator>oradim -new -sid ora10g

C:\oracle\product\10.2.0\fast_recovery_area
C:\oracle\product\10.2.0\admin\
C:\oracle\product\10.2.0\admin\adump
C:\oracle\product\10.2.0\admin\bdump
C:\oracle\product\10.2.0\admin\cdump
C:\oracle\product\10.2.0\admin\dpdump
C:\oracle\product\10.2.0\admin\pfile
C:\oracle\product\10.2.0\admin\udump

8. 把主库备份集拷贝到备库并进行恢复，主要是3个步骤

① nomount状态下恢复备库控制文件， RMAN> restore controlfile from 'C:\backup\xxxx'; xxxx为含有备库控制文件的备份片名称

② mount状态下恢复数据库，RMAN> restore database;

③ 恢复备库归档日志文件，RMAN> restore archivelog all;

或在做完第①步后，在主库open，备库nomount状态下连接到RMAN执行：
rman target sys/oracle@ora10gpd auxiliary /
run
{
allocate channel C1 device type disk;
allocate auxiliary channel C2 device type disk;
duplicate target database for standby nofilenamecheck;
release channel C1;
release channel C2;
}

9. 备库创建standby redo logfile，大小位置需和主库一致

10. 完成恢复并启动mpr0进程，即启用redo apply，alter database recover managed standby database disconnect from session;

如果一切顺利，那么此时备库就会开始逐一应用主库传过来的归档日志文件

但，事实没有这么简单，在我实际做下来的结果是，主库的redo log日志文件无法传递到备库，备库的alert log日志会报 ORA-19527 和 ORA-00312 错误，如下：

ORA-19527: 必须重命名物理备用重做日志
ORA-00312: 联机日志 1 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO01.LOG'

这是由于10g以后，oracle为了加快swtichover的速度，在can become a primary之前就去clear the online logfiles了，而如果没有设置log_file_name_convert，这个时候oracle可能就不能识别哪怕是冷备copy过来的路径文件名都一模一样的redo logfile，解决方案就是在主库参数中添加log_file_name_convert，原来没有用这个参数，是因为主备库的log日志文件路径都一样（因为用了同一个数据库实例名ora10g）

SQL> alter system set log_file_name_convert='C:\oracle\product\10.2.0\oradata\ora10g','C:\oracle\product\10.2.0\oradata\ora10g' scope=spfile;

log_file_name_convert 这个参数非在线可修改，必须重启后才能生效：

这就有点尴尬，生产库就必须重启一下，也就是说必须停一下库，哪怕只是几分钟，不过当设置完成，重启standby，apply日志以后，看到alert log日志中果然可以看到clear online logfiles了，问题得到解决

备库alert log日志会提示以下内容：

Thu Jul 17 10:51:25 2014

注意看备库告警日志中提示的开始清除redo logfile的时间和下图window目录中这几个文件创建的时间，就是在清除在线日志文件的你那一刻，在备库生成了相应的文件。

也就是说，当启用redo apply 的时候，备库先会提示无法读取参数中配置的在线日志文件，那后就会去清除该日志，并自动生成该文件，就是这么个过程

当然，alert log还会继续提示也不存在sandby redo logfile，如下：

Media Recovery Waiting for thread 1 sequence 66
Thu Jul 17 10:51:25 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 2100
RFS[2]: Identified database type as "physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:51:25 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\udump\ora10g_rfs_2100.trc:
ORA-00313: 无法打开日志组 4 (用于线程 1) 的成员
ORA-00312: 联机日志 4 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\STDREDO04.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

这个standby redo logfile和online redo logfile又有些不同，如果碰到无法打开，数据库不会去清除并自动创建，而是需要我们手动去创建

但可以从v$log视图中发现，该文件是已经存在于备库控制文件中的（因为主库在创建备库控制文件备份的时候，就已经创建好了嘛），那就无法用语句再创建一次，会提示该文件已存在（而实际上物理并不存在），可以先drop掉，再重新创建，如果添加或删除主库online redo logfile，那么需要先把standby_file_management参数的值改为manual，之后再改回auto

如果standby redo logfile配置有问题，那么当切换保护模式到maximize availability或maximize protection时，会报：

ORA-16072: a minimum of one standby database destination is required

此时即使已经配置了LOG_ARCHIVE_DEST_2中已经配置了LGWR SYNC AFFIRM，open数据库时会报：

ORA-03113: end-of-file on communication channel

这是因为，最高可用和最大保护这两种模式必须使用LGWR进程来写到standby redo logfile，如果这个条件不能保证，那么就无法打开数据库，强制断开与数据库的链接，以提供对数据库的最大范围的安全保护

等这些日志都顺利在备库建立后，备库就可以开始同步应用主库归档日志了：

Thu Jul 17 10:51:25 2014
RFS[1]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_66_9WGGKFWB_.ARC'
Thu Jul 17 10:51:30 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_66_9WGGKFWB_.ARC
Thu Jul 17 10:51:50 2014
RFS[2]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_67_9WGGKFVT_.ARC'
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:52:16 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_67_9WGGKFVT_.ARC
Media Recovery Waiting for thread 1 sequence 68 (in transit)
Thu Jul 17 10:57:20 2014
RFS[2]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_68_9WGGL635_.ARC'
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:57:22 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_68_9WGGL635_.ARC
Media Recovery Waiting for thread 1 sequence 69 (in transit)
Thu Jul 17 10:57:35 2014
RFS[2]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_69_9WGGWJCK_.ARC'
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:57:38 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_69_9WGGWJCK_.ARC
Media Recovery Waiting for thread 1 sequence 70 (in transit)
Thu Jul 17 10:57:51 2014
RFS[2]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_70_9WGGWZ9C_.ARC'
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:57:53 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_70_9WGGWZ9C_.ARC
Media Recovery Waiting for thread 1 sequence 71 (in transit)

可以看到，此时 sequence 70已经在备库上应用，在等待主库传sequence 71的日志了