A description for this ORA-600 error is not yet published. ora-600 2663/2662A data block SCN is ahead of the current SCN.
in alert log
RA-00600: internal error code, arguments: [2663], [0], [464592], [0], [464858], [], [], []
in trace file
----- Call Stack Trace ----- skdstdst()+36-->kgdsdst()ksedst1()+98-->skdstdst()ksedst()+34-->ksedst1()dbkedDefDump()+2741-->ksedst()ksedmp()+36-->dbkedDefDump()ksfdmp()+64-->ksedmp()dbgexPhaseII()+1764-->ksfdmp()dbgexProcessError()-->dbgexPhaseII()+2675dbgeExecuteForError-->dbgexProcessError()()+83dbgePostErrorKGE()+-->dbgeExecuteForError2138()dbkePostKGE_kgsf()+-->dbgePostErrorKGE()66kgeade()+351-->dbkePostKGE_kgsf()kgeriv_int()+120-->kgeade()kgeriv()+12-->kgeriv_int()kgesiv()+110-->kgeriv()ksesic4()+194-->kgesiv()kcrfw_redo_gen()+15-->ksesic4()738kcbchg1_main()+4019-->kcrfw_redo_gen()kcbchg1()+200-->kcbchg1_main()
The ORA-600 [2663] 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 [2663] internal error.
ORA-600 [2663] [a] [b] [c] [d] []
ARGUMENTS:
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Read more about SCN http://www.anbob.com/archives/2024.html
Check list and possible causes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1, If Parallel Server check both nodes are using the same lock manager instance & point at the same control files.
2, If not Parallel Server check that 2 instances haven’t mounted the same database (Is there a second PMON process around ? – shutdown any other instances to be sure)
Possible causes:
- doing an open resetlogs with _ALLOW_RESETLOGS_CORRUPTION enabled
- a hardware problem, like a faulty controller, resulting in a failed write to the control file or the redo logs
- restoring parts of the database from backup and not doing the appropriate recovery
- restoring a control file and not doing a RECOVER DATABASE USING BACKUP CONTROLFILE
- having _DISABLE_LOGGING set during crash recovery
- problems with the DLM in a parallel server environment
- a bug such as (after data guard switch over)
- This included the time of backup a running transaction. This could happen because the binary copy was made while the source DB was online.
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.
Keep track of the number current scn from alert,as in alert log
ORA-00600: internal error code, arguments: [2663], [0], [4007], [0], [6721], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [2663], [0], [4609], [0], [6721], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [2663], [0], [5681], [0], [6721], [], [], [], [], [], [], []
2,Check for SMON traces and have the alert.log and trace files ready to send to support.
3,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.
4,You can bump the SCN on open using
See [NOTE:30681.1] Be aware that you should really rebuild the database if you use this option.
set the following hidden parameter on database and bounce the database.
_allow_error_simulation=true
Now, the SCN is increased by doing
alter system set events 'immediate trace name adjust_scn level n';
where translates to (n*0×40000000) as the target SCN value. ie. n = 1 will set the SCN as 0×0000.40000000.
5, oradebug DUMPvar SGA kcsgscn
oradebug POKE
6, using parameter _MINIMUM_GIGA_SCN increasing the checkpoint_change# value in datafile header block
7, first with bbed increasing the checkpoint_change# value in datafile header block to a appopraite value, and then re-create controlfile.
Note:
From 11.2.0.2.5, oracle don’t support ADJUST SCN any more.