[Perf] impact du paramètre query_rewrite_enabled

Bonjour,

je voulais savoir si le fait que le paramètre query_rewrite_enabled soit positionné par defaut à TRUE en 10G peut expliquer certains problèmes de perfs sur des requêtes suite à la migration 9i vers la 10G.

Il me semble avoir lu dans le livre de Gavin POWELL que ce paramètre pouvait fortement altérer les plans d'execution.

Je me pose cette question car je travaille pour un éditeur de progiciels financiers et chez un de nos clients qui a migré en 10G récemment il y'a des requêtes qui mettent 2 heures alors qu'avant elles passaient en moins de 10 minutes. Les stats sont apparemment à jour et la volumétrie n'a pas changé.

ce paramètre peut-il expliquer cela? Je n'ai pas accès à leur base directement donc j'ai un peu de mal mais je leur ait demandé en attendant de passer le paramètre OPTIMIZER_FEATURES_ENABLE à 9.2.0 pour voir quel est le plan d'execution d'avant.

Par ailleurs le paramètre query_rewrite_enabled sert_il vraiment à qqchose si on utilise pas les Vues Materialisées?

Merci à ceux qui pourront m'aider

Ca m'est arrivé assez souvent d'avoir des performances dégradées en migrant de 9i vers 10g
Plutôt que de remettre OPTIMIZER_FEATURES_ENABLE à 9.2.0, vérifie que les requêtes sont vraiment bien écrites et optimisées, sans conversions implicites, qu'il y a les indexes là où il faut (sur les FK par exemple), que les stats sont bien calculées avec histogrammes (par défaut depuis la 10g il me semble)
Regarde aussi si ce n'est pas dû à des requêtes lancées plein de fois avec un hard parse à chaque fois (j'avais déjà eu ce problème : l'optimiseur 10g mettait quelques centièmes de secondes de plus que l'optimiseur 9i pour calculer le plan d'exécution, sauf que quand une requête est hard-parsée 1 millions de fois, on voit la différence ...)
Bref la migration en 10g est peut-être l'occasion de remettre au carré ou d'optimiser ce qui ne l'a jamais été mais qui marchait quand-même en 9i grâce à des plans d'exécution "chanceusement corrects"

Merci de t'intéresser à mon topic.

Apparemment le client a lancé la requête incriminée avec le paramètre OPTIMIZER_FEATURES_ENABLE à 9.2.0 et le plan d'execution est toujours le même.

j'ai demandé à ce que les stats soit recalculés sur toutes les tables pour être sûr.

Es-tu certains que les histogrammes sont calculés par défaut en 10G? sur toutes les colonnes de toutes les tables ? Ca m'étonne!!!!

Que veux tu dire exactement quand tu parles de hard-parse ?

Les histogrammes sont calcules par default en 10g, mais avec le parametre AUTO, ce qui ne signifie pas un histogramme sur toutes les colonnes mais un peu mieux, ca depend de la repartition des donnees et de la charge sur chaque colonne.

Nicolas.

Le plan est-il meilleur et la requête moins longue quand tu mets query_rewrite_enabled à FALSE ?
En 10g il me semble que dans dbms_stats, la valeur est par défaut est "FOR ALL COLUMNS SIZE AUTO". Regarde dans DBA_TAB_COL_STATISTICS si des stats existent sur les colonnes
C'est juste une requête lancée unitairement qui est longue ?
Ou bien c'est la même requête souvent lancée mais avec des valeurs de paramètres différents ? Si c'est ce cas, la non-utilisation de bind variables peut amener à recalculer le plan d'exécution à chaque nouvelle exécution de la requête, ce qui peut être coûteux si elle est exécutée souvent

Bref les causes peuvent être multiples ;)
T'as fait un coup de AWR pour voir les attentes sur la base ?

Le client se situe à singapour et je n'ai pas accès à leur base. Actuellement il fait nuit chez eux et les stats vont être recalculés ce week end. Je demanderai un accès via webex à leur base lundi matin pour analyser tout ça. Apparemment il s'agit d'une seule requête appelée une seule fois lors d'un reporting.

le client n'a pas testé d'exécuter la requête avec le paramètre à 9.2.0. Il a seulement regarder le plan d'execution qui est exactement le même (selon lui).

Effectivement en 10g Oracle arrive plus ou moins à déterminer les colonnes sur lesquels il doit calculer des histogrammes.

peux tu me répondes sur les hard-parse ?

Laisse tomber les hard parse si c'est juste une requête lancée une fois qui est longue ç'était une mauvaise piste
Compare les plans d'exécution avec ton optimiseur en 9i et en 10g, vérifie s'il ne manque pas des indexes, si les cardinalités sont bonnes dans les plans d'exécution, ...