标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet 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-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,875)
- DB2 (22)
- MySQL (82)
- Oracle (1,701)
- 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备份恢复 (658)
- Oracle安装升级 (107)
- 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)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
-
最近发表
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
- ORA-00314: log 3 of thread 1, expected sequence# N doesn’t match 0
- 记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理
- 需要注意:dbv 检测controlfile可能不准
- 达梦数据库redo异常强制拉库
- dd破坏包含50多个pdb的asm 磁盘组恢复
标签归档:obet system
通过obet 恢复system坏块,打开数据库
客户由于误操作直接在虚拟化平台点击电源键,强制关闭了正在运行的数据库服务器虚机,导致数据库无法正常启动,检查发现ntfs文件系统损坏

通过obet工具检测数据文件坏块(obet dbv功能完整说明),发现核心的system文件上面有一些坏块
File #1: D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF (225281 blocks) - Started: 2026-08-21 16:40:23 File #1: rfile=1 (0x00000001) header_block_num=225280 (0x00037000) filesize_status:OK file 1, block 212238: tailchk error (expected 0x0106276F, got 0x01065E92), bad block file 1, block 213507: tailchk error (expected 0x0106276F, got 0x01065E92), bad block file 1, block 213515: tailchk error (expected 0x01065E92, got 0x0106276F), bad block file 1, block 213547: tailchk error (expected 0x0106276F, got 0x01065E92), bad block file 1, block 213555: tailchk error (expected 0x01065E92, got 0x0106276F), bad block file 1, block 221387: tailchk error (expected 0x0106276F, got 0x01065E92), bad block file 1, block 221403: tailchk error (expected 0x01065E92, got 0x0106B19C), bad block file 1, block 221419: tailchk error (expected 0x01065E92, got 0x0106C7E3), bad block file 1, block 222117: tailchk error (expected 0x01065E92, got 0x0106276F), bad block file 1, block 222133: tailchk error (expected 0x0106276F, got 0x01065E92), bad block file 1, block 222141: tailchk error (expected 0x01065E92, got 0x0106276F), bad block file 1, block 222173: tailchk error (expected 0x0106C7E3, got 0x01065E92), bad block File #1 completed: 0 all zero, 0 soft corrupted, 12 tailchk error, 0 checksum error, 0 rdba error
这个12个坏块的数量和dbv检测结果一致
DBVERIFY: Release 19.0.0.0.0 - Production on 星期五 8月 21 17:37:02 2026 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF 页 212238 流入 - 很可能是介质损坏 Corrupt block relative dba: 0x00433d0e (file 1, block 212238) Fractured block found during dbv: Data in bad block: type: 6 format: 2 rdba: 0x00433d0e last change scn: 0x0000.0002.d71a6f27 seq: 0x1 flg: 0x06 spare3: 0x0 consistency value in tail: 0x925e0601 check value in block header: 0x93bb computed block checksum: 0xfd79 ………… 页 222173 流入 - 很可能是介质损坏 Corrupt block relative dba: 0x004363dd (file 1, block 222173) Fractured block found during dbv: Data in bad block: type: 6 format: 2 rdba: 0x004363dd last change scn: 0x0000.0002.d708e3c7 seq: 0x1 flg: 0x06 spare3: 0x0 consistency value in tail: 0x925e0601 check value in block header: 0xe089 computed block checksum: 0x7199 DBVERIFY - 验证完成 检查的页总数: 225280 处理的页总数 (数据): 125451 失败的页总数 (数据): 0 处理的页总数 (索引): 29984 失败的页总数 (索引): 0 处理的页总数 (其他): 48214 处理的总页数 (段) : 1 失败的总页数 (段) : 0 空的页总数: 21619 标记为损坏的总页数: 12 流入的页总数: 12 加密的总页数 : 0 最高块 SCN : 12199365950 (2.3609431358)
使用obet的reair block功能进行修复(obet repair block使用说明)
OBET> set file 1 filename set to: D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF (file#1) OBET> set block 212238 block set to: 212238 OBET> d File: D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF Block: 212238 Offsets: 0 to 31 -------------------------------------------------------------------------------- 67A1C000 06A20000 0E3D4300 276F1AD7 02000106 BB930000 02000000 D0020000 E46E1AD7 <32 bytes read> OBET> tailchk Check tailchk for File D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF, Block 212238: current = 0x925E0601, required = 0x6F270601 OBET> backup Backing up file #1, block 212238 Successfully backed up block 212238 from D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF to backup_blk\SYSTEM01.DBF.212238_20260821173825.blk OBET> set mode edit mode set to: edit OBET> repair Usage: repair [subcommand] repair block [file N] [X] - Repair tailchk/checksum (optional: file N, block X) repair blkscn [file N] [X] - Repair block SCN (optional: file N, block X) OBET> repair block Warning: Missing value for 'block', using global setting: 212238 Repairing block 212238 in file D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF... Repair analysis for block 212238: 1. seq_kcbh check: 0x01 -> OK 2. Tailchk check: 0x925E0601 -> needs repair (0x6F270601) 3. Checksum check: 0xBB93 -> OK Confirm repair operations: File: D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF Block: 212238 Operations needed: fix tailchk Confirm? (Y/YES to proceed): y Verification after repair: 1. seq_kcbh: 0x01 OK 2. Tailchk: 0x6F270601 OK 3. Checksum: 0xBB93 OK Block 212238 repair completed successfully.
所有坏块依次进行修复,然后再次使用dbv检测
DBVERIFY: Release 19.0.0.0.0 - Production on 星期五 8月 21 17:42:02 2026 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF Block Checking: DBA = 4407811, Block Type = KTB-managed data block **** actual rows locked by itl 2 = 0 != # in trans. header = 1 **** actual rows locked by itl 3 = 0 != # in trans. header = 1 ---- end index block validation 页 213507 失败, 校验代码为 6401 Block Checking: DBA = 4407819, Block Type = KTB-managed data block **** row 120: key out of order **** actual rows locked by itl 2 = 0 != # in trans. header = 1 **** actual rows marked deleted = 1 != kdxlende = 0 ---- end index block validation 页 213515 失败, 校验代码为 6401 DBVERIFY - 验证完成 检查的页总数: 225280 处理的页总数 (数据): 125451 失败的页总数 (数据): 0 处理的页总数 (索引): 29996 失败的页总数 (索引): 2 处理的页总数 (其他): 48214 处理的总页数 (段) : 1 失败的总页数 (段) : 0 空的页总数: 21619 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 12199365950 (2.3609431358)
有两个block有少量逻辑错误,可以通过数据库级别设置进行跳过,基本上实现了这个12个坏块的自动修复.后续就是数据库的打开过程
SQL> startup mount pfile='d:/pfile.txt'
ORACLE 例程已经启动。
Total System Global Area 1.2885E+10 bytes
Fixed Size 16120656 bytes
Variable Size 7751073792 bytes
Database Buffers 5100273664 bytes
Redo Buffers 17432576 bytes
数据库装载完毕。
SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-00742: 日志读取在线程 1 序列 19828 块 11511 中检测到写入丢失情况
ORA-00312: 联机日志 2 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\NHIS\REDO02.LOG'
SQL> RECOVER DATABASE UNTIL TIME '2026-08-21:13:28:56' USING BACKUP CONTROLFILE;
ORA-00279: change 12198905983 generated at 08/21/2026 12:43:18 needed for
thread 1
ORA-00289: suggestion :
D:\APP\ADMINISTRATOR\PRODUCT\19.0.0\DBHOME_1\RDBMS\ARC0000019827_1199133733.0001
ORA-00280: change 12198905983 for thread 1 is in sequence #19827
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D:\APP\ADMINISTRATOR\ORADATA\NHIS\REDO01.LOG
ORA-00279: change 12199301614 generated at 08/21/2026 13:27:06 needed for
thread 1
ORA-00289: suggestion :
D:\APP\ADMINISTRATOR\PRODUCT\19.0.0\DBHOME_1\RDBMS\ARC0000019828_1199133733.0001
ORA-00280: change 12199301614 for thread 1 is in sequence #19828
ORA-00278: log file 'D:\APP\ADMINISTRATOR\ORADATA\NHIS\REDO01.LOG' no longer
needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D:\APP\ADMINISTRATOR\ORADATA\NHIS\REDO02.LOG
ORA-00756: 鎭㈠鎿嶄綔妫€娴嬪埌鏁版嵁鍧楀啓鍏ヤ涪澶?ORA-10567:
Redo is inconsistent with data block (file# 4, block# 31663, file offset is 259383296 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: 鏁版嵁鏂囦欢 4: 'D:\APP\ADMINISTRATOR\ORADATA\NHIS\UNDOTBS01.DBF'
ORA-10560: block type 'KTU UNDO BLOCK'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
Database altered.


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

