obet一键恢复offline数据文件

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

标题:obet一键恢复offline数据文件

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

客户有一个数据库由于异常断电之后无法正常启动,自行尝试恢复之后但是没有open成功,让可以通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本收集信息进行评估,发现两个问题:
1. 根据查询信息确认users01.dbf(file# 4)文件处于offline状态,而且checkpoint scn明显小于其他文件
offline


2. 通过分析alert日志确认客户在尝试offline file 4 之后open数据库报ORA-600 4194错误,数据库没有open成功

Mon Mar 30 06:26:30 2026
Starting ORACLE instance (normal)
Mon Mar 30 06:27:00 2026
ALTER DATABASE DATAFILE 4 OFFLINE DROP
Completed: ALTER DATABASE DATAFILE 4 OFFLINE DROP
Mon Mar 30 06:27:26 2026
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 7 processes
Started redo scan
Completed redo scan
 read 88 KB redo, 103 data blocks need recovery
Started redo application at
 Thread 1: logseq 3, block 3
Recovery of Online Redo Log: Thread 1 Group 3 Seq 3 Reading mem 0
  Mem# 0: /home/oracle/app/oracle/oradata/orcl/redo03.log
Completed redo application of 0.07MB
Completed crash recovery at
 Thread 1: logseq 3, block 180, scn 415466134
 103 data blocks read, 103 data blocks written, 88 redo k-bytes read
Mon Mar 30 06:27:28 2026
Thread 1 advanced to log sequence 4 (thread open)
Thread 1 opened at log sequence 4
  Current log# 1 seq# 4 mem# 0: /home/oracle/app/oracle/oradata/orcl/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Mar 30 06:27:28 2026
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
Errors in file /home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_17628.trc(incident=186839):
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /home/oracle/app/oracle/diag/rdbms/orcl/orcl/orcl_smon_17628_i186839.trc
Exception [type: SIGBUS, Non-existent physical address] [ADDR:0x6C0C4B62] [PC:0x2297750, kgegpa()+40]
Exception [type: SIGBUS, Non-existent physical address] [ADDR:0x6C0C4B62] [PC:0x229597B, kgebse()+279]
Mon Mar 30 06:27:28 2026
PMON (ospid: 17604): terminating the instance due to error 397
Errors in file /home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_17628.trc:
ORA-00328: archived log ends at change 415466135, need later change 415466136
ORA-00334: archived log: '/home/oracle/app/oracle/oradata/orcl/redo03.log'
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], []
Instance terminated by PMON, pid = 17604

