Discussion :

[tropiko]

Bonjour ,
J'utilise SQL profile pour améliorer les plans d'exécution des requêtes de mon appli.
Aujourd'hui des requêtes sont prévues d'être modifiés(évolution) et le sql_id ainsi que le sql profile associé vont probablement changer.
Que faut -il faire dans ce cas ...?
générer un nouveau sql profile ?
Autre astuce pour limiter l'impact ?
Merci pour votre aide ?

[pachot]

Bonjour,

D'une manière générale, je considère les profils comme une solution provisoire, en attendant de pouvoir modifier des requêtes, modifier le modèle de données, ajouter des statistiques étendues, etc.
L'idéal serait de:

1. faire le tour des profils pour voir quel problème ils étaient censés adresser
2. tester ces uses cases dans la nouvelle release pour voir s'il y a à nouveau un problème
3. faire le tuning nécessaire, les profils n'étant qu'une alternative

Les profils sont utiles lorsqu'on ne peut rien faire sur le code. Mais si c'est une appli qui évolue, alors il aurait été préférable de trouver d'autres solutions. En dernier lieu, tout ce que fait un profil peut être fait dans la requête. Et c'est une meilleure place, plus facile à documenter.

Ce qui est certain, c'est que même si c'est possible d'affecter un profile existant à un autre sql_id, c'est une très mauvaise idée. Les profils sont déterminés par l'ensemble des plans d'exécution possible pour une requête. Si elle change, alors les profils ne sont plus adaptés.

Cordialement,
Franck.

[Mohamed.Houri]

Bonjour

Si le code SQL des requêtes va changer si bien que leur v$sql.force_matching_signature ne corresponde plus au dba_sql_profiles.signature (en admettant que vous ayez crée le profile avec la propriété FORCE à TRUE) alors le profile cessera d'être appliquée et Oracle se rabattra sur le plan compilé par le CBO.

Comme l'a si bien indiqué Franck, le profile représente une solution d'urgence lorsqu'une requête compliquée se met à dévier dangereusement lors d'un batch critique et que vous êtes appelé, de nuit, à intervenir d'urgence. Vous constatez que le même sql_id a déjà bien tourné avec un autre plan (plan_hash_value) alors vous décidez d'affecter ce plan_hash_value à cet sql_id. Et la requête reprend son temps d’exécution habituel.

Le problème c'est que trop souvent, nous oublions ce profile et au lieu d'aller à la recherche de la cause qui se trouve être très probablement un problème de statistiques ne reflétant pas la réalité (même si fraîchement calculées) nous passons à autre chose jusqu'au jour ou le profile pour une raison ou une autre cesse de s'appliquer.

Très récemment, un profile oubliée sur une requête extrêmement critique a cessé de fonctionner parce que la requête utilise une vue dont le contenu a changé (le code de la requête n'a pas changé). Il a fallu dans l'urgence améliorer la performance de cette requête sans avoir la possibilité de lui affecter un profile.

Bien Cordialement