>ORA-00600: internal error code, arguments: [kqlfFillBindData:1]

>http://updates.oracle.com/ARULink/PatchDetails/process_form?aru=9130568&patch_password=&no_header=0

Subject: ORA-00600[kqlfFillBindData:1] Raised
Doc ID: 428018.1 Type: PROBLEM
Modified Date: 23-MAY-2008 Status: MODERATED

In this Document
Symptoms
Cause
Solution
References

This document is being delivered to you via Oracle Support’s Rapid Visibility (RaV) process, and therefore has not been subject to an independent technical review.

Applies to:
Oracle Server – Enterprise Edition – Version: 10.2.0.2.0
This problem can occur on any platform.
Symptoms

The following errors are seen in the alert log:

ORA-00600: internal error code, arguments: [kqlfFillBindData:1]

The following errors may also occur:

ORA-00600: internal error code, arguments: [729]

ORA-00600: internal error code, arguments: [1234]

The stack trace may look like the following:

ksedst ksedmp ksfdmp kgerinv kgeasnmierr kqlfFillBindData kqlffc kqlfgo kgligo
Cause

This issue is caused by Bug 5638146 ORA-600[KQLFFILLBINDDATA:1] ON INSERT INTO WRH$_SQLSTAT ON 10.2.0.2.
Solution

To resolve this issue, you may choose any one of these options:

1. Apply the 10.2.0.4 patchset which was not available at the time of this writing (Apr 2007).

2. Check MetaLink for backport Patch 5638146 for your operating system and database release.

3. Use the workaround:
Use a smaller number of bind variables in the query.
References
Bug 5638146 – ORA-600[KQLFFILLBINDDATA:1] ON INSERT INTO WRH$_SQLSTAT ON 10.2.0.2
——————————————
SQL ;
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kqlfFillBindData:1], [669], [468], [], [], [], [], []
Current SQL statement for this session:
insert into wrh$_sqlstat (snap_id, dbid, instance_number, sql_id, plan_hash_value, optimizer_cost, optimizer_mode, optimizer_env_hash_value, sharable_mem, loaded_versions, version_count, module, action, sql_profile, force_matching_signature, parsing_schema_id, parsing_schema_name, fetches_total, fetches_delta, end_of_fetch_count_total, end_of_fetch_count_delta, sorts_total, sorts_delta, executions_total, executions_delta, px_servers_execs_total, px_servers_execs_delta, loads_total, loads_delta, invalidations_total, invalidations_delta, parse_calls_total, parse_calls_delta, disk_reads_total, disk_reads_delta, buffer_gets_total, buffer_gets_delta, rows_processed_total, rows_processed_delta, cpu_time_total, cpu_time_delta, elapsed_time_total, elapsed_time_delta, iowait_total, iowait_delta, clwait_total, clwait_delta, apwait_total, apwait_delta, ccwait_total, ccwait_delta, direct_writes_total, direct_writes_delta, plsexec_time_total, plsexec_time_delta, javexec_time_total, javexec_time_delta, bind_data, flag) SELECT /*+ ordered use_nl(sql) index(sql kglobt03) */ :snap_id, :dbid, :instance_number, kglobt03, kglobt30, kglobtn0, decode(kglobt32, 0, ‘NONE’, 1, ‘ALL_ROWS’, 2, ‘FIRST_ROWS’, 3, ‘RULE’, 4, ‘CHOOSE’, ‘UNKNOWN’), kglobcceh, kglobhs0+kglobhs1+kglobhs2+kglobhs3+ kglobhs4+kglobhs5+kglobhs6, kglobclc, kglobccc, kglobts0, kglobts1, kglobts3, kglobt49, kglobt18, kglobts4, kglobt04, kglobdft, kglobt35, kglobdef, kglobt01, kglobdso, kglobt05, kglobdex, kglobt48, kglobdpx, kglhdldc, kglobdld, kglhdivc, kglobdiv, kglobt12, kglobdps, kglobt13, kglobddr, kglobt14, kglobdbf, kglobt15, kglobdro, kglobt06, kglobdcp, kglobt07, kglobdel, kglobwui, kglobdui, kglobwcl, kglobdcl, kglobwap, kglobdap, kglobwcc, kglobdcc, kglobwdw, kglobddw, kglobt42, kglobdpl, kglobt43, kglobdjv, kglobcbca, NULL FROM X$KEWRSQLIDTAB sie, X$KGLCURSOR_CHILD_SQLIDPH sql WHERE sie.sqlid_kewrsie = sql.kglobt03
—– Call Stack Trace —–
———————————

