ORA-600 [2662] Block SCN is ahead of Current SCN [ID 28929.1]

 

ORA-600 [2662] "Block SCN is ahead of Current SCN" [ID 28929.1]
	Modified 09-DEC-2010     Type REFERENCE     Status PUBLISHED

 

 

 

Note: For additional ORA-600 related information please read Note:146580.1

 

PURPOSE:           

  This article discusses the internal error "ORA-600 [2662]", what

  it means and possible actions. The information here is only applicable

  to the versions listed and is provided only for guidance.

 

ERROR:             

  ORA-600 [2662] [a] [b] [c] [d] [e]

 

VERSIONS:

  versions 6.0 to 10.1

 

DESCRIPTION:

 

  A data block SCN is ahead of the current SCN.

 

  The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN

  stored in a UGA variable.

 

  If the SCN is less than the dependent SCN then we signal the ORA-600 [2662]

  internal error.

 

ARGUMENTS:

  Arg [a]  Current SCN WRAP

  Arg [b]  Current SCN BASE

  Arg [c]  dependent SCN WRAP

  Arg [d]  dependent SCN BASE

  Arg [e]  Where present this is the DBA where the dependent SCN came from.

 

FUNCTIONALITY:     

  File and IO buffer management for redo logs

 

IMPACT:

  INSTANCE FAILURE

  POSSIBLE PHYSICAL CORRUPTION

 

SUGGESTIONS:       

    

  There are different situations where ORA-600 [2662] can be raised.

 

  It can be raised on startup or duing database operation.

 

  If not using Parallel Server, check that 2 instances have not mounted

  the same database.

 

  Check for SMON traces and have the alert.log and trace files ready

  to send to support.

 

  Check the SCN difference [argument d]-[argument b].

 

  If the SCNs in the error are very close, then try to shutdown and startup

  the instance several times.

 

  In some situations, the SCN increment during startup may permit the

  database to open. Keep track of the number of times you attempted a

  startup.

 

  If the Known Issues section below does not help in terms of identifying

  a solution, please submit the trace files and alert.log to Oracle

  Support Services for further analysis.

 

  Known Issues:

 

  Bug# 5889016   See Note:5889016.8

      Corruption / OERI during recovery

      Fixed:

 

  Bug# 4453449   See Note:4453449.8

      OERI:3020 / corruption errors from multiple FLASHBACK DATABASE

      Fixed: 10.2.0.2, 11.1.0.6

 

  Bug# 2899477   See Note:2899477.8

      Minimise risk of a false OERI[2662]

      Fixed: 9.2.0.5, 10.1.0.2

 

  Bug# 2764106   See Note:2764106.8

      False OERI[2662] possible on SELECT which can crash the instance

      Fixed: 9.2.0.5, 10.1.0.2

 

  Bug# 2216823   See Note:2216823.8

      OERI [2662] reusing a TEMPFILE with a restored database

      Fixed: 10.1.0.2

 

  Bug# 2054025   See Note:2054025.8

      OERI:2662 possible on new TEMPORARY index block

      Fixed: 9.0.1.3, 9.2.0.1

 

  Bug# 851959   See Note:851959.8

      OERI:2662 possible from distributed OPS select

      Fixed: 7.3.4.5

 

  Bug# 647927 P  See Note:647927.8

      Digital Unix ONLY: OERI:2662 could occur under heavy load

      Fixed: 8.0.4.2, 8.0.5.0

 

 

 

 

 

 INTERNAL ONLY SECTION - NOT FOR PUBLICATION OR DISTRIBUTION TO CUSTOMERS

 ========================================================================

 

There were 2 forms of this error until 7.2.3:

 

 Type I:  4/5 argument forms -

                              The SCN found on a block (dependent SCN) is ahead of the

                                current SCN. See below for this

 

 Type II:        1 Argument (before 7.2.3 only):

                 Oracle is in the process of writing a block to a log file.

                 If the calculated block checksum is less than or equal to 1

                 (0 and 1 are reserved) ORA-600 [2662] is returned.

                 This is a problem generating an offline immediate log marker

                 (kcrfwg).

                 *NOT DOCUMENTED HERE*

        

Type I

~~~~~~

    a.  Current SCN WRAP

    b.  Current SCN BASE

    c.  dependent SCN WRAP

    d.  dependent SCN BASE

    e.  Where present this is the DBA where the dependent SCN came from.

        From kcrf.h:

         If the SCN comes from the recent or current SCN then a dba

         of zero is saved. If it comes from undo$ because the undo segment is

         not available then the undo segment number is saved, which looks like

         a block from file 0. If the SCN is for a media recovery redo (i.e.

         block number == 0 in change vector), then the dba is for block 0

         of the relevant datafile. If it is from another database for a

         distributed transaction then dba is DBAINF(). If it comes from a TX 

         lock then the dba is really usn<<16+slot.

 

Type II

