Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2520495
  • 博文数量: 323
  • 博客积分: 10211
  • 博客等级: 上将
  • 技术积分: 4934
  • 用 户 组: 普通用户
  • 注册时间: 2006-08-27 14:56
文章分类

全部博文(323)

文章存档

2012年(5)

2011年(3)

2010年(6)

2009年(140)

2008年(169)

分类: Oracle

2009-12-08 14:06:51

今天在检查oracle alert log的时候发现这样一个报错:
ORA-00600: internal error code, arguments:[26599], [1], [146], [], [], [], [], []
到metalink上查了一下,发现oracle是这样描述的:
 
Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.1 to 10.2.0.1
Information in this document applies to any platform.
Abstract
ORA-600 [26599]  affects the Oracle JAVAVM and occurs during java class instantiation i.e when a class is being loaded into shared memory within the Oracle JAVAVM. When the error occurs, the 3rd parameter is significant in determining the likely cause.

The error usually occurs when we try and load a dependent class and it cannot be found. The 2 most common causes of this are when that dependent class has been incorrectly aged out of memory due to a pressure on resources, ORA-600 [26599][1][54] or when 2 processes are trying to load the same class at the same time, ORA-600[26599][1][224] / ORA-600[26599][1][229]. (It is a feature of the JAVAM that once a class is instantiated it is shared between processes).

The error is usually not fatal to the database in itself, since the classes eventually get instantiated by other processes. However, if the hierarchy remains in an inconsistent state, it is possible for the Process Monitor (pmon) to crash while attempting to clean up the process – typically with ORA-600 [17148]

This article lists the most common occurrences of these symptoms and their solutions.
Document History
Author :  Simon Slack
Create Date 09-Nov-2007
Update Date 09-Nov-2007
Expire Date
An Overview of ORA-600 [26599] 1. ORA-600 [26599] [1] [54]:

This issue is described in and occurs when a class has a super class that has a super class, and that super super class is aged out during a time of heavy load. When the base class comes to be used, it attempts to loads the super classes and fails with ORA-600 [26599] [1] [54]. This occurs in Version 9.2 and earlier, because the dependency mechanism was only tracking super classes. The main impact of this bug was reduced in 9i, when all classes referred to in classes.bin ( i.e. those from a standard JDK) were automatically pinned. However it may still be possible to have this occur.

is fixed in 10.1, but no patches exist for earlier versions.

Since this is a resource, issue, in that classes are aged out when memory is tight, increasing the size of the shared_pool may alleviate this. Oracle have also devised a workaround which should avoid this, whereby you identify all classes that could possibly be aged out, and then incorporate code to pin them into the shared pool in a database startup trigger.

drop table JAVA_SUPERS;

create table JAVA_SUPERS as (
select
JOXFTREFERENCEDNAME SUPER_NAME,
JOXFTREFERENCEDNAMESCHEMA SUPER_OWNER,
O.NAME,
U.NAME OWNER
from
X$JOXFC,OBJ$ O,USER$ U
where OBJ#=JOXFTOBN
and USER#=OWNER#
and JOXFTREFERENCEDNAMESUPER=JOXFTREFERENCEDNAMENUMBER
);

drop TABLE JAVA_SUPER_SUPERS;

create table JAVA_SUPER_SUPERS as (
select OWNER,X.NAME
from
(select S1.SUPER_OWNER OWNER,S1.SUPER_NAME NAME
from
JAVA_SUPERS S1,
JAVA_SUPERS S2
where S1.NAME=S2.SUPER_NAME
and S1.OWNER=S2.SUPER_OWNER
group by
cube (S1.SUPER_OWNER,S1.SUPER_NAME))X,
OBJ$ O,
USER$ U
where OWNER is not null
and X.NAME is not null
and X.NAME=O.NAME
and OWNER=U.NAME
and OWNER#=USER#
and O.TYPE#=29
and O.STATUS=1
and (floor(O.FLAGS/128)*2)=floor(O.FLAGS/64));


create or replace procedure PIN_JAVA_SUPER_SUPERS as
OWNER varchar2(30);
NAME varchar2(30);
ROWN number;
SOFAR number := 0;
DONE boolean := false;
SQLERR number;
cursor C is select OWNER,NAME,ROWNUM
from JAVA_SUPER_SUPERS;
begin
loop
open C;
loop
begin
fetch C into OWNER, NAME, ROWN;
if C%notfound then DONE := true; end if;
exit when C%notfound;
exception when others then
SQLERR := SQLCODE;
if SQLERR = -1555 then exit; -- snapshot too old, re-execute fetch query
else raise;
end if;
end;
IF ROWN > SOFAR then
SOFAR := ROWN;
begin
dbms_shared_pool.keep('"'||OWNER||'"."'||NAME||'"','JC');
exception when others then
SQLERR := SQLCODE;
if SQLERR = -701 then null; -- already perm kept: ignore and proceed.
else raise;
end if;
end;
end if;
end loop;
close C;
if DONE then exit; end if;
end loop;
end;
/

