ORA-07445和ORA-00600是系统内部错误 查错方法

ORA-07445和ORA-00600是系统内部错误，一般是由于BUG引起的，要解决或者避免这些错误一般需要到metalink上查。metalink甚至专门推出了一个工具用于这两个错误的查找。

与普通错误不同的是，ORA-07445和ORA-00600是一系列错误的总称，引起错误的原因可能成千上万个，如何快速、准确地找出到错误的原因是解决这类问题的难点。
出现ORA-07445或ORA-00600错误时，一般都会产生一个trace文件，这个文件的路径和名称可以在alert文件中找到。
这篇文章主要是谈谈如何在trace文件找找出关键信息。

1、ORA-07445

找出ORA-007445最关键是找出出错的函数名（这里的函数是指开发ORALCE的函数），然后根据函数名搜索错误原因及解决方法。
ORA-07445后一般跟着若干个由[]括起来的字符串，通常第一个被[]括起来的字符串就是我们需要的函数名。
ORA-07445的报错一般有两种：
1）ORA-07445: exception encountered: core dump [lnxmin()+252] [SIGSEGV] [Address not mapped to object] [0x000000002] [] []
这种情况很简单，第一个被[]括起来的字符串是lnxmin，这就是引发错误的函数名，我们根据这个信息去查就可以了。

2）ORA-07445: exception encountered: core dump [0000000100E84B7C] [SIGSEGV] [Address not mapped to object] [0x0000004F0] [] []
这种情况比较麻烦，因为oracle并没有告诉我们出错的函数名，0000000100E84B7C可能只是一个地址，无法根据这个来作为关键字进行查询。
这时我们就要从trace文件着手了。在trace文件内容的前部分中的Call Stack Trace部分可以发现有用信息。
对比一下多个trace文件，可以发现在这种情况下Call Stack Trace一般都包含类似下面的内容：
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+328 CALL ksedst()+0 FFFFFFFF7FFF3BD0 ?
000000000 ? 000000000 ?
00000003E ?
FFFFFFFF7FFF4468 ?
1031D56C8 ?
ssexhd()+604 CALL ksedmp()+0 000000000 ? 000103400 ?
0001035D9 ? 000102C00 ?
1035D9000 ? 1035D9C28 ?
sigacthandler()+44 PTR_CALL 0000000000000000 1035E1000 ?
FFFFFFFF7FFF5400 ?
000000000 ? 000000001 ?
1035DEDD8 ? 00000000B ?
qsmkzii_init_qsmksi PTR_CALL 0000000000000000 00000000B ?
nline()+624 FFFFFFFF7FFF5400 ?
FFFFFFFF7FFF5120 ?
00000000B ? 00038001C ?
1035DC458 ?
qsmkzss_setup_summa CALL qsmkzii_init_qsmksi FFFFFFFF7CD12908 ?
ry()+480 nline()+0 000103000 ?
FFFFFFFF7CD93650 ?
000000000 ?
FFFFFFFF7CD93650 ?
103258100 ?
......

其中里面的ksedmp、ssexhd、sigacthandler这三个函数在每一个ORA-07445 [0000000100E84B7C]类似的trace文件都存在，这是进行oracle异常处理的，一般不用管。
stack的第一列的第四行的信息就是我们需要的信息：qsmkzii_init_qsmksinline，这个就是出错的函数名。
在metalink根据这个函数名去查找，一般就可以知道错误的原因和是否有合适的方面来解决、避免这个错误。
如果根据第四行的函数名得不到有用的信息，可以尝试一下第五行的信息作为函数名，如果还是不能查到有用的信息，则可以认为metalink上没有这个错误的信息。

2、ORA-00600
查找ORA-00600的关键信息比ORA-07445稍微简单，它相当于ORA-07445的第一种情况。
ORA-00600后一般跟着若干个由[]括起来的字符串，通常第一个被[]括起来的字符串就是我们需要的参数。
ORA-00600的报错信息在从alert文件和trace文件都存在，不过为了得到更多的信息，建议看trace文件。
一个ORA-00600的trace文件类似下面：
*** SESSION ID:(22.3813) 2004-10-26 09:57:13.167
*** 2004-10-26 09:57:13.167
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Current SQL statement for this session:
SELECT VALUE FROM NLS_INSTANCE_PARAMETERS WHERE PARAMETER ='NLS_DATE_FORMAT'
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+328 CALL ksedst()+0 FFFFFFFF7FFF9660 ?
000000000 ? 000000000 ?
00000003E ?
FFFFFFFF7FFF9EF8 ?
1031C9458 ?
kgerinv()+184 PTR_CALL 0000000000000000 000000000 ? 000103400 ?
0001035CD ? 000102C00 ?
1035CD000 ? 1035CD328 ?
kgeasnmierr()+28 CALL kgerinv()+0 1035CD588 ? 1036EDE38 ?
0000013C8 ? 000000001 ?
1035CF694 ? 1035CE958 ?
ttcgcshnd()+248 CALL kgeasnmierr()+0 1035CD588 ? 1036EDE38 ?
1033A2758 ? 000000001 ?
000000000 ? 000000000 ?
ttcc2u()+784 CALL ttcgcshnd()+0 1035CD588 ? 102DA4880 ?

上面的信息中，ttcgcshnd-1就是我们要找的第一个参数，也是查询的关键字。

3、trace中其他有用的信息
在ORA-00600和ORA-07445的trace文件都包含了一些其他的有用信息。
在trace文件的PROCESS STATE部分，可以查看出错时SESSION的信息，包含主机名、那个用户执行的、用什么工具执行的等。
这些信息可能不太好找，查找方法是：从trace文件中找到PROCESS STATE，然后从PROCESS STATE往下找第一个"session"（关键字）出现的地方，这部分信息就包含我们需要的这些重要信息。

按照关键字"HOST"查可以得到客户端的IP