[11gR2] Hash Unique : explosion du Cost

Hash Unique : explosion du Cost

Bonjour,

Je travaille actuellement avec OBIEE et j'essaye d'améliorer les temps d'execution de certaines requêtes en jouant sur les paramètres de la base de données et indexes (étant donné que les requêtes sont générées automatiquement, je n'ai aucun moyen de les modifier). En me penchant sur l'explain plan d'une requête, je suis tombé sur ce qui suit:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                    | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------------------------------
|  86 |            HASH UNIQUE                       |                       | 12645 |  1580K|  8194M|   637K  (1)| 02:07:26 |
|* 87 |             HASH JOIN                        |                       |    62M|  7682M|       |  1460  (26)| 00:00:18 |
|  88 |              VIEW                            | index$_join$_015      | 15633 |   305K|       |    31   (4)| 00:00:01 |
|* 89 |               HASH JOIN                      |                       |       |       |       |            |          |
|  90 |                BITMAP CONVERSION TO ROWIDS   |                       | 15633 |   305K|       |     4   (0)| 00:00:01 |
|  91 |                 BITMAP INDEX FULL SCAN       | BMI_M_PARENT_DESC     |       |       |       |            |          |
|  92 |                INDEX FAST FULL SCAN          | M_CUSTOMER_PARENT_IDX | 15633 |   305K|       |    33   (0)| 00:00:01 |
|* 93 |              HASH JOIN                       |                       | 28642 |  3020K|       |  1054   (1)| 00:00:13 |
|* 94 |               VIEW                           | index$_join$_013      |  6943 |   189K|       |     8  (13)| 00:00:01 |
|* 95 |                HASH JOIN                     |                       |       |       |       |            |          |
|  96 |                 INLIST ITERATOR              |                       |       |       |       |            |          |
|  97 |                  BITMAP CONVERSION TO ROWIDS |                       |  6943 |   189K|       |     3   (0)| 00:00:01 |
|* 98 |                   BITMAP INDEX SINGLE VALUE  | BMI_M_GEOGRAPHY_SITE  |       |       |       |            |          |
|  99 |                 INDEX FAST FULL SCAN         | IDX_M_GEOGRAPHY_SITE  |  6943 |   189K|       |     5   (0)| 00:00:01 |
| 100 |               NESTED LOOPS                   |                       | 28642 |  2237K|       |  1046   (1)| 00:00:13 |
| 101 |                MERGE JOIN CARTESIAN          |                       |     7 |   189 |       |     2   (0)| 00:00:01 |
|*102 |                 INDEX RANGE SCAN             | IDX$$_19C610005       |     1 |     4 |       |     1   (0)| 00:00:01 |
| 103 |                 BUFFER SORT                  |                       |     7 |   161 |       |     1   (0)| 00:00:01 |
| 104 |                  TABLE ACCESS BY INDEX ROWID | M_SECTOR              |     7 |   161 |       |     1   (0)| 00:00:01 |
|*105 |                   INDEX RANGE SCAN           | IDX$$_19C610006       |     7 |       |       |     1   (0)| 00:00:01 |
| 106 |                INLIST ITERATOR               |                       |       |       |       |            |          |
|*107 |                 INDEX RANGE SCAN             | AA_BBB_FACTS_GMS_IDX  |  4092 |   211K|       |   149   (0)| 00:00:02 |
------------------------------------------------------------------------------------------------------------------------------

Je sais que j'ai tronqué mais c'est pour voir dans un premier temps si ça vaut la peine de creuser plus loin le saut du cost avec le hash unique. ( requête SQL de 240 lignes et Explain Plan du même gabarit) Est ce que cela vient du nombre de lignes dans le Hash Join?

Je reste à votre disposition si vous souhaitez plus d'informations.

Merci d'avance pour le temps accordé à mon cas :)

En 11gR2, si vous avez l'option tuning pack, vous pouvez utiliser SQL monitor pour voir où est effectivement passé le temps dans votre requête, si vous ne l'avez (l'option) pas il faut se résoudre à la tracer (la requête).

La colonne cost n'est qu'une statistique elle même basée sur les statistiques des objets de votre base (tables, index ...) et sur votre paramétrage (optimizer_index_cost_adj, db_file_multiblock_read_count, nls_sort ...) elle ne reflète pas une réalité intrinsèque mais le calcul effectué par le CBO sur les informations dont il dispose.

D'accord, donc ça ne reste qu'un cout hypothétique. Je vais lancer le tout avec le profiler alors et on va voir si le soucis vient du même endroit.

Merci