联系:手机/微信(+86 17813235971) QQ(107644445)
作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
客户由于误操作直接在虚拟化平台点击电源键,强制关闭了正在运行的数据库服务器虚机,导致数据库无法正常启动,检查发现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.
