Home/ Questions/Q 7815381
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T05:30:18+00:00

This one has me stumped, so I thought I’d see if anyone else has

  • 0

This one has me stumped, so I thought I’d see if anyone else has ran into this issue and/or knows of a workaround.

I have the following SELECT statement:

SELECT * FROM TPM_VIEWSEARCH_EXPORT VS WHERE (PROJECTTYPEID IN (1))

This works fine, though it’s a pretty slow query that returns about 3,000 rows. However, I want to order the results. So I try:

SELECT * FROM TPM_VIEWSEARCH_EXPORT VS WHERE (PROJECTTYPEID IN (1)) ORDER BY PROJECTID, VERSIONID

When I do this, the query runs for about 25 seconds and then returns:

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

I can also move the ORDER BY clause into the view definition itself, and get the same error. The annoying thing is this repros only on our production server (which runs on Linux), and not on my development server which runs locally on Windows. However, it does repro 100% of the time.

The VIEW definition may or may not matter, but here it is anyway:

CREATE VIEW TPM_VIEWSEARCH_EXPORT AS
   SELECT
      V.PROJECTID, V.VERSIONID, V.NAME, V.STAGEID, V.REQUESTTYPE, V.PRIORITY, V.HEALTH, V.TRAININGDELIVERYSTART, V.TRAININGDELIVERYEND, V.MEASUREMENTINFO, V.DESCRIPTION, V.BUSINESSSPONSORLEVELINVOLVE,
      P.INITIATIVEID, P.LEADERSHIPONLY, P.BUSINESSLAUNCHDATE, P.EXPECTEDBUSINESSRESULTS, P.PROJECTTYPEID,
      T.SHORTNAME as ProjectType,
      I.NAME as InitiativeName, 
      C.NAME as TrainingCategory,
      S.NAME as StageName,
      PTO.FIRSTNAME as PTOFirst, PTO.LASTNAME as PTOLast,
      STO.FIRSTNAME as STOFirst, STO.LASTNAME as STOLast,
      LTS.FIRSTNAME as LTSFirst, LTS.LASTNAME as LTSLast,
      R.FIRSTNAME as ReqFirst, R.LASTNAME as ReqLast,
      BS.FIRSTNAME as BSFirst, BS.LASTNAME as BSLast,
      (select WM_CONCAT(FIRSTNAME || ' ' || LASTNAME) from TPM_PROJECTVERSIONSME inner join TPM_USER USING (USERID) where PROJECTID=V.PROJECTID and VERSIONID=V.VERSIONID) as SME,
      (select WM_CONCAT(NAME) from TPM_PROJECTAREAS inner join TPM_AREAS USING (AREAID) where PROJECTID=V.PROJECTID) as Areas,
      (select WM_CONCAT(NAME) from TPM_PROJECTWORKGROUPS inner join TPM_WORKGROUPS USING (WORKGROUPID) where PROJECTID=V.PROJECTID) as Workgroups,
      (select WM_CONCAT(NAME) from TPM_PROJECTVERSIONSYSTEMS inner join TPM_SYSTEMS USING (SYSTEMID) where PROJECTID=V.PROJECTID and VERSIONID=V.VERSIONID) as Systems,
      (select WM_CONCAT(NAME) from TPM_PROJECTVERSIONTEAMS inner join TPM_DEVELOPMENTTEAMS USING (TEAMID) where PROJECTID=V.PROJECTID and VERSIONID=V.VERSIONID) as SupportingDevTeams
   FROM TPM_PROJECTVERSION V
   INNER JOIN TPM_PROJECT P ON P.PROJECTID = V.PROJECTID
   INNER JOIN TPM_PROJECTTYPES T ON T.PROJECTTYPEID = P.PROJECTTYPEID
   INNER JOIN TPM_INITIATIVES I ON I.INITIATIVEID = P.INITIATIVEID
   INNER JOIN TPM_PROJECTSTAGE S ON S.STAGEID = V.STAGEID
   INNER JOIN TPM_PROJECTCATEGORIES PC ON (PC.PROJECTID=V.PROJECTID)
   INNER JOIN TPM_TRAININGCATEGORIES C ON (C.CATEGORYID=PC.CATEGORYID)
   INNER JOIN TPM_USER R ON (V.REQUESTOR=R.USERID)
   INNER JOIN TPM_USER BS ON (V.BUSINESSSPONSOR=BS.USERID)
   LEFT JOIN TPM_USER PTO ON PTO.USERID = V.PRIMARYTRAININGOWNER
   LEFT JOIN TPM_USER STO ON (V.SECONDARYTRAININGOWNER=STO.USERID)
   LEFT JOIN TPM_USER LTS ON (V.LEADTRAININGSPONSOR=LTS.USERID)

The DBAs that run the production server claim this is a known Oracle bug, however no patch is available. Is this truly an Oracle bug, or does this issue have something to do with the view definition or the data in the database.

UPDATE:

Oracle version (Dev machine, which works):

Oracle Database 11g Express Edition Release 11.2.0.2.0 - Beta
PL/SQL Release 11.2.0.2.0 - Beta
CORE    11.2.0.2.0  Production
TNS for 32-bit Windows: Version 11.2.0.2.0 - Beta
NLSRTL Version 11.2.0.2.0 - Production

Oracle version (Production):

TNS for Solaris: Version 11.2.0.2.0 - Production
PL/SQL Release 11.2.0.2.0 - Production
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
NLSRTL Version 11.2.0.2.0 - Production
CORE    11.2.0.2.0  Production
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The solution, which was recommended by Justin Cave in a comment, was to switch to the LISTAGG function instead of WM_CONCAT. This method not only avoids the crash, but also increases the speed of the query from about 46 minutes to around 30 seconds. The updated code is:

      (select LISTAGG(LASTNAME || ', ' || FIRSTNAME, '; ') WITHIN GROUP (ORDER BY LASTNAME, FIRSTNAME) from TPM_PROJECTVERSIONSME inner join TPM_USER USING (USERID) where PROJECTID=V.PROJECTID and VERSIONID=V.VERSIONID) as SME,
  (select LISTAGG(NAME, '; ') WITHIN GROUP (ORDER BY NAME) from TPM_PROJECTAREAS inner join TPM_AREAS USING (AREAID) where PROJECTID=V.PROJECTID) as Areas,
  (select LISTAGG(NAME, '; ') WITHIN GROUP (ORDER BY NAME) from TPM_PROJECTWORKGROUPS inner join TPM_WORKGROUPS USING (WORKGROUPID) where PROJECTID=V.PROJECTID) as Workgroups,
  (select LISTAGG(NAME, '; ') WITHIN GROUP (ORDER BY NAME) from TPM_PROJECTVERSIONSYSTEMS inner join TPM_SYSTEMS USING (SYSTEMID) where PROJECTID=V.PROJECTID and VERSIONID=V.VERSIONID) as Systems,
  (select LISTAGG(NAME, '; ') WITHIN GROUP (ORDER BY NAME) from TPM_PROJECTVERSIONTEAMS inner join TPM_DEVELOPMENTTEAMS USING (TEAMID) where PROJECTID=V.PROJECTID and VERSIONID=V.VERSIONID) as SupportingDevTeams
    • 0