1. 适用于：
Oracle Server - Enterprise Edition - Version: 8.1.7.4 to 11.1
any platform

2. 目标
如何分析与内部错误(ORA-600)和core dump (ORA-7445)相关的问题。

2.1 概述
本文指导客户通过metalink关键词查询，来对内部错误(ORA-600)和核心dump (ORA-7445)相关的问题进行初步分析。
根据关键字搜出很多文档后，要么是一些数据库bug的条目，或者是一些短文，必须同特定的环境相关联起来，从而缩小搜索范围。本文将给出一些小提示。

2.2 简介
常见的情况是，某些已经发现了的问题，已经在metalink中文档化了，或者已经有了公开的bug相关信息。使用恰当的技术，可以将范围缩小到某个特定的、能匹配问题的bug，在文档中找到临时解决措施，或者有关的补丁信息。本文的主要目的是重新查找导致内部错误或核心dump的oracle代码的bug。本文的目标是，发现oracle代码中导致内部错误和core dump的bug，这些方法可能在解决其他你可能遇到的问题的时候，也同样适用。下面的段落主要介绍如何从trace文件中提炼关联的关键字，来查找和特定错误环境相关的文档。同时也尽量尝试帮助大家通过和具体的错误环境相关联，来进一步缩小关联文档范围。

 
3. 解决方案
3.1 ORA-00600: 内部错误代码, 参数: [参数1] [参数X]
Oracle内核在遇到异常条件的时候，会产生内部错误ORA-600。在内核代码的不同处理阶段，一些被称为assertions的过程会被执行。这些条件必须是确定的，并确保能继续下去。Assertions是对实例与数据库的内存和数据完整性的内部健康的检查与保护。当这样的assertions失败后，就会抛出ORA-600错误，错误的第一个参数为数字或者数字字母类型，可能会有更多的参数，取决于具体错误。注意，并非所有的ORA-600错误都是导致会话终止的致命错误，有些是无所谓的。然而有些可能非常严重，需要进行仔细的调查。

3.1.1 ORA-600内部错误的第一个参数
最重要的一个单独的信息就是内部错误的第一个参数，其类型为数字或者字母数字，它唯一的标示了何种assertion失败以及报错的特定模块。当查找问题原因的时候，在关键字查询中，应该常常包含第一个参数。

3.2 ORA-07445:抛出异常：core dump
Core dump是一种异常的情况，和内部错误ORA-600类似，但是，他们最大的区别在于内核不会去解释错误，然而在出现内部错误时，通过assertion的方式来发现一个异常条件，这些assertion都是事先定义好的检查，core dump之所以出现，是由于操作系统在某些点上会终止进程，因为这些进程正在执行一个被禁止的操作，比如试图访问不属于进程的内存区。这就是为什么核心dump常常跟违反访问有关。在计算机术语中，'core’相当于是‘内存’。一个core dump就是进程的内存被dump到文件系统的一个文件‘core’中。

3.2.1标识失败模块
知道在哪个内部模块中产生了core dump非常重要。模块名通常会和错误显示在一起，但并不总是这样。如果没有和错误显示在一起，请参考3.2.5 Call Stack Trace，如果知道模块名的话，在搜索的关键字中包含失败的模块名。

4.1 Trace文件
对于内部错误和core dump，用户进程会在user_dump_dest目录下会产生一个跟踪文件，而后台进程会在background_dump_dest目录下会产生一个跟踪文件。在11g中，所有的跟踪文件都位于参数diagnostic_dest指定的目录下。两种类型的跟踪文件以同样的方式看待，尽管在跟踪文件中的一些特定的信息部分是否出现取决于特定错误。在core dump情况下，对内核来说，因为信号句柄可以捕捉此错误，通过调用dump程序比如ksedmp()，仍然可以将相关信息dump出来。另一方面，对大多数的内部错误而言，当dump准备就绪时，进程已经崩溃（终止了）。

4.2 跟踪文件的相关部分
并不打算在这里提供对跟踪文件的详细解释或者深入理解，下面的一些部分在跟踪文件中常常被标识出来，这些能帮助你提炼相关的关键字，来进行搜索，理解特定环境下发生什么错误，你就可以缩小查找范围了。

4.2.1 头部
头部包括一些诸如跟踪文件名字、oraclce的版本，ORACLE_HOME，系统名字，节点名字，OS版本，实例名，进程信息等。虽然在关键字中不会直接用上，但是在以后，在识别跟你问题相关的文档时非常有用。

4.2.2 错误部分
写入在alert.log中的错误如果经常重复出现，可能还有一些跟错误相关的额外信息。当内部错误发生的时候，除了ORA-600的参数之外，开发者可能打算将一些关键状态信息直接写入跟踪文件。此时，这些信息对你进行搜索是非常有帮助的。

4.2.3 会话的当前sql语句
也许你知道，也许并不不知道，错误发生的时候正在做什么操作。一些常见的关键字比如'insert', 'update' 或者 'delete'对你的搜索并没帮助（它们太常见了），而将特定的文档和问题的信息结合起来会比较有用，例如，某个bug在已经查到的信息中，它只在insert的时候发生，但是你却在执行delete操作，因此就可以放心的断言，这个bug跟你的问题无关。
如果当前的sql语句在跟踪文件中没有列出来，可以参见3.2.6游标dump。

4.2.4 PL/SQL Call Stack
如果当前的会话执行的是个PL/SQL操作，就会在此部分显示。它显示是什么用户或者内部的PL/SQL包被调用。Call Stacks应从底往上读，如果此处有oracle的包，就在你的搜索关键字中包含它。

