Discussion :

[bidi]

Damned que c'est compliqué

Voici le résultat:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
----------------------------------------------------------------------------------------------
| Id  | Operation              |  Name                          | Rows  | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                                |     1 |    41 |   221  (10)|
|   1 |  SORT GROUP BY         |                                |     1 |    41 |            |
|*  2 |   HASH JOIN            |                                |     1 |    41 |   221  (10)|
|   3 |    NESTED LOOPS        |                                |   175 |  5425 |   124   (1)|
|*  4 |     INDEX RANGE SCAN   | ACTOR_M1_DENOM_LNM             |    60 |  1260 |     4  (25)|
|*  5 |     INDEX RANGE SCAN   | PART_ACTOR_M1_ACTOR_ID         |     3 |    30 |     3  (34)|
|*  6 |    INDEX FAST FULL SCAN| FILE_DECLARATION_M3_CITY_POST  |   149 |  1490 |    96  (21)|
----------------------------------------------------------------------------------------------

et c'est super rapide...

Mais j'ai quand même besoin de l'autre critère...

Je vais aller relire l'article car je ne vois pas ce que vous voulez dire avec "l''hypothèse d'indépendance des prédicats"

[mnitu]

Peux-tu vérifier la valeur du paramètre optimizer_index_cost_adj ?

[bidi]

Bon, sur ma db de test il est à 100.

Sur la db de prod, je n'ai pas accès

Mais j'imagine que c'est la même valeur car les comportements sont identiques.

J'ai demandé aux dba, j'attends leur réponse ^^.

[bidi]

voilà, j'ai eu confirmation, il est également à 100

Je vais essayer de jouer un peu avec ce paramètre pour voir ce que ça donne.

La valeur par défaut n'est pas conseillée de ce que j'ai pu lire...

Le problème c'est que je ne pourrai sans doute pas le faire changer en prod car il y a d'autres applications qui tournent et ils sont très... frilleux ^^

Au moins je saurai d'où ça vient

[mnitu]

Si la valeur est à 100 c’est OK.
Je pense que le souci est lié à la forte dépendance des colonnes postcode et city_lnm. Je vois deux solutions : soit de laisser un hint avec dynamique sampling à 4 (cella devrait suffire) soit de modifier la densité de la colonne city_lnm pour metre la valeur 1. Mais ça dépende des autres requêtes qui s’exécutent sur ces tables.

[bidi]

En effet, en retirant une des deux conditions, la requête est très rapide...

Les requêtes font toujours qui utilise city_lnm utilisent toujours aussi postcode. Est-ce suffisant pour mettre la densité de la colonne city_lnm à 1?

dernière petite question et je cloturerai ce sujet ^^

Est-il suffisant de faire: alter system flush shared_pool;

pour vider la cache et pouvoir ainsi avoir des mesures significatives des temps de réponse?

Merci

edit: avec un dynamic_sampling à 5 c'est parfait. 4 n'est apparement pas suffisant.

[mnitu]

En effet, en retirant une des deux conditions, la requête est très rapide...

Donc ça confirme l’hypothèse que dans ce cas le problème est lié à la dépendance des prédicats.

Les requêtes font toujours qui utilise city_lnm utilisent toujours aussi postcode. Est-ce suffisant pour mettre la densité de la colonne city_lnm à 1?

Oui, je pense mais, il faut tester et documenter.

Est-il suffisant de faire: alter system flush shared_pool;

pour vider la cache et pouvoir ainsi avoir des mesures significatives des temps de réponse?

Ca dépende mais je pense que non. Normalement une requête est exécutée plusieurs fois et donc le fait de trouver des informations dans le cache corresponde à une situation "normale".

[bidi]

Ok ben un grand merci en tout cas pour le temps passé à résoudre mon problème ^^.

Bonne continuation.