2012-03-16 63 views
2

這個問題讓我難以理解,所以我想我會看看是否有其他人遇到過這個問題和/或知道解決方法。使用ORDER BY子句查看視圖時出現內部Oracle錯誤

我有以下SELECT聲明:

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

這工作得很好,雖然這是一個返回約3000行一個相當緩慢的查詢。但是,我想訂購結果。所以我嘗試:

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

當我這樣做,查詢約25秒運行,然後返回:

ORA-00600:內部錯誤代碼,參數:[kokegPinLob1],[], [], [],[],[],[],[],[],[],[],[]

我還可以移動至ORDER BY子句到視圖定義本身,和得到相同的錯誤。令人討厭的是這個repros只在我們的生產服務器上運行(在Linux上運行),而不是在Windows上本地運行的開發服務器上。但是,它可以在100%的時間內重現。

視圖定義可能會或可能沒有關係,但在這裏它是無論如何:

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) 

運行生產服務器要求這是一個已知的bug的Oracle數據庫管理員,但是沒有補丁可用。這是真正的Oracle錯誤,還是這個問題與視圖定義或數據庫中的數據有關?

UPDATE:

Oracle版本(開發機,它的工作原理):

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版本(生產):

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 
+2

查詢計劃在這兩種環境中是否相同?你知道DBA認爲哪個錯誤會導致錯誤嗎?如果不通過Metalink並查看生成的跟蹤文件,我的猜測是問題至少部分與使用未記錄的WM_CONCAT函數有關。你能否使用不同的技術來進行字符串聚合?如果你使用11.2,你可以使用'LISTAGG'函數嗎? – 2012-03-16 19:42:26

+0

@JustinCave - 我在帖子中添加了兩個版本。我*似乎*有兩個LISTAGG,但不能找出正確的語法,以使其與查詢工作.. – 2012-03-16 20:28:32

+1

@JustinCave - 認真如果你曾經在西雅圖地區,我欠你一杯。切換到LISTAGG不僅可以修復該錯誤,還可以將查詢速度從46分鐘加速到30秒左右!神聖的廢話.. – 2012-03-16 20:41:32

回答

2

的解決方案,這是在評論建議賈斯汀洞,是切換到LISTAGG函數代替WM_CONCAT。這種方法不僅可以避免崩潰,還可以將查詢速度從大約46分鐘提高到大約30秒。更新的代碼是:

(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

這是一般的內部錯誤號碼Oracle程序例外。它表明一個過程遇到了一個低級的,意想不到的情況。此消息的原因包括:

超時

文件損壞

在內存故障的數據檢查

硬件,內存或I/O錯誤

正確還原文件

第一個參數是內部消息編號。其他參數是各種數字,名稱和字符串。這些數字可能會改變不同版本的Oracle之間的含義。

操作:將此錯誤報告給Oracle客戶支持人員收集以下信息之後:

+0

謝謝!我們已經向Oracle提交了一份服務請求,因此他們可能會有興趣查看。從那個列表中,我會說超時將是最好的猜測,因爲它是一個如此龐大的查詢。 – 2012-03-16 19:44:18

相關問題