2011-07-20 20 views
3

我在oracle中有一個查詢,導致OLAP系統中的估計成本很高。估計的行數只有100K,但成本是一個巨大的數字。我想知道如何計算成本的數量,以及在哪種情況下會出現超高估計成本?「TABLE ACCESS BY LOCAL INDEX ROWID」估計成本高

執行計劃:

17 TABLE ACCESS BY LOCAL INDEX ROWID /BIC/FZ3PM_C01         
| (Estim. Costs = 1,299,922,942,955,190 , Estim. #Rows = 104,711)     
| Pstart: 1 Pstop: 471                
| Estim. CPU-Costs = 18,446,744,073,709,601,000 Estim. IO-Costs = 86,157,375,  
|                      
--- 16 BITMAP CONVERSION TO ROWIDS             
    |                     
    --- 15 BITMAP AND                
     |                    
     |-- 7 BITMAP MERGE               
     | |                   
     | --- 6 BITMAP KEY ITERATION            
     |  |                  
     |  |-- 4 BUFFER SORT             
     |  | |                 
     |  | ------3 TABLE ACCESS FULL /BIC/DZ3PM_C012       
     |  |   (Estim. Costs = 4 , Estim. #Rows = 180)     
     |  |   Estim. CPU-Costs = 1,093,126 Estim. IO-Costs = 4   
     |  |   Filter Predicates           
     |  |                  
     |  ------5 BITMAP INDEX RANGE SCAN /BIC/FZ3PM_C01~050      
     |    Pstart: 1 Pstop: 471           
     |    Search Columns: 1            
     |    Access Predicates            
     |                    
     --- 14 BITMAP MERGE               
      |                   
      --- 13 BITMAP KEY ITERATION            
       |                  
       |-- 11 BUFFER SORT             
       | |                 
       | --- 10 HASH JOIN             
       |  | (Estim. Costs = 2,492 , Estim. #Rows = 1,264,100)  
       |  | Estim. CPU-Costs = 801,483,146 Estim. IO-Costs = 2,407 
       |  | Access Predicates           
       |  |                
       |  |-----8 TABLE ACCESS FULL /BI0/XMATERIAL      
       |  |  (Estim. Costs = 1,470 , Estim. #Rows = 50,880)  
       |  |  Estim. CPU-Costs = 403,451,418 Estim. IO-Costs = 1,427 
       |  |  Filter Predicates          
       |  ------9 TABLE ACCESS FULL /BIC/DZ3PM_C011      
       |    (Estim. Costs = 1,007 , Estim. #Rows = 1,264,100) 
       |    Estim. CPU-Costs = 259,249,328 Estim. IO-Costs = 980 
       |                  
       ------12 BITMAP INDEX RANGE SCAN /BIC/FZ3PM_C01~040     
         Pstart: 1 Pstop: 471           
         Search Columns: 1            
         Access Predicates            
+0

'9 TABLE ACCESS FULL/BIC/DZ3PM_C011 | (估計費用= 1,007,估計#行數= 1,264,100)' –

回答

0

位圖索引的轉換是,你錯過了一個很好的指標,甲骨文決定建立一個新的臨時指數使用現有的索引飛的指示。這可能是相當繁重的操作,並且只要執行查詢就會丟失構建的位圖索引 - 因此在下次運行時不會重複使用。

您可以手動創建索引或向查詢中添加一些提示來阻止位圖轉換嗎? http://psoug.org/reference/hints.html - 提示的簡短列表。更多的Oracle文檔。

我開始使用100k行的子查詢,用no_merge提示保護它(Oracle將在內部創建臨時視圖)並在此之後放入其他連接。如果查詢優化器將繼續惹計劃 - 迫使更多的提示像指數或USE_NL等

3

100,000估計行是輸出。它可能需要做大量的工作來篩選大數據集,甚至更多地總結大數據集。這就是說,這些費用是相當天文(甚至與需要400多個分區的數據大小的數據庫)

嘗試做解釋計劃,然後一個SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY)

這提供了一個更可讀的計劃。您希望所有訪問和過濾謂詞都能看到它正在做什麼,並總結了成本。

0

非常高的成本可能是由系統統計數據不佳造成的。

select * from sys.aux_stats$;的結果與this page的說明進行比較。

我見過一些由11g錯誤引起的瘋狂估計 - 收集工作負載統計信息可能完全失敗,並將數字設置爲幾個數量級。