Bug No: 5638146
Filed 01-NOV-2006 Updated 01-APR-2009
Product Oracle Server – Enterprise Edition Product Version 10.2.0.2.0
Platform AIX5L Based Systems (64-bit) Platform Version No Data
Database Version 10.2.0.2.0 Affects Platforms Generic
Severity Severe Loss of Service Status Development to Q/A
Base Bug N/A Fixed in Product Version 11.1.0.0

Problem statement:

ORA-600[KQLFFILLBINDDATA:1] ON INSERT INTO WRH$_SQLSTAT ON 10.2.0.2

*** 11/01/06 03:38 pm ***

PLEASE SEE TESTCASE AT *** RSPOWELL 02/19/07 05:12 am ***

*** 11/08/06 04:43 pm *** (CHG: Sta->16)

*** 11/08/06 04:43 pm ***

*** 11/09/06 03:05 am *** (CHG: Asg->NEW OWNER)

*** 11/09/06 03:39 am *** (CHG: Sta->10)

*** 11/09/06 03:39 am ***

*** 12/01/06 03:53 pm *** (CHG: Sta->16)

*** 12/01/06 03:53 pm ***

*** 12/01/06 03:56 pm ***

*** 12/04/06 01:12 am *** (CHG: Sta->10)

*** 12/04/06 01:12 am ***

The CTAS has to be taken when the problem ORA-600 occurs

so we can look at the content in relation to the trace

to see if we can see what may have caused the problem.

Do you have the trace matching the time when this CTAS

was done so we can try to cross reference.

*** 12/19/06 03:57 pm *** (CHG: Sta->16)

*** 12/19/06 03:57 pm ***

*** 12/20/06 03:42 am *** (CHG: Sta->10)

*** 12/20/06 03:42 am ***

*** 01/19/07 10:31 am *** (CHG: Sta->16)

*** 01/19/07 10:31 am ***

*** 01/22/07 09:41 am *** (CHG: Sta->10)

*** 01/22/07 09:41 am ***

*** 01/22/07 02:25 pm *** (CHG: Sta->16)

*** 01/22/07 02:25 pm ***

*** 01/23/07 02:37 am *** (CHG: Sta->10)

*** 01/23/07 02:37 am ***

I suspect “c” may raise questions. Something like

this may help catch the bad SQL_ID:

.

drop table xx_bug;

create table xx_bug (

SQL_ID VARCHAR2(13),

ADDR RAW(8)

);

declare

bnd raw(2000);

begin

for R in (select addr, KGLOBT03 from X$KGLCURSOR_CHILD_SQLIDPH)

loop

insert into xx_bug values(R.KGLOBT03, R.addr);

commit;

begin

— See if this SQL_ID bind info throws ORA-600

select max(KGLOBCBCA) into bnd from X$KGLCURSOR_CHILD_SQLIDPH

where KGLOBT03=R.KGLOBT03;

exception

when no_data_found then

null; — This is ok as row gone now

end;

— If we got here we did not ORA-600. Delete the row.

delete from xx_bug;

commit;

end loop;

end;

/

set pages 1000

select * from xx_bug;

select * from X$KGLCURSOR_CHILD_SQLIDPH where KGLOBT03=’&id’;

.

.

This will scan X$KGLCURSOR_CHILD_SQLIDPH and for each

row insert the SQL_ID into xx_bug. It then tries to get

