案例学习Oracle错误：ORA-00600

原文:ORA-00600 internal error code, arguments: [string], [string], [string], [string], [string], [string], [string], [string]

　　Cause This is the generic internal error number for Oracle program exceptions. It indicates that a process has encountered a low-level, unexpected condition. Causes of this message include:

　　1.timeouts

　　2.file corruption

　　3.failed data checks in memory

　　4.hardware, memory, or I/O errors

　　5.incorrectly restored files

　　The first argument is the internal message number. Other arguments are various numbers, names, and character strings. The numbers may change meanings between different versions of Oracle.

　　Action Report this error to Oracle Customer Support after gathering the following information:

　　1.events that led up to the error

　　2.the operations that were attempted that led to the error

　　3.the conditions of the operating system and databases at the time of the error

　　4.any unusual circumstances that occurred before receiving the ORA-00600 message

　　5.contents of any trace files generated by the error

　　6.the relevant portions of the Alter files Note: The cause of this message may manifest itself as different errors at different times.

　　Be aware of the history of errors that occurred before this internal error.

 　　ORACLE ORA-00600错误的阐述

　　ORACLE ORA-00600错误不是你的程序错误.是ORACLE内部的错误,一般来说,大部分的ORA-00600错误均是由ORACLE软件的bug所导致，因此对于这样的错误需要及时联系ORACLE技术支持工程师.对于这种类型的ORA-00600错误，一个简单的处理方式就是打补丁，将数据库升级到一个稳定的版本，另外建议屏蔽某些ORACLE特性，诸如MTS(MultiThread Server)。但也有部分错误是由数据库内部的表或索引(包括应用的)结构被损坏所或其他原因所造成。

　　1:ORA-600[12700]表示执行SQL语句时对应的某些实体(表/索引)损坏;该错误的处理方法为:

　　修改init$ORACLE_SID.ora文件，增加如下几行:

　　event = “10210 trace name context forever level 10”

　　event = “10211 trace name context forever level 10”

　　event = “10231 trace name context forever level 10

　　执行以下语句:

　　analyze table/index/cluster [name] validate structure;

　　如果怀疑是数据字典损坏，则不能采用以上的方法对表进行分析，因为在某些平台上执行以上操作将引起系统瘫痪，执行如下存储过程:

　　DBMS_UTILITY.ANALYZE_SCHEMA

　　例2:在对数据库进行读写操作时出现错误:ORA-00600:internal error code,arguments:[4519],[6711],[2],…表示执行SQL语句时的对应的实体数据块[6711]的结构被破坏所引起。该错误的处理方法为:

　　执行如下的package进行分析:

　　SQL > select dbms_utility.data_block_address_file(6711) from dual;

　　SQL > select dbms_utility.data_block_address_block(6711) from dual;

　　查找其对应的block_id和file_id。

　　通过如下的sql命令查找出被破坏的实体类型、owner等:

　　SQL > select segment_name,segment_type,owner

　　from dba_extents

　　where file_id=file# and block# between

　　block_id and block_id+blocks-1;

　　如果被破坏的对象并非系统表或索引，则可以通过对该数据库对象/r进行备份后重新创建实体的方法进行。如果出现的错误为系统表或索引，则需要根据实际情况进行处理。

　　另外,用ResultSet来执行插入,更新,删除原则上是可行的,但效率很低,而且无法测试操作是否成功.

　　案例一:ORA-00600 [2662]错误解决过程

　　情景描述:客户那边数据库突然出现一个current日志文件坏了，导致数据库crash了，然后现场工程师使用_ALLOW_RESETLOGS_CORRUPTION = TRUE这个隐含参数，做了不完全恢复后强行将数据库打开。可是打开数据库后发现只能用internal用户连接进去，别的用户连接都报错，错误信息如下:

　　ORA-00600: internal error code, arguments: [2662], [0], [431267936], [0], [431273216], [0], [], []

　　查询不了任何应用的表，应用也没法使用，于是想尝试全库的exp出来然后重新imp进去建库，结果发现exp数据也不成功，也是报同样的ORA-600的错误，用户当时数据没有任何的备份过，只能想办法尽量打开数据库，导出数据了。

　　处理过程:

　　先检查了600错误产生的trace文件:

　　*** SESSION ID:(7.15) 2004.11.23.23.28.16.824

　　ksedmp: internal or fatal error

　　ORA-00600: internal error code, arguments: [2662], [0], [431267754], [0], [431272752], [0], [], []

　　Current SQL statement for this session:

　　SELECT * FROM "WHSB"."SB_BSBF"

