Oracle数据库常用的DUMP和TRACE操作

Oracle数据库DUMP与TRACE深度解析

原创于 2025-09-13 10:03:09 发布 · 890 阅读

25 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #oracle

AI辅助_面试宝典专栏收录该内容

584 篇文章

订阅专栏

在这里插入图片描述

好的，我们来深入探讨 Oracle 数据库诊断工具包中两个非常强大且底层的工具：DUMP 和 TRACE。这两个工具是 Oracle DBA 和性能优化专家进行深度问题诊断的“手术刀”。

核心概念区分

首先，明确两个术语的区别：

DUMP (转储)：
- 官方/专业解释：将数据库内部特定结构（如数据块、文件头、控制文件、日志文件等）的二进制内容以人类可读的格式（十六进制+ASCII翻译）输出到一个跟踪文件中。它展示的是某一时刻的静态快照。
- 通俗解释：就像对数据库的某个部分（如一个数据块）做一次 “CT扫描” 或 “解剖” 。你把它的所有字节都打印出来，以便查看其内部最原始的结构和内容。这主要用于数据一致性检查、 corruption（损坏）分析、内部原理学习。
TRACE (跟踪)：
- 官方/专业解释：让 Oracle 服务器进程在执行操作期间，将其所执行的每一步骤、所使用的资源（逻辑读、物理读、CPU时间等）、等待的事件等信息实时地记录到跟踪文件中。它展示的是一个操作的动态执行过程。
- 通俗解释：就像给数据库进程戴上一個 “执法记录仪” 或 “黑匣子” 。它完整记录了这个进程“做了什么”、“怎么做的”、“花了多久”、“在等什么”。这主要用于性能问题诊断、SQL调优、死锁分析。

1. DUMP 操作详解

适用场景与作用

场景1：数据块损坏 (Corruption)：当 ORA-01578 错误出现时，使用 DUMP 来查看损坏块的具体内容，判断损坏范围和程度。
场景2：逻辑逻辑验证：怀疑某些数据在块中的存储不正确（例如，行记录格式、ITL槽信息等），通过 DUMP 进行验证。
场景3：学习内部原理：直观地理解 Oracle 数据块、段头、控制文件等内部结构的组成，正如我们之前讨论的 ASSM 位图块和段头块。

常用 DUMP 命令与示例

A. 转储数据块 (Data Block)
这是最常用的 DUMP 操作。

-- 1. 首先，找到要转储的对象的详细位置（文件号和块号）。
-- 例如，要找到某一行记录在哪个块中：
SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) AS FILE_ID,
       DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) AS BLOCK_ID,
       ROWID
FROM your_table_name
WHERE your_primary_key = 'some_value';

-- 假设查询结果：FILE_ID = 5, BLOCK_ID = 134

-- 2. 执行转储命令
ALTER SYSTEM DUMP DATAFILE 5 BLOCK 134;
-- 或者转储一个范围内的块：
ALTER SYSTEM DUMP DATAFILE 5 BLOCK MIN 134 BLOCK MAX 134;

B. 转储段头 (Segment Header)
段头块包含了区的映射图（Extent Map），转储它可以查看段的全部区分配信息。

-- 首先找到段的头块位置（FILE_ID和BLOCK_ID）
SELECT header_file, header_block
FROM dba_segments
WHERE segment_name = 'YOUR_TABLE_NAME' AND owner = 'YOUR_SCHEMA';

-- 假设查询结果：header_file = 5, header_block = 130

-- 转储段头块
ALTER SYSTEM DUMP DATAFILE 5 BLOCK 130;

C. 转储数据文件头 (Datafile Header)
每个数据文件的第一个块（Block 1）是文件头，包含了文件的状态、SCN、检查点信息等。

ALTER SYSTEM DUMP DATAFILE '/u01/oradata/mydb/users01.dbf' BLOCK MIN 1 BLOCK MAX 1;

