ORACLE问题诊断思路

Author: Rainny

Google的创始人说过一句话：一切皆有可能。作为软件，一切皆有可能。我总是对我自己说，如果你在使用某一种软件，发生任何错误，都是有可能的。所以，当发生错误时，最重要是你对待错误的心态和解决问题的思路。

   ORACLE作为一种大型的数据库软件，更是有无以统计的BUG，作为一个DBA，只要你还在这个行当，就有可能会碰到新的BUG。从某种角度上来说，DBA就相当于QA，他只是在使用人家开发的软件，而对ORACLE的熟悉程度，取决于他对ORACLE结构的了解深度。而对ORACLE的了解深度，又来自于日常的对ORACLE的操作和实践。

“一切ORACLE，源于ORACLE”，所有的DBA，除了其本身来自于ORACLE公司，从事ORACLE源代码的开发，其经验其实都是来自于对ORACLE这个软件的测试。换句话说，如果你没有碰到问题，那么你的ORACLE技术水平可能也就是在原地徘徊，而如果你不断碰到问题－>解决问题,则你的ORACLE能力在不断提高中。由于ORACLE体系庞大，所以其软件本身是由一个庞大的团队来开发完成的，所以，既使是参与ORACLE源代码开发的技术人员，也不可能完全了解ORACLE，一个人的精力和知识必竟是有限的。所以，在技术的海洋里，死记硬背了多少知识还不如掌握解决问题的思路和方法。所以从这一点来说，哲学上或其它方面的认识同样适用于软件。

     下面为ORACLE内核的结构图。结构图有点类似于武侠小说中某种武术的总诀，它能给你一个大概的认识。当然，任何一种结构都可能是由多个模块所组成。下面的内核子系统的解释最主要的帮助就在于，当你碰到ORACLE的错误时，内核子系统的简称有可能会出现在错误信息当中，这有助于你查找问题的根源。

 

 

 

What Kernel Subsystems are available?

Listed below are some of the important subsystems in the Oracle kernel. This table might help you to read those dreaded trace files and internal messages. For example, if you see messages like this, you will at least know where they come from:

OPIRIP: Uncaught error 447. Error stack:

KCF: write/open error block=0x3e800 online=1

Kernel Subsystems:

OPI

Oracle Program Interface

KK

Compilation Layer - Parse SQL, compile PL/SQL

KX

Execution Layer - Bind and execute SQL and PL/SQL

K2

Distributed Execution Layer - 2PC handling

NPI

Network Program Interface

KZ

Security Layer - Validate privs

KQ

Query Layer

RPI

Recursive Program Interface

KA

Access Layer

KD

Data Layer

KT

Transaction Layer

KC

Cache Layer

KS

Services Layer

KJ

Lock Manager Layer

KG

Generic Layer

KV

Kernel Variables (eg. x$KVIS and X$KVII)

S or ODS

Operating System Dependencies

 

 

ORACLE的错误有分好几种，有数据库的（如ORA-开头的），有操作系统相关的（如OSD-代表和操作系统有关），有网络的(如TNS-开头的代表是与网络连接有关的错误)，也有某一种实用工具的(如IMP-开头的代表是和ORACLE导入工具有关的错误)，其实这些都是ORACLE有做检查的错误。还有一种错误，错误号为ORA-00600的，这表示是ORACLE的内部错误？何谓内部错误？其实是ORACLE没有做检查，或者是没有写好异常处理的错误，这些内部错误其实大部分是ORACLE的一些BUG，也就是说是在ORACLE正式RELEASE的时候，还没有被QA检测出来的错误。ORACLE的开发人员在开发的时候就认识到，要完全避免错误是不可能的，但当有某种未知的错误出现时，会尽量给出一些诊断信息以供后面进行追踪。所以ORA-00600错误后面总是会有一些参数，这些参数就是一些提示信息，以供ORACLE SUPPORT人员进行问题追踪。

   到目前为止，还没有哪个人能完全总结出ORA-00600的所有参数，事实上它确实也是不可统计的。包括ORACLE的开发人员也无法预计会发生什么错误。当偶尔在报警日志中发现ORA-00600错误时，也不必惊慌。如果多次出现，经验告诉我们，这可能是ORACLE的BUG，你需要去应用OS或ORACLE的补丁或将ORACLE升级到某个稳定的版本。  

   处理问题的思路是，当错误发生时，要通过自己所掌握的知识，诊断问题大概是出在哪个子系统，然后再进一步深入下去。

   事实上，对于一些非常INTERNAL的问题，ORACLE公司内部或有一些工具，这些工具都是不公开的，也没有任何文档介绍，只供ORACLE内部最核心的技术人员使用。这其实也是ORACLE的商业机密。所以，错误是难免的，但出错了，总是有办法解决的。最终解决，还是要找ORACLE的，ORACLE也就是这么来赚钱的！哈哈！