ORA-600(2662)錯誤的重制和解決（二）

前兩天同僚在測試DATA GUARD的時候将主庫的ONLINE日志意外覆寫，造成資料庫無法打開，采用隐含參數的方法打開又碰到ORA-600錯誤，最後采用設定EVENTS的方式解決。

由于是在别人的機器上操作，而且很多操作都是摸索進行，是以沒有将操作記錄下來。現在打算重制一下問題并簡單記錄解決過程。

上篇已經描述了問題的産生步驟，下面描述解決這個問題的方法。

産生問題的根源在于啟動STANDBY資料庫的時候，覆寫了PRIMARY資料庫的線上LOGFILE。

嘗試恢複資料庫：

SQL> CONN /@YTK AS SYSDBA

已連接配接到空閑例程。

SQL> STARTUP MOUNT

ORACLE 例程已經啟動。

Total System Global Area  251658240 bytes

Fixed Size                  1290012 bytes

Variable Size             167772388 bytes

Database Buffers           75497472 bytes

Redo Buffers                7098368 bytes

資料庫裝載完畢。

SQL> RECOVER DATABASE UNTIL CANCEL;

ORA-00279: 更改 5706539056 (在 12/11/2007 15:49:26 生成) 對于線程 1 是必需的

ORA-00289: 建議: E:\ORACLE\ORADATA\YTK\ARCHIVELOG\ARC01333_0577472831.001

ORA-00280: 更改 5706539056 (用于線程 1) 在序列 #1333 中

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

CANCEL

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出現如下錯誤

ORA-01194: 檔案 1 需要更多的恢複來保持一緻性

ORA-01110: 資料檔案 1:

'E:\ORACLE\ORADATA\YTK\DATAFILE\O1_MF_SYSTEM_1TDY2CXS_.DBF'

ORA-01112: 未啟動媒體恢複

看來資料庫已經無法通過正常方式啟動了。這時候最好的辦法是通過資料庫的備份來進行恢複，通過不完全恢複來恢複資料庫。

但是同僚當時沒有資料庫的備份，那麼就隻能通過非正常的方式打開了。

由于丢失線上日志，是以隻能通過添加隐含參數的方式：

SQL> ALTER SYSTEM SET "_allow_resetlogs_corruption" = TRUE SCOPE = SPFILE;

系統已更改。

SQL> SHUTDOWN IMMEDIATE

ORA-01109: 資料庫未打開

已經解除安裝資料庫。

ORACLE 例程已經關閉。

Variable Size             171966692 bytes

Database Buffers           71303168 bytes

SQL> RECOVER DATABASE UNTIL CANCEL

SQL> ALTER DATABASE OPEN RESETLOGS;

ALTER DATABASE OPEN RESETLOGS

*

第 1 行出現錯誤:

ORA-01092: ORACLE 執行個體終止。強制斷開連接配接

檢查alert檔案：

ALTER DATABASE   MOUNT

Tue Dec 11 17:16:19 2007

Setting recovery target incarnation to 1

Successful mount of redo thread 1, with mount id 160883103

Database mounted in Exclusive Mode

Completed: ALTER DATABASE   MOUNT

Tue Dec 11 17:16:46 2007

ALTER DATABASE RECOVER  DATABASE UNTIL CANCEL 

Media Recovery Start

 parallel recovery started with 2 processes

ORA-279 signalled during: ALTER DATABASE RECOVER  DATABASE UNTIL CANCEL  ...

Tue Dec 11 17:16:49 2007

ALTER DATABASE RECOVER    CANCEL 

ORA-1547 signalled during: ALTER DATABASE RECOVER    CANCEL  ...

Tue Dec 11 17:16:51 2007

ALTER DATABASE RECOVER CANCEL

ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...

Tue Dec 11 17:17:00 2007

Tue Dec 11 17:17:01 2007

RESETLOGS is being done without consistancy checks. This may result

in a corrupted database. The database should be recreated.

Errors in file e:\oracle\admin\ytk\udump\ytk_ora_2412.trc:

ORA-00265: 要求執行個體恢複, 無法設定 ARCHIVELOG 模式

Archive all online redo logfiles failed:265

RESETLOGS after incomplete recovery UNTIL CHANGE 5706539056

