关于10g DG中的ORA-19527和ORA-00312错误解决示例
这几天在搭建10g DG Windows 2008 R2的测试环境，主要是明天要去给一客户重新搭建一套生产库的DG，其中发现一些问题，特此记录一下
由于将要部署到生产环境，所以考虑在线搭建DG的方案，即不停库的情况下，而问题主要就是出在不停库时，用RAMN创建STANDBY的时候
通常在线搭建DG，主要是下面几个步骤：
1. 确保主库开启归档(生产库基本都是开启的)，并开启force logging模式
SQL> select database_role,log_mode,force_logging from v$database;
SQL> alter database force logging; --force_logging可以在线修改，而不像开启归档必须在mount状态修改
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\ora10g\adump
C:\oracle\product\10.2.0\admin\ora10g\bdump
C:\oracle\product\10.2.0\admin\ora10g\cdump
C:\oracle\product\10.2.0\admin\ora10g\dpdump
C:\oracle\product\10.2.0\admin\ora10g\pfile
C:\oracle\product\10.2.0\admin\ora10g\udump
红色部分必须写，因为已经在pfile中指定了具体的路径
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），就以为可以不设置了
引用一段官方的解释：
Cause
This is in fact an enhancement to the Dataguard product in 10gR2 ..
The goal here is to improve speed of switchover. Before this a switchover would require to clear the online logfiles before we can become a primary. In this release we attempt to clear the online logfiles when starting Managed Recovery.
If the files exist then they will be cleared, but if they do not exist we report the error and the MRP does not fail.
As an extra enhancementif the online redo logs do exist you must specify the log_file_name_convert parameter even if there is no difference in the name. This has been implemented to reduce the chances that the primary online redo logs are cleared when MRP starts. It is the equivalent of asking - Are you sure you want the logs to be called this....
If the log_file_name_convert parameter is not set then the ORA-19527 is reported and the log file is not cleared at this time..
Solution
Solution to stop both of these errors is to create the online redo logs andensure log_file_name_convert is set.
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:49:21 2014alter database recover managed standby database disconnect from session
MRP0 started with pid=16, OS id=2548
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 2 processes
Thu Jul 17 10:49:26 2014
Waiting for all non-current ORLs to be archived...
Thu Jul 17 10:49:26 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员
ORA-00312: 联机日志 1 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO01.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu Jul 17 10:49:26 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员
ORA-00312: 联机日志 1 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO01.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Clearing online redo logfile 1 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO01.LOG--开始清除REDO01.LOG
Clearing online log 1 of thread 1 sequence number 64
Thu Jul 17 10:49:26 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员
ORA-00312: 联机日志 1 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO01.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu Jul 17 10:49:27 2014
Completed: alter database recover managed standby database disconnect from session
Thu Jul 17 10:49:27 2014
Clearing online redo logfile 1 complete --清除online redo logfile 'REDO01.LOG' 完毕，此时会在oradata目录生成一个REDO01.LOG文件
Thu Jul 17 10:49:27 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
ORA-00312: 联机日志 2 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO02.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu Jul 17 10:49:27 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
ORA-00312: 联机日志 2 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO02.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Clearing online redo logfile 2 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO02.LOG --开始清除REDO02.LOG
Clearing online log 2 of thread 1 sequence number 65
Thu Jul 17 10:49:27 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
ORA-00312: 联机日志 2 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO02.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Clearing online redo logfile 2 complete --清除online redo logfile 'REDO02.LOG' 完毕，此时会在oradata目录生成一个REDO02.LOG文件
Thu Jul 17 10:49:28 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 3 (用于线程 1) 的成员
ORA-00312: 联机日志 3 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO03.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu Jul 17 10:49:28 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 3 (用于线程 1) 的成员
ORA-00312: 联机日志 3 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO03.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Clearing online redo logfile 3 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO03.LOG--开始清除REDO03.LOG
Clearing online log 3 of thread 1 sequence number 66
Thu Jul 17 10:49:28 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\bdump\ora10g_mrp0_2548.trc:
ORA-00313: 无法打开日志组 3 (用于线程 1) 的成员
ORA-00312: 联机日志 3 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO03.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Clearing online redo logfile 3 complete --清除online redo logfile 'REDO03.LOG' 完毕，此时会在oradata目录生成一个REDO03.LOG文件
Media Recovery Waiting for thread 1 sequence 66
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的日志了