一次坏块ora-01578的分析过程
👉 本文共约998个字，系统预计阅读时间或需4分钟。
现象
接到应用反馈某张业务表无法进行查询，报ORA-01578有坏块出现。
分析
该表为普通表，可以通过analyze命令快速分析是表有问题还是索引有问题，可以确定表有坏块。
本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信db_bao，谢谢！
视图查询，显示有3个坏块（可能不准确），通过文件号和块号查询出坏块都指向了这张表。目前看只有这张表有问题。CORRUPTION_CHANGE#列0表示物理坏块，非0表示逻辑坏块。
该库没有未接入备份,blockrecover用不了，也就是说正常手段无法修复。但可以通过expdp工具或者dbms_repair包等其它手段来抢救该表上正常块上的数据。
这套库有adg，在adg上可正常查询，比较幸运的是这张当前无数据，无数据丢失风险。
处理方法
因为不需要做数据恢复，DB侧最终给的建议是换表，便于后续写入读取数据。
另外因为有坏块出现，后面通过dbv对全库数据文件进行检测，命令大致如下如下：
1 2 3 4 5 | set feedback off head off echo off linesize 200 pagesize 1000 spool /tmp/dbvchk.sh select 'dbv file=' || name || ' blocksize='|| block_size || ' USERID=sys/x’x’x’x logfile=' ||substr(name, instr(name, '/', -1, 1) +1) ||'.' || file# || '.log' from v$datafile; |
对输出结果进行过滤，部分数据文件上出现了大量坏块。
对于这种大量的坏块，初步怀疑可能是存储有问题，但主机侧反馈底层存储都正常，问题到这里就比较无解了，但好在有套adg环境，容灾库上未发现有坏块,后期考虑切到容灾库。另外业务侧除了反馈这张表有问题外，其它表再也没反馈。只能说运气较好，可能坏块不是出在热表上。
总 结
当出现坏块时，DBV可以快速的且不影响业务的情况下统计出全库有多少坏块。如果只有个别几个块，我们可以尝试修复或者抢救出非坏块上的数据。但如果是大量的出现坏块，且影响业务，这可能就是灾难的故障。最后要说的是，对于DBA来说，备份重于一切。
