首页 > 其他分享 >断电引起redo和数据文件不一致故障恢复---惜分飞

断电引起redo和数据文件不一致故障恢复---惜分飞

时间:2024-08-04 21:18:15浏览次数:7  
标签:2024 ADMINISTRATOR APP 分飞 xff --- file redo ORA

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

标题:断电引起redo和数据文件不一致故障恢复

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

有些时候故障总是来的让人非常意外,这个在准备停机迁移数据库之前的几分钟由于某种原因直接导致主机掉电,再次开机数据库无法启动

Sat Aug 03 23:10:37 2024 Successful mount of redo thread 1, with mount id 3696805928 Database mounted in Exclusive Mode Lost write protection disabled Completed: alter database mount Sat Aug 03 23:10:43 2024 alter database open Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\trace\xff_ora_6808.trc: ORA-01113: 文件 21 需要介质恢复 ORA-01110: 数据文件 21: 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XIFENFEI.DBF' ORA-1113 signalled during: alter database open...

尝试数据库恢复各种报错ORA-600 kdourp_inorder2,ORA-600 3020,ORA-7445 kdxlin等

ALTER DATABASE RECOVER    CONTINUE DEFAULT  Media Recovery Log D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XFF\ARCHIVELOG\2024_08_03\O1_MF_1_1159998_MBW605HP_.ARC ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ... ALTER DATABASE RECOVER    CONTINUE DEFAULT  Media Recovery Log D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XFF\ARCHIVELOG\2024_08_03\O1_MF_1_1159999_MBW63QBY_.ARC Sat Aug 03 23:22:10 2024 Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xC] [PC:0x14306B54A, kdxlin()+4432] Sat Aug 03 23:22:10 2024 Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xC] [PC:0x14306B54A, kdxlin()+4432] Sat Aug 03 23:22:10 2024 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\trace\xff_pr25_7740.trc  (incident=132557): ORA-00600: internal error code, arguments: [kdourp_inorder2], [4], [22], [44], [44], [], [], [], [], [], [], [] Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\incident\incdir_132557\xff_pr25_7740_i132557.trc ERROR: Unable to normalize symbol name for the following short stack (at offset 213): dbgexProcessError()+200<-dbgeExecuteForError()+65<-dbgePostErrorKGE()+2269<-dbkePostKGE_kgsf()+77<-kgeade()+562 <-kgerelv()+151<-kgerev()+45<-kgerec5()+60<-sss_xcpt_EvalFilterEx()+1862<-sss_xcpt_EvalFilter()+174 <-.1.4_5+59<-00007FFCB5E2C92F<-00007FFCB5E3D82D<-00007FFCB5DE916B<-00007FFCB5E3C9EE<-kdxlin()+4432 <-kco_issue_callback()+196<-kcoapl()+746<-kcbr_apply_change()+6156<-kcbr_mapply_change()+1162 <-kcbrapply()+2297<-kcbr_apply_pending()+2931<-krp_slave_apply()+1155<-krp_slave_main()+4010<-ksvrdp()+2580 <-opirip()+904<-opidrv()+906<-sou2o()+98<-opimai_real()+280<-opimai()+191<-BackgroundThreadStart()+646 <-00007FFCB562168D<-00007FFCB5E14629 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\trace\xff_pr1w_6472.trc  (incident=132485): ORA-07445: exception encountered: core dump [kdxlin()+4432] [ACCESS_VIOLATION] [ADDR:0xC] [PC:0x14306B54A] Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\incident\incdir_132485\xff_pr1w_6472_i132485.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 D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\trace\xff_pr2o_7472.trc  (incident=132709): ORA-07445: exception encountered: core dump [kdxlin()+4432] [ACCESS_VIOLATION] [ADDR:0xC] [PC:0x14306B54A] Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\incident\incdir_132709\xff_pr2o_7472_i132709.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Sat Aug 03 23:22:11 2024 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\trace\xff_pr18_7812.trc  (incident=132301): ORA-00600: internal error code, arguments: [3020], [62], [517633], [260564481], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 62, block# 517633, file offset is 4240449536 bytes) ORA-10564: tablespace HSEMR_TAB ORA-01110: data file 62: 'D:\APP\ADMINISTRATOR\ORADATA\XFF\EMR006.DBF' ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK' Sat Aug 03 23:22:56 2024 Slave exiting with ORA-10562 exception Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\trace\xff_pr25_7740.trc: ORA-10562: Error occurred while applying redo to data block (file# 64, block# 508263) ORA-10564: tablespace HSEMR_TAB ORA-01110: data file 64: 'D:\APP\ADMINISTRATOR\ORADATA\XFF\HSEMR_TAB008.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 467202 ORA-00600: internal error code, arguments: [kdourp_inorder2], [4], [22], [44], [44], [], [], [] Sat Aug 03 23:22:56 2024 Slave exiting with ORA-10562 exception Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\trace\xff_pr1w_6472.trc: ORA-10562: Error occurred while applying redo to data block (file# 65, block# 498512) ORA-10564: tablespace HSEMR_TAB ORA-01110: data file 65: 'D:\APP\ADMINISTRATOR\ORADATA\XFF\EMR009.DBF' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 467200 ORA-00607: Internal error occurred while making a change to a data block ORA-00602: internal programming exception ORA-07445: exception encountered: core dump [kdxlin()+4432] [ACCESS_VIOLATION] [ADDR:0xC] Sat Aug 03 23:22:57 2024 Media Recovery failed with error 448 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xff\xff\trace\xff_pr00_6732.trc: ORA-00283: recovery session canceled due to errors ORA-00448: normal completion of background process Sat Aug 03 23:22:57 2024 ORA-600 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ... ALTER DATABASE RECOVER CANCEL ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...