4.2.5 Call Stack Trace
在call stack trace部分列举的模块，就是用户搜索的非常好的关键字，他们通常唯一标识特定bug，然而，在丢弃顶部或者底部的一些模块时要注意，下面一些模块应该被忽略：sigacthandler(),ssexhd(), ksedmp(), ksesicX()(其中的X是个数字，此数字表示是ora-600错误除第一个参数之外的一个参数)。所有的kse* 和 kge*模块通常可以被忽略，他们分别表示核心服务错误(Kernel Service Error)与核心通用错误（Kernel Generic Error），这些模块是在错误已经发生后被调用的，执行一些诸如dump跟踪文件之类的工作，并且这些对大多数的内部错误和core dump是相同的，因此对于缩小搜索范围没帮助。底部的一些模块也一样，他们只是用于一些初始化进程的开始，任何在opiexe()（包括）模块以下的模块都可以安全的忽略。当你使用3到4个来自call stack trace前面的相关模块（结合其他的相关关键字），在metalink搜索中，常常能有效找到相关结果。如果没有，你可能需要减少模块的搜索数量，从stack中自上向下删除模块。如果你还是没有找到结果，很可能你遇到的是一个新的尚未被发现的问题。

4.2.6 游标 Dump
即使在跟踪文件中当前的sql语句并没有和错误列在一起，游标仍然可以显示错误发生时的sql语句。只需要简单的搜索'current cursor'来找到一个游标号，然后往下找到对应游标号的游标。同时你也可以在这部分找到绑定变量的值，具体参考文档Note 154170.1以获取更详细的信息。

4.2.7 进程状态  -- 会话状态对象
一个进程的状态是进程状态对象的列表，详细讨论这些超出了本文范围，对现在而言，只需要知道，状态对象是以层次结构，来组织包含会话相关状态信息的内存对象。一个状态对象包含相关会话信息，可以帮助我们缩小特定错误的搜索范围。在你的跟踪文件中，简单的查找一下'program'，你就会找到类似下面的部分：
SO: 7000000223acfe0, type: 4, owner: 700000022357868, flag: INIT/-/-/0x00
    (session) trans: 7000000230d47a0, creator: 700000022357868, flag: (18100041) USR/- BSY/-/-/-/-/-
              DID: 0001-0012-00000083, short-term DID: 0000-0000-00000000
              txn branch: 0
              oct: 2, prv: 0, sql: 70000002831a5a0, psql: 70000002831a5a0, user: 48/ISIS
    O/S info: user: someuser, term: SOMETTY01, ospid: 628:1948, machine: BOX\SOMETTY01
              program: someprogram.exe
    application name: someprogram.exe, hash value=0
    last wait for 'db file sequential read' blocking sess=0x0 seq=1054 wait_time=16729
                file#=1, block#=2ec3, blocks=1
    temporary object counter: 0
当用到特定的程序的时候，你可能想在搜索关键字中将其包含进来，不管它是不是oracle客户端程序。我们有时候会以'as is'的方式提供和oracle相关的第三方产品信息。尝试标识何种类型的程序被使用，这些包括JDBC (thin or OCI), Pro*C, OCI等，有些问题比如与JDBC有关，这将对我们判断问题大有帮助。

5.1 使用‘高级搜索’
为了找到对应的数据库的bug入口（很可能包含了call stack trace中的模块），经常会做一次高级搜索，并确保在页面的右边部分的‘源’部分，我们选择的是‘Bug Database’，另外，在'Knowledge Base'部分，包含一些oracle员工的短文。开始不要选择'Technical Forum'，如果在’ knowlege base’和’ bug database’部分都没找到，在论坛中可能会找到一些相关信息(这并不是不重视forums，他们有不同的用途)。高级搜索的页面提示提供了一些高效搜索的技巧。

5.2 关键字搜索的一般解释
重要的是试验和错误，当搜索返回海量文档，尝试使用问题特定的其他关键字来缩小范围，另一方面，如果没有结果返回，减少一些关键字，如果你使用了太多的call stack trace中的模块，减少几个模块，但应该保留最上面的几个模块，一些特殊的模块可能已经出现的文档中以另外的名字被调用，或者call stack trace没有在bug的文档中明确写出。

5.3没有相关的bug或者文档
你可能是第一个遇到此问题的用户，在这种情况下，使用metalink把服务请求进行一个文件归档，尽量描述问题的详细情况，你也可以对按照前面的方法进行的分析做个小结。

5.4 提供反馈
如果你发现文档不清楚，或者认为包含错误，或者你基于自己的经验觉得可以增加相关信息，请使用反馈按钮，将文档号和你的意见提交给我们。我们非常欢迎高质量的反馈，因为这可以改进我们的知识基础。

6.1 将bug和文档与你的问题关联起来
现在你已经获得了很多关于通过浏览跟踪文件的相关部分来了解问题了，并且提取了合适数量和质量（唯一性）的关键字，你执行了搜索并得到一些相关文档，那些文档通常已经很清晰了，它们以QA的形式为你提供匹配你问题的详细环境。
Bug读起来很讨厌，请直接跳到最后，查看版本信息，看看bug描述是不是跟你的情况相同。一个已经处理并被发布了的bug应该会有这样的部分，除非它是另一个bug的重复，在这种情况下，需要查看源bug。自9.2开始后解决的bug中，常常会有一个note小结，读起来容易些。
你正遇到某个bug，如果你找到的信息与你的问题完全匹配，修订（补丁或者临时办法）可以解决问题。

7.0 小结
好的搜索关键字包括错误消息，内部错误的第一个参数以及相关的内部模块名，程序名和类型，可能会进一步缩小查找范围。

4. 参考文档
Note:260459.1