接手这个故障之后,由于数据库是非归档模式,而且已经被屏蔽一致性强制打开过(open过程没成功),redo已经被clear过,因此基于这样的情况,直接上obet工具(Oracle Block Editor Tool修改file# 4的文件头状态
obet修复之前文件状态

STATUS	CHECKPOINT_TIME 			 FUZ CHECKPOINT_CHANGE# 	 ROW_NUM
------- ---------------------------------------- --- ------------------ ----------------
OFFLINE 2026-03-30 06:24:41			 YES	      415446014 	       1
ONLINE	2026-03-30 06:28:26			 YES	      415486184 	       7

obet修改文件头操作

OBET> open listfile.txt
Loaded 8 files from  datafile list 'listfile.txt'.

OBET> info

Loaded files (2 total):
----------------------------------------
Number  Path
----------------------------------------
     1  /home/oracle/app/oracle/oradata/orcl/system01.dbf
     4  /opt/oradata/orcl/users01.dbf
----------------------------------------

OBET> set mode edit
mode set to: edit


OBET> set file 4
filename set to: /opt/oradata/orcl/users01.dbf (file#4)

OBET> backup block 1
Created backup directory: backup_blk
Successfully backed up block 1 from current file to /tmp/backup_blk/users01.dbf_1.20260331092333


OBET> copy chkscn file 1 to file 4

Confirm Modify chkscn:
Source: file#1 (/home/oracle/app/oracle/oradata/orcl/system01.dbf)
Target: file#4 (/opt/oradata/orcl/users01.dbf)
Proceed? (Y/YES to confirm): y
Successfully copied checkpoint SCN information from file#1 to file#4.

OBET> exit
Exiting OBET.

再次查询文件头scn信息

STATUS	CHECKPOINT_TIME 			 FUZ CHECKPOINT_CHANGE# 	 ROW_NUM
------- ---------------------------------------- --- ------------------ ----------------
OFFLINE 2026-03-30 06:28:26			 NO	      415486184 	       1
ONLINE	2026-03-30 06:28:26			 YES	      415486184 	       7

尝试online文件,并open库成功

SQL> recover datafile 4;
Media recovery complete.
SQL> alter database datafile 4 online;

Database altered.

SQL> alter database open;

Database altered.

然后expdp导出数据成功,基本完成本次数据恢复工作
dump


Oracle典型故障:The controlfile header block returned by the OS has a sequence number that is too old

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

标题:Oracle典型故障:The controlfile header block returned by the OS has a sequence number that is too old

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

这个是一例子客户数据库运行过程中突然报:The controlfile header block returned by the OS has a sequence number that is too old.然后数据库无法正常启动的数据库恢复case
以前处理过一些类似case:Controlfile sequence number in file header is different from the one in memory
故障现象
alert日志中报The controlfile header block returned by the OS has a sequence number that is too old.错误,然后数据库crash


Wed Mar 18 12:00:44 2026
********************* ATTENTION: ******************** 
 The controlfile header block returned by the OS
 has a sequence number that is too old. 
 The controlfile might be corrupted.
 PLEASE DO NOT ATTEMPT TO START UP THE INSTANCE 
 without following the steps below.
 RE-STARTING THE INSTANCE CAN CAUSE SERIOUS DAMAGE 
 TO THE DATABASE, if the controlfile is truly corrupted.
 In order to re-start the instance safely, 
 please do the following:
 (1) Save all copies of the controlfile for later 
     analysis and contact your OS vendor and Oracle support.
 (2) Mount the instance and issue: 
     ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
 (3) Unmount the instance. 
 (4) Use the script in the trace file to
     RE-CREATE THE CONTROLFILE and open the database. 
*****************************************************
USER (ospid: 15912): terminating the instance

这个错误比较明显是由于控制文件的sequence number比较老导致,出现这种问题,一般是由于io过慢,或者底层不稳定(比如虚拟化平台,文件系统异常,硬件不稳定等)导致(官方参考文档:The controlfile header block returned by the OS has a sequence number that is too old.)

尝试重启数据库报ORA-01207错误

Wed Mar 18 18:51:54 2026
alter database mount exclusive
Successful mount of redo thread 1, with mount id 1534819594
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount exclusive
alter database open
Errors in file e:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_2992.trc:
ORA-01122: ????? 18 ????
ORA-01110: ???? 18: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\XIFENFEI.DBF'
ORA-01207: ????????? - ??????
ORA-1122 signalled during: alter database open...
Wed Mar 18 18:52:01 2026
Checker run found 1 new persistent data failures

该错误的官方解释

[oracle@xifenfei.com ~]$ oerr ora 1207
01207, 00000, "file is more recent than control file - old control file"
// *Cause:  The control file change sequence number in the data file is 
//         greater than the number in the control file. This implies that
//         the wrong control file is being used. Note that repeatedly causing
//         this error can make it stop happening without correcting the real
//         problem. Every attempt to open the database will advance the
//         control file change sequence number until it is great enough.
// *Action: Use the current control file or do backup control file recovery to 
//         make the control file current. Be sure to follow all restrictions 
//         on doing a backup control file recovery.

由于数据文件比控制文件更新,导致该问题,通过查询v$datafile_header发现更多类似异常文件(可以使用Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)收集信息)
111


alert日志文件中也有明显的写错日志信息
222

这些二进制内容和监听日志内容被写入到了alert日志中,证明当时文件系统或者操作系统甚至更底层出现了异常,这个客户是运行在云平台上的,具体运营需要平台厂商才能分析

故障处理
重建控制文件并进行recover

SQL> startup nomount pfile='e:/pfile.txt' ;
ORACLE 例程已经启动。

Total System Global Area 2.9931E+10 bytes
Fixed Size                  2190296 bytes
Variable Size            1946158120 bytes
Database Buffers         2.7917E+10 bytes
Redo Buffers               64905216 bytes
SQL> @rectl.sql

控制文件已创建。
SQL> recover database;

完成介质恢复。

尝试启动数据库,报ora-600 2662错误

SQL> alter database open;

alter database open
*
第 1 行出现错误:

ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [1], [45773288], [1], [45777527], [301990016]
ORA-00600: internal error code, arguments: [2662], [1], [45773287], [1], [45777527], [301990016]
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [1], [45773285], [1], [45777527], [301990016]
进程 ID: 2708
会话 ID: 148 序列号: 5

数据库启动报ORA-600 2662错误,这个是典型的文件头scn过小的问题,通过自研小工具Patch_SCN可以快速解决,以前类似文章:
Patch SCN一键解决ORA-600 2662故障
Patch SCN工具一键恢复ORA-600 kcbzib_kcrsds_1
ORA-600 kcratr_nab_less_than_odr和ORA-600 2662故障处理
333


修改scn之后,数据库顺利打开

SQL> startup mount pfile='e:/pfile.txt';
ORACLE 例程已经启动。

Total System Global Area 2.9931E+10 bytes
Fixed Size                  2190296 bytes
Variable Size            1946158120 bytes
Database Buffers         2.7917E+10 bytes
Redo Buffers               64905216 bytes
数据库装载完毕。
SQL> alter database open;

alter database open
*
第 1 行出现错误:
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF'
SQL> recover database;

完成介质恢复。
SQL> alter database open;

数据库已更改。

通过alert日志回顾其他dba oracle异常恢复故障处理以及后续open数据库操作

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

标题:通过alert日志回顾其他dba oracle异常恢复故障处理以及后续open数据库操作

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

客户有一个数据库故障,是其他工程师进行恢复操作,最后搞不定通过朋友介绍找到我的.我通过分析alert日志,大概追述故障经过
1. 数据库断电之后启动报ORA-01172 ORA-01151错误,直接启动数据库失败,从报错看是由于数据库在open过程中前滚redo日志异常导致

Thu Feb 26 06:48:35 2026
alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 23 processes
Started redo scan
Completed redo scan
 read 73194 KB redo, 37226 data blocks need recovery
Thu Feb 26 06:48:49 2026
Started redo application at
 Thread 1: logseq 869366, block 3
Recovery of Online Redo Log: Thread 1 Group 2 Seq 869366 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
Thu Feb 26 06:48:50 2026
RECOVERY OF THREAD 1 STUCK AT BLOCK 16938 OF FILE 3
Slave exiting with ORA-1172 exception
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_p016_4672.trc:
ORA-01172: recovery of thread 1 stuck at block 16938 of file 3
ORA-01151: use media recovery to recover block, restore backup if needed
Aborting crash recovery due to slave death, attempting serial crash recovery
Beginning crash recovery of 1 threads
Started redo scan
Thu Feb 26 06:49:00 2026
Completed redo scan
 read 73194 KB redo, 37226 data blocks need recovery
Started redo application at
 Thread 1: logseq 869366, block 3
Thu Feb 26 06:49:10 2026
Recovery of Online Redo Log: Thread 1 Group 2 Seq 869366 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
RECOVERY OF THREAD 1 STUCK AT BLOCK 16938 OF FILE 3
Aborting crash recovery due to error 1172
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_9260.trc:
ORA-01172: recovery of thread 1 stuck at block 16938 of file 3
ORA-01151: use media recovery to recover block, restore backup if needed
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_9260.trc:
ORA-01172: recovery of thread 1 stuck at block 16938 of file 3
ORA-01151: use media recovery to recover block, restore backup if needed
ORA-1172 signalled during: alter database open...

2. 尝试recover database报ORA-600 3020、ORA-600 17147、ORA-600 17114、ORA-600 17182等错误,这个报错比较明确是由于redo的block信息和datafile的block不一致,导致实例recover database失败

Thu Feb 26 06:50:54 2026
ALTER DATABASE RECOVER  database  
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 24 slaves
Thu Feb 26 06:50:57 2026
Recovery of Online Redo Log: Thread 1 Group 2 Seq 869366 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
Thu Feb 26 06:50:59 2026
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr0i_9232.trc  (incident=79538):
ORA-00600: internal error code, arguments: [3020], [3], [16934], [12599846], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 16934, file offset is 138723328 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 3: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\UNDOTBS01.DBF'
ORA-10560: block type 'KTU UNDO BLOCK'
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_79538\orcl_pr0i_9232_i79538.trc
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr0i_9232.trc  (incident=79539):
ORA-00600: internal error code, arguments: [17114], [0x0381C4C60], [], [], [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [17182], [0x0381C6948], [], [], [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [17147], [0x0381C4C60], [], [], [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [3020], [3], [16934], [12599846], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 16934, file offset is 138723328 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 3: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\UNDOTBS01.DBF'
ORA-10560: block type 'KTU UNDO BLOCK'

3. 使用隐含参数尝试强制拉库,报ORA-600 2662错误,导致强制拉库没有成功,这个错误相对比较简单,一般修改数据库scn即可

Thu Feb 26 07:04:39 2026
alter database open resetlogs
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 16794964253372
Resetting resetlogs activation ID 1548038913 (0x5c453301)
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_8712.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG'
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_8712.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 2 of thread 1 is not current copy
ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG'
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_8712.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 3 of thread 1 is not current copy
ORA-00312: online log 3 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG'
Thu Feb 26 07:04:49 2026
Setting recovery target incarnation to 3
Thu Feb 26 07:04:50 2026
Assigning activation ID 1753992092 (0x688bcb9c)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
Successful open of redo thread 1
Thu Feb 26 07:04:50 2026
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Feb 26 07:04:50 2026
SMON: enabling cache recovery
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_8712.trc  (incident=82031):
ORA-00600: internal error code, arguments: [2662], [3910], [1642126020], [3910], [1642126047], [4194432]
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_8712.trc:
ORA-00600: internal error code, arguments: [2662], [3910], [1642126020], [3910], [1642126047], [4194432]
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_8712.trc:
ORA-00600: internal error code, arguments: [2662], [3910], [1642126020], [3910], [1642126047], [4194432]
Error 600 happened during db open, shutting down database
USER (ospid: 8712): terminating the instance due to error 600
Thu Feb 26 07:05:00 2026
Instance terminated by USER, pid = 8712
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (8712) as a result of ORA-1092

4. 尝试重新open库,数据库open成功但是报ORA-600 kturbleurec1、ORA-600 kcbgtcr_13错误,数据库运行一会就直接crash,这个错误一般是由于undo异常导致

Thu Feb 26 07:09:10 2026
alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 23 processes
Started redo scan
Completed redo scan
 read 0 KB redo, 0 data blocks need recovery
Started redo application at
 Thread 1: logseq 1, block 3, scn 16794964253378
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
Completed redo application of 0.00MB
Completed crash recovery at
 Thread 1: logseq 1, block 3, scn 16794964273379
 0 data blocks read, 0 data blocks written, 0 redo k-bytes read
Thu Feb 26 07:09:14 2026
Thread 1 advanced to log sequence 2 (thread open)
Thread 1 opened at log sequence 2
  Current log# 2 seq# 2 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Feb 26 07:09:14 2026
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
Thu Feb 26 07:09:21 2026
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_p002_10096.trc  (incident=84847):
ORA-00600: internal error code, arguments: [kturbleurec1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_84847\orcl_p002_10096_i84847.trc
Thu Feb 26 07:09:21 2026
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_4600.trc  (incident=84831):
ORA-00600: internal error code, arguments: [kcbgtcr_13], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_84831\orcl_ora_4600_i84831.trc
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_4600.trc  (incident=84832):
ORA-00600: internal error code, arguments: [kcbgtcr_13], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_84832\orcl_ora_4600_i84832.trc

客户那边还做了各种恢复尝试,最终依旧无法正常open库,让我这边进行恢复支持.由于客户库不大,而且可以提供数据进行恢复,我让客户发生我数据之后,在本地电脑上进行恢复,下载文件之后,重命名相关路径然后尝试open库

SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-16433: 必须以读/写模式打开数据库。

重建控制文件

C:\Users\XFF>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on 星期五 2月 27 14:36:57 2026

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> startup nomount pfile='d:/pfile.txt'
ORACLE 例程已经启动。

Total System Global Area 4275781632 bytes
Fixed Size                  2182592 bytes
Variable Size             973079104 bytes
Database Buffers         3288334336 bytes
Redo Buffers               12185600 bytes
SQL> @rectl.sql

控制文件已创建。

SQL> recover database;
完成介质恢复。

尝试open库报ORA-600 2663错误

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2663], [3910], [1642323772],
[3910], [1642327019], [], [], [], [], [], [], []
进程 ID: 27296
会话 ID: 14 序列号: 3

使用Patch_SCN工具修改数据库scn
ora-600-2663-patch_scn


再次尝试open数据库

SQL> recover database;
完成介质恢复。
SQL> alter database open ;

数据库已更改。

alert日志报ORA-600 6856错误

Fri Feb 27 14:40:03 2026
QMNC started with pid=62, OS id=18360 
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: alter database open 
Fri Feb 27 14:40:03 2026
Errors in file c:\app\xff\diag\rdbms\orcl\orcl\trace\orcl_p001_21540.trc  (incident=15787):
ORA-00600: 内部错误代码, 参数: [6856], [0], [479], [], [], [], [], [], [], [], [], []
Incident details in: c:\app\xff\diag\rdbms\orcl\orcl\incident\incdir_15787\orcl_p001_21540_i15787.trc
Fri Feb 27 14:40:04 2026
Starting background process CJQ0
Fri Feb 27 14:40:04 2026
CJQ0 started with pid=63, OS id=15592 
Doing block recovery for file 8 block 1541549
Resuming block recovery (PMON) for file 8 block 1541549
Block recovery from logseq 3, block 108 to scn 16794965431265
Recovery of Online Redo Log: Thread 1 Group 3 Seq 3 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\20260227\REDO03.LOG
Block recovery completed at rba 3.16415.16, scn 3910.1643303906
Fri Feb 27 14:40:04 2026
Trace dumping is performing id=[cdmp_20260227144004]
SMON: ignoring slave err,downgrading to serial rollback
Errors in file c:\app\xff\diag\rdbms\orcl\orcl\trace\orcl_smon_21696.trc  (incident=15723):
ORA-00600: 内部错误代码, 参数: [6856], [0], [479], [], [], [], [], [], [], [], [], []
Incident details in: c:\app\xff\diag\rdbms\orcl\orcl\incident\incdir_15723\orcl_smon_21696_i15723.trc
………………
ORACLE Instance orcl (pid = 15) - Error 607 encountered while recovering transaction (3, 10) on object 81310.
Errors in file c:\app\xff\diag\rdbms\orcl\orcl\trace\orcl_smon_21696.trc:
ORA-00607: 当更改数据块时出现内部错误
ORA-00600: 内部错误代码, 参数: [6856], [0], [479], [], [], [], [], [], [], [], [], []
Process debug not enabled via parameter _debug_enable
Trace dumping is performing id=[cdmp_20260227144011]
PMON (ospid: 23760): terminating the instance due to error 474

该错误是undo异常引起,屏蔽掉异常undo之后,正常open,并顺利导出所有数据,完成本次恢复任务
dmp


obet处理ORA-704 ORA-604 ORA-1578故障

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

标题:obet处理ORA-704 ORA-604 ORA-1578故障

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

有客户数据库启动报ORA-704 ORA-604 ORA-1578错误,导致启动失败
ORA-704-ORA-1578


alert日志报错

Fri Feb 06 23:38:43 2026
SMON: enabling cache recovery
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_239325.trc  (incident=1008437):
ORA-01578: ORACLE data block corrupted (file # 1, block # 241)
ORA-01110: data file 1: '+DATADG/orcl/datafile/system.270.1015415183'
Fri Feb 06 23:38:46 2026
Redo thread 2 internally disabled at seq 6 (CKPT)
Archived Log entry 182212 added for thread 2 sequence 5 ID 0xd68b4385 dest 1:
ARC0: Archiving disabled thread 2 sequence 6
Archived Log entry 182213 added for thread 2 sequence 6 ID 0xd68b4385 dest 1:
Thread 1 advanced to log sequence 9 (LGWR switch)
  Current log# 1 seq# 9 mem# 0: +DATADG/orcl/onlinelog/group_1.302.1223816761
  Current log# 1 seq# 9 mem# 1: +ARCHDG/orcl/onlinelog/group_1.257.1223816761
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_239325.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 241)
ORA-01110: data file 1: '+DATADG/orcl/datafile/system.270.1015415183'
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_239325.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 241)
ORA-01110: data file 1: '+DATADG/orcl/datafile/system.270.1015415183'
Error 704 happened during db open, shutting down database
USER (ospid: 239325): terminating the instance due to error 704
Fri Feb 06 23:38:48 2026
Instance terminated by USER, pid = 239325
ORA-1092 signalled during: alter database open...
opiodr aborting process unknown ospid (239325) as a result of ORA-1092
Fri Feb 06 23:38:48 2026
ORA-1092 : opitsk aborting process

对system文件进行dbv检测(客户通过asmcmd cp命令拷贝出来system文件)

DBVERIFY - Verification starting : FILE = /asm_backup/orcl/datafile/SYSTEM.270.1015415183

DBV-00200: Block, DBA 4194545, already marked corrupt
csc(0x0006.d75a0ed7) higher than block scn(0x0000.00000000)
Page 241 failed with check code 6054

DBV-00200: Block, DBA 4306619, already marked corrupt
csc(0x0006.d75a14f4) higher than block scn(0x0000.00000000)
Page 112315 failed with check code 6054


DBVERIFY - Verification complete

Total Pages Examined         : 738560
Total Pages Processed (Data) : 424109
Total Pages Failing   (Data) : 1
Total Pages Processed (Index): 287403
Total Pages Failing   (Index): 1
Total Pages Processed (Other): 3408
Total Pages Processed (Seg)  : 1
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 23640
Total Pages Marked Corrupt   : 2
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 3613010282 (6.3613010282)

这里可以看到有两个block被标记为坏块原因是由于:csc(0×0006.d75a0ed7) higher than block scn(0×0000.00000000),坏块错误代码为:Page 241 failed with check code 6054.这种问题的原因是由于block的scn小于数据块的csc(一般是由于写丢失导致),对于这个问题,最近在obet中刚刚增加了repair blkscn功能进行修复,具体参考:obet修复csc higher than block scn类型坏块,使用工具修复操作(其他block类似修改)

OBET> set filename /datapool/asm_backup/orcl/datafile/SYSTEM.270.1015415183
filename set to: /datapool/asm_backup/orcl/datafile/SYSTEM.270.1015415183

OBET> set block 241
block set to: 241

OBET> backup
Created backup directory: backup_blk
Successfully backed up current block from current file to 
    /tmp/backup_blk/SYSTEM.270.1015415183_241.20260209122822

OBET> repair blkscn

Repairing SCN for block 241...

Current block SCN information:
  scn_base: 0x00000000 (0)
  scn_wrap: 0x0000 (0)

Block 1 reference information:
  hdr_base: 0xD75FF65E (3613390430)
  hdr_wrap: 0x0006 (6)

Current block CSC information:
  csc_base: 0xD75A0ED7 (3613003479)
  csc_wrap: 0x0006 (6)

Calculated values:
  blkcsc: 29382807255 (0x00000006D75A0ED7)
  blkscn: 0 (0x0000000000000000)

blkscn < blkcsc, SCN repair required.

SCN repair requires edit mode.
Please enable edit mode with 'set mode edit' first.

OBET> set mode edit
mode set to: edit

OBET> repair blkscn

Repairing SCN for block 241...

Current block SCN information:
  scn_base: 0x00000000 (0)
  scn_wrap: 0x0000 (0)

Block 1 reference information:
  hdr_base: 0xD75FF65E (3613390430)
  hdr_wrap: 0x0006 (6)

Current block CSC information:
  csc_base: 0xD75A0ED7 (3613003479)
  csc_wrap: 0x0006 (6)

Calculated values:
  blkcsc: 29382807255 (0x00000006D75A0ED7)
  blkscn: 0 (0x0000000000000000)

blkscn < blkcsc, SCN repair required.

New SCN values to write:
  new_scn_base: 0xD75FF65D (3613390429)
  new_scn_wrap: 0x0006 (6)

Confirm SCN repair operations:
File: /datapool/asm_backup/orcl/datafile/SYSTEM.270.1015415183
Block: 241
Operations:
  1. Write new scn_base (0xD75FF65D)
  2. Write new scn_wrap (0x0006)
  3. Fix seq_kcbh (0xFF -> 0x01)

Confirm? (Y/YES to proceed): y

[Undo information saved - use 'undo' command to restore original values]

Verification after SCN repair:
1. scn_base: 5DF65FD7 (expected: 5DF65FD7)
2. scn_wrap: 0600 (expected: 0600)
3. seq_kcbh: 0x01 OK

Block 241 SCN repair completed successfully.
Execute tailchk apply and sum apply for this block.

OBET> tailchk apply

Confirm applying tailchk:
File: /datapool/asm_backup/orcl/datafile/SYSTEM.270.1015415183
Block: 241
Offset in block: 8188 (file offset: 0x001E3FFC)
Original value: 0xFF060000
New value:      0x01065DF6
Confirm? (Y/YES to proceed): y
Verification successful: Stored tailchk matches calculated value (0x01065DF6).
Tailchk applied successfully.

OBET> sum apply

Confirm applying checksum:
File: /datapool/asm_backup/orcl/datafile/SYSTEM.270.1015415183
Block: 241
Offset in block: 16 (file offset: 0x001E2010)
Original value: 0x7330
New value:      0x2AE7
Confirm? (Y/YES to proceed): y
Verification successful: Stored checksum matches calculated value (0x2AE7).
Checksum applied successfully.

然后dbv检查数据文件

[oracle@db4 tmp]$ dbv file=/datapool/asm_backup/orcl/datafile/SYSTEM.270.1015415183

DBVERIFY: Release 11.2.0.4.0 - Production on Mon Feb 9 20:37:54 2026

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

DBVERIFY - Verification starting : FILE =
         /datapool/asm_backup/orcl/datafile/SYSTEM.270.1015415183


DBVERIFY - Verification complete

Total Pages Examined         : 738560
Total Pages Processed (Data) : 424109
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 287403
Total Pages Failing   (Index): 1
Total Pages Processed (Other): 3408
Total Pages Processed (Seg)  : 1
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 23640
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 3613451063 (6.3613451063)

然后直接顺利打开数据库

SQL> alter database open;

Database altered.

由于该库在我接手之前已经做了大量的强制拉库等各种恢复尝试,因此对该库做逻辑导出,导入新库完成本次恢复任务

ORA-600 kcratr_nab_less_than_odr和ORA-600 4193故障处理

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

标题:ORA-600 kcratr_nab_less_than_odr和ORA-600 4193故障处理

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

数据库启动报ORA-600 kcratr_nab_less_than_odr

alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 15 processes
Started redo scan
Completed redo scan
 read 2930 KB redo, 1357 data blocks need recovery
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_19096.trc  (incident=576634):
ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [7859], [62180], [63172], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\incident\incdir_576634\orcl_ora_19096_i576634.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Aborting crash recovery due to error 600
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_19096.trc:
ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [7859], [62180], [63172], [], [], [], [], [], [], []
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_19096.trc:
ORA-00600: ??????, ??: [kcratr_nab_less_than_odr], [1], [7859], [62180], [63172], [], [], [], [], [], [], []
ORA-600 signalled during: alter database open...

这个错误一般常见的是11.2.0.1的数据库异常关机了容易遇到
又一例ORA-600 kcratr_nab_less_than_odr
ORA-600 kcratr_nab_less_than_odr故障解决
这个客户是11.2.0.4的库(在这个版本中该错误相对较少,虽然也遇到过几次)
11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
分析日志发现是由于之前io比较慢导致写入异常导致

Fri Feb 06 00:32:59 2026
********************* ATTENTION: ******************** 
 The controlfile header block returned by the OS
 has a sequence number that is too old. 
 The controlfile might be corrupted.
 PLEASE DO NOT ATTEMPT TO START UP THE INSTANCE 
 without following the steps below.
 RE-STARTING THE INSTANCE CAN CAUSE SERIOUS DAMAGE 
 TO THE DATABASE, if the controlfile is truly corrupted.
 In order to re-start the instance safely, 
 please do the following:
 (1) Save all copies of the controlfile for later 
     analysis and contact your OS vendor and Oracle support.
 (2) Mount the instance and issue: 
     ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
 (3) Unmount the instance. 
 (4) Use the script in the trace file to
     RE-CREATE THE CONTROLFILE and open the database. 
*****************************************************
CKPT (ospid: 2600): terminating the instance
Fri Feb 06 00:33:00 2026
System state dump requested by (instance=1, osid=2600 (CKPT)), summary=[abnormal instance termination].
System State dumped to trace file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_diag_2488_20260206003300.trc
Fri Feb 06 00:33:01 2026
opiodr aborting process unknown ospid (3420) as a result of ORA-1092

处理这个错误相对比较简单,重建控制文件即可
11


但是后续数据库出现ORA-600 4193错误

Fri Feb 06 02:57:34 2026
ALTER DATABASE OPEN
Thread 1 opened at log sequence 7860
  Current log# 1 seq# 7860 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO01.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
[4044] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:5166812 end:5167140 diff:328 (3 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_smon_3868.trc  (incident=640589):
ORA-00600: 内部错误代码, 参数: [4193], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\incident\incdir_640589\orcl_smon_3868_i640589.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Starting background process QMNC
Fri Feb 06 02:57:36 2026
QMNC started with pid=21, OS id=5008 
Completed: ALTER DATABASE OPEN
Fri Feb 06 02:57:37 2026
db_recovery_file_dest_size of 4182 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Block recovery from logseq 7860, block 132954 to scn 55142160294
Recovery of Online Redo Log: Thread 1 Group 1 Seq 7860 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO01.LOG
Block recovery completed at rba 7860.132998.16, scn 12.3602552743
Block recovery from logseq 7860, block 132954 to scn 55142160257
Recovery of Online Redo Log: Thread 1 Group 1 Seq 7860 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO01.LOG
Block recovery completed at rba 7860.132954.16, scn 12.3602552707
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_smon_3868.trc:
ORA-01595: 释放区 (5) 回退段 (21) 时出错
ORA-00600: 内部错误代码, 参数: [4193], [], [], [], [], [], [], [], [], [], [], []
Flush retried for xcb 0x96c82600, pmd 0x8c6a70b8
Block recovery from logseq 7860, block 132954 to scn 55142160294
Recovery of Online Redo Log: Thread 1 Group 1 Seq 7860 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO01.LOG
Block recovery completed at rba 7860.132998.16, scn 12.3602552743
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_pmon_2728.trc:
ORA-00600: 内部错误代码, 参数: [4193], [], [], [], [], [], [], [], [], [], [], []
PMON (ospid: 2728): terminating the instance due to error 472
System state dump requested by (instance=1, osid=2728 (PMON)), summary=[abnormal instance termination].
Fri Feb 06 02:58:17 2026
Instance terminated by PMON, pid = 2728

这个错误相对比较简单,由于undo回滚段异常,处理掉异常undo之后,数据库正常,完成本次恢复任务

aix环境10g由于控制器异常导致ORA-600 4000故障处理

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

标题:aix环境10g由于控制器异常导致ORA-600 4000故障处理

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

一台运行在aix环境下面的10.2.0.1的数据库
version


由于控制器异常导致数据库启动的时候报ORA-600 4000错误

Wed Jan 28 18:17:06 2026
Completed crash recovery at
 Thread 1: logseq 499321, block 14459, scn 17457591400427
 257 data blocks read, 41 data blocks written, 14457 redo blocks read
Wed Jan 28 18:17:06 2026
Thread 1 advanced to log sequence 499322
Thread 1 opened at log sequence 499322
  Current log# 2 seq# 499322 mem# 0: /dev/rrk_redo2
Successful open of redo thread 1
Wed Jan 28 18:17:06 2026
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Jan 28 18:17:06 2026
SMON: enabling cache recovery
Wed Jan 28 18:17:07 2026
Errors in file /u01/app/oracle/admin/orcl1/udump/orcl1_ora_16187632.trc:
ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], []
Wed Jan 28 18:17:08 2026
Errors in file /u01/app/oracle/admin/orcl1/udump/orcl1_ora_16187632.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], []
Wed Jan 28 18:17:08 2026
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 16187632
ORA-1092 signalled during: alter database open...

ORA-600 4000这个是在10g版本中非常常见的一个错误,一般是由于对应的block上面有事务没有提交或者scn过大导致,跟踪数据库启动过程发现在以下sql语句报错,而且报错为file 1 block 27527

EXEC #2:c=0,e=62,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=437860213380
WAIT #2: nam='db file sequential read' ela= 139 file#=1 block#=27527 blocks=1 obj#=-1 tim=437860213555
*** 2026-01-31 15:31:40.417
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], []
Current SQL statement for this session:
select rowcnt,blkcnt,empcnt,avgspc,chncnt,avgrln,nvl(degree,1), nvl(instances,1) from tab$ where obj# = :1

这里可以获取到两个有效信息:
1. 报错block为:file 1 block 27227
2. 报错sql为:select rowcnt,blkcnt,empcnt,avgspc,chncnt,avgrln,nvl(degree,1), nvl(instances,1) from tab$ where obj# = :1

进一步对报错数据块进行分析

Block header dump:  0x00406b87
 Object id on Block? Y
 seg/obj: 0x2  csc: 0xfe0.a99d3719  itc: 2  flg: -  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000b.014.00f1bb09  0x008027a5.eada.0e  C---    0  scn 0x0fda.f353b198
0x02   0x0009.01e.00212e2a  0x01400cdf.113e.01  --U-    1  fsc 0x0000.a99d371b

这里可以确认几个有效信息:
1. 该block的csc scn为:17457592743705
2. 一条已经提交的事务的scn为:17433059635608
3. 还有一条没有提交的事务,使用的回滚段为9,这个和我们报错的ORA-600[4000][9]这个回滚段名称匹配上

基于上述分析,我们需要确认两件事情:
1. 通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本检查结果,确认当前是数据库的文件头scn为:17457591420434小于该block的csc scn
chk


2. itl操上面有一个锁需要提交,通过bbed工具对其进行提交,然后得出dump block信息

Block header dump:  0x00406b87
 Object id on Block? Y
 seg/obj: 0x2  csc: 0xfe0.a99d3719  itc: 2  flg: -  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000b.014.00f1bb09  0x008027a5.eada.0e  C---    0  scn 0x0fda.f353b198
0x02   0x0009.01e.00212e2a  0x01400cdf.113e.01  C---    0  scn 0x0000.a99d371b

修改好itl之后,先尝试重启库,如果不出意外应该会报ORA-600 2662类似错误(因为前面分析了csc scn大于文件头scn的问题)
2662


这里的ORA-600 2662中的4221831就是报错的rdba地址(10进制),通过dbms_utility.data_block_address_file转换

SQL> select dbms_utility.data_block_address_file(4221831) "file",
  2  dbms_utility.data_block_address_block(4221831) "block"
  3   from dual;

      file      block
---------- ----------
         1      27527

得出报错的ORA-600 2662的block就是我们之前分析和修复的itl块,通过修改该块scn或者修改数据库scn,该库均可open,后续就是安排导出数据导入新库的活

ORA-600 3716故障处理

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

标题:ORA-600 3716故障处理

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

数据库由于ORA-600 kcvent_intcic_zero_half错误导致实例重启

Reconfiguration started (old inc 8, new inc 10)
List of instances:
 1 2 (myinst: 2) 
 Nested reconfiguration detected. 
 Global Resource Directory frozen
 Communication channels reestablished
 * domain 0 valid = 1 according to instance 1 
 Master broadcasted resource hash value bitmaps
 Non-local Process blocks cleaned out
 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
 Set master node info 
 Submitted all remote-enqueue requests
 Dwn-cvts replayed, VALBLKs dubious
 All grantable enqueues granted
Fri Jan 30 22:07:08 2026
minact-scn: Master returning as live inst:1 has inc# mismatch instinc:0 cur:10 errcnt:0
 Submitted all GCS remote-cache requests
 Fix write in gcs resources
Reconfiguration complete
Fri Jan 30 22:07:17 2026
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ckpt_1748.trc  (incident=228496):
ORA-00600: internal error code, arguments: [kcvent_intcic_zero_half], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle11g/diag/rdbms/hisdb/hisdb2/incident/incdir_228496/hisdb2_ckpt_1748_i228496.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ckpt_1748.trc:
ORA-00600: internal error code, arguments: [kcvent_intcic_zero_half], [], [], [], [], [], [], [], [], [], [], []
CKPT (ospid: 1748): terminating the instance due to error 469
Fri Jan 30 22:07:18 2026
ORA-1092 : opitsk aborting process
Fri Jan 30 22:07:19 2026
System state dump requested by (instance=2, osid=1748 (CKPT)), summary=[abnormal instance termination].

初步分析该错误是由于oracle bug引起,在11.2.0.4版本中比较少见,主要常见于19c版本中
kcvent_intcic_zero_half


正常情况下,实例重启即可,这个客户比较不幸,数据库重启遭遇ORA-600 3716错误

ALTER DATABASE OPEN /* db agent *//* {0:11:28647} */
This instance was first to open
Beginning crash recovery of 2 threads
 parallel recovery started with 15 processes
Started redo scan
Completed redo scan
 read 1120 KB redo, 386 data blocks need recovery
Started redo application at
 Thread 2: logseq 847, block 641786
Recovery of Online Redo Log: Thread 2 Group 3 Seq 847 Reading mem 0
  Mem# 0: +DATADISK/hisdb/onlinelog/group_3.267.1109863469
  Mem# 1: +ARCHIVEDISK/hisdb/onlinelog/group_3.261.1109863469
Completed redo application of 0.38MB
Completed crash recovery at
 Thread 2: logseq 847, block 644027, scn 20674490933
 386 data blocks read, 0 data blocks written, 1120 redo k-bytes read
ARCH: STARTING ARCH PROCESSES
Fri Jan 30 22:07:47 2026
ARC0 started with pid=53, OS id=332 
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Fri Jan 30 22:07:48 2026
ARC1 started with pid=54, OS id=364 
Fri Jan 30 22:07:48 2026
ARC2 started with pid=55, OS id=366 
Fri Jan 30 22:07:48 2026
ARC3 started with pid=56, OS id=368 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ora_29981.trc  (incident=240679):
ORA-00600: ??????, ??: [3716], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle11g/diag/rdbms/hisdb/hisdb2/incident/incdir_240679/hisdb2_ora_29981_i240679.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Abort recovery for domain 0
Aborting crash recovery due to error 600
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ora_29981.trc:
ORA-00600: ??????, ??: [3716], [], [], [], [], [], [], [], [], [], [], []
Abort recovery for domain 0
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ora_29981.trc:
ORA-00600: ??????, ??: [3716], [], [], [], [], [], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE OPEN /* db agent *//* {0:11:28647} */...

接手客户故障尝试启动数据库也报ORA-600 3716错误

SQL> startup
ORACLE instance started.

Total System Global Area 2.0176E+10 bytes
Fixed Size                  2261928 bytes
Variable Size            3288337496 bytes
Database Buffers         1.6844E+10 bytes
Redo Buffers               41463808 bytes
Database mounted.
ORA-00600: internal error code, arguments: [3716], [], [], []

根据官方描述该问题
open


那解决该问题相对比较简单

SQL>@rectl.sql

Control file created.
SQL> recover database;
Media recovery complete.
SQL> alter database open;

Database altered.

完美恢复这次故障,实现数据0丢失,业务直接使用

不当恢复truncate数据导致数据库不能open处理

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

标题:不当恢复truncate数据导致数据库不能open处理

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

有客户误truncate操作干掉了数据库中的几张表,然后尝试通过FY_Recover_Data进行恢复,恢复到一半然后终止了,数据库结果就起不来了(具体什么原因不知道,肯定是各种不合适的操作引起的故障),我接手故障的时候,数据库被强制resetlogs,报ORA-600 2662错误

Fri Jan 30 10:24:16 2026
alter database open resetlogs
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 49708968810
Clearing online redo logfile 1 /u01/oracle/oradata/orcl/redo01.log
Clearing online log 1 of thread 1 sequence number 1069648
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /u01/oracle/oradata/orcl/redo02.log
Clearing online log 2 of thread 1 sequence number 1069649
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /u01/oracle/oradata/orcl/redo03.log
Clearing online log 3 of thread 1 sequence number 1069647
Clearing online redo logfile 3 complete
Resetting resetlogs activation ID 1738690566 (0x67a25006)
Online log /u01/oracle/oradata/orcl/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/oracle/oradata/orcl/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/oracle/oradata/orcl/redo03.log: Thread 1 Group 3 was previously cleared
Fri Jan 30 10:24:17 2026
Setting recovery target incarnation to 3
Fri Jan 30 10:24:17 2026
Assigning activation ID 1751706121 (0x6868ea09)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u01/oracle/oradata/orcl/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Jan 30 10:24:17 2026
SMON: enabling cache recovery
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc  (incident=123363):
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328561], [11], [2464328917], [12583040], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl/incident/incdir_123363/orcl_ora_14707_i123363.trc
Fri Jan 30 10:24:18 2026
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc:
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328561], [11], [2464328917], [12583040], [], [], [], []
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc:
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328561], [11], [2464328917], [12583040], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 14707): terminating the instance due to error 600
Instance terminated by USER, pid = 14707
ORA-1092 signalled during: alter database open resetlogs...
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc:
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328564], [11], [2464328917], [12583040], [], [], [], []
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328563], [11], [2464328917], [12583040], [], [], [], []
ORA-01092: ORACLE 实例终止。强制断开连接
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328561], [11], [2464328917], [12583040], [], [], [], []
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc:
ORA-27300: 操作系统系统相关操作: semctl 失败, 状态为: 22
ORA-27301: 操作系统故障消息: Invalid argument
ORA-27302: 错误发生在: sskgpwpost1
ORA-27303: 附加信息: semid = 32779
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328564], [11], [2464328917], [12583040], [], [], [], []
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328563], [11], [2464328917], [12583040], [], [], [], []
ORA-01092: ORACLE 实例终止。强制断开连接
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [11], [2464328564], [11], [2464328917], [12583040], []
ORA-00600: internal error code, arguments: [2662], [11], [2464328563], [11], [2464328917], [12583040], []
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [11], [2464328561], [11], [2464328917], [12583040], []

