Veja se ajuda,
Subject: ORA-600 [2662] "Block SCN is ahead of Current SCN"
Doc ID: Note:28929.1 Type: REFERENCE
Last Revision Date: 04-JUL-2006 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# 4453449 See Note 4453449.8
OERI:3020 / corruption errors from multiple FLASHBACK DATABASE
Fixed: 10.2.0.2, 11
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
Thiago M. Zerbinato [thiagomz]
OCP DBA
---
http://thiagomz.hpg.com.br
Domos§ wrote:
> Senhores, estou tentando dar recover em uma base 9i, mas após o
> procedimento de recover e esta dando erro no alter database open.
>
> Podem me ajudar?
>
> Segue o alert do procedimento.
>
> Obrigado
>
> Falconi
>
> CREATE CONTROLFILE REUSE DATABASE "CAMORIM" NORESETLOGS ARCHIVELOG
> -- SET STANDBY TO MAXIMIZE PERFORMANCE
> MAXLOGFILES 50
> MAXLOGMEMBERS 5
> MAXDATAFILES 100
> MAXINSTANCES 1
> MAXLOGHISTORY 453
> LOGFILE
> GROUP 1 (
> '/home/oracle9i/oradata/camorim/redo01.log',
> '/app2/oradata/db1/redo01b.log'
> ) SIZE 100M,
> GROUP 2 (
> '/home/oracle9i/oradata/camorim/redo02.log',
> '/app2/oradata/db1/redo02b.log'
> ) SIZE 100M,
> GROUP 3 (
> '/home/oracle9i/oradata/camorim/redo03.log',
> '/app2/oradata/db1/redo03b.log'
> ) SIZE 100M
> -- STANDBY LOGFILE
> DATAFILE
> '/home/oracle9i/oradata/camorim/system01.dbf',
> '/home/oracle9i/oradata/camorim/undotbs01.dbf',
> '/home/oracle9i/oradata/camorim/cwmlite01.dbf',
> '/home/oracle9i/oradata/camorim/drsys01.dbf',
> '/home/oracle9i/oradata/camorim/example01.dbf',
> '/home/oracle9i/oradata/camorim/indx01.dbf',
> '/home/oracle9i/oradata/camorim/odm01.dbf',
> '/home/oracle9i/oradata/camorim/tools01.dbf',
> '/home/oracle9i/oradata/camorim/users01.dbf',
> '/home/oracle9i/oradata/camorim/xdb01.dbf',
> '/app/oradata/db1/asstec_01.dbf',
> '/app/oradata/db1/asstec_02.dbf',
> '/app/oradata/db1/asstec_03.dbf',
> '/app/oradata/db1/asstec_04.dbf',
> '/app/oradata/db1/asstec_05.dbf',
> '/app2/oradata/db1/ASSTECX1.dbf',
> '/app2/oradata/db1/ASSTECX2.dbf',
> '/app/oradata/db1/COBRAD01.dbf',
> '/app2/oradata/db1/ASSTECX3.dbf',
> '/app/oradata/db1/asstec_06.dbf'
> CHARACTER SET WE8ISO8859P1
> Mon Jan 15 11:58:06 2007
> Successful mount of redo thread 1, with mount id 3445027470
> Mon Jan 15 11:58:06 2007
> Completed: CREATE CONTROLFILE REUSE DATABASE "CAMORIM" NORESE
> Mon Jan 15 11:58:23 2007
> ALTER DATABASE RECOVER DATABASE
> Mon Jan 15 11:58:23 2007
> Media Recovery Start
> Mon Jan 15 11:58:23 2007
> Recovery of Online Redo Log: Thread 1 Group 3 Seq 10834 Reading mem 0
> Mem# 0 errs 0: /home/oracle9i/oradata/camorim/redo03.log
> Mem# 1 errs 0: /app2/oradata/db1/redo03b.log
> Media Recovery Complete
> Completed: ALTER DATABASE RECOVER DATABASE
> Mon Jan 15 11:58:34 2007
> ARCH: Evaluating archive log 1 thread 1 sequence 10832
> ARCH: Beginning to archive log 1 thread 1 sequence 10832
> Creating archive destination
> LOG_ARCHIVE_DEST_1: '/app2/archive/db1/COB_db10000010832.dbf'
> ARCH: Completed archiving log 1 thread 1 sequence 10832
> ARCH: Evaluating archive log 2 thread 1 sequence 10833
> ARCH: Beginning to archive log 2 thread 1 sequence 10833
> Creating archive destination
> LOG_ARCHIVE_DEST_1: '/app2/archive/db1/COB_db10000010833.dbf'
> ARCH: Completed archiving log 2 thread 1 sequence 10833
> Mon Jan 15 11:58:52 2007
> ALTER DATABASE OPEN
> Mon Jan 15 11:58:52 2007
> Beginning crash recovery of 1 threads
> Mon Jan 15 11:58:52 2007
> Started redo scan
> Mon Jan 15 11:58:52 2007
> Completed redo scan
> 1 redo blocks read, 0 data blocks need recovery
> Mon Jan 15 11:58:52 2007
> Started recovery at
> Thread 1: logseq 10834, block 2, scn 0.2211862264
> Mon Jan 15 11:58:52 2007
> Recovery of Online Redo Log: Thread 1 Group 3 Seq 10834 Reading mem 0
> Mem# 0 errs 0: /home/oracle9i/oradata/camorim/redo03.log
> Mem# 1 errs 0: /app2/oradata/db1/redo03b.log
> Mon Jan 15 11:58:52 2007
> Completed redo application
> Mon Jan 15 11:58:52 2007
> Ended recovery at
> Thread 1: logseq 10834, block 3, scn 0.2211882266
> 0 data blocks read, 0 data blocks written, 1 redo blocks read
> Crash recovery completed successfully
> Mon Jan 15 11:58:52 2007
> LGWR: Primary database is in CLUSTER CONSISTENT mode
> Thread 1 advanced to log sequence 10835
> Thread 1 opened at log sequence 10835
> Current log# 1 seq# 10835 mem#
> 0: /home/oracle9i/oradata/camorim/redo01.log
> Current log# 1 seq# 10835 mem# 1: /app2/oradata/db1/redo01b.log
> Successful open of redo thread 1
> Mon Jan 15 11:58:53 2007
> ARC2: Evaluating archive log 3 thread 1 sequence 10834
> ARC2: Beginning to archive log 3 thread 1 sequence 10834
> Creating archive destination
> LOG_ARCHIVE_DEST_1: '/app2/archive/db1/COB_db10000010834.dbf'
> Mon Jan 15 11:58:53 2007
> SMON: enabling cache recovery
> Mon Jan 15 11:58:53 2007
> ARC2: Completed archiving log 3 thread 1 sequence 10834
> Mon Jan 15 11:58:54 2007
> Errors in file /home/oracle9i/admin/camorim/udump/db1_ora_5771.trc:
> ORA-00600: internal error code, arguments: [2662], [0], [2211882271],
> [0], [2211995651], [8388617], [], []
> Mon Jan 15 11:58:54 2007
> Errors in file /home/oracle9i/admin/camorim/udump/db1_ora_5771.trc:
> ORA-00600: internal error code, arguments: [2662], [0], [2211882271],
> [0], [2211995651], [8388617], [], []
> Mon Jan 15 11:58:54 2007
> Error 600 happened during db open, shutting down database
> USER: terminating instance due to error 600
> Instance terminated by USER, pid = 5771
> ORA-1092 signalled during: ALTER DATABASE OPEN...
> Mon Jan 15 12:03:55 2007
> USER: terminating instance due to error 1092
> Instance terminated by USER, pid = 5771
>
>
>
>> Apostilas » Dicas e Exemplos » Funções » Mundo Oracle » Package » Procedure
>> » Scripts » Tutoriais acesse:
>> http://www.oraclebr.com.br/codigo/ListaCodigo.php
> --------------------------------------------------------------------------------------------------------------------------
>> Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira
>> responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> --------------------------------------------------------------------------------------------------------------------------
>> O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE:
>> http://www.oraclebr.com.br/
> ------------------------------------------------------------------------------------------------------------------------
>
> Links do Yahoo! Grupos
>
>
>
> __________ Informação do NOD32 IMON 1980 (20070115) __________
>
> Esta mensagem foi verificada pelo NOD32 sistema antivírus
> http://www.eset.com.br
>
>
>
