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

推荐订阅源

博
博客园_首页
B
Blog RSS Feed
Microsoft Azure Blog
Microsoft Azure Blog
J
Java Code Geeks
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Google DeepMind News
Google DeepMind News
F
Fortinet All Blogs
V
V2EX
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Engineering at Meta
Engineering at Meta
月光博客
月光博客
阮一峰的网络日志
阮一峰的网络日志
M
MIT News - Artificial intelligence
IT之家
IT之家
博
博客园 - 【当耐特】
U
Unit 42
云风的 BLOG
云风的 BLOG
L
LangChain Blog
小众软件
小众软件
Microsoft Security Blog
Microsoft Security Blog
B
Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
宝玉的分享
宝玉的分享
N
Netflix TechBlog - Medium

博客园 - 惜分飞

不太常见的10.2.0.1的oracle redo损坏恢复--惜分飞 obet快速修复oracle 位图损坏块 obet forcecopy功能抢救硬件故障中的数据文件 分享一例运行在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 rose双机引起文件系统损坏导致数据库异常故障处理---惜分飞 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）
通过obet 恢复system坏块,打开数据库---惜分飞
惜分飞 · 2026-08-25 · via 博客园 - 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：通过obet 恢复system坏块,打开数据库

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户由于误操作直接在虚拟化平台点击电源键,强制关闭了正在运行的数据库服务器虚机,导致数据库无法正常启动,检查发现ntfs文件系统损坏
ntfs-err

通过obet工具检测数据文件坏块(obet dbv功能完整说明),发现核心的system文件上面有一些坏块

File

File

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

这个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

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

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 !=

**** actual rows locked by itl 3  = 0 !=

---- 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 !=

**** 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.

使用expdp导出数据,完成本次恢复任务
expdp_ok

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。