## 一个事务在redo log里长什么样？图解Oracle日志格式

做数据库的人都知道redo log重要，但真要说清楚里面到底存了什么——大部分人也就能说出“记录数据变更”这六个字。

再往下问：怎么记的？一个UPDATE语句在redo里长什么样？事务开始和提交在日志里怎么体现？

能答上来的人就不多了。

这篇文章用一张图、一个完整事务的例子，把redo log的格式从头到尾拆一遍。

**先说结论：一个事务在redo log里，就是一堆Change Vector（改变向量）的集合，用相同的事务ID串在一起，用操作码标记开始和结束。**

下面来看具体怎么存的。


### 一、物理层面：redo log就是一串512字节的块

redo log文件在磁盘上长什么样？就是一串连续的二进制块。

每个块的大小通常是**512字节**——Windows、Linux、Solaris上都是这个值，HP-UX上是1024字节。这个值跟Oracle的数据块大小（通常是8KB）不是一回事，redo的块大小是在Oracle源代码里写死的。

整个文件的构成很简单：**文件头 + N个数据块**。

**文件头（File Header）** 占用第一个块。里面存了：

- 前2个字节：文件类型。`0x22`是redo log文件，`0xA2`是数据文件，`0xC2`是控制文件
- 偏移量20处、2个字节：块大小
- 偏移量24处、4个字节：块数量

从第二个块开始才是真正的redo数据。

每个数据块开头都有一个**16字节的块头（Block Header）** ，以签名`0x0122`开头。块头里存了三个关键信息：

- 块在文件中的编号
- 日志序号
- 该块内第一条记录起始位置的偏移量

**这三个值合起来就是RBA（Redo Byte Address）** ——每条redo记录在文件里的“门牌号”：哪个日志文件、哪个块、块内哪个位置开始。


### 二、逻辑层面：Redo Record → Change Vector

跳过文件头，从第二个块开始，里面存的就是真正的redo数据了。

redo log file由一系列的**redo record**（也叫redo entry）组成。每个redo record由两部分构成：

- **记录头（Redo Record Header）** ：存元信息——线程号、RBA、SCN等
- **一个或多个Change Vector**：真正的变更数据

SCN（System Change Number）是Oracle的全局时钟，决定了变更的顺序。

重点来了——**Change Vector**。

**Change Vector是redo log里最小粒度的变更单元，它描述了对单个数据块的一次变更**。

一个Change Vector**只针对一个数据块，只包含一个变化**。这个数据块可以是普通数据块、回滚块、数据段头块、回滚段头块等等。

每个Change Vector由**头（Header）和体（Body）** 两部分组成。

**头里包含的关键字段**：

| 字段 | 含义 |
|---|---|
| change # | 同一个redo record中change vector的编号 |
| TYP | 变更类型 |
| CLS | block类别（跟x$bh.class一致） |
| AFN | 绝对文件号 |
| DBA | 数据块地址 |
| SCN | 修改时的系统变更号 |
| SEQ | 同一个SCN下的不同修改序号 |
| **OP** | **操作码，最重要** |

**操作码（OP Code）** 告诉你这个Change Vector描述的是什么类型的操作。

常用的OP Code：

| OP Code | 含义 |
|---|---|
| 5.1 | 撤销修改（Undo Record） |
| **5.2** | **事务开始** |
| **5.4** | **事务提交（Commit）** |
| 10.2 | 插入索引 |
| 10.4 | 删除索引 |
| **11.2** | **插入一行数据** |
| **11.3** | **删除一行数据** |
| **11.5** | **更新一行数据** |
| 11.11 | 插入多行数据 |
| 13.1 | 申请空间（CREATE TABLE） |
| 24.1 | DDL操作 |

**体（Body）** 里存的是具体变更数据——修改前的值（前镜像）、修改后的值（后镜像），以及数据块的版本号等信息。


### 三、一个完整事务长什么样？

用一个`UPDATE`语句把上面的概念串起来。

假设执行：

```sql
UPDATE employees SET salary = 8000 WHERE employee_id = 1001;
```

这条语句在redo log里会产生**多个Change Vector**，而**不是一条**。

**第一步：事务开始。**

在PGA里生成一个Change Vector，OP Code是**5.2**，标记事务开始。

同时在undo segment header的事务表中分配一个ITL事务槽。事务ID（XID）由三部分组成：回滚段号、槽号、序列号。

**第二步：修改数据块。**

生成一个Change Vector，OP Code是**11.5**（更新一行数据）。Body里记录了：
- 修改哪个数据块（DBA）
- 修改前的值（salary=5000）
- 修改后的值（salary=8000）

**第三步：修改回滚块（UNDO）。**

生成一个Change Vector，OP Code是**5.1**（撤销修改）。Body里记录了修改前的完整数据——万一事务回滚，需要靠这个把数据恢复回去。

**第四步：如果有索引，还要改索引。**

如果employee_id上有索引，还需要生成索引相关的Change Vector（OP 10.2或10.4）。

**第五步：事务提交。**

生成一个Change Vector，OP Code是**5.4**，标记事务结束。同时记录提交时的SCN。

所以一个简单的UPDATE，redo里实际产生了**至少4-5个Change Vector**：1个事务开始 + 1个数据块修改 + 1个回滚块修改 + N个索引修改 + 1个事务提交。

把它们用同一套图表示出来就是这样的：