Resetting resetlogs activation ID 97264511 (0x5cc237f)

Online log E:\ORACLE\ORADATA\YTK\ONLINELOG\REDO01.LOG: Thread 1 Group 1 was previously cleared

Online log E:\ORACLE\ORADATA\YTK\ONLINELOG\REDO02.LOG: Thread 1 Group 2 was previously cleared

Online log E:\ORACLE\ORADATA\YTK\ONLINELOG\REDO03.LOG: Thread 1 Group 3 was previously cleared

Setting recovery target incarnation to 2

Tue Dec 11 17:17:02 2007

Assigning activation ID 160883103 (0x996e19f)

LGWR: STARTING ARCH PROCESSES

ARC0 started with pid=18, OS id=2904

ARC0: Archival started

ARC1: Archival started

ARC1 started with pid=19, OS id=2584

Tue Dec 11 17:17:03 2007

LGWR: STARTING ARCH PROCESSES COMPLETE

LNS1 started with pid=20, OS id=3328

Tue Dec 11 17:17:06 2007

Thread 1 advanced to log sequence 2

Thread 1 opened at log sequence 2

  Current log# 2 seq# 2 mem# 0: E:\ORACLE\ORADATA\YTK\ONLINELOG\REDO02.LOG

Successful open of redo thread 1

ARC1: Becoming the 'no FAL' ARCH

ARC1: Becoming the 'no SRL' ARCH

ARC0: Becoming the heartbeat ARCH

ARC1: LGWR is scheduled to archive destination LOG_ARCHIVE_DEST_2 after log switch

ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (270)

ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned

Tue Dec 11 17:17:07 2007

Errors in file e:\oracle\admin\ytk\bdump\ytk_arc1_2584.trc:

ORA-00270: 建立歸檔日志  時出錯

ARC1: Error 270 Closing archive log file 'ytks'

******************************************************************

LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

SMON: enabling cache recovery

Tue Dec 11 17:17:08 2007

ORA-00600: 内部錯誤代碼, 參數: [2662], [1], [1411571767], [1], [1411576360], [4194309], [], []

Tue Dec 11 17:17:11 2007

Error 600 happened during db open, shutting down database

USER: terminating instance due to error 600

Errors in file e:\oracle\admin\ytk\bdump\ytk_lns1_3328.trc:

ORA-00600: 内部錯誤代碼, 參數: [], [], [], [], [], [], [], []

Errors in file e:\oracle\admin\ytk\bdump\ytk_p001_1936.trc:

ORA-00600: 内部錯誤代碼, 參數: [15784], [600], [], [], [], [], [], []

Errors in file e:\oracle\admin\ytk\bdump\ytk_p000_576.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_pmon_3424.trc:

ORA-00600: ??????, ??: [], [], [], [], [], [], [], []

Tue Dec 11 17:17:12 2007

Errors in file e:\oracle\admin\ytk\bdump\ytk_psp0_1720.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_mman_3256.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_lgwr_3528.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_ckpt_2696.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_dbw0_2148.trc:

Tue Dec 11 17:17:14 2007

Errors in file e:\oracle\admin\ytk\bdump\ytk_reco_1928.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_smon_1940.trc:

Instance terminated by USER, pid = 2412

ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS...

現在出現了前文提到的ORA-600[2662]錯誤。

查詢metalink，Oracle給出了兩種解決方法，如果600的2662錯誤中第三個參數和第五個參數差别很小，那麼就可以通過多次打開關閉資料庫執行個體的方式來增加SCN的值。

不過這種方式每次啟動隻SCN隻增加1，重新開機三次系統：

ORA-00600: 内部錯誤代碼, 參數: [2662], [1], [1411571770], [1], [1411576360], [4194309], [], []

而目前的SCN和期望的SCN還相差4000多，顯然通過重新開機的方法不現實。

Oracle給出的第二種方式是通過設定EVENTS來提高Oracle的CURRENT SCN，這個方法的前提就是設定_allow_resetlogs_corruption隐含參數為true：

Variable Size             209715428 bytes

Database Buffers           33554432 bytes

SQL> ALTER SESSION SET EVENTS '10015 TRACE NAME ADJUST_SCN LEVEL 1';

會話已更改。

SQL> ALTER DATABASE OPEN;

ALTER DATABASE OPEN

