10046 trace详解(1)

本文详述了Oracle数据库中10046事件的使用方法,包括不同层级的跟踪设置、特定场景下的应用及trace文件解析。10046事件用于深入分析SQL语句的运行状态,涵盖Parse、Fetch、Execute各阶段的等待事件、资源消耗及执行计划,是SQL调优和DDL命令分析的强大工具。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

    10046 trace帮助我们解析一条/多条SQL、PL/SQL语句的运行状态,这些状态包括:Parse/Fetch/Execute三个阶段中遇到的等待事件、消耗的物理和逻辑读、CPU时间、执行计划等,它为我们揭示了一条、多条SQL的运行情况,对SQL调优是一个非常好的辅助工具,同时还能帮我们分析一些DDL维护命令的内部工作原理,RMAN、Data Pump Expdp/impdp等工具缓慢问题。

    记得进公司面试时提到这个一样问题,查看SQL执行计划有哪此方法,10046、PL/SQL F5快捷键、EXPLAIN PLAN FOR ....、TOAD也可以查看,其实10053也可以查看SQL的执行计划,那么10046和10053的区别是什么呢?10053是最常用的ORACLE优化器optimizer跟踪trace,10053可以作为我们解析优化器为什么选择某个执行计划,其中理由的辅助工具,但并不告诉我们这个执行计划到底运行的如何。而10046并不解释optimizer优化器的工作,但它同样说明了在SQL解析Parse阶段所遇到的等待事件和所消耗的CPU资源,以及Execute执行和Fetch阶段的各项指标,简单来说,10046告诉我们SQL插计划运行情况,10053告诉我们优化器为什么选择这个执行计划。

     通常为了诊断SQL调优类问题,我们需要记录下这些语句在执行过程中产生的等待以及bind variables(绑定变量)的信息。 这些信息可以通过级别为12的10046 trace获得。下面的例子列举了在各种场景下,如何设定10046事件。

一、Trace文件的位置
    从11gR1开始,Oracle引入了新的诊断结构,以参数DIAGNOSTIC_DEST控制存放trace文件与core文件的路径。可以用以下命令,获取DIAGNOSTIC_DEST的位置:

    SQL> show parameter diagnostic_dest;

    11gR1以前,果是用户进程,10046 trace文件会被生成在user_dump_dest下,如果是后台进程,trace文件会被生成在background_dump_dest下,下面的命令可以显示user_dump_dest:

    SQL> show parameter user_dump_dest

    注:通过设定tracefile_identifier,通过这个设置可以帮助我们更容易的找到生成的trace文件。

二、在Session级打开trace
    这种方法适用于SQL语句可以在新的session创建后再运行。

    alter session set tracefile_identifier='10046'; 
    alter session set timed_statistics = true;
    alter session set statistics_level=all;--实例级别设置此选项需要注意,会消耗大量的CPU
    alter session set max_dump_file_size = unlimited;
    alter session set events '10046 trace name context forever,level 12';
 --常用的级别是12
    执行需要被trace的SQL

    select * from dual;
    exit;
    如果不退出当前session, 可以用以下命令关闭trace:

    alter session set events '10046 trace name context off';

    注意,如果session没有被彻底地关闭并且跟踪被停止了,某些重要的trace信息的可能会丢失。
    注意:这里我们将"statistics_level"设置为all,这是因为有可能这个参数在系统级不是默认值"TYPICAL"(比如 BASIC)。为了收集性能相关问题的信息我们需要打开某个级别的statistics。我们推荐在 session 级将这个参数设置成 ALL 以便于收集更多的信息,尽管这不是必须的。

三、跟踪一个已经开始的进程
    如果需要跟踪一个已经存在session,可以用 oradebug连接到session上,并发起10046 trace。
    首先,用某种方法找到需要被跟踪的session.
    例如,在SQL*Plus里,找出目标session的OS的进程ID(spid):
    select p.PID,p.SPID,s.SID
    from v$process p,v$session s
    where s.paddr = p.addr
    and s.sid = &SESSION_ID
    /

   SPID  是操作系统的进程标识符(os pid)
   PID 是Oracle的进程标识符(ora pid)
    假设需要被跟踪的OSPID是9834,以sysdba的身份登录到SQL*Plus并执行下面的命令:
    oradebug setospid 9834
   oradebug unlimit
   oradebug event 10046 trace name context forever,level 12
   注: 也可以通过oradebug使用 'setorapid'命令连接到一个session。
   下面的例中, 使用 PID(Oracle进程标识符)(而不是SPID), oradebug命令将被改为:
   connect / as sysdba
   oradebug setorapid 9834
   oradebug unlimit
   oradebug event 10046 trace name context forever,level 12
   跟踪过程完成以后,关闭oradebug跟踪:
    oradebug event 10046 trace name context off
四、实例层的跟踪
  
 注意: 在实例层设置跟踪需要非常小心,这是因为整体性能会由于所有session都被跟踪而受到影响,这个设置将会跟踪在这个参数设置“以后”创建的每个session。已经存在的session不会被跟踪,系统层的10046跟踪适用于当我们知道问题session会出现,但是不能预先识别它的时候,在这种情况下,可以打开系统层跟踪一小段时间,当问题被重现以后立即将其关闭,然后从已经生成的trace中查找需要的信息,用以下命令打开系统层的跟踪:

    alter system set events '10046 trace name context forever,level 12'

