rose双机引起文件系统损坏使得数据库异常故障处理---惜分飞

有客户做了双机rose,由于某种故障导致共享存储在两个主机之间相互频繁挂载(甚至出现了同时挂载的情况),使得该文件系统发生损坏

修复双机故障之后,数据库启动ORA-01122 ORA-01110 ORA-01200错误

初步看这个报错,block差距有点大,文件头中记录为419840个block,现在实际有的block数量为384000,使用obet查看文件头记录block number情况

|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| OBET> p kcvfh.kcvfhhdr File: E:\TEMP\20260219\SYSTEM01.DBF Size: 8192 bytes Block: 1 Offset: 20 struct kcvfhhdr, 76 bytes @20 ``ub4 kccfhswv @20 0x00000000 ``ub4 kccfhcvn @24 0x0B200400 ``ub4 kccfhdbi @28 0x85D98FAB ``text kccfhdbn[8] @32-39 XXXX ``ub4 kccfhcsq @40 0x00091079 ``ub4 kccfhfsz @44 0x00066800 <<--16转换为10进制为419840 ``s_blkz kccfhbsz @48 0x00 ``ub2 kccfhfno @52 0x0001 ``ub2 kccfhtyp @54 0x0003 ``ub4 kccfhacid @56 0x00000000 ``ub4 kccfhcks @60 0x00000000 ``text kccfhtag[32] @64-95 <kcvfh.kcvfhhdr structure printed successfully> |

对于这种情况,以前有过很多次处理经验(一般办法2个:1>修改文件头的block数量记录;2>修改现在的文件大小和实际文件有匹配),以前类似的处理记录:
bbed处理ORA-01200故障
记录一次ORA-01200完美恢复
ORA-01122 ORA-01200故障处理

处理完成system文件异常之后,sysaux文件继续异常

|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| SQL> recover datafile 1; 完成介质恢复。 SQL> recover datafile 2; ORA-00283: 恢复会话因错误而取消 ORA-01110: 数据文件 2: ``'Z:\APP\ADMINISTRATOR\ORADATA\XXXX\SYSAUX01.DBF' ORA-01122: 数据库文件 2 验证失败 ORA-01110: 数据文件 2: ``'Z:\APP\ADMINISTRATOR\ORADATA\XXXX\SYSAUX01.DBF' ORA-01200: 149760 的实际文件大小小于 153600 块的正确大小 |

类似处理该故障之后,由于文件系统故障导致不少文件出现大量连续坏块(全0或者记录了其他文件内容的坏块),这种是由于文件系统元数据异常导致,通过文件系统层面恢复继续无法正常处理,对于这样的情况,通过碎片扫描工具按照oracle block级别的文件重组(其实就是基于rdba信息进行重组),获取正确的数据块信息然后重新重组成数据文件

然后打开数据库,顺利导出数据,实现客户数据最大限度恢复

相关推荐
烬羽2 分钟前
给 Agent 一个检索式记忆:把对话历史存进 Milvus,该记的都记得
javascript·数据库·agent
星云API技术支持10 分钟前
企业微信二次开发外部群:群聊数据与联系人信息如何建立关联
数据库·php·企业微信
我不是程序员三三12 分钟前
桌面管理软件哪个最好?从一次上线翻车事故,拆解选型评估与配置落地全流程
数据库
落木萧萧82515 分钟前
MyBatis 关联查询的四种写法,为什么最后都变回了手写 XML
java·数据库·后端
春风解人意21 分钟前
从零开始学习嵌入式P35----数据库
数据库·嵌入式硬件·学习
sunoo-22922 分钟前
【网络编程 + 数据库】select 与 epoll 核心区别详解 + SQLite 入门到 C 接口全攻略
linux·网络·数据库·vscode·学习·sqlite
TDengine (老段)23 分钟前
TDengine 错误处理 — 错误码、异常传播、故障恢复
大数据·数据库·物联网·时序数据库·tdengine·涛思数据
zbyyd27 分钟前
Linux 系统编程 :select/epoll 多路复用与 SQLite 数据库实战
linux·数据库·sqlite
俊昭喜喜里28 分钟前
c#中的构造函数
开发语言·数据库·c#
养生技术人38 分钟前
Oracle OCP认证考试题目详解082系列第17题
运维·数据库·sql·oracle·ocp