the bind info for that X$KGLCURSOR_CHILD_SQLIDPH sql_id .

If it succeeds this is not the bad row so it deletes from

xx_bug. If the row has gone it deletes the xx_bug row.

If the row throws ORA-600 the SQL_ID will be left in

xx_bug.

.

The select after the PLSQL block should confirm if that

is the problem SQL_ID. As much info as possible about that

SQL_ID would then be helpful, including all the events+dumps

listed.

.

*** 02/16/07 03:30 pm *** (CHG: Sta->16)

*** 02/16/07 03:30 pm ***

*** 02/19/07 05:12 am *** (CHG: Sta->11 SubComp->LIB CACHE)

*** 02/19/07 05:12 am ***

.

BDE Screening

~~~~~~~~~~~~~

Testcase

~~~~~~~~~~~~~~~~~

.

Files: BDETC.tar.Z (containing setup.sql, tc.sql)

.

Steps:

sqlplus /nolog @setup

Create a user TC, a table TST and then issues a SQL

statement which uses a large number of bind variables

(5480 binds) . The statement is run few times to ensure it

is cached in the SGA.

.

sqlplus /nolog @tc

Runs a select of KGLOBCBCA from X$KGLCURSOR_CHILD_SQLIDPH

^

ORA-600 [kqlfFillBindData:1], [1200], [636]

.

Reproduced

~~~~~~~~~~

Reproduced in 10.2.0.2

Reproduced in RDBMS_MAIN_LINUX_070216

.

.

Workaround/s

~~~~~~~~~~~~

Do not use > 5461 bind variables in a single SQL

.

.

*** 02/19/07 05:12 am *** (CHG: Asg->NEW OWNER)

*** 02/19/07 05:12 am ***

*** 02/21/07 05:00 am *** (CHG: DevPri->2)

*** 02/21/07 05:00 am *** (CHG: Confirmed Flag->Y)

*** 02/21/07 05:00 am *** (CHG: Asg->NEW OWNER)

*** 02/21/07 05:00 am ***

*** 02/21/07 05:00 am *** (CHG: Asg->NEW OWNER)

*** 02/23/07 07:00 am *** ESCALATED

*** 02/23/07 07:04 am ***

*** 02/24/07 08:36 am *** (CHG: Asg->NEW OWNER)

*** 02/24/07 08:36 am ***

*** 03/02/07 03:14 pm ***

*** 03/07/07 06:18 pm ***

*** 03/20/07 05:44 am ***

*** 03/20/07 09:37 am ***

*** 03/28/07 10:22 am ***

*** 04/03/07 07:49 am ***

*** 04/04/07 06:40 pm ***

REDISCOVERY INFORMATION:

If ‘ORA-00600 [kqlfFillBindData:1]’ is raised and there are

thousands of bind variables in the SQL statement, then you

may be encountering this particular problem.

WORKAROUND:

Try to reduce the number of bind variables.

RELEASE NOTES:

]]’ORA-00600 [kqlfFillBindData:1]’ is no longer raised against

]]a SQL statement containing thousands of bind variables.

*** 04/04/07 06:47 pm *** (CHG: Fixed->11.1.0.0)

*** 04/04/07 06:47 pm *** (CHG: Sta->80)

*** 04/05/07 06:14 am ***

*** 04/05/07 08:43 am ***

*** 04/05/07 12:58 pm ***

*** 04/05/07 01:25 pm ***

*** 04/05/07 01:26 pm ***

*** 04/05/07 01:26 pm ***

*** 04/06/07 04:42 am ***

*** 04/06/07 04:04 pm ***

*** 04/08/07 11:28 am ***

*** 04/09/07 08:58 am ***

*** 04/09/07 03:19 pm ***

*** 04/10/07 07:09 am ***

*** 04/10/07 01:17 pm ***

*** 04/11/07 03:11 pm ***

*** 04/12/07 01:53 pm ***

*** 04/12/07 07:30 pm ***

