Re: Statistics stopping after a while

From: Frederic PAYANT <fpayant_at_club-internet.fr>
Date: 15 Apr 2002 05:42:55 -0700
Message-ID: <b6525ebd.0204150442.4cbc9f32@posting.google.com>

Thanks to you,

I finally found that I had a trouble with one of my indexes, which refuse to be analyzed (some sort of timid index maybe ;-) )

I've a log in my alert files and a dump in udump directory.

Alert is as follow :
Errors in file /product/oracle/admin/PINDB011/udump/pindb011_ora_3759.trc: ORA-00600: internal error code, arguments: [17056], [2168011084], [], [], [], [], [], []

dump begin like this :
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production With the Partitioning option
JServer Release 8.1.7.0.0 - Production
ORACLE_HOME = /product/oracle/moteur/8.1.7 System name: SunOS

Node name:      burton
Release:        5.8
Version:        Generic_108528-12
Machine:        sun4u

Instance name: PINDB011
Redo thread mounted by this instance: 1
Oracle process number: 25
Unix process pid: 3759, image: oracle_at_burton (TNS V1-V3)

SESSION ID:(26.1661) 2002-04-14 22:01:35.681
2002-04-14 22:01:35.681 ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [17056], [2168011084], [], [], [], [], [], [] Current SQL statement for this session: analyze index "PIN"."SYS_IL0000015309C00003$$" COMPUTE statistics ----- PL/SQL Call Stack ----- object line object handle number name 8127da34 184 package body SYS.DBMS_DDL 81327508 4319 package body SYS.DBMS_STATS 81327508 4443 package body SYS.DBMS_STATS 81327508 4605 package body SYS.DBMS_STATS 81327508 4756 package body SYS.DBMS_STATS 81327508 4741 package body SYS.DBMS_STATS 813348bc 1 anonymous block ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- --------------------
ksedmp()+168 CALL ksedst()+0 540 ? 0 ? FFBD6748 ? FFBD61EC ? FFBD61D0 ? 0 ?

Can I get any information of this dump, or must I send it to Oracle to obtain info ?
(the point is that this error occurs on all my databases, who all are installed the same way. Therefore I suppose that this problem must be something very trivial in our installation scripts, but apart that it is index SYS_IL0000015309C00003$$ which is responsible, I can't deduice anything else )

Thanks for your help and have a nice day ( or night for eastern timed people
;-D )

Frederic PAYANT Received on Mon Apr 15 2002 - 07:42:55 CDT