wner = 'DBMON' and name = 'P_DH2' order by line asc; LINE TEXT ---------- ------------------------------------------------------------ 1 procedure p_dh2 as 2 v_cnt number; 3 begin 4 ----just for errorstack test 5 select count(*) into v_cnt from dh_t; 6 dbms_output.put_line('the dh_t count is '||v_cnt); 7 p_dh1; 8 end; 9 9 rows selected. SQL> select line, text from dba_source where owner = 'DBMON' and name = 'P_DH1' order by line asc; LINE TEXT ---------- ------------------------------------------------------------ 1 procedure p_dh1 as 2 v_id number :=1234335; 3 v_name varchar2(200) :='oradh'; 4 begin 5 --just for errorstack test 6 insert into dh_t values (v_id,v_name); 7 commit; 8 end; 9 9 rows selected. 你可以发现会话正在执行的PL/SQL第6行（一个insert语句导致错误）。 通常,当error dump，crash，hang发生时(顶部的行是”parent" function递归调用的“child”function正在执行的代码)，PL/SQL errorstack告诉我们精确的PL/SQL code。
3、从Errorstack跟踪文件中发现当前bind variable value 为什么找到具体的语句后，我们还需要寻找具体的绑定变量值？？可以归纳为如下四种原因 一个会话可能以某种方式变的非常消耗CPU,并且会话的wait等待时间没有任何意义.
你需要调查什么SQL正在被执行，并且你需要查看SQL带有的绑定变量
SQL的执行计划是正常的，但是性能却非常低下
可以假设当某些表或者行源变的大的时候，存在数据倾斜，CBO没有计算出正确的执行计划。
因此，你需要知道当问题发生时SQL使用的绑定变量是什么，不幸的是
Oracle中并没有一个V$视图让我们去查看某个session的当前绑定变量值。V$SQL_BIND_CAPTURE视图仅仅随机的采样绑定变量值，并不存储所有的被使用的绑定变量值，而dbms_xplan.display_cursor中显示的也只是第一次窥探的绑定变量值.
Oracle 11gR2中实时的SQL Monitoring特性能够达到此目的。在V$SQL_MONITOR中有一列BIND_XML,此列包含正在运行的足够长时间(默认占用CPU超过5s的SQL，都会出现在次视图中)的bind variable values.但是这个只有在11gR2并且具有Diag+Tuning pack licenses时才有效。 注意：由于SQL语句的绑定变量值存在于进程的PGA中的私有内存中，因此不能轻易的跟踪另一个进程私有内存。errorstack跟踪文件中中包含CURSORDUMP,也就包含我们想要得到的bind variable value。
我们继续看开始的跟踪文件，如下 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 ? 000000 |