标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr kgegpa MySQL恢复 ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 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-600 kdsgrp1 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)
- 操作系统 (110)
- 数据库 (1,823)
- DB2 (22)
- MySQL (80)
- Oracle (1,652)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (620)
- Oracle安装升级 (103)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (45)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (28)
-
最近发表
- 注意:PostgreSQL库出现readme_to_recover勒索
- Oracle 19c 202601补丁(RUs+OJVM)-19.30
- Patch_SCN快速解决ORA-600 2663故障
- 在生产环境错误执行dd命令破坏asm磁盘故障恢复
- obet实现对数据文件坏块检测功能
- oracle linux 8.10注意pmlogger导致空间被大量占用
- obet快速修改scn/resetlogs恢复数据库(缺少归档,ORA-00308)
- 使用DBMS_PDB.RECOVER抢救单个pdb
- aix环境写入大文件设置combehin提高效率
- 记录一次国产数据库被rm -rf /*删除的救援过程
- 数据库启动报 maximum number of processes () exceeded分析
- ORA-600 [ksunfy : too few sessions]
- 由于数据块scn大于数据库scn导致ORA-600 kcbzib_kcrsds_1错误
- ORA-600 ktbair2: illegal inheritance恢复
- 一键恢复ORA-00704 ORA-00702故障—202512
- PostgreSQL查询一个表相关的所有oid
- PostgreSQL oid文件替换实现数据访问
- 模拟sql server故障备份完成恢复实现数据0丢失
- sql server 事务日志备份异常恢复案例
- win平台挂起Oracle数据库启动进程
标签归档: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)

加我微信(17813235971)
加我QQ(107644445)