ORA-00314: 日志 2 (用于線程 1) 要求的序号 2 與 0 不比對

ORA-00312: 聯機日志 2 線程 1: 'E:\ORACLE\ORADATA\YTK\ONLINELOG\REDO02.LOG'

資料庫并沒有打開，而是報錯ORA-314。這個錯誤倒是很容易了解，由于目前的日志被STANDBY資料庫的重置歸檔所覆寫，造成了這個期望的日志和目前的不滿足。

下面将三個連接配接日志改名，使PRIMARY資料庫找不到聯機日志：

E:\>CD E:\ORACLE\ORADATA\YTK\ONLINELOG

E:\oracle\oradata\YTK\ONLINELOG>MOVE REDO01.LOG REDO01.LOG.BAK

E:\oracle\oradata\YTK\ONLINELOG>MOVE REDO02.LOG REDO02.LOG.BAK

E:\oracle\oradata\YTK\ONLINELOG>MOVE REDO03.LOG REDO03.LOG.BAK

再次嘗試打開：

ORA-00313: 無法打開日志組 2 (用于線程 1) 的成員

ORA-27041: 無法打開檔案

OSD-04002: 無法打開檔案

O/S-Error: (OS 2) 系統找不到指定的檔案。

報錯找不到檔案，通過RESETLOGS方式建立新的日志：

ORA-00279: 更改 5706539077 (在 12/12/2007 14:17:14 生成) 對于線程 1 是必需的

ORA-00289: 建議: E:\ORACLE\ORADATA\YTK\ARCHIVELOG\ARC00002_0641139429.001

ORA-00280: 更改 5706539077 (用于線程 1) 在序列 #2 中

再次嘗試設定EVENTS：

Variable Size             218104036 bytes

Database Buffers           25165824 bytes

ERROR:

ORA-03113: 通信通道的檔案結束

錯誤和剛才已經有差別了，看來有打開的希望，檢查alert檔案發現：

ORA-00316: ?? 2 (???? 1) ?????? 0 ??????

ORA-00312: ???? 2 ?? 1: 'E:\ORACLE\ORADATA\YTK\ONLINELOG\REDO02.LOG'

Wed Dec 12 14:45:55 2007

Errors in file e:\oracle\admin\ytk\bdump\ytk_lgwr_3712.trc:

LGWR: terminating instance due to error 316

Errors in file e:\oracle\admin\ytk\bdump\ytk_lns1_3508.trc:

ORA-00316: 日志  (用于線程 ) 頭部中的類型  不是日志檔案

Errors in file e:\oracle\admin\ytk\bdump\ytk_arc1_536.trc:

Master background archival failure: 316

Wed Dec 12 14:45:56 2007

Errors in file e:\oracle\admin\ytk\bdump\ytk_arc0_3656.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_dbw0_3716.trc:

ORA-00316: ??  (???? ) ??????  ??????

Wed Dec 12 14:45:58 2007

Errors in file e:\oracle\admin\ytk\bdump\ytk_pmon_3608.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_psp0_1816.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_mman_2304.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_reco_3408.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_ckpt_2296.trc:

Errors in file e:\oracle\admin\ytk\bdump\ytk_smon_3416.trc:

Wed Dec 12 14:45:59 2007

Instance terminated by LGWR, pid = 3712

報了一堆的ORA-316和ORA-312錯誤。為了避免現在仍然啟動的STANDBY資料庫幹擾，關閉STANDBY資料庫，再次嘗試以RESETLOGS方式打開資料庫：

SQL> CONN /@YTKS AS SYSDBA

已連接配接。

Variable Size             222298340 bytes

Database Buffers           20971520 bytes

完成媒體恢複。

資料庫已更改。

資料庫終于打開。下面要做的就是去掉隐含參數，再次重新開機，驗證是否可以啟動。

SQL> ALTER SYSTEM RESET "_allow_resetlogs_corruption" SCOPE = SPFILE SID = '*';

資料庫已經關閉。

SQL> STARTUP

資料庫已經打開。

資料庫已經正常打開，但是由于使用_allow_resetlogs_corruption方式打開，會造成資料的丢失，且資料庫的狀态不一緻。是以，這種情況下Oracle建議通過EXP方式導出資料庫。重建新資料庫後，再導入。