目的

本文檔主要介紹ora-07445錯誤相關內容，并給出了對這個錯誤的進一步診斷建議，文檔主要基于unix系統編寫，但原理通用。

文檔適用范圍

主要為DBA處理系統的ora-07445錯誤時使用。

0ra-07445錯誤的定義

當oracle服務器進程從操作系統收到一個致命的錯誤信息時會拋出ora-07445錯誤，這個錯誤可以被oracle后臺進程或者用戶進程激發。當錯誤被拋出時，系統會首先寫一個錯誤日志到alert.log文件中，然后會寫跟蹤文件到user_dump_dest或background_dump_dest中；最后會將主存信息轉儲到core_dump_dest中。

操作系統有很多的非法操作設計，一個經常會碰到的情況就是，當一個進程訪問一個非法地址（比如系統預留地址）時致命錯誤將會產生。

Ora-07445錯誤是一個非常普通的錯誤，可能在oracle的任何代碼中產生，該錯誤代碼更詳細的描述需要進一步跟蹤其跟蹤文件。

Ora-07445的表現方式

在不同的平臺上，ora-07445可能出現的情況有所不同，兩種比較經常出現的方式如下所示：

實例1

ORA-07445: exception encountered: core dump [run_some_SQL()+268] [SIGBUS] [Invalid address alignment] [] [] []

實例2
ORA-07445: exception encountered: core dump [10] [2122262800] [261978112] [] [] []

實例1說明：

l???????? 錯誤發生在函數run_some_sql()中

l???????? 進程收到的信號是SIGBUS

l???????? 一些其他相關信息。

實例2給定的信息相對較少

l???????? 沒有給出導致錯誤的函數名稱

l???????? 進程收到的信息是signal 10

l???????? 一些在本次錯誤中無用的信息

錯誤發生時需要搜集哪些信息

1，? alert.log文件，這個文件至少可以查出ora-07445錯誤發生前后的其他相關錯誤，確認init.ora文件信息也包含在里邊。

2，? 自實例上次啟動以來所有的ora-07445和ora-00600錯誤及其跟蹤文件。

?

Trace file文件中信息的相關說明

