左右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 archivelogformat '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參数文件，password文件。复制到备库%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日志会提示下面内容：

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日志