«СТОЛОВЫЙ ДОСТУП ПО МЕСТНОМУ ИНДЕКСУ ROWID» высокие сметные расходы

Question

У меня есть запрос в Oracle, который приводит к высокой оценочной стоимости в системе OLAP. оценочный номер строки составляет всего 100K, но стоимость огромна. Интересно, как рассчитывается количество затрат и в какой ситуации произойдет сверхвысокая оценочная стоимость?

План выполнения:

  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                                            

Answer 1

100 000 оценочных строк - это выходные данные.Может потребоваться проделать большую работу, чтобы отфильтровать большой набор данных до этого и еще больше, чтобы обобщить большой набор данных.Тем не менее, эти затраты довольно астрономические (даже с базой данных с размером данных, требующим 400+ разделов)

Попробуйте выполнить план объяснения, а затем выберите SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY)

Это обеспечивает гораздо более читаемый план.Вы хотите, чтобы все предикаты доступа и фильтра видели, что он делает, и затраты, когда они суммируются.

Answer 2

Очень высокие затраты могут быть вызваны плохой системной статистикой.

Сравните результаты с select * from sys.aux_stats$; с описаниями на этой странице .

Я видел некоторые сумасшедшие оценки, вызванные ошибкой в ​​11 г - сбор статистики рабочей нагрузки может полностью завершиться неудачей и установить значения, которые отклоняются на несколько порядков.

Answer 3

Ask Tom имеет полезную тему о сметной стоимости здесь:

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:40112614814595

Answer 4

Преобразование растрового индекса является признаком того, что вы пропустили хороший индекс, и Oracle решила создать новый временный индекс на лету, используя существующие индексы.Это может быть довольно трудоемкая операция, и встроенный индекс растрового изображения сбрасывается при выполнении запроса, поэтому повторное использование при следующем запуске не требуется.

Не могли бы вы создать индекс вручную или добавить несколько подсказок в запрос для блокировки преобразования растрового изображения?http://psoug.org/reference/hints.html - краткий список подсказок.Подробнее в документации Oracle.

Я начал с подзапроса для строк размером 100 тыс., Защитил его подсказкой no_merge (Oracle создаст временное представление внутри) и после этого разместил другие объединения.Если оптимизатор запросов продолжит связываться с планом - используйте дополнительные подсказки, такие как index или use_nl и т. Д.