Oracle Bug – 第5页

Oracle内部错误ORA-07445[kpopfr()+339] [SIGFPE]一例

2009/09/23 by admin 2 Comments

当所有列长度综合超过1048576时可能引发的一个dump错误，session会自动关闭。一般只有列很多且单列较“宽”时可能出现该错误。

已经测试的在10.2.0.1,以及10.2.0.3上均可以再现该问题，测试方法：

create table test

( c000 char(2000),

c001 char(2000),

…

c523 char(2000),

c524 char(576));

— sum of all column size is 1048576(0x100000).

Run next shell script.

while [ 1 ]

echo “set feedback off”

echo “select * from test where c001 = ‘A’;”

done | sqlplus -s scott/tiger

Note 245840.1 Information on the sections in this article

以上循环执行一段时间后session会被关闭，告警日志中出现

ORA-07445: exception encountered: core dump [kpopfr()+339] [SIGFPE] [Integer divide by zero][0x002327FF5] [] []的记录。没有在9i版本上测试，不能确定其影响。

该bug在10.2.0.4 patch set中已被修复，也可以通过小补丁形式修复，Oracle发布的小布丁只针对10.2.0.3版本，即10.2.0.1上是不能打的。

附bug描述原文：
Subject: Bug 5753629 – Query may dump [in kpopfr / kposdi]

Doc ID: 5753629.8 Type: PATCH

Modified Date : 03-APR-2009 Status: PUBLISHED

@ Note to support: do not edit this note – it is auto generated
Bug 5753629 Query may dump [in kpopfr / kposdi]

This note gives a brief overview of bug 5753629.
The content was last updated on: 03-APR-2009
Click here for details of each of the sections below.
Affects:

Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions < 11
Versions confirmed as being affected

* 10.2.0.3

Platforms affected Generic (all / most platforms affected)

Fixed:

This issue is fixed in

* 10.2.0.3 Patch 9 on Windows Platforms
* 10.2.0.4 (Server Patch Set)
* 11.1.0.6 (Base Release)
* Process May Dump (ORA-7445) / Abend / Abort
* Dump in or under kpopfr / kposdi
* (None Specified)

Symptoms:

Related To:

Description

Repeatedly executing a query can lead to a dump in kpopfr.

eg:

create table test

( c000 char(2000),

c001 char(2000),

…

c523 char(2000),

c524 char(576));

— sum of all column size is 1048576(0x100000).

Run next shell script.

while [ 1 ]

echo “set feedback off”

echo “select * from test where c001 = ‘A’;”

done | sqlplus -s scott/tiger

Dump occurs

Please note: The above is a summary description only. Actual symptoms can vary. Matching to any

symptoms here does not confirm that you are encountering this problem. Always consult with Oracle

Support for advice.

References

Bug 5753629 (This link will only work for PUBLISHED bugs)

Filed Under: Oracle, Oracle Bug Tagged With: ORA-07445, Oracle Bug

Oracle内部错误ORA-600:[1112]

2009/07/06 by admin Leave a Comment

以下为ORA-600[1112]内部错误的相关诊断信息:

ERROR:
ORA-600 [1112] [a] [b] [c] [d] [e]

VERSIONS:
versions 7.3 to 9.2

DESCRIPTION:

ORA-600 [1112] is getting raised while trying to add a
row cache enqueue to a transaction state object during
lookup of the default tablespace number during table
creation.

FUNCTIONALITY:
STATE OBJECT MANAGEMENT

IMPACT:
PROCESS FAILURE
NON CORRUPTIVE - No underlying data corruption.


Bug 2489130 - OERI:1112 can occur while dumping PROCESSSTATE informatio (Doc ID 2489130.8)
Bug 4126973: ORA-600[504] AND ORA-600[1112] OCCURED WHEN GETTING "ERRORSTACK"
Base Bug 2489130
Bug 3954753: ORA-600 [1112] AND SESSION CRASH

The cause for the ORA-00600 [1112] appears due to Bug 2489130
This error can occur on dumping of process state which is what occurred here.
The primary issue is the WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!
This then triggers a system state and process state to be dumped due to nature of the problem.
The ORA-00600 [1112] gets dumped out when process state is done.

Stack for trace very similar to Bug 2489130 and this is only known bug on 9.2 like this with a fix.

