ora-00600:[17281], [1001]一例

检查告警日志发现出现ora-600:[17281],[1001]记录,该数据库版本为10.2.0.4:

ORA-00600: internal error code, arguments: [17281], [1001], [0x70000042F5E54F8], [], [], [], [], []
ORA-01001: invalid cursor

分析该600错误产生的trace文件,发现当时运行的语句是一段匿名块:

Current SQL statement for this session:
declare
t_owner varchar2(30);
t_name  varchar2(30);
procedure check_mview is
dummy integer;
begin
if :object_type = ‘TABLE’ then
select 1 into dummy
from sys.all_objects
where owner = :object_owner
and object_name = :object_name
and object_type = ‘MATERIALIZED VIEW’
and rownum = 1;
:object_type := ‘MATERIALIZED VIEW’;
end if;
exception
when others then null;
end;
begin
:sub_object := null;
if :deep != 0 then
begin
if :part2 is null then
select constraint_type, owner, constraint_name
into :object_type, :object_owner, :object_name
from sys.all_constraints c
where c.constraint_name = :part1 and c.owner = user
and rownum = 1;
else
select constraint_type, owner, constraint_name, :part3
into :object_type, :object_owner, :object_name, :sub_object
from sys.all_constraints c
where c.constraint_name = :part2 and c.owner = :part1
and rownum = 1;
end if;
if :object_type = ‘P’ then :object_type := ‘PRIMARY KEY’; end if;
if :object_type = ‘U’ then :object_type := ‘UNIQUE KEY’; end if;
if :object_type = ‘R’ then :object_type := ‘FOREIGN KEY’; end if;
if :object_type = ‘C’ then :object_type := ‘CHECK CONSTRAINT’; end if;
return;
exception
when no_data_found then null;
end;
end if;
:sub_object := :part2;
if (:part2 is null) or (:part1 != user) then
begin
select object_type, user, :part1
into :object_type, :object_owner, :object_name
from sys.all_objects
where owner = user
and object_name = :part1
and object_type in (‘MATERIALIZED VIEW’, ‘TABLE’, ‘VIEW’, ‘SEQUENCE’, ‘PROCEDURE’, ‘FUNCTION’, ‘PACKAGE’, ‘TYPE’, ‘TRIGGER’, ‘SYNONYM’)
and rownum = 1;
if :object_type = ‘SYNONYM’ then
select s.table_owner, s.table_name
into t_owner, t_name
from sys.all_synonyms s
where s.synonym_name = :part1
and s.owner = user
and rownum = 1;
select o.object_type, o.owner, o.object_name
into :object_type, :object_owner, :object_name
from sys.all_objects o
where o.owner = t_owner
and o.object_name = t_name
and object_type in (‘MATERIALIZED VIEW’, ‘TABLE’, ‘VIEW’, ‘SEQUENCE’, ‘PROCEDURE’, ‘FUNCTION’, ‘PACKAGE’, ‘TYPE’, ‘TRIGGER’, ‘SYNONYM’)
and rownum = 1;
end if;
:sub_object := :part2;
if :part3 is not null then
:sub_object := :sub_object || ‘.’ || :part3;
end if;
check_mview;
return;
exception
when no_data_found then null;
end;
end if;
begin
select s.table_owner, s.table_name
into t_owner, t_name
from sys.all_synonyms s
where s.synonym_name = :part1
and s.owner = ‘PUBLIC’
and rownum = 1;
select o.object_type, o.owner, o.object_name
into :object_type, :object_owner, :object_name
from sys.all_objects o
where o.owner = t_owner
and o.object_name = t_name
and object_type in (‘MATERIALIZED VIEW’, ‘TABLE’, ‘VIEW’, ‘SEQUENCE’, ‘PROCEDURE’, ‘FUNCTION’, ‘PACKAGE’, ‘TYPE’, ‘TRIGGER’, ‘SYNONYM’)
and rownum = 1;
check_mview;
return;
exception
when no_data_found then null;
end;
:sub_object := :part3;
begin
select o.object_type, o.owner, o.object_name
into :object_type, :object_owner, :object_name
from sys.all_objects o
where o.owner = :part1
and o.object_name = :part2
and object_type in (‘MATERIALIZED VIEW’, ‘TABLE’, ‘VIEW’, ‘SEQUENCE’, ‘PROCEDURE’, ‘FUNCTION’, ‘PACKAGE’, ‘TYPE’, ‘TRIGGER’, ‘SYNONYM’)
and rownum = 1;
check_mview;
return;
exception
when no_data_found then null;
end;
begin
if :part2 is null and :part3 is null
then
select ‘USER’, null, :part1
into :object_type, :object_owner, :object_name
from sys.all_users u
where u.username = :part1
and rownum = 1;
return;
end if;
exception
when no_data_found then null;
end;
begin
if :part2 is null and :part3 is null and :deep != 0
then
select ‘ROLE’, null, :part1
into :object_type, :object_owner, :object_name
from sys.session_roles r
where r.role = :part1
and rownum = 1;
return;
end if;
exception
when no_data_found then null;
end;
:object_owner := null;
:object_type := null;
:object_name := null;
:sub_object := null;
end;
—– Call Stack Trace —–
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
——————– ——– ——————– —————————-
ksedst+001c          bl       ksedst1              088424844 ? 041124844 ?
ksedmp+0290          bl       ksedst               104A54870 ?
ksfdmp+0018          bl       03F30204
kgeriv+0108          bl       _ptrgl
kgeasi+0118          bl       kgeriv               1104722C8 ? 1101B87C0 ?
104AFA0FC ? 7000000100067F8 ?
000000000 ?
kgicli+0188          bl       kgeasi               110195A58 ? 110447310 ?
438100004381 ? 200000002 ?
200000002 ? 000000000 ?
0000003E9 ? 000000002 ?
kgidlt+0398          bl       kgicli               110450A70 ? 104C734E0 ?
kgidel+0018          bl       kgidlt               FFFFFFFFFFF90B8 ? 000000000 ?
000000003 ? 000000000 ?
FFFFFFFFFFF9468 ?
perabo+00ac          bl       kgidel               FFFFFFFFFFF8D20 ? 0000000FF ?
perdcs+0050          bl       perabo               000000000 ? 000000820 ?
000000000 ?
peidcs+01dc          bl       perdcs               110477618 ? 000000000 ?
kkxcls+00a4          bl       peidcs               FFFFFFFFFFF9468 ? 110477618 ?
kxsClean+0044        bl       kkxcls               1100DD338 ?
kxsCloseXsc+0444     bl       kxsClean             FFFFFFFFFFF9760 ?
kksCloseCursor+031c  bl       kxsCloseXsc          110478688 ? 110281FB0 ?
opicca+00c4          bl       kksCloseCursor       104BD9640 ?
opiclo+00a0          bl       opicca               10013D940 ?
kpoclsa+0050         bl       03F32B00
opiodr+0ae0          bl       _ptrgl
ttcpip+1020          bl       _ptrgl
opitsk+1124          bl       01F9F2A0
opiino+0990          bl       opitsk               000000000 ? 000000000 ?
opiodr+0ae0          bl       _ptrgl
opidrv+0484          bl       01F9E0E8
sou2o+0090           bl       opidrv               3C02DC1BBC ? 44065F000 ?
FFFFFFFFFFFF3A0 ?
opimai_real+01bc     bl       01F9B9F4
main+0098            bl       opimai_real          000000000 ? 000000000 ?
__start+0098         bl       main                 000000000 ? 000000000 ?



