碰到一些SQL问题，有时常规的方式，例如执行计划，不足以给出问题的线索。因此，可能还需要跟踪这条SQL，通过Oracle提供的trace，了解它内部执行的机制，从中寻找线索。
需求：用户TEST通过dbeaver登录到数据库，需要跟踪它所执行的SQL。
（1）确定TEST用户通过dbeaver执行SQL的会话信息。
sys或者具有v$访问权限的用户，执行如下SQL，
select p.PID,p.SPID,s.SID, s.serial#, s.program, p.tracefilefrom v$process p,v$session swhere s.paddr = p.addrand s.username='TEST';
得到会话信息，根据实际情况，确认第二条记录，是需要的会话，
（2）sys或者高级别账号，执行如下语句，其中session_id是（1）的s.sid，serial_num是（1）的s.serial#，
begindbms_monitor.session_trace_enable(session_id =>364,serial_num =>5061,binds =>TRUE,waits =>TRUE,plan_stat =>'all_executions');end;/
（3）TEST用户执行语句，
SELECT * FROM t;（t表不存在）SELECT * FROM test;
（4）如上SQL执行的数据都存储到（1）的p.tracefile。从如下的展示，仅仅是（3）的这两条简单的语句，就写了33K的内容到trace，足以见得Oracle为了执行语句，其实内部机制还是很复杂的，
[oracle@VM-24-12-centos ~]$ ls -lrht /opt/oracle/diag/rdbms/bisalcdb/BISALCDB/trace/BISALCDB_ora_12992.trc-rw-r----- 1 oracle oinstall 33K Mar 5 22:30 /opt/oracle/diag/rdbms/bisalcdb/BISALCDB/trace/BISALCDB_ora_12992.trc
打开trace，可以看到第一条SQL提示了"PARSE ERROR"，第二条SQL展示了具体执行的信息（包括执行计划、PARSE/EXEC/FETCH等语句执行阶段的消耗），可以有助于进一步对SQL进行探索，
vi /opt/oracle/diag/rdbms/bisalcdb/BISALCDB/trace/BISALCDB_ora_12992.trc...=====================PARSE ERROR #140644761776904:len=15 dep=0 uid=112 oct=3 lid=112 tim=29833470188260 err=942SELECT * FROM tWAIT #140644761776904: nam='SQL*Net break/reset to client' ela= 6 driver id=1413697536 break?=1 p3=0 obj#=0 tim=29833470188396WAIT #140644761776904: nam='SQL*Net break/reset to client' ela= 171292 driver id=1413697536 break?=0 p3=0 obj#=0 tim=29833470359703WAIT #140644761776904: nam='SQL*Net message to client' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=0 tim=29833470359777*** 2023-03-05T22:30:19.385011+08:00 (BISALPDB1(3))WAIT #140644761776904: nam='SQL*Net message from client' ela= 7794254 driver id=1413697536 #bytes=1 p3=0 obj#=0 tim=29833478155022CLOSE #140644761776904:c=6,e=6,dep=0,type=0,tim=29833478155121...=====================PARSING IN CURSOR #140644761776904 len=18 dep=0 uid=112 oct=3 lid=112 tim=29833495043325 hv=2851490487 ad='68c943b0' sqlid='46ncd1ynzckpr'SELECT * FROM testEND OF STMTPARSE #140644761776904:c=12575,e=27931,p=3,cr=47,cu=0,mis=1,r=0,dep=0,og=1,plh=1357081020,tim=29833495043325EXEC #140644761776904:c=10,e=10,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1357081020,tim=29833495043368WAIT #140644761776904: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=0 tim=29833495043420FETCH #140644761776904:c=2,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1357081020,tim=29833495043440STAT #140644761776904 id=1 cnt=0 pid=0 pos=1 obj=73296 op='TABLE ACCESS FULL TEST (cr=0 pr=0 pw=0 str=1 time=1 us cost=2 size=13 card=1)'...
（5）关闭trace跟踪，则需要执行如下这条语句，
begindbms_monitor.session_trace_disable(session_id =>364,serial_num =>5061);end;/
可以将上述过程进行封装，通过工具、脚本等形式，快速调用，丰富我们排查问题的工具箱。
除此之外，10046和10053，也是我们探究问题需要具备的武器，
像常见的ORA-00060，同样通过Oracle自动生成的trace文件，可以从中找到锁之间的关联，进而有助于判断应用设计的逻辑顺序问题，
近期更新的文章：
近期的热文：
《推荐一篇Oracle RAC Cache Fusion的经典论文》
文章分类和索引：
原文作者：bisal的个人杂货铺；如有侵权，请联系管理员删除。
