暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

ORA-7445: [ksfqpcb]

老杨 2019-03-26
537

问题描述

在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错误。

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论