nested loop au lieu de hash join suite a instalation nouveau serveur

bonjour,

voici mon problème.

Nous avons une base en 10G sur un vieu serveur. nous avons acheter un nouveau serveur plus puissant et aussi une nouvelle licence oracle 10G.
Nous voulons garder l'ancien pour faire des tests ou éventuellement par la suite faire de la synchro (pour ma culture perso).

j'ai un pb de perf sur une requête assez grosse. sur l'ancien serveur cette requete s'execute en moins de 10 sec et sur le nouveau après 5 minutes, j'ai du couper son execution.

J'ai recalculer les stats, adapter les paramètres serveurs au dimensions du nouveau. J'ai même essayé de changer le mode de l'optimiser.

enfin bref, si je vous consulte, c'est je suis arrivé au bou de mes idées en la matière.

je vous fourni en pièce jointe (ZIPPE pour entrer dans les quotats )les deux explain des requêtes et le contenu de celle-ci.

la ou je pense que c'est interressant, c'est au debut.

Merci beaucoup

Stéphane

l'ancien serveur donne en explain :

Citation:

---

---------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 136 | 4726 (1)| 00:00:57 |
| 1 | SORT ORDER BY | | 1 | 136 | 4726 (1)| 00:00:57 |
|* 2 | HASH JOIN | | 1 | 136 | 4725 (1)| 00:00:57 |
| 3 | VIEW | | 1 | 49 | 3151 (1)| 00:00:38 |
| 4 | SORT ORDER BY | | 1 | 56 | 3151 (1)| 00:00:38 |


le nouveau donne ceci :
Plan hash value: 640089427

--------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 279 | 2044 (3)| 00:00:25 |
| 1 | SORT ORDER BY | | 1 | 279 | 2044 (3)| 00:00:25 |
| 2 | NESTED LOOPS | | 1 | 279 | 2043 (3)| 00:00:25 |
| 3 | VIEW | | 1 | 181 | 1363 (3)| 00:00:17 |

---

L’explain plan dit que le nouveau plan est meilleur en termes de coût: 2044 par rapport au 4726 et de temps d’exécution : 0,25 sec par rapport au 0.57.
Qu’est-ce que ça donne une trace SQL étendue sur le serveur le plus puissant ?
Comment les statistiques ont été calculées sur les deux serveurs ?

En tout cas votre requête SQL me paraît mal écrite, vous appelez trois fois la vue v_graph_charge_poste pour faire des niveaux d'aggrégats différents alors que vous pourriez le faire je pense en un seul scan avec des fonctions analytiques - je dis je pense car c'est quand même assez dense.

Que fait la fonction f_minmax() ?
Quel est le script derrière v_graph_charge_poste ?

Alors la requête est peut être mal ecrite, mais je n'en suis pas l'auteur et en ce moment je ne me vois pas me lancer dans sa modification.

Je ne sais même pas comment lancer une trace sur cette requête.

je pensais plutôt a un paramétrage du serveur.

la régénération des stats a été réalisée avec la console entreprise.
pour l'ensemble des schémas.

ce qui est bizare, c'est le nested loop c'etait un moment (pendant une journée) transformer en hash join apres suppression des stats.

Citation:

---

Envoyé par manusridolph

...Je ne sais même pas comment lancer une trace sur cette requête.
...

---

TKPROF et Explain Plan

Citation:

---

Envoyé par manusridolph

...ce qui est bizare, c'est le nested loop c'etait un moment (pendant une journée) transformer en hash join apres suppression des stats.

---

Comment l'optimiseur d'Oracle calcule le coût

apparemment c'est le order by a la fin qui penalise la requete.

j'ai supprimé cet ordre et fait le tri par la suite (apres generation d'u fichier texte et intégration dans excel).


Merci
.

Citation:

---

Envoyé par manusridolph

apparemment c'est le order by a la fin qui penalise la requete. ...

---

C'est quoi la valeur du paramètre optimizer_mode ?