通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本检查发现有文件被offline,且resetlogs 信息不对
resetlogs


通过obet工具(Oracle数据块编辑工具( Oracle Block Editor Tool)-obet)对resetlogs相关信息进行修改

OBET> set mode edit
mode set to: edit

OBET> set file 18
filename set to: /tmp/FY_RST_DATA.DAT (file#18)

OBET> copy resetlogscn file 1 to file 18

Confirm Modify resetlogscn:
Source: file#1 (/u01/oracle/oradata/orcl/system01.dbf)
Target: file#18 (/tmp/FY_RST_DATA.DAT)
Proceed? (Y/YES to confirm): y
Successfully copied resetlog SCN information from file#1 to file#18.

OBET> copy chkscn file 1 to file 18

Confirm Modify chkscn:
Source: file#1 (/u01/oracle/oradata/orcl/system01.dbf)
Target: file#18 (/tmp/FY_RST_DATA.DAT)
Proceed? (Y/YES to confirm): y
Successfully copied checkpoint SCN information from file#1 to file#18.

OBET> sum
Check value for File /tmp/FY_RST_DATA.DAT, Block 1:
current = 0xF8EA, required = 0xFCEA

OBET> sum check
Warning: Unknown option 'check', ignored
Check value for File /tmp/FY_RST_DATA.DAT, Block 1:
current = 0xF8EA, required = 0xFCEA

OBET> sum apply

Confirm applying checksum:
File: /tmp/FY_RST_DATA.DAT
Block: 1
Offset in block: 16 (file offset: 0x00002010)
Original value: 0xF8EA
New value:      0xFCEA
Confirm? (Y/YES to proceed): y
Verification successful: Stored checksum matches calculated value (0xFCEA).
Checksum applied successfully.

然后尝试打开库,报ORA-600 kdourp_inorder2错误

Database Characterset is ZHS16GBK
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_9198.trc  (incident=159324):
ORA-00600: internal error code, arguments: [kdourp_inorder2], [16], [0], [146], [108], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl/incident/incdir_159324/orcl_smon_9198_i159324.trc
Stopping background process MMNL
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Block recovery from logseq 2, block 39 to scn 49708988852
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: /u01/oracle/oradata/orcl/redo02.log
Block recovery completed at rba 2.42.16, scn 11.2464348597
ORACLE Instance orcl (pid = 14) - Error 600 encountered while recovering transaction (14, 8) on object 14.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_9198.trc:
ORA-00600: internal error code, arguments: [kdourp_inorder2], [16], [0], [146], [108], [], [], [], [], []
Stopping background process MMON
Fri Jan 30 11:42:26 2026
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_9198.trc  (incident=159325):
ORA-00600: internal error code, arguments: [kdourp_inorder2], [16], [0], [146], [108], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl/incident/incdir_159325/orcl_smon_9198_i159325.trc
Starting background process MMON
Fri Jan 30 11:42:27 2026
MMON started with pid=49, OS id=10684
Starting background process MMNL
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Block recovery from logseq 2, block 39 to scn 49708988852
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: /u01/oracle/oradata/orcl/redo02.log
Block recovery completed at rba 2.42.16, scn 11.2464348597
ORACLE Instance orcl (pid = 14) - Error 600 encountered while recovering transaction (14, 8) on object 14.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_9198.trc:
ORA-00600: internal error code, arguments: [kdourp_inorder2], [16], [0], [146], [108], [], [], [], [], []

该报错比较明显是由于undo回滚段异常导致,通过屏蔽回滚段,open库成功.后续对客户truncate的表进行分析,比较悲催由于没有第一时间保护现场而且对所在表空间进行了大量写入操作,导致truncate数据恢复较少.

Patch_SCN快速解决ORA-600 2663故障

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

标题:Patch_SCN快速解决ORA-600 2663故障

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

一个维保客户和我说他们测试库删除了日志文件导致库无法启动,让我帮忙看看
客户现场现况
1. 磁盘空间使用100%

[oracle@We1-db_Test ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           3.9G  880K  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/vda1        40G   38G   92M 100% /
tmpfs           783M     0  783M   0% /run/user/0

2. 数据库redo被删除了部分,而且是active状态的被删除

[oracle@We1-db_Test ~]$ ls -l /opt/app/oracle/oradata/orcl/redo0*
-rw-r----- 1 oracle oinstall 52429312 Jan 15 15:29 /opt/app/oracle/oradata/orcl/redo04.log
-rw-r----- 1 oracle oinstall 52429312 Jan 15 16:26 /opt/app/oracle/oradata/orcl/redo05.log

SQL> select group#,SEQUENCE#,STATUS FROM V$lOG;

    GROUP#  SEQUENCE# STATUS
---------- ---------- ----------------
         1       8989 CURRENT
         2          0 UNUSED
         5          0 UNUSED
         4          0 UNUSED
         3       8988 ACTIVE

SQL> select member from v$logfile;

MEMBER
-----------------------------------------------------
/opt/app/oracle/oradata/orcl/redo03.log
/opt/app/oracle/oradata/orcl/redo02.log
/opt/app/oracle/oradata/orcl/redo01.log
/opt/app/oracle/oradata/orcl/redo04.log
/opt/app/oracle/oradata/orcl/redo05.log

基于当前情况,直接open库无望,但是空间不足问题需要先解决,不然恢复过程中创建redo空间不足依旧会报错卡死,所以先清理了监听和alert等日志,系统空闲了3G多空间,可以进行恢复操作

[oracle@We1-db_Test trace]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           3.9G  880K  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/vda1        40G   34G  3.9G  90% /
tmpfs           783M     0  783M   0% /run/user/0

恢复数据库
1. 由于active redo丢失,毫无疑问,直接强制拉库,使用_allow_resetlogs_corruption参数开干

SQL> startup mount pfile='/tmp/pfile';
ORACLE instance started.

Total System Global Area 2455228416 bytes
Fixed Size                  2255712 bytes
Variable Size             905970848 bytes
Database Buffers         1526726656 bytes
Redo Buffers               20275200 bytes
Database mounted.
SQL> recover database until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done


SQL> recover database using backup controlfile;
ORA-00279: change 311982775 generated at 12/31/2025 17:35:11 needed for thread
1
ORA-00289: suggestion :
/opt/app/oracle/fast_recovery_area/ORCL/archivelog/2026_01_16/o1_mf_1_8988_%u_.a
rc
ORA-00280: change 311982775 for thread 1 is in sequence #8988


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0],
[311982833], [], [], [], [], [], [], []
Process ID: 11917
Session ID: 576 Serial number: 3

alert日志报错

Fri Jan 16 21:25:31 2026
Assigning activation ID 1750515127 (0x6856bdb7)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /opt/app/oracle/oradata/orcl/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Jan 16 21:25:31 2026
SMON: enabling cache recovery
Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc  (incident=81753):
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []
Incident details in: /opt/app/oracle/diag/rdbms/orcl/we1db/incident/incdir_81753/we1db_ora_11917_i81753.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc:
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []
Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc:
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 11917): terminating the instance due to error 600
Instance terminated by USER, pid = 11917
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (11917) as a result of ORA-1092
Fri Jan 16 21:25:33 2026
ORA-1092 : opitsk aborting process

