标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-600 kdsgrp1 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,862)
- DB2 (22)
- MySQL (82)
- Oracle (1,688)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (646)
- Oracle安装升级 (106)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (90)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (48)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (31)
-
最近发表
- 记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理
- 需要注意:dbv 检测controlfile可能不准
- 达梦数据库redo异常强制拉库
- dd破坏包含50多个pdb的asm 磁盘组恢复
- Oracle数据库系统回滚段异常处理-ORA-600 4137/4193
- 使用deepseek进行Oracle恢复,引起重大故障
- 接手一个只差临门一脚的数据库恢复
- 硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复
- 1.5T MySQL数据库完美恢复
- WARNING: detected duplicate paths to the same disk导致crs无法正常启动故障解决
- asm dd 10M导致system文件部分坏块修复
- Oracle 19c 202604补丁(RUs+OJVM)-19.31
- Oracle故障第一现场被恢复混乱的数据库恢复
- impdp报ORA-39083 ORA-14102错误处理
- 一次断电引起的Oracle故障恢复-ora-600 2662故障
- OraScan(Oracle 碎片扫描工具) 使用说明
- .[xueyuanjie@onionmail.org].AIR勒索加密数据库恢复
- oracleasm createdisk破坏的acfs文件系统恢复
- 先offline数据文件,再resetlogs导致恢复复杂的故障处理
- exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理
分类目录归档:非常规恢复
硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复
有硬件恢复圈朋友找到我,说硬件恢复之后dbv报dbv-00102错误,让我给看看是否可以处理

这个是oracle dbv中一种常见错误,一般是由于block 0 不对,或者是由于文件大小不对引起,让把恢复文件发给我,进行检查
SQL> select name,bytes/1024/1024/1024 from v$datafile_header; NAME BYTES/1024/1024/1024 -------------------------------------------------------------------------------- -------------------- H:\BAIDUNETDISK\ORADATA\XXXXORCL\SYSTEM01.DBF 2.080078125 H:\BAIDUNETDISK\ORADATA\XXXXORCL\SYSAUX01.DBF 2.880859375 H:\BAIDUNETDISK\ORADATA\XXXXORCL\UNDOTBS01.DBF 9.0087890625 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS01.DBF 31.993408203125 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS02.DBF 8.1640625 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS03.DBF 7.958984375 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS04.DBF 7.958984375 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS05.DBF 7.890625 已选择8行。
确定USER02-USERS05的dbf文件实际大小(数据文件头记录)在8G左右,但是目前恢复出来的文件大小只有4G左右

在恢复工具中直接查看文件大小情况

这里比较明显rs中虽然显示文件状态良好,但是实际大小也不对(得出经验:以后恢复中不能太依赖这个状态),根据反馈现场是三个盘的raid5,中途做了一次强制上线,然后客户也使用win pe拷贝过一次数据,大小和现在一样,也是少了近4G.第一反应可能是由于raid盘弄的不对,但是经过对其他文件的确认,多完全没有问题,排除了盘错误的问题,怀疑是由于文件系统异常导致,对于这种的情况,文件系统层面肯定无法恢复,考虑使用自研的OraScan工具进行扫描(OraScan(Oracle 碎片扫描工具) 使用说明)


通过OraScan扫描找到相关block,并提取出来数据文件

