ORA-07445: exception encountered: core dump [PC:0x90000000D017E10]
上週給客戶做巡檢時在alert日誌發現這個錯誤ORA-07445: exception encountered: core dump [PC:0x90000000D017E10] [SIGSEGV]
ORA-07445: exception encountered: core dump [PC:0x90000000D017E10] [SIGSEGV] [ADDR:0xFFFFFFFFDFFFB00] [PC:0x90000000D017E10] [Address not mapped to object]
2014/11/18 04:39:20 Incident details in: /u01/oracle/diag/rdbms/jzh/jzh2/incident/incdir_432484/jzh2_ora_16778166_i432484.trc
2014/11/18 04:39:20 Use ADRCI or Support Workbench to package the incident.
2014/11/18 04:39:20 See Note 411.1 at My Oracle Support for error and packaging details.
2014/11/18 04:39:23 Dumping diagnostic data in directory=[cdmp_20141118043923], requested by (instance=2, osid=16778166), summary=[incident=432484].
2014/11/18 04:39:25 Sweep [inc][432484]: completed
2014/11/18 04:39:25 Sweep [inc2][432484]: completed
檢查jzh2_ora_16778166_i432484.trc檔案
*** 2014-11-18 04:39:20.986
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
----- PL/SQL Stack -----
----- PL/SQL Call Stack -----
object line object
handle number name
700001b4ec35250 287 package body SYS.DBMS_BACKUP_RESTORE
主要關注Call Stack呼叫堆疊部份,標紅字型似乎與備份有關,接著往下看呼叫堆疊跟蹤;
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+40 bl 107c4a874 000000000 ? 000000001 ?
000000003 ? 000000001 ?
000000000 ? 000000001 ?
000000003 ? 000000001 ?
ksedst1()+112 call skdstdst() 13A78E053D5C8E98 ?
4820384100000000 ?
110849E30 ? 000002004 ?
1106C99A8 ? 10A389A84 ?
000000000 ? 1106C99A8 ?
ksedst()+40 call ksedst1() 303106C99A8 ? 002050033 ?
10A389A78 ? 7000000000262 ?
000000000 ? 000000000 ?
10A389078 ? 000000000 ?
dbkedDefDump()+1516 call ksedst() 00000000D ? 110000B14 ?
000000000 ? 110000B14 ?
000000000 ? 00000000B ?
F1000F0A00340000 ?
300000003 ?
ksedmp()+72 call dbkedDefDump() 300000000 ? 064306634 ?
90000000D017E10 ? 000000001 ?
00000000B ? 11084AB10 ?
11084ADC0 ? 000000001 ?
ssexhd()+2672 call ksedmp() 109E0CBF0 ? 200000002 ?
函式呼叫順序 skdstdst-> ksedst1-> ksedst-> dbkedDefDump-> ksedmp-> ssexhd,接著往下看;
**** At frame 60 recursion pattern of size 2 found, for return address
90000000d022d50 suppressing printing.
**** At frame 14748 recursion pattern broken, last return was ----->在框架14748遞迴模式被broken
90000000d017fd8
skgfrls()+492 call 90000000cff2b80 1054647D0 ? 10A258658 ?
00000001A ? 000000002 ?
FFFFFFFFFFFAEF4 ? 000000000 ?
000000000 ? 700000000023600 ?
ksfq_rls()+160 call skgfrls() 1054551C4 ? 700001B6DB04418 ?
700001A3AD57258 ? 000000002 ?
000000001 ? 700001B6A0BCC98 ?
11085AF58 ? 700000000003668 ?
ksfqxdes()+1368 call ksfq_rls() 000000000 ? 1106597D8 ?
700001B6DB043B8 ? 000000005 ?
700001B6A0BCC98 ? 110000250 ?
FFFFFFFFFFF44F0 ?
8842408200000002 ?
krbdrel()+148 call ksfqxdes() 110B3C2F0 ? 000000000 ?
110983E18 ? 000000000 ?
000000000 ? 000000000 ?
110974628 ? 000000003 ?
krbdgdal()+480 call krbdrel() 000000000 ? 110B2A388 ?
000000000 ? 000000010 ?
FFFFFFFFFFF4CF0 ? 110B29870 ?
FFFFFFFFFFF4D10 ?
FFFFFFFFFFF4C40 ?
krbidvda()+480 call krbdgdal() 11065D870 ? 000000000 ?
FFFFFFFFFFF5180 ?
2220004100000000 ?
000000001 ? 000000400 ?
110B29890 ? 000000044 ?
pevm_icd_call_commo call krbidvda() 110974628 ? 700001B6A0BCC98 ?
函式呼叫順序skgfrls-> ksfq_rls-> ksfqxdes-> krbdrel-> krbdgdal-> krbidvda 這一過程出現了問題,ksfg_rls是release the sequential device that was allocated earlier,說明在release device(釋放裝置)時出現了問題,當rman在釋放channel時可能遇到該問題,接著往下看;
client details:
O/S info: user: oraprd, term: , ospid: 55312806
machine: jzh2 program: rman@jzh2 (TNS V1-V3)
client info: rman channel=ch02
application name: backup incr datafile, hash value=1167306624
action name: 0000066 STARTED4, hash value=2243181322
Current Wait Stack:
0: waiting for 'Backup: MML shutdown'
=0x0, =0x0, =0x0
wait_id=1815 seq_num=2056 snap_id=1
wait times: snap=2.196096 sec, exc=2.196096 sec, total=2.196096 sec
wait times: max=infinite, heur=2.196096 sec
wait counts: calls=0 os=0
in_wait=1 iflags=0x5a0
--------------------------------------------------
[2 samples, 04:39:21 - 04:39:22]
waited for 'Backup: MML shutdown', seq_num: 2056
p1: ''=0x0
p2: ''=0x0
p3: ''=0x0
time_waited: >= 1 sec (still in wait)
[1 sample, 04:39:20]
not in wait at each sample
[117 samples, 04:37:23 - 04:39:19]
rman channel為ch02在等待MML shutdown,等待時間從04:37:23 - 04:39:19,alert日誌與trace檔案中報ORA-07445的時間點如下:
2014/11/18 04:39:20 ORA-07445: exception encountered: core dump [PC:0x90000000D017E10] [SIGSEGV] [ADDR:0xFFFFFFFFDFFFB00] [PC:0x90000000D017E10] [Address not mapped to object] []
至此可以判斷該錯誤是由於rman在release channel時導致的。
mos上解釋是bug 17240394,oracle沒有給出原因和解決方案,一般這個錯誤可以忽略!
ORA-07445: exception encountered: core dump [PC:0x90000000D017E10] [SIGSEGV] [ADDR:0xFFFFFFFFDFFFB00] [PC:0x90000000D017E10] [Address not mapped to object]
2014/11/18 04:39:20 Incident details in: /u01/oracle/diag/rdbms/jzh/jzh2/incident/incdir_432484/jzh2_ora_16778166_i432484.trc
2014/11/18 04:39:20 Use ADRCI or Support Workbench to package the incident.
2014/11/18 04:39:20 See Note 411.1 at My Oracle Support for error and packaging details.
2014/11/18 04:39:23 Dumping diagnostic data in directory=[cdmp_20141118043923], requested by (instance=2, osid=16778166), summary=[incident=432484].
2014/11/18 04:39:25 Sweep [inc][432484]: completed
2014/11/18 04:39:25 Sweep [inc2][432484]: completed
檢查jzh2_ora_16778166_i432484.trc檔案
*** 2014-11-18 04:39:20.986
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
----- PL/SQL Stack -----
----- PL/SQL Call Stack -----
object line object
handle number name
700001b4ec35250 287 package body SYS.DBMS_BACKUP_RESTORE
主要關注Call Stack呼叫堆疊部份,標紅字型似乎與備份有關,接著往下看呼叫堆疊跟蹤;
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+40 bl 107c4a874 000000000 ? 000000001 ?
000000003 ? 000000001 ?
000000000 ? 000000001 ?
000000003 ? 000000001 ?
ksedst1()+112 call skdstdst() 13A78E053D5C8E98 ?
4820384100000000 ?
110849E30 ? 000002004 ?
1106C99A8 ? 10A389A84 ?
000000000 ? 1106C99A8 ?
ksedst()+40 call ksedst1() 303106C99A8 ? 002050033 ?
10A389A78 ? 7000000000262 ?
000000000 ? 000000000 ?
10A389078 ? 000000000 ?
dbkedDefDump()+1516 call ksedst() 00000000D ? 110000B14 ?
000000000 ? 110000B14 ?
000000000 ? 00000000B ?
F1000F0A00340000 ?
300000003 ?
ksedmp()+72 call dbkedDefDump() 300000000 ? 064306634 ?
90000000D017E10 ? 000000001 ?
00000000B ? 11084AB10 ?
11084ADC0 ? 000000001 ?
ssexhd()+2672 call ksedmp() 109E0CBF0 ? 200000002 ?
函式呼叫順序 skdstdst-> ksedst1-> ksedst-> dbkedDefDump-> ksedmp-> ssexhd,接著往下看;
**** At frame 60 recursion pattern of size 2 found, for return address
90000000d022d50 suppressing printing.
**** At frame 14748 recursion pattern broken, last return was ----->在框架14748遞迴模式被broken
90000000d017fd8
skgfrls()+492 call 90000000cff2b80 1054647D0 ? 10A258658 ?
00000001A ? 000000002 ?
FFFFFFFFFFFAEF4 ? 000000000 ?
000000000 ? 700000000023600 ?
ksfq_rls()+160 call skgfrls() 1054551C4 ? 700001B6DB04418 ?
700001A3AD57258 ? 000000002 ?
000000001 ? 700001B6A0BCC98 ?
11085AF58 ? 700000000003668 ?
ksfqxdes()+1368 call ksfq_rls() 000000000 ? 1106597D8 ?
700001B6DB043B8 ? 000000005 ?
700001B6A0BCC98 ? 110000250 ?
FFFFFFFFFFF44F0 ?
8842408200000002 ?
krbdrel()+148 call ksfqxdes() 110B3C2F0 ? 000000000 ?
110983E18 ? 000000000 ?
000000000 ? 000000000 ?
110974628 ? 000000003 ?
krbdgdal()+480 call krbdrel() 000000000 ? 110B2A388 ?
000000000 ? 000000010 ?
FFFFFFFFFFF4CF0 ? 110B29870 ?
FFFFFFFFFFF4D10 ?
FFFFFFFFFFF4C40 ?
krbidvda()+480 call krbdgdal() 11065D870 ? 000000000 ?
FFFFFFFFFFF5180 ?
2220004100000000 ?
000000001 ? 000000400 ?
110B29890 ? 000000044 ?
pevm_icd_call_commo call krbidvda() 110974628 ? 700001B6A0BCC98 ?
函式呼叫順序skgfrls-> ksfq_rls-> ksfqxdes-> krbdrel-> krbdgdal-> krbidvda 這一過程出現了問題,ksfg_rls是release the sequential device that was allocated earlier,說明在release device(釋放裝置)時出現了問題,當rman在釋放channel時可能遇到該問題,接著往下看;
client details:
O/S info: user: oraprd, term: , ospid: 55312806
machine: jzh2 program: rman@jzh2 (TNS V1-V3)
client info: rman channel=ch02
application name: backup incr datafile, hash value=1167306624
action name: 0000066 STARTED4, hash value=2243181322
Current Wait Stack:
0: waiting for 'Backup: MML shutdown'
=0x0, =0x0, =0x0
wait_id=1815 seq_num=2056 snap_id=1
wait times: snap=2.196096 sec, exc=2.196096 sec, total=2.196096 sec
wait times: max=infinite, heur=2.196096 sec
wait counts: calls=0 os=0
in_wait=1 iflags=0x5a0
--------------------------------------------------
[2 samples, 04:39:21 - 04:39:22]
waited for 'Backup: MML shutdown', seq_num: 2056
p1: ''=0x0
p2: ''=0x0
p3: ''=0x0
time_waited: >= 1 sec (still in wait)
[1 sample, 04:39:20]
not in wait at each sample
[117 samples, 04:37:23 - 04:39:19]
rman channel為ch02在等待MML shutdown,等待時間從04:37:23 - 04:39:19,alert日誌與trace檔案中報ORA-07445的時間點如下:
2014/11/18 04:39:20 ORA-07445: exception encountered: core dump [PC:0x90000000D017E10] [SIGSEGV] [ADDR:0xFFFFFFFFDFFFB00] [PC:0x90000000D017E10] [Address not mapped to object] []
至此可以判斷該錯誤是由於rman在release channel時導致的。
mos上解釋是bug 17240394,oracle沒有給出原因和解決方案,一般這個錯誤可以忽略!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10271187/viewspace-1382464/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- ORA-07445: exception encountered: core dump [skgxpdmpctxException
- ORA-07445: exception encountered: core dump [kglpin()+527]Exception
- ORA-07445 exception encountered: core dump [kslgetl()+80]Exception
- ORA-07445: exception encountered: core dump [kgghtNumElements()Exception
- ORA-07445: exception encountered: core dump [ksxpunmap()+2742]Exception
- ORA-07445: exception encountered: core dump [qervwRowProcedure()+133]Exception
- ORA-07445 exception encountered: core dump。幫忙看看。Exception
- ORA-07445: exception encountered: core dump [qertbStart()+327] [SIGSEGV]ExceptionGse
- ORA-07445: exception encountered: core dump [ksxpunmap()+2742] [SIGSEGV]ExceptionGse
- ORA-07445: exception encountered: core dump [ptmak()+107]Exception
- ORA-07445: exception encountered: core dump [kglic0()+774]Exception
- ORA-07445: exception encountered: core dump [qkaqkn()+5390] [SIGSEGV]ExceptionGse
- ORA-07445: exception encountered: core dump [kgghstfel()+15] [SIGSEGV] ...ExceptionGse
- ORA-07445: exception encountered: core dump [__intel_new_memcpy()+5424]ExceptionIntelmemcpy
- move tablespace: ORA-07445:exception encountered: core dump [qcdlgtd()+182]Exception
- ORA-07445: exception encountered: core dump [kglpnp()+119] [SIGSEGV]ExceptionGse
- ORA-07445: exception encountered: core dump [CommonClientExit()+101] [SIGSEGV]ExceptionclientGse
- 報錯:ORA-07445: exception encountered: core dump [kkqtnloCbk()+111] [SIGSEGV]ExceptionQTGse
- ORA-07445: exception encountered: core dump [kksIsNLSEqual()+72] [SIGSEGV] [Address not mapped to obExceptionGseAPP
- ORA-07445: exception encountered: (一)Exception
- ORA-7445: exception encountered: core dump [kpodpals()+11332] [SIGSEGV]ExceptionGse
- 記一次ORA-07445: exception encountered: core dump [_intel_fast_memcpy.A()+10] [SIGSEGV] [Address not maExceptionIntelASTmemcpyGse
- 記一次ORA-07445: exception encountered: core dump [sdbgrfcvp_convert_pathinfo()+35] [SIGSEGV] [ADDR:0xFExceptionGse
- 11.2.0.1bug引發的報錯:ORA-07445: exception encounteredException
- ORA-07445: core dump [kpopfr()+673] [SIGFPE] [Integer divide by zero]IDE
- oracle10g中drop user造成ORA-07445 core dumpOracle
- Linux Core DumpLinux
- Linux core dump使用Linux
- 容器程式Core Dump處理
- java core dump分析實戰Java
- audit_file_dest, background_dump_dest, core_dump_dest, user_dump_dest
- Caffe訓練模型時core dump模型
- gdb除錯core dump檔案之二除錯
- core dump如何解決排查的過程
- 【求助】sqlplus出現core dump的提示SQL
- 學會用core dump除錯程式錯誤除錯
- .NET Core學習筆記(7)——Exception最佳實踐筆記Exception
- pytorch 程式碼出現 ‘segmentation fault (core dump)’ 問題PyTorchSegmentation