Настройка объяснения плана SQL

Question

Простой SQL ниже вернул бы 1 запись и выполнялся довольно быстро.У него также есть хороший план объяснения (с использованием индекса P1, который является индексами первичного ключа).

Единственная проблема в том, что ему нужен огромный буфер, т.е. байты = 347 миллионов (ниже скопировано из плана).

6 TABLE ACCESS BY INDEX ROWID TABLE SIEBEL.S_ORG_EXT Cost: 2  Bytes: 347,432,257  Cardinality: 9,390,061  

Таблица S_ORG_EXT и S_OPTY имеет ОГРОМНЫЙ объем.Это то, что я не мог контролировать.Есть ли у вас какие-либо идеи, как оптимизировать план для использования меньшего размера буфера?

Заранее спасибо!

SQL:

SELECT A1.NAME
  FROM SIEBEL.S_ORG_EXT A1, SIEBEL.S_OPTY A3, SIEBEL.S_BU A4
 WHERE     A1.ROW_ID = A3.PR_DEPT_OU_ID                                    --4
       AND A3.ROW_ID = :V1                                                 --1
       AND A4.ROW_ID = A3.BU_ID                                            --2
       AND A3.PR_DEPT_OU_ID IS NOT NULL                                    --3

План

SELECT STATEMENT  ALL_ROWSCost: 5  Bytes: 77  Cardinality: 1                
    7 NESTED LOOPS  Cost: 5  Bytes: 77  Cardinality: 1              
        4 NESTED LOOPS  Cost: 3  Bytes: 40  Cardinality: 1          
            2 TABLE ACCESS BY INDEX ROWID TABLE SIEBEL.S_OPTY Cost: 3  Bytes: 31  Cardinality: 1    
                1 INDEX UNIQUE SCAN INDEX (UNIQUE) SIEBEL.S_OPTY_P1 Cost: 2  Cardinality: 1  
            3 INDEX UNIQUE SCAN INDEX (UNIQUE) SIEBEL.S_BU_P1 Cost: 0  Bytes: 1,485  Cardinality: 165   
        6 TABLE ACCESS BY INDEX ROWID TABLE SIEBEL.S_ORG_EXT Cost: 2  Bytes: 347,432,257  Cardinality: 9,390,061        
            5 INDEX UNIQUE SCAN INDEX (UNIQUE) SIEBEL.S_ORG_EXT_P1 Cost: 1  Cardinality: 1      

Answer 1

Вам не нужно оптимизировать план, так как вы уже знаете, что sql работает быстро, а количество байтов является оценкой количества байтов, возвращаемых источником строки. Вложенные циклы не являются наиболее эффективными для очень больших таблиц, сом в зависимости от размера других таблиц, к которым можно стремиться при объединении хешей с помощью подсказки use_hash или установки optimizer_index_caching (http://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams143.htm)