Discussion :

[tropiko]

Dans quel chacun de ces précieux hint est recommandé ?

La combinaison FULL + USE_HASH est elle la plus puissante dans la majorité des cas ?

Merci les hinteurs pour les directives
merci

[mnitu]

Parfois NL est plus performant, parfois c’est Merge Join parfois c’est Hash Join. N’utilisez pas des hints que pour tester. De toute façon si vous ne comprenez pas les différences entre ces méthodes des jointures utiliser ces Hints ne vous apporte rien.

[FSiebert]

C'est évidemment parce qu'une méthode est meilleure que les autres qu'Oracle a mis au point un optimiseur très complexe pour déterminer la méthode à utiliser

[tropiko]

oui mais dans quel cas utiliser l'une ou l'autre pour optimiser une requête ?MERGE si predicat de type > ou < ?
Hash si équi-jointure ? càd = ?

[FSiebert]

Comme déjà dit, il n'y a pas de règle, ça dépend de plein de paramètres.
L'utilisation des hints n'est pas conseillé si vous ne maîtrisez pas le sujet, et, sans vouloir vous vexez, ça ne semble pas être le cas.

Il y a de grandes chances que l'optimiseur Oracle arrive à un meilleur résultat que vous (avec des statistiques à jour) ; et si problème de performance il y a, cherchez plutôt à optimiser votre requête qu'à influencer son plan d'exécution.
Si vous avez besoin de conseils plus approfondis sur un point précis, postez votre requête et son plan d'exécution.

[pachot]

Bonjour,

A noter que utiliser FULL et/ou USE_HASH sans LEADING et éventuellement SWAP_JOIN_INPUTS n'a souvent aucun sens. Car forcer un Hash Join sans dire dans quel sens on fait la jointure est plutôt aléatoire !

La bonne optimisation, c'est de fournir les bonnes stats à l'optimiseur et alors il choisira la bonne méthode. Ce n'est pas une question d'equi-join ou semi-join mais une question de nombre de lignes.

Cordialement,
Franck.

[tropiko]

Bonjour ,

Mon plan d’exécution 11g a changé par rapport à la 10g.

Un MERGE JOIN CARTESIEN est apparu et la requête a subi une régression.
Il s’agit SELECT avec jointure entre table T1,T2 et T3.

La table T2 lie les 2 tablesT1 et T3 mais Oracle commence par faire un MERGE JOIN CARTESIEN entre T1 et T3 !

La solution était de forcer l’ordre de jointure
SELECT /*+ ORDERED */ …
FROM T1,T2,T3
…
Et je retrouve en fin mon plan 10g (sans MERGE JOIN CARTESIEN).
Votre avis ? Puis-je faire autrement ?

[mnitu]

Oui, virez d’abord le hint de la requête. Assurez-vous que les statistiques sont correctement calculées. Investiguez pour comprendre la raison du changement du plan. Fournissez un jeu d’essai pour se faire aider.

[pachot]

Bonjour,

Un MERGE JOIN CARTESIEN est apparu et la requête a subi une régression

le Merge Join Cartesien est choisi lorsque les 2 tables on très peu de lignes. Il faudrait vérifier si c'est le cas, et sinon voir pourquoi l'estimation est mauvaise.
Cordialement,
Franck.

[mnitu]

Pas forcement.
C’est plutôt de disposer des sources des données déjà triées ou facile à trier. Et pour les non-equi joins comme le hash join ne fonctionne pas ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
28
29
30
31
32
33
34
35
36
37
38
39
 
Connecté à :
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
SQL> set linesize 132
SQL> show parameter optimizer
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      10.2.0.4
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      all_rows
optimizer_secure_view_merging        boolean     TRUE
SQL> set autotrace traceonly explain
SQL> select *
  2    from big a
  3         Join
  4         big b
  5      On a.id = b.id
  6   Order By a.Id
  7  /
 
Plan d'exécution
----------------------------------------------------------
Plan hash value: 2325133430
 
-----------------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |  1606K|   278M|       | 62162   (1)| 00:12:26 |
|   1 |  MERGE JOIN                  |        |  1606K|   278M|       | 62162   (1)| 00:12:26 |
|   2 |   TABLE ACCESS BY INDEX ROWID| BIG    |  1588K|   137M|       | 24042   (1)| 00:04:49 |
|   3 |    INDEX FULL SCAN           | PK_BIG |  1588K|       |       |  3422   (1)| 00:00:42 |
|*  4 |   SORT JOIN                  |        |  1588K|   137M|   381M| 38120   (1)| 00:07:38 |
|   5 |    TABLE ACCESS FULL         | BIG    |  1588K|   137M|       |  4674   (2)| 00:00:57 |
-----------------------------------------------------------------------------------------------

[pachot]

Bonjour,

C’est plutôt de disposer des sources des données déjà triées ou facile à trier.

Non, je ne parlais pas du 'sort-merge join' mais du 'merge join cartesian' dont parlais tropiko.

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
------------------------------------------------------------------------------------------------------------------
| Id  | Operation            | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |      |      1 |        |      2 |00:00:00.01 |       7 |       |       |          |
|   1 |  MERGE JOIN CARTESIAN|      |      1 |      2 |      2 |00:00:00.01 |       7 |       |       |          |
|   2 |   TABLE ACCESS FULL  | T2   |      1 |      2 |      2 |00:00:00.01 |       4 |       |       |          |
|   3 |   BUFFER SORT        |      |      2 |      1 |      2 |00:00:00.01 |       3 |  2048 |  2048 | 2048  (0)|
|*  4 |    TABLE ACCESS FULL | T1   |      1 |      1 |      1 |00:00:00.01 |       3 |       |       |          |
------------------------------------------------------------------------------------------------------------------

T1 doit être petite car elle est bufferisée. T2 doit avoir peu de lignes car on va voir le buffer pour chaque ligne. C'est intéressant lorsque la jointure ramène presque toutes les lignes de 2 petites tables.

Cordialement,
Franck