在Oracle 10.2.0.4 RAC for Windows环境的告警日志中发现了这个错误。
Windows下的Oracle维护的不多，而Windows下的RAC就更少见了，而对应的这个错误也是比较少见的：
Wed Oct 13 13:00:07 2010 Errors IN file c:\app\oracle\product\10.2.0\admin\cam\bdump\cam1_arc1_6052.trc: ORA-16038: 日志 2 SEQUENCE# 508 无法归档。 ORA-19504: 无法创建文件"" ORA-00312: 联机日志 2 线程 1: '+CAM/cam/onlinelog/group_2.266.724245379' Wed Oct 13 13:00:32 2010 Errors IN file c:\app\oracle\product\10.2.0\admin\cam\bdump\cam1_m000_3972.trc: ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x7FEFE115160] [ADDR:0xFFFFFFFFFFFFFFFF] [UNABLE_TO_READ] [] |
导致这个ORA-7445错误的是M000进程，说明是AWR快照生成时导致的错误，检查详细的错误信息：
*** ACTION NAME:(Auto-FLUSH Slave Action) 2010-10-13 13:00:32.504 *** MODULE NAME:(MMON_SLAVE) 2010-10-13 13:00:32.504 *** SERVICE NAME:(SYS$BACKGROUND) 2010-10-13 13:00:32.504 *** SESSION ID:(48.9158) 2010-10-13 13:00:32.504 *** 2010-10-13 13:00:32.504 ksedmp: internal OR fatal error ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x7FEFE115160] [ADDR:0xFFFFFFFFFFFFFFFF] [UNABLE_TO_READ] [] CURRENT SQL statement FOR this SESSION: INSERT INTO wrh$_comp_iostat (SNAP_ID, DBID, INSTANCE_NUMBER, COMPONENT, FILE_TYPE, IO_TYPE, OPERATION, BYTES, IO_COUNT) SELECT :snap_id, :dbid, :instance_number, 'RMAN', 'DATAFILE', is_sync, TYPE, SUM(bytes), SUM(io_count) FROM (SELECT decode(x.type, 1, 'READ', 'WRITE') AS TYPE, CASE WHEN (bitand(x.flags, 2) = 0) THEN 'SYNC' ELSE 'ASYNC' END AS is_sync, x.blocks * x.block_size AS bytes, CASE WHEN (bitand(x.flags, 2) = 0) THEN (x.sync_count) ELSE (x.async_short_count + x.async_long_count + x.async_ready) END AS io_count FROM x$ksfqp x, v$dbfile df WHERE x.type IN (1,2) AND df.name = x.filename) GROUP BY is_sync, TYPE CHECK trace file c:\app\oracle\product\10.2.0\db_1\rdbms\trace\cam1_ora_0.trc FOR preloading .sym file messages ----- Call Stack Trace ----- calling CALL entry argument VALUES IN hex location TYPE point (? means dubious VALUE) -------------------- -------- -------------------- ---------------------------- 000007FEFE115160 0000000000000000 000000000 000000000 000000000 000000000 ksfqpcb+289 CALL??? 000007FEFE115160 000000000 000000000 2A2D4F668 0000003BA qerfxFetch+1946 CALL??? ksfqpcb+289 021640168 000000000 000000000 000000001 rwsfcd+109 CALL??? qerfxFetch+1946 2A2D4F868 000007FFF 0239D6210 2A2D4E7F0 qerhjFetch+569 CALL??? rwsfcd+109 00001F430 005559DD8 7FF4DBC5C48 7FF0FDB2DC8 qergsFetch+637 CALL??? qerhjFetch+569 02030FCF8 000000108 000000000 0211452A8 rwsfcd+109 CALL??? qergsFetch+637 7FF4DBC56C0 7FF0E13002E 000000000 7FF3A922C50 insfch+132 CALL??? rwsfcd+109 0211452A8 021145350 021144A94 021145338 insdrv+762 CALL??? insfch+132 000000000 000000000 7FF4DBC5C48 0239D6210 inscovexe+470 CALL??? insdrv+762 02030C1D8 000000018 000000000 000000000 insExecStmtExecIniE CALL??? inscovexe+470 2A2D53420 2A2D4D3E8 021145D98 ngine+99 000000002 insexe+453 CALL??? insExecStmtExecIniE 000000003 000000031 000000000 ngine+99 0239D6210 opiexe+4991 CALL??? insexe+453 2A2D52DA0 021145D98 000000102 000000000 kpoal8+2139 CALL??? opiexe+4991 000000049 000000003 021146380 000000001 opiodr+1136 CALL??? kpoal8+2139 00000005E 000000000 02114A0E8 0000003C8 kpoodrc+30 CALL??? opiodr+1136 00000005E 000000000 02114A0E8 000000000 rpiswu2+517 CALL??? kpoodrc+30 0239D69D0 000000000 000000000 0239D69D0 kpoodr+666 CALL??? rpiswu2+517 2B7048898 000000000 0202E9EF4 000000002 xupirtrc+2119 CALL??? kpoodr+666 01010CA90 0202F6238 02114A058 000433555 upirtrc+123 CALL??? xupirtrc+2119 000000000 0101463E7 000000000 02114A250 kpurcsc+153 CALL??? upirtrc+123 000000000 0056EBE5D 02114B930 0202F6328 kpuexecv8+1661 CALL??? kpurcsc+153 02114AA10 077338666 0202F6328 02114C901 kpuexec+1680 CALL??? kpuexecv8+1661 224D2829BFEF 0202FF120 000000065 0052B55FA OCIStmtExecute+68 CALL??? kpuexec+1680 000000010 000000001 000000000 000000000 kewrose_oci_stmt_ex CALL??? OCIStmtExecute+68 020000021 7FF812517B0 ec+80 004032B0D 0202FF120 kewrgwxf1_gwrsql_ex CALL??? kewrose_oci_stmt_ex 000000000 000000000 00000004C ft_1+378 ec+80 000000000 kewrgwxf_gwrsql_exf CALL??? kewrgwxf1_gwrsql_ex 000000000 000000000 t+571 ft_1+378 7FFDEADBEEF 000000000 kewrews_execute_wr_ CALL??? kewrgwxf_gwrsql_exf 000000000 02114DEC8 034B245C0 SQL+70 t+571 200000015 kewrftbs_flush_tabl CALL??? kewrews_execute_wr_ 003C89940 00001E650 00001E788 e_by_sql+203 SQL+70 00001E770 kewrft_flush_table+ CALL??? kewrftbs_flush_tabl 000000000 00001E778 00001F758 260 e_by_sql+203 7FF00000001 kewrftec_flush_tabl CALL??? kewrft_flush_table+ 000000001 000000000 02114E2E0 e_ehdlcx+826 260 000000000 kewrfat_flush_all_t CALL??? kewrftec_flush_tabl 2BCC3004F 02114DEC0 000000000 ables+1395 e_ehdlcx+826 000000000 kewrfos_flush_onesn CALL??? kewrfat_flush_all_t 000000001 000000001 000000004 ap+191 ables+1395 2B709CC28 kewrfsc_flush_snaps CALL??? kewrfos_flush_onesn 7FF52E5B220 000000006 hot_c+652 ap+191 7FF00000000 224D00000003 kewrafs_auto_flush_ CALL??? kewrfsc_flush_snaps 000000001 000000001 00000002E slave+838 hot_c+652 0004A89F3 kebm_slave_main+242 CALL??? kewrafs_auto_flush_ 7FF75831318 0004A8075 slave+838 02114E5C0 2B7080C88 ksvrdp+1404 CALL??? kebm_slave_main+242 000000000 005273191 000000000 000000000 opirip+834 CALL??? ksvrdp+1404 656E5C310000001E 003C8B000 02114FA30 000000000 opidrv+860 CALL??? opirip+834 000000032 000000004 02114FD50 000000000 sou2o+52 CALL??? opidrv+860 000000032 000000004 02114FD50 000000003 opimai_real+272 CALL??? sou2o+52 000000000 000000000 000000000 000000000 opimai+96 CALL??? opimai_real+272 000000000 000000000 000000000 000000000 BackgroundThreadSta CALL??? opimai+96 02114FEA8 000000001 000000000 rt+633 000000000 00000000770C495D CALL??? BackgroundThreadSta 006CA7B50 000000000 000000000 rt+633 000000000 00000000772C8791 CALL??? 00000000770C495D 000000000 000000000 000000000 000000000 --------------------- Binary Stack Dump --------------------- |
从详细日志中可以确定这个ORA-7445错误是发生在ksfqpcb函数上，而且错误发生的SQL在插入WRH$_COMP_IOSTAT表。
根据MOS的记录，这个错误与Bug 8710008 : ORA-07445 [KSFQPCB+0054] ON INSERT TO WRH$_COMP_IOSTAT IN MMON描述的非常相似，除了报错函数和报错语句相同外，数据库的版本也都是10.2.0.4。Oracle在该问题描述时，将BUG指向一个未公开的BUG：8710249。虽然这个bug没有公开，但是Oracle在文档RMAN produces CORE dump during backup Ora-07445: [__gi_strncpy()+17] [ID 1094624.1]中对这个问题进行了描述。这个错误影响版本为10.2.0.4及以后的10.2版本，而这个bug的修复要到11.2中，目前没有在10.2中解决这个问题的方法。
不过客户的数据库的告警日志中只出现了一次这个错误，说明这个错误并非每次重现，而且这个错误出现之前，出现了大量的归档错误的信息，不能排除是由于归档无法完成，从而引发了这个WRH$_COMP_IOSTAT表的插入错误。对应当前的环境而言，如果可以避免归档的问题，很可能就不会引起这个ORA-7445错误。