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

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

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

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

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

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

---

一、10046事件是什么？为什么比SQL_TRACE更强大？

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 文件占用空间。

---

二、10046事件的四个常用级别（背下来就够用）

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

---

三、实战1：跟踪当前会话（最简单）

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

SQL

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

1. 开启 10046 Level 12：

SQL

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

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

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

SQL

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

---

四、实战2：跟踪指定会话（生产最常用）

方法一：使用 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 用户操作。

---

五、TKPROF：把“天书”变成清晰报告（与SQL_TRACE通用）

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（更现代的方式）

生产注意事项：

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

---

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

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

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