　　得到的信息有限，只能看到是严重内部错误，剩下的都是内存堆栈的一堆信息，于是查找了一下这个错误的具体相关信息。

　　ORA-600 [2662] "Block SCN is ahead of Current SCN"，说明当前数据库的数据块的SCN早于当前的SCN，主要是和存储在UGA变量中的dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了。这个错误一共有五个参数，分别代表不同的含义，

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

　　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.

　　我们分析错误中的提示，它的参数b=431267754,d=431272752,表明当前的SCN确实是小于dependent SCN，所以产生了这个600的错误。

　　通过查阅文档，发现这个错误的产生原因主要有以下几条:

　　使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库

　　硬件错误引起数据库没法写控制文件和重做日志文件

　　错误的部分恢复数据库

　　恢复了控制文件但是没有使用recover database using backup controlfile进行恢复

　　数据库crash后设置了_DISABLE_LOGGING隐含参数

　　在并行服务器环境中DLM存在问题

　　仔细对比了一下，发现问题可能是由于第一条产生的，由于设置了_ALLOW_RESETLOGS_CORRUPTION这个隐含参数后，虽然强制性的打开数据库，但是数据库本身存在了corruption，仍然存在严重的问题。

　　于是想到使用ADJUST_SCN事件来调整当前的SCN，使其大于dependent SCN，然后保证数据库可以全库的导出，然后重建数据库导入数据。

　　用internal用户登陆数据库后，连接别的用户，还是失败报错，执行:

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

　　然后尝试连接别的用户，连接成功。

　　最后exp整个数据库，重建数据库后导入数据，整个数据库恢复成功!

　　通过这个实例，我们可以看到，尽量的不要去使用那些隐含参数，这些参数是oracle所不推荐使用的，也不是万能的!如果使用了可能会存在一些遗留的问题，如果非要使用，建议使用后一定要exp/imp重建建立数据库。

　　深入测试:ORA-00600 2262错误解决

　　使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库后,我们说很多时候你会遇到ORA-00600 2662号错误，这个错误的含义是:

　　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.

　　在测试中,很容易模拟这个错误:

　　Thu Oct 20 10:38:27 2005

　　SMON: enabling cache recovery

　　Thu Oct 20 10:38:27 2005

　　Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:

　　ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []

　　Thu Oct 20 10:38:28 2005

　　Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:

　　ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []

　　如果SCN相差不多，可以通过多次重起数据库解决。

　　也可以通过内部事件:

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

　　我这里通过几次重起就解决了问题

　　超时情况:ORA-00600:internal error code,arguments:[num],[?],[?],[?],[?]

　　产生原因:这种错误通常为oracle的内部错误，只对oss和oracle开发有用。ora-600的错误经常伴随跟踪文件的状态转储(系统状态和进程状态)，系统状态存储将包括ORACLE RDBMS持有的当前对象的信息，进程状态转储则将显示特殊进程持有的对象，当进程符合了某错误条件时，经常是由于一些信息取自它持有的一个块，如果我们知道这些错误进程持有的块，就容易跟踪问题的来源。

　　解决方法:一般来说出现这个错误我们本身是无法解决的，只有从提高系统本身各方面来解决这个内部问题，如增加硬件设备，调整系统性能，使用OPS(当然OPS从某种意义上说并不是一种好的解决方式)等。ORA-600错误的第一个变量用于标记代码中错误的位置(代码中的每个部分的第一变量都不一样)，从第二个到第五个变量显示附加信息，告诉OSS代码在哪里出现了错误。

　　一个报错例子如下:

　　ora-00600: internal error code, arguments: [1237], [], [], [], [], [], [], []

　　相应的英文如下:

　　cause:this is a catchall internal error message for Oracle program exceptions.It indicates that a process

　　has met a low-level,unexpected condition.Various causes of this message include:

　　time-outs(超时)

　　file corruption(文件太老)

　　failed data checks in memory(内存检索失败)

　　hardware,memory,or I/O errors(硬件、内存或者磁盘错误)

　　incorrectly restored files(错误的重建文件)

　　案例二:系统写入控制文件的时候超时

　　错误描述:我们的系统由于出现了若干个ORA-00600错误导致崩溃。错误信息说是在写入控制文件的时候超时。我们将参数从900调高到1800，给系统更多的时间去更新，但是看起来对于实际问题没有任何帮助。

　　我们用的是Oracle9i 9.2.0.4，它是一个大型的数据仓库应用程序。您认为我们应该查看哪里呢?

