逻辑STANDBY创建中碰到ORA-16146: standby destination control file enqueue unavailable

准备创建一个逻辑的STANDBY数据库供开发的查询生产数据使用，但是把物理的standby转换成逻辑standby的时候，碰到了ORA-16146: standby destination control file enqueue unavailable错误，于是故事开始。。。[@more@]

首先建好了物理的standby，然后使用语句alter database recover to logical standby dgl201把物理的standby转换成逻辑的standby，日志如下：
Sat Dec 22 09:00:20 2007
alter database recover to logical standby dgl201 --这里是开始转换的命令
Sat Dec 22 09:00:20 2007
Media Recovery Start: Managed Standby Recovery (billdb)--这里是首先开始的恢复
Sat Dec 22 09:00:20 2007
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 7 processes
Media Recovery Log /u02/stdlog/Arc_2_2189_592235202.arc--开始应用在做物理standby期间产生的日志
.....
Sat Dec 22 09:00:24 2007
Incomplete Recovery applied until change 3600776580--这里说明恢复到哪个scn，可是咋地会是一个不完全恢复呢？当时没注意到，写这篇文章时才注意到
Sat Dec 22 09:00:24 2007
Media Recovery Complete (billdb)--恢复完成
RESETLOGS after incomplete recovery UNTIL CHANGE 3600776580--开始resetlog
Resetting resetlogs activation ID 1538888656 (0x5bb993d0)
Online log /u02/oradata/billdb/redo1_01.log: Thread 1 Group 1 was previously cleared
.........
Standby became primary SCN: 3600776578
Sat Dec 22 09:00:30 2007
Setting recovery target incarnation to 2
Sat Dec 22 09:00:30 2007
WARNING: STANDBY_FILE_MANAGEMENT initialization parameter is not set to the value "AUTO".
This may cause recovery of the standby database to terminate
prior to applying all available redo data.
It may be necessary to use the ALTER DATABASE CREATE DATAFILE
command to add datafiles created on the primary database.
Converting standby mount to primary mount.
Sat Dec 22 09:00:30 2007
ACTIVATE STANDBY: Complete - Database mounted as primary (billdb)--把standby数据库转换成独立的库
*** DBNEWID utility started ***
DBID will be changed from 1519325762 to new DBID of 4181729902 for database BILLDB--转换数据库的dbid
DBNAME will be changed from BILLDB to new DBNAME of DGL201--转换数据库的名称
Starting datafile conversion
Setting recovery target incarnation to 1
Datafile conversion complete
Database name changed to DGL201.
Modify parameter file and generate a new password file before restarting.
Database ID for database DGL201 changed to 4181729902.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open with RESETLOGS option.--数据库宕下来，然后使用resetlog打开
Succesfully changed database name and ID.
*** DBNEWID utility finished succesfully ***
Completed: alter database recover to logical standby dgl201--切换完成。

然后数据库重新启动
ALTER DATABASE MOUNT
Sat Dec 22 09:02:40 2007
Setting recovery target incarnation to 1
Sat Dec 22 09:02:40 2007
Successful mount of redo thread 1, with mount id 4181760492
Sat Dec 22 09:02:40 2007
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Sat Dec 22 09:03:41 2007
alter database open resetlogs--数据库被resetlog
Sat Dec 22 09:03:41 2007
RESETLOGS after complete recovery through change 3600776581
Sat Dec 22 09:05:35 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
Sat Dec 22 09:07:35 2007
Errors in file /u01/app/oracle/admin/billdb/udump/billdb_rfs_8101.trc:
ORA-16146: standby destination control file enqueue unavailable
到这里出现了这个错误提示，而且后面还有很多这样的提示出现。无从下手了,只有看着错误越来越多，可是后面却出现了如下提示：
Sat Dec 22 09:21:43 2007
Setting recovery target incarnation to 2
Sat Dec 22 09:21:43 2007
RFS[1]: Assigned to RFS process 8339
RFS[1]: Identified database type as 'logical standby'--这里可以看到已经开始从主库取日志，并且认出了standby为逻辑的
Sat Dec 22 09:21:43 2007
RFS LogMiner: Client enabled and ready for notification
Sat Dec 22 09:21:43 2007
CHANGE TRACKING file DBID mismatch.--因为之前是使用这个物理standby做备份的，所以使用了rman中的tracking
Change tracking file contains DBID 4181742236.
Control file contains DBID 4181729902.--这个鬼地方很疑惑，为什么change tracking file的DBID的时候，转换出来的居然和控制文件中的不一样，而控制文件中的是和上面日志中出现的转换后的数据库中的DBID是一致的，可见是tracking中的DBID转错了。（这个也是后来才发现的）
Resetting change tracking file.
CHANGE TRACKING is reinitializing the change tracking file.

同时，还在metalink上查找了这个错误，说10g中可以忽略的，可以过的去的，晕菜。那就等它慢慢的过去吧，这时以为这个standby已经做好了，谁知道这才仅仅是开始，一会功夫，数据库连不上了，自己宕下来了，日志如下：
Sat Dec 22 09:21:45 2007
RFS LogMiner: Client enabled and ready for notification
Sat Dec 22 09:21:45 2007
RFS LogMiner: Client enabled and ready for notification
Sat Dec 22 09:21:48 2007
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb_ckpt_8030.trc:
ORA-00600: internal error code, arguments: [kctdsb_internal_02], [], [], [], [], [], [], []
Sat Dec 22 09:21:49 2007
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb_ckpt_8030.trc:
ORA-00600: internal error code, arguments: [kctdsb_internal_02], [], [], [], [], [], [], []
Sat Dec 22 09:21:49 2007
CKPT: terminating instance due to error 469
Instance terminated by CKPT, pid = 8030

然后重新启动几次，总是在数据库open后一会就出现上面的600错误，然后自己宕了，这下彻底挂了，于是到metalink上查找这个600错误，却说这个是一个unpublish的bug，没有提到任何的解决办法，只有升级数据库。重试了N次的重启后，还是每次就是600，然后就挂了，因为是CKPT使得数据库挂了，加上之前转换过程中open resetlog的时候很慢，估计scn不一致导致的。

后来看了日志，发现了上面rman的tracking的错误，于是把库打开后直接把这个tracking去掉，然后checkpoint切换了几次，没有问题，窃喜，以为搞定了，可是过了一会，又挂了，还是同样的600。最后还是转到原来的思路，既然是scn不一致，那就强制打开吧，设置了参数alter system set "_allow_resetlogs_corruption"=true scope=spfile，然后加上之前使用物理standby的管理方式来折腾的时候出现了需要恢复的提示，于是使用隐含参数打开后，就先进行了恢复操作：
SQL> alter database mount;

Database altered.

SQL> recover database using backup controlfile until cancel;
ORA-00283: recovery session canceled due to errors
ORA-19907: recovery time or SCN does not belong to recovered incarnation

SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

SQL> recover database using backup controlfile ;
ORA-00283: recovery session canceled due to errors
ORA-19907: recovery time or SCN does not belong to recovered incarnation

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

SQL> alter database open resetlogs;

Database altered.
这个时候open resetlog彻底的成功了，等了半天，切换过几次日志，没发现问题，然后设置开始日志的应用，看到最新的数据进来，问题得到了解决。

因为要做两台standby，另一台碰见了一摸一样的问题，于是直接设置隐含参数打开，然后recover database using backup controlfile until cancel;，然后再open resetlog，就直接ok了。

因为对standby和oracle理解不是很深，只知道这样可以把问题解决了，为什么这样就ok了呢，暂时未知。。。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25016/viewspace-995649/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25016/viewspace-995649/