一、概述 在Oracle
数据库运行过程中，我们经常会遇到这样或那样的错误，但是错误的提示并不具体，加大了我们在诊断问题时的难度。 ErrorStack是Oracle提供的一种对于错误堆栈进行跟踪的方法，通过设置跟踪可以将一些指定错误的后台信息详细的转储出来，写入跟踪文件，帮助我们诊断问题。 备注： 1、当oracle发生关键的错误诸如：ora-600,Errorstack是自动被oracle dump写入trace文件中。 2、当你在alert.log里面看见这类错误，并提示已经产生trace文件。打开对应的trace后，你会发现这类trace文件一般都是以“ksedmp:internal or fatal error"开头，"kesdmp"意味着Kernel Service Error Dump，这一行下面的内容就是errorstack记录的错误堆栈！
Errorstack dump也可以通过使用Oradebug errorstack 3手工调用，前提是先使用Oradebug setospid设定了目标进程之后。Oradebug Errorstack对于诊断一个session似乎Hang住(但是在v$session_wait里面并未出现合理的wait event)或者是比正常时消耗更多资源时，获取当前session执行sql、具体的变量值等等信息，从而帮助你找到问题根源！
二、跟踪级别和方法 ErrorStack主要有4个跟踪级别，如下 0 仅转储错误堆栈
1 转储错误堆栈和函数调用堆栈
2 Level 1 + ProcessState
3 Level 2 + Context area （一般我们诊断问题，都是使用这个级别的跟踪！）
ErrorStack设置方法，如下（仅指定特定的错误代码，只有这个特定的错误出现时才能被触发！） 实例级别：alter system set events='984 trace name errorstack forever,level 3' scope=spfile;
会话级别: alter session set events='984 trace name errorstack forever,level 3';
oradebug： 1、oradebug setospid xxxx; 2、oradebug dump errorstack 3 --当前session正在运行的语句
三、ErrorStack跟踪文件中的内容 Errorstack跟踪文件有很多信息，这里我们主要讲解对我们诊断问题最有用的四个部分的内容（其它很多内容我们无法看懂），如下
从Errorstack跟踪文件中发现当前正在执行SQL文本。
从Errorstack跟踪文件中发现当前正在执行PL/SQL包和PL/SQL source code line number。
从Errorstack跟踪文件中发现当前bind variable value。
从Errorstack跟踪文件中发现一个cursor正在使用多少private memory(UGA)。
针对上面的四个部分，我将通过一个具体的errorstack跟踪文件示例来展示盒加深理解，errorstack的跟踪文件如下（具体生成方式代码，放在最后了）。这一部分的内容主要参考tanelpoder大牛的博客。
1、从Errorstack跟踪文件中发现当前正在执行SQL文本 这一部分非常容易找到，当前sql语句的文本信息在跟踪文件的最前面部分(可以搜索Current SQL statement for this session) Trace file /u01/oracle/diag/rdbms/cn100/cn100/trace/cn100_ora_10848.trc
Oracle
Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Oracle Label
Security, OLAP,
Data Mining,
Oracle
Database Vault
and
Real Application Testing
options
ORACLE_HOME = /u01/oracle/product/11.2.0
System
name: Linux
Node
name: 192oracle.cn100.com
Release: 2.6.32-358.el6.x86_64
Version: #1 SMP Fri Feb 22 00:31:26 UTC 2013
Machine: x86_64
Instance
name: cn100
Redo thread mounted
by this
instance: 1
Oracle process
number: 26
Unix process pid: 10848, image: oracle@192oracle.cn100.com (TNS V1-V3)
*** 2014-07-01 11:16:36.260
***
SESSION ID:(61.13360) 2014-07-01 11:16:36.260
*** CLIENT ID:() 2014-07-01 11:16:36.260
*** SERVICE
NAME:(SYS$USERS) 2014-07-01 11:16:36.260
***
MODULE
NAME:(
SQL*Plus) 2014-07-01 11:16:36.260
***
ACTION
NAME:() 2014-07-01 11:16:36.260
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0,
level=3, mask=0x0)
----- Error Stack Dump -----
ORA-01438:
value larger
than specified
precision allowed
for this
column
-----
Current SQL Statement for this
session (sql_id=b8n03s73k7d39) -----
--可以看到，当前SQL就在这一行下面
INSERT
INTO DH_T
VALUES (:B2 ,:B1 )
----- PL/
SQL Stack -----
----- PL/
SQL
Call Stack -----
object line
object
handle
number
name
0x1075fcd10 6
procedure DBMON.P_DH1
0xfcfaebe8 7
procedure DBMON.P_DH2
0x10e7d6420 1 anonymous block
-----
Call Stack Trace -----
calling
call entry argument
values
in hex
location
type point (? means dubious
value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+36
call kgdsdst() 000000000 ? 000000000 ?
7FFF332C8AD8 ? 00000 |