在上一篇文章中，我们介绍了
SQL_TRACE + TKPROF 这对性能诊断黄金组合，很多读者反馈“干货满满，实战好用”。

但当你遇到更棘手的问题时——

• SQL执行慢，但看不出具体在等什么（等待事件）
• 绑定变量值不对，导致执行计划走歪
• 需要最完整的执行统计和真实耗时分布……

这时，
10046诊断事件 就该登场了！

它是 Oracle 官方未公开的扩展诊断工具，被无数 DBA 称为“性能排查的核武器”。今天我们从原理到实战，手把手教你用好它，读完你就能在生产环境精准定位“隐形杀手”。

点赞 + 关注 + 转发，下期继续分享进阶组合拳，一起成为 Oracle 性能优化高手！

10046 是 Oracle 的扩展诊断事件（Diagnostic Event），专门用于产生更丰富的 SQL 跟踪信息。

它本质上是
SQL_TRACE 的增强版，主要优势在于：

• Level 4：额外捕获绑定变量（bind variables）真实值
• Level 8：额外捕获详细等待事件（wait events）
• Level 12：最常用组合 = SQL语句 + 执行统计 + 绑定变量 + 等待事件 + 详细执行计划

一句话总结区别：

• SQL_TRACE（不加wait）→ 只看基本执行统计，缺少等待和绑定
• 10046 Level 12 → 几乎把 SQL 执行的“每一毫秒”都记录下来，是深度性能诊断的首选

注意：虽然强大，但它是未公开事件，生产环境请谨慎使用，跟踪完及时关闭，避免产生过多 trace 文件占用空间。

• Level 0：关闭跟踪（相当于 SQL_TRACE=FALSE）
• Level 1：基础跟踪，等同于普通 SQL_TRACE
• Level 4：Level 1 + 绑定变量信息（关键！能看到实际传入的参数值）
• Level 8：Level 1 + 等待事件信息（能看到 SQL 在哪里卡住了）
• Level 12：Level 1 + 4 + 8（推荐！大多数性能诊断都用这个级别）

2. 查看当前 SID 和 Trace 文件位置：

SQL

SELECT DISTINCT SID FROM V$MYSTAT;
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';

2. 开启 10046 Level 12：

SQL

ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';

（forever 表示在整个会话期间持续有效）

2. 执行你的业务 SQL……
4. 关闭跟踪：

SQL

ALTER SESSION SET EVENTS '10046 trace name context off';

方法一：使用 DBMS_SYSTEM.SET_EV（推荐，权限控制好）

SQL

-- 先查目标会话
SELECT SID, SERIAL#, USERNAME, PROGRAM 
FROM V$SESSION 
WHERE USERNAME IS NOT NULL;
-- 开启
EXEC DBMS_SYSTEM.SET_EV(1, 7, 10046, 12, '');   -- SID, SERIAL#, 10046, Level 12
-- 执行测试SQL...
-- 关闭
EXEC DBMS_SYSTEM.SET_EV(1, 7, 10046, 0, '');

方法二：oradebug（适合跟踪第三方会话或当前会话，功能最强）

跟踪第三方会话（需要知道 SPID）：

SQL

-- 查 SPID
SELECT SPID FROM V$PROCESS WHERE ADDR = (SELECT PADDR FROM V$SESSION WHERE SID = 32);
-- 设置
ORADEBUG SETOSPID 2045
ORADEBUG EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12
-- 执行SQL...
-- 关闭
ORADEBUG EVENT 10046 TRACE NAME CONTEXT OFF
-- 查看 trace 文件
ORADEBUG TRACEFILE_NAME

跟踪当前会话（超级方便）：

SQL

ORADEBUG SETMYPID
ORADEBUG EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12
-- 执行SQL...
ORADEBUG EVENT 10046 TRACE NAME CONTEXT OFF
ORADEBUG TRACEFILE_NAME

小贴士：oradebug 功能强大，但属于底层调试工具，使用时建议以 SYS 用户操作。

Trace 文件生成后，用 TKPROF 格式化（推荐参数）：

Bash

tkprof your_tracefile.trc report.txt sys=no sort=exeela

• sys=no：过滤 SYS 用户的递归 SQL，报告更干净
• sort=exeela：按总耗时（elapsed time）排序，最慢的 SQL 排最前面

报告核心字段解读（重点复习）：

• elapsed：总响应时间（包含等待，最重要）
• cpu：纯 CPU 时间
• disk：物理 IO（硬盘读，最该优化的）
• query：一致性逻辑读（SELECT 多时常见）
• current：当前模式读（DML 操作常见）

优化口诀：先看 elapsed 和 disk，高了就重点优化；再看 waits，找出具体在等什么（db file sequential read、latch 等）。

• 开发说“绑定变量传值不对” → 用 Level 4 或 12，看 raw trace 中的 BIND 部分
• SQL 忽快忽慢 → 用 Level 8 或 12，看 WAIT 部分
• 需要最完整信息 → 直接 Level 12
• 多个会话同时跟踪 → 可以结合 DBMS_MONITOR（更现代的方式）

生产注意事项：

2. 跟踪时间不要太长，避免 trace 文件爆炸
4. 及时关闭事件
6. 大文件可使用 trcsess 合并多个 trace 文件后再 TKPROF
8. 12c+ 版本优先考虑 DBMS_MONITOR.SESSION_TRACE_ENABLE（功能类似，更友好）

掌握了
10046 Level 12 + TKPROF，你就已经拥有了比普通 DBA 强一个档次的诊断能力。下次再遇到“SQL慢但不知道为什么慢”，直接 Trace 起来，5-10 分钟出报告，领导和同事都会对你刮目相看！

评论区互动： 你目前最常遇到的性能问题是什么？是等待事件多？还是绑定变量导致的计划问题？或者执行计划不稳定？ 我在后台一一回复，欢迎交流～

—— 睿 | Oracle性能优化老司机 专注硬核干货，欢迎关注，一起卷技术，少背锅！