Changement de plan d'exécution

[scheu]

Bonjour

En 10.2.0.4, j'ai un traitement de nuit qui fait une requête (avec bind variables), je le trace pour récupérer avec tkprof le plan d'exécution (qui n'est pas terrible)
Je calcule le lendemain matin le plan d'exécution de cette même requête bindée, et il est différent en mieux (pas le même ordre de jointure des différentes tables, pas les mêmes indexes utilisés)

Entre temps, pas de modifications des stats des tables ni indexes
Le traitement tracé ne semble pas faire de "alter session" pour modifier des paramètres d'instance

Quelles sont autres les raisons qui pourraient expliquer que le plan d'exécution soit différent la nuit, et quelques heures plus tard le matin ?

Une charge ponctuelle trop importante sur la base pourrait-elle avoir une influence sur le plan d'exécution ?
Ou autre ?

Merci d'avance pour votre aide, je commence à m'arracher les cheveux là ...

[jkofr]

Un calcul des stats par les nightly jobs peut-être?

Quelle est la valeur de la colonne LAST_ANALYZED de tes tables juste avant ton traitement?

Jko

[scheu]

Merci pour ton aide
J'y avais pensé mais non, j'ai bien vérifié, j'avais désactivé le calcul quotidien des stats depuis plusieurs jours pour être sûr
Le dernier calcul des stats date d'avant le nightly job, j'ai bien vérifié dans la colonne last_analyzed (donc pas de nouvelles stats calculées par le batch)

Je ne comprends donc toujours pas pourquoi j'ai un plan d'exécution différent entre le nightly job et après

[jkofr]

Peut-être un changement massif de données.
Dans ce cas, tes stats et histos sont plus en phase avec la répartition de tes données.

Une idées a explorer.

Tu devais extraire tous les prédicats de la requête en question pour voir.

jko

[Rams7s]

Est-ce qu'il y a eu un hard parse de la requete le soir ('mauvais plan') et le matin ('bon plan')?
Si les statistics sont les memes, et la bind variable aussi, c'est peut-etre du a l'usage des bind variables en elles memes.

[jkofr]

Envoyé par Rams7s

Est-ce qu'il y a eu un hard parse de la requete le soir ('mauvais plan') et le matin ('bon plan')?
Si les statistics sont les memes, et la bind variable aussi, c'est peut-etre du a l'usage des bind variables en elles memes.

En combinaison donc d'un changement radical de la répartition des histos...

Je pousserai l'investigation dans cette direction.

jko

[Mohamed.Houri]

Il faudrait au moins poster les deux explains plan que vous avez déjà jugés comme bon et mauvais. Je me hasarde en pensant que ''bon et mauvais'' pour vous correspondent à ''rapide et lent'' respectivement n'est ce pas?

Puisque vous dites que vous avez récupéré l'explain plan avec tkprof (peut-être avez vous activé le 10046 events et l'avez profilé avec tkprof) il y a donc de fortes chances que les explains plans que vous avez obtenus sont les vrais explains plan exécutés par votre requête. je veux dire qu'il ne faut pas se baser sur les explains plan obtenus par la commande explain plan for ... suivi d'un select * from table(dbms_xplan.display) car ces derniers ne sont qu'une approximation et peuvent représenter une erreur car ils considèrent tous les binds variables comme des varchar2

Vous n'avez également pas précisé si les bind variables que vous avez utilisées la nuit diffèrent de celles que vous avez utilisées le matin, néanmoins il semblerait que votre problème de changement d'explain plan provienne du "bind variable peeking". L'Optimizer (CBO) calcule son explain plan sur la base des premières input bind variables et le "stock" dans le library cache du shared pool pour une eventuelle réutilisation. En l'absence d'histograme sur les colonnes "bindées" il est probable que l'explain plan ne change pas. Dans le cas contraire, toutes les requêtes suivantes subiront un bind variable peeking pouvant conduire à un explain plan différent.

Le cache et l'activité de la base de données au moment de l'execution de la requête peuvent jouer un role très important aussi: pensez bien que le travail nécessaire pour un select sur une table qui est en train d'être modifiée (read consistency) est différent de celui fait lors d'un select sur une table calme.

Enfin, il suffit parfois d'un seul record de plus pour faire basculer un explain plan d'un état A à un état B. C'est le record de la limite :-)

Enfin, si les bind variables de nuit et celles de jour sont identiques je vous suggere dans ce cas de lire l'article suivant écrit par Jonathan Lewis suite à une question que j'ai posée moi-même il y a quelques années déjà

http://jonathanlewis.wordpress.com/2.../12/no-change/

Bien cordialement

Mohamed Houri

[Ahmed AANGOUR]

un bon plan le matin, un bon plan le soir...ça me rappelle l'histoire vraie qu'on m'a raconté une fois concernant un pb soumis au support Oracle. Le pb énoncé par le client consistait à dire que lorsqu'il faisait beau l'application ne rencontrait pas de pb de perf mais lorsqu'il pleuvait la base était dans les choux.

Si vous voulez en savoir plus j'ai repris cette anecdote (que je trouve géniale) pour illustrer le Bind Peeking dans un article que j'ai écris il y'a plusieurs mois:
http://ahmedaangour.blogspot.com/201...e-peeking.html