标题比较长,没有办法,错误产生的时候出现的有意义的告警信息就是如此。
在同事的笔记本上出现,WindowsXP环境,在metalink上查询了一下,类似的错误还不少,而且基本上都是windows环境。这个错误发生之前只有一个操作,就是数据库建立。也就是说,在DBCA建库完成后,执行了一个SHUTDOWN操作,在SHUTDOWN快要结束的时候,出现了这个ORA-7445错误。
日志中的错误信息为:
Fri Jun 27 16:22:45 2008
Shutting down instance: further logons disabled
Fri Jun 27 16:22:46 2008
Stopping background process QMNC
Fri Jun 27 16:22:47 2008
Stopping background process CJQ0
Fri Jun 27 16:22:48 2008
Stopping background process MMNL
Fri Jun 27 16:22:49 2008
Stopping background process MMON
Fri Jun 27 16:22:50 2008
Shutting down instance (immediate)
License high water mark = 15
Fri Jun 27 16:22:50 2008
Stopping Job queue slave processes, flags = 7
Fri Jun 27 16:22:50 2008
Job queue slave processes stopped
Fri Jun 27 16:22:53 2008
ALTER DATABASE CLOSE NORMAL
Fri Jun 27 16:22:53 2008
SMON: disabling tx recovery
SMON: disabling cache recovery
Fri Jun 27 16:22:54 2008
Shutting down archive processes
Archiving is disabled
Fri Jun 27 16:22:59 2008
ARCH shutting down
ARC1: Archival stopped
Fri Jun 27 16:23:04 2008
ARCH shutting down
ARC0: Archival stopped
Fri Jun 27 16:23:05 2008
Thread 1 closed at log sequence 32
Successful close of redo thread 1
Fri Jun 27 16:23:05 2008
Completed: ALTER DATABASE CLOSE NORMAL
Fri Jun 27 16:23:05 2008
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Fri Jun 27 16:28:13 2008
Errors in file e:\oracle\product\10.2.0\db_1\rdbms\trace\jssweb_ora_5588.trc:
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x7C9306C3] [ADDR:0x650051] [UNABLE_TO_WRITE] []
而对应的trace文件中的信息为:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows XP Version V5.1 Service Pack 2
CPU : 2 - type 586
Process Affinity : 0x00000000
Memory (Avail/Total): Ph:1042M/2030M, Ph+PgF:3022M/3906M, VA:1902M/2047M
Instance name: jssweb
Redo thread mounted by this instance: 0
Oracle process number: 0
Windows thread id: 5588, image: ORACLE.EXE (SHAD)
*** 2008-06-27 16:28:13.109
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x7C9306C3] [ADDR:0x650051] [UNABLE_TO_WRITE] []
Current SQL information unavailable - no SGA.
check trace file e:\oracle\product\10.2.0\db_1\rdbms\trace\jssweb_ora_0.trc for preloading .sym file messages
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
7C9306C3 00000000
77E58179 CALL??? 00000000
77E5814B CALLrel 77E58157
77E5E272 CALLrel 77E58143
77E5EB6B CALLrel 77E5E251
77E5E946 CALLrel 77E5E2A6
76EF3320 CALLreg 00000000
77E5EA17 CALLreg 00000000
77E5EA42 CALLrel 77E5E995
77ED4588 CALLrel 77E59843
76EF7F97 CALLrel 76EF2D78 76EF2E88 76EF2B68 6D97410
76EF7F37 CALLrel 76EF7F81
76EF7EE3 CALLrel 76EF7F0F
76EF7D21 CALLrel 76EF7DF7
76EF2E26 CALLrel 76EF7CF0
719CA1E0 CALLrel 719C17AB
719CA336 CALLrel 719CA0ED
71A22FC5 CALLreg 00000000
71A22FA3 CALLrel 71A22FB1
71A22F6D CALLrel 71A22F8C
71A22F0B CALLrel 71A22F25
71A2576C CALLrel 71A22E99
71A25263 CALLrel 71A2570E
71A2516A CALLrel 71A251F8
62984CED CALL??? 00000000
62982202 CALLrel 62984CCC 81885A0 68D9E0C
609C4476 CALL??? 00000000
609AB019 CALLrel 609C436C
609B5F6E CALLrel 609AA858 6D98020 5 6D980E8 6D982F8
688EC50
609B9EF1 CALLrel 609B5E88
609B98E8 CALLrel 609B9EB4
609BA51D CALLrel 609B942C
6097C425 CALLrel 609BA234 68AC0A4 688EBEC 0 6D99674
688F1C4 688EC50
60978F10 CALLreg 00000000 6D9B048 A 60A59F54 10808
6D9D7C0 9BFE5E4 9BFE5DC
9BFE568 1543294 9C08AD8 0
6D99F38 60A59FD8
_kpkiadef+73 CALLrel _osncon+0 6D9FE2D A 10808 6D9D7C0
9BFE5E4 9BFE5DC 9BFE568
9BFE618 1543294 9C08AD8
_xupiini+643 CALLreg 00000000
_xupiah0+49 CALLrel _xupiini+0 9BFE540 6D9FE2D A 400 68873D0
68873D0 9BF7EE0
_upiah0+71 CALLrel _xupiah0+0 9BFE540 6D9FE2D A 400 68873D0
68873D0 9BF7EE0
_kpuatch+1007 CALLrel _upiah0+0
_OCIServerAttach+99 CALLrel _kpuatch+0
_opiino+622 CALLrel _OCIServerAttach+0 9BFE4C0 6886D38 6D9FE2D A 400
_opiodr+1286 CALLreg 00000000 3C 4 6D9FC24
_opidrv+819 CALLrel _opiodr+0 3C 4 6D9FC24 0
_sou2o+45 CALLrel _opidrv+0 3C 4 6D9FC24
_opimai_real+112 CALLrel _sou2o+0 6D9FC18 3C 4 6D9FC24
_opimai+92 CALLrel _opimai_real+0 2 6D9FC50
_OracleThreadStart@ CALLrel _opimai+0
4+726
7C80B680 CALLreg 00000000
METALINK上的解释也包括很多种。个人感觉Doc ID: Note:466370.1这篇文档的现象和描述比较接近。怀疑是操作系统本身的问题导致了Oracle的bug。
这个bug属于偶然出现的,再次重启,关闭数据库并未出现,可能和当时操作系统的状态有关,总的来说,对系统影响不大。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-366170/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-366170/