接到应用反馈某张业务表无法进行查询，报ORA-01578有坏块出现。
1)、该表为普通表，可以通过analyze命令快速分析是表有问题还是索引有问题，可以确定表有坏块。
2)、视图查询，显示有3个坏块（可能不准确），通过文件号和块号查询出坏块都指向了这张表。目前看只有这张表有问题。CORRUPTION_CHANGE#列0表示物理坏块，非0表示逻辑坏块。该库没有未接入备份,blockrecover用不了，也就是说正常手段无法修复。但可以通过expdp工具或者dbms_repair包等其它手段来抢救该表上正常块上的数据。
3)、这套库有adg，在adg上可正常查询，比较幸运的是这张当前无数据，无数据丢失风险。
因为不需要做数据恢复，DB侧最终给的建议是换表，便于后续写入读取数据。
另外因为有坏块出现，后面通过dbv对全库数据文件进行检测，命令大致如下如下：
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来说，备份重于一切。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130056.html
摘要：初步分析提升可从两方面入手，一个是增加并发数，其二是减少平均响应时间。大部分的时间花在系统与数据库的交互上，到这，便有了一个优化的主题思路最大限度的降低平均响应时间。不要轻易否定一项公认的技术真理，要拿数据说话。 本文最早发表于个人博客：PylixmWiki 应项目的需求，我们使用tornado开发了一个api系统，系统开发完后，在8核16G的虚机上经过压测qps只有200+。与我们当...
摘要：直接显示了一个疑似内存泄漏的问题。然后分析文件给出的信息，发现一个叫的类。文件里面说的内存泄漏的大概的意思就是说，这个类里面的存放的东西太多了，爆掉了。修改了代码将调用的地方改成了单例。修改完线上跑了一段日子，后来也没有出现过这样的问题。 问题描述: 早上去公司上班,突然就邮件一直报警,接口报异常,然后去查服务器的运行情况,发现java的cpu爆了.接着就开始排查问题 问题解决...
阅读 1347·2023-01-11 13:20
阅读 1685·2023-01-11 13:20
阅读 1133·2023-01-11 13:20
阅读 1860·2023-01-11 13:20
阅读 4101·2023-01-11 13:20
阅读 2705·2023-01-11 13:20
阅读 1386·2023-01-11 13:20
阅读 3598·2023-01-11 13:20