first argument为17281,该代码对应为在关闭游标时发生错误事件。
发生错误时的调用栈为:kkxcls->peidcs->perdcs->perabo->kgidel->kgidlt->kgicli,通过以上调用栈与argument信息在600 lookup工具中查询,可以发现bug:[6051353]:

Hdr: 6051353 10.1.0.45 THIN 10.1.0.5 PRODID-972 PORTID-212 ORA-600
Abstract: ORA-600[17281] ORA-[1001]

*** 05/14/07 07:09 am ***
TAR:
----
17450130.600

PROBLEM:
--------
Oracle 10.1.0.5 64-bit
AIX5L 64-bit server

Following the application of CPUJAN2007 patch, the database is giving
internal errors.
Tha alert log sjows:
  ORA-600: internal error code, arguments: [17281], [1001],
[0x70000001E792DC8], [], [], [], [], []
  ORA-1001: invalid cursor

Trace file shows the failing statement is an insert.

INSERT INTO V_RPMORGRESOURCEPOSITION
(ORGID, RESOURCEID, EFFECTIVEDAY, TERMINATIONDAY, OWNEDMW,
COMMITTEDMW, AVAILABLEMW, UNOFFEREDMW, FRRCOMMITTEDMW )
SELECT :B12 , :B11 , EFFECTIVEDAY, LEAST(:B10 , :B9 ),
NVL(OWNEDMW,0) + NVL(:B8 ,0), NVL(COMMITTEDMW,0) + NVL(:B7 ,0),
NVL(AVAILABLEMW,0) + NVL(:B6 ,0), NVL(UNOFFEREDMW,0) + NVL(:B5 ,0),
NVL(FRRCOMMITTEDMW,0) + NVL(:B4 ,0)
FROM RPMORGRESOURCEPOSITION
WHERE ORGID = :B3 AND RESOURCEID = :B2 AND EFFECTIVEDAY = :B1

    Other information:
        O/S info: user: , term: , ospid: 1234, machine: esu03als
        client info: smartino@PJM
        application name: eRpm
        action name: QueryZonalLoadObligationDetail
        last wait for 'SQL*Net message from client'