A fix for bug 2489130 is included in the 9.2.0.7 patchset.
Recommend applying 9.2.0.8 patchset to have this and other bug fixes.
This would only prevent the ORA-00600 [1112] from occurring on state dumps.
The primary row cache issue still to be investigated by performance team.

Filed Under: Oracle, Oracle Bug Tagged With: ora-00600, row cache

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

SQL> select count(*) from WWork;

COUNT(*)
----------
116114

select count(*) from WWork where Work_WorkID = 100;
select count(*) from WWork where Work_WorkID = 100
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [],
[]

Tablespace id 15 is the same where the index is created.

analyze table livelink.WWORK validate structure cascade;

analyze table livelink.WWORK validate structure cascade
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [],
[]

analyze index livelink.WWORK_PRIMARY validate structure;
analyze index livelink.WWORK_PRIMARY validate structure
*
ERROR at line 1:
ORA-08100: index is not valid - see trace file for diagnostics

I'm wondering if the issue could be resolved recreating the index.

alter index WWORK_PRIMARY rebuild online noparallel;

On the alert log file, ORA-00600 began at:
Sun Jun 5 23:29:10 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_26554.trc:
ORA-00600: internal error code, arguments: [ktbair1], [1], [6], [], [], [], [], []
Mon Jun 6 00:35:51 2011
Thread 1 advanced to log sequence 303722
Current log# 19 seq# 303722 mem# 0: /u002/oradata/motpcom/redo19.log
Mon Jun 6 00:35:51 2011
And then below error often raised in alert log:
Mon Jun 6 02:45:00 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_28348.trc:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [], []
Mon Jun 6 02:50:01 2011
I also found other errors:
Mon Jun 6 05:00:01 2011
ORA-01555 caused by SQL statement below (Query Duration=18448 sec, SCN: 0x09f0.52bb91c8):
Mon Jun 6 05:00:01 2011
SELECT COUNT(d.dataid)
FROM allemployees a, networks_dataids d, kuaf k, dversdata v
WHERE k.name=a.user_id(+) AND d.userid=k.id AND a.user_id is null
Mon Jun 6 05:00:13 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_28348.trc:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [], []
Mon Jun 6 05:05:13 2011
And
Tue Jun 7 02:02:14 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_25842.trc:
ORA-07445: exception encountered: core dump [00000001011B8AD8] [SIGSEGV] [Address not mapped to object] [0x000000A88] [] []
Tue Jun 7 02:03:11 2011
And
Tue Jun 7 02:41:35 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_27325.trc:
ORA-00600: internal error code, arguments: [2662], [2544], [1396224900], [28954], [3445424704], [786437], [], []
Tue Jun 7 02:41:35 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_27325.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [2544], [1396224900], [28954], [3445424704], [786437], [], []
Tue Jun 7 02:41:59 2011 

SQL> select count(*) FROM WWork where Work_WorkID=100;
select count(*) FROM WWork where Work_WorkID=100
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [],
[]


SQL> alter index WWORK_PRIMARY rebuild online noparallel;

Index altered.

SQL> select count(*) FROM WWork where Work_WorkID=100;

COUNT(*)
----------
0

Index corruptions do not always mean that there is a Bug.
Indexes corrupt when the transaction ID that associates it with its data does not match.
In majority of the cases, this happens when a table has a large amount of DDL or DML processing as in a OLAP
processing. The index buffer cache is over written with an incorrect transaction id and an error results.
The error could be a ORA-00600 [25027] error, an ORA-8102/8103, or another ORA-00600 error.
Possibly, adding another index may resolve the issue of relying on just one index.

In addition, the index space must be reviewed to determine whether there is enough space.
As in the first example above, if there isn't space, then the index can be overwritten and an error can appear.
I suggest reading My Oracle Knowledge Note 33343.1 "How to Find Out How Much Space an Index is Using" which provides select
statements to show the actual usage of blocks within an index. This gives an idea of how 'full' an index is and
allows the DBA to adjust next extent sizes etc.

In addition, you can start the Index Tuning Wizard from Enterprise Manager in order to get advice on the indexes within the database.

We would like to emphasize that the best method to resolve a corrupt index is to drop and recreate it and not use a rebuild.
If this index corrupts again, then we suggest that it be dropped and recreated.


ORA-600 [25012] "Relative to Absolute File Number Conversion Error"


Note: For additional ORA-600 related information please read Note:146580.1