不幸数据库遇到ORA-600 2663错误,这个故障在以前的文章中描述过,基本上和ORA-600 2662的处理思路类似,这里直接使用:Patch_SCN for Linux进行恢复
2. 使用Patch_SCN处理数据库SCN

SQL> startup nomount pfile='/tmp/pfile';
ORACLE instance started.

Total System Global Area 2455228416 bytes
Fixed Size                  2255712 bytes
Variable Size             905970848 bytes
Database Buffers         1526726656 bytes
Redo Buffers               20275200 bytes
SQL>@rectl

Control file created.

SQL> recover database;
Media recovery complete.

patch_scn


SQL> alter database open;

Database altered.
SQL> SELECT CURRENT_SCN FROM V$DATABASE;

     CURRENT_SCN
----------------
       322002903

到这里完成数据库open操作,后续逻辑导出完成恢复任务

obet快速修改scn/resetlogs恢复数据库(缺少归档,ORA-00308)

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

标题:obet快速修改scn/resetlogs恢复数据库(缺少归档,ORA-00308)

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

最初是由于业务系统报ORA-01578导致
blk


然后相关人员上来进行了一系列操作,包括但不限于offline文件,create datafile 44,recover datafile,还尝试做resetlogs,使用备份控制文件还原等等.我接手该故障的时候状态
resetlog
44号文件状态是12月1日的,而且resetlogs信息也不对.通过和客户沟通,确认是他们在没有备份44号文件的前提下直接执行了类似alter database create datafile 44的命令,但是在应用了写归档之后,发现提示有归档不存在