通过分析确认有部分数据文件和redo信息不匹配,导致无法正常recover成功

SQL> recover datafile 77; 完成介质恢复。 SQL> recover datafile 78; ORA-00283: 恢复会话因错误而取消 ORA-00600: 内部错误代码, 参数: [3020], [78], [473221], [327628933], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 78, block# 473221, file offset is 3876626432 bytes) ORA-10564: tablespace HSEMR_TAB ORA-01110: 数据文件 78: 'D:\APP\ADMINISTRATOR\ORADATA\XFF\HIS23.DBF' ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK'   SQL> recover datafile 66; ORA-00279: 更改 6029114092 (在 08/03/2024 19:44:05 生成) 对于线程 1 是必需的 ORA-00289: 建议: D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XFF\ARCHIVELOG\2024_08_03\O1_MF_1_115999   9_MBW63QBY_.ARC ORA-00280: 更改 6029114092 (用于线程 1) 在序列 #1159999 中     指定日志: {<RET>=suggested | filename | AUTO | CANCEL} auto 已应用的日志。 完成介质恢复。 SQL> recover datafile 65; ORA-00279: 更改 6029114092 (在 08/03/2024 19:44:05 生成) 对于线程 1 是必需的 ORA-00289: 建议: D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XFF\ARCHIVELOG\2024_08_03\O1_MF_1_115999   9_MBW63QBY_.ARC ORA-00280: 更改 6029114092 (用于线程 1) 在序列 #1159999 中     指定日志: {<RET>=suggested | filename | AUTO | CANCEL} auto ORA-00283: 恢复会话因错误而取消 ORA-10562: Error occurred while applying redo to data block (file# 65, block# 498544) ORA-10564: tablespace HSEMR_TAB ORA-01110: 数据文件 65: 'D:\APP\ADMINISTRATOR\ORADATA\XFF\EMR009.DBF' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 467200 ORA-00607: 当更改数据块时出现内部错误 ORA-00602: 内部编程异常错误 ORA-07445: 出现异常错误: 核心转储 [kdxlin()+4432] [ACCESS_VIOLATION] [ADDR:0xC] [PC:0x14306B54A] [UNABLE_TO_READ] []     ORA-01112: 未启动介质恢复

对于最终无法正常recover成功数据文件,使用Oracle数据库恢复利器:Oracle Recovery Tools工具快速调整scn
oracle-recovery-tools


然后重建ctl,recover 数据库并open成功

 

