ORA-07445和ORA-00600是系統內部錯誤 查錯方法

ORA-07445和ORA-00600是系統內部錯誤，一般是由於BUG引起的，要解決或者避免這些錯誤一般需要到metalink上查。metalink甚至專門推出了一個工具用於這兩個錯誤的尋找。

與普通錯誤不同的是，ORA-07445和ORA-00600是一系列錯誤的總稱，引起錯誤的原因可能成千上萬個，如何快速、準確地找出到錯誤的原因是解決這類問題的痛點。
出現ORA-07445或ORA-00600錯誤時，一般都會產生一個trace檔案，這個檔案的路徑和名稱可以在alert檔案中找到。
這篇文章主要是談談如何在trace檔案找找出關鍵資訊。

 

1、ORA-07445

找出ORA-007445最關鍵是找出出錯的函數名（這裡的函數是指開發ORALCE的函數），然後根據函數名搜尋錯誤原因及解決方案。
ORA-07445後一般跟著若干個由[]括起來的字串，通常第一個被[]括起來的字串就是我們需要的函數名。
ORA-07445的報錯一般有兩種：
1）ORA-07445: exception encountered: core dump [lnxmin()+252] [SIGSEGV] [Address not mapped to object] [0x000000002] [] []
這種情況很簡單，第一個被[]括起來的字串是lnxmin，這就是引發錯誤的函數名，我們根據這個資訊去查就可以了。

2）ORA-07445: exception encountered: core dump [0000000100E84B7C] [SIGSEGV] [Address not mapped to object] [0x0000004F0] [] []
這種情況比較麻煩，因為oracle並沒有告訴我們出錯的函數名，0000000100E84B7C可能只是一個地址，無法根據這個來作為關鍵字進行查詢。
這時我們就要從trace檔案著手了。在trace檔案內容的前部分中的Call Stack Trace部分可以發現有用資訊。
對比一下多個trace檔案，可以發現在這種情況下Call Stack Trace一般都包含類似下面的內容：
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+328 CALL ksedst()+0 FFFFFFFF7FFF3BD0 ?
000000000 ? 000000000 ?
00000003E ?
FFFFFFFF7FFF4468 ?
1031D56C8 ?
ssexhd()+604 CALL ksedmp()+0 000000000 ? 000103400 ?
0001035D9 ? 000102C00 ?
1035D9000 ? 1035D9C28 ?
sigacthandler()+44 PTR_CALL 0000000000000000 1035E1000 ?
FFFFFFFF7FFF5400 ?
000000000 ? 000000001 ?
1035DEDD8 ? 00000000B ?
qsmkzii_init_qsmksi PTR_CALL 0000000000000000 00000000B ?
nline()+624 FFFFFFFF7FFF5400 ?
FFFFFFFF7FFF5120 ?
00000000B ? 00038001C ?
1035DC458 ?
qsmkzss_setup_summa CALL qsmkzii_init_qsmksi FFFFFFFF7CD12908 ?
ry()+480 nline()+0 000103000 ?
FFFFFFFF7CD93650 ?
000000000 ?
FFFFFFFF7CD93650 ?
103258100 ?
......

其中裡面的ksedmp、ssexhd、sigacthandler這三個函數在每一個ORA-07445 [0000000100E84B7C]類似的trace檔案都存在，這是進行oracle異常處理的，一般不用管。
stack的第一列的第四行的資訊就是我們需要的資訊：qsmkzii_init_qsmksinline，這個就是出錯的函數名。
在metalink根據這個函數名去尋找，一般就可以知道錯誤的原因和是否有合適的方面來解決、避免這個錯誤。
如果根據第四行的函數名得不到有用的資訊，可以嘗試一下第五行的資訊作為函數名，如果還是不能查到有用的資訊，則可以認為metalink上沒有這個錯誤的資訊。

2、ORA-00600
尋找ORA-00600的關鍵資訊比ORA-07445稍微簡單，它相當於ORA-07445的第一種情況。
ORA-00600後一般跟著若干個由[]括起來的字串，通常第一個被[]括起來的字串就是我們需要的參數。
ORA-00600的報錯資訊在從alert檔案和trace檔案都存在，不過為了得到更多的資訊，建議看trace檔案。
一個ORA-00600的trace檔案類似下面：
*** SESSION ID:(22.3813) 2004-10-26 09:57:13.167
*** 2004-10-26 09:57:13.167
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Current SQL statement for this session:
SELECT VALUE FROM NLS_INSTANCE_PARAMETERS WHERE PARAMETER ='NLS_DATE_FORMAT'
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+328 CALL ksedst()+0 FFFFFFFF7FFF9660 ?
000000000 ? 000000000 ?
00000003E ?
FFFFFFFF7FFF9EF8 ?
1031C9458 ?
kgerinv()+184 PTR_CALL 0000000000000000 000000000 ? 000103400 ?
0001035CD ? 000102C00 ?
1035CD000 ? 1035CD328 ?
kgeasnmierr()+28 CALL kgerinv()+0 1035CD588 ? 1036EDE38 ?
0000013C8 ? 000000001 ?
1035CF694 ? 1035CE958 ?
ttcgcshnd()+248 CALL kgeasnmierr()+0 1035CD588 ? 1036EDE38 ?
1033A2758 ? 000000001 ?
000000000 ? 000000000 ?
ttcc2u()+784 CALL ttcgcshnd()+0 1035CD588 ? 102DA4880 ?

上面的資訊中，ttcgcshnd-1就是我們要找的第一個參數，也是查詢的關鍵字。

3、trace中其他有用的資訊
在ORA-00600和ORA-07445的trace檔案都包含了一些其他的有用資訊。
在trace檔案的PROCESS STATE部分，可以查看出錯時SESSION的資訊，包含主機名稱、那個使用者執行的、用什麼工具執行的等。
這些資訊可能不太好找，尋找方法是：從trace檔案中找到PROCESS STATE，然後從PROCESS STATE往下找第一個"session"（關鍵字）出現的地方，這部分資訊就包含我們需要的這些重要訊息。

按照關鍵字"HOST"查可以得到用戶端的IP