本文档主要介绍ora-07445 错误相关内容，并给出了对这个错误的进一步诊断建议，文档主要基于unix
ora-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]
实例2
ORA-07445: exception encountered: core dump [10] [2122262800] [261978112] [] [] []
实例1 说明：
错误发生在函数run_some_sql() 中
进程收到的信号是SIGBUS
一些其他相关信息。
实例2 给定的信息相对较少：
没有给出导致错误的函数名称
进程收到的信息是signal 10
一些在本次错误中无用的信息 错误发生时需要搜集哪些信息
错误发生时需要搜集哪些信息错误发生时需要搜集哪些信息
错误发生时需要搜集哪些信息
1 、alert.log 文件，这个文件至少可以查出ora-07445 文件信息也包含在里边。
2、 自实例上次启动以来所有的ora-07445 和ora-00600 错误及其跟踪文件。Trace file
*** SESSION ID:(194.14075) 2002-05-08 23:35:18.202 <--- timestamp
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
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) -------------------- -------- -------------------- ----------------------------
ksedst+001c bl ksedst1 000000001 ? 000000000 ?
ksedmp+0290 bl ksedst 104C20490 ?
ssexhd+03e0 bl ksedmp 300001D15 ?
000047DC ? 00000000
pfrinstr_DEFINE+004 bl pevm_DEFINE 1000000000028 ? 0FFFF6F80 ?
0 110AB4328 ? 7000007198E2C28 ?
110FEE460 ? 000000000 ?
pfrrun_no_tool+005c bl _ptrgl
pfrrun+1064 bl pfrrun_no_tool FFFFFFFFFFF7548 ? 110CAC9A0 ?
FFFFFFFFFFF6FA0 ?
plsql_run+06e8 bl pfrrun 110B15F60 ?
peicnt+0244 bl plsql_run 110B15F60 ? 10001004640A4 ?
000000000 ?
kkxexe+0250 bl peicnt FFFFFFFFFFF82D8 ? 110B15F60 ?
opiexe+3024 bl kkxexe 110CAC9A0 ?
kpoal8+0ef0 bl opiexe FFFFFFFFFFFB954 ?
FFFFFFFFFFFB6C0 ?
FFFFFFFFFFF9AF0 ?
opiodr+0b2c bl _ptrgl
ttcpip+1020 bl _ptrgl
opitsk+117c bl 01FC70C8
opiino+09d0 bl opitsk 0FFFFD920 ? 000000000 ?
opiodr+0b2c bl _ptrgl
opidrv+04a4 bl opiodr 3C102A2E38 ? 404C734B0 ?
FFFFFFFFFFFF8E0 ? 0102A2E30 ?
sou2o+0090 bl opidrv 3C02A2911C ? 4A15F6CE0 ?
FFFFFFFFFFFF8E0 ?
opimai_real+01bc bl 01FC3934
main+0098 bl opimai_real 000000000 ? 000000000 ?
__start+0070 bl main 000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------
========== FRAME [1] (ksedst+001c -> ksedst1) ==========
Dump of memory from 0x00000001103A43F0 to 0x00000001103A4460
1103A43F0 00000001 103A4460 42222240 00000000 [.....:D`B""@....]
1103A4400 00000001 0000AC20 42222248 00000000 [....... B""H....]
1103A4410 09000000 00004940 00000000 00000000 [......I@........]
1103A4420 00000000 00000001 00000000 00000000 [................]
1103A4430 00000000 00000000 00000000 00000003 [................]
1103A4440 00000000 00000001 00000001 10009480 [................]
1103A4450 00000000 00000000 00000001 103A4460 [.............:D`]
========== FRAME [2] (ksedmp+0290 -> ksedst) ==========
Dump of memory from 0x00000001103A4460 to 0x00000001103A4860
1103A4460 00000001 103A4890 42222481 00000020 [.....:H.B"$.... ]
1103A4470 00000001 0000B454 00000001 103A45D4 [.......T.....:E.]
1103A4480 00000000 88226828 00000000 00000000 [....."h(........]
1103A4490 00000001 04C20490 00000000 00000000 [................]
..................................省略若干行..............................
========== FRAME [14] (ttcpip+1020 -> _ptrgl) ==========
Dump of memory from 0x0FFFFFFFFFFFB260 to 0x0FFFFFFFFFFFB360
FFFFFFFFFFFB260 0FFFFFFF FFFFB830 44A42B80 00000027 [.......0D.+....']
FFFFFFFFFFFB270 00000001 00C085C4 00000001 102325E0 [.............#%.]
FFFFFFFFFFFB280 0FFFFFFF FFFFB440 00000001 102325E0 [.......@.....#%.]
FFFFFFFFFFFB290 0000005E 100D4360 00000017 00000760 [...^..C`.......`]
FFFFFFFFFFFB2A0 0FFFFFFF FFFFB950 00000000 108FD070 [.......P.......p]
FFFFFFFFFFFB2B0 0001FFFF FFFFB3A0 004D0020 0054005A [.........M. .T.Z]
FFFFFFFFFFFB2C0 00520000 00000000 00000000 00000000 [.R..............]
FFFFFFFFFFFB2D0 0000FFFF FFFFFFAA 00010000 00000000 [................]
FFFFFFFFFFFB2E0 00000000 00010000 00170001 108DCE10 [................]
FFFFFFFFFFFB2F0 0FFFFFFF FFFFB3C0 00000000 00000000 [................]
FFFFFFFFFFFB300 00000000 00000000 00000000 00000000 [................]
FFFFFFFFFFFB310 00000000 00000000 00000002 D37C77C0 [.............|w.]
FFFFFFFFFFFB320 00000000 0000000F 00000001 100D8C90 [................]
FFFFFFFFFFFB330 0033CE65 6AFD326F 00000000 0000000A [.3.ej.2o........]
FFFFFFFFFFFB340 0FFFFFFF FFFFB3C0 00000001 100D44B0 [..............D.]
FFFFFFFFFFFB350 00000001 10009480 0FFFFFFF FFFFB528 [...............(]
<----Stack trace ends here----- Argument/Register Address Dump -----
重现错误
重现错误如果客户可以随意的重现ora-07445错误，那么诊断并解决问题的时间将会被缩短。重现错误的第一步当然是找出造成错误的current sql。
文档Note 154170.1中主要描述了怎么查找当前错误的执行语句。但我们需要注意的是，
当前问题可能是由于前面几个相关的其他语句执行时的上下文环境决定是否能出问题，所以
有可能找到当前语句但无法重现问题。在找到系统出错时执行的语句后我们需要确认下面的问题：
是不是只有在当前参数时系统才会报错
是否在每天的固定时间点出错
出错跟哪些系统操作有主要关联，比如数据库的备份或者其他高消耗操作
是在特定的应用程序和用户下出错还是所有的程序和用户都出错
第一次报错是什么时间，当时对系统做了什么改变
系统出错时有没有伴随其他的错误产生
如何找出 ora-07445发生时系统执行的语句
Step 1Find 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字节，那么我们就不能通过这种方式得到绑定变量的值。
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
----------------------------------------
No binds included, so the SQL statement is the PL/SQL block:
BEGIN myparser.convert('/tmp','workflow000_2.log',2); END;
参考至：http://wenku.baidu.com/view/e64ee51ba8114431b90dd841.html
如有错误，欢迎指正
