ORA-00600[2662][][][][][]错误解决

今天给客户做数据恢复，发现必须使用隐藏参数_allow_resetlogs_corruption，结果一用报出了ORA-00600 2662的错误。客户那边说丢失

今天给客户做数据恢复，发现必须使用隐藏参数_allow_resetlogs_corruption，结果一用报出了ORA-00600 2662的错误。

客户那边说丢失了一个数据文件CUUG.DBF，只有一个以前的冷备份（结果就备份了这一个数据文件............#@#@￥...）。接管客户系统时，，那边dba已经将控制文件重建了。无语中......

将以前的数据文件拷贝回来，重新注册归档日志后，开始恢复。报错：

看下数据文件的SCN：

然后看下归档日志：

这眼看普通恢复没戏了.....归档日志不连续。

开启隐藏参数

scope=spfile;

再次尝试打开数据库，开始提示ORA-00600错误了。

小编还为您整理了以下内容，可能对您也有帮助：

如何处理ORA-600 2662错误

通过正常方式启动数据库时，从alert文件中，我们可以看到ora-00600 2662号错误。

Sun Dec 11 18:02:25 2005

Errors in file /opt/oracle/admin/conner/ump/conner_ora_13349.trc:

ORA-00600: internal error code, arguments: [2662], [0], [547743994], [0], [898092653], [8388617], [], []

Sun Dec 11 18:02:27 2005

Errors in file /opt/oracle/admin/conner/ump/conner_ora_13349.trc:

ORA-00600: internal error code, arguments: [2662], [0], [547743994], [0], [898092653], [8388617], [], []

Sun Dec 11 18:02:27 2005

Error 600 happened ring db open, shutting down database

USER: terminating instance e to error 600

此时我们可以通过Oracle的内部事件来调整SCN:

增进SCN有两种常用方法:

1.通过immediate trace name方式(在数据库Open状态下)

alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';

2.通过10015事件(在数据库无法打开，mount状态下)

alter session set events '10015 trace name adjust_scn level x';

注:level 1为增进SCN 10亿 (1 billion) (1024*1024*1024),通常Level 1已经足够。也可以根据实际情况适当调整。

本例由于数据库无法打开，只能使用的二种方法。

[oracle@jumper dbs]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Proction on Sun Dec 11 18:26:18 2005

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

SQL> startup mount pfile=initconner.ora

ORACLE instance started.Total System Global Area 97588504 bytes

Fixed Size 451864 bytes

Variable Size 33554432 bytes

Database Buffers 62914560 bytes

Redo Buffers 667648 bytes

Database mounted.

SQL> alter session set events '10015 trace name adjust_scn level 10';

Session altered.

SQL> alter database open;

Database altered.

注意,由于我使用了10015事件，使得SCN增进了10 billion，稍后我们可以验证。

[oracle@jumper dbs]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Proction on Sun Dec 11 18:26:18 2005

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

SQL> startup mount pfile=initconner.ora

ORACLE instance started.Total System Global Area 97588504 bytes

Fixed Size 451864 bytes

Variable Size 33554432 bytes

Database Buffers 62914560 bytes

Redo Buffers 667648 bytes

Database mounted.

SQL> alter session set events '10015 trace name adjust_scn level 10';

Session altered.

SQL> alter database open;

Database altered.

此时数据库可以打开，从alert文件中我们可以看到如下提示:

Sun Dec 11 18:27:04 2005

SMON: enabling cache recovery

Sun Dec 11 18:27:05 2005

Debugging event used to advance scn to 10737418240

SCN被增进了10 billion,即 10 * (1024*1024*1024) = 10737418240,正好是日志里记录的数量。

我们从数据库内部看一下检查点的增进情况：

SQL> select open_mode from v$database;

OPEN_MODE

----------

READ WRITESQL> select file#,CHECKPOINT_CHANGE# from v$datafile;

FILE# CHECKPOINT_CHANGE#

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

1 547783998

2 547783998

3 547783998SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.Total System Global Area 97588504 bytes

Fixed Size 451864 bytes

Variable Size 33554432 bytes

Database Buffers 62914560 bytes

Redo Buffers 667648 bytes

Database mounted.

Database opened.

SQL> select file#,CHECKPOINT_CHANGE# from v$datafile; FILE# CHECKPOINT_CHANGE#

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

1 1.0737E+10

2 1.0737E+10

3 1.0737E+10SQL> col CHECKPOINT_CHANGE# for 99999999999999999

SQL> select file#,CHECKPOINT_CHANGE# from v$datafile; FILE# CHECKPOINT_CHANGE#

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

1 10737418447

2 10737418447

3 10737418447

我们看到CHECKPOINT_CHANGE# 最终被增进了10 Billion.这要是账户上的钱该有多好：）

打不开oracle数据库，公司的 Oracle数据库打不开了，一open就报错Ora-00600该

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

Oracle的损坏/坏块 主要分以下几种：

ORA-1578

ORA-8103

ORA-1410

ORA-1499

ORA-1578

ORA-81##

ORA-14##

ORA-26040

ORA-600 Errors

Block Corruption

Index Corruption

Row Corruption

UNDO Corruption

Control File

Consistent Read

Dictionary

File/RDBA/BL

Error Description Corruption related to:

ORA-1578 ORA-1578一般为Oracle检测到存在物理坏块问题，包括其检测数据块中的checksum不正确，或者tail_chk信息不正确等。 ORA-1578 is reported when a block is thought to be corrupt on read.

Block

数据块

OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)” Master Note

OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)”

Fractured Block explanation

Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g

Diagnosing and Resolving 1578 reported on a Local Index of a Partitioned table

ORA-1410

ORA-1410错误常见于从INDEX或其他途径获得的ROWID,到数据表中查询发现没有对应的记录。

该错误可能因为数据表与其索引存在不一致，也可能是分区的数据表本身存在问题。

This error is raised when an operation refers to a ROWID in a table for which there is no such row.

The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.

ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table.

Row

数据行

Understanding The ORA-1410

Summary Of Bugs Containing ORA 1410

OERR: ORA 1410 “invalid ROWID”

ORA-8103

该ORA-8103可能由多个BUG引起，例如LOB在10.2.0.4之前可能会由于BUG覆盖了另一张表的segment header，导致出现ORA-8103错误。

诊断该问题可以从数据表的segment header和data_object_id入手。

The object has been deleted by another user since the operation began.

If the error is reprocible, following may be the reasons:-

a.) The header block has an invalid block type.

b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).

Block

数据块

ORA-8103 Troubleshooting, Diagnostic and Solution

OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution

ORA-8102 ORA-8102常见于索引键值与表上存的值不一致。 An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch.

Index

索引

OERR ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)

ORA-1499 对表和索引做交叉验证时发现问题 An error occurred when validating an index or a table using the ANALYZE command.

One or more entries does not point to the appropriate cross-reference.

Index

索引

ORA-1499. Table/Index row count mismatch

OERR: ORA-1499 table/Index Cross Reference Failure – see trace file

ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.

This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-

a.) Row locked by a non-existent transaction

b.) The amount of space used is not equal to block size

c.) Transaction header lock count mismatch.

While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it ‘moves’.

Send the tracefile to support for analysis.

If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:

ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE; Block

OERR: ORA 1498 “block check failure – see trace file”

ORA-26040 由于采用过nologging/unrecoverable选项的redo生成机制，且做过对应的recover，导致数据块中被填满了0XFF，导致报错ORA-26040。 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.

This Error raises always together with ORA-1578

Block

数据块

OERR ORA-26040 Data block was loaded using the NOLOGGING option

ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution

ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors

ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled

ORA-1578 ORA-26040 On Awr Table

Errors ORA-01578, ORA-26040 On Standby Database

Workflow Tables ORA-01578 ORACLE data block corrupted ORA-26040 Data block was loaded using the NOLOGGING option

ORA-1578, ORA-26040 Data block was loaded using the NOLOGGING option

ORA-600[12700]

从索引获得的ROWID，对应到数据表时发现不存在数据行错误。

一把是一致性度consistent read问题

Oracle is trying to access a row using its ROWID, which has been obtained from an index.

A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.

ORA-600 [12700] can also be reported e to a consistent read (CR) problem.

Consistent Read

一致性读

Resolving an ORA-600 [12700] error in Oracle 8 and above.

ORA-600 [12700] “Index entry Points to Missing ROWID”

ORA-600[3020] 主要问题是redo和数据块中的信息不一致 This is called a ‘STUCK RECOVERY’.

There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered. Redo

ORA-600 [3020] “Stuck Recovery”

Information Required for Root Cause Analysis of ORA-600 [3020] (stuck recovery)

ORA-600[4194] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch has been detected between Redo records and rollback (Undo) records.

We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.

This error is reported when the validation fails. Undo

ORA-600 [4194] “Undo Record Number Mismatch While Adding Undo Record”

Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter

ORA-600[4193] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch has been detected between Redo records and Rollback (Undo) records.

We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.

This error is reported when this validation fails. Undo

ORA-600 [4193] “seq# mismatch while adding undo record”

Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter

Ora-600 [4193] When Opening Or Shutting Down A Database

ORA-600 [4193] When Trying To Open The Database

ORA-600[4137] transaction id不匹配，问题可能存在与回滚段中或者对象本身存在讹误 While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.

This would indicate a corrupted rollback segment. Undo/Redo

ORA-600 [4137] “XID in Undo and Redo Does Not Match”

ORA-600[6101] Not enough free space was found when inserting a row into an index leaf block ring the application of undo. Index

ORA-600 [6101] “insert into leaf block (undo)”

ORA-600[2103] Oracle is attempting to read or update a generic entry in the control file.

If the entry number is invalid, ORA-600 [2130] is logged. Control File

ORA-600 [2130] “Attempt to access non-existant controlfile entry”

ORA-600[4512] Oracle is checking the status of transaction locks within a block.

If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block mp.

This error possibly indicates a block corruption. Block

ORA-600 [4512] “Lock count mismatch”

ORA-600[2662] 主要是发现一个数据块的SCN甚至超过了当前SCN，常规解决途径有调整SCN等，但11.2以后Oracle公司使较多调整SCN的方法失效了 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. Block

ORA-600 [2662] “Block SCN is ahead of Current SCN”

ORA 600 [2662] DURING STARTUP

ORA-600[4097] 访问一个回滚段头以便确认事务是否已提交时，发现XID有问题 We are accessing a rollback segment header to see if a transaction has been committed.

However, the xid given is in the future of the transaction table.

This could be e to a rollback segment corruption issue OR you might be hitting the following known problem. Undo

ora-00600:内部错误代码,参数:[kcratr1_lastbwr],[],[],[],[],[],[],[] 怎么解决

SQL> startup mount;

SQL> recover database;

SQL> alter database open

本文如未解决您的问题请添加抖音号：51dongshi（抖音搜索懂视），直接咨询即可。