??? *** 2002-05-08 23:35:18.224???? <---timestamp
*** SESSION ID:(194.14075) 2002-05-08 23:35:18.202
Exception signal: 10 (SIGBUS), code: 1 (Invalid address alignment), addr: 0x41e7, PC: kjrfnd()+44
*** 2002-05-08 23:35:19.404
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [kjrfnd()+44] [SIGBUS] [Invalid
address alignment] [16871] [] []???? <----the errror
Current SQL statement for this session:?? <---the current SQL statement
DELETE FROM MY_TABLE WHERE COL1 < :b1
----- PL/SQL Call Stack -----
? object?? ???line? object
? handle?? ?number? name
e560c680??? ????35? anonymous block
e560c680??? ???290? anonymous block
----- Call Stack Trace -----?????????? <----Stack trace starts here
calling??? ??????????call?? ?? entry?????????? ?????argument values in hex
location??? ????????type?? point? ????????????? ?(? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+168?? ????????CALL???? ????????ksedst()+0??? ????????540 ? 0 ? FFBE4F98 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ?FFBE4A3C ? FFBE4A20 ? 0 ?
ssexhd()+380?? ?????????CALL??? ?????????ksedmp()+0?? ??????? 3 ? 0 ? 1 ? FFBE56B8 ? 1 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ?6 ?
sigacthandler()+40? ?PTR_CALL?? 00000000??????? ??????A ? FFBE5F10 ? 19FE000 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ?19FE000 ? 0 ? 0 ?
kjrfnd()+44?? ????????????? ?PTR_CALL 00000000????????? ?????A ? FFBE5F10 ? FFBE5C58 ?
kjrref()+176?? ????????????? CALL???????????? kjrfnd()+0??????????? 4177 ? F6A7F020 ? 0 ? 41DF ?
kjuocl()+732?? ???????????? CALL???????????? kjrref()+0??????????? ?FFBE63AC ? 19FA400 ?
kjusuc()+1260?? ?????????CALL??? ?????????kjuocl()+0?? ?????????FFBE6218 ? EB5FB9A8 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ?EB5FB9A8 ? 5 ? 5 ? 0 ?
ksipget()+832?? ??????????CALL?? ??????????kjusuc()+0? ?????????19FA400 ? FFBE63AC ? 0 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ??E2A2ED40 ? 19FA400 ? 8 ?
ksqcmi()+3356?? ?????????CALL??? ?????????ksipget()+0?? ???????10020 ? FFBE6648 ? EE15430C ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ??0 ? 0 ? 0 ?
ksqgtl()+944?? ????????????CALL ???????????? ksqcmi()+0????????? FFBE65A8 ? 1 ? EDEB4C90 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ??EE1542D4 ? 1 ? 0 ?
<... lots of stuff deleted here ...>
sou2o()+20?? ????????????? ?CALL??????????? ?opidrv()+0?????????? 3C ? FFBEF784 ? 19F8000 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ???2F6C6F67 ? 0 ? 0 ?
main()+160?? ????????????? ??CALL?????????? ??sou2o()+0????????? ??FFBEFA80 ? 3C ? 4 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ???FFBEFA70 ? 1746CF4 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ???1A06318 ?
_start()+220?? ????????????? CALL???????????? main()+0??????????? ???0 ? FFBEFC2C ? 1A1D478 ?
???? ????????????? ????????????? ????????????? ????????????? ????????????? ????????????? ??19F8000 ? 0 ? 0 ?
?????? ????????????? ????????????? ????????????? ?????????? <----Stack trace ends here
----- Argument/Register Address Dump -----

重現錯誤

如果客戶可以隨意的重現ora-07445錯誤，那么診斷并解決問題的時間將會被縮短。重現錯誤的第一步當然是找出造成錯誤的current sql。

文檔Note 154170.1中主要描述了怎么查找當前錯誤的執行語句。但我們需要注意的是，當前問題可能是由于前面幾個相關的其他語句執行時的上下文環境決定是否能出問題，所以有可能找到當前語句但無法重現問題。

在找到系統出錯時執行的語句后我們需要確認下面的問題：

l???????? 是不是只有在當前參數時系統才會報錯

l???????? 是否在每天的固定時間點出錯

l???????? 出錯跟哪些系統操作有主要關聯，比如數據庫的備份或者其他高消耗操作

l???????? 是在特定的應用程序和用戶下出錯還是所有的程序和用戶都出錯

l???????? 第一次報錯是什么時間，當時對系統做了什么改變

l???????? 系統出錯時有沒有伴隨其他的錯誤產生

?

?

?

如何找出錯誤ora-07445發生時系統執行的語句

在trace file中查找錯誤出現時的語句主要分兩個步驟：首先找到錯誤發生時的執行語句，然后需要找到語句中綁定變量的值。

Step 1：Find the SQL

在跟蹤文件中查找字符串“Current cursor”（一般在cursor dump段的起始部分），使用current cursor后面的數字定位出錯時系統的執行語句。

如果找到的這個數字為0說明沒有dump出有效的執行語句。

如果找到的這個數字n不為0，接著往下查找，定位到字符串“cursor n”其中n為剛找到的數字。從10.2版本后，你可能需要定位到字符串“cursor #n”，這里cursor name后面跟隨的語句就是我們需要的sql。

另外我們也可以通過查找字符串“Current SQL statement for this session”來定位我們需要查找的sql語句，通常情況下，這個語句出現在trace file文件的開始部分。

如果定位到的sql語句中引用了變量（：a1…）那么我們需要通過下面步驟2找出綁定的變量值。

Step 2：find values of the bind variables

如果定位得到的sql語句中出現了綁定變量，那么我們將會在cursor name后面發現”bind *”之類的字符串，其中×為0到n-1的值，n為sql語句中綁定變量的個數。

對每個綁定變量都有一系列的屬性說明列表，下面簡單描述列表后面的屬性。

Dty : databype 1 varchar2 or nvarchar2

??????????? 2 number

??????????? 8 long

??????????? 11 rowid

??????????? 12 date

??????????? 23 raw

??????????? 24 long raw

??????????? 96 char

??????????? 112 clob or nclob

??????????? 113 blob

??????????? 114 bfile

Mxl: the maximum lenth

Scl: the scale(for number columns)

Pre: the precision(for number columns)

Value: 綁定變量的值

??? 通過解析上面的內容，你可以得到綁定變量的類型及其數據值，也有一些情況（非常少），你在bind *后面找不到values字節，那么我們就不能通過這種方式得到綁定變量的值。

Examples

In the following we will work through some examples of how to extract the SQL statement from trace files.

IMPORTANT: Replacing bind variables with literals can result in the optimizer choosing a different query path and thus the problem may not reproduce!

Example 1:

You should now be able to find the datatype of the bind variable (including length, scale, and precision if applicable) and the value.

The cursor dump starts with:

******************** Cursor Dump ************************
Current cursor: 2, pgadep: 1
Cursor Dump:
----------------------------------------

so we are looking for cursor 2:

----------------------------------------
Cursor 2 (20139ad0): CURFETCH curiob: 2013bca4
curflg: 7 curpar: 20139ab0 curusr: 0 curses 587a250c
cursor name: select text from view$ where rowid=:1
child pin: 50a5b650, child lock: 50a5a628, parent lock: 50a5a844
xscflg: 20141466, parent handle: 4f348490, xscfl2: 400
nxt: 2.0x0000006c nxt: 1.0x000001d8
Cursor frame allocation dump:
frm: -------- Comment -------- Size Seg Off
bhp size: 52/560
bind 0: dty=11 mxl=16(16) mal=00 scl=00 pre=00 oacflg=18 oacfl2=1 size=16
offset=0
bfp=2013e9f4 bln=16 avl=16 flg=05
value=0000138C.0046.0004

The current SQL is:

select text from view$ where rowid=:1

and the bind variable translates into:

:1 ~ bind 0 - ROWID (dty=11), value = 0000138C.0046.0004

so we can eg. reconstruct the original SQL statement as:

SQL> variable a1 varchar2(20)
SQL>?exec :a1 := '0000138C.0046.0004';
SQL>?select text from view$ where rowid=:a1;

Note that we construct the statement using a SQL*Plus bind variable in order to prevent the optimizer from choosing a different plan (not that it would make any difference for this particular example).

Example 2:
The cursor dump starts with:

******************** Cursor Dump ************************
Current cursor: 11, pgadep: 1
Cursor Dump:
----------------------------------------

ie. we should look for cursor 11:

----------------------------------------
Cursor 11 (202cb9f0): CURBOUND curiob: 202f8b04
curflg: dd curpar: 0 curusr: 0 curses 30047c7c
cursor name: SELECT LOCKID FROM DBMS_LOCK_ALLOCATED WHERE NAME =
:b1 FOR UPDATE
child pin: 0, child lock: 300dc9b4, parent lock: 301730b8
xscflg: 1151421, parent handle: 3025b4dc
bind 0: dty=1 mxl=32(00) mal=00 scl=00 pre=00 oacflg=01
No bind buffers allocated
----------------------------------------

The current SQL statement is then:

SELECT LOCKID FROM DBMS_LOCK_ALLOCATED WHERE NAME = :b1 FOR UPDATE

The bind variable :b1 is of type VARCHAR2(32) (dty=1, mxl=32), but no value has been assigned to it at the time of the dump ("No bind buffers allocated").

Example 3:

******************** Cursor Dump ************************
Current cursor: 2, pgadep: 0
Cursor Dump:
----------------------------------------
...
----------------------------------------
Cursor 2 (20140444): CURNULL curiob: 0
curflg: 44 curpar: 0 curusr: 0 curses 701dc94c
----------------------------------------

In this case there is no SQL being executed at the time of the dump.

Example 4:

******************** Cursor Dump ************************
Current cursor: 1, pgadep: 0
pgactx: ccf361c0 ctxcbk: 0 ctxqbc: 0 ctxrws: 0
Cursor Dump:
----------------------------------------
Cursor 1 (400d9478): CURBOUND curiob: 400e43d8
curflg: 4c curpar: 0 curusr: 0 curses d5348f80
cursor name: BEGIN myparser.convert('/tmp','workflow000_2.log',2); END;
child pin: d14a4d70, child lock: d1589968, parent lock: d14c64a0
xscflg: 100064, parent handle: d083f1c0, xscfl2: 4040408
nxt: 1.0x000000a8
Cursor frame allocation dump:
frm: -------- Comment -------- Size Seg Off

總結

以上是生活随笔為你收集整理的项目中遇到的ORA error 及解决办法 ---ora-07445的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。