标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,666)
- DB2 (22)
- MySQL (73)
- Oracle (1,528)
- Data Guard (51)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (65)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (559)
- Oracle安装升级 (90)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (77)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
- Oracle 19c RAC 替换私网操作
- 监听报TNS-12541 TNS-12560 TNS-00511错误
- drop tablespace xxx including contents恢复
- Linux 8 修改网卡名称
- 如何修改集群的公网信息(包括 VIP) (Doc ID 1674442.1)
- 如何在 oracle 集群环境下修改私网信息 (Doc ID 2103317.1)
- ORA-600 [kcvfdb_pdb_set_clean_scn: cleanckpt] 相关bug
- ORA-600 krhpfh_03-1210故障处理
标签归档:ORA-01207
ORA-600 krhpfh_03-1210故障处理
rac数据库多个节点均处于open状态,数据查询正常,但是应用入库有些时候会失败报类似ORA-01187: cannot read from file because it failed verification tests错误:
故障最初原因是由于有坏盘,换盘之后,有两个节点数据实例crash
Mon Aug 19 21:16:47 2024 Read of datafile '+DATA/xifenfei99.dbf' (fno 1399) header failed with ORA-01207 Rereading datafile 1399 header failed with ORA-01207 Errors in file /u01/app/oracle/diag/rdbms/xff/xff5/trace/xff5_ckpt_75779.trc: ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode ORA-01122: database file 1399 failed verification check ORA-01110: data file 1399: '+DATA/xifenfei99.dbf' ORA-01207: file is more recent than control file - old control file Errors in file /u01/app/oracle/diag/rdbms/xff/xff5/trace/xff5_ckpt_75779.trc: ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode ORA-01122: database file 1399 failed verification check ORA-01110: data file 1399: '+DATA/xifenfei99.dbf' ORA-01207: file is more recent than control file - old control file CKPT (ospid: 75779): terminating the instance due to error 1242 Mon Aug 19 21:16:47 2024 System state dump requested by (instance=5, osid=75779 (CKPT)), summary=[abnormal instance termination]. System State dumped to trace file /u01/app/oracle/diag/rdbms/xff/xff5/trace/xff5_diag_75725.trc Mon Aug 19 21:16:52 2024 ORA-1092 : opitsk aborting process Mon Aug 19 21:16:53 2024 ORA-1092 : opitsk aborting process Mon Aug 19 21:16:53 2024 License high water mark = 131 Termination issued to instance processes. Waiting for the processes to exit Mon Aug 19 21:17:02 2024 Instance termination failed to kill one or more processes Instance terminated by CKPT, pid = 75779 Mon Aug 19 21:17:03 2024 USER (ospid: 33495): terminating the instance Termination issued to instance processes. Waiting for the processes to exit Mon Aug 19 21:17:13 2024 Instance termination failed to kill one or more processes Instance terminated by USER, pid = 33495
但是数据库人工启动成功,查询所有数据文件均处于online状态
可是有部分入库进程非常慢大量等待在enq:HW – contention
所有数据库节点alert日志偶尔报ORA-01186: file 1399 failed verification tests等错
Tue Aug 20 21:30:02 2024 Read of datafile '+DATA/xifenfei99.dbf' (fno 1399) header failed with ORA-01207 Rereading datafile 1399 header failed with ORA-01207 Errors in file /u01/app/oracle/diag/rdbms/xff/xff1/trace/xff1_dbw0_43828.trc: ORA-01186: file 1399 failed verification tests ORA-01122: database file 1399 failed verification check ORA-01110: data file 1399: '+DATA/xifenfei99.dbf' ORA-01207: file is more recent than control file - old control file File 1399 not verified due to error ORA-01122 Read of datafile '+DATA/xifenfei99.dbf' (fno 1399) header failed with ORA-01207 Rereading datafile 1399 header failed with ORA-01207 Errors in file /u01/app/oracle/diag/rdbms/xff/xff1/trace/xff1_dbw0_43828.trc: ORA-01186: file 1399 failed verification tests ORA-01122: database file 1399 failed verification check ORA-01110: data file 1399: '+DATA/xifenfei99.dbf' ORA-01207: file is more recent than control file - old control file File 1399 not verified due to error ORA-01122
基于这种情况,初步判断:
1. 是由于该集群本身多节点(6个节点),只要有节点是open状态,其他节点关闭再启动依旧可以正常启动,但是无法写入数据到报ORA-01207错误的数据文件中(可以读取数据).
2. 如果所有节点关闭关闭,然后数据库无法正常启动会报ORA-01207: file is more recent than control file错误
这样的情况,根据以往经验,ORA-01207: file is more recent than control file通过重建ctl即可恢复,先关闭所有节点,然后尝试启动一个节点
SQL> alter database open; alter database open * ERROR at line 1: ORA-01122: database file 1399 failed verification check ORA-01110: data file 1399: '+DATA/xifenfei99.dbf' ORA-01207: file is more recent than control file - old control file
alter database open Wed Aug 21 14:14:22 2024 SUCCESS: diskgroup REDO was mounted Wed Aug 21 14:14:22 2024 NOTE: dependency between database xff and diskgroup resource ora.REDO.dg is established Wed Aug 21 14:14:27 2024 Errors in file /u01/app/oracle/diag/rdbms/xff/xff1/trace/xff1_ora_47884.trc: ORA-01122: database file 1399 failed verification check ORA-01110: data file 1399: '+DATA/xifenfei99.dbf' ORA-01207: file is more recent than control file - old control file ORA-1122 signalled during: alter database open...
和预期的一样,重试重建ctl,然后数据库报ORA-00600 [krhpfh_03-1210]错误
SQL> shutdown immediate; ORA-01109: database not open Database dismounted. ORACLE instance shut down. SQL> startup nomount pfile='/tmp/xff/pfile'; ORACLE instance started. Total System Global Area 1.3255E+11 bytes Fixed Size 2244832 bytes Variable Size 9.7442E+10 bytes Database Buffers 3.4897E+10 bytes Redo Buffers 208654336 bytes SQL> @rectl Control file created. SQL> SQL> SQL> SQL> recover database; 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-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [krhpfh_03-1210], [fno =], [1399], [fhcpc =], [274968], [fhccc =], [274983], [], [], [], [], [] ORA-01110: data file 1399: '+DATA/xifenfei99.dbf'
这里的提示是有fhcpc和fhccc值不对导致,通过bbed查看相关值
BBED> set file 1399 FILE# 1399 BBED> p kcvfhccc ub4 kcvfhccc @148 0x00043227 ===>274983(10进制) BBED> p kcvfhcpc ub4 kcvfhcpc @140 0x00043218 ===>274968(10进制)
报错比较明显通过bbed修改这两个值
BBED> m /x 2a390400 offset 148 Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: /tmp/xff/1399.dbf.header (1399) Block: 1 Offsets: 148 to 659 Dba:0x5dc00001 ------------------------------------------------------------------------ 2a390400 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0c000000 0f004441 5441315f 5442535f 45515f30 31000000 00000000 00000000 00000000 78010000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 cfebdd33 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 419333df 81001c0a 6ab13046 06000000 c1520400 02000000 10000000 7e000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0d000d00 0d000100 00000000 00000000 <32 bytes per line> BBED> m /x 2b390400 offset 140 File: /tmp/xff/1399.dbf.header (1399) Block: 1 Offsets: 140 to 651 Dba:0x5dc00001 ------------------------------------------------------------------------ 2b390400 e6ef524d 2a390400 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0c000000 0f004441 5441315f 5442535f 45515f30 31000000 00000000 00000000 00000000 78010000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 cfebdd33 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 419333df 81001c0a 6ab13046 06000000 c1520400 02000000 10000000 7e000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0d000d00 0d000100 <32 bytes per line>
修改好这些值之后,recover database和open数据库成功,检查字典正常,业务读写也正常,完成本次恢复任务
SQL> @hcheck HCheck Version 07MAY18 on 21-AUG-2024 15:13:02 ---------------------------------------------- Catalog Version 11.2.0.3.0 (1102000300) db_name: XFF Catalog Fixed Procedure Name Version Vs Release Timestamp Result ------------------------------ ... ---------- -- ---------- -------------- ------ .- LobNotInObj ... 1102000300 <= *All Rel* 08/21 15:13:02 PASS .- MissingOIDOnObjCol ... 1102000300 <= *All Rel* 08/21 15:13:02 PASS .- SourceNotInObj ... 1102000300 <= *All Rel* 08/21 15:13:02 PASS .- OversizedFiles ... 1102000300 <= *All Rel* 08/21 15:13:02 PASS .- PoorDefaultStorage ... 1102000300 <= *All Rel* 08/21 15:13:02 PASS .- PoorStorage ... 1102000300 <= *All Rel* 08/21 15:13:02 PASS .- TabPartCountMismatch ... 1102000300 <= *All Rel* 08/21 15:13:02 PASS .- OrphanedTabComPart ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- MissingSum$ ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- MissingDir$ ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- DuplicateDataobj ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- ObjSynMissing ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- ObjSeqMissing ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- OrphanedUndo ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- OrphanedIndex ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- OrphanedIndexPartition ... 1102000300 <= *All Rel* 08/21 15:13:03 PASS .- OrphanedIndexSubPartition ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- OrphanedTable ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- OrphanedTablePartition ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- OrphanedTableSubPartition ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- MissingPartCol ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- OrphanedSeg$ ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- OrphanedIndPartObj# ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- DuplicateBlockUse ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- FetUet ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- Uet0Check ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- SeglessUET ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- BadInd$ ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- BadTab$ ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- BadIcolDepCnt ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- ObjIndDobj ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- TrgAfterUpgrade ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- ObjType0 ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- BadOwner ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- StmtAuditOnCommit ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- BadPublicObjects ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- BadSegFreelist ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- BadDepends ... 1102000300 <= *All Rel* 08/21 15:13:04 PASS .- CheckDual ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- ObjectNames ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- BadCboHiLo ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- ChkIotTs ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- NoSegmentIndex ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- BadNextObject ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- DroppedROTS ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- FilBlkZero ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- DbmsSchemaCopy ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- OrphanedObjError ... 1102000300 > 1102000000 08/21 15:13:05 PASS .- ObjNotLob ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- MaxControlfSeq ... 1102000300 <= *All Rel* 08/21 15:13:05 PASS .- SegNotInDeferredStg ... 1102000300 > 1102000000 08/21 15:13:06 PASS .- SystemNotRfile1 ... 1102000300 > 902000000 08/21 15:13:06 PASS .- DictOwnNonDefaultSYSTEM ... 1102000300 <= *All Rel* 08/21 15:13:07 PASS .- OrphanTrigger ... 1102000300 <= *All Rel* 08/21 15:13:07 PASS .- ObjNotTrigger ... 1102000300 <= *All Rel* 08/21 15:13:07 PASS --------------------------------------- 21-AUG-2024 15:13:07 Elapsed: 5 secs --------------------------------------- Found 0 potential problem(s) and 0 warning(s) PL/SQL procedure successfully completed. Statement processed. Complete output is in trace file: /u01/app/oracle/diag/rdbms/xff/xff1/trace/xff1_ora_70961_HCHECK.trc
分布式存储故障导致数据库无法启动故障处理
国内xx医院使用了国外医疗行业龙头的pacs系统,由于是一个历史库,存放在分布式存储中,由于存储同时多个节点故障,导致数据库多个文件异常,数据库无法启动,三方维护人员尝试通通过rman归档进行应用日志,结果发现日志有损坏报ORA-00354 ORA-00353,无法记录恢复,希望我们给予支持
Mon Apr 29 13:28:40 2024 Media Recovery failed with error 354 Mon Apr 29 13:28:40 2024 Errors in file F:\XXXXXX_DB\ORACLE\ADMIN\diag\rdbms\xxx\msxxx1\trace\xxx_pr00_4568.trc: ORA-00283: recovery session canceled due to errors ORA-00354: corrupt redo log block header ORA-00353: log corruption near block 487424 change 8737273868 time 04/01/2024 01:38:25 ORA-00334: archived log: 'F:\XXXXXX_DB\ORADATA\XXX\LOGARC0000052184_0922116268.0001' ORA-283 signalled during: alter database recover logfile 'F:\XXXXXX_DB\ORADATA\XXX\LOGARC0000052184_0922116268.0001'...
接手故障之后,通过尝试恢复发现除该错误之外,还有ORA-600 4552之类错误
跳过这些异常文件恢复,最终确认异常文件有如下部分
这些文件由于日志无法正常应用(有日志损坏无法应用,有日志和数据文件block不匹配导致无法应用),这样的情况直接通过自研的Oracle Recovery Tools小工具直接修改文件头信息
然后尝试OPEN数据库结果报ORA-1207
对于这个故障可以通过rectl或者using backup ctl方式处理,然后open数据库成功
由于该系统是历史库,不会有新业务写入,通过对异常表和索引进行处理之后,客户测试业务可以正常访问,完成本次恢复
ORA-1200/ORA-1207数据库恢复
由于系统性能问题或者底层io问题,数据库alert日志报一下控制文件损坏错误然后crash掉
Mon Nov 13 08:06:44 2023 Thread 1 advanced to log sequence 12100 (LGWR switch) Current log# 1 seq# 12100 mem# 0: /u01/oracle/oradata/xifenfei/redo01.log Mon Nov 13 09:23:59 2023 ********************* 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: 17064): terminating the instance Mon Nov 13 09:24:00 2023 System state dump requested by (instance=1, osid=17064), summary=[abnormal instance termination].
重启数据库报ORA-01122 ORA-01110 ORA-01207错误
Mon Nov 13 10:11:21 2023 ALTER DATABASE OPEN Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_25824.trc: ORA-01122: database file 1 failed verification check ORA-01110: data file 1: '/u01/oracle/oradata/xifenfei/system01.dbf' ORA-01207: file is more recent than control file - old control file ORA-1122 signalled during: ALTER DATABASE OPEN...
处理好上述错误之后遭遇ORA-01122 ORA-01110 ORA-01200,类似文章:
bbed处理ORA-01200故障
ORA-01122 ORA-01200故障处理
Mon Nov 13 10:51:48 2023 alter database open Read of datafile '/u01/oracle/oradata/xifenfei/sysaux01.dbf' (fno 2) header failed with ORA-01200 Rereading datafile 2 header failed with ORA-01200 Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_24148.trc: ORA-01122: database file 2 failed verification check ORA-01110: data file 2: '/u01/oracle/oradata/xifenfei/sysaux01.dbf' ORA-01200: actual file size of 2860800 is smaller than correct size of 2867200 blocks ORA-1122 signalled during: alter database open...
解决上述错误之后,尝试open库报ORA-00314 ORA-00312之类错误
Mon Nov 13 18:00:43 2023 alter database open Beginning crash recovery of 1 threads parallel recovery started with 15 processes Started redo scan Completed redo scan read 61894 KB redo, 589 data blocks need recovery Started redo application at Thread 1: logseq 12100, block 112760 Recovery of Online Redo Log: Thread 1 Group 1 Seq 12100 Reading mem 0 Mem# 0: /u01/oracle/oradata/xifenfei/redo01.log Completed redo application of 1.20MB Mon Nov 13 18:00:44 2023 Hex dump of (file 2, block 39078) in trace file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p011_27469.trc Reading datafile '/u01/oracle/oradata/xifenfei/sysaux01.dbf' for corruption at rdba: 0x008098a6 (file 2, block 39078) Reread (file 2, block 39078) found same corrupt data (logically corrupt) RECOVERY OF THREAD 1 STUCK AT BLOCK 39078 OF FILE 2 Mon Nov 13 18:00:44 2023 Exception [type: SIGSEGV, Address not mapped to object][ADDR:0xC][PC:0x95FB838, kdxlin()+4946][flags: 0x0, count: 1] Mon Nov 13 18:00:44 2023 Exception [type: SIGSEGV, Address not mapped to object][ADDR:0xC][PC:0x95FB4DE, kdxlin()+4088][flags: 0x0, count: 1] Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p011_27469.trc: ORA-00314: log 2 of thread 1, expected sequence# 12093 doesn't match 12085 ORA-00312: online log 2 thread 1: '/u01/oracle/oradata/xifenfei/redo02.log' Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p011_27469.trc: ORA-00314: log 3 of thread 1, expected sequence# 12096 doesn't match 12080 ORA-00312: online log 3 thread 1: '/u01/oracle/oradata/xifenfei/redo03.log' ORA-00314: log 2 of thread 1, expected sequence# 12093 doesn't match 12085 ORA-00312: online log 2 thread 1: '/u01/oracle/oradata/xifenfei/redo02.log'
后面继续处理遇到类似这样错误
ALTER DATABASE RECOVER CANCEL Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_pr00_31110.trc: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/u01/oracle/oradata/xifenfei/system01.dbf' ORA-1547 signalled during: ALTER DATABASE RECOVER CANCEL ... ALTER DATABASE RECOVER CANCEL ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ... Mon Nov 13 19:06:28 2023 alter database open resetlogs ORA-1194 signalled during: alter database open resetlogs...
最后确认其他数据文件均可recover 成功,只有file 2 无法正常recover
SQL> recover datafile 1; Media recovery complete. SQL> recover datafile 2; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [3020], [2], [950840], [9339448], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 2, block# 950840, file offset is 3494313984 bytes) ORA-10564: tablespace SYSAUX ORA-01110: data file 2: '/u01/oracle/oradata/xifenfei/sysaux01.dbf' ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK' SQL> recover datafile 3; Media recovery complete. SQL> recover datafile 4; Media recovery complete. SQL> recover datafile 5; Media recovery complete. SQL> recover datafile 6; Media recovery complete. SQL> recover datafile 7; Media recovery complete. SQL> recover datafile 2 allow 1 corruption; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [3020], [2], [2410240], [10798848], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 2, block# 2410240, file offset is 2564816896 bytes) ORA-10564: tablespace SYSAUX ORA-01110: data file 2: '/u01/oracle/oradata/xifenfei/sysaux01.dbf' ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK'
通过bbed修改文件头,直接open数据库成功,并协助客户顺利导出数据
参考类似文章:
使用bbed修复损坏datafile header
使用bbed让rac中的sysaux数据文件online