PURPOSE:            
  This article discusses the internal error "ORA-600 [25012]", what 
  it means and possible actions. The information here is only applicable 
  to the versions listed and is provided only for guidance.
 
ERROR:              
  ORA-600 [25012] [a] [b] [c]
 
VERSIONS:
  versions 8.0 and above
 
DESCRIPTION:

  We are trying to generate the absolute file number given a tablespace 
  number and relative file number and cannot find a matching file number
  or the file number is zero.
 
ARGUMENTS:          
  Arg [a] Tablespace Number 
  Arg [b] Relative file number
  Arg [c] Absolute file number (This arg is present is more recent releases)
 
FUNCTIONALITY:      
  KERNEL FILE MANAGEMENT TABLESPACE COMPONENT
 
IMPACT:             
  POSSIBLE PHYSICAL CORRUPTION
 
SUGGESTIONS:        

  The possibility of physical corruption exists.

  Obtain the trace files and alert.log for this error and log a Service Request
  with Oracle Support Services for diagnosis.

  If the Arg [b] Relative file number returns 0 (zero), look for fake indexes
  that can cause this error.

  The following query list fake indexes :

  select a.*,b.flags from dba_objects a, sys.ind$ b
  where a.object_id = b.obj#
  and bitand(b.flags,4096)=4096;

  Known Issues:




Known Bugs
You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button:


    NB	Bug	Fixed	Description
    	5653641 	11.2.0.1 	Corrupt dictionary from DROP TABLESPACE containing _offline_rollback_segments
    * 	8198906 	10.2.0.5, 11.2.0.1 	OERI [kddummy_blkchk] / OERI [5467] for an aborted transaction of allocating extents
    	4925342 	9.2.0.8, 10.2.0.3, 11.1.0.6 	OERI [25027] / OERI [25012] on IOT analyze estimate statistics
    	3258674 	9.2.0.7, 10.1.0.4, 10.2.0.1 	QMN process may dump or raise an internal error during DML
    	4186885 	10.2.0.1 	Partition numbers for IOT index/overflow segments are not synchronized
    	3751874 	9.2.0.6, 10.1.0.4, 10.2.0.1 	OERI[25012] can occur when _old_connect_by_enabled set to true
    	3430832 	9.2.0.6, 10.1.0.3, 10.2.0.1 	OERI[25012] in DML after ONLINE create index against PARTITIONED table
    	3915343 	9.2.0.7, 10.1.0.5, 10.2.0.1 	OERI [25012] on COMMIT with refresh ON-COMMIT Materialized view over cluster
    	4305391 	9.2.0.7, 10.1.0.5, 10.2.0.1 	OERI[25012] with kditalp can occur during a temporary LOB operation
    P* 	6047085 		Linux x64-64: SGA corruption / crash following any ORA-7445
    	2526334 	9.2.0.3, 10.1.0.2 	OERI:25012 from AND EQUAL with B-Tree and DOMAIN index
    	2531519 	9.2.0.3, 10.1.0.2 	OERI:[25012] from parallel direct load of bitmap managed segments
    	3150268 	9.2.0.5, 10.1.0.2 	OERI[kcbgcur_1] / OERI:25012 deleting rows from PARENT table with LIST subpartitions
    	3070856 	9.2.0.5, 10.1.0.2 	OERI:12700 / 25012 / ktrexc_1 on transported tablespace with SMU
    	3771508 	9.2.0.7 	OERI[kcbgtcr_1] / OERI[25012] selecting from V$AQ in a shared server
    	3900237 	9.2.0.7 	OERI[25012] changing length of indexed column for a global temporary table
    	1834530 	8.1.7.4, 9.0.1.4, 9.2.0.1 	OERI:25012 / wrong results after EXCHANGE 
        PARTITION with indexes with different FREELIST /FREELIST GROUPS
    	1698789 	9.2.0.1 	Wrong results, ORA-1410, ORA-8103, OERI:25012 on SELECT of UNSCOPED REF with ROWID
    	2189615 	8.1.7.4, 9.0.1.4, 9.2.0.1 	OERI:25012 / OERI:504 [cache buffers chains] selecting from certain V$ tables
    	1784708 	8.1.7.3, 9.0.1.1, 9.2.0.1 	OERI:KCBGTCR_1/OERI:25012 accessing LONG / LONG RAW in a HASH CLUSTER
    	1872985 	9.0.1.2, 9.2.0.1 	Dump / OERI:25012 from BITMAP CONVERSION of INDEX on GLOBAL TEMPORARY TABLE
    	1968815 	9.0.1.2, 9.2.0.1 	OERI:25012 possible from SMON following DROP TABLESPACE command
    	2287815 	9.0.1.4, 9.2.0.1 	OERI:KTSPISCHNT / OERI:25012 after exchange PARTITION with bitmap managed segments
    	2184731 	8.1.7.4, 9.2.0.1 	OERI:25012 possible from index prefetch
    	1837529 	8.1.7.3, 9.0.1.1, 9.2.0.1 	OERI:KFTR2BZ_1/OERI:25012 from CREATE sub-partitioned local INDEX ONLINE
    	2214167 	9.0.1.4, 9.2.0.1 	OERI:25012 / wrong results possible after TRUNCATE of bitmap managed index
    	2212389 	9.0.1.4, 9.2.0.1 	OERI:25012 / Cursor frame memory corruption when cursor with BINDS aged out / reloaded
    	1788648 	8.1.7.3, 9.0.1.1, 9.2.0.1 	OERI:25012 [2147483647] possible selecting from certain V$ views
    	1527982 	8.1.7.2, 9.0.1.0 	OERI:25012 / Bitmap indextable mismatch after UPDATE of PARTITION KEY moves rows
    	1949273 	8.1.7.3, 9.0.1.0 	OERI:25012 / ORA-1555 / ORA-22922 accessing LOB data after ALTER TABLE MOVE lob
    	1264970 	8.1.7.1, 9.0.1.0 	OERI:25012 / OERI:6050 possible coalescing index with freelists
    	1396571 	8.0.6.3, 8.1.6.3, 8.1.7.1, 9.0.1.0 	OERI:25012 possible importing with TRANSPORT_TABLESPACE=Y
    	1678963 	8.1.7.2, 9.0.1.0 	OERI:25012 / OERI:4142 possible on TRUNCATE of a table with a CLOB column
    	1297674 	8.0.6.2, 8.1.6.3, 8.1.7.0 	OERI:25012 Analyzing partitioned table with ESTIMATE
    	1138239 	8.1.6.2, 8.1.7.0 	OERI-25012 possible on direct read from plugged in (transportable) tablespace
    	1228658 	8.1.6.2, 8.1.7.0 	Create INDEX on SNAPSHOT/MV can produce corrupt index (OERI:13004 / OERI:25012 / ORA-1499)
    	1108002 	8.1.7.0 	OERI:25012 when DBMS_STATS tries to gather stats for a GLOBAL TEMPORARY table
    	986928 	8.1.7.0 	DBMS_SPACE.UNUSED_SPACE reports OERI:25012 for TEMPORARY tables
    	1312233 	8.1.6.3, 8.1.7.0 	OERI:25012 / OERI:KCBGCUR_1 possible on PQ STAR query with PARTITIONED fact table
    	718499 	8.0.6.1, 8.1.5.0 	OERI:25012 possible on OPS parallel create index
    	677243 	8.0.6.0 	OERI:kdddgbX on DELETE / UPDATE / SELECT for UPDATE with an invalid ROWID
    	679817 	8.0.5.1 	OERI:25012 from view containing 2+ LOB columns
    	595698 	8.0.4.3, 8.0.5.0 	DELETE on table with many child constraints may dump.

        '*' against a bug indicates that an alert exists for that issue.
        '+' indicates a particularly notable bug.
        'P' indicates a port specific bug.
        "OERI:nnnnn" is used as shorthand for ORA-600 [nnnnn]. 

Symptom(s)
~~~~~~~~~~

ORA-600 [25012] errors with same first argument and different
second arguments (second arguments changes during every SELECT Run)

Eg.:

ORA-600 [25012], [5], [1023], [], [], [], []


The first argument corresponds to a tablespace and second argument
corresponds to a file number.

The tablespace points to an index tablespace


Cause
~~~~~

Bug:2184731


Fix
~~~~

Bug:2184731 is fixed in 8.1.7.4 and 9.2

The workaround is to set _db_file_noncontig_mblock_read_count=1.


References
~~~~~~~~~~

Note:100073.1  ORA-600 [25012] "Relative to Absolute File Number 
                 Conversion Error"