　　处理过程：ORA-600错误信息是Oracle环境发布的没有捕获的错误。换句话说，ORA-600错误是让你了解出现问题的一个通用的方式，但是数据库并不知道问题是什么。与ORA-600在同一行上，还会在括号内出现一行额外的信息。括号里面的第一个代码是最重要的，因为它表示Oracle内核代码的哪个部分出现了ORA-600错误。没有这第一个参数的话，很难判断问题到底是什么。如果你访问了MetaLink，那么类型“ORA 600 xxxx”中的“xxxx”就是括号中的第一个参数。它应该可以帮助你辨别问题到底是什么，以及解决方案是什么。除此之外，你还可以试试在Google上查看是否有其他人以前发表了同样的错误。最后，ORA-600错误只能通过Oracle
Support来进行诊断。所以，如果以上所有方法都不能解决你的问题，就打开Oracle Support的TAR吧。

　　案例三:在Oracle 8i中更新表的时候出错

　　错误描述:我无法在Windows 2000下的Oracle 8i中对表进行更新。总是出现ORA-0600错误信息。你能帮助我吗?

　　处理过程：ORA-600错误信息是一个通用的错误信息，因为Oracle不知道错误是什么。所以它可能是由许多不同的问题导致的。代码中最重要的一部分信息就是ORA-00600后面括号里的第一部分。它指向了问题的原因。不幸的是，因为数据库不知道错误是什么，所以它就转而发送了一条通用的ORA-600错误信息。你可以咨询Oracle Support来解决这个问题。如果你没有联系到技术支持，那么到Metalink找出有关这个话题的Tar。他们可以为你解决问题。如果你从未访问过MetaLink，那么你最好是在google上查询"ORA",
"600"，以及括号内的第一个代码。很有可能会有人遇到和你一样的问题并且在网络上有相应的解决办法。

　　附录:ORA-00600错误分析（论坛精华整理）

　　ORA-600错误1->解决思路

　　ORA-00600: internal error code, arguments: [ksmovrflow], [kkznxddl.begin], [], [], [], [], [], []

　　晚上测试实体化视图复制，测试环境中的master site是Oracle10g，MV site是Oracle9201，当在MV site上创建快速刷新的实体化视图时，报ORA-600错误。

　　SQL> CREATE MATERIALIZED VIEW KAMUS.ACCOUNT2004 REFRESH FAST WITH PRIMARY KEY AS SELECT * FROM KAMUS.ACCOUNT2004@orcl;

　　CREATE MATERIALIZED VIEW KAMUS.ACCOUNT2004 REFRESH FAST WITH PRIMARY KEY AS SELECT * FROM KAMUS.ACCOUNT2004@orcl

　　ORA-00600: internal error code, arguments: [ksmovrflow], [kkznxddl.begin], [], [], [], [], [], []

　　查metalink，发现又是一个bug，这个bug只有当在Oracle8或者9中创建基于Oracle10g的实体化视图时才会发生。

　　Oracle10g的master table中创建主键时候显式指定了主键的名称。如下

　　alter table table_name add constraint < constraint name> primary key (< col>);

　　解决方法:

　　删除这个主键，然后创建一个不指定名称的主键，由Oracle自动命名，如下

　　alter table ACCOUNT2004 add primary key(OCCURTIME, ACCTID, CURRENCYID);

　　这样产生的主键名称就变成SYS_CXXXX。

　　之后重新在MV site上创建实体化视图，成功。

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

　　ORA-600错误2->解决思路

　　详细解决过程请查看 全文

　　提问者:rebecca_xt

　　查看trace和日志文件

　　LOG和TRACE 文件见 全文

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

　　回答者:logzgh

　　根据trace和日志文件看，应该是smon做回滚时出了问题。

　　建议在init.ora文件里面加上10046和10061,10513事件

　　event="10513 trace name context forever, level 2"

　　event="10061 trace name context forever, level 10"

　　event="10046 trace name context forever,level 4"

　　试试看，然后再将新产生的Trace文件上传。

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

　　提问者:rebecca_xt

　　我在初始化参数中加入如下

　　event="10513 trace name context forever, level 2"

　　event="10061 trace name context forever, level 10"

　　event="10046 trace name context forever,level 4"

　　数据库就可以打开了.为什么呀??

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

　　回答者:logzgh

　　有没有试试我说的那三个事件。特别是10061事件

　　你这个很可能是在smon清理临时段时报错。

　　现在你将10046和10513事件拿掉。

　　只加10061事件看看。如果只加10061事件可以启动的话，

　　那么你启动数据库后

　　执行alter session set events='immediate trace name drop_segments level 14'。