~~~~~~~

    a.  checksum -> log block checksum - zero if none (thread # in old format) 

 

---------------------------------------------------------------------------

 

Diagnosis:

~~~~~~~~~~     

  In addition to different basic types from above, there are different

  situations where ORA-600 [2662] type I can be raised.

 

Getting started:

~~~~~~~~~~~~~~~~

   (1) is the error raised during normal database operations (i.e. when the

       database is up) or during startup of the database?

   (2) what is the SCN difference [d]-[b] ( subtract argument 'b' from arg 'd')?

   (3) is there a fifth argument [e] ?

       If so convert the dba to file# block#

       Is it a data dictionary object? (file#=1)

       If so find out object name with the help of reference dictionary

               from second database

   (4) What is the current SQL statement? (see trace)

       Which table is refered to?

       Does the table match the object you found in previous step?

 

   Be careful at this point: there may be no relationship between DBA in [e]

   and the real source of problem (blockdump).

 

 

Deeper analysis:

~~~~~~~~~~~~~~~~

  (1) investigate trace file:

      this will be a user trace file normally but could be an smon trace too

  (2) search for: 'buffer'

      ("buffer dba" in Oracle7 dumps, "buffer tsn" in Oracle8/Oracle9 dumps)

      this will bring you to a blockdump which usually represents the

      'real' source of OERI:2662

 

      WARNING: There may be more than one buffer pinned to the process

               so ensure you check out all pinned buffers.

 

   -> does the blockdump match the dba from e.?

   -> what kind of blockdump is it?         

       (a) rollback segment header

       (b) datablock

       (c) other

 

  

Check list and possible causes

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

  If Parallel Server check both nodes are using the same lock manager

  instance & point at the same control files.

 

  Possible causes:

 

  (1) doing an open resetlogs with _ALLOW_RESETLOGS_CORRUPTION enabled   

  (2) a hardware problem, like a faulty controller, resulting in a failed

      write to the control file or the redo logs    

  (3) restoring parts of the database from backup and not doing the

      appropriate recovery    

  (4) restoring a control file and not doing a RECOVER DATABASE USING BACKUP

      CONTROLFILE    

  (5) having _DISABLE_LOGGING set during crash recovery                     

  (6) problems with the DLM in a parallel server environment     

  (7) a bug     

 

  Solutions:

 

   (1) if the SCNs in the error are very close, attempting a startup several

       times will bump up the dscn every time we open the database even if

       open fails. The database will open when dscn=scn.

     

   (2)You can bump the SCN either on open or while the database is open

      using <Event:ADJUST_SCN> (see Note:30681.1).

      Be aware that you should rebuild the database if you use this

      option.

 

   Once this has occurred you would normally want to rebuild the

   database via exp/rebuild/imp as there is no guarantee that some

   other blocks are not ahead of time.

 

Articles:

~~~~~~~~~

  Solutions:

   Note:30681.1   Details of the ADJUST_SCN Event

   Note:1070079.6 Alter System Checkpoint

 

  Possible Causes:

   Note:1021243.6 CHECK INIT.ORA SETTING _DISABLE_LOGGING

   Note:41399.1   Forcing the database open with `_ALLOW_RESETLOGS_CORRUPTION`

   Note:851959.9  OERI:2662 DURING CREATE SNAPSHOT AT MASTER SITE

 

 

Known Bugs:

~~~~~~~~~~~

 

Fixed In. Bug No.      Description

---------+------------+----------------------------------------------------

7.1.5     BUG:229873

7.1.3     Bug:195115   Miscalculation of SCN on startup for distributed TX ?

7.1.6.2.7 Bug:297197   Port specific Solaris OPS problem

7.3       Bug:336196   Port specific IBM SP AIX problem -> dlm issue   

7.3.4.5   Bug:851959   OERI:2662 possible from distributed OPS select

Not fixed Bug:2216823  OERI:2662 reported when reusing tempfile with restored DB

8.1.7.4   Bug:2177050  OERI:729 space leak possible (with tags "define var info"/"oactoid info")

                       can corrupt UGA and cause OERI:2662

 

---------------------------------------------------------------------------

 

Ensure that this note comes out on top in Metalink when searched

ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600

ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600

2662 2662 2662 2662 2662 2662 2662 2662 2662

2662 2662 2662 2662 2662 2662 2662 2662 2662

 

 

</Internal_Only

 

 

Related Products ·         Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition ·         Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Personal Edition ·         Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Standard Edition Keywords BUGTAG_ADDBUGS; INTTEAMREVIEWED; NOTDDRCONFIRMED Errors ORA-600[2662]

 

 

 

 

------------------------------------------------------------------------------

Blog： http://blog.csdn.net/tianlesoftware

网上资源： http://tianlesoftware.download.csdn.net

相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx

DBA1 群：62697716(满); DBA2 群：62697977(满)

DBA3 群：62697850   DBA 超级群：63306533;    

聊天 群：40132017

--加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请