> 系列第 28 篇。上一篇讲了操作码——记录在说什么。这一篇讲地址——它改的那块数据，到底在磁盘的什么位置。
***
## 一句现场对话

"日志里不是给了 DBA 吗？拿着它去读那个块不就行了？"

问这话的人已经写过一版原型：从 redo record 里取出地址，拼了个路径，打开文件，**seek** 过去——读到的是乱码。

因为 **DBA 不是磁盘地址**。它是数据库内部的一套编号，从这串数字到"磁盘上的哪个字节"，中间还隔着几层换算；而在 ASM 上，完全是另一套。
***
## 01 DBA 是什么：两个数字拼起来的

DBA（Data Block Address）看起来是一个整数，其实是两个字段压在一起：

```text
DBA = (相对文件号 rfile# << N) | 块号 block#
```

拆开就是：

- **rfile#**：相对文件号，指的是"这个表空间里的第几个文件"，**不是全局文件号**；
- **block#**：这个文件里的第几个块。

这两个字段合起来，才能唯一确定一个块。**注意是"相对"**——同一个 rfile# 在不同表空间里指向不同文件，这是第一个容易踩的坑。
> **［插图 1：chart1_layers.png］**
>
> 把光标放这一行 → 删掉提示 → 点「插入 → 图片」上传同目录下的 chart1_layers.png
***
## 02 三层换算，一层都不能少

从 DBA 到"磁盘偏移"，要过三道：

**第一道：rfile# → 绝对文件号。**
查 **DBA_DATA_FILES** 或 **V$DATAFILE**，匹配 **RELATIVE_FNO**，取出真正的 **FILE#**。相对号只在一个表空间内有效，跨表空间就撞号。

**第二道：文件号 → 文件名。**
还是同一张视图，取 **FILE_NAME**。这一步在文件系统上给你一个路径，在 ASM 上给你一个 **+DG/.../datafile/xxx** 的别名，在裸设备上给你一个 **/dev/raw/rawN**。

**第三道：块号 → 字节偏移。**
偏移 = **block# × block_size**。注意块大小不是固定的：常见 8KB，也有 16KB、32KB、32KB 以上少见但在。**你要读的文件块大小，跟 **DB_BLOCK_SIZE** 可能不是一回事**（不同表空间可以有不同的块大小）。搞错这一步，读出来的位置全偏。

顺带一个常识：**block 0 是文件头**，不是数据。**block 1 通常是段头**（ASSM 表空间下，段头之后还跟着 L1/L2 位图块）。你要找的"某张表的某一行"，往往还要再往深处走几层。
***
## 03 在 ASM 上，这套算法直接失效

这是最容易被低估的一段。文件系统上，"文件是一段连续的字节"这个假设成立；ASM 上不成立。

ASM 里的"文件"不是路径，是**一个编号 + 一张映射表（extent map）**：

- 文件被切成 **AU**（allocation unit，分配单元，默认 1MB）；
- 每个 AU 落在**哪块盘的哪个位置**，由 extent map 记录；
- 同一个文件的 AU 可能**分散在不同磁盘**上（条带化）；
- 开了**冗余**（normal 两份、high 三份）之后，同一份数据有多个副本，读哪个要按 failure group 判断。

所以"打开文件、seek 到偏移"这个动作，在 ASM 上没有对应物。你要做的是：

1. 拿到 (磁盘组, 文件号)；
2. 读这个文件的 extent map；
3. 把"文件内的逻辑块号"翻译成 "extent 序号 + AU 内偏移"；
4. 再按 AU 找到具体哪块盘、哪个偏移。

**四步，每一步都可能出错，而且错了不报错——你只是读到了别的数据。**
> **［插图 2：chart2_asm.png］**
>
> 把光标放这一行 → 删掉提示 → 点「插入 → 图片」上传同目录下的 chart2_asm.png
***
## 04 传统路线：这一层你根本碰不到

说回对比。

用 LogMiner，你压根不需要知道 DBA 是什么。它给你的 **SQL_REDO** 里只有 **WHERE id=1**，没有块号、没有文件号、没有偏移。**地址这一层被完整封装在数据库内部。**

这是好事——省了整整一层工程量。但它也带来一个副作用：

**当解析结果不对时，你没有任何办法定位到"是哪一块读错了"。**

拿到一条错误的变更，你只能怀疑：字典错了？事务边界错了？类型解错了？还是读的位置就不对？**这四种可能，在 LogMiner 的输出里长得一模一样。**

反过来，如果是自己读字节：先看 DBA 换算对不对，再看块头校验过没过，再看 record 边界对不对。**问题能一层层剥开。**