*** 04/13/07 10:30 am ***

*** 04/15/07 04:31 pm ***

*** 04/15/07 04:32 pm ***

*** 04/15/07 04:32 pm ***

*** 04/15/07 04:34 pm ***

*** 04/15/07 04:35 pm ***

*** 04/15/07 04:36 pm ***

*** 04/15/07 04:36 pm ***

*** 04/15/07 04:37 pm ***

*** 04/15/07 04:37 pm ***

*** 04/16/07 07:22 am ***

*** 04/18/07 02:24 am ***

*** 04/18/07 03:50 am ***

*** 04/19/07 12:20 am ***

*** 04/19/07 04:22 am ***

*** 04/19/07 05:18 am ***

*** 04/19/07 05:20 am ***

*** 04/19/07 05:20 am ***

*** 04/19/07 05:20 am ***

*** 04/19/07 05:20 am ***

*** 04/19/07 05:20 am ***

*** 04/19/07 05:20 am ***

*** 04/19/07 05:20 am ***

*** 04/19/07 05:22 am ***

*** 04/19/07 05:28 am ***

*** 04/19/07 10:51 am ***

*** 04/23/07 02:50 am ***

*** 04/23/07 02:52 am ***

*** 04/24/07 05:59 am ***

*** 05/14/07 03:21 pm ***

*** 05/16/07 03:10 am ***

*** 05/16/07 11:27 pm ***

*** 05/18/07 03:26 am ***

*** 05/18/07 03:28 am ***

*** 05/18/07 04:02 am ***

*** 05/18/07 04:04 am ***

*** 05/18/07 04:13 am ***

*** 05/18/07 06:31 am ***

*** 05/25/07 06:54 pm ***

*** 05/29/07 07:47 pm ***

*** 06/01/07 01:33 pm ***

bug 5638146

*** 06/26/07 03:22 am ***

*** 06/28/07 01:08 am ***

*** 06/28/07 01:18 am ***

*** 07/30/07 02:02 am ***

*** 08/08/07 01:07 pm ***

*** 08/08/07 01:08 pm ***

*** 08/23/07 11:59 am ***

*** 08/29/07 02:08 am ***

*** 08/30/07 12:18 pm ***

*** 08/30/07 12:18 pm ***

*** 09/01/07 03:16 am ***

*** 09/07/07 07:05 am ***

*** 09/07/07 07:07 am ***

*** 10/26/07 01:01 am ***

*** 11/09/07 03:08 am ***

*** 11/09/07 03:20 am ***

*** 11/09/07 12:07 pm ***

*** 11/09/07 12:09 pm ***

*** 11/09/07 09:29 pm ***

*** 11/09/07 09:31 pm ***

*** 11/13/07 01:50 pm ***

*** 11/18/07 03:25 pm ***

*** 11/19/07 11:48 pm ***

*** 11/19/07 11:50 pm ***

*** 05/07/08 01:17 am ***

*** 05/07/08 02:42 am ***

*** 05/07/08 02:42 am ***

*** 12/17/08 04:42 pm ***

*** 12/24/08 05:19 am ***

*** 03/17/09 03:25 pm ***

*** 03/17/09 05:57 pm ***

*** 04/01/09 11:08 am ***

.
———————————-
README for 5638146
Patch Details

#
# WARNING: Failure to carefully read and understand these requirements may
# result in your applying a patch that can cause your Oracle Server to
# malfunction, including interruption of service and/or loss of data.
#
# If you do not meet all of the following requirements, please log an
# iTAR, so that an Oracle Support Analyst may review your situation. The
# Oracle analyst will help you determine if this patch is suitable for you
# to apply to your system. We recommend that you avoid applying any
# temporary patch unless directed by an Oracle Support Analyst who has
# reviewed your system and determined that it is applicable.
#
# Requirements:
#
# – You must have located this patch via a Bug Database entry
# and have the exact symptoms described in the bug entry.
#
# – Your system configuration (Oracle Server version and patch
# level, OS Version) must exactly match those in the bug
# database entry – You must have NO OTHER PATCHES installed on
# your Oracle Server since the latest patch set (or base release
# x.y.z if you have no patch sets installed).
#
# – [Oracle 9.2.0.2 & above] You must have Perl 5.00503 (or later)
# installed under the ORACLE_HOME, or elsewhere within the host
# environment. OPatch is no longer included in patches as of 9.2.0.2.
# Refer to the following link for details on Perl and OPatch:
# http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=189489.1
#
# – [IBM AIX O/S & Java patches for Oracle 9.2]
# In order to apply java class updates to IBM AIX based systems using
# java_131, you must update your java if you are running a version prior
# to Service Refresh build date 20030630a. This is
# necessary to fix IBM Defect#60472.
#
# To identify which java build date you are on, enter the following
# command ;
#
# > $ORACLE_HOME/jdk/bin/java -fullversion
# … example response …
# java full version “J2RE 1.3.1 IBM AIX build ca131-20030630a”
#
# The string ends in the date format YYYYMMDD or YYYYMMDDa where ‘a’
# indicates an updated release to the original build. You should always
# apply the latest AIX Java SDK 1.3.1 Service Update available from IBM.
# As a minimum, the above service refresh can be found under
# APAR IY47055. The signature for the updated JVM is ca131-20030630a.
# Information on the latest available fixes, as well as how to apply
# the APARs to your AIX systems, is available at the IBM Java site.
#
# If you are running AIX 5L, you can safely ignore any comment against
# the APAR that says (AIXV43 only). The APAR is applicable to
# both AIX 4.3 and AIX 5L.
#
# Once you have updated your java installation you need to copy these
# updated files to Oracle’s copies in $ORACLE_HOME/jdk.
# As the Oracle owner, simply issue the following commands;
#
# > cd /usr/java131
# > cp -fpR * $ORACLE_HOME/jdk
#
#
# If you do NOT meet these requirements, or are not certain that you meet
# these requirements, please log an iTAR requesting assistance with this
# patch and Support will make a determination about whether you should
# apply this patch.
#
#————————————————————————-
# Interim Patch for Base Bugs: 5638146
#————————————————————————-
#
# DATE: Wed Apr 18 22:32:51 2007
# ——————————-
# Platform Patch for : AIX5L Based Systems (64-bit)
# Product Version # : 10.2.0.2
# Product Patched : RDBMS
#
# Bugs Fixed by this patch:
# ————————-
# 5638146:ORA-600[KQLFFILLBINDDATA 1] ON INSERT INTO WRH$_SQLSTAT ON 10.2.0.2
#
# Patch Installation Instructions:
# ——————————–
# To apply the patch, unzip the PSE container file:
#
# p5638146_10202_AIX64-5L.zip
#
# Set your current directory to the directory where the patch
# is located:
#
# % cd 5638146
# On AIX platforms only for 10201 Patches :
#
# Ensure environment variable OBJECT_MODE is set to 32_64
# e.g.
#
# % setenv OBJECT_MODE 32_64
# or
# $ export OBJECT_MODE=32_64
#
# Ensure that the directory containing the opatch script appears in
# your $PATH; then enter the following command:
#
# % opatch apply
#
# Patch Special Instructions:
# —————————
# Make sure all instances running under the ORACLE_HOME being patched
# are cleanly shutdown before installing this patch. Also ensure that
# the tool used to terminate the instance(s) has exited cleanly.
#
# If the Oracle inventory is not setup correctly this utility will
# fail. To check accessibility to the inventory you can use the
# command
#
# % opatch lsinventory
#
# If you have any problems installing this PSE or are not sure
# about inventory setup please call Oracle support.
#
# Patch Deinstallation Instructions:
# ———————————-
# Use the following command:
#
# % cd 5638146
# % opatch rollback -id 5638146
#

———————————-
ora600_sapnote_0001033315
Bugs-5638146

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s