DIAGNOSTIC ANALYSIS:
--------------------
the function stack exactly matches 4359111
kgicli kgidlt kgidel perabo
    Bug 4359111 - STRESS ORA-600[17281] WHEN RUNNING GMT APPLICATION13
But this is already fixed in 10.1.0.5

The 'client' (esu03als) is a Linux server and there is no oracle running
there.

The AIX SysAdmin. who manages the esu03als server says this about the
application:

    "The way RPM connects to our database is by using DBCP (Apache Jakarta
     Project -- see
     As far as I can tell, the release (jar) contained within the RPM
     delivery is version 1.1 of DBCP which was released on 2003-10-20."

This couls also be Bug 5392685/5413487 but tis doesn't seem to have a
resolution.

Also could be Bug 5366763
  possible workaround - set session_cached_cursors to 0
  But this is already set to 0.

Originally the Customer thought this error started after applying CPUJAN2007,
but it is appearing on another database where the CPU patch is not applied.

WORKAROUND:
-----------
none

RELATED BUGS:
-------------
4359111
5413487
5366763

REPRODUCIBILITY:
----------------
intermittent

TEST CASE:
----------
none

STACK TRACE:
------------
          ksedmp ksfdmp kgeriv kgeasi
          kgicli kgidlt kgidel perabo perdcs peidcs kkxcls2 kxtcln
          kxsClean kksCloseCursor opicca opiclo kpoclsa opiodr
          ttcpip opitsk opiino opiodr opidrv sou2o
          main

其调用栈完全一致,可以基本确定2者的关联性。但该文档叙述bug发生在10.1.0.5的AIX版本上,且据称该Bug之前已在“Bug 4359111 – STRESS ORA-600[17281] WHEN RUNNING GMT APPLICATION13”中声明并在10.1.0.5上修复,看起来又是一个伪修复的漏洞。另外一个文档叙述了同样的错误发生在10.2.0.4上:

Hdr: 8337808 10.2.0.4 RDBMS 10.2.0.4 PRG INTERFACE PRODID-5 PORTID-46 ORA-600 4359111
Abstract: ORA-600 [17281] [1001] EVEN AFTER APPLYING THE PATCH 4359111

In prod_ora_12985.trc we see that:
 O/S info: user: Arun?Sharma, term: ARUN, ospid: 2556:3300,
 machine: BVM-EDP\ARUN
Got the ORA-600 at 2009-04-17 13:27:21 .

From the trace this was likely because the PLSQL block in
cursor #2 has an instantiation entry indicating that it
has cursor #3 open:
 INSTANTIATION OBJECT: object=0xf60e9ed0
 type="PL/SQL"[0] lock=0xa383a928 handle=0xb48def6c body=(nil)
 flags=[40] executions=0
 CURSORS: size=4 count=1 next=3
 index cursor      tag  context flags
 ----- ------ -------- -------- ---------------
     2      3 0xf60d56f4 0xf60f832c LRU/PRS/[03]
            ^here

But there is no cursor#3 so it has likely been closed independently

So the immediate thing to do would be to find out what this OS
user (Arun Sharma) was doing at 13.27 on 17th April from the
ARUN machine under OS pid 2556:3300 ?
 - what was the client program ?
 - what is this clients Oracle RSF version ?
 - what was being done in that client at that time.