这也是为什么很多团队在 LogMiner 上排查一个数据不一致的问题，要花几周——不是问题难，是没有抓手。
***
## 05 裸日志怎么做：把定位做成可验证的

自己定位，关键不是"能不能算对"，是"算错了能不能发现"。四个动作：

1. **每一步换算都留痕。** (rfile#, block#) → (file#, name) → 偏移，三步的中间结果都记下来。出问题直接看是哪一步断的。
2. **进块先验块头。** 每个数据块/日志块都有签名和校验。校验不过就停——**不要"跳过继续"**，那等于默认后面还是对的。
3. **块大小从文件头读，不写死。** 不同表空间块大小可以不同，写死 8KB 是新手最常犯的错。
4. **ASM 走 extent map，不假装它是文件。** 不要求把 ASM 挂成文件系统，也不依赖 ASM 实例配合——直接读磁盘上的 AU。

**这四件事做完，"读错位置"这个可能性就被排除了。** 剩下的错误才有可能被归到字典、事务、类型上去。
> **［插图 3：chart3_compare.png］**
>
> 把光标放这一行 → 删掉提示 → 点「插入 → 图片」上传同目录下的 chart3_compare.png
***
## 06 TLA 是怎么处理的

河北英数的 **TLA**（Transaction Log Analysis，事务日志解析组件）在地址这一层做了一个明确的取舍：**不依赖 Oracle 的文件访问接口，自己完成从 DBA 到物理位置的换算。**

具体是三点：

- **文件系统、裸设备、ASM 三种形态走同一套定位逻辑。** 差异只在"最后一步怎么取到 AU"，前面的换算链路完全一致。这意味着客户不用为了采数据去改存储形态——ASM 就 ASM，不会要求"你先挂成文件系统"。
- **ASM 直接解析 extent map。** 不经过 ASM 实例，也不需要 **asmcmd** 之类的工具配合。多个副本时按可读性选，不挑"主副本"。
- **每一步都能回放。** 定位过程中的中间结果可导出，出问题时能精确说出"这个块是从哪块盘的哪个偏移读出来的"。

这话说得直白一点：**地址这一层做扎实了，才谈得上"读得对"。** 读得再快，位置错一位，整条链路的数据都是假的。
***
## 07 说句实在话

我们在这上面栽过一次，很典型。

客户环境是 ASM，我们的第一版原型在测试环境（文件系统）跑得很好。上客户环境之后，解析出来的数据**大部分对、偶尔错几行**。查了两周，最后发现是块大小——客户有个表空间用了 16KB 块，我们按 8KB 算了偏移，读到的位置偏移了一倍。

**错得不多，所以特别难查。** 如果全错，第一天就发现了。

从那以后我们加了一条硬规则：**块大小不写默认值，读不到就报错停下。** 宁可起不来，也不要带着一个默认值跑起来。

> 要说清楚：DBA 的位域划分（相对文件号与块号各占多少位）在不同版本、不同表空间类型下有差异；ASM 的 AU 大小、条带粒度、冗余份数也随配置变化。本文给的是通用机制，具体参数请以目标环境实测为准。
***
**往期回顾**

- （二十四）拿今天的字典去翻昨天的日志，能不错位吗？
- （二十五）采个数据，凭什么占我数据库的会话？
- （二十六）只想采个 Oracle 日志，却要先搭一套分布式集群？
- （二十七）redo 里的操作码，150 多种你其实只用得上 10 个
- （二十八）日志里那个 DBA，到底指向磁盘上的哪个字节？ ← 本篇
***
**声明**：DBA 的组成、**DBA_DATA_FILES** / **V$DATAFILE** 中 **RELATIVE_FNO** 与 **FILE#** 的关系、块头与段头的位置，可参考 Oracle 官方文档《Database Concepts》与《Database Reference》。ASM 的 AU、extent map、条带化与冗余机制参考《Automatic Storage Management Administrator's Guide》。不同版本与配置存在差异，具体参数请以实测为准。


系列第 28 篇。上一篇讲了操作码——记录在说什么。这一篇讲地址——它改的那块数据，到底在磁盘的什么位置。

它改的那块数据，到底在磁盘的什么位置。

数据库

DBA由相对文件号与块号拼接而成，需经三层换算才能定位磁盘偏移，ASM环境则依赖extentmap映射，块大小错误易致解析偏移，裸日志解析应留痕每步换算并验证块头。

文件系统

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

它改的那块数据，到底在磁盘的什么位置。-腾讯云开发者社区-腾讯云

它改的那块数据，到底在磁盘的什么位置。

它改的那块数据，到底在磁盘的什么位置。

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