Oracle中的SQL_TRACE是什么？诊断事件是什么？常用的10046及10053诊断事件的区别是什么？

SQL_TRACE

SQL_TRACE是Oracle提供的用于进行SQL跟踪的手段，是强有力的辅助诊断工具。在日常的数据库问题诊断和解决中，SQL_TRACE是非常常用的方法。可以设置SQL_TRACE为TRUE，但是一般不推荐在全局指定为TRUE，只建议在会话级别指定。若在全局设定则对性能会造成较大影响。

诊断事件

Oracle为数据库提供了多种的诊断工具，诊断事件（Event）是其中一种非常实用的方法，它能使DBA可以方便地转储数据库各种结构及跟踪特定事件的发生过程。
通过如下的脚本可以获取所有的诊断事件列表：

DECLARE
  ERR_MSG VARCHAR2(32767);
BEGIN
  DBMS_OUTPUT.ENABLE('');
  FOR ERR_NUM IN 10000 .. 10999 LOOP
    ERR_MSG := SQLERRM(-ERR_NUM);
    IF ERR_MSG NOT LIKE '%Message ' || ERR_NUM || ' not found%' THEN
      DBMS_OUTPUT.PUT_LINE(ERR_MSG);
    END IF;
  END LOOP;
END;
/

在Linux系统下诊断事件的消息文件放在目录：$ORACLE_HOME/rdbms/mesg/oraus.msg。oraus.msg文件属于文本文件，可以直接打开查看。

诊断事件可以像普通的ORA错误一样采用oerr命令来查询，如下所示：

[oracle@orclalhr ~]$ oerr ora 10046
10046, 00000, "enable SQL statement timing"
// *Cause:
// *Action:
[oracle@orclalhr ~]$ oerr ora 10053
10053, 00000, "CBO Enable optimizer trace"
// *Cause:
// *Action:
[oracle@orclalhr ~]$ oerr ora 10704
10704, 00000, "Print out information about what enqueues are being obtained"
// *Cause:  When enabled, prints out arguments to calls to ksqcmi and
//          ksqlrl and the return values.
// *Action: Level indicates details:
//   Level: 1-4: print out basic info for ksqlrl, ksqcmi
//          5-9: also print out stuff in callbacks:  ksqlac, ksqlop
//          10+: also print out time for each line

设置诊断事件有两种方法，一种是在pfile参数文件中设置事件，这样数据库在OPEN后，将影响到所有的会话。设置格式如下：

event="eventnumber trace name eventname [forever,] [level levelnumber] : ......."

通过冒号（:）符号，可以连续设置多个事件，也可以通过连续使用event来设置多个事件。如：

event = "10248 trace name context forever, level 10:10249 trace name context forever, level 10"

或者分开写，如：

event="10248 trace name context forever, level 10"
event="10249 trace name context forever, level 10"

另一种方法是在会话过程中使用ALTER SESSION SET EVENTS命令，只对当前会话有影响。设置格式如下：

ALTER SESSION|SYSTEM SET EVENTS '[eventnumber|immediate] trace name eventname [forever] [, level levelnumber] : .......' 

通过英文冒号（:）符号，可以连续设置多个事件，也可以通过连续使用ALTER SESSION SET EVENTS来设置多个事件，如：

ALTER SYSTEM SET 
           EVENTS='10325 trace name context forever, level 10','10015 trace name context forever, level 1' 
           COMMENT='Debug tracing of control and rollback';

-- 或：
ALTER SYSTEM SET EVENTS='10325 trace name context forever, level 10:10015 trace name context forever, level 1';

格式说明：

• eventnumber指触发dump的事件号，事件号可以是Oracle错误号（出现相应错误时跟踪指定的事件）或Oralce内部事件号，内部事件号在10000到10999之间，不能与immediate关键字同用。
• immediate关键字表示命令发出后，立即将指定的结构dump到跟踪文件中，这个关键字只用在ALTER SESSION语句中，并且不能与eventnumber、forever关键字同用。
• trace name是关键词，trace name位于第二、三项，除它们外的其它限定词是供Oracle内部开发组用的。
• eventname指事件名称，即要进行dump的实际结构名。若eventname为context，则指根据内部事件号进行跟踪。
• forever关键字表示事件在实例或会话的周期内保持有效状态，不能与immediate同用。
• level为事件级别关键字。但在dump错误栈（errorstack）时不存在级别。level通常位于1-10之间（10046有时用到12），10意味着转储事件所有的信息。例如当转储控制文件时，level 1表示转储控制文件头，而level 10表明转储控制文件全部内容。
• levelnumber表示事件级别号，一般从1到10，1表示只dump结构头部信息，10表示dump结构的所有信息。
• 转储所生成的trace文件在user_dump_dest初始化参数指定的位置。
• 移除所有的诊断事件（Event）：

