11g使用非duplicate方式创建物理standby要注意的问题总结

在上篇博文中，使用了duplicate方式来创建物理standby http://blog.csdn.net/aaron8219/article/details/38434579

今天来说说在11g中采用非duplicate方式创建备库碰到的一些问题，并做个总结。

在10g中，通常可以使以下几种方法创建备库控制文件

RMAN> backup current controlfile for standby format 'c:\ctl_%U';
RMAN> backup full database format 'c:\backup\full_%U' include current controlfile for standby;
RMAN> copy current controlfile for standby to 'c:\backup\control01.ctl';
SQL> alter database create standby controlfile as 'c:\backup\control01.ctl';

前两种生成的是备库控制文件的备份集，需要在nomount状态下，用RMAN命令restore，如：
SQL> startup nomount
RMAN> restore controlfile from 'c:\backup\xxxx';

而后两种是直接创建备库控制文件。一种是通过RMAN命令的方式，另一种是通过SQL命令的方式，创建出来的备库控制文件，可以直接复制到备库目标路径后用来启动备库到mount状态，如：
复制到C:\app\oracle\oradata\tc并冗余(CONTROL01.CTL,CONTROL02.CTL)后，可以直接在备库执行
SQL> startup mount --直接启动到mount状态，不需要RMAN恢复

但是在11g中，RMAN备份不再支持以“backup current controlfile for standby”或“include current controlfile for standby”来创建备库控制文件，虽然命令仍然可以执行成功，但是当你在备库恢复完控制文件并启动到mount状态下，你会发现这个控制文件依旧是主库的控制文件，如：
RMAN> restore controfile from 'c:\backup\xxxx';
RMAN> alter database mount;
SQL> select database_role from v$database;


DATABASE_ROLE
----------------
PRIMARY --注意，数据库角色是由控制文件决定的，这里是primary，说明是用主库控制文件启动的


如果没有注意到这点，那么当你恢复完数据库文件，并启用REDO APPLY的时候，就会报错，提示不是备用数据库。
所以，如果不是用duplicate方式来创建备库的话，要注意使用创建文件的方式直接生成备库控制文件，而不是生成RMAN备份集


上次使用了RMAN的duplicate方式来配置DG物理备库，那么这次就用非duplicate方式来做一次，其实步骤大致和10g是一致的，可以参考我以前搭建10g DG的博客，惟一不同的是，不再使用备份集来恢复备库控制文件


具体步骤(略)，直接跳到完成数据库数据文件恢复后


--查看备库的日志文件

SQL> set lin 120 pages 120
SQL> col member for a60
SQL> select group#,member from v$logfile;


    GROUP# MEMBER
---------- ------------------------------------------------------------
         2 C:\APP\ORACLE\ORADATA\TC\GROUP_2.262.855057605
         2 +FRA/tc/onlinelog/group_2.258.855057607
         1 C:\APP\ORACLE\ORADATA\TC\GROUP_1.261.855057597
         1 +FRA/tc/onlinelog/group_1.257.855057601
         3 C:\APP\ORACLE\ORADATA\TC\GROUP_3.266.855058587
         3 +FRA/tc/onlinelog/group_3.259.855058591
         4 C:\APP\ORACLE\ORADATA\TC\GROUP_4.267.855058593
         4 +FRA/tc/onlinelog/group_4.260.855058595
         5 C:\APP\ORACLE\ORADATA\TC\STB_REDO05.LOG
         6 C:\APP\ORACLE\ORADATA\TC\STB_REDO06.LOG
         7 C:\APP\ORACLE\ORADATA\TC\STB_REDO07.LOG
         8 C:\APP\ORACLE\ORADATA\TC\STB_REDO08.LOG
         9 C:\APP\ORACLE\ORADATA\TC\STB_REDO09.LOG


--对比一下主库的日志文件

SQL> set lin 120 pages 120
SQL> col member for a60
SQL> select group#,member from v$logfile;


    GROUP# MEMBER
---------- ------------------------------------------
         2 +DATA/tc/onlinelog/group_2.262.855057605
         2 +FRA/tc/onlinelog/group_2.258.855057607
         1 +DATA/tc/onlinelog/group_1.261.855057597
         1 +FRA/tc/onlinelog/group_1.257.855057601
         3 +DATA/tc/onlinelog/group_3.266.855058587
         3 +FRA/tc/onlinelog/group_3.259.855058591
         4 +DATA/tc/onlinelog/group_4.267.855058593
         4 +FRA/tc/onlinelog/group_4.260.855058595


由于主库没有创建备库日志文件，所以目前只有在线日志文件，共4组，分配给2个THREAD，每个THREAD使用2组，并且每组有2个MEMBER，一个放在+DATA，另一个放在+FRA

通过观察发现，此时在备库控制文件中记录的2个日志组位置，一个是通过LOG_FILE_NAME_CONVERT参数指定的从'+DATA/TC/ONLINELOG'转换到了'C:\APP\ORACLE\ORADATA\TC\'，但是并没有指定过'+FRA/TC/ONLINELOGFILE'，所以也就是现在看到的状态，+FRA那部分依然是主库的结构，但是备库是采用单实例本地磁盘的结构，并没有使用ASM磁盘组，那么这样2组日志，在备库应该怎么使用呢？

可以发现，其实此