```
┌─────────────────────────────────────────────────────────────────┐
│                     一个 UPDATE 事务在 redo log 里              │
├─────────────────────────────────────────────────────────────────┤
│  ┌──────────────────────────────────────────────────────────┐  │
│  │              Redo Record (数据块修改)                    │  │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐    │  │
│  │  │Change Vector│  │Change Vector│  │Change Vector│    │  │
│  │  │  OP: 5.2    │  │  OP: 11.5   │  │  OP: 5.1    │    │  │
│  │  │  事务开始    │  │  更新一行    │  │  撤销修改    │    │  │
│  │  │  XID: 0x... │  │  前后镜像    │  │  (UNDO)     │    │  │
│  │  └─────────────┘  └─────────────┘  └─────────────┘    │  │
│  └──────────────────────────────────────────────────────────┘  │
│                              │                                 │
│                              ▼                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │              Redo Record (索引修改)                      │  │
│  │  ┌─────────────┐  ┌─────────────┐                      │  │
│  │  │Change Vector│  │Change Vector│                      │  │
│  │  │  OP: 10.2   │  │  OP: 5.4    │                      │  │
│  │  │  插入索引    │  │  事务提交    │                      │  │
│  │  │             │  │  SCN: xxx   │                      │  │
│  │  └─────────────┘  └─────────────┘                      │  │
│  └──────────────────────────────────────────────────────────┘  │
├─────────────────────────────────────────────────────────────────┤
│  同一个 XID = 同一个事务   5.2开始 → ... → 5.4提交            │
└─────────────────────────────────────────────────────────────────┘
```


### 四、怎么把这些散落的Change Vector拼回完整事务？

现在问题来了：一个事务的Change Vector可能分散在不同的redo record里，甚至跨多个日志文件。怎么把它们拼回去？

**第一步：按XID分组。**

每个Change Vector里都带了事务ID（XID）。TLA解析的时候，读到Change Vector先提取XID，按XID把散落的Change Vector归类。

**第二步：识别事务边界。**

- 读到OP 5.2 → 事务开始
- 读到OP 5.4 → 事务提交
- 读到OP 5.1 → 有撤销操作

**第三步：按SCN和RBA排序。**

同一个事务内的Change Vector可能分散在不同位置，但通过SCN和RBA可以还原出时间顺序。

**第四步：还原数据变更。**

每个Change Vector的Body里存了前镜像和后镜像。按顺序应用，就能得到完整的数据变更记录。

**第五步：判断是否输出。**

如果一个事务最终回滚了，TLA在重建的时候会检查——**以回滚结束的事务，所有Change Vector都不输出**。

这就是为什么TLA能做到“只输出已提交事务”——它是在二进制层面完整还原了事务的生命周期。


### 五、说回TLA

讲完格式，再说说TLA跟这些东西的关系。

TLA做的事，就是**直接去读这些二进制块，按上面的规则一层层解析**。

不调用LogMiner，不调用XStream，就是自己读文件、自己解格式、自己拼事务。

格式清楚了，很多事情就好办了。

比如LogMiner有30字符表名限制——因为LogMiner在解析Change Vector之后多了一层“翻译成SQL”的逻辑，这层逻辑有命名长度限制。TLA直接读二进制，根本不走那层，自然没这个限制。

比如LogMiner不支持BLOB/CLOB——因为这些类型在Change Vector的Body里存的方式比较特殊，LogMiner的“翻译层”处理不了。TLA直接解析Body里的二进制数据，自己控制解析逻辑，能处理。

说到底，redo log就是个二进制文件。格式搞清楚了，剩下的就是工程问题。


### 六、总结

一张图总结一个事务在redo log里的样子：

> **一个事务 = 多个Change Vector + 相同XID + 5.2开头 + 5.4结尾**

- redo log是512字节的二进制块，有文件头和数据块
- 数据块里是redo record，每个record包含一个或多个Change Vector
- Change Vector是**最小粒度**的变更单元，描述**单个数据块**的一次变更
- 操作码（OP Code）标识变更类型——5.2开始、5.4提交、11.5更新
- 一个UPDATE会生成多个Change Vector：事务开始、数据修改、UNDO、索引、事务提交
- 拼回完整事务靠XID分组 + 边界识别 + SCN/RBA排序

redo log里存的不是SQL，是物理级别的块变更信息。LogMiner所谓的“还原SQL”，其实是根据Change Vector反向构造出来的——这也是它各种限制的根源。

TLA做的事情更直接：不构造SQL，直接从二进制还原变更数据。格式吃透了，限制就少了。

---

*补充：不同Oracle版本的redo格式有细微差异，实际解析时需要根据版本做适配。本文基于主流版本（10g/11g/12c）的通用格式描述。*

做数据库的人都知道redo log重要，但真要说清楚里面到底存了什么——大部分人也就能说出“记录数据变更”这六个字。

一个事务在redo log里长什么样？图解Oracle日志格式

数据库

操作系统

开发工具

Oracle事务在redolog中以ChangeVector集合形式存储，包含事务开始(5.2)、数据修改(11.5)、UNDO记录(5.1)和事务提交(5.4)等操作码。每个512字节块存储变更向量，通过XID、SCN和RBA还原事务完整生命周期，实现数据变更的物理级记录。

日志文件

数据恢复

代码解释

Windows

Solaris

Linux

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一个事务在redo log里长什么样？图解Oracle日志格式-腾讯云开发者社区-腾讯云

一个事务在redo log里长什么样？图解Oracle日志格式

一个事务在redo log里长什么样？图解Oracle日志格式

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