使用dbv检测文件
C:\Users\XFF>dbv file=H:\BaiduNetdisk\xff\YFKJORCL.USERS.4.7.4.N.DBF DBVERIFY: Release 11.2.0.4.0 - Production on 星期日 6月 7 18:06:30 2026 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\XFF\YFKJORCL.USERS.4.7.4.N.DBF DBVERIFY - 验证完成 检查的页总数: 1043200 处理的页总数 (数据): 67167 失败的页总数 (数据): 0 处理的页总数 (索引): 37995 失败的页总数 (索引): 0 处理的页总数 (其他): 861109 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 76929 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 347454063 (0.347454063)
把文件拷贝替换掉之前恢复的USERS02-USER05.DBF,然后尝试打开数据库
SQL> recover database ; 完成介质恢复。 SQL> alter database open ; alter database open * 第 1 行出现错误: ORA-03113: 通信通道的文件结尾 进程 ID: 3308 会话 ID: 14 序列号: 3
查看alert日志分析原因
Sun Jun 07 14:43:51 2026 Recovery of Online Redo Log: Thread 1 Group 2 Seq 36464 Reading mem 0 Mem# 0: H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO02.LOG Completed: ALTER DATABASE RECOVER database alter database open Beginning crash recovery of 1 threads parallel recovery started with 19 processes Started redo scan Completed redo scan read 2353 KB redo, 0 data blocks need recovery Started redo application at Thread 1: logseq 36464, block 15876 Recovery of Online Redo Log: Thread 1 Group 2 Seq 36464 Reading mem 0 Mem# 0: H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO02.LOG Completed redo application of 0.00MB Completed crash recovery at Thread 1: logseq 36464, block 20582, scn 347475303 0 data blocks read, 0 data blocks written, 2353 redo k-bytes read Sun Jun 07 14:43:57 2026 Errors in file c:\app\xff\diag\rdbms\yfkjorcl\o11201\trace\o11201_lgwr_2204.trc: ORA-00314: ?? 3 (???? 1) ??? sequence# 36462 ? 32025 ??? ORA-00312: ???? 3 ?? 1: 'H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO03.LOG' Errors in file c:\app\xff\diag\rdbms\yfkjorcl\o11201\trace\o11201_lgwr_2204.trc: ORA-00314: ?? 3 (???? 1) ??? sequence# 36462 ? 32025 ??? ORA-00312: ???? 3 ?? 1: 'H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO03.LOG' Errors in file c:\app\xff\diag\rdbms\yfkjorcl\o11201\trace\o11201_ora_3308.trc: ORA-00314: 日志 1 (用于线程 ) 要求的 sequence# 与 不匹配 ORA-00312: 联机日志 3 线程 1: 'H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO03.LOG' USER (ospid: 3308): terminating the instance due to error 314 Sun Jun 07 14:44:02 2026 Instance terminated by USER, pid = 3308
由于redo group 异常导致库无法正常open,但是由于已经recover database成功,因此大概率可以clear该redo 组
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
3 INACTIVE
2 CURRENT
SQL> alter database clear logfile group 3;
数据库已更改。
SQL> alter database open;
数据库已更改。
数据库open成功,然后使用expdp导出数据,完成本次恢复任务.
记录一次win删除数据文件完美恢复案例
有客户在操作系统层面删除了四个数据文件(数据库在关闭情况下直接删除物理文件),然后offline,启动数据库,结果发现被删除的数据文件是业务表空间的,导致大量业务访问报错

通过数据库层面查询确认这些文件已经不存在

对于这样的情况,先尝试从文件系统层面尝试反删除恢复文件

由于删除文件之后,启动了数据库并写入了一些日志和数据导致被删除的文件的元数据信息彻底丢失,这种情况下基于文件系统的反删除恢复肯定无法需要的数据,对于这种情况,考虑进行碎片层面恢复,以前有过类似案例:
win系统删除oracle数据文件恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
删除数据库文件并部分覆盖情况下Oracle恢复
通过底层扫描发现需要恢复的文件头部信息丢失,其他block完整(该文件本身不大,只有100M),扫描出来的数据块类似这样的结果


这里比较幸运,丢失的block为1-3,也就是涉及文件头和一些位图信息,通过以前自研的OraFHR工具(Oracle数据库被勒索加密一键open工具–OraFHR)进行重构文件头,再通过oracle recovery tools工具进行文件头的一些修复工作

再重建控制文件打开数据库,并完美导出数据,实现数据0丢失恢复

文件系统损坏导致数据库异常故障处理
有客户做了双机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信息进行重组),获取正确的数据块信息然后重新重组成数据文件

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

加我微信(17813235971)
加我QQ(107644445)

