rac redo log file被意外覆盖数据库恢复

《rac redo log file被意外覆盖数据库恢复》有 5 条评论

1. 惜分飞 说：

   2016 年 1 月 23 日21:39

   ORA-00600 [6006]
   ================

   Oracle is undoing an index leaf key operation. If the key is not found,
   ORA-00600 [6006] is logged.

   ORA-600[6006] is usually caused by a media corruption problem related to either a
   lost write to disk or a corruption on disk.
2. 惜分飞 说：

   2012 年 6 月 15 日22:38

   在一次三个节点的rac恢复过程中遇到如下错误

   Errors in file /u01/app/oracle/admin/ZSDB/udump/zsdb2_ora_18918.trc:
   ORA-00600: internal error code, arguments: [kclchkblk_4], [1], [1727335936], [1], [1726872599], [], [], []
   

   这个库的tempfile已经全部被删除，而且从这里的错误提示a和c的值为1中也可以看出来是system01.dbf文件scn异常导致
3. 惜分飞 说：

   2012 年 5 月 17 日15:43

   ORA-600 [kclchkblk_4] and ORA-600 [2662] After Recovery of Database

   Applies to:
   Oracle Server - Enterprise Edition - Version: 9.0.1.0 to 10.1.0.2 - Release: 9.0.1 to 10.1
   Information in this document applies to any platform.
   ***Checked for relevance on 22-03-2012***
   
   Symptoms
   1) You restored the database from backup and did an incomplete recovery.
   
   2) Opened the database with resetlogs.
   
   3) After opening the database, you start getting following errors:
   
   ORA-00600 [kclchkblk_4]
   ORA-00600 [2662]
   
   Example output from ALERT: 
   
   Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
   ORA-600: internal error code, arguments: [kclchkblk_4], [1904], 
   [18446744073431179384], [1904], 
   [18446744073403569507], [], [], []
   
   Starting background process QMNC
   QMNC started with pid=24, OS id=8329
   
   Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
   ORA-600: internal error code, arguments: [2662], [1904], [3988985522], 
   [1904], [4016595064], [83
   88610], [], []
   
   Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
   ORA-600: internal error code, arguments: [2662], [1904], [3988985525], 
   [1904], [4016595064], [83
   88610], [], []
   SMON: terminating instance due to error 474
   Instance terminated by SMON, pid = 7493
   
   
   4) The call stack generated for ORA-600 [kclchkblk_4] looks similar to: 
   
   kclchkblk kcbzib kcbgcur ktfbhget ktftfcload
   
   Changes
   This problem situation occurs in 10.1.0.2, after flashback database 
   when trying to open database, using 'open database resetlogs'.
   
   Cause
   1) Error, ORA-600[KCLCHKBLK_4], is signaled because the SCN in a tempfile block
   is too high. The same reason caused the ORA-600[2662]s in the alert logs.
   
   2) This issue is because the tempfiles may not get reinitialized during open resetlogs.
   
   This problem is analyzed in unpublished 
   Bug 3517013: GSIST: OPEN DB RESETLOG AFTER FLASHBACK DB FAILS ORA-600 [KCLCHKBLK_4], [1904], 
   which is fixed in 10.1.0.3 and later in 10.1.
   
   This problem will not occure in 10.2 or later, since we nolonger reinitialize tempfiles in 10.2.
   Solution
   
   To workaround this problem once it has occured, please follow below steps 
   to remove and recreate the tempfiles: 
   
   First find the tempfiles in the database:
   
   SQL>select file_name, file_id from dba_temp_files;
   Startup mount
   
   Drop all the tempfiles:
   SQL>alter database tempfile drop;
   
   Alter database open;
   
   Add new tempfile(s).
   SQL>alter tablespace add tempfile size N;
   
   Restart the instance.
   
   To avoid hitting this problem, which is fixed in 10.1.0.3 and later:
   Apply 10.1.0.3 or later patchset or upgrade to 10.2 or later.
   
   Preferable solution is to upgrade to a supported version of RDBMS.
   See Document 757445.1 FAQ for Products in Extended Support
   