Sun Aug 04 01:01:51 2024 Successful mount of redo thread 1, with mount id 3696824638 Completed: CREATE CONTROLFILE REUSE DATABASE "XFF" NORESETLOGS FORCE LOGGING ARCHIVELOG     MAXLOGFILES 16     MAXLOGMEMBERS 3     MAXDATAFILES 200     MAXINSTANCES 8     MAXLOGXFFTORY 23360 LOGFILE   GROUP 1 'D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO01.LOG'  SIZE 50M BLOCKSIZE 512,   GROUP 2 'D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO02.LOG'  SIZE 50M BLOCKSIZE 512,   GROUP 3 'D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO03.LOG'  SIZE 50M BLOCKSIZE 512 DATAFILE   'D:\APP\ADMINISTRATOR\ORADATA\XFF\SYSTEM01.DBF',   'D:\APP\ADMINISTRATOR\ORADATA\XFF\SYSAUX01.DBF', …… ALTER DATABASE RECOVER  database  Media Recovery Start  started logmerger process Only allocated 127 recovery slaves (requested 128) Parallel Media Recovery started with 127 slaves Sun Aug 04 01:01:56 2024 Recovery of Online Redo Log: Thread 1 Group 2 Seq 1160002 Reading mem 0   Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO02.LOG Completed: ALTER DATABASE RECOVER  database  Sun Aug 04 01:02:20 2024 alter database open Beginning crash recovery of 1 threads  parallel recovery started with 32 processes Started redo scan Completed redo scan  read 1946 KB redo, 0 data blocks need recovery Started redo application at  Thread 1: logseq 1160002, block 2, scn 6029119350 Recovery of Online Redo Log: Thread 1 Group 2 Seq 1160002 Reading mem 0   Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO02.LOG Completed redo application of 0.00MB Completed crash recovery at  Thread 1: logseq 1160002, block 3895, scn 6029139793  0 data blocks read, 0 data blocks written, 1946 redo k-bytes read Initializing SCN for created control file Database SCN compatibility initialized to 3 Sun Aug 04 01:02:21 2024 LGWR: STARTING ARCH PROCESSES Sun Aug 04 01:02:21 2024 ARC0 started with pid=71, OS id=2772 ARC0: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC0: STARTING ARCH PROCESSES Sun Aug 04 01:02:22 2024 ARC1 started with pid=72, OS id=7996 Sun Aug 04 01:02:22 2024 ARC2 started with pid=73, OS id=2900 Sun Aug 04 01:02:22 2024 ARC3 started with pid=74, OS id=6856 Archived Log entry 1 added for thread 1 sequence 1160000 ID 0xc4814d77 dest 1: ARC1: Archival started ARC2: Archival started ARC2: Becoming the 'no FAL' ARCH ARC2: Becoming the 'no SRL' ARCH ARC1: Becoming the heartbeat ARCH Thread 1 advanced to log sequence 1160003 (thread open) Thread 1 opened at log sequence 1160003   Current log# 1 seq# 1160003 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO01.LOG Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Sun Aug 04 01:02:23 2024 SMON: enabling cache recovery Archived Log entry 2 added for thread 1 sequence 1160002 ID 0xc4814d77 dest 1: Archived Log entry 3 added for thread 1 sequence 1160001 ID 0xc4814d77 dest 1: ARC3: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE [7808] Successfully onlined Undo Tablespace 2. Undo initialization finished serial:0 start:7657234 end:7657703 diff:469 (4 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.          Txff 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 No Resource Manager plan active ********************************************************** WARNING: Files may exists in db_recovery_file_dest that are not known to the database. Use the RMAN command CATALOG RECOVERY AREA to re-catalog any such files. If files cannot be cataloged, then manually delete them using OS command. One of the following events caused txff: 1. A backup controlfile was restored. 2. A standby controlfile was restored. 3. The controlfile was re-created. 4. db_recovery_file_dest had previously been enabled and    then disabled. ********************************************************** replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC Sun Aug 04 01:02:27 2024 QMNC started with pid=75, OS id=7884 LOGSTDBY: Validating controlfile with logical metadata LOGSTDBY: Validation complete Completed: alter database open

后续处理异常表,lob,index等数据,客户业务测试都ok,完成本次恢复工作

