分类目录归档：数据库

Patch_SCN快速修复ORA-01555数据库open故障

发表于 2026 年 7 月 26 日 由 惜分飞

有一个朋友在线把数据文件拷贝走,然后发现异常又拷贝回来,结果再重启库发现数据库无法正常启动,尝试强制拉库

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 1046834263 generated at 07/24/2026 22:04:11 needed for thread
1
ORA-00289: suggestion : /data02/archivelog/reybtstg/1_1755_1147617488.dbf
ORA-00280: change 1046834263 for thread 1 is in sequence #1755


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/app/oracle/oradata/reybtstg/system01.dbf'

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 10 with name
"_SYSSMU10_1197734989$" too small
Process ID: 298308
Session ID: 613 Serial number: 3

alert日志报错信息

ARC0: STARTING ARCH PROCESSES COMPLETE
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /data02/reybtstg/oradata/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Jul 25 14:15:34 2026
SMON: enabling cache recovery
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.3e656c5d):
select ctime, mtime, stime from obj$ where obj# = :1
Errors in file /u01/app/oracle/diag/rdbms/reybtstg/reybtstg/trace/reybtstg_ora_298308.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 10 with name "_SYSSMU10_1197734989$" too small
Errors in file /u01/app/oracle/diag/rdbms/reybtstg/reybtstg/trace/reybtstg_ora_298308.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 10 with name "_SYSSMU10_1197734989$" too small
Error 704 happened during db open, shutting down database
USER (ospid: 298308): terminating the instance due to error 704
Instance terminated by USER, pid = 298308
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (298308) as a result of ORA-1092
Sat Jul 25 14:15:35 2026
ORA-1092 : opitsk aborting process

这个错误比较好处理只要修改Oracle scn即可,使用Patch_SCN for Linux进行修改

