数据库管理309期 2025-04-04
数据库管理-第309期 苦逼的坏块修复（20250404）
作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE Partner 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 公众号：胖头鱼的鱼缸 CSDN：胖头鱼的鱼缸（尹海文） 墨天轮：胖头鱼的鱼缸 ITPUB：yhw1809。 除授权转载并标明出处外，均为“非法”抄袭
本周因为EMC存储中同时坏了两块盘（当然还有一些列热备和TRACK的问题），因此连续3天凌晨配合存储进行割接，在这期间看到了RAC集群的IO等待较高，EMC修复部分问题后IO等待又下去了，以为问题已经解决，但是在今天经业务侧反馈数据库有坏块报错（其实EMC操作前就有预警），正好今天又有全备，通过全备日志发现有27个数据文件报有坏块。
1 坏块
坏块，block/page corrupt，其实字面意思就是一个块出现了异常，里面数据无法使用了，需要进行修复。在使用这些块时会有以下报错：
ORA-01578: Oracle data block corrupted (file #num, block #num)
这时候会明确告诉你哪个数据文件的哪个块损坏了，这个块就需要进行修复。
2 检查数据文件
一般来说在这种情况下我会去检查这个数据文件是否还有其他坏块，可以通过dbv命令进行检查：
dbv file=/path/to/file
这里可以看到具体的坏块编号和总的坏块数量。除了使用dbv以外，在备份过程中也会对数据文件进行检查，通过备份日志也能查看到对应有坏块的数据文件。
当然也能在RMAN中使用下面命令手动对数据库所有数据文件进行检查：
rman target / RMAN> validate database;
检查完成后也会有上面类似的输出结果。
3 修复坏块
坏块的修复需要几个条件：
- 有效可用的备份
- ADG
当使用到坏块时会自动触发坏块修复，在有ADG的情况下会通过备库自动完成修复：
在有有效可用备份的情况下也能恢复，但是在使用NBU等三方备份设备时，可能会因为备份存储目标位置不同导致恢复失败，这种情况下则需要通过手工指定备份路径的方式进行恢复，这里不做展示了，类似命令可以通过《数据库管理-第189期 在19c上truncate了表咋办（20240513）》查看。
而在有ADG灾备库的环境中就比较方便了：
rman target / RMAN> blockrecover datafile #num block #num;
这里也可以看到是从备库进行的恢复。
4 复盘
在本次故障中，因为一些数据文件教老，不易触发自动修复，且为了避免后期使用到时对业务系统产生影响（毕竟有报错会产生），通过备份日志对所有发现坏块的数据文件进行了手动坏块修复。在修复过程中发现了一些有趣的现象：
- 每个数据文件坏块数量都是16的倍数
- 每一组（按16个坏块划分）都是连续编号的块出现异常，每一组之间不一定连续
这里可以简单计算一下，16*8k=48k，这里也能大概推测出EMC存储底层的单元大小了。
总结
本期复盘了一下因EMC存储异常导致的坏块问题，如何检查并修复这些坏块。
老规矩，知道写了些啥。
