重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛

标题: 使用 dd 测试数据库底层的存储 [打印本页]

作者: mahan 时间: 2026-6-28 18:57
标题: 使用 dd 测试数据库底层的存储
在使用 dd 测试数据库底层的存储时，最核心的原则只有一个：必须绕过操作系统的缓存（Page Cache）。否则，您测出来的将是服务器内存的速度（动辄几GB/s），对排查由于物理磁盘慢导致的卡顿毫无意义。

请按照以下三个场景依次在主库的 Linux 命令行中执行（测试前请先通过 df -h /u01 确保该目录下至少有 15GB 的可用空间）：

场景 1：测试大块顺序写入带宽（模拟数据文件扩展、大批量刷脏块）
这个测试用来探测存储链路的最大物理写入带宽。我们绕过系统缓存，直接向物理磁盘写入一个 10GB 的文件。

Bash
# 写入一个 10GB 的文件，块大小 1MB
dd if=/dev/zero of=/u01/test_write_large.dbf bs=1M count=10240 oflag=direct
参数解析：oflag=direct 是灵魂参数，它强制 I/O 绕过内存缓存直接落盘。

指标解读：命令执行完毕后，会输出一个平均速度（例如 ... MB/s 或 ... GB/s）。对于连接企业级 SAN 存储的数据库服务器，如果这个数值低于 200 MB/s，说明存储层面的基础带宽或多路径链路存在严重拥堵。

场景 2：测试大块顺序读取带宽（模拟大表全表扫描、RMAN 备份）
基于刚才写入的文件，测试存储的物理读取速度。同样必须绕过缓存。

Bash
# 读取刚才的 10GB 文件，块大小 1MB
dd if=/u01/test_write_large.dbf of=/dev/null bs=1M iflag=direct
参数解析：iflag=direct 强制直接从磁盘物理读取，不走内存。

指标解读：通常读取速度会远高于写入速度。如果这个值异常低，解释了为什么 AWR 报告中 db file scattered read 等多块读等待事件耗时很久。

场景 3：测试小数据块高频写入（极其重要！模拟 Oracle Redo 日志提交）
Oracle 的 Redo 日志写入通常是小块（例如 8K 或更小）的连续追加写入。这个测试能最真实地反映出之前 AWR 报告中 log file parallel write （前台 Commit 慢）的底层病因。

Bash
# 写入一个 1GB 的文件，块大小 8K
dd if=/dev/zero of=/u01/test_write_small.dbf bs=8k count=131072 oflag=direct
现象预期：由于每次只写 8K 且强制落盘，这个测试会比场景 1 慢得多。

指标解读：如果这个测试输出的速度只有几 MB/s 甚至几十 KB/s，那就彻底坐实了问题：这块存储处理高频小块 I/O 的能力（IOPS 响应）已经彻底崩溃，直接导致了数据库 Commit 被挂起。

测试完成后的清理工作
测试完毕后，千万别忘了把生成的测试垃圾文件删掉，释放空间：

Bash
rm -f /u01/test_write_large.dbf
rm -f /u01/test_write_small.dbf

进阶提示：
dd 的局限性
dd 是一个单线程的测试工具。它能告诉你存储的“下限”（如果 dd 跑出来都很慢，那存储绝对有问题）。

但如果 dd 跑出来的速度还不错，系统却依然卡顿，那是因为 Oracle 是极高并发的多线程读写。当成百上千个会话同时发起 I/O 时，存储的控制器可能会瞬间瘫痪。如果用 dd 测不出问题，下一步就必须使用 fio 工具进行多线程并发压测了。

欢迎光临重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛 (http://bbs.cqsztech.com/)