create or replace trigger DB_START_JAVAVM after startup on database

begin
PIN_JAVA_SUPER_SUPERS;
end;
/


2. ORA-600 [26599], [1], [139]

This is described in and occurs when loading large and complex java applications which cause an internal structure to overflow. This issue is only seen on 64 bit platforms.

only affects version prior to 10.1 and is fixed in the 9.2.0.7 patch set and later.

3. ORA-600 [26599], [1], [146]

This is described in unpublished Bug 4157520  and occurs because of an incorrect check that should not be in the code. There is no workaround if you encounter it.

unpublished Bug 4157520 is fixed in 10.2 and is back ported to 10.1.0.5 and later and one off patches can be made for 9.2.0.8.
--4157520这个patch只有for 9.2.0.7版本的。我们的数据库版本是0.6

4. ORA-600 [26599], [1], [157]

This is described in and occurs when using the javavm on a standby database after recovery has occurred. This is because the recovery process forces java classes to age out and this is missed by the Javavm’s internal state mechanism.

will be fixed in 10.2.0.4 and one off patches can be made for 9.2.0.8
5. Ora-600 [26599] [1] [224]/ Ora-600 [26599] [1] [229]

This issue is described in This typically occurs soon after a database is started particularly if there are a number of back ground database jobs running concurrently that use java stored procedures heavily e.g. XML Data loading using the XDK for Java. The problem occurs when 2 processes are trying to instantiate a number of dependant classes at the same time. What can happen is that the second process inadvertently attempts to instantiate a class that is already being instantiated by the first. This second instantiation alters an internal marker, which, since classes are shared, gets propagated to the other process that had already instantiated the class with a different marker. This inconsistency causes ORA-600 [26599] [1] [224] or ORA-600 [26599] [1] [229] to occur in the first process.

Once the error has occurred and the process has crashed, the process is able to be re run successfully, since it will now pick up the class instantiated previously. Therefore, as long as pmon does not crash cleaning the process up, and the application is able to re run the offending procedure, there is no long term effect on the server.

is fixed in 10.2, back ported to 10.1.0.4 and later and back ported to 9.2.0.7 and later. The fix to this bug is usually effective although in certain cases it may not be completely effective.

The likelihood of this happening can be reduced by preventing multiple processes loading the java classes all at once, say by setting job_queue_processes to 1 initially, allowing the application to run for a short while and then increasing job_queue_processes. An alternative is to ‘warm start’ the javavam using a startup trigger. The trigger is used to resolve commonly used classes, thus instantiating them as the database comes up and prior to any other processes so that when those processes do run, the classes have already been instantiated and there is no clash.

The problem can be in determining what code should go into the trigger.

A suggested method is as follows:

After the application has been running for a reasonable time, and all classes are loaded,run the following SQL*Plus code as sys or connected internal and spool the output to a file.
SET HEADING OFF
SET PAGESIZE 0
SET TRIMSPOOL ON

Spool tmpfile.txt

select 'X:=dbms_java.resolver('''||KGLNAOBJ||''',''SYS'',''JAVA CLASS'');'
from X$KGLOB
where KGLOBTYP=29
and KGLHDFLG=42991616;

spool off

this will give e.g.:

X:=dbms_java.resolver('sun/tools/asm/SwitchData','SYS','JAVA CLASS');
X:=dbms_java.resolver('/ab449c3a_CollectionsUnmodifia','SYS','JAVA CLASS');
X:=dbms_java.resolver('oracle/aurora/vm/CachedLocales','SYS','JAVA CLASS');
X:=dbms_java.resolver('java/lang/Number','SYS','JAVA CLASS');
..
X:=dbms_java.resolver('java/io/ObjectStreamClass$2','SYS','JAVA CLASS');
X:=dbms_java.resolver('sun/tools/tree/Les***pression','SYS','JAVA CLASS');
X:=dbms_java.resolver('java/util/AbstractList','SYS','JAVA CLASS');


Note that depending on the complexity there can be many more classes listed.
now as the SYS user, incorporate this into a procedure and call it from a startup trigger:
i.e.

create or replace procedure WARM_START_JAVAVM as

X varchar2(200);
begin

  X:=dbms_java.resolver('sun/tools/asm/SwitchData','SYS','JAVA CLASS');
  X:=dbms_java.resolver('/ab449c3a_CollectionsUnmodifia','SYS','JAVA CLASS');
  X:=dbms_java.resolver('oracle/aurora/vm/CachedLocales','SYS','JAVA CLASS');
  X:=dbms_java.resolver('java/lang/Number','SYS','JAVA CLASS');

  X:=dbms_java.resolver('java/io/ObjectStreamClass$2','SYS','JAVA CLASS');
  X:=dbms_java.resolver('sun/tools/tree/Les***pression','SYS','JAVA CLASS');
  X:=dbms_java.resolver('java/util/AbstractList','SYS','JAVA CLASS');

end;
/

create or replace trigger DB_START_JAVAVM after startup on database

begin
  WARM_START_JAVAVM;
end;
/
阅读(2590) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~