4. 惜分飞 说：

   2012 年 5 月 17 日15:40

   ORA-600 [6006] ORA-600 [6856] During Startup Instance, Followed by Termination by SMON

   Applies to:
   Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3 - Release: 10.2 to 10.2
   Information in this document applies to any platform.
   
   
   Symptoms
   The following errors are occurring when starting the instance: 
   
   ORA-00600: internal error code, arguments: [6006], [1], [], [], [], [], [], [] 
   
   ORA-00600: internal error code, arguments: [6856], [0], [60], [], [], [] 
   
   SMON will eventually terminate the instance. 
   
   
   Cause
   These errors can occur if the database crashes under certain circumstances.
   The undo segments are trying to rollback a failed transaction and cannot. 
   
   ORA-00600: internal error code, arguments: [6006], [1], [], [], [], [], [], []
   Oracle is undoing an index leaf key operation. If the key is not found,
   ORA-00600 [6006] is logged.
   
   ORA-00600: internal error code, arguments: [6856], [0], [60], [], [], []
   SMON is trying to recover a dead transaction. But the undo application runs into an
   internal error (trying to delete a row that is already deleted).
   
   
   Solution
   Review the trace files and look for the object(s) involved.
   If the trace file does not have a SQL statement, search on the following: "block dump header" 
   In the block header there will be a seg/obj = hex value.
   Convert the hex to dec and this will give you the data_object_id.
   The alert.log may also show the affected object, for example:
   ORACLE Instance ORCL (pid = 8） - Error 600 encountered while recovering 
   transaction (9999, 36) on object 45879.
   SQL>select object_id, data_object_id, owner, object_name from dba_objects where 
   object_id = object# or data_object_id=object# ;
   
   This will be the object you need to work with. 
   In case no object is shown at select of dba_objects check if object has been already dropped 
   and is still present in recyclebin(in that case the problem can/will still be observed):
   SQL> select u.name,r.original_name,t.name from recyclebin$ r, user$ u, ts$ t where 
        r.obj#=&object_id and r.ts#=t.ts# and r.owner#=u.user# ;
    
   To implement the solution:
   1. shutdown instance (if not already down)
   SQL> shutdown immediate
   
   2. set event - event="10513 trace name context forever, level 2" 
   (event disables transaction recovery which was initiated by SMON)
   It would be best to create a pfile which is to be used for this action only:
   SQL> 
   connect / as sysdba
   startup mount
   create pfile='/tmp/init$ORACLE_SID.ora' from spfile;
   shutdown immediate
   +
   echo 'event="10513 trace name context forever, level 2"' >> /tmp/init$ORACLE_SID.ora
   
   *) in case already a pfile is being used make a copy to /tmp and ...
   
   3. startup instance using the pfile as just created:
   SQL>
   connect / as sysdba
   startup pfile=/tmp/init$ORACLE_SID.ora
   4. Drop the object:
   a) If the object is an index the action is to drop the index, in case no create 
   script is present you can extract one by:
   SQL>
   connect / as sysdba
   set long 1000000
   select dbms_metadata.get_ddl('INDEX',upper('&object_name'),upper('&owner')) from dual;
   
   b) If the object is a table there will likely be a need to salvage the content of 
   the table before dropping the table. 
   Possible options:
   - exp{dp} table
   - CTAS (CreateTableAsSelect)
   
   
   In case recyclebin is active it might be that object was already in recylebin OR has 
   been moved by drop into the recyclebin, therefore check and purge the recyclebin (if applicable):
   SQL> select u.name,r.original_name,t.name from recyclebin$ r, user$ u, ts$ t
        where r.obj#=&object_id and r.ts#=t.ts# and r.owner#=u.user# ;
   
   SQL> purge &tablespace_name;
   or
   SQL> purge dba_recyclebin;
   
   5. shutdown the instance
   SQL>
   connect / as sysdba
   shutdown immediate
   
   6. remove the event 
   Only needed in case the event was pushed into the spfile, if true the steps are:
   SQL>
   connect / as sysdba
   startup mount
   alter system reset event scope=spfile sid='*';
   shutdown immediate
   
   7. startup the instance
   SQL>
   connect / as sysdba
   startup
   
   8. recreate the affected object(s)
   
5. 惜分飞 说：

   2012 年 5 月 17 日15:32

   ORA-600 [kcbgcur_9]

   ERROR:
     Format: ORA-600 [kcbgcur_9] [a] [b] [c] [d]
    
   VERSIONS:
     versions 8.0 to 10.0
    
   DESCRIPTION:
   
     Buffers are pinned in a specific class order to prevent internal deadlocks.
   
     This exception means there is a class violation with the current 
     buffers pinned in the wrong class order, or duplicate buffers of
     the same class.
   
     May occur with an ORA-372 error when trying to update read-only 
     tablespace or partition via direct load.
   
   ARGUMENTS:
     Arg [a] The Database Block Address (DBA)
     Arg [b] The buffer class
     Arg [c] Block class order mask
     Arg [d] Block class checking mask
   
   FUNCTIONALITY:      
     BUFFER CACHE
    
   IMPACT:             
     PROCESS FAILURE
     NON CORRUPTIVE - No underlying data corruption.
    
   SUGGESTIONS:
   
     Check all system hardware (disk, memory) to ensure there are no  errors.