引言在Oracle数据库性能调优工作中当我们通过AWR报告或实时监控定位到高消耗SQL之后下一步就需要对SQL进行微观层面的深度剖析。SQL Trace10046事件配合TKPROF工具是Oracle提供的最经典、最强大的SQL级性能分析手段。它能精确记录SQL执行过程中的每一步等待事件、CPU消耗、逻辑读和物理读是SQL调优的“显微镜”。本文将系统讲解SQL Trace的原理、启用方法、Trace文件的管理以及如何用TKPROF将原始Trace文件转换为可读性强的分析报告帮助你从Trace文件中提取关键性能信息。一、SQL Trace的核心原理1.1 什么是SQL TraceSQL Trace是Oracle数据库提供的一种内核级诊断工具。当对某个会话或整个实例启用SQL Trace后Oracle会将SQL执行过程中的所有细节信息写入一个Trace文件中包括每条SQL的解析Parse、执行Execute、获取Fetch各阶段的耗时CPU时间、等待事件及耗时逻辑读consistent gets db block gets和物理读disk reads执行计划及行源操作统计信息绑定变量的值1.2 10046事件的级别SQL Trace通过10046事件来控制跟踪深度共分为四个级别| 级别 | 说明 | 用途 ||------|------|------|| Level 1 | 标准SQL Trace | 记录SQL执行的基本统计信息 || Level 4 | Level 1 绑定变量值 | 可以看到SQL实际使用的绑定变量值 || Level 8 | Level 1 等待事件 | 记录SQL执行过程中的所有等待事件及耗时 || Level 12 | Level 1 绑定变量 等待事件 | 最全面的Trace级别推荐用于深入分析 |10046事件级别Level 1Level 4Level 8Level 12基本SQL统计CPU时间/逻辑读/物理读Level 1 绑定变量值Level 1 等待事件详情Level 1 绑定变量 等待事件最全面二、启用SQL Trace的六种方法2.1 方法一对当前会话启用最常用-- 开启Level 12的Trace ALTER SESSION SET events 10046 trace name context forever, level 12; -- 执行需要分析的SQL SELECT * FROM employees WHERE department_id 10; -- 关闭Trace ALTER SESSION SET events 10046 trace name context off;2.2 方法二使用DBMS_SESSION包-- 对当前会话开启 EXEC DBMS_SESSION.SESSION_TRACE_ENABLE(waits TRUE, binds TRUE); -- 执行SQL... -- 关闭 EXEC DBMS_SESSION.SESSION_TRACE_DISABLE();2.3 方法三对其他会话启用-- 查询目标会话的SID和SERIAL# SELECT sid, serial#, username, status FROM v$session WHERE username HR; -- 对指定会话开启Trace EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE( session_id 123, serial_num 456, waits TRUE, binds TRUE ); -- 关闭指定会话的Trace EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE( session_id 123, serial_num 456 );2.4 方法四使用DBMS_MONITOR对特定服务/模块启用-- 对特定服务和模块组合开启Trace EXEC DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE( service_name SALES_SVC, module_name ORDER_ENTRY, waits TRUE, binds TRUE ); -- 关闭 EXEC DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE( service_name SALES_SVC, module_name ORDER_ENTRY );2.5 方法五设置SQL_ID级别Trace12c及以上-- 对特定SQL_ID开启Trace ALTER SYSTEM SET EVENTS sql_trace [sql: 5tjqf7sxdz5g2] level12; -- 关闭 ALTER SYSTEM SET EVENTS sql_trace [sql: 5tjqf7sxdz5g2] off;2.6 方法六通过登录触发器-- 创建登录触发器对特定用户的会话自动开启Trace CREATE OR REPLACE TRIGGER trace_hr_session AFTER LOGON ON DATABASE BEGIN IF USER HR THEN EXECUTE IMMEDIATE ALTER SESSION SET events 10046 trace name context forever, level 12; END IF; END; /三、定位和读取Trace文件3.1 查找Trace文件路径-- 查看Trace文件目录 SHOW PARAMETER user_dump_dest; -- 或者通过以下查询获取完整路径 SELECT value FROM v$parameter WHERE name user_dump_dest; -- 查看当前会话的Trace文件名Oracle 11g及以上 SELECT value FROM v$diag_info WHERE name Default Trace File;3.2 标识自己的Trace文件-- 在Trace文件中加入标记便于后续识别 ALTER SESSION SET tracefile_identifier my_sql_test; -- Trace文件名将包含此标识SID_ora_PID_my_sql_test.trc3.3 查看Trace文件名的方法-- 方法一通过v$process和v$session关联 SELECT p.tracefile FROM v$session s, v$process p WHERE s.paddr p.addr AND s.sid (SELECT SYS_CONTEXT(USERENV, SID) FROM DUAL); -- 方法二使用oradebug需SYSDBA权限 ORADEBUG SETMYPID ORADEBUG TRACEFILE_NAME四、TKPROF工具详解4.1 什么是TKPROFTKPROFTransient Kernel Profiler是Oracle自带的命令行工具用于将原始Trace文件二进制的、难以阅读的格式转换为格式化的、易读的分析报告。它能汇总每条SQL的执行统计计算每条SQL的资源消耗按多种维度排序CPU时间、物理读、逻辑读、执行次数等生成包含执行计划的报告4.2 TKPROF的基本语法tkprof trace_file output_file [options]常用选项| 选项 | 说明 ||------|------||sysno| 排除SYS用户递归执行的SQL强烈推荐 ||sortoption| 按指定维度排序输出 ||printn| 只输出前n条SQL ||aggregateyes/no| 是否合并相同SQL的统计信息 ||explainuser/pass| 为每条SQL生成执行计划 ||recordfile| 将Trace中的SQL提取到文件中 ||waitsyes/no| 是否输出等待事件摘要 ||insertfile| 生成可将统计信息存入数据库的INSERT脚本 |4.3 排序选项详解sort参数是TKPROF最重要的选项决定报告中SQL的排列顺序| 排序键 | 含义 ||--------|------||prsela| 按解析阶段总耗时Parse Elapsed ||exeela| 按执行阶段总耗时Execute Elapsed ||fchela| 按获取阶段总耗时Fetch Elapsed ||prscpu| 按解析阶段CPU时间 ||execpu| 按执行阶段CPU时间 ||fchcpu| 按获取阶段CPU时间 ||prscnt| 按解析次数 ||execnt| 按执行次数 ||fchcnt| 按获取次数 ||disk| 按物理读数量 ||query| 按逻辑读数量Consistent Gets DB Block Gets ||rows| 按处理行数 |常用排序组合# 按物理读降序排列分析I/O瓶颈 tkprof ora_12345.trc output_io.txt sysno sortdisk # 按获取阶段耗时降序排列分析查询响应时间 tkprof ora_12345.trc output_time.txt sysno sortfchela # 按逻辑读降序排列分析SQL效率 tkprof ora_12345.trc output_gets.txt sysno sortquery五、TKPROF报告解读指南5.1 报告整体结构一份典型的TKPROF报告包含以下部分1. 头信息Trace文件名称、版本、排序选项 2. SQL语句摘要每条SQL的统计信息 3. 执行计划SQL的执行路径 4. 等待事件摘要等待类型及次数统计 5. 总体摘要所有SQL的汇总统计5.2 SQL语句摘要部分解读SQL ID: 5tjqf7sxdz5g2 Plan Hash: 3896541234 SELECT employee_id, first_name, last_name FROM employees WHERE department_id :dept_id call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.01 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 0.15 0.18 45 3200 0 43 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.15 0.20 45 3200 0 43 Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 84 (HR) Rows Row Source Operation ------- --------------------------------------------------- 43 TABLE ACCESS BY INDEX ROWID EMPLOYEES (cr3200 pr45 pw0 time186543 us) 43 INDEX RANGE SCAN EMP_DEPT_IDX (cr150 pr10 pw0 time45123 us)(object id 74821)关键指标解读| 列名 | 含义 | 分析要点 ||------|------|----------||call| SQL处理阶段Parse/Execute/Fetch | 三个阶段各自消耗多少资源 ||cpu| CPU时间秒 | 与elapsed对比差距大说明有等待 ||elapsed| 总耗时秒 | 包含CPU时间和等待时间 ||disk| 物理读数据块 | 值越高I/O开销越大 ||query| 一致性逻辑读CR Gets | 反映SQL访问的数据块数量是SQL效率的核心指标 ||current| 当前模式逻辑读DB Block Gets | 通常来自DML操作 ||rows| 处理的行数 | 与实际返回的行数对比 |5.3 行源操作信息解读在Row Source Operation部分cr一致性逻辑读数量pr物理读数量pw物理写数量time本步骤消耗时间微秒通过对比每一步的cr和pr可以精确定位SQL执行过程中最耗资源的步骤。5.4 执行计划与统计信息如果在TKPROF中使用了explain参数报告还会包含优化器估算的执行计划。将估算的计划与实际的行源操作统计进行对比可以发现统计信息不准确或优化器选择偏差的问题。六、完整操作流程示例是否1.确定分析目标SQL2.选择Trace启用方式3.开启SQL Trace4.执行目标SQL5.关闭SQL Trace6.定位Trace文件7.使用TKPROF格式化8.分析TKPROF报告找到性能瓶颈?9.制定优化方案返回检查Trace级别或扩大范围10.实施优化并验证实战命令序列-- 步骤1-5在SQL*Plus中操作 ALTER SESSION SET tracefile_identifier perf_test; ALTER SESSION SET events 10046 trace name context forever, level 12; -- 执行目标SQL SELECT /* my_test */ e.employee_id, e.last_name, d.department_name FROM employees e, departments d WHERE e.department_id d.department_id AND e.salary 5000; ALTER SESSION SET events 10046 trace name context off; -- 步骤6找到Trace文件 SELECT value FROM v$diag_info WHERE name Default Trace File;# 步骤7在操作系统命令行执行TKPROF cd /u01/app/oracle/diag/rdbms/orcl/orcl/trace/ # 按物理读排序输出 tkprof orcl_ora_12345_perf_test.trc report_disk.txt sysno sortdisk # 按获取阶段耗时排序并生成执行计划 tkprof orcl_ora_12345_perf_test.trc report_time.txt \ sysno sortfchela explainhr/hr waitsyes # 提取SQL语句到文件 tkprof orcl_ora_12345_perf_test.trc report_sql.txt \ sysno recordextracted_sql.sql七、Trace分析的高级技巧7.1 使用trcsess合并多个Trace文件当应用通过连接池访问数据库时一个业务操作可能涉及多个会话的Trace可以使用trcsess工具合并# 按Session ID合并 trcsess outputmerged.trc session123.456 *.trc # 按客户端ID合并需要在应用端设置DBMS_SESSION.SET_IDENTIFIER trcsess outputmerged.trc clientidmyapp *.trc # 对合并后的文件运行TKPROF tkprof merged.trc merged_report.txt sysno sortfchela7.2 分析绑定变量值当Trace级别包含Level 4或Level 12时可以在Trace文件中直接看到绑定变量值BINDS #18446744071539018256: Bind#0 oacdty02 mxl22(22) mxlc00 mal00 scl00 pre00 oacflg03 fl21000000 frm00 csi00 siz24 off0 kxsbbbfp7f8b3c0a5d00 bln22 avl02 flg05 value10或在TKPROF报告中使用bindsyes参数查看。7.3 与AWR数据关联验证将TKPROF报告中SQL的SQL_ID与AWR中的记录关联-- 从AWR中查询同一SQL_ID的历史执行统计 SELECT snap_id, executions_delta, elapsed_time_delta / 1000000 AS elapsed_sec, disk_reads_delta, buffer_gets_delta, rows_processed_delta FROM dba_hist_sqlstat WHERE sql_id 5tjqf7sxdz5g2 ORDER BY snap_id;八、使用场景与最佳实践8.1 典型使用场景| 场景 | Trace方案 | 分析重点 ||------|-----------|----------|| 单条SQL响应慢 | 当前会话Level 12 | 等待事件分布物理读比例 || 批量作业性能差 | 对其他会话启用Level 8 | Execute阶段耗时逻辑读总量 || 绑定变量窥探问题 | Level 12 | 查看绑定变量实际值对比不同值的计划 || 间歇性性能抖动 | DBMS_MONITOR长期监控 | 结合ASH数据对比异常时段 || 连接池环境 | trcsess合并多个Trace | 端到端的完整调用链路 |8.2 注意事项与风险性能影响Level 12的Trace会产生大量写入I/O对生产系统有不可忽视的性能影响。建议在业务低峰期使用或对单个会话短期开启。磁盘空间Trace文件增长极快需要确保Trace目录有足够空间并在分析完成后及时清理。优先使用DBMS_MONITOR在生产环境中推荐使用DBMS_MONITOR系列包其功能更丰富且易于管理。敏感信息Trace文件中可能包含业务数据绑定变量值需要注意安全保管。不要只依赖TKPROF估算计划explain参数生成的是估算计划与实际情况可能存在差异。务必结合Trace中实际的行源操作统计进行分析。九、总结与建议SQL Trace是Oracle最底层的SQL性能分析工具通过10046事件的四个级别控制跟踪粒度Level 12绑定变量等待事件是进行深度分析的最佳选择。TKPROF将原始Trace文件转化为结构化报告核心排序键包括fchela查询耗时、disk物理读、query逻辑读根据不同的分析目标选择合适的排序方式。报告解读的核心是对比CPU时间与Elapsed时间识别等待、关注物理读与逻辑读的比例评估缓存效率、分析行源操作每一步的资源消耗定位执行计划瓶颈。最佳实践先通过AWR定位高消耗SQL再用SQL Trace对该SQL进行微观剖析最后结合执行计划和统计信息制定优化方案。调优箴言TKPROF报告中的每个数字都有其物理含义不要满足于“看到了什么”而要追问“为什么是这个数字”。
引言在Oracle数据库性能调优工作中当我们通过AWR报告或实时监控定位到高消耗SQL之后下一步就需要对SQL进行微观层面的深度剖析。SQL Trace10046事件配合TKPROF工具是Oracle提供的最经典、最强大的SQL级性能分析手段。它能精确记录SQL执行过程中的每一步等待事件、CPU消耗、逻辑读和物理读是SQL调优的“显微镜”。本文将系统讲解SQL Trace的原理、启用方法、Trace文件的管理以及如何用TKPROF将原始Trace文件转换为可读性强的分析报告帮助你从Trace文件中提取关键性能信息。一、SQL Trace的核心原理1.1 什么是SQL TraceSQL Trace是Oracle数据库提供的一种内核级诊断工具。当对某个会话或整个实例启用SQL Trace后Oracle会将SQL执行过程中的所有细节信息写入一个Trace文件中包括每条SQL的解析Parse、执行Execute、获取Fetch各阶段的耗时CPU时间、等待事件及耗时逻辑读consistent gets db block gets和物理读disk reads执行计划及行源操作统计信息绑定变量的值1.2 10046事件的级别SQL Trace通过10046事件来控制跟踪深度共分为四个级别| 级别 | 说明 | 用途 ||------|------|------|| Level 1 | 标准SQL Trace | 记录SQL执行的基本统计信息 || Level 4 | Level 1 绑定变量值 | 可以看到SQL实际使用的绑定变量值 || Level 8 | Level 1 等待事件 | 记录SQL执行过程中的所有等待事件及耗时 || Level 12 | Level 1 绑定变量 等待事件 | 最全面的Trace级别推荐用于深入分析 |10046事件级别Level 1Level 4Level 8Level 12基本SQL统计CPU时间/逻辑读/物理读Level 1 绑定变量值Level 1 等待事件详情Level 1 绑定变量 等待事件最全面二、启用SQL Trace的六种方法2.1 方法一对当前会话启用最常用-- 开启Level 12的Trace ALTER SESSION SET events 10046 trace name context forever, level 12; -- 执行需要分析的SQL SELECT * FROM employees WHERE department_id 10; -- 关闭Trace ALTER SESSION SET events 10046 trace name context off;2.2 方法二使用DBMS_SESSION包-- 对当前会话开启 EXEC DBMS_SESSION.SESSION_TRACE_ENABLE(waits TRUE, binds TRUE); -- 执行SQL... -- 关闭 EXEC DBMS_SESSION.SESSION_TRACE_DISABLE();2.3 方法三对其他会话启用-- 查询目标会话的SID和SERIAL# SELECT sid, serial#, username, status FROM v$session WHERE username HR; -- 对指定会话开启Trace EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE( session_id 123, serial_num 456, waits TRUE, binds TRUE ); -- 关闭指定会话的Trace EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE( session_id 123, serial_num 456 );2.4 方法四使用DBMS_MONITOR对特定服务/模块启用-- 对特定服务和模块组合开启Trace EXEC DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE( service_name SALES_SVC, module_name ORDER_ENTRY, waits TRUE, binds TRUE ); -- 关闭 EXEC DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE( service_name SALES_SVC, module_name ORDER_ENTRY );2.5 方法五设置SQL_ID级别Trace12c及以上-- 对特定SQL_ID开启Trace ALTER SYSTEM SET EVENTS sql_trace [sql: 5tjqf7sxdz5g2] level12; -- 关闭 ALTER SYSTEM SET EVENTS sql_trace [sql: 5tjqf7sxdz5g2] off;2.6 方法六通过登录触发器-- 创建登录触发器对特定用户的会话自动开启Trace CREATE OR REPLACE TRIGGER trace_hr_session AFTER LOGON ON DATABASE BEGIN IF USER HR THEN EXECUTE IMMEDIATE ALTER SESSION SET events 10046 trace name context forever, level 12; END IF; END; /三、定位和读取Trace文件3.1 查找Trace文件路径-- 查看Trace文件目录 SHOW PARAMETER user_dump_dest; -- 或者通过以下查询获取完整路径 SELECT value FROM v$parameter WHERE name user_dump_dest; -- 查看当前会话的Trace文件名Oracle 11g及以上 SELECT value FROM v$diag_info WHERE name Default Trace File;3.2 标识自己的Trace文件-- 在Trace文件中加入标记便于后续识别 ALTER SESSION SET tracefile_identifier my_sql_test; -- Trace文件名将包含此标识SID_ora_PID_my_sql_test.trc3.3 查看Trace文件名的方法-- 方法一通过v$process和v$session关联 SELECT p.tracefile FROM v$session s, v$process p WHERE s.paddr p.addr AND s.sid (SELECT SYS_CONTEXT(USERENV, SID) FROM DUAL); -- 方法二使用oradebug需SYSDBA权限 ORADEBUG SETMYPID ORADEBUG TRACEFILE_NAME四、TKPROF工具详解4.1 什么是TKPROFTKPROFTransient Kernel Profiler是Oracle自带的命令行工具用于将原始Trace文件二进制的、难以阅读的格式转换为格式化的、易读的分析报告。它能汇总每条SQL的执行统计计算每条SQL的资源消耗按多种维度排序CPU时间、物理读、逻辑读、执行次数等生成包含执行计划的报告4.2 TKPROF的基本语法tkprof trace_file output_file [options]常用选项| 选项 | 说明 ||------|------||sysno| 排除SYS用户递归执行的SQL强烈推荐 ||sortoption| 按指定维度排序输出 ||printn| 只输出前n条SQL ||aggregateyes/no| 是否合并相同SQL的统计信息 ||explainuser/pass| 为每条SQL生成执行计划 ||recordfile| 将Trace中的SQL提取到文件中 ||waitsyes/no| 是否输出等待事件摘要 ||insertfile| 生成可将统计信息存入数据库的INSERT脚本 |4.3 排序选项详解sort参数是TKPROF最重要的选项决定报告中SQL的排列顺序| 排序键 | 含义 ||--------|------||prsela| 按解析阶段总耗时Parse Elapsed ||exeela| 按执行阶段总耗时Execute Elapsed ||fchela| 按获取阶段总耗时Fetch Elapsed ||prscpu| 按解析阶段CPU时间 ||execpu| 按执行阶段CPU时间 ||fchcpu| 按获取阶段CPU时间 ||prscnt| 按解析次数 ||execnt| 按执行次数 ||fchcnt| 按获取次数 ||disk| 按物理读数量 ||query| 按逻辑读数量Consistent Gets DB Block Gets ||rows| 按处理行数 |常用排序组合# 按物理读降序排列分析I/O瓶颈 tkprof ora_12345.trc output_io.txt sysno sortdisk # 按获取阶段耗时降序排列分析查询响应时间 tkprof ora_12345.trc output_time.txt sysno sortfchela # 按逻辑读降序排列分析SQL效率 tkprof ora_12345.trc output_gets.txt sysno sortquery五、TKPROF报告解读指南5.1 报告整体结构一份典型的TKPROF报告包含以下部分1. 头信息Trace文件名称、版本、排序选项 2. SQL语句摘要每条SQL的统计信息 3. 执行计划SQL的执行路径 4. 等待事件摘要等待类型及次数统计 5. 总体摘要所有SQL的汇总统计5.2 SQL语句摘要部分解读SQL ID: 5tjqf7sxdz5g2 Plan Hash: 3896541234 SELECT employee_id, first_name, last_name FROM employees WHERE department_id :dept_id call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.01 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 0.15 0.18 45 3200 0 43 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.15 0.20 45 3200 0 43 Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 84 (HR) Rows Row Source Operation ------- --------------------------------------------------- 43 TABLE ACCESS BY INDEX ROWID EMPLOYEES (cr3200 pr45 pw0 time186543 us) 43 INDEX RANGE SCAN EMP_DEPT_IDX (cr150 pr10 pw0 time45123 us)(object id 74821)关键指标解读| 列名 | 含义 | 分析要点 ||------|------|----------||call| SQL处理阶段Parse/Execute/Fetch | 三个阶段各自消耗多少资源 ||cpu| CPU时间秒 | 与elapsed对比差距大说明有等待 ||elapsed| 总耗时秒 | 包含CPU时间和等待时间 ||disk| 物理读数据块 | 值越高I/O开销越大 ||query| 一致性逻辑读CR Gets | 反映SQL访问的数据块数量是SQL效率的核心指标 ||current| 当前模式逻辑读DB Block Gets | 通常来自DML操作 ||rows| 处理的行数 | 与实际返回的行数对比 |5.3 行源操作信息解读在Row Source Operation部分cr一致性逻辑读数量pr物理读数量pw物理写数量time本步骤消耗时间微秒通过对比每一步的cr和pr可以精确定位SQL执行过程中最耗资源的步骤。5.4 执行计划与统计信息如果在TKPROF中使用了explain参数报告还会包含优化器估算的执行计划。将估算的计划与实际的行源操作统计进行对比可以发现统计信息不准确或优化器选择偏差的问题。六、完整操作流程示例是否1.确定分析目标SQL2.选择Trace启用方式3.开启SQL Trace4.执行目标SQL5.关闭SQL Trace6.定位Trace文件7.使用TKPROF格式化8.分析TKPROF报告找到性能瓶颈?9.制定优化方案返回检查Trace级别或扩大范围10.实施优化并验证实战命令序列-- 步骤1-5在SQL*Plus中操作 ALTER SESSION SET tracefile_identifier perf_test; ALTER SESSION SET events 10046 trace name context forever, level 12; -- 执行目标SQL SELECT /* my_test */ e.employee_id, e.last_name, d.department_name FROM employees e, departments d WHERE e.department_id d.department_id AND e.salary 5000; ALTER SESSION SET events 10046 trace name context off; -- 步骤6找到Trace文件 SELECT value FROM v$diag_info WHERE name Default Trace File;# 步骤7在操作系统命令行执行TKPROF cd /u01/app/oracle/diag/rdbms/orcl/orcl/trace/ # 按物理读排序输出 tkprof orcl_ora_12345_perf_test.trc report_disk.txt sysno sortdisk # 按获取阶段耗时排序并生成执行计划 tkprof orcl_ora_12345_perf_test.trc report_time.txt \ sysno sortfchela explainhr/hr waitsyes # 提取SQL语句到文件 tkprof orcl_ora_12345_perf_test.trc report_sql.txt \ sysno recordextracted_sql.sql七、Trace分析的高级技巧7.1 使用trcsess合并多个Trace文件当应用通过连接池访问数据库时一个业务操作可能涉及多个会话的Trace可以使用trcsess工具合并# 按Session ID合并 trcsess outputmerged.trc session123.456 *.trc # 按客户端ID合并需要在应用端设置DBMS_SESSION.SET_IDENTIFIER trcsess outputmerged.trc clientidmyapp *.trc # 对合并后的文件运行TKPROF tkprof merged.trc merged_report.txt sysno sortfchela7.2 分析绑定变量值当Trace级别包含Level 4或Level 12时可以在Trace文件中直接看到绑定变量值BINDS #18446744071539018256: Bind#0 oacdty02 mxl22(22) mxlc00 mal00 scl00 pre00 oacflg03 fl21000000 frm00 csi00 siz24 off0 kxsbbbfp7f8b3c0a5d00 bln22 avl02 flg05 value10或在TKPROF报告中使用bindsyes参数查看。7.3 与AWR数据关联验证将TKPROF报告中SQL的SQL_ID与AWR中的记录关联-- 从AWR中查询同一SQL_ID的历史执行统计 SELECT snap_id, executions_delta, elapsed_time_delta / 1000000 AS elapsed_sec, disk_reads_delta, buffer_gets_delta, rows_processed_delta FROM dba_hist_sqlstat WHERE sql_id 5tjqf7sxdz5g2 ORDER BY snap_id;八、使用场景与最佳实践8.1 典型使用场景| 场景 | Trace方案 | 分析重点 ||------|-----------|----------|| 单条SQL响应慢 | 当前会话Level 12 | 等待事件分布物理读比例 || 批量作业性能差 | 对其他会话启用Level 8 | Execute阶段耗时逻辑读总量 || 绑定变量窥探问题 | Level 12 | 查看绑定变量实际值对比不同值的计划 || 间歇性性能抖动 | DBMS_MONITOR长期监控 | 结合ASH数据对比异常时段 || 连接池环境 | trcsess合并多个Trace | 端到端的完整调用链路 |8.2 注意事项与风险性能影响Level 12的Trace会产生大量写入I/O对生产系统有不可忽视的性能影响。建议在业务低峰期使用或对单个会话短期开启。磁盘空间Trace文件增长极快需要确保Trace目录有足够空间并在分析完成后及时清理。优先使用DBMS_MONITOR在生产环境中推荐使用DBMS_MONITOR系列包其功能更丰富且易于管理。敏感信息Trace文件中可能包含业务数据绑定变量值需要注意安全保管。不要只依赖TKPROF估算计划explain参数生成的是估算计划与实际情况可能存在差异。务必结合Trace中实际的行源操作统计进行分析。九、总结与建议SQL Trace是Oracle最底层的SQL性能分析工具通过10046事件的四个级别控制跟踪粒度Level 12绑定变量等待事件是进行深度分析的最佳选择。TKPROF将原始Trace文件转化为结构化报告核心排序键包括fchela查询耗时、disk物理读、query逻辑读根据不同的分析目标选择合适的排序方式。报告解读的核心是对比CPU时间与Elapsed时间识别等待、关注物理读与逻辑读的比例评估缓存效率、分析行源操作每一步的资源消耗定位执行计划瓶颈。最佳实践先通过AWR定位高消耗SQL再用SQL Trace对该SQL进行微观剖析最后结合执行计划和统计信息制定优化方案。调优箴言TKPROF报告中的每个数字都有其物理含义不要满足于“看到了什么”而要追问“为什么是这个数字”。