　　如果依然报错的话，你再执行

　　Select owner,segment_name,tablespace_name from dba_segments where segment_type='TEMPORARY';

　　看看是否有临时段存在非temp表空间中。如果有的话，将那个表空间的数据exp出来，drop掉再重建表空间，然后将其中的数据imp回去。

　　如果是100513事件启作用的话，可以采用隐含参数

　　_offline_rollback_segmnets或_corrupted_rollback_segments来处理，具体你可以在itpub上搜索，有很多的相关的文章。

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

　　提问者:rebecca_xt

　　的确是只加10061事件看看就可以启动数据库的。

　　alter session set events='immediate trace name drop_segments level 14'。

　　成功执行了。

　　这句的作用是什么呀?下一步还需要做什么

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

　　回答者:logzgh

　　成功了的话，你把那些事件都拿掉，正常启动数据库试试看。

　　思路很简单，看trace文件和alert.log文件，发现是oracle开始是可以open的，但是open过后，smon进程遇错，oracle被终止。

　　开始我猜想有两种可能，一种是做回滚时出错，还有一种是smon清理临时段出错。

　　后来想想前滚都已经正常 完成了，那回滚时报600号错误的可能性较小，因此怀疑是清理临时段报错了。加上10061事件，禁止smon清理临时段。然后手工清理。

　　如果一切顺利的话，此时正常启动数据库应该可以了。

　　后来进展不顺利，提问者和回答者MSN去了，不过大概思路就是这样的了，剩下的自己多试验一下应该就没问题了!

　　ORA-600错误3

　　ORA-600错误3->解决思路 全文

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

　　ORA-600错误4

　　ORA-00600: internal error code, arguments: [2662], [0], [431267754], [0], [431272752], [0], [], []

　　ORA-600错误4->解决思路 全文

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

　　ORA-600错误5

　　ORA-00600: internal error code, arguments: [3619], [13], [0]

　　ORA-600错误5->解决思路

　　这个错误解决的方法很简单，重建控制文件=OK。

　　ORA-600错误6

　　ORA-00600: internal error code, arguments: [ksmovrflow], [datablk : kspptsp], [], [], [], [], [], []

　　ORA-600错误6->解决思路

　　这个错误是spfile文件有损坏，您可以使用一个完好的pfile文件来启动数据库，然后create spfile from pfile='pfile的绝对路径';

　　SQL> shutdown immediate

　　数据库已经关闭。

　　已经卸载数据库。

　　ORACLE 例程已经关闭。

　　--修改init.ora 然后用修改后的启动数据库

　　SQL> startup pfile='d:/oracle/admin/orcl/pfile/init.ora'

　　ORACLE 例程已经启动。

　　Total System Global Area 135338868 bytes

　　Fixed Size 453492 bytes

　　Variable Size 109051904 bytes

　　Database Buffers 25165824 bytes

　　Redo Buffers 667648 bytes

　　数据库装载完毕。

　　数据库已经打开。

　　SQL> create spfile from pfile='d:/oracle/admin/orcl/pfile/init.ora';

　　文件已创建。

　　SQL> shutdown immediate

　　数据库已经关闭。

　　已经卸载数据库。

　　ORACLE 例程已经关闭。

　　SQL> startup --此时Oralce会自动的使用SPfile来启动数据库，所以直接startup就可以了

　　ORACLE 例程已经启动。

　　Total System Global Area 135338868 bytes

　　Fixed Size 453492 bytes

　　Variable Size 109051904 bytes

　　Database Buffers 25165824 bytes

　　Redo Buffers 667648 bytes

　　数据库装载完毕。

　　数据库已经打开。

相关笔记


err
ORA-00333err
SQL> alter database open; alter database open * ERROR at line 1: ORA-00333: redo log read error block 145410 count 2048 omdrms10:/RMSUAT/CHINACS/admin/bdump>tail -f alert_CHINACS.log SMON started ...

每一个DBA在进行数据库管理的过程中不可避免的要遇到形形色色的错误(ORA-xxxx)。有些错误由于频繁出现、原因复杂而被DBA们戏称之为"经典的错误"。其中O每一个DBA在进行数据库管理的过程中不可避免的要遇到形形色色的错误(ORA-xxxx)。有些错误由于频繁出现、原因复杂而被DBA们戏称之为"经典的错误"。其中ORA-3113
"end of fileon communication channel" 就是这样的一个. 　　 　　我们可以简单的把这个错误理解为Oracle客户端进程和数据库后台进程连接中断。不过，导致这个错误的原因实际上有很多种,对...