首页 » ORACLE 9i-23c » Troubleshooting ORA-07445 [intel_fast_memcpy.A()+18]

Troubleshooting ORA-07445 [intel_fast_memcpy.A()+18]

  • 2016/07/21
  • ORACLE 9i-23c
  • 600 views
  • Troubleshooting ORA-07445 [intel_fast_memcpy.A()+18]已关闭评论

前不久有个朋友从遇到了个问题，在数据库启动过程种出现ora-7445, 然后数据库CRASH, 环境11.1.0.7 windows 版本， 临时禁用了smon tx recovery打开数据库, 没有再继续跟踪，这里记录一下.

# DB ALERT

alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 15 processes
Started redo scan
Completed redo scan
 503 redo blocks read, 54 data blocks need recovery
Started redo application at
 Thread 1: logseq 833357, block 3
Recovery of Online Redo Log: Thread 1 Group 7 Seq 833357 Reading mem 0
  Mem# 0: E:\ORACLE\APP\ORADATA\anbob\REDO07.LOG
Completed redo application of 0.19MB
Completed crash recovery at
 Thread 1: logseq 833357, block 506, scn 14928904673880
 54 data blocks read, 54 data blocks written, 503 redo blocks read
Thu Jun 23 15:24:31 2016
Thread 1 advanced to log sequence 833358 (thread open)
Thread 1 opened at log sequence 833358
  Current log# 8 seq# 833358 mem# 0: E:\ORACLE\APP\ORADATA\anbob\REDO08.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Jun 23 15:24:32 2016
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Exception [type: ACCESS_VIOLATION, UNABLE_TO_WRITE] [ADDR:0x19DC0000] [PC:0x52B428E, _intel_fast_memcpy.A()+18]
Database Characterset is ZHS16GBK
Errors in file e:\oracle\app\diag\rdbms\anbob\anbob\trace\anbob_smon_484.trc  (incident=389522):
ORA-07445: exception encountered: core dump [intel_fast_memcpy.A()+18] [ACCESS_VIOLATION] [ADDR:0x19DC0000] [PC:0x52B428E] [UNABLE_TO_WRITE] []
Incident details in: e:\oracle\app\diag\rdbms\anbob\anbob\incident\incdir_389522\anbob_smon_484_i389522.trc
Opening with internal Resource Manager plan
Starting background process FBDA
Thu Jun 23 15:24:33 2016
FBDA started with pid=52, OS id=4484
replication_dependency_tracking turned off (no async multimaster replication found)
Thu Jun 23 15:24:34 2016
Trace dumping is performing id=[cdmp_20160623152434]
Starting background process QMNC
Thu Jun 23 15:24:34 2016
QMNC started with pid=53, OS id=4824
Thu Jun 23 15:24:35 2016
Sweep Incident[389522]: completed
Thu Jun 23 15:24:37 2016
Errors in file e:\oracle\app\diag\rdbms\anbob\anbob\trace\anbob_pmon_820.trc:
ORA-00474: SMON process terminated with error
PMON (ospid: 820): terminating the instance due to error 474
Thu Jun 23 15:24:39 2016
opidrv aborting process S000 ospid (5468_5488) due to error ORA-474
Instance terminated by PMON, pid = 820

zz


Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.0 Service Pack 1
CPU                 : 16 - type 8664, 16 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:11838M/16377M, Ph+PgF:23713M/32548M
Instance name: anbob
Redo thread mounted by this instance: 1
Oracle process number: 13
Windows thread id: 484, image: ORACLE.EXE (SMON)


*** 2016-06-23 15:24:33.319
*** SESSION ID:(873.1) 2016-06-23 15:24:33.319
*** CLIENT ID:() 2016-06-23 15:24:33.319
*** SERVICE NAME:() 2016-06-23 15:24:33.319
*** MODULE NAME:() 2016-06-23 15:24:33.319
*** ACTION NAME:() 2016-06-23 15:24:33.319

Dump continued from file: e:\oracle\app\diag\rdbms\anbob\anbob\trace\anbob_smon_484.trc
ORA-07445: exception encountered: core dump [intel_fast_memcpy.A()+18] [ACCESS_VIOLATION] [ADDR:0x19DC0000] [PC:0x52B428E] [UNABLE_TO_WRITE] []

========= Dump for incident 389522 (ORA 7445 [intel_fast_memcpy.A()+18]) ========
----- Beginning of Customized Incident Dump(s) -----
Exception [type: ACCESS_VIOLATION, UNABLE_TO_WRITE] [ADDR:0x19DC0000] [PC:0x52B428E, _intel_fast_memcpy.A()+18]

Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
Process Id: 0x0000155c  Thread Id : 0x000001e4    Time : Thu Jun 23 15:24:33
Excp. Code: 0xc0000005  Excp. Type: ACCESS_VIO    Flags: 0x00000000