D. 转储控制文件 (Control File)
控制文件是数据库的“大脑”，包含了数据库的物理结构信息。

ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME CONTROLF LEVEL 10';

DUMP 文件解读

DUMP 命令输出的文件位于数据库服务器的 diag/rdbms/<db_name>/<instance_name>/trace 目录下，文件名通常包含 _ora_<spid>.trc。

文件内容看起来非常晦涩，但有其固定结构。以一个数据块 DUMP 为例，你通常会看到：

Buffer tsn: 表空间号。
rdba: 数据块地址。
scn: 系统变更号，块最后一次更改的SCN。
seq: 序列号，用于并发控制。
Itl: 事务槽列表，记录在此块上活动的事务信息。
行数据区域: 以 tab 0, row 0 开头，显示行记录的实际内容（十六进制和ASCII形式）。

2. TRACE 操作详解

适用场景与作用

场景1：SQL性能调优：找出SQL语句执行慢的根本原因（是全表扫描还是索引问题？是排序开销大还是多表连接效率低？）。
场景2：等待事件分析：发现数据库“慢”的时候，进程大部分时间在“等待”什么资源（如等I/O、等锁、等latch）？
场景3：错误诊断：追踪特定错误（如死锁 ORA-00060）发生的详细上下文和过程。
场景4：10046事件：这是最强大的跟踪工具，可以提供远超普通SQL跟踪的详细信息。

常用 TRACE 命令与示例

A. 对当前会话开启标准SQL跟踪
这是最常用的入门级跟踪。

-- 1. 在当前会话中开启跟踪
ALTER SESSION SET SQL_TRACE = TRUE;
-- 或者使用更现代的命令：
EXEC DBMS_SESSION.SESSION_TRACE_ENABLE;

-- 2. 在应用程序中执行你想要分析的SQL操作...

-- 3. 关闭跟踪
ALTER SESSION SET SQL_TRACE = FALSE;
-- 或
EXEC DBMS_SESSION.SESSION_TRACE_DISABLE;

B. 跟踪其他指定会话 (SID, SERIAL#)
如果需要跟踪一个已存在的会话（例如，一个前端的应用连接）。

-- 1. 找到要跟踪的会话的SID和SERIAL#
SELECT sid, serial#, username, program
FROM v$session
WHERE ...;

-- 假设 SID=123, SERIAL#=45678

-- 2. 使用DBMS_MONITOR包对其进行跟踪
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => 123, serial_num => 45678, waits => TRUE, binds => TRUE);

-- 3. 等待问题复现后，关闭跟踪
EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(session_id => 123, serial_num => 45678);

C. 使用强大的 10046 事件
10046事件提供了不同级别的跟踪深度：

Level 1：标准跟踪，等同于 SQL_TRACE=TRUE。
Level 4： Level 1 + 绑定变量 (Bind Variables) 的值。
Level 8： Level 1 + 等待事件 (Wait Events) 信息。
Level 12： Level 4 + Level 8 (绑定变量+等待事件)。这是最常用的全面诊断级别。

-- 对当前会话开启Level 12 (12 = 4 + 8) 跟踪
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';

-- 执行要分析的操作...

-- 关闭跟踪
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';

TRACE 文件分析

生成的跟踪文件同样在服务器的trace目录下。原始跟踪文件很难阅读，通常使用 TKPROF 工具将其转换为格式化的、易于理解的报告。

# 在操作系统命令行下使用TKPROF
tkprof /u01/app/oracle/diag/rdbms/mydb/MYDB/trace/MYDB_ora_12345.trc output=/tmp/trace_report.txt sys=no sort=prsela, exeela, fchela

# 参数解释：
#   input_trace_file: 原始的跟踪文件
#   output: 生成的格式化报告文件
#   sys=no: 过滤掉由SYS用户执行的递归SQL（使报告更清晰）
#   sort=...: 按某些列排序（例如按CPU时间、 elapsed时间等）