标签云
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,655)
- DB2 (22)
- MySQL (71)
- Oracle (1,519)
- Data Guard (51)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (158)
- 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备份恢复 (553)
- Oracle安装升级 (90)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (76)
- 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)
-
最近发表
- 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故障处理
- 19c库启动报ORA-600 kcbzib_kcrsds_1
- DBMS_SESSION.set_context提示ORA-01031问题解决
- redo写丢失导致ORA-600 kcrf_resilver_log_1故障
- 硬件故障导致ORA-01242 ORA-01122等错误
- 200T 数据库非归档无备份恢复
- 利用flashback快速恢复failover 的备库
- [comingback2022@cock.li].eking和[tsai.shen@mailfence.com].faust扩展名勒索病毒数据库可以完美恢复
- opatch auto 出现unable to get oracle owner for 错误
- Oracle 23ai 表和视图的列最多支持到4096个
- 断电引起redo和数据文件不一致故障恢复
- ORA-03113: 通信通道的文件结尾
标签归档:ORA-01110
ORA-01110 ORA-17070 OSD-04006 故障恢复
有朋友找到我说应用访问数据库和导出数据都报ORA-01110 ORA-17070 OSD-04006之类错误,数据库可以正常open,但是业务访问关键数据和导出报错
对于这个错误,根据以往恢复经验,初步判断可能硬件异常(比如坏道,硬件故障)或者文件系统异常引起,让客户尝试拷贝该文件,确认该文件也无法拷贝
对于这种情况,如果放弃该文件,恢复其他文件数据,那样数据丢失比例太大,直接通过特定恢复工具对其损坏文件进行拷贝,最大限度强求当前文件数据,发现一些扇区损坏跳过继续拷贝
通过坏块检查工具进行检查确认该文件76个block损坏(对于32G的数据文件损坏1M数据,比较好效果)
对坏块进行处理,然后使用expdp导出数据,最大限度抢救数据
一键恢复ORA-01113 ORA-01110—Oracle Recovery Tools
一般由于归档日志丢失或者非归档库可能在数据库启动的时候出现类似如下错误
SQL> startup ORACLE instance started. Total System Global Area 2137886720 bytes Fixed Size 2282960 bytes Variable Size 587205168 bytes Database Buffers 1543503872 bytes Redo Buffers 4894720 bytes Database mounted. ORA-01113: file 1 needs media recovery ORA-01110: data file 1: 'F:\ORADATA\XIFENFEI\SYSTEM01.DBF'
主要是由于数据文件不一致需要比较老的日志,但是日志不存在从而导致该问题
以前是通过一系列的方法强制open库,以前类似文章:
12c ORA-01113 ORA-01110 恢复
分享一次ORA-01113 ORA-01110故障处理过程
现在可以通过Oracle Recovery Tools工具一键解决
尝试open数据库
SQL> recover database; Media recovery complete. SQL> alter database open; Database altered.
软件下载:OraRecovery下载
使用说明:使用说明
12.2 standby 报ORA-01110
12.2备库报错
2018-06-13T19:29:00.302767+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 1: '/u01/app/oracle/oradata/xifenfei/system01.dbf' 2018-06-13T19:29:00.829861+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 2: '/u01/app/oracle/oradata/xifenfei/rich101.dbf' 2018-06-13T19:29:00.930632+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 3: '/u01/app/oracle/oradata/xifenfei/sysaux01.dbf' 2018-06-13T19:29:01.010230+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 4: '/u01/app/oracle/oradata/xifenfei/undotbs01.dbf' 2018-06-13T11:29:01.055975+00:00 Archived Log entry 5072 added for T-1.S-5020 ID 0x6a8e9d72 LAD:1 RFS[18]: Selected log 10 for T-1.S-5024 dbid 1787743346 branch 957530932 2018-06-13T19:29:01.091059+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 5: '/u01/app/oracle/oradata/xifenfei/richman01.dbf' 2018-06-13T19:29:01.172613+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 7: '/u01/app/oracle/oradata/xifenfei/users01.dbf' 2018-06-13T19:29:01.251906+08:00 Errors in file /u01/app/oracle/diag/rdbms/xifenfeidg/xifenfei/trace/xifenfei_m000_2457.trc: ORA-01110: data file 8: '/u01/app/oracle/oradata/xifenfei/r_index01.dbf'
trace文件
*** 2018-06-13T19:29:00.282836+08:00 *** SESSION ID:(2281.15120) 2018-06-13T19:29:00.282868+08:00 *** CLIENT ID:() 2018-06-13T19:29:00.282873+08:00 *** SERVICE NAME:(SYS$BACKGROUND) 2018-06-13T19:29:00.282878+08:00 *** MODULE NAME:(MMON_SLAVE) 2018-06-13T19:29:00.282883+08:00 *** ACTION NAME:(DDE async action) 2018-06-13T19:29:00.282888+08:00 *** CLIENT DRIVER:() 2018-06-13T19:29:00.282892+08:00 ========= Dump for error ORA 312 (no incident) ======== ----- DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) ----- dbkh_reactive_run_check: BEGIN dbkh_reactive_run_check:; incident_id=0 dbkh_run_check_internal: BEGIN; check_namep=DB Structure Integrity Check, run_namep=<null> dbkh_run_check_internal: BEGIN; timeout=0 dbkh_run_check_internal: AFTER RUN CREATE; run_id=1841 *** 2018-06-13T19:29:00.302510+08:00 DDE previous invocation failed before phase II DDE was called in a 'No Invocation Mode' ----- Start Diag Diagnostic Dump ----- Diagnostic dump is performed due to an error in the diagfw code during error handling. Dump error and call stack for the diagnostic dump: *** 2018-06-13T19:29:00.302576+08:00 dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=1, mask=0x0) ----- Error Stack Dump ----- ORA-01110: data file 1: '/u01/app/oracle/oradata/xifenfei/system01.dbf' ----- SQL Statement (None) ----- Current SQL information unavailable - no cursor. ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedst()+119 call kgdsdst() 7FFF1A0D6C68 000000002 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 000000082 ? dbkedDefDump()+1200 call ksedst() 000000000 000000002 ? 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? ksedmp()+259 call dbkedDefDump() 000000001 000000000 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgexExecuteIntDiag call ksedmp() 000000001 000000000 ? Dmp()+1457 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgeBeginInvoke()+3 call dbgexExecuteIntDiag 7F5A00000003 7F5A99B856C0 59 Dmp() 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbgePostErrorKGE()+ call dbgeBeginInvoke() 7F5A99B856C0 7FFF1A0D7D20 1676 7FFF1A0B86D0 ? 7FFF1A0B87E8 ? 000000000 ? 000000082 ? dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 7F5A99BC59A0 7F5A99AA0048 90 000000456 7FFF1A0B87E8 ? 000000000 ? 000000082 ? kgeade()+432 call dbkePostKGE_kgsf() 7F5A99BC59A0 7F5A99AA0048 000000456 7FFF1A0B87E8 ? 000000000 ? 000000082 ? kgerelv()+144 call kgeade() 7F5A99BC59A0 ? 7F5A99BC5BE8 ? 7F5A99AA0048 ? 000000456 ? 000000000 000000000 kgerev()+36 call kgerelv() 7F5A99BC59A0 ? 7F5A99AA0048 ? 7F5A99AA0048 ? 000000456 ? 012E79CF4 ? 000000002 ? kserec2()+185 call kgerev() 7F5A99BC59A0 ? 7F5A99AA0048 ? 7F5A99AA0048 ? 000000456 ? 7FFF1A0D8000 000000002 ? kcf_record_fn()+634 call kserec2() 7F5A99BC59A0 ? 000000000 000000001 000000001 00000002C 141E0C518 kcvvra_dfh()+5278 call kcf_record_fn() 000000001 151622BB8 000000000 7FFF1A0DA5D8 00000002C ? 141E0C518 ? kcidr_file_header_c call kcvvra_dfh() 7FFF1A0DA460 ? 7FFF1A0D9FE8 ? heck_common()+4669 000000000 ? 7FFF1A0D9398 7F5A94379000 ? 000000001 ? kcidr_file_header_a call kcidr_file_header_c 7F5A99A9F7A0 7F5A94379000 ll_check_common()+2 heck_common() 000000001 000000000 259 7F5A94379000 ? 000000000 kcidr_cross_check() call kcidr_file_header_a 7F5A99A9F7A0 7FFF1A0DABE4 +566 ll_check_common() 000000001 ? 000000000 ? 7F5A94379000 ? 000000000 ? dbkird_cross_check( call kcidr_cross_check() 7F5A99A9F7A0 7FFF1A0DABE4 ? )+557 7F5A99BC5BE8 000000000 ? 7F5A94379000 ? 000000000 ? dbkh_run_check_inte call dbkird_cross_check( 7F5A99A9F7A0 7FFF1A0DABE4 ? rnal()+2228 ) 7F5A99BC5BE8 ? 000000000 ? 7F5A94379000 ? 000000000 ? dbkh_reactive_run_c call dbkh_run_check_inte 7FFF1A0DB970 000000000 heck()+3011 rnal() 000000002 000000000 000000000 000000000 dbgdaAsyncReceive() call dbkh_reactive_run_c 7F5A99B856C0 7FFF1A0DBC90 +279 heck() 000000002 ? 000000000 ? 000000000 ? 000000000 ? dbgea_exec_()+1739 call dbgdaAsyncReceive() 7F5A99B856C0 0020C0029 7FFF1A0E7CA0 7FFF1A0E7D20 000000002 000000000 ? dbgea_exec()+621 call dbgea_exec_() 7F5A99B856C0 7F5A94984D18 0000000E8 000000000 000000002 ? 000000000 ? dbkea_exec()+1718 call dbgea_exec() 7F5A99B856C0 7F5A94984D18 0000000E8 000000000 000000002 ? 000000000 ? dbkea_slave_exec()+ call dbkea_exec() 7F5A99B856C0 ? 7F5A94984D18 ? 518 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? kebm_slave_cb()+64 call dbkea_slave_exec() 1453D7248 7F5A94984D18 ? 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? kebm_slave_main()+7 call kebm_slave_cb() 1453D7248 ? 7F5A94984D18 ? 72 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? ksvrdp_int()+2010 call kebm_slave_main() 1453D7248 ? 1453D7248 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? opirip()+602 call ksvrdp_int() 000000000 ? 000000000 ? 0000000E8 ? 000000000 ? 000000002 ? 000000000 ? opidrv()+602 call opirip() 000000032 000000004 7FFF1A0EAD98 000000000 ? 000000002 ? 000000000 ? sou2o()+145 call opidrv() 000000032 000000004 7FFF1A0EAD98 000000000 ? 000000002 ? 000000000 ? opimai_real()+202 call sou2o() 7FFF1A0EAD70 000000032 000000004 7FFF1A0EAD98 000000002 ? 000000000 ? ssthrdmain()+417 call opimai_real() 000000000 7FFF1A0EB080 000000004 ? 7FFF1A0EAD98 ? 000000002 ? 000000000 ? main()+262 call ssthrdmain() 000000000 000000003 7FFF1A0EB080 000000001 000000000 000000000 ? __libc_start_main() call main() 000000000 7FFF1A0EB2B8 +245 7FFF1A0EB080 ? 000000001 ? 000000000 ? 000000000 ? _start()+41 call __libc_start_main() 000D05240 000000001 7FFF1A0EB2B8 7F5A95015C05 ? 000000000 ? 000000000 ? --------------------- Binary Stack Dump ---------------------
BUG:24844841 – PHSB:CDB M000 REPORTED ORA-1110 ON ADG WHEN A DATAFILE IS ADDED ON PRIMARY
@ The M000 messages is a false alarm as well. It is a false alarm by DRA check
@ that doesn’t consider standby media recovery properly. Adding a file happens
@ to trigger the timing for the false alarm.
@ One way to fix this is to skip file header check if standby recovery is
@ running inside kcidr_file_header_all_check_common.
M000进程检查数据库文件头信息,由于bug原因报ORA-01110错误.
处理建议
1.打上补丁24844841
2.19.1版本修复该问题
3.重启备库,启动mgr
4.暂时忽略该问题(目前没有发现影响数据库同步)
参考:ORA-01110 For All Files In Standby Database (Doc ID 2322290.1)