数据库中ORA-600各个参数含义分析

本篇内容主要讲解"数据库中ORA-600各个参数含义分析"，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习"数据库中ORA-600各个参数含义分析"吧!

一. ORA-600 概述

ORA-600 是一个非常头疼的一个错误。比如：

ORA-00600:internal error code, arguments: [4194], [43], [46], [], [], [], [], []

这个就是undo 损坏出现故障的一个提示信息。

二. 第一个参数说明

在[ID 175982.1]文档上的定义分成了2种：

（1）the first parameter is a number which reflects the source componentor layer the error is connected with; or

（2）the first parameter is a mnemonic which indicates the source modulewhere the error originated. This type of internal error is now used inpreference to an internal error number.

2.1 Internal Errors Categorised by numberrange（数字类型）

Thefollowing table provides an indication of internal error codes used in theOracle server. Thus, if ora-600[X] is encountered, it is possible to glean somehigh level background information : the error in generated in the Y layer whichindicates that there may be a problem with Z.

2.2 Internal Errors Categorised by mnemonic（字符串类型）

Thefollowing table details mnemonics error stems which are possible. If you haveencountered : ora-600[kkjsrj:1] for example, you should look down the ErrorMnemonic column (errors in alphabetical order) until you find the matchingstem. In this case, kkj indicates that something unexpected has occurred in jobqueue operation.

三. 其他参数说明

在MOS 的文档： [ID28929.1] 上有说明。

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

http://blog.csdn.net/tianlesoftware/article/details/6106130

Oracle DB 服务器 系统时间修改问题 与 SCN 关系的深入研究

http://blog.csdn.net/tianlesoftware/article/details/6163859

ORA-600 各个参数的格式和说明如下：

ERROR:

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

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 wherethe dependent SCN came from.

注意，这里的DBA 指的是Data Block Address. 相关说明，参考我的Blog：

Oracle rdba和 dba 说明

http://blog.csdn.net/tianlesoftware/article/details/6529346

From kcrf.h:

Ifthe SCN comes from the recent or current SCN then a dba of zero is saved. If itcomes from undo$ because the undo segment is not available then the undosegment number is saved, which looks like a block from file 0. If the SCN isfor a media recovery redo (i.e. block number == 0 in change vector), then thedba is for block 0 of the relevant datafile. If it is from another database fora distributed transaction then dba is DBAINF(). If it comes from a TX lock thenthe dba is really usn<<16+slot.

在MOS 的文档：[ID 365536.1] 里提到了SCN 与SCN WRAP，SCN BASE这两个参数的关系。

SCN value is storedinternally as :

（1）SCN_wrap

（2）SCN_base

Wheneverthe SCN is incremented, the BASE component is incremented first unil it reachesit maximum. Once the BASE reaches the maximum value allowed, it is initializedto zero again after incrementing the WRAP by 1.

--开始时WRAP 为0，即SCN_WRP=0.当BASE增长到最大值后，SCN_BAS变为0. 同时SCN_WRP增长到1

Using this logic, we cancalculate the timestamp of the SCN as follows:

(SCN_WRP* 4294967296) + SCN_BAS should give us the SCN in the number format

--SCN 的计算公式，这里我们看出SCN 是根据SCN_BAS计算出来的。和系统时间是没有关系的。 只是方便我们来进行操作，如闪回恢复，而将SCN 和 系统时间每隔5分钟进行一次映射。 映射完后，由SMON进程将映射关系写入SMON_SCN_TIME表。 可以把SCN 看成是Oracle内部的时间。

To get the time/date for an SCN value in9i, use the following example:

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

-- (a) Get the current SCN base.

SQL>select max(scn_bas) SCN_BASE fromsmon_scn_time;

1603342197

--(b) Get the complete SCN and thetimestamp.

SQL> alter session setNLS_DATE_FORMAT='DD-MON-YY HH:MI:SS';

SQL> select time_dp TIMESTAMP,scn_wrp*4294967296+SCN_bas SCN from smon_scn_time where scn_bas='1603342197';

TIMESTAMP SCN

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

28-JUL-06 05:31:08 8252235517813

现在来看下这5个参数之间的关系。

ARGUMENTS:

Arg [a] Current SCN WRAP

Arg [b] Current SCN BASE

Arg [c] dependent SCNWRAP

Arg [d] dependent SCN BASE

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

根据SCN WRAP 和 SCN BASE，我们可以计算出当前SCN 对应的timestamp。

对与depent SCN 和 current SCN 关系，咨询了一下dbsnake。给出的回复如下：

当一个库是clean shutdown的时候，Oracle一定会做full checkpoint，把所有的dirty block都写回各自的datafile，同时把当前的SCN作为checkpoint SCN写回到各个datafile的datafile header中。也就是说，如果一个库是clean shutdown，那么这个库不可能有一个数据块的块里的SCN（Oracle的一个数据块里的SCN有三种，分别是块头的SCN，CSC和ITL中记录的commit SCN）比刚才写回的checkpoint SCN要大。

当一个库启动时，Oracle会做一系列的校验，其中有一个检查就是Oracle会去检查system表空间下的某些块，如果Oracle发现这些块里的SCN要比这个库当前的current SCN（实际上，启库时的current SCN就来源于shutdown时记录在datafileheader中的checkpoint SCN）要大的时候，就表明这个库是有问题了，

此时Oracle就会报跟SCN相关的一系列错误，ORA-600[2662]只是其中的一种。对于ORA-600[2662]这种情况，dependent SCN实际上就是Oracle发现有问题的system表空间下的某些块里的SCN，这个SCN可能是这个块里ITL中记录的commit SCN，也有可能是CSC (cleanout SCN)。

根据dbsnake 的说明，这个dependent SCN 是某个数据块里的SCN. 正常情况下，这个SCN 是要小于current SCN的，当dependent SCN 大于current SCN 就会报相关的错误。instance failure 和physical corruption 都可能会造成这个问题。

到此，相信大家对"数据库中ORA-600各个参数含义分析"有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！