ALTER SYSTEM RESET EVENT SCOPE=SPFILE SID='*' ;

如果设置了诊断事件（Event），那么如何知道在系统中设置了哪些诊断事件（Event）呢？如果事件是在pfile文件中设置的，那么可以用“SHOW PARAMETER EVENT”来查看。如果是通过“ALTER SYSTEM|SESSION”来设置的，那么可以使用如下的SQL来查看：

SET SERVEROUTPUT ON SIZE 1000000
DECLARE
  EVENT_LEVEL NUMBER;
BEGIN
  FOR I IN 10000 .. 99999 LOOP
    SYS.DBMS_SYSTEM.READ_EV(I, EVENT_LEVEL);
    IF (EVENT_LEVEL > 0) THEN
      DBMS_OUTPUT.PUT_LINE('Event ' || TO_CHAR(I) || ' set at level ' ||TO_CHAR(EVENT_LEVEL));
    END IF;
  END LOOP;
END;
/

但是，10046和10053事件不能通过这种方式查询，只能通过oradebug来查询，如下：

SYS@orclasm > oradebug setmypid
SYS@orclasm > oradebug eventdump system
SYS@orclasm > oradebug eventdump session

设置诊断事件需要注意的是，即可以使用“ALTER SYSTEM EVENTS”，也可以使用“ALTER SYSTEM EVENT”，它们的区别在如下2点：

①　EVENTS可以动态修改，可以使用“ALTER SESSION”或“ALTER SYSTEM”设置，只影响内存不影响参数文件

②　EVENT不能动态修改，只能使用“ALTER SYSTEM”或在参数文件里设置，必须重启库方可生效

另外，“ALTER SYSTEM”会记录到告警日志中，“ALTER SESSION”不会记录在告警日志中。

10046和10053

最为常用的诊断事件是10046和10053事件。10046事件是Oracle提供的内部事件，是对SQL_TRACE的增强。Oracle的10046事件，可以跟踪应用程序所执行的SQL语句，并且得到其解析次数、执行次数、CPU使用时间等信息。这对DBA来分析、定位数据库性能问题是非常有用的。
10046事件可分成不同的级别（LEVEL），分别追踪记录不同程度的有用信息。对于这些不同的级别，应当注意的是向下兼容的，即高一级的TRACE信息包含低于此级的所有信息。
10046事件可以设置以下级别:
①　level 0：禁用SQL_TRACE，等价于SQL_TRACE=FALSE
②　level 1：启用标准的SQL_TRACE功能跟踪SQL语句，包括解析、执行、提取、提交、回滚、响应时间、服务时间、处理的行数，物理读和写的数目、执行计划以及其它一些额外信息，等价于SQL_TRACE=TRUE
③　level 4：Level 1 + 包括绑定变量（Bind Values）的详细信息
④　level 8：Level 1 + 包括等待事件
⑤　level 12：包括绑定变量与等待事件，包含Level 1 + Level 4 + Level 8
10053事件是最常用的Oracle优化器跟踪Trace。10053事件解析优化器为什么选择某个执行计划但并不记录这个执行计划到底运行地如何。10046事件并不解释优化器的工作，但它记录了在SQL解析阶段所遇到的等待事件和所消耗的CPU等资源，以及执行阶段的各项指标。需要注意的是，如果一个SQL语句已经被解析过，那么就不会生成10053的trace文件，但10046的trace文件可以重复生成。
简而言之，10046事件记录SQL如何运行，而10053记录优化器为什么为这个SQL选择某个执行计划。

在Oracle中跟踪会话执行语句的几种方法

因为TRACE的目标范围不同，所以导致必须使用不同的方法。若作用于数据库全局的，则改初始化参数。若只作用于当前会话的，则就用ALTER SESSION命令。若作用于其它会话的，则就用DBMS_SYSTEM包。
①　SQL_TRACE参数设置：非常传统的方法
SQL_TRACE可以作为初始化参数在全局启用，也可以通过命令行方式在具体会话启用。在参数文件（PFILE/SPFILE）中指定：SQL_TRACE=TRUE或ALTER SYSTEM SET SQL_TRACE=TRUE;。
通过在全局启用SQL_TRACE可以跟踪到所有后台进程及所有用户进程的活动，通过跟踪文件的实时变化，可以清晰地看到各个进程之间的紧密协调。需要注意的是，在全局启用SQL_TRACE会产生大量trace文件，很容易耗尽磁盘空间，这通常会导致比较严重的性能问题，所以在生产环境中要谨慎使用，并且及时关闭。
在大多数时候使用SQL_TRACE跟踪的都是当前会话的进程。通过跟踪当前进程可以发现当前操作的后台数据库递归活动，这在研究数据库新特性时尤其有效，在研究SQL执行，发现后台错误等方面也非常有用。
在会话级启用和停止SQL_TRACE的方式如下所示：
启用当前SESSION的跟踪:

