0001 ?
7FFF332CCFD8 ? 000000000 ?
......为了排版,后续省略......
2、
从Errorstack跟踪文件中发现当前正在执行PL/SQL包和PL/SQL source code line number Errorstack跟踪文件和前面一样，如下 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 ? 000000001 ?
7FFF332CCFD8 ? 000000000 ?
......为了排版,后续省略...... 注意上面跟踪文件中PL/SQL标红那一部分，就是我们关注的部分。 如果进行errorstack跟踪式，跟踪进程执行的是一个PL/SQL调用，那么PL/SQL调用堆也将被跟踪下来(在PL/SQL Call Stack部分)。这部分告诉你错误发生时Oracle在执行具体哪个PL/SQL过程（包or函数）以及errorstack跟踪过程中的具体哪个调用发生错误。这对我们诊断问题非常有帮助 PL/SQL Call Stack包含三列，如下 object handle
line number
object name
下面我们一一介绍这三列的含义：
1、object handle object handle是这个对象(PL/SQL过程、包、函数、匿名块)被load进library cache中的内存地址，可以通过这个映射地址和X$KGLOB.KGLHDADR表列关联起来以发现那个对象是正在被处理。如下 SQL> select kglnaown,kglnaobj,kglhdadr from X$KGLOB a where KGLHDADR='00000001075FCD10'; KGLNAOWN KGLNAOBJ KGLHDADR ---------- ---------- ---------------- DBMON P_DH1 00000001075FCD10
2、line number 这个是非常重要的信息，它将告诉你当errorstack调用发生时正在执行的PL/SQL代码（可以定位到代码中的具体行）。例如，在如上的输出中，在这个匿名块的第1行调用了DBMON.P_DH2存储过程，而DBMON.P_DH2存储过程在第7行调用了另外一个存储过程DBMON.P_DH1，当errorstack跟踪发生时正在执行DBMON.P_DH2存储过程中的第6行代码。
3、object name PL/SQL存储的对象名(或者匿名块，当对象并没有存储在一个过程中)，如果是匿名块(匿名块的文本可以通过V$SQL发现),你可以关联这个地址和V$SQL.ADDRESS来发现匿名块的文本信息。
以上的PL/SQL call stack仅仅包含三行。 0x1075fcd10 6 procedure DBMON.P_DH1
0xfcfaebe8 7 procedure DBMON.P_DH2
0x10e7d6420 1 anonymous block
应该从下而上来
阅读一个PL/SQL call stack，例如 1.底部的行可以告诉我们正在执行一个匿名块以及在这个匿名块的第一行，它在调用DBMON.P_DH2存储过程 2.第二行可以告诉我们DBMON.P_DH2存储过程在第7行调用了另外一个存储过程DBMON.P_DH1 3.DBMON.P_DH2存储过程中的第6行代码出现错误，errorstack信息被转储。
通过查询DBA_SOURCE，我们可以与errorstack跟踪文件中的PL/SQL call stack部分信息进行验证，如下。 SQL> select line, text from dba_source where o |