用以下命令关闭在所有session中的10046跟踪:

    alter system set events '10046 trace name context off';
五、通过初始化参数设置进行实例层的跟踪
    设置以下参数并重新启动实例后,实例上所有的session都会打开跟踪。

    event="10046 trace name context forever,level 12"

    如果要关闭可以通过移除这个参数并且重启实例,或者使用下面的alter system命令可以关闭跟踪。

    alter system set events '10046 trace name context off';

六、通过logon trigger设置跟踪
   有的时候当需要跟踪某个特定用户的操作时,可以使用logon trigger来打开跟踪

   CREATE OR REPLACE TRIGGER SYS.set_trace
   AFTER LOGON ON DATABASE
   WHEN (USER like '&USERNAME')
   DECLARE
   lcommand varchar(200);
   BEGIN
   EXECUTE IMMEDIATE 'alter session set tracefile_identifier=''From_Trigger''';
   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 set_trace;

   / 

   需要注意的事,为了能打开跟踪session, 执行trigger的用户需要被显式地授予'alter session'权限

   grant alter session to user_xj

七、用SQLT收集trace
    SQLTXPLAIN的Xecute方法生成的诊断文件中会包含10046 trace,正如XECUTE这个名字所示,SQLT会执行被分析的SQL语句,然后生成一个诊断文件集(包括10046 trace)。详见:
    Note:215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose SQL statements performing poorly (Doc ID 215187.1)

    用这种方法生成的trace文件会被包含在SQLT输出包中, 格式为:

    sqlt_s12345_10046_execute.trc   --其中12345是SQLT报告ID
八、用DBMS_MONITOR进行跟踪
    DBMS_MONITOR包提供几个打开跟踪的方法。详细请见:
    Note:293661.1 Tracing Enhancements In 10g Using DBMS_MONITOR
    如果您运行的是PL/SQL存储过程或包,那么可以通过使用PL/SQL profiler判断PL/SQL运行期间的时间消耗的具体信息。下面的文档介绍了PL/SQL profiler的使用方法:
    Note:243755.1 Implementing and Using the PL/SQL Profiler

九、其它特定场景下打开跟踪的方法
    Note:21154.1 EVENT: 10046 "enable SQL statement tracing (including binds/waits)"
   
 Note:1274511.1 General SQL_TRACE / 10046 trace Gathering Examples
   
 Note:160124.1 How to Set SQL Trace on with 10046 Event Trace which Provides the Bind Variables
   
 Note:371678.1 Capture 10046 Traces Upon User Login (without using a trigger)
   
 Note:1102801.1 How to Get 10046 Trace for Parallel Query
   
 Note:242374.1 Tracing PX session with a 10046 event or sql_trace
   
 Note:258418.1 Getting 10046 Trace for Export and Import

十、Trace文件解析

    Note:199081.1 SQL_TRACE (10046), TKProf and Explain Plan - Overview Reference
   
 Note:39817.1 Interpreting Raw SQL_TRACE and DBMS_SUPPORT.START_TRACE output
   
 Note:224270.1 Trace Analyzer TRCANLZR - Interpreting Raw SQL Traces with Binds and/or Waits 

                  generated by EVENT 10046
   
 NOTE:41634.1 - TKProf Basic Overview
   
 NOTE:32951.1 - TKProf Interpretation (9i and below)
   
 NOTE:760786.1 - TKProf Interpretation (9i and above)
   
 NOTE:214106.1 - Using TKProf to compare actual and predicted row counts
   
 Note:199083.1 * Master Note: SQL Query Performance Overview
   
 Note:398838.1 * FAQ: SQL Query Performance - Frequently Asked Questions

转载于:https://www.cnblogs.com/youngerger/p/8541788.html