ALTER DATABASE RECOVER    CONTINUE DEFAULT
Media Recovery Log /data/app/oracle/archive/orcl/1_181285_1103629544.dbf
ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
ALTER DATABASE RECOVER    CONTINUE DEFAULT
Media Recovery Log /data/app/oracle/archive/orcl/1_181286_1103629544.dbf
Tue Jan 06 12:48:12 2026
Errors with log /data/app/oracle/archive/orcl/1_181286_1103629544.dbf
Errors in file /data/app/oracle/diag/rdbms/orcl8/orcl/trace/orcl_pr00_8338.trc:
ORA-00308: cannot open archived log '/data/app/oracle/archive/orcl/1_181286_1103629544.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

分析现存归档,确实发现12月1日之后丢失了部分归档日志(归档不连续)
arch


基于这种情况(故障数据文件直接被覆盖,归档又出现了多天的连续断档,而且没有有效备份),只能先打开数据库,然后根据情况导出数据,然后导入到新库中.这里我直接使用obet来修改resetlogs和checkpoint 信息,实现数据库快速打开

OBET> help
OBET (Oracle Block Editor Tool) commands:
  open <config_file>    - Load file list from config file (format: <num> <path>)
  info                  - Show loaded file list (from open command)
  set filename <path>   - Set target file path (required)
  set file <num>        - Set filename using loaded file number (from open list)
  set blocksize <size>  - Set block size (2048,4096,[8192],16384,32768)
  set block <num>       - Set block number (starts from 0, default: 1)
  set offset <offset>   - Set offset within block (< blocksize, default: 0)
  set count <bytes>     - Set number of bytes to read (default: 32)
  set mode edit/browse  - Enable edit/browse mode
  d/dump [options]      - Display data (options: block X, offset Y, count N)
  m/modify <hex> [opts] - Modify data with hex (opts: block X, offset Y)
  undo                  - Undo last modification
  sum [block X]         - Calculate checksum for block (default: current block)
  sum apply [block X]   - Apply checksum: write calculated value to block
  tailchk [block X]     - Calculate tailchk for block (default: current block)
  tailchk apply [block X] - Apply tailchk: write calculated value to block
  repair [block X]      - Repair bad block (fix seq_kcbh, tailchk, checksum)
  copy data <src> to <dest>  - Copy data between files
    <src> format: file,block,offset,count (e.g., 1,1,10,64)
    <dest> format: file[,block][,offset] (e.g., 3 or 3,1 or 3,1,128)
  copy block file#,block# to file#,block#     - Copy entire data block
  copy chkscn file n to file m         - Copy datafile header checkpoint SCN info
  copy resetlogscn file n to file m    - Copy datafile header resetlogs info
  backup [file n] [block m] - Backup data block (optional file and block parameters)
  corrupt [block X]     - Mark block as corrupted (default: current block)
  show                  - Display current settings (filename, blocksize, block, offset, count, mode)
  license               - Show/manage software license (registration code required)
  version               - Show software version and developer information
  p/print <param>       - Print Oracle structure,Use the 'p/print' command to see details
  undo                  - Undo the last copy chkscn or copy resetlogscn operation
  spool <file>          - Start logging to file (spool off to stop)
  help                  - Show this help message
  quit/exit             - Exit OBET