SQL> ALTER SESSION SET SQL_TRACE=TRUE;
Session altered.

此时的SQL操作将被跟踪:

SQL> SELECT COUNT(*) FROM DBA_USERS;
  COUNT(*)
----------
        44

结束跟踪:

SQL> ALTER SESSION SET SQL_TRACE=FALSE;
Session altered.

在很多时候需要跟踪其他用户的进程，而不是当前用户，这可以通过Oracle提供的系统包DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION来完成。

通过V$SESSION可以获得SID、SERIAL#等信息，获得进程信息，选择需要跟踪的进程：

SQL> col spid for a8
SQL> col spid for a10
SQL> col username for a10
SQL> col tracefile for a80
SQL> SELECT S.INST_ID, S.SID, S.SERIAL#, P.SPID, S.USERNAME, P.TRACEFILE
  2    FROM GV$SESSION S, GV$PROCESS P
  3   WHERE P.ADDR = S.PADDR
  4     AND S.INST_ID = P.INST_ID
  5     AND S.USERNAME IS NOT NULL;
   INST_ID        SID    SERIAL# SPID       USERNAME   TRACEFILE
---------- ---------- ---------- ---------- ---------- ---------------------------------------------------------------------------
         1        144        293 37302      SYS        /u02/app/oracle/diag/rdbms/oratest/oratest/trace/oratest_ora_37302_lhr.trc
         1        146       1557 37340      SYS        /u02/app/oracle/diag/rdbms/oratest/oratest/trace/oratest_ora_37340.trc
         1         26        321 37380      LHR        /u02/app/oracle/diag/rdbms/oratest/oratest/trace/oratest_ora_37380.trc
         1        152       3243 37400      SYS        /u02/app/oracle/diag/rdbms/oratest/oratest/trace/oratest_ora_37400.trc

设置跟踪SID为26的会话:

SQL> EXEC DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(26,321,TRUE);
PL/SQL procedure successfully completed.

可以等候片刻，等待SID为26的会话执行SQL，完成后，停止跟踪：

SQL> EXEC DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(26,321,FALSE);
PL/SQL procedure successfully completed.

①　使用10046事件

全局设定：参数文件中指定：EVENT="10046 TRACE NAME CONTEXT FOREVER,LEVEL 12"

或者：

SQL> ALTER SYSTEM SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';--启用
SQL> ALTER SYSTEM SET EVENTS '10046 TRACE NAME CONTEXT OFF';--关闭

当前会话设定：

SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';
SQL> --执行SQL语句
SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';

在Oracle 11g中还可以对单个SQL打开10046事件跟踪，命令如下所示：

ALTER SYSTEM SET EVENTS 'SQL_TRACE [SQL:&&SQL_ID] WAIT=TRUE,BIND=TRUE,PLAN_STAT=ALL_EXECUTIONS,LEVEL=12';

关闭单个SQL的跟踪命令如下所示：

ALTER SYSTEM SET EVENTS 'SQL_TRACE [SQL:&&SQL_ID] OFF';

若要针对每个新连接的会话生成10046跟踪文件，则可以使用登录触发器。如下的代码是跟踪LHR用户的信息，在用户LHR登录数据库系统时会启动10046跟踪。

CREATE OR REPLACE TRIGGER TRI_SET_TRACE_LHR
AFTER LOGON ON DATABASE
WHEN (USER IN ('LHR'))
DECLARE
BEGIN
    EXECUTE IMMEDIATE 'ALTER SESSION SET STATISTICS_LEVEL=ALL';
    EXECUTE IMMEDIATE 'ALTER SESSION SET MAX_DUMP_FILE_SIZE=UNLIMITED';
    EXECUTE IMMEDIATE 'ALTER SESSION SET EVENTS ''10046 TRACE NAME CONTEXT FOREVER, LEVEL 12''';
END TRI_SET_TRACE_LHR;

③　DBMS_SESSION包：只能跟踪当前会话，不能指定会话
跟踪当前会话：

SQL> EXEC DBMS_SESSION.SET_SQL_TRACE(TRUE);
SQL> 执行SQL
SQL> EXEC DBMS_SESSION.SET_SQL_TRACE(FALSE);