标签:2024,ADMINISTRATOR,APP,分飞,xff,---,file,redo,ORA
From: https://www.cnblogs.com/xifenfei/p/18342205

相关文章

  • 权威案例--发包人保修时未尽通知义务的,其主张质保金的责任并非必然消失,而是通常基于未
    《建设工程施工合同纠纷案件裁判规则(三)》中陈述:2020年《建设工程司法解释一》第12条规定:“因承包人的原因造成建设工程质量不符合约定,承包人拒绝修理、返工或者改建,发包人请求减少支付工程价款的,人民法院应予支持。”根据该条规定可以看出,原则上发包人应该先通知承包人修复,只有在......
  • Midjourney、Sora和硅谷机密-《分析模式》漫谈15
    DDD领域驱动设计批评文集做强化自测题获得“软件方法建模师”称号《软件方法》各章合集“AnalysisPatterns”的Preface(前言)有这么一句:KentBeck,WardCunningham,andJimCopleinencouragedmetogetinvolvedwiththecommunityandto developmyideasaspatte......
  • 《软件方法》强化自测题-分析(8)
    DDD领域驱动设计批评文集做强化自测题获得“软件方法建模师”称号《软件方法》各章合集按照业务建模、需求、分析、设计工作流考察,答案不直接给出,可访问自测链接自测,做到全对才能知道答案。知识点见《软件方法》(http://www.umlchina.com/url/softmeth.html)、“软件需求设......
  • 第二周--多维特征/2022吴恩达机器学习课程
    示例在先前的模型中,只有一个特征值x(房子的大小),你可以预测y,房子的价格。但是现在你又知道了多个细节。所以我们就需要更多的符号去表示对于的特征,如下:模型对比寻找一种更简单的方法重新写该表达式。向量这种算法叫多元线性回归为了实现这一点,我们有一个技巧叫矢量化......
  • 如何写出高质量ChatGPT指令?195条Prompt示例-第二弹
    第一弹链接:如何写出高质量ChatGPT指令?195条Prompt示例-CSDN博客点点关注,对催更第三弹更有用哦!3.明确说明所需的主题或任务明确提及你希望ChatGPT解决的任务或主题。这有助于集中响应,避免偏差或模糊的输出。不要像“谈论营销策略”这样笼统的提示,而要具体。例如,“为小企业......
  • WiFiAp探究实录--功能实现与源码分析
    wifi热点说的是wifiAp相关,所以如果源码开发的话,这个WifiAp算是一个搜索代码的关键字,含义是WifiAccesspoint,wifi接入点。所以下文中的wifi热点统一用WifiAp代替wifiAp打开方式:设置->更多->移动网络共享->便携式wlan热点。wifiAp打开条件:任何情况下均可。只是有内网外网之分......
  • Arm V8 - ADRP指令
    ADRP指令作用将当前指令所在页的基地址加/减去字节差,并写入目标寄存器字节差:与目标地址页基地址的间隔字节数,其为PAGE_SIZE的整数倍此时的字节差就是指令所操作的立即数该指令通常配合add指令来向目标寄存器写入完整的地址最后通过br、blr实现长跳转字节码对应关系......
  • 基于JAVA的商品供应管理系统-JavaEE
    点击下载源码基于JAVA的商品供应管理系统-JavaEE摘要当今社会己进入信息社会时代,信息己经受到社会的广泛关注,被看作社会和科学技术发展的三大支柱(材料、能源、信息)之一。信息是管理的基础,是进行决策的基本依据。在一个组织里,信息己作为人力、物力、财力之外的第四种能源......
  • SpringBoot项目配置多数据源-Transcational事务篇
    结论通过多次实践,在执行业务代码场景中,Spring事务并不能同时管理两个数据源的事务,只能管理单个数据源的事务。如果确实有需要同时操作两个数据源,而且需要事务的场景,可以trycatah起来,然后判断需不需要对数据处理(模拟回滚)。上一篇:SpringBoot项目配置多数据源,结合mybatis-pl......
  • 【秋招笔试】2024-08-03-科大讯飞秋招笔试题(算法岗)-三语言题解(CPP/Python/Java)
    ......