邏輯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了呢，暫時未知。。。