Bug:2184731    ORA-600 [25012] WHEN SELECT FROM A TABLE USING AN INDEX

Filed Under: Oracle, Oracle Bug Tagged With: ora-00600, Oracle索引index

Oracle内部错误ORA-07445: [ACCESS_VIOLATION] [unable_to_trans_pc][UNABLE_TO_READ]

2008/11/10 by admin Leave a Comment

ORA-07445: [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x5A1113A] [ADDR:0xFFFFFFFFFFFFFFFF] [UNABLE_TO_READ]一般是Windows平台上常见的内存不足问题引起，在64 bit 或 32bit 平台均可能发生，一般建议通过增加SGA_MAX_SIZE和SGA_TARGET(ASMM)来解决该问题，同时增加SHARED_POOL_SIZE、 JAVA_POOL_SIZE、 STREAMS_POOL_SIZE到200M以上。

也可能是由于Windows平台感染了计算机病毒引起的，建议同时也要查杀病毒。

ORA-07445 [ACCESS_VIOLATION] [unable_to_trans_pc] on Windows Platforms
Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.3 and later   [Release: 10.2 and later ]
Information in this document applies to any platform.
***Checked for relevance on 06-Oct-2011***
RDBMS 9.2 or greater on Windows platforms
Symptoms

ORA-07445: exception trouvee : image memoire [ACCESS_VIOLATION] [kpudcr2c+89] [PC:0x100CD3D1] 
[ADDR:0x19EC0000] [UNABLE_TO_WRITE] [] 

ORA-07445: Message 7445 not found; product=RDBMS; facility=ORA
; arguments: [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x5A1113A] [ADDR:0xFFFFFFFFFFFFFFFF] [UNABLE_TO_READ]

ORA-27300: OS system dependent operation:WaitForSingleObject failed with status: 0
ORA-27301: OS failure message: The operation completed successfully.
ORA-27302: failure occurred at: sssxcpttcs5

Changes

none known
Cause

This error

ORA-07445: Message 7445 not found; product=RDBMS; facility=ORA
; arguments: [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x5A1113A] [ADDR:0xFFFFFFFFFFFFFFFF]
[UNABLE_TO_READ]

is typical for WIN out of memory and is commonly seen when INIT.ORA parameters are set to 
that of the DBCA starter DB.

This problem appears as likely on 64 bit platforms as on 32 bit

Solution

Please refer to Note 342443.1 and apply latest minipack.

Have sufficient physical memory on Server so that you can allocate more SGA/PGA to the database.

 1) Increase SGA_MAX_SIZE  and SGA_TARGET so that you can accommodate following pools.

2) Restart the instance.

3) Increase INIT.ORA memory parameters and make sure following pools are set to recommended value i.e. 200M.

a) SHARED_POOL_SIZE

b) JAVA_POOL_SIZE

c) STREAMS_POOL_SIZE

ORA-07445: [ACCESS_VIOLATION] [unable_to_trans_pc]...[UNABLE_TO_READ] on Windows

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 and later   [Release: 10.2 and later ]
Microsoft Windows (32-bit)
***Checked for relevance on 06-Oct-2011***
Symptoms

Session aborted on a select statement and a trace file is created with :

ORA-07445: exception encountered: core dump [ACCESS_VIOLATION]
[unable_to_trans_pc] [PC:0x7C34538C] [ADDR:0xFFFFFFFF] [UNABLE_TO_READ] []
Cause

Such arguments often highlight a resource failure where memory is the most common cause of this problem.

Two hidden processes on the server were generating error messages and consuming all of the CPU : LSASS and SCCHOST

These are often due to virus.

(A later case was discovered due to a  third party software named Quest Intrust Agent. )

Solution

Problem was fixed after these two actions were performed:

1. Both processes were killed.

2. Antivirus software found some viruses and eliminated them. 

ORA-7445 [ACCESS_VIOLATION] [unable_to_trans_pc] [UNABLE_TO_WRITE] ORA-27301: 
OS failure message: Not enough storage ORA-27300 ORA-27302 

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.3 and later   [Release: 10.2 and later ]
Information in this document applies to any platform.
***Checked for relevance on 22-Oct-2010***
Symptoms

These errors were encountered and the DB crashed.:

ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [unable_to_trans_pc]
[PC:0x7C34126B] [ADDR:0x0] [UNABLE_TO_WRITE] []
ORA-27300: OS system dependent operation:CreateThread failed with status: 8
ORA-27301: OS failure message: Not enough storage is available to process this command.
ORA-27302: failure occurred at: ssthrddcr.