---会话1
[oracle@xff ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Sat Jul 25 14:21:11 2026

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

Connected to an idle instance.

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

Total System Global Area 6.4137E+10 bytes
Fixed Size		    2269072 bytes
Variable Size		 1.5569E+10 bytes
Database Buffers	 4.8318E+10 bytes
Redo Buffers		  246980608 bytes
SQL> @/tmp/rectl

Control file created.

---会话2
[oracle@xff tmp]$ ./Patch_SCN -h
Usage:
  Software License:       ./Patch_SCN -key
  Get Oracle SPID:        ./Patch_SCN -spid
  Get SCN address:        ./Patch_SCN -addr
  Automatic address mode: ./Patch_SCN <spid> <new_value>
  Manual address mode:    ./Patch_SCN <spid> <address> <new_value>
  Where:
    <spid> - Oracle process ID
    <address> - Memory address (hexadecimal)
    <new_value> - SCN value to modify (decimal or hexadecimal)
[oracle@xff tmp]$ ./Patch_SCN -spid

Found 3 Oracle LOCAL=YES processes: 283668  283670  305036  

Process Details:
UID        PID  PPID  C STIME TTY          TIME CMD
oracle   283668 283627  0 Jul18 ?        00:15:10 oracletesta (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   283670 283627  0 Jul18 ?        00:35:25 oracletesta (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   305036 304678  0 14:21 ?        00:00:00 oracleorcltg (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
[oracle@xff tmp]$ ./Patch_SCN 305036 1146834263
Successfully obtained address automatically: 0x6001ae70
Original Oracle SCN at Address 0x6001ae70: 0x0
Are you sure you want to modify Oracle SCN? (yes/no): yes
New SCN at Address 0x6001ae70: 0x445b4d57
Oracle SCN successfully modified.

数据库正常打开

----会话1
SQL> recover database;
Media recovery complete.
SQL> alter database open ;

Database altered.

SQL>

完成本次数据库恢复工作.

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

快速处理 ORA-01210: data file header is media corrupt 故障

发表于 2026 年 7 月 24 日 由 惜分飞

客户反馈硬件故障之后,数据库无法正常启动，尝试recover操作报ORA-01122错误

SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-01122: 数据库文件 1 验证失败
ORA-01110: 数据文件 1: 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\SYSTEM01.DBF'
ORA-01207: 文件比控制文件更新 - 旧的控制文件

这个错误比较明显，由于数据文件的checkpoint信息比数据文件 file# 1新，通过重建ctl可以进行解决

SQL> @rectl.sql
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS FORCE LOGGING ARCHIVELOG
*
第 1 行出现错误:
ORA-01503: CREATE CONTROLFILE failed
ORA-01210: data file header is media corrupt
ORA-01110: data file 42: 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\XFF.DBF'

但是这里遭遇到ORA-01210错误

[oracle@iZbp11c0qyuuo1gr7j98upZ ~]$ oerr ora 1210
01210, 00000, "data file header is media corrupt"
// *Cause: The file header block is internally inconsistent. The beginning
//         of the block has a header with a checksum and other data for
//         insuring the consistancy of the block. It is possible that
//         the last disk write did not operate correctly. The most likely
//         problem is that this is not a datafile for any database.
// *Action: Have operating system make correct file available to database.
//         If the trace file dump indicates that only the checksum is wrong,
//         restore from a backup and do media recovery.

这个错误比较明显，官方解释可能是由于文件头的写丢失导致checksum异常,对于这样的故障，可以考虑使用bbed进行修复，但是obet更加方便（Oracle数据块编辑工具( Oracle Block Editor Tool)-obet），直接使用这个工具进行处理

OBET> tailchk
Check tailchk for File H:\BaiduNetdisk\oracledata\orcl\XFF.DBF, Block 1:
current = 0x6E743122, required = 0x010B0000
OBET> d
File: H:\BaiduNetdisk\oracledata\orcl\HD_DATAPMS01.DBF
Block: 1                Offsets:     0 to    31
--------------------------------------------------------------------------------
00002000 0BA20000 0100800A 00000000 00000104 02870000 00000000 0004200B 2F2E315E
<32 bytes read>
OBET> set mode edit
mode set to: edit
OBET> tailchk apply
Confirm applying tailchk:
File: H:\BaiduNetdisk\oracledata\orcl\XFF.DBF
Block: 1
Offset in block: 8188 (file offset: 0x00003FFC)
Original value: 0x6E743122
New value:      0x010B0000
Confirm? (Y/YES to proceed): y
Verification successful: Stored tailchk matches calculated value (0x010B0000).
Tailchk applied successfully.
OBET> sum apply
Confirm applying checksum:
File: H:\BaiduNetdisk\oracledata\orcl\XFF.DBF
Block: 1
Offset in block: 16 (file offset: 0x00002010)
Original value: 0x0287
New value:      0x38ED
Confirm? (Y/YES to proceed): y
Verification successful: Stored checksum matches calculated value (0x38ED).
Checksum applied successfully.

然后直接重建ctl成功，并顺利打开数据库

Thu Jul 23 12:11:39 2026
Successful mount of redo thread 1, with mount id 1767178232
Completed: CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 18688
LOGFILE
  GROUP 1 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO01.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO02.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO03.LOG'  SIZE 50M BLOCKSIZE 512
DATAFILE
  'H:\BAIDUNETDISK\ORACLEDATA\ORCL\SYSTEM01.DBF',
  'H:\BAIDUNETDISK\ORACLEDATA\ORCL\SYSAUX01.DBF',
  'H:\BAIDUNETDISK\ORACLEDATA\ORCL\UNDOTBS01.DBF',
………………
CHARACTER SET ZHS16GBK
Thu Jul 23 12:12:21 2026
ALTER DATABASE RECOVER  database  
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 20 slaves
Thu Jul 23 12:12:21 2026
Recovery of Online Redo Log: Thread 1 Group 3 Seq 104748 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO03.LOG
Recovery of Online Redo Log: Thread 1 Group 1 Seq 104749 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO01.LOG
Completed: ALTER DATABASE RECOVER  database  
alter database open upgrade
Beginning crash recovery of 1 threads
 parallel recovery started with 19 processes
Started redo scan
Completed redo scan
 read 8331 KB redo, 0 data blocks need recovery
Started redo application at
 Thread 1: logseq 104749, block 2, scn 788671390
Recovery of Online Redo Log: Thread 1 Group 1 Seq 104749 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO01.LOG
Completed redo application of 0.00MB
Completed crash recovery at
 Thread 1: logseq 104749, block 16665, scn 788695898
 0 data blocks read, 0 data blocks written, 8331 redo k-bytes read
Initializing SCN for created control file
Database SCN compatibility initialized to 3
Thu Jul 23 12:12:27 2026
LGWR: STARTING ARCH PROCESSES
Thu Jul 23 12:12:27 2026
ARC0 started with pid=40, OS id=20580 
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Jul 23 12:12:28 2026
ARC1 started with pid=41, OS id=12396 
Thu Jul 23 12:12:28 2026
ARC2 started with pid=42, OS id=18888 
Thu Jul 23 12:12:28 2026
ARC3 started with pid=43, OS id=16552 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Archived Log entry 1 added for thread 1 sequence 104747 ID 0x5e30f62f dest 1:
Thread 1 advanced to log sequence 104750 (thread open)
Thread 1 opened at log sequence 104750
  Current log# 2 seq# 104750 mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO02.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Jul 23 12:12:29 2026
SMON: enabling cache recovery
Archived Log entry 2 added for thread 1 sequence 104749 ID 0x5e30f62f dest 1:
Archived Log entry 3 added for thread 1 sequence 104748 ID 0x5e30f62f dest 1:
[19300] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:15968843 end:15968859 diff:16 (0 seconds)
Dictionary check beginning
Tablespace 'TEMP' 
#3
 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
         This condition can occur when a backup controlfile has
         been restored.  It may be necessary to add files to these
         tablespaces.  That can be done using the SQL statement:
         ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
         Alternatively, if these temporary tablespaces are no longer
         needed, then they can be dropped.
           Empty temporary tablespace: TEMP
*********************************************************************
Database Characterset is ZHS16GBK
Stopping background process MMNL
Errors in file C:\APP\XFF\diag\rdbms\orcl\orcl\trace\orcl_smon_18084.trc  (incident=7313):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: C:\APP\XFF\diag\rdbms\orcl\orcl\incident\incdir_7313\orcl_smon_18084_i7313.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Block recovery from logseq 104750, block 74 to scn 906345854
Recovery of Online Redo Log: Thread 1 Group 2 Seq 104750 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO02.LOG
Block recovery completed at rba 104750.75.16, scn 0.906345855
Block recovery from logseq 104750, block 74 to scn 906345854
Recovery of Online Redo Log: Thread 1 Group 2 Seq 104750 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO02.LOG
Block recovery completed at rba 104750.75.16, scn 0.906345855
Errors in file C:\APP\XFF\diag\rdbms\orcl\orcl\trace\orcl_smon_18084.trc:
ORA-01595: 释放区 (2) 回退段 (4) 时出错
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []

这里有一个ORA-600 4194错误,由于undo回滚段异常，对异常回滚段进行处理，然后导出数据完成本次恢复工作

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

ORA-00314: log 3 of thread 1, expected sequence# N doesn’t match 0

发表于 2026 年 7 月 21 日 由 惜分飞

有朋友咨询一个Oracle数据库由于断电无法启动的问题,最初错误是一个非常常见的ORA-01113 ORA-01110错误
ora-01113

对应的alert日志错误

Tue Jul 21 15:38:12 2026
ALTER DATABASE OPEN
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_4632.trc:
ORA-01113: 文件 2 需要介质恢复
ORA-01110: 数据文件 2: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX01.DBF'
ORA-1113 signalled during: ALTER DATABASE OPEN...
Tue Jul 21 15:38:12 2026
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m000_4948.trc:
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG'
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m000_4948.trc:
ORA-00314: log 2 of thread 1, expected sequence# 6890 doesn't match 0
ORA-00312: online log 2 thread 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG'
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m000_4948.trc:
ORA-00314: log 3 of thread 1, expected sequence# 6891 doesn't match 0
ORA-00312: online log 3 thread 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG'

把数据文件拿到本地之后,尝试执行recover database操作

SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-00314: 日志 3 (用于线程 1) 要求的 sequence# 6891 与 0 不匹配
ORA-00312: 联机日志 3 线程 1: 'H:\BAIDUNETDISK\ORCL\REDO03.LOG'

ORA-00314 ORA-00312这个错误比较常见,但是直接提示要求的 sequence# 6891 与 0 不匹配（后面不匹配的是0）的情况不常见.使用winhex打开redo文件
seq0

这里比较明显的redo的sequence变为了0,初步看感觉是被触发了logfile clear操作导致（我查找了故障前后的alert日志确认没有人工clear操作redolog）,但是数据库实例恢复刚好需要这个redo,因此数据库无法正常打开,基于这种情况,考虑重建ctl,然后强制打开库

SQL> @rectl

CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  NOARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01229: data file 1 is inconsistent with logs
ORA-01110: data file 1: 'H:\BAIDUNETDISK\ORCL\SYSTEM01.DBF'

由于redo异常导致noresetlogs方式重建ctl报ORA-01229错误.对于这样的情况使用resetlogs方式重建成功,然后强制打开库

SQL> recover database using backup controlfile;
ORA-00279: change 178744591 generated at 07/18/2026 18:55:48 needed for thread
1
ORA-00289: suggestion :
C:\APP\XFF\PRODUCT\11.2.0.1\DBHOME_1\RDBMS\ARC0000006891_1176155303.0001
ORA-00280: change 178744591 for thread 1 is in sequence #6891


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
H:\BAIDUNETDISK\ORCL\REDO03.LOG
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'H:\BAIDUNETDISK\ORCL\REDO03.LOG'


SQL> recover database using backup controlfile;
ORA-00279: change 178744591 generated at 07/18/2026 18:55:48 needed for thread
1
ORA-00289: suggestion :
C:\APP\XFF\PRODUCT\11.2.0.1\DBHOME_1\RDBMS\ARC0000006891_1176155303.0001
ORA-00280: change 178744591 for thread 1 is in sequence #6891


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
H:\BAIDUNETDISK\ORCL\REDO02.LOG
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'H:\BAIDUNETDISK\ORCL\REDO02.LOG'


SQL> E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
SP2-0734: unknown command beginning "E:\APP\ADM..." - rest of line ignored.
SQL> recover database using backup controlfile;
ORA-00279: change 178744591 generated at 07/18/2026 18:55:48 needed for thread
1
ORA-00289: suggestion :
C:\APP\XFF\PRODUCT\11.2.0.1\DBHOME_1\RDBMS\ARC0000006891_1176155303.0001
ORA-00280: change 178744591 for thread 1 is in sequence #6891


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
H:\BAIDUNETDISK\ORCL\REDO01.LOG
ORA-00310: 归档日志包含序列 6892; 要求序列 6891
ORA-00334: 归档日志: 'H:\BAIDUNETDISK\ORCL\REDO01.LOG'

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 178744591 generated at 07/18/2026 18:55:48 needed for thread
1
ORA-00289: suggestion :
C:\APP\XFF\PRODUCT\11.2.0.1\DBHOME_1\RDBMS\ARC0000006891_1176155303.0001
ORA-00280: change 178744591 for thread 1 is in sequence #6891


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-10879: error signaled in parallel recovery slave
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'H:\BAIDUNETDISK\ORCL\SYSTEM01.DBF'


SQL> alter database open resetlogs;

Database altered.

然后使用expdp导出数据,提供dmp文件,完成本次恢复任务

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