联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
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)