oracle出現(xiàn)ORA-00600錯誤如何處理

小編給大家分享一下oracle出現(xiàn)ORA-00600錯誤如何處理，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

由于客戶現(xiàn)場異常斷電，oracle數(shù)據(jù)庫又無法啟動了。遠程上去看看吧。

1. 數(shù)據(jù)庫只能mount，已經(jīng)無法啟動

   SQL> select status from v$instance;
   STATUS
   ------------
   MOUNTED
   SQL> ALTER DATABASE OPEN;
   ALTER DATABASE OPEN
   *
   ERROR at line 1:
   ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

2. 嘗試recover和resetlogs open都不行

   SQL> recover database;
   ORA-00283: recovery session canceled due to errors
   ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
   SQL> ALTER DATABASE OPEN resetlogs;
   ALTER DATABASE OPEN resetlogs
   *
   ERROR at line 1:
   ORA-01113: file 1 needs media recovery
   ORA-01110: data file 1: 'D:\APP\ORACLE\ORADATA\PRJDB\SYSTEM01.DBF'

3. Alert log 顯示錯誤

   ~~~~~~~~~~~~~~~~
   Sun Jan 14 19:52:29 2018
   ALTER DATABASE OPEN
   Beginning crash recovery of 1 threads
   parallel recovery started with 3 processes
   ......
   Started redo scan
   Completed redo scan
   read 2300 KB redo, 0 data blocks need recovery
   Errors in file d:\app\oracle\diag\rdbms\prjdb\prjdb\trace\prjdb_ora_1644.trc  (incident=315209):
   ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [29904], [4864], [4870], [], [], [], [], [], [], []
   Incident details in: d:\app\oracle\diag\rdbms\prjdb\prjdb\incident\incdir_315209\prjdb_ora_1644_i315209.trc
   Aborting crash recovery due to error 600
   Errors in file d:\app\oracle\diag\rdbms\prjdb\prjdb\trace\prjdb_ora_1644.trc:
   ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [29904], [4864], [4870], [], [], [], [], [], [], []
   Errors in file d:\app\oracle\diag\rdbms\prjdb\prjdb\trace\prjdb_ora_1644.trc:
   ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [29904], [4864], [4870], [], [], [], [], [], [], []
   ORA-600 signalled during: ALTER DATABASE OPEN...
   ~~~~~~~~~~~~~~~~~~~

4. 結合ALERT里的錯誤ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [29904], [4864], [4870],是由于服務器異常斷電，導致LGWR寫redo log時失敗，
   下次重新啟動數(shù)據(jù)庫時，需要做實例級恢復，而又無法從聯(lián)機日志文件里獲取到這些redo信息，因為上次斷電時，寫日志失敗了。

5. 那么ORA-00600的錯誤里，那幾個參數(shù) [1], [29904], [4864], [4870]的含義是，實例需要恢復sequence為29904的redo文件，需要恢復到編號為4870的日志塊，而實際上只能恢復到第4864個日志塊兒，所以數(shù)據(jù)庫就不能正常啟動。

6. 那我們怎么辦呢？先檢查一下控制文件和datafile記錄的checkpoint_change#信息吧。

數(shù)據(jù)文件檢查點（記錄在控制文件中）

SQL> select file#,checkpoint_change#,last_change# from v$datafile where rownum<5;
     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
         1          664629049
         2          664629049
         3          664629049
         4          664629049

系統(tǒng)檢查點（記錄在控制文件中）

SQL>  select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
---------- ------------------ ------------
         664607310

數(shù)據(jù)文件頭檢查點（記錄在數(shù)據(jù)文件中）

SQL> select file#,checkpoint_change# from v$datafile_header where rownum<5;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1          664629049
         2          664629049
         3          664629049
         4          664629049

-7. 以上三個checkpoint_change#要一致(只讀、脫機表空間除外)，數(shù)據(jù)庫才能正常打開。否則會需要進行一步的處理。正常關庫時，會生成新的檢查點，寫入上述三個checkpoint_change#，同時數(shù)據(jù)文件中的last_change#也會記錄下該檢查點，也就是說三個checkpoint_change#與last_change#記錄著同一個值。

-8. 通過上面的錯誤，以及checkpoint_change#的不一致，已經(jīng)可以確認，就是控制文件，由于斷電。導致的controlfile損壞（checkpoint_change#不一致）。

-9. 由于沒有備份，我們只能通過重建controlfile的方式，來解決這個問題。

指定trace文件的生成路徑
SQL> alter database backup controlfile to trace as '/tmp/controlfile.trc';

生成文件提取建庫腳本如下，啟動數(shù)據(jù)庫到nomount狀態(tài)，執(zhí)行下面腳本。
注意：類似的恢復操作，先將現(xiàn)有的數(shù)據(jù)庫進行備份。即使這個數(shù)據(jù)庫已經(jīng)無法啟動。我們也要防止恢復操作導致的更嚴重的問題。

CREATE CONTROLFILE REUSE DATABASE "PRJDB" NORESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 200
    MAXINSTANCES 8
    MAXLOGHISTORY 584
LOGFILE
  GROUP 1 'D:\APP\ORACLE\ORADATA\PRJDB\REDO01.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 'D:\APP\ORACLE\ORADATA\PRJDB\REDO02.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 'D:\APP\ORACLE\ORADATA\PRJDB\REDO03.LOG'  SIZE 50M BLOCKSIZE 512
DATAFILE
  'D:\APP\ORACLE\ORADATA\PRJDB\SYSTEM01.DBF',
  'D:\APP\ORACLE\ORADATA\PRJDB\SYSAUX01.DBF',
  'D:\APP\ORACLE\ORADATA\PRJDB\UNDOTBS01.DBF',
  'D:\APP\ORACLE\ORADATA\PRJDB\USERS01.DBF'
CHARACTER SET US7ASCII;

-10. 檢查數(shù)據(jù)庫狀態(tài)

SQL> select status from v$instance;
STATUS
 ------ ----- -
MOUNTED

-11. 嘗試重啟一下，看到是需要恢復的（其實我是知道這樣起不來的，但是就像任性的看看報錯）。

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: 'D:\APP\ORACLE\ORADATA\PRJDB\SYSTEM01.DBF'

-12. 恢復數(shù)據(jù)庫，其實啥也沒做，recover就是走個過場，但是必須得走這個流程。

SQL> recover database;
Media recovery complete.

11. 啟動數(shù)據(jù)庫，成功

    SQL> alter database open;
    Database altered.
    SQL> select status from v$instance;
    STATUS
    --- --------
    OPEN

12. 再看看checkpoint_change#值，統(tǒng)一了吧。

    SQL> select file#,checkpoint_change#,last_change# from v$datafile where rownum<5;
     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
    ---------- ------------------ ------------
         1          664649053
         2          664649053
         3          664649053
         4          664649053

    SQL> select checkpoint_change# from v$database;
    CHECKPOINT_CHANGE#
    ------------------
         664649053

    SQL> select file#,checkpoint_change# from v$datafile_header where rownum<5;
     FILE# CHECKPOINT_CHANGE#
    ---------- ------------------
         1          664649053
         2          664649053
         3          664649053
         4          664649053

以上是“oracle出現(xiàn)ORA-00600錯誤如何處理”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業(yè)資訊頻道！