惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Jina AI
Jina AI
Hugging Face - Blog
Hugging Face - Blog
博客园 - 三生石上(FineUI控件)
博客园 - 【当耐特】
大猫的无限游戏
大猫的无限游戏
IT之家
IT之家
宝玉的分享
宝玉的分享
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
Apple Machine Learning Research
Apple Machine Learning Research
酷 壳 – CoolShell
酷 壳 – CoolShell
阮一峰的网络日志
阮一峰的网络日志
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
爱范儿
爱范儿
小众软件
小众软件
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The Cloudflare Blog
S
SegmentFault 最新的问题
博客园 - Franky
博客园_首页
T
Tailwind CSS Blog
雷峰网
雷峰网
罗磊的独立博客

博客园 - 惜分飞

不太常见的10.2.0.1的oracle redo损坏恢复--惜分飞 obet快速修复oracle 位图损坏块 obet forcecopy功能抢救硬件故障中的数据文件 通过obet 恢复system坏块,打开数据库---惜分飞 分享一例运行在aix上的sap系统数据库恢复过程--惜分飞 obet dbv功能完整说明 Oracle Block Editor Tool 几乎动用了所有手段的Oracle故障恢复--惜分飞 Oracle Block Edit Tool (obet) 功能增强–2026.07 使用deepseek进行Oracle恢复,引起重大故障---惜分飞 硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复 1.5T MySQL数据库完美恢复---惜分飞 asm dd 10M导致system文件部分坏块修复---惜分飞 一次断电引起的Oracle故障恢复-ora-600 2662故障---惜分飞 Oracle故障第一现场被恢复混乱的数据库恢复--惜分飞 OraScan (Oracle碎片扫描工具)使用说明 imp导入dmp报IMP-00098: INTERNAL ERROR: impgst2故障处理 记录一次win删除数据文件完美恢复案例 国产信创库fio破坏主备库以及备份故障处理--惜分飞 .wman扩展名勒索mysql数据库恢复 Oracle数据库被勒索加密一键open工具–OraFHR ORA-704 ORA-604 ORA-1578故障处理 csc(0x0006.d75a14f4) higher than block scn(0x0000.00000000)--故障处理--obet ORA-600 kcratr_nab_less_than_odr和ORA-600 4193故障处理---惜分飞 aix环境10g由于控制器异常导致ORA-600 4000故障处理---惜分飞 不当恢复truncate数据导致数据库不能open处理 在生产环境错误执行dd命令破坏asm磁盘故障恢复---惜分飞 Patch_SCN快速解决ORA-600 2663故障 obet实现对数据文件坏块检测功能(obet dbv) obet快速修改scn/resetlogs恢复数据库(缺少归档,ORA-00308)
rose双机引起文件系统损坏导致数据库异常故障处理---惜分飞
惜分飞 · 2026-02-21 · via 博客园 - 惜分飞

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

ntfs


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


初步看这个报错,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信息进行重组),获取正确的数据块信息然后重新重组成数据文件
QQ20260220-005159


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