OBET> open 1.txt                 
Loaded 2 files from config file '1.txt'.

OBET> info

Loaded files (2 total):
----------------------------------------
Number  Path
----------------------------------------
     1  /data/app/oracle/oradata/orcl/system01.dbf
    44  /data/app/oracle/oradata/orcl/xff26.dbf
----------------------------------------

OBET> set file 44
filename set to: /data/app/oracle/oradata/orcl/xff26.dbf (file#44)

OBET> d

File: /data/app/oracle/oradata/orcl/xff26.dbf
Block: 1                Offsets:     0 to    31
--------------------------------------------------------------------------------
0xifenfei000 0BA20000 0100000B 00000000 00000104 B05F0000 00000000 0004200B 65583D61 

<32 bytes read>


OBET> backup file 44 block 1
Created backup directory: backup_blk
Successfully backed up block 1 from file#44 to /tmp/backup_blk/xff26.dbf_1.20260106182405

OBET> copy resetlogscn file 1 to file 44
Error: Edit mode not enabled. Use 'set mode edit' first.

OBET> set mode edit     
mode set to: edit

OBET> copy resetlogscn file 1 to file 44

Confirm Modify resetlogscn:
Source: file#1 (/data/app/oracle/oradata/orcl/system01.dbf)
Target: file#44 (/data/app/oracle/oradata/orcl/xff26.dbf)
Proceed? (Y/YES to confirm): y
Successfully copied resetlog SCN information from file#1 to file#44.

OBET> copy chkscn file 1 to file 44

Confirm Modify chkscn:
Source: file#1 (/data/app/oracle/oradata/orcl/system01.dbf)
Target: file#44 (/data/app/oracle/oradata/orcl/xff26.dbf)
Proceed? (Y/YES to confirm): y
Successfully copied checkpoint SCN information from file#1 to file#44.

OBET> tailchk
Check tailchk for File /data/app/oracle/oradata/orcl/xff26.dbf, Block 1:
current = 0x010B0000, required = 0x010B0000

OBET> sum
Check value for File /data/app/oracle/oradata/orcl/xff26.dbf, Block 1:
current = 0xB05F, required = 0x6DA3

OBET> sum apply

Confirm applying checksum:
File: /data/app/oracle/oradata/orcl/xff26.dbf
Block: 1
Offset in block: 16 (file offset: 0x0xifenfei010)
Original value: 0xB05F
New value:      0x6DA3
Confirm? (Y/YES to proceed): y
Verification successful: Stored checksum matches calculated value (0x6DA3).
Checksum applied successfully.

然后重建ctl正常打开数据库

[oracle@xifenfei check_db]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Tue Jan 6 18:29:22 2026

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup mount pfile='/tmp/pfile';
ORACLE instance started.

Total System Global Area 6.8413E+10 bytes
Fixed Size		    2270360 bytes
Variable Size		 3.3554E+10 bytes
Database Buffers	 3.4762E+10 bytes
Redo Buffers		   93585408 bytes
Database mounted.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01190: control file or data file 1 is from before the last RESETLOGS
ORA-01110: data file 1: '/data/app/oracle/oradata/orcl/system01.dbf'


SQL> shutdown immediate;
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.
SQL> 
SQL> 
SQL> startup nomount pfile='/tmp/pfile
';
ORACLE instance started.

Total System Global Area 6.8413E+10 bytes
Fixed Size		    2270360 bytes
Variable Size		 3.3554E+10 bytes
Database Buffers	 3.4762E+10 bytes
Redo Buffers		   93585408 bytes
SQL> @ctl.sql

Control file created.

SQL> SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-00264: no recovery required


SQL> alter database open;

Database altered.

后续根据情况选择导出表,对于导出报错的表再进行二次处理.