分类目录归档:Oracle备份恢复

obet快速修复oracle 位图损坏块

近期有客户由于虚拟化平台系统负载过高,重启之后导致数据库出现一些坏块
1_1


其中被框起来的坏块比较好处理,属于数据库中间某个对象的block,对异常对象进行处理即可,但是有一个block 2,block 10 这种都属于数据文件中位图块(用来记录哪些block被使用,哪些block是没有使用),这种block如果损坏会导致该文件无法分配新的空间(也不能回收空间,无法统计表空间使用情况等)
1_2
1_3

alert日志有大量报错
1_5

对于这种情况,直接使用obet的坏块修复功能

OBET> set file 116
filename set to: /oradata/NNC_DATA207.dbf (file# 116)
endian auto-detected: little

OBET> set block 10
block set to: 10

OBET> backup
Backing up file #116, block 10
Successfully backed up block 10 from /oradata/NNC_DATA207.dbf to backup_blk/NNC_DATA207.dbf.10_20260902200547.blk

OBET> repair block
Warning: Missing value for 'block', using global setting: 10

Repairing block 10 in file /oradata/NNC_DATA207.dbf...

Repair analysis for block 10:
1. seq_kcbh check: 0xFF -> needs repair (0x01)
2. Tailchk check: 0x00001EFF -> needs repair (0x00001E01)
3. Checksum check: 0xCBC7 -> OK

Confirm repair operations:
File: /oradata/NNC_DATA207.dbf
Block: 10
Operations needed: fix offset14, fix tailchk
Confirm? (Y/YES to proceed): y

Verification after repair:
1. seq_kcbh: 0x01 OK
2. Tailchk: 0x00001E01 OK
3. Checksum: 0xCBC7 OK

Block 10 repair completed successfully.

OBET>

OBET> set file 119
filename set to: /oradata/NNC_DATA210.dbf (file# 119)
endian auto-detected: little

OBET> set block 2
block set to: 2

OBET> backup
Backing up file #119, block 2
Successfully backed up block 2 from /oradata/NNC_DATA210.dbf to backup_blk/NNC_DATA210.dbf.2_20260902200645.blk

OBET> repair block
Warning: Missing value for 'block', using global setting: 2

Repairing block 2 in file /oradata/NNC_DATA210.dbf...

Repair analysis for block 2:
1. seq_kcbh check: 0xFF -> needs repair (0x01)
2. Tailchk check: 0x00001DFF -> needs repair (0x00001D01)
3. Checksum check: 0x80EC -> OK

Confirm repair operations:
File: /oradata/NNC_DATA210.dbf
Block: 2
Operations needed: fix offset14, fix tailchk
Confirm? (Y/YES to proceed): y

Verification after repair:
1. seq_kcbh: 0x01 OK
2. Tailchk: 0x00001D01 OK
3. Checksum: 0x80EC OK

Block 2 repair completed successfully.

OBET> exit
Exiting OBET.

使用dbv检测,位图坏块全部修复

[oracle@nccdb ~]$ dbv file=/oradata/NNC_DATA210.dbf

DBVERIFY: Release 11.2.0.4.0 - Production on Wed Sep 2 20:07:15 2026

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - Verification starting : FILE = /oradata/NNC_DATA210.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 4194302
Total Pages Processed (Data) : 3472440
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 205988
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 515867
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 7
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 751241252 (22.751241252)
[oracle@nccdb ~]$ dbv file=/oradata/NNC_DATA207.dbf

DBVERIFY: Release 11.2.0.4.0 - Production on Wed Sep 2 20:08:23 2026

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - Verification starting : FILE = /oradata/NNC_DATA207.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 4194302
Total Pages Processed (Data) : 3471468
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 204185
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 518642
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 7
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 751241266 (22.751241266)

后续数据顺利导出,完成这次恢复
1_4


发表在 Oracle备份恢复 | 标签为 , , | 评论关闭

不太常见的10.2.0.1的oracle redo损坏恢复

曾经恢复过大量10g的库,现在一年也恢复不了几个10g的了,而10.2.0.1的64位库更是少之又少了.近期有幸处理过一个这样的case,重温了当年的感觉

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 64-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

由于系统断电导致该版本的erp系统的数据库无法启动,看alert日志由于redo损坏导致异常(ORA-00354 ORA-00353)

Thu Jun 04 10:27:40 2026
ALTER DATABASE RECOVER  datafile 5  
Thu Jun 04 10:27:40 2026
Media Recovery Start
WARNING! Recovering data file 5 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
 parallel recovery started with 7 processes
Thu Jun 04 10:27:40 2026
Recovery of Online Redo Log: Thread 1 Group 3 Seq 26215 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
Thu Jun 04 10:28:06 2026
Errors in file d:\oracle\product\10.2.0\admin\ORCL\udump\ORCL_ora_3856.trc:
ORA-00354: 损坏重做日志块头部
ORA-00353: 日志损坏接近块 93816 更改 1049070732 时间 05/27/2025 18:00:16
ORA-00334: 归档日志: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG'

接手之后再次验证了该错误
1


这种错误基本上要不bbed/obet修改文件头,要不直接屏蔽一致性强制打开,我直接选择了强制拉库,先做不完全恢复
2

然后强制拉库报ORA-600 2662错误
3

直接使用_minimum_giga_scn修改scn,数据库open成功,并使用expdp成功导出数据,完成本次恢复工作
4

发表在 Oracle备份恢复 | 标签为 , | 评论关闭

obet forcecopy功能抢救硬件故障中的数据文件

客户raid5发现有盘离线,并且其他盘有坏道,进行了多次换盘操作替换了大部分有坏道磁盘,但是部分文件访问依旧会报io错误
ioerror


直接cp文件报

cp: error reading 'datafile': Input/output error

数据库层面操作报

ORA-01115: IO error reading block from file %s (block # %s)
ORA-27072: File I/O error
Linux-x86_64 Error: 5: Input/output error
Additional information: 4
Additional information: 21571487880

对于这样的情况,使用obet的forcecopy功能直接强制拷贝文件,可以最大限度求救数据obet forcecopy
forcecopy


把所有损坏文件拷贝出来之后传输到其他机器上,检查所有文件坏块情况
obet_bad_block

运气不错,整体坏块非常少,而且没有涉及数据库字典文件,然后尝试恢复
recovery

虽然recover database成功,但是不幸open 库报ORA-600 kcbzib_kcrsds_1错误

SQL> ALTER DATABASE OPEN ;
ALTER DATABASE OPEN 
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], []
Process ID: 15786
Session ID: 3054 Serial number: 46983

通过obet的patch_scn功能进行修改scn
obet_patch_scn


顺利打开数据库,并导出数据

发表在 Oracle备份恢复 | 标签为 , , , , | 评论关闭