ORA-07445異常報錯opixguid()+13

資料庫版本為11.2.0.4，資料庫alert不不時丟擲異常告警：

ORA-07445: 出現異常錯誤: 核心轉儲 [opixguid()+13] [SIGSEGV] [ADDR:0x7F67B7F4EBC0] [PC:0x648BB7D] [Address not mapped to object] []

Dump file /oracle/app/oracle/diag/rdbms/orcl/orcl1/incident/incdir_1392049/orcl1_ora_75913_i1392049.trc

檢查 orcl1_ora_75913_i1392049.trc日誌：

Dump continued from file: /oracle/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_75913.trc

ORA-07445: 出現異常錯誤: 核心轉儲 [opixguid()+13] [SIGSEGV] [ADDR:0x7F67B7F4EBC0] [PC:0x648BB7D] [Address not mapped to object] []

========= Dump for incident 1392049 (ORA 7445 [opixguid()+13]) ========

----- Beginning of Customized Incident Dump(s) -----

Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x7F67B7F4EBC0] [PC:0x648BB7D, opixguid()+13] [flags: 0x0, count: 1]

Registers:

%rax: 0x00007f67b7f4eba0 %rbx: 0x00007fcf2bbe99f0 %rcx: 0x00007fff0e82afc8

%rdx: 0x00007fff0e82adec %rdi: 0x00000015310cb5d0 %rsi: 0x00007fff0e82ade8

%rsp: 0x00007fff0e82ab60 %rbp: 0x00007fff0e82ab60 %r8: 0x0000000000000000

%r9: 0x0000000000000001 %r10: 0x0000000000000000 %r11: 0x0000000000000000

%r12: 0x00000015310cbca0 %r13: 0x00007fcf2bbe99f0 %r14: 0x00000015310cb5d0

%r15: 0x00007fff0e82afc8 %rip: 0x000000000648bb7d %efl: 0x0000000000010206

opixguid()+1 (0x648bb71) mov %rsp,%rbp

opixguid()+4 (0x648bb74) mov 0x40(%rdi),%rax

opixguid()+8 (0x648bb78) test %rax,%rax

opixguid()+11 (0x648bb7b) je 0x648bb8b

> opixguid()+13 (0x648bb7d) mov 0x20(%rax),%eax

opixguid()+16 (0x648bb80) mov %eax,(%rsi)

opixguid()+18 (0x648bb82) xor %eax,%eax

opixguid()+20 (0x648bb84) mov %eax,(%rdx)

opixguid()+22 (0x648bb86) mov %rbp,%rsp

*** 2024-02-21 00:14:07.913

dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0)

----- Current SQL Statement for this session (sql_id=bnkanq9uxrv08) -----

SELECT * FROM V_GY_YONGHUXX WHERE YONGHUGH=:YONGHUGH ORDER BY YONGHUID

----- Call Stack Trace -----

calling call entry argument values in hex

location type point (? means dubious value)

-------------------- -------- -------------------- ----------------------------

skdstdst()+41 call kgdsdst() 000000000 ? 000000000 ?

7FCF2BD65C40 ? 7FCF2BD65D18 ?

7FCF2BD6A7C0 ? 000000003 ?

ksedst1()+103 call skdstdst() 000000000 ? 000000000 ?

7FCF2BD65C40 ? 7FCF2BD65D18 ?

7FCF2BD6A7C0 ? 000000003 ?

ksedst()+39 call ksedst1() 000000001 ? 000000001 ?

7FCF2BD65C40 ? 7FCF2BD65D18 ?

7FCF2BD6A7C0 ? 000000003 ?

dbkedDefDump()+2746 call ksedst() 000000001 ? 000000001 ?

7FCF2BD65C40 ? 7FCF2BD65D18 ?

7FCF2BD6A7C0 ? 000000003 ?

ksedmp()+41 call dbkedDefDump() 000000003 ? 000000003 ?

7FCF2BD65C40 ? 7FCF2BD65D18 ?

7FCF2BD6A7C0 ? 000000003 ?

ssexhd()+2462 call ksedmp() 000000003 ? 000000003 ?

7FCF2BD65C40 ? 7FCF2BD65D18 ?

7FCF2BD6A7C0 ? 000000003 ?

__sighandler() call ssexhd() 00000000B ? 7FCF2BD6BBF0 ?

7FCF2BD6BAE8 ? 7FCF2BD65D18 ?

7FCF2BD6A7C0 ? 000000003 ?

opixguid()+13 signal __sighandler() 15310CB5D0 ? 7FFF0E82ADE8 ?

7FFF0E82ADEC ? 7FFF0E82AFC8 ?

000000000 ? 000000001 ?

ddfnet3Share()+129 call opixguid() 15310CB5D0 ? 7FFF0E82ADE8 ?

7FFF0E82ADEC ? 7FFF0E82AFC8 ?

000000000 ? 000000001 ?

kksarm()+700 call ddfnet3Share() 15310CBCA0 ? 7FCF2BBE99F0 ?

15310CB5D0 ? 7FFF0E82AFC8 ?

000000000 ? 000000001 ?

kksauc()+721 call kksarm() 15310CBCA0 ? 7FCF2BBE99F0 ?

000000000 ? 7FFF0E82AFC8 ?

000000000 ? 000000001 ?

kkscscid_auc_eval() call kksauc() 7FCF2BBE99F0 ? 7FFF0E82C4F0 ?

+371 000000000 ? 7FFF0E82AFC8 ?

000000000 ? 000000001 ?

kkscsCheckCriteria( call kkscscid_auc_eval() 00C3189C0 ? 7FCF2BBE99F0 ?

)+1986 15531B2618 ? 7FFF0E82C4F0 ?

000000000 ? 000000001 ?

kkscsCheckCursor()+ call kkscsCheckCriteria( 000000027 ? 7FFF0E82C4F0 ?

783 ) 7FCF2BBE99F0 ? 7FFF0E82C4F0 ?

000000000 ? 000000001 ?

從中看到只是查詢V_GY_YONGHUXX這個試圖，檢查試圖資料就幾百條，也不至於記憶體不夠。

透過文件 Troubleshooting ORA-7445 [opixguid] (Doc ID 1469649.1)內容符合這個問題。

原因：

這是一個bug導致。

解決：

修改：

SQL> alter system set OPEN_LINKS =100 scope=spfile;

重啟例項， ORA-7445 [OPIXGUID()+13]報錯不在產生。