You may observe this in the trace file.:

"Current SQL information unavailable - no SGA."

Changes

This could be triggered by hardware issues or an increase in volume or by day to day operations.
Cause

Insufficient memory.

Solution

Ensure that the existing memory is functioning properly.

Verify you have enough memory available to support the configuration implemented. 

Another option is to decrease the size of the SGA.

Check your OS log for hardware errors. 

ORA-07445: [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x609C6FA2] [ADDR:0x79A0040] [UNABLE_TO_READ] 

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.2 and later   [Release: 10.2 and later ]
Information in this document applies to any platform.
Symptoms

ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [unable_to_trans_pc] [PC:0x609C6FA2]
[ADDR:0x79A0040] [UNABLE_TO_READ] []
occuring on a select with bind variables.

The call stack will be exact or similar to:
_clscugblmterm -> _clsc_term -> _clscterm -> _prom_terminate
AND/OR
malloc -> _malloc_unlocked -> cleanfree -> realfree 

--clscugblmterm is a RAC function, however in the case of this bug, the instances ARE NOT RAC. 

Cause

The cause of this problem has been identified and verified in an unpublished Bug 4723824.

This bug was introduced in 10.2.0.2.

Solution

Your options are:
1) Verify the patch you are on for 10.2.0.2 on windows is at least at patch least 8 as this bug is
fixed in windows 10.2.0.2 patch 8.  Please see Note:161549.1 for further information about windows patching
OR
2)  If on UNIX, determine from MOS if there is a one-off patch available on your database/OS version combination
OR
3) RECOMMENDED:  Upgrade to 11g as this bug is fixed in the 11g database version.

Ora-7445 [ACCESS_VIOLATION] [unable_to_trans_pc] After Applying Windows 10.2.0.4 Patch Bundle 10 

Applies to:

Oracle Server - Standard Edition - Version: 10.2.0.4 to 10.2.0.4 - Release: 10.2 to 10.2
z*OBSOLETE: Microsoft Windows XP
Microsoft Windows XP
Symptoms

On Windows, using Oracle 10.2.0.4, getting the following error in the alert.log:

ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [unable_to_trans_pc]
[PC:0x7C911669] [ADDR:0x0] [UNABLE_TO_READ] []

  --- Call Stack ----
  _sldmGetHostName _sldmInit _ldmInit _keltnfy _kscnfy _ksucrp _opiino _opiodr _opidrv _sou2o
  _opimai_real _opimai
Cause

High CPU usage
Solution

Install KB 951312 from Microsoft to overcome this problem of high CPU usage. http://support.microsoft.com

Drop User Cascade Results In ORA-03113 and ORA-7445 [ACCESS_VIOLATION] [unable_to_trans_pc]
Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.5 - Release: 10.2 to 10.2
Information in this document applies to any platform.
Checked for relevance on 4-Nov-2011
Symptoms

Drop user cascade fails with ORA-3113 error:

SQL> drop user vipr cascade;
drop user vipr cascade
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel

The alert.log shows:

ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [unable_to_trans_pc]
[PC:0x61FF2728] [ADDR:0x4] [UNABLE_TO_READ] []

In the trace we see:

Current SQL statement for this session:
drop java source "VIPR"."HOST"
----- Call Stack Trace -----
joxdrp opiexe opiosq0 opiosq opiodr rpidrus rpidru rpiswu2 rpidrv rpisplu rpispl kzdukl kzudrp
opiexe opiosq0 kpooprx kpoal8 opiodr ttcpip opitsk opiino opiodr opidrv sou2o
It is failing when trying to drop java source.

Cause

JVM is in REMOVING status.

COMP_NAME VERSION STATUS
Oracle Enterprise Manager 10.2.0.3.0 VALID
Oracle Workspace Manager 10.2.0.1.0 VALID
Oracle Database Catalog Views 10.2.0.3.0 VALID
Oracle Database Packages and Types 10.2.0.3.0 VALID
JServer JAVA Virtual Machine 10.2.0.3.0 REMOVING

Solution

Follow Note 276554.1 How to Reload the JVM in 10.1.0.X and 10.2.0.X to remove or reload JVM.

Filed Under: Oracle, Oracle Bug Tagged With: windows 2003