ORA-07445: 出现异常错误: 核心转储 [kupfuDecompress()+2279]

问题背景:

客户expdp导出数据的时候程序以外中止,协助排查问题原因


问题处理:
报错如下

 

 

 

查看alert日志

Dump file c:\app\administrator\diag\rdbms\crm\crm\incident\incdir_131384\crm_dw00_5696_i131384.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.1 Service Pack 1
CPU : 16 - type 8664, 16 Physical Cores
Process Affinity : 0x0x0000000000000000
Memory (Avail/Total): Ph:10000M/16383M, Ph+PgF:26083M/32765M
VM name : VMWare Version (6)
Instance name: crm
Redo thread mounted by this instance: 1
Oracle process number: 30
Windows thread id: 5696, image: ORACLE.EXE (DW00)


*** 2020-03-22 17:55:42.649
*** SESSION ID:(690.599) 2020-03-22 17:55:42.649
*** CLIENT ID:() 2020-03-22 17:55:42.649
*** SERVICE NAME:(SYS$BACKGROUND) 2020-03-22 17:55:42.649
*** MODULE NAME:(Data Pump Worker) 2020-03-22 17:55:42.649
*** ACTION NAME:(SYS_IMPORT_FULL_01) 2020-03-22 17:55:42.649

Dump continued from file: c:\app\administrator\diag\rdbms\crm\crm\trace\crm_dw00_5696.trc
ORA-07445: 出现异常错误: 核心转储 [kupfuDecompress()+2279] [ACCESS_VIOLATION] [ADDR:0x10] [PC:0x521B77B] [UNABLE_TO_READ] []

========= Dump for incident 131384 (ORA 7445 [kupfuDecompress()+2279]) ========
----- Beginning of Customized Incident Dump(s) -----
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x10] [PC:0x521B77B, kupfuDecompress()+2279]

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
Process Id: 0x00000730 Thread Id : 0x00001640 Time : Sun Mar 22 17:55:42
Excp. Code: 0xc0000005 Excp. Type: ACCESS_VIO Flags: 0x00000000

------------------- Registers ----------------------------
ip=000000000521B77B sp=000000002552F0D0 rp=000000001A1074A0
r1=0000000000000001 r2=000000000521B774 r3=0000000000400000
r4=0000000000000000 r5=000000002552F0D0 r6=000000001A1074A0 r7=0000000000000000
r8=0000000000000000 r9=000000002AFD09D0 r10=000000002AF2FE00 r11=0000FFF1077DF569
r12=0000000000000000 r13=0000000000000000 r14=000000002552F680 r15=000000002AFD09D0
------------------- End of Registers ---------------------


*** 2020-03-22 17:55:42.665
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=ggatk0yxyd8r7) -----
BEGIN
SYS.KUPW$WORKER.MAIN('SYS_IMPORT_FULL_01', 'CRM', 0);
END;
----- PL/SQL Stack -----
----- PL/SQL Call Stack -----
object line object
handle number name
00000002FBA9BE10 58 package body SYS.KUPD$DATA_INT
00000002FC79FD70 3104 package body SYS.KUPD$DATA
00000002FC7BF030 14187 package body SYS.KUPW$WORKER
00000002FC7BF030 4412 package body SYS.KUPW$WORKER
00000002FC7BF030 8889 package body SYS.KUPW$WORKER
00000002FC7BF030 1649 package body SYS.KUPW$WORKER
00000002FC7C0C78 2 anonymous block

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
kupfuDecompress()+2 0000000000000000 2020202020202020
279 6E6F6E6120203220
6C622073756F6D79

BEGIN
SYS.KUPW$WORKER.MAIN('SYS_IMPORT_FULL_01', 'CRM', 0);
END;

这个sql是数据泵使用的sql,没办法避免了,采用exp的方式导出数据,建议客户及时迁移

posted on   数据与人文  阅读(834)  评论(0编辑  收藏  举报

编辑推荐:
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
阅读排行:
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

点击右上角即可分享
微信分享提示