<think>好的,用户现在想详细了解Arthas中的trace命令的用法和功能。之前已经给出过一些命令列表,但用户现在特别关注trace,所以需要深入展开。 首先,我需要回顾之前提供的回答,确保信息一致。之前的回答中提到了trace命令用于追踪方法内部调用链路,并统计各节点耗时,支持按耗时过滤。示例是`trace *MathUtils calculate* '#cost>50'`。现在需要更详细地解释这些内容。 接下来,用户提供的站内引用中,引用[2]提到了trace命令如何工作,以及一个字节码的例子。这说明用户可能对trace的工作原理感兴趣,比如它是如何通过字节码增强来实现的。需要将这部分信息整合进去,但要用更易懂的语言解释,而不是直接引用字节码。 用户的需求是详细用法和功能说明,因此需要分点列出。可能的结构包括基本功能、核心特性、参数详解、使用示例、注意事项等。同时,要结合之前的引用,如`reset`命令在停止后重置增强类,避免性能影响,这也需要在注意事项里提到。 还需要考虑用户可能的实际使用场景。比如性能调优、排查超时问题、理解调用链路等。给出不同场景下的示例命令,帮助用户更好地应用。例如,结合慢SQL调优,或者多层调用分析。 要注意用户可能遇到的常见问题,比如正则表达式匹配、耗时过滤的语法、输出结果的理解。这些都需要在说明中解释清楚,避免用户混淆。 另外,用户可能对高级用法感兴趣,比如结合其他命令(tt、watch)使用,或者在排查复杂问题时如何组合命令。可以简要提及这些,但不过于深入,保持回答的专注性。 最后,确保引用正确的参考文献,比如引用[1]中的基础命令和reset,引用[2]中的trace工作原理。同时,添加相关问题,帮助用户进一步学习,比如如何优化耗时方法,trace和watch的区别,以及如何排查阻塞问题。 检查是否覆盖了所有关键点:功能、参数、示例、注意事项、高级技巧、相关引用,以及相关问题。确保语言简洁明了,结构清晰,符合用户要求的格式,如使用中文,正确使用LaTeX语法等。</think>### Arthas `trace` 命令详解与高级用法 `trace` 是 Arthas 中最常用的性能诊断命令之一,主要用于**追踪方法内部调用链路**,并**精确统计各层调用耗时**,帮助快速定位性能瓶颈。以下从功能原理、参数解析到实战场景进行完整说明。 --- #### 一、**核心功能与原理** 1. **功能定位** - 统计方法内部调用链路中**每个节点的执行耗时**(支持递归层级追踪) - 支持**条件过滤**(如耗时阈值、异常状态) - 通过**字节码增强技术**实现无侵入式监控[^2] 2. **工作原理** `trace` 通过动态修改目标方法的字节码(参考引用[2]中的字节码示例),在方法入口/出口处插入监控代码,记录时间戳并计算耗时。执行完成后,将统计结果按调用层级树状展示。 --- #### 二、**基础语法与参数** ```bash trace [类全限定名] [方法名] [条件表达式] [参数选项] ``` | 参数/选项 | 说明 | |---------------------|--------------------------------------------------------------------| | `-n <value>` | 执行次数限制(如 `-n 5` 表示仅记录前5次调用) | | `#cost > 100` | 耗时过滤条件(单位:ms,仅输出耗时超过100ms的调用) | | `-E` | 开启正则表达式匹配类名/方法名(默认通配符`*`匹配) | | `--skipJDKMethod` | 跳过JDK内置方法(如`java.util.*`,减少干扰) | | `--listenerId <id>` | 绑定监听器ID(用于动态启停监控任务) | --- #### 三、**使用场景与示例** ##### 场景1:**定位接口响应慢的根因** ```bash trace com.example.OrderController getOrderDetail "#cost > 200" -n 3 ``` - **输出结果**: ```text ---ts=2023-10-01 12:00:00;thread_name=main;id=1;is_daemon=false;priority=5; `---[205ms] com.example.OrderController:getOrderDetail() +---[10ms] com.example.OrderService:queryOrder() # 查询订单 +---[180ms] com.example.PaymentService:checkPayment() # 检查支付状态 `---[15ms] com.example.LogService:writeLog() # 记录日志 ``` - **分析**:`checkPayment` 方法耗时占比87%,需优先优化支付状态检查逻辑[^1]。 ##### 场景2:**分析多层嵌套调用** ```bash trace -E com\.service\..*Service .* -j 3 "#cost > 50" --skipJDKMethod ``` - **参数说明**: - `-E`:正则匹配 `com.service` 包下所有以 `Service` 结尾的类 - `-j 3`:追踪最大深度为3层 - `--skipJDKMethod`:过滤JDK内置方法 ##### 场景3:**结合条件表达式排查偶现问题** ```bash trace *UserService getUserInfo 'params[0]!=null && params[0].length()>10 && #cost>100' ``` - **功能**:仅当用户ID长度超过10且耗时超过100ms时触发记录。 --- #### 四、**高级技巧** 1. **动态启停监控** 通过 `--listenerId` 实现灵活控制: ```bash trace --listenerId 1 *Service * "#cost>200" # 启动监听 trace --listenerId 1 -d # 停止监听 ``` 2. **结合 `watch` 命令深度分析** 当 `trace` 定位到高耗时方法后,使用 `watch` 观察具体参数和返回值: ```bash watch com.example.PaymentService checkPayment "{params, returnObj}" -x 3 -s ``` 3. **耗时统计校准** 通过 `-n` 参数限制采样次数,避免高频监控影响性能: ```bash trace *Dao * -n 10 "#cost>50" # 仅采样前10次符合条件的调用 ``` --- #### 五、**注意事项** 1. **性能影响** - 高频方法(如每秒万次调用)谨慎使用,建议通过 `-n` 限制采样次数 - 诊断完成后及时执行 `stop` 或 `reset` 清除增强代码[^1] 2. **正则匹配陷阱** - 类名/方法名中含特殊字符(如`$`)需转义,例如 `com.example.Class\$Inner` 3. **耗时精度** - 统计耗时包含Arthas自身逻辑耗时(通常 <1ms,可忽略) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值