It is unlikely that the user will remember such fine detail
so you may want to track the alert log closely and as soon
as you seen the ORA-600 find the O/S user , machine etc..
and try to contact them ASAP to confirm what they were doing
etc.. If we can get a handle on the client version / program /
actions that may help. Beyond that the next step is likely
to need a diagnostic on the server side to note cursor close
operations from the client without extranoues additional trace.

From the above update his client is TOAD using 8.0.6.0 on Windows.
TOAD is known to be affected by bug 4359111 so
you should upgrade this client to a version where
bug 4359111 is fixed. (4359111 is a CLIENT SIDE fix)

Marking as an unconfirmed duplicate of bug 4359111
as it looks like some specific client may be connecting
which does not have that patch in place.

与以上文档描述相同,trace中存在以下记录:

INSTANTIATION OBJECT: object=1105e4fe8
type=”PL/SQL”[0] lock=70000044155a8b0 handle=70000042f5e54f8 body=0 level=0
flags=[40] executions=0
CURSORS: size=4 count=3 next=5
index cursor      tag  context flags
—– —— ——– ——– —————
2      4 11049ecc8 110525f60 LRU/PRS/[03]
3      6 11049ecc8 1105261f0 LRU/PRS/[03]
4      5 11049ecc8 110526338 LRU/PRS/[03]

但实际上这里cursor 3所打开的cursor#:4,5,6均不存在,所以cursor# 3也被单独关闭了。文档中问题是由toad引起的,首先toad连接数据库是不需要安装Oracle client的,它通过一些客制化过的c/c++的接口连接到DB;如文档所述可以确定toad V8.0.6.0受到 Bug4359111的影响,而我们的环境中是通过PL/SQL developer连接到数据库的,该工具需要用到Oracle client,而开发人员安装的Oracle client一般为9.2.0.1,极有可能是这一较低版本的客户端软件造成了问题发生,到这里触发Bug的条件基本清晰了。

8i/9i的oracle client虽然仍能够连接到10g,但难保不发生一些兼容性问题或者将早期版本中的Bug再次代入,Oracle对这些连接形式或已不提供技术支持,或提供扩展模式(可能收费)的技术支持。以下列表列出了各版本Server-client的兼容性:



  • #1 – See Note 207319.1
  • #2 – An ORA-3134 error is incorrectly reported if a 10g client tries to connect to an 8.1.7.3 or lower server. See Note 3437884.8 .
  • #3 – An ORA-3134 error is correctly reported when attempting to connect to this version.
  • #4 – There are problems connecting from a 10g client to 8i/9i where one is EBCDIC based. See Note 3564573.8
  • #5 – For connections between 10.2 (or higher) and 9.2 the 9.2 end MUST be at 9.2.0.4 or higher. Connections between 10.2 (or higher) and 9.2.0.1, 9.2.0.2 or 9.2.0.3 are not supported.
  • #6 – For connections between 11.1 (or higher) and 10.1 / 10.2 the 10g end MUST be at 10.1.0.5 / 10.2.0.2 (or higher) respectively in order to use PLSQL between those versions. See Note 4511371.8 for more details.

其实在我们升级或迁移Oracle数据库的时候就因该考虑到客户端软件也需要升级到合适版本才能满足今后兼容性及应用程序健壮度的要求,当然客户端软件并不一定只是oracle client,它可能是jdbc,也许是odbc,也许是dbi等等。

关注dbDao.com的新浪微博

扫码关注dbDao.com 微信公众号:

Comments

  1. admin says:

    该会话在exit时又出现了ora-600[17271]trace:
    **********************************************
    ********** INTERNAL ERROR 17271 **********
    ********** INSTANTIATION SPACE LEAK **********
    **********************************************
    KGI STATE DUMP for session=70000048a2d24c0
    ————————————-
    INSTANTIATION OBJECT: object=11050d7b8
    type=”PL/SQL”[0] lock=70000044cb56be0 handle=700000436736d40 body=0 level=0
    flags=[40] executions=0
    KGI STATE DUMP DONE for session=70000048a2d24c0
    *** 2010-07-28 17:54:12.312
    ksedmp: internal or fatal error
    ORA-00600: internal error code, arguments: [17271], [instantiation space leak], [], [], [], [], [], []
    —– Call Stack Trace —–
    calling call entry argument values in hex
    location type point (? means dubious value)
    ——————– ——– ——————– —————————-
    ksedst+001c bl ksedst1 1042BC9BC ? 000000000 ?
    ksedmp+0290 bl ksedst 104A54870 ?
    ksfdmp+0018 bl 03F30204
    kgeriv+0108 bl _ptrgl
    kgesiv+0080 bl kgeriv FFFFFFFFFFF8C30 ? 104AFA494 ?
    000000001 ? 000000000 ?
    11050D7B8 ?
    kgesic1+0040 bl kgesiv 000000000 ? 000000000 ?
    1101C5A20 ? 104AFA4C4 ?
    104AFA434 ?
    kgisdl+0108 bl kgesic1 110195A58 ? 110447310 ?
    437700004377 ? 000000001 ?
    000000018 ? 104AFA4C4 ?
    000000000 ? 000000000 ?
    ksuxds+06b4 bl kgisdl 000000000 ? 90000000050D250 ?
    ksudel+0054 bl ksuxds 70000048A2D24C0 ? 104AFEAF8 ?
    opilof+0c7c bl 03F32528
    opiodr+0ae0 bl _ptrgl
    ttcpip+1020 bl _ptrgl
    opitsk+1124 bl 01F9F2A0
    opiino+0990 bl opitsk 000000000 ? 000000000 ?
    opiodr+0ae0 bl _ptrgl
    opidrv+0484 bl 01F9E0E8
    sou2o+0090 bl opidrv 3C02DC1BBC ? 44065F000 ?
    FFFFFFFFFFFF3A0 ?
    opimai_real+01bc bl 01F9B9F4
    main+0098 bl opimai_real 000000000 ? 000000000 ?
    __start+0098 bl main 000000000 ? 000000000 ?

    MOS文档ID 821603.1指出:

    ORA-600 [17271] [instantiation space leak] During the Session Exit [ID 821603.1]
    Applies to:
    Oracle Server – Enterprise Edition – Version: 10.2.0.4
    This problem can occur on any platform.
    Symptoms
    The following errors are reported in the alert log file:

    ORA-00600: internal error code, arguments: [17271], [instantiation space leak], [], [], [], [],[], []

    and the trace file will show the instantiation object corresponds to top level plsql object (PL/SQL[0]) :

    INSTANTIATION OBJECT: object=ffffffff57c0a190
    type=”PL/SQL”[0] lock=39b3624f0 handle=399bc6c28 body=0 level=0
    flags=[40] executions=0

    Cause
    Bug 5932986 ORA-00600 [17271], [INSTANTIATION SPACE LEAK] UPON SESSION EXIT

    With Table function queries on session exit we see internal error 17271.
    The ORA-600[17271] error will not corrupt the database in any way and can be safely ignored.
    It is raised when Oracle tries to deinstantiate shareable objects (eg cursors) during logoff etc.

    Solution
    1. The error can be ignored

    2. Install the future patchset 10.2.0.5 when was available. This patchset will include the fix for
    the Bug 5932986

    又一个可忽略的Bug……

  2. admin says:

    Type B – Defect Fixed in Product Version 10.2.0.99
    Severity 2 – Severe Loss of Service Product Version 10.2.0.1.0
    Status 80 – Development to Q/A Platform 23 – Oracle Solaris on SPARC (64-bit)
    Created 14-Mar-2007 Platform Version –
    Updated 23-Sep-2008 Base Bug –
    Database Version 10.2.0.1.0
    Affects Platforms Generic
    Product Source Oracle

    Show Related Products Related Products
    Line Oracle Database Products Family Oracle Database
    Area Application Development Product 11 – PL/SQL

    Hdr: 5932986 10.2.0.1.0 PLSQL 10.2.0.1.0 PRODID-11 PORTID-23
    Abstract: ORA-600 [17271], [INSTANTIATION SPACE LEAK] UPON SESSION EXIT

    *** 03/14/07 03:15 am ***
    TAR:
    —-
    6177281.993

    PROBLEM:
    ——–

    DIAGNOSTIC ANALYSIS:
    ——————–

    According to the Bug.4362818, ORA-600 [17271], [INSTANTIATION SPACE LEAK] can
    occur, when CURSOR_SPACE_FOR_TIME=TRUE

    But in this case it is already false.

    SQL> show parameter cursor_space_for_time
    cursor_space_for_time boolean FALSE

    WORKAROUND:
    ———–
    Not avilable

    RELATED BUGS:
    ————-
    Bug.4362818

    REPRODUCIBILITY:
    —————-
    Each time durring insert in plan table on diffrent platforms. Tested on
    windows and solaris. Error is also reproducible in 10.2.0.3

    TEST CASE:
    ———-

    /* Create plan table */

    create table plan_tab
    (sql_id varchar2(20),
    plan_obj sys.DBMS_XPLAN_TYPE_TABLE)
    nested table plan_obj store as plan_t;

    /* Execute the following statements. */

    show parameter cursor

    select /*HELLO*/ count(*) from SCOTT.emp;

    select sql_id,sql_text from v$sql where sql_text like ‘%HELLO%’ and sql_text
    not like ‘%v$sql%’;

    /* Replace the “sql_id” retrived in the above statement with “&&sql_id” in
    the following insert. */

    insert into plan_tab (sql_id, plan_obj) values
    (‘&&sql_id’,sys.DBMS_XPLAN_TYPE_TABLE());

    insert into the(select plan_obj from plan_tab where sql_id = ‘&&sql_id’)
    select * from table(dbms_xplan.display_cursor(‘&&sql_id’));

    exit;

    /* You will get the ORA-600: INTERNAL ERROR CODE, ARGUMENTS: [17271],
    [INSTANTIATION SPACE LEAK] error in alert log file once you log off */

    STACK TRACE:
    ————
    ksedmp kgeriv kgesiv kgesic1 kgisdl ksuxds
    ksudel opilof opiodr ttcpip opitsk opiino
    opiodr opidrv sou2o opimai_real main start

  3. admin says:

    Type B – Defect Fixed in Product Version 10.2
    Severity 3 – Minimal Loss of Service Product Version 9.2.0.6
    Status 35 – To Filer for Review Platform 453 – Oracle Solaris on SPARC (32-bit)
    Created 11-May-2005 Platform Version –
    Updated 09-Oct-2006 Base Bug –
    Database Version 9.2.0.6
    Affects Platforms Generic
    Product Source Oracle

    Show Related Products Related Products
    Line Oracle Database Products Family Oracle Database
    Area Oracle Database Product 5 – Oracle Server – Enterprise Edition

    Hdr: 4362818 9.2.0.6 RDBMS 9.2.0.6 DICTIONARY PRODID-5 PORTID-453
    Abstract: ORA-600 [17271], [INSTANTIATION SPACE LEAK] WHEN CURSOR_SPACE_FOR_TIME=TRUE

    *** 05/11/05 12:46 am ***
    TAR:
    —-
    SR 4423347.999

    PROBLEM:
    ——–

    When cursor_space_for_time=true is set, insert into nested table fails with

    INSERT INTO APPLICATION_PARAMETER_SETS (
    *
    ERROR at line 1:
    ORA-603: ORACLE server session terminated by fatal error

    ORA-600: internal error code, arguments: [17271], [instantiation space
    leak],
    [], [], [], [], [], []

    DIAGNOSTIC ANALYSIS:
    ——————–

    With cursor_space_for_time=false (default value) this works.

    Reproduced in-house on Linux x86:
    9.2.0.6: reproduces
    10.1.0.4: reproduces

    Reproduces with sql_trace=false.

    WORKAROUND:
    ———–
    cursor_space_for_time=false

    RELATED BUGS:
    ————-

    REPRODUCIBILITY:
    —————-
    Consistently

    TEST CASE:
    ———-
    available

    STACK TRACE:
    ————
    On Solaris 9206 32-bit:

    ksedmp kgeriv kgesiv kgesic1 kgisdl ksuxds
    kssdch_stage ksudlc ksupop opiodr ttcpip opitsk
    opiino opiodr opidrv sou2o main start

  4. admin says:

    ORA-21780 And ORA-00600 [17271] [Instantiation Space Leak] [ID 759432.1]
    Applies to:
    Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 10.2.0.3 – Release: 10.2 to 10.2

    Symptoms

    Running PL/SQL may fail with below errors:

    ORA-21780
    and
    ORA-00600: internal error code, arguments: [17271], [instantiation space leak]

    Cause

    This behavior was noted in Bug 6370942

    Abstract: ORA-21780 ERRORS WHEN EXECUTING PL/SQL PACKAGES FROM JAVA WEB APPLICATION:

    This bug was closed as duplicate of unpublished Bug: 6061892

    Details:

    A long running application that drops and/or recreates many plsql packages or top-level procedures or functions which are used in calls from SQL to PL/SQL may result in ORA-21780: MAXIMUM NUMBER OF DURATIONS EXCEEDED and/or ORA-4030: OUT OF PROCESS MEMORY error messages.

    This is fixed in the 10.2.0.4 patchset and 11.1.0.6 release
    Solution

    1. Upgrade to 10.2.0.4 or higher.

    2. If available for your platform/version, download and apply merge Patch 6837452 as the one-off patch for unpublished Bug 6061892 introduces the problem described in unpublished Bug: 6139254.

    Hence we need to apply the merge Patch 6837452 , which contains the fix for both bugs.

  5. admin says:

    Type B – Defect Fixed in Product Version –
    Severity 2 – Severe Loss of Service Product Version 9.2.0.4.0
    Status 91 – Closed, Could Not Reproduce Platform 23 – Oracle Solaris on SPARC (64-bit)
    Created 02-Jun-2004 Platform Version –
    Updated 05-Jan-2005 Base Bug –
    Database Version 9.2.0.4.0
    Affects Platforms Generic
    Product Source Oracle

    Show Related Products Related Products
    Line Oracle Database Products Family Oracle Database
    Area Oracle Database Product 5 – Oracle Server – Enterprise Edition

    Hdr: 3666444 9.2.0.4.0 RDBMS 9.2.0.4.0 DICTIONARY PRODID-5 PORTID-23 ORA-600
    Abstract: ORA-600 [17271] [INSTANTIATION SPACE LEAK] ERRORS RUNNING APPLICATION

    *** 06/02/04 07:42 am ***
    TAR:
    —-
    3762039.994

    PROBLEM:
    ——–

    Customer has a third party application (LoadRunner) that is running using
    approx 10 ~ 12 simultaneous sessions. After 10 or 12 connections are used the
    ora-600 [17271] error is received in the alert log continuously and additional

    DIAGNOSTIC ANALYSIS:
    ——————–
    Trace log provides the following:
    INSTANTIATION OBJECT: object=ffffffff7cf72f90
    type=”cursor”[2] lock=3bcecc998 handle=3b0db9360 body=0 level=0
    flags=FST[60] executions=0
    ————————————-
    INSTANTIATION OBJECT: object=ffffffff7cf9d358
    type=”cursor”[2] lock=3acb57360 handle=3b0db9360 body=0 level=0
    flags=FST[60] executions=0

    ORA-600: internal error code, arguments: [17271], [instantiation space
    leak], [], [], [], [],
    [], []

    SO: 3a73aac58, type: 4, owner: 3a83cf668, flag: INIT/-/-/0x00
    (session) trans: 0, creator: 3a83cf668, flag: (18100041) USR/-
    BSY/-/-/DEL/-/- DID: 0001-005E-000003A6, short-term DID: 0000-0000-00000000txn
    branch: 0 oct: 0, prv: 0, sql: 3b0db9360, psql: 3b0db9360, user: 33/MDR_USER
    O/S info: user: weblogic, term: unknown, ospid: , machine:
    message from client’ blocking sess=0x0 seq=28524 wait_time=596029877 driver
    id=74637000, #bytes=1, =0 temporary object counter: 0

    Did not find any known issues to match this problem. Note that alert.log also
    contains an intermittent snapshot error (which may or may not be related)..
    ORA-12012: error on auto execute of job 3
    ORA-12535: TNS:operation timed out
    ORA-6512: at “SYS.DBMS_SNAPSHOT”, line 794
    ORA-6512: at “SYS.DBMS_SNAPSHOT”, line 851
    ORA-6512: at “SYS.DBMS_IREFRESH”, line 683
    ORA-6512: at “SYS.DBMS_REFRESH”, line 195
    ORA-6512: at line 1

    WORKAROUND:
    ———–
    N/A

    RELATED BUGS:
    ————-

    REPRODUCIBILITY:
    —————-
    Ct can reproduce this problem on demand by running the application with 10 to
    12 connections.

    TEST CASE:
    ———-
    N/A

    STACK TRACE:
    ————
    kgesic1 kgisdl ksuxds ksudel opidcl opidrv

    SUPPORTING INFORMATION:
    ———————–
    alert.log and trace file will be uploaded to ess30. RDA is available at GTCR.

Speak Your Mind

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569