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

推荐订阅源

Google DeepMind News
Google DeepMind News
爱范儿
爱范儿
J
Java Code Geeks
L
LangChain Blog
V
V2EX
大猫的无限游戏
大猫的无限游戏
S
SegmentFault 最新的问题
博客园 - Franky
Microsoft Azure Blog
Microsoft Azure Blog
Jina AI
Jina AI
Blog — PlanetScale
Blog — PlanetScale
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
The Cloudflare Blog
博客园 - 司徒正美
B
Blog
G
Google Developers Blog
Stack Overflow Blog
Stack Overflow Blog
罗磊的独立博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Apple Machine Learning Research
Apple Machine Learning Research
Engineering at Meta
Engineering at Meta
MyScale Blog
MyScale Blog
有赞技术团队
有赞技术团队
Hugging Face - Blog
Hugging Face - 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


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