------------------- Registers ----------------------------
ip=00000000052B428E sp=00000000197FAEE8 rp=0000000000000002
r1=0000000019DBE104 r2=0000000000000010 r3=0000000019A2A9CC
r4=0000000000000054 r5=00000000197FAEE8 r6=0000000000000002 r7=0000000019A2C8C4
r8=0000000019DBFFFC r9=0000000000001F7C r10=0000000000002104 r11=0000000000002104
r12=0000000000001F7C r13=00000000197FB4D0 r14=0000000019A28808 r15=0000000019A2A97E
------------------- End of Registers ---------------------


*** 2016-06-23 15:24:33.320
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.

----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
_intel_fast_memcpy.           0000000000000000     000000000 000000000 000000000
A()+18                                             000000000
0000000019A2A978     CALL???  _intel_fast_memcpy.  0198101CC 0012F2DB7 000030000
A()+18               0FFFFFFFF
00000000198101CC     CALL???  0000000019A2A978     0012F2DB7 000030000 0FFFFFFFF
00000009C
kturunlc()+813       CALL???  00000000198101CC     000030000 0FFFFFFFF 00000009C
000000000
kturmmbu()+65        CALL???  kturunlc()+0         0197FB140 015725720 000000000
015725720
kturrur()+621        CALL???  kturmmbu()+18        0000006FA 30E075F27 000000003
007D5F54F
ktundo()+515         CALL???  kturrur()+0          000000004 005D1DEB8 002050030
0000000FF
ktubko()+1435        CALL???  ktundo()+0           000000002 B553B00C0131A
0198101C0 000000204
kturrt()+27766       CALL???  ktubko()+0           0197FCEA8 0197FCE50 000000004
0197FD1A0
kturec()+1002        CALL???  kturrt()+26107       0197FD1A0 30E070013
CD3500000001 000000000
kturax()+915         CALL???  kturec()+0           000000046 000000000 000000001
CD3500000000
ktprbeg()+2391       CALL???  kturax()+0           200000004 000000000 000021300
1FCC34F38
ktmmon()+11837       CALL???  ktprbeg()+782        000000000 007B301A8 019D900A0
000000428
ktmSmonMain()+232    CALL???  ktmmon()+485         006F376B0 000002000 019D9CF90
015725CE0
ksbrdp()+1165        CALL???  ktmSmonMain()+0      006F376B0 00000A07C
3EDD00000424 14720012E91D
opirip()+727         CALL???  ksbrdp()+0           00000001E 005CDB518 0197FF9E0
000000000
opidrv()+855         CALL???  opirip()+0           000000032 000000004 0197FFD30
000000000
sou2o()+52           CALL???  opidrv()+213         000000032 000000004 0197FFD30
0197FFDB0
opimai_real()+295    CALL???  sou2o()+0            000000000 0771BA967 000000000
000000000
opimai()+96          CALL???  opimai_real()+0      000000000 000000000 000000000
000000000
BackgroundThreadSta  CALL???  opimai()+0           0197FFE98 000000001 000000000
rt()+695                                           000000000
00000000771B495D     CALL???  BackgroundThreadSta  01B917FA0 000000000 000000000
rt()+0               000000000
00000000773B8791     CALL???  00000000771B4950     000000000 000000000 000000000
000000000

日志中发现是在启动时smon 进程在tx recover时遇到的致命错误， 先禁用smon 事务回滚，成功open了数据库。

alter system set event= '10513 trace name context forever, level 2' scope=spfile;
shutdown immediate;
startup ;

后期处理
1, 可以尝试查询数据库存在的死事务，确认涉及的对象，或修改内容
2，可以尝试跟踪undo 应用配置10218 event, 根据uba 找最后应用到的undo block,再找到data block 当时的记录
This event simply shows the undo block addresses for the undo applied during recovery

 alter system set events '10218 trace name context forever,level 1';


uba: 0x00c0aa56.00e2.12
uba: 0x00c0aa56.00e2.11
uba: 0x00c0aa56.00e2.10
uba: 0x00c0aa56.00e2.0f
uba: 0x00c0aa56.00e2.0e
uba: 0x00c0aa56.00e2.0d

trace monitor transaction recovery during startup

alter system set events '10013 trace name context forever, level 10';

3，可以尝试，删掉当时的表再重构
4，确认了问题点可以尝试BBED 提交事务和清理回滚段

打赏

,

对不起，这篇文章暂时关闭评论。

上一篇：

下一篇：