DBMS_SESSION.SET_SQL_TRACE相当于ALTER SESSION SET SQL_TRACE，从生成的TRACE文件可以明确地看ALTER SESSION SET SQL_TRACE语句。使用DBMS_SESSION.SESSION_TRACE_ENABLE过程，不仅可以看到等待事件信息还可以看到绑定变量信息，相当于“ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';”语句：

SQL> EXEC DBMS_SESSION.SESSION_TRACE_ENABLE(WAITS=>TRUE,BINDS=>TRUE);
SQL> 执行SQL
SQL> EXEC DBMS_SESSION.SESSION_TRACE_DISABLE(); 

④　DBMS_SYSTEM包
使用DBMS_SYSTEM.SET_EV设置10046事件：

SQL> EXEC DBMS_SYSTEM.SET_EV(SID,SERIAL#,10046,12,'');--启用跟踪
SQL> EXEC DBMS_SYSTEM.SET_EV(SID,SERIAL#,10046,0,'');--结束跟踪

⑤　DBMS_MONITOR包
该包是从Oracle 10g开始提供的，功能非常强大。可在模块级别、动作级别、客户端级别、数据库级别、会话级别进行跟踪，Oracle官方支持。

-- 跟踪当前会话：
SQL> EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE;
SQL> --执行SQL
SQL> EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE;

-- 跟踪其他会话：
SQL>EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(SESSION_ID=>SID,SERIAL_NUM=>SERIAL#,WAITS=>TRUE,BINDS=>TRUE);
SQL> --执行SQL
SQL>EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(SESSION_ID=>SID,SERIAL_NUM=>SERIAL#);

⑥　oradebug
这是SQL*Plus的工具，需要提供OSPID或者Oracle PID。

-- 跟踪当前会话：
SQL> oradebug setmypid;
Statement processed.
SQL> oradebug unlimit;
Statement processed.
SQL> oradebug event 10046 trace name context forever,level 12;
Statement processed.
SQL> 执行SQL
SQL> oradebug tracefile_name
SQL> oradebug event 10046 trace name context off;
Statement processed.

-- 跟踪其他会话：
SQL> select spid,pid2  from v$process
  2  where addr in (select paddr from v$session where sid=(select distinct sid from v$mystat));
SPID                PID

------------ ----------
1457                 313
SQL> oradebug setospid 1457;
Statement processed.
-- 或者：
SQL> oradebug setorapid 313;
Statement processed.
SQL> oradebug unlimit;
Statement processed.
SQL> oradebug event 10046 trace name context forever,level 12;
Statement processed.
SQL> oradebug tracefile_name
SQL> oradebug event 10046 trace name context off;
Statement processed.

使用oradebug help可以查看oradebug的命令帮助。

⑦　dbms_support包

系统默认没有安装dbms_support这个包，可以手动执行$ORACLE_HOME/rdbms/admin/bmssupp.sql脚本来创建该包跟踪当前会话：

SQL> exec dbms_support.start_trace
SQL> 执行sql
SQL> exec dbms_support.stop_trace
跟踪其他会话：等待事件+绑定变量，相当于level 12的10046事件。
SQL> select sid,serial#,username from v$session where ...;
SQL> exec dbms_support.start_trace_in_session(sid=>sid,serial=>serial#,waits=>true,binds=>true);
SQL> exec dbms_support.stop_trace_in_session(sid=>sid,serial=>serial#);

----select value from v$diag_info where name like '%Default%';

对于一个比较复杂的存储过程来说，如何快速定位到是什么语句什么原因导致的失败解析呢？

在解析SQL的过程中，若碰到SQL语法错误、访问的对象不存在或没有权限，则会导致目标SQL语句解析失败，所以，解析失败的SQL语句是不会生成执行计划的。可以通过如下几种方式找到解析失败的SQL：

①　通过关联X$KGLCURSOR和X$KGLCURSOR_CHILD_SQLID视图

②　通过使用10035事件

③　通过Oracle systemdump

Oracle提供了一系列的跟踪事件来帮助定位各种问题，通过10035事件可以诊断解析失败的情况，如下：

[oracle@rhel6lhr ~]$ oerr ora 10035

10035, 00000, "Write parse failures to alert log file"

首先通过“alter system set events '10035 trace name context forever,leve 5';”开启监控，然后使用tail观察告警日志，找到问题SQL之后，使用命令“alter system set events '10035 trace name context off';”关闭10035事件。

errorstack的作用是什么？

参考：https://www.xmmup.com/ruhezhenduanyixieweiyuliaode-oracle-cuowuora-nnnn-shiyongerrorstackshengchengzhenduanwenjian.html

如何收集systemdump？如何收集hanganalyze？

参考：https://www.xmmup.com/ruheshoujisystemdumpruheshoujihanganalyze.html