平台：Windows Server 2003 (32-bit)
数据库版本：10.2.0.3 

由于此数据库应用存在大量未使用绑定变量的SQL，造成了数据库性能较低，所以考虑将cursor_sharing由exact改为simliar来暂时解决这个问题。但是在修改cursor_sharing后，
在alert log中出现下列大量的07445错误，并且形成很多的trace文件（每个都在5Mb左右，10秒左右产生一个）

alert log中有下面的错误信息：
Tue May 27 10:34:16 2008
Errors in file d:\oracle\product\10.2.0\admin\mymiles\udump\mymiles_ora_1856.trc:
ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [_opidsa+360] [PC:0x2080540] [ADDR:0x0] [UNABLE_TO_READ] []

Tue May 27 10:34:26 2008
Errors in file d:\oracle\product\10.2.0\admin\mymiles\udump\mymiles_ora_3104.trc:
ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [_opidsa+360] [PC:0x2080540] [ADDR:0x0] [UNABLE_TO_READ] []

Tue May 27 10:36:47 2008
Errors in file d:\oracle\product\10.2.0\admin\mymiles\udump\mymiles_ora_980.trc:
ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [_opidsa+360] [PC:0x2080540] [ADDR:0x0] [UNABLE_TO_READ] []

Tue May 27 10:37:01 2008
Errors in file d:\oracle\product\10.2.0\admin\mymiles\udump\mymiles_ora_1052.trc:
ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [_opidsa+360] [PC:0x2080540] [ADDR:0x0] [UNABLE_TO_READ] []

trace文件有下列信息：
*** SERVICE NAME:(mymiles) 2008-05-27 10:34:16.781
*** SESSION ID:(109.224) 2008-05-27 10:34:16.781
*** 2008-05-27 10:34:16.781
ksedmp: internal or fatal error
ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [_opidsa+360] [PC:0x2080540] [ADDR:0x0] [UNABLE_TO_READ] []
Current SQL statement for this session:
select cd.cp_id 
from CP_DICT cd
where cd.cp_tel=:"SYS_B_0"

======省略部分内容======

    SO: 5AB3C05C, type: 4, owner: 5AA8C9DC, flag: INIT/-/-/0x00
    (session) sid: 109 trans: 00000000, creator: 5AA8C9DC, flag: (c0100041) USR/- BSY/-/-/-/-/-
              DID: 0001-0029-000000BE, short-term DID: 0000-0000-00000000
              txn branch: 00000000
              oct: 3, prv: 0, sql: 50AFAD94, psql: 2C5AE504, user: 63/ELITE
    O/S info: user: Administrator, term: SVCTAG-FNT942X, ospid: 3060:4080, machine: WORKGROUP\SVCTAG-FNT942X
              program: EliteGeneralServer.exe
    application name: EliteGeneralServer.exe, hash value=0
    last wait for 'SQL*Net message from client' blocking sess=0x00000000 seq=2812 wait_time=232 seconds since wait started=1
                driver id=54435000, #bytes=1, =0
    Dumping Session Wait History
     for 'SQL*Net message from client' count=1 wait_time=232
                driver id=54435000, #bytes=1, =0
     for 'SQL*Net message to client' count=1 wait_time=1
                driver id=54435000, #bytes=1, =0
     for 'SQL*Net message from client' count=1 wait_time=292
                driver id=54435000, #bytes=1, =0
     for 'SQL*Net message to client' count=1 wait_time=2
                driver id=54435000, #bytes=1, =0
     for 'SQL*Net message from client' count=1 wait_time=473094
                driver id=54435000, #bytes=1, =0
     for 'SQL*Net message to client' count=1 wait_time=2
                driver id=54435000, #bytes=1, =0
     for 'SQL*Net message from client' count=1 wait_time=4181
                driver id=54435000, #bytes=1, =0
     for 'SQL*Net message to client' count=1 wait_time=3
                driver id=54435000, #bytes=1, =0
     for 'db file scattered read' count=1 wait_time=1097
                file#=4, block#=4454, blocks=5
     for 'db file sequential read' count=1 wait_time=6462
                file#=4, block#=4453, blocks=1
    temporary object counter: 0

根据以上信息怀疑是由BUG引起的。上metalink一查找：原来是由BUG.5648872引起的。但Windows平台上没有此BUG相应的Patch，暂时只能使用alter system flush shared_pool顶着了。

PS:在yangtingkun大侠的一篇文章http://space.itpub.net/4227/viewspace-69468t中提到这个BUG可能是PL/SQL Developer版本5连接10g数据库造成的，看来也不完全是由这种情况造成的。