有應用人員反映某套Linux上的11.2.0.1數據庫系統中出現了UNION ALL后返回的結果集不正確的問題,我們具體分析下出現問題的其中一條語句: SELECT MTL_SECONDARY_INVENTORIES.SECONDARY_INVENTORY_NAME,MTL_SECONDARY_INVENTORIES.ORGANIZATION_ID,MTL_SECONDARY_INVENTORIES.DESCRIPTION,MTL_SECONDARY_INVENTORIES.AVAILABILITY_TYPE,MTL_SECONDARY_INVENTORIES.MATERIAL_ACCOUNT,MTL_SECONDARY_INVENTORIES.MATERIAL_OVERHEAD_ACCOUNT,MTL_SECONDARY_INVENTORIES.RESOURCE_ACCOUNT,MTL_SECONDARY_INVENTORIES.OVERHEAD_ACCOUNT,MTL_SECONDARY_INVENTORIES.OUTSIDE_PROCESSING_ACCOUNT,MTL_SECONDARY_INVENTORIES.ASSET_INVENTORY,MTL_SECONDARY_INVENTORIES.EXPENSE_ACCOUNT,MTL_SECONDARY_INVENTORIES.ENCUMBRANCE_ACCOUNT,MTL_SECONDARY_INVENTORIES.ATTRIBUTE3,MTL_SECONDARY_INVENTORIES.ATTRIBUTE5,WORKFLOW_START_TIMES.WORKFLOW_START_TIMEFROM REPEMEAERP.MTL_SECONDARY_INVENTORIES,REPEMEAERP.WORKFLOW_START_TIMESWHERE MTL_SECONDARY_INVENTORIES.DW_UPDATE_DT >TO_DATE('01/01/1900 00:00:00', 'MM/DD/YYYY HH24:MI:SS')AND MTL_SECONDARY_INVENTORIES.DW_UPDATE_DT <=WORKFLOW_START_TIMES.WORKFLOW_START_TIMEAND WORKFLOW_START_TIMES.WORKFLOW_NAME =LTRIM(RTRIM('w_int_FreqBatch_EMEA')) /*以上是QUERY A*/ UNION ALL /*以下是QUERY B*/ SELECT DISTINCT 'WORKORDERS',MTL_SECONDARY_INVENTORIES.ORGANIZATION_ID,'WORK ORDERS WITH WIP AS CATEGORY VALUE',1,0,0,0,0,0,1,0,0,'MOI','0',WORKFLOW_START_TIMES.WORKFLOW_START_TIMEFROM REPEMEAERP.MTL_SECONDARY_INVENTORIES, EIMMAINT.WORKFLOW_START_TIMESWHERE MTL_SECONDARY_INVENTORIES.DW_UPDATE_DT >TO_DATE('01/01/1900 00:00:00', 'MM/DD/YYYY HH24:MI:SS')AND MTL_SECONDARY_INVENTORIES.DW_UPDATE_DT <=WORKFLOW_START_TIMES.WORKFLOW_START_TIMEAND WORKFLOW_START_TIMES.WORKFLOW_NAME =LTRIM(RTRIM('w_int_FreqBatch_EMEA')) / 138 rows selected. 以上查詢語句中，QUERY A部分(也就是UNION ALL之前的SELECT語句)單獨查詢時返回返回69條記錄，QUERY B部分單獨查詢時返回15記錄，UNION ALL后返回的結果卻是138條記錄，而非84條記錄。實際上這套系統也是最近才從10g遷移到11gr2上，之前在10g中同樣的應用沒有出過類似的問題，可以猜測是11g中新引入的某種特性存在可能引發wrong result的Bug。 具體思路雖然有了，但仍無法確定問題的關鍵所在；我們來看看該SQL的執行計劃: ----------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 2443 | 52 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 7 | 2443 | 52 (0)| 00:00:01 | |* 2 | TABLE ACCESS FULL | WORKFLOW_START_TIMES | 1 | 29 | 48 (0)| 00:00:01 | | 3 | VIEW | VW_JF_SET$9BAED2EA | 1 | 320 | 4 (0)| 00:00:01 | | 4 | UNION ALL PUSHED PREDICATE | | | | | | |* 5 | FILTER | | | | | | | 6 | TABLE ACCESS BY INDEX ROWID| MTL_SECONDARY_INVENTORIES | 3 | 336 | 2 (0)| 00:00:01 | |* 7 | INDEX RANGE SCAN | IDX_MTL_SECONDARY_INVENTORIES | 1 | | 1 (0)| 00:00:01 | |* 8 | FILTER | | | | | | | 9 | TABLE ACCESS BY INDEX ROWID| MTL_SECONDARY_INVENTORIES | 3 | 36 | 2 (0)| 00:00:01 | |* 10 | INDEX RANGE SCAN | IDX_MTL_SECONDARY_INVENTORIES | 1 | | 1 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): ---------------------------------------------------2 - filter("WORKFLOW_START_TIMES"."WORKFLOW_NAME"='w_int_FreqBatch_EMEA') 5 - filter(TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')<"WORKFLOW_START_TIMES"."WORKFLOW_START_TIME") 7 - access("MTL_SECONDARY_INVENTORIES"."DW_UPDATE_DT">TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "MTL_SECONDARY_INVENTORIES"."DW_UPDATE_DT"<="WORKFLOW_START_TIMES"."WORKFLOW_START_TIME" ) 8 - filter(TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')<"WORKFLOW_START_TIMES"."WORKFLOW_START_TIME") 10 - access("MTL_SECONDARY_INVENTORIES"."DW_UPDATE_DT">TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "MTL_SECONDARY_INVENTORIES"."DW_UPDATE_DT"<="WORKFLOW_START_TIMES"."WORKFLOW_START_TIME" ) 你可能從以上執行計劃中發現了兩處十分陌生的字眼:UNION ALL? PUSHED PREDICATE和VW_JF_SET$。它們是什么！？ 先來說說JF,JF是join factorization的縮寫，你可以把它翻譯作鏈接因式分解，如果你學過離散數學或者數據庫原理的話，那么這種在11.2.0.1中最新推出的基于成本的變換操作對你來說并不陌生。用公式的樣式來表達大概是下面這樣: YYA,YYB和YYC是3個關聯的數據對象亦或者是3個關聯的結果集; (YYA JOIN YYB) UNION [ALL] (YYA JOIN YYC) 可以轉換成為: YYA JOIN (YYB UNION [ALL] YYC) 這樣做YYA部分只需要讀取一次，還可以少做一次JOIN,聽上去是挺不錯的吧！ 下面我們來看一個Oracle使用join factorization的十分簡單的實例: SQL> select * from v$version;BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for Linux: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - ProductionSQL> drop table yya;drop table yya*ERROR at line 1:ORA-00942: table or view does not existSQL> drop table yyb;drop table yyb*ERROR at line 1:ORA-00942: table or view does not existSQL> create table yya as select rownum id1,rownum id2,rownum id3 from dual connect by level<=20000; Table created. SQL> create table yyb as select rownum id1,rownum id2,rownum id3 from dual connect by level<=20000; Table created.SQL> explain plan for 2 select * from yya ,yyb where yya.id1=yyb.id1 3 union all 4 select * from yya, yyb where yya.id1=yyb.id1;Explained.SQL> set linesize 100 pagesize 1400;SQL> select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------- Plan hash value: 744914999------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 40000 | 2500K| 49 (3)| 00:00:01 | |* 1 | HASH JOIN | | 40000 | 2500K| 49 (3)| 00:00:01 | | 2 | TABLE ACCESS FULL | YYA | 20000 | 234K| 16 (0)| 00:00:01 | | 3 | VIEW | VW_JF_SET$6E3F6682 | 40000 | 2031K| 32 (0)| 00:00:01 | | 4 | UNION-ALL | | | | | | | 5 | TABLE ACCESS FULL| YYB | 20000 | 761K| 16 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL| YYB | 20000 | 761K| 16 (0)| 00:00:01 | -------------------------------------------------------------------------------------------Predicate Information (identified by operation id): ---------------------------------------------------1 - access("YYA"."ID1"="ITEM_1")/*執行計劃中出現了VW_JF_SET$F22B2A93,Oracle選擇了使用join factorization，該執行計劃總成本49*/SQL> alter session set "_optimizer_join_factorization"=false;Session altered./*隱藏參數_optimizer_join_factorization決定了優化器是否可以選用join factorization,現在我們禁用它*/ SQL> explain plan for2 select * from yya join yyb on yya.id1=yyb.id13 union all4 select * from yya join yyb on yya.id1=yyb.id1;Explained.SQL> select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------- Plan hash value: 3439541885---------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 40000 | 1992K| 66 (52)| 00:00:01 | | 1 | UNION-ALL | | | | | | |* 2 | HASH JOIN | | 20000 | 996K| 33 (4)| 00:00:01 | | 3 | TABLE ACCESS FULL| YYA | 20000 | 234K| 16 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| YYB | 20000 | 761K| 16 (0)| 00:00:01 | |* 5 | HASH JOIN | | 20000 | 996K| 33 (4)| 00:00:01 | | 6 | TABLE ACCESS FULL| YYA | 20000 | 234K| 16 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL| YYB | 20000 | 761K| 16 (0)| 00:00:01 | ----------------------------------------------------------------------------Predicate Information (identified by operation id): ---------------------------------------------------2 - access("YYA"."ID1"="YYB"."ID1")5 - access("YYA"."ID1"="YYB"."ID1") /*禁用鏈接因式分解后，Oracle使用了常規的"笨辦法"，成本上升到66*//*有趣的是下面的測試*/SQL> alter session set "_optimizer_join_factorization"=true;Session altered.SQL> create table yyc as select * from yyb;Table created.SQL> explain plan for2 select * from yya,yyc where yya.id1=yyc.id13 union all4 select * from yya,yyb where yya.id1=yyb.id1;Explained.SQL> select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------- Plan hash value: 4240055274---------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 40000 | 1992K| 66 (52)| 00:00:01 | | 1 | UNION-ALL | | | | | | |* 2 | HASH JOIN | | 20000 | 996K| 33 (4)| 00:00:01 | | 3 | TABLE ACCESS FULL| YYA | 20000 | 234K| 16 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| YYC | 20000 | 761K| 16 (0)| 00:00:01 | |* 5 | HASH JOIN | | 20000 | 996K| 33 (4)| 00:00:01 | | 6 | TABLE ACCESS FULL| YYA | 20000 | 234K| 16 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL| YYB | 20000 | 761K| 16 (0)| 00:00:01 | ----------------------------------------------------------------------------Predicate Information (identified by operation id): ---------------------------------------------------2 - access("YYA"."ID1"="YYC"."ID1")5 - access("YYA"."ID1"="YYB"."ID1") /*confused，Oracle有什么理由在這里反而不用join factorization了呢?看起來短期內join factorization的實際應用還有待"商榷" *//*10053事件能解釋這一問題嗎?*/ SQL> alter system flush shared_pool;System altered.SQL> oradebug setmypid; Statement processed. SQL> oradebug event 10053 trace name context forever,level 1; Statement processed. SQL> explain plan for2 select * from yya join yyb on yya.id1=yyb.id13 union all4 select * from yya join yyc on yya.id1=yyc.id1;Explained.SQL> oradebug event 10053 trace name context off; Statement processed. SQL> oradebug tracefile_name; /home/maclean/app/maclean/diag/rdbms/prod/PROD/trace/PROD_ora_7907.trcview /home/maclean/app/maclean/diag/rdbms/prod/PROD/trace/PROD_ora_7907.trc *********************************** Cost-Based Join Factorization *********************************** Join-Factorization on query block SET$1 (#1) JF: Using search type: exhaustive JF: Generate basic transformation units Validating JF unit: (branch: {2, 3} table: {YYA, YYA})rejected: join predicates do not matchJF: Generate transformation units from basic units JF: No state generated. /*優化器認為其鏈接謂詞不符合使用join factorization的條件，JF題案被駁回，"懸案"!*/ join factorization是很棒的新技術，這點沒錯，但新技術往往又是horrible(可怕的)，最近我常用這個詞。我們的問題是不是這個新來的引起的呢?通過join factorization關鍵字檢索MOS，可以發現一個今年(2010)3月出現的Bug 9504322,quote: Hdr: 9504322 11.2.0.1 RDBMS 11.2.0.1 QRY OPTIMIZER PRODID-5 PORTID-226 Abstract: WRONG RESULTS WITH UNION_ALL AND INLINE VIEWS *** 03/24/10 05:38 am *** PROBLEM: -------- Wrong results on 11.2 for queries of type: SELECT * FROM ( SELECT ... FROM view, table WHERE ... UNION ALL SELECT ... FROM view, table WHERE NOT ... ); DIAGNOSTIC ANALYSIS: -------------------- Problem seen between 10.2.0.4 and 11.2.0.1. If we remove the use of inline view the correct results are returned. WORKAROUND: ----------- N/A RELATED BUGS: ------------- REPRODUCIBILITY: ---------------- It is reproducing on generic 11.2.0.1 呵呵，似乎有點眉目了，不過實踐是檢驗真理的唯一標準: SQL> alter session set "_optimizer_join_factorization"=true;Session altered.SELECT MTL_SECONDARY_INVENTORIES.SECONDARY_INVENTORY_NAME,MTL_SECONDARY_INVENTORIES.ORGANIZATION_ID,MTL_SECONDARY_INVENTORIES.DESCRIPTION,MTL_SECONDARY_INVENTORIES.AVAILABILITY_TYPE,MTL_SECONDARY_INVENTORIES.MATERIAL_ACCOUNT,MTL_SECONDARY_INVENTORIES.MATERIAL_OVERHEAD_ACCOUNT,MTL_SECONDARY_INVENTORIES.RESOURCE_ACCOUNT,MTL_SECONDARY_INVENTORIES.OVERHEAD_ACCOUNT,MTL_SECONDARY_INVENTORIES.OUTSIDE_PROCESSING_ACCOUNT,MTL_SECONDARY_INVENTORIES.ASSET_INVENTORY,MTL_SECONDARY_INVENTORIES.EXPENSE_ACCOUNT,MTL_SECONDARY_INVENTORIES.ENCUMBRANCE_ACCOUNT,MTL_SECONDARY_INVENTORIES.ATTRIBUTE3,MTL_SECONDARY_INVENTORIES.ATTRIBUTE5,WORKFLOW_START_TIMES.WORKFLOW_START_TIMEFROM REPEMEAERP.MTL_SECONDARY_INVENTORIES,REPEMEAERP.WORKFLOW_START_TIMESWHERE MTL_SECONDARY_INVENTORIES.DW_UPDATE_DT >TO_DATE('01/01/1900 00:00:00', 'MM/DD/YYYY HH24:MI:SS')AND MTL_SECONDARY_INVENTORIES.DW_UPDATE_DT <=WORKFLOW_START_TIMES.WORKFLOW_START_TIMEAND WORKFLOW_START_TIMES.WORKFLOW_NAME =LTRIM(RTRIM('w_int_FreqBatch_EMEA')) /*以上是QUERY A*/ UNION ALL /*以下是QUERY B*/ SELECT DISTINCT 'WORKORDERS',MTL_SECONDARY_INVENTORIES.ORGANIZATION_ID,'WORK ORDERS WITH WIP AS CATEGORY VALUE',1,0,0,0,0,0,1,0,0,'MOI','0',WORKFLOW_START_TIMES.WORKFLOW_START_TIMEFROM REPEMEAERP.MTL_SECONDARY_INVENTORIES, EIMMAINT.WORKFLOW_START_TIMESWHERE MTL_SECONDARY_INVENTORIES.DW_UPDATE_DT >TO_DATE('01/01/1900 00:00:00', 'MM/DD/YYYY HH24:MI:SS')AND MTL_SECONDARY_INVENTORIES.DW_UPDATE_DT <=WORKFLOW_START_TIMES.WORKFLOW_START_TIMEAND WORKFLOW_START_TIMES.WORKFLOW_NAME =LTRIM(RTRIM('w_int_FreqBatch_EMEA')) /138 rows selected. 結果和我們猜想的大相徑庭，join factorization并非罪魁，找不到終點讓我們回到原點。 至此UNION ALL PUSHED PREDICATE有了極大的嫌疑，什么是PUSH PREDICATE？我把它叫做謂詞前推，這玩樣最早出現在10g上，但一直問題多多！它到底是何種OPERATION呢？讓我們來看看下面的例子: SQL> select * from v$version;BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for Linux: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - ProductionSQL> create table youyus (t1 int,t2 varchar2(20));Table created.SQL> alter table youyus add primary key(t1);Table altered.SQL> explain plan for2 select *3 from youyus4 union all5 select * from youyus;Explained. /*在之后的語句中將用到這個子查詢*/ SQL> select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------- Plan hash value: 1959159425----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 50 | 4 (50)| 00:00:01 | | 1 | UNION-ALL | | | | | | | 2 | TABLE ACCESS FULL| YOUYUS | 1 | 25 | 2 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| YOUYUS | 1 | 25 | 2 (0)| 00:00:01 | ----------------------------------------------------------------------------- /*在之后的語句中將用到這個子查詢,這里它的"原始"執行計劃十分簡單*/SQL> explain plan for2 select v2.t1, v2.t23 from (select t1 from youyus where rownum=1) v1,4 (select *5 from youyus6 union all7 select * from youyus) v28 where v1.t1 = v2.t1;Explained.SQL> select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------- Plan hash value: 2456530141----------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 27 | 1 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 1 | 27 | 1 (0)| 00:00:01 | | 2 | VIEW | | 1 | 13 | 1 (0)| 00:00:01 | |* 3 | COUNT STOPKEY | | | | | | | 4 | INDEX FULL SCAN | SYS_C0010819 | 1 | 13 | 1 (0)| 00:00:01 | | 5 | VIEW | | 1 | 14 | 0 (0)| 00:00:01 | | 6 | UNION ALL PUSHED PREDICATE | | | | | | | 7 | TABLE ACCESS BY INDEX ROWID| YOUYUS | 1 | 25 | 0 (0)| 00:00:01 | |* 8 | INDEX UNIQUE SCAN | SYS_C0010819 | 1 | | 0 (0)| 00:00:01 | | 9 | TABLE ACCESS BY INDEX ROWID| YOUYUS | 1 | 25 | 0 (0)| 00:00:01 | |* 10 | INDEX UNIQUE SCAN | SYS_C0010819 | 1 | | 0 (0)| 00:00:01 | -----------------------------------------------------------------------------------------------Predicate Information (identified by operation id): ---------------------------------------------------3 - filter(ROWNUM=1)8 - access("YOUYUS"."T1"="V1"."T1")10 - access("YOUYUS"."T1"="V1"."T1") /* PUSHED PREDICATE將謂詞邏輯前推到UNION ALL的子查詢中，其優勢在于可以避免全表掃描，利用索引*/SQL> set linesize 100 pagesize 1400; SQL> SQL> explain plan for2 select /*+ no_push_pred(v2) */ v2.t1, v2.t23 from (select t1 from youyus where rownum=1) v1,4 (select *5 from youyus6 union all7 select * from youyus) v28 where v1.t1 = v2.t1;Explained.SQL> select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------- Plan hash value: 2769827061------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 38 | 6 (17)| 00:00:01 | |* 1 | HASH JOIN | | 1 | 38 | 6 (17)| 00:00:01 | | 2 | VIEW | | 1 | 13 | 1 (0)| 00:00:01 | |* 3 | COUNT STOPKEY | | | | | | | 4 | INDEX FULL SCAN | SYS_C0010819 | 1 | 13 | 1 (0)| 00:00:01 | | 5 | VIEW | | 2 | 50 | 4 (0)| 00:00:01 | | 6 | UNION-ALL | | | | | | | 7 | TABLE ACCESS FULL| YOUYUS | 1 | 25 | 2 (0)| 00:00:01 | | 8 | TABLE ACCESS FULL| YOUYUS | 1 | 25 | 2 (0)| 00:00:01 | -------------------------------------------------------------------------------------Predicate Information (identified by operation id): ---------------------------------------------------1 - access("V1"."T1"="V2"."T1")3 - filter(ROWNUM=1) /*no_push_pred hint讓Oracle 放棄使用PUSHED PREDICATE，使用常規UNION-ALL操作后，子查詢執行計劃回歸成全表掃描，整個計劃成本上升*/

轉載于:https://www.cnblogs.com/macleanoracle/archive/2010/08/06/2967489.html

總結

以上是生活随笔為你收集整理的UNION ALL returning wrong results?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。