Discussion :

[hmira]

* Bonjour, *

J'avais un doute sur l'impact des instructions telles que "ALTER TABLE .... DISABLE TRIGGER ALL" ou "ALTER TABLE ... ENABLE TRIGGER ALL" sur le Plan Cache des Query et procédures.

Je croyais que seules les "vraies" modifications de structures (exemple ajout ou modification du type d'une colonnes, etc) avaient pour effet d'invalider le Plan Cache liés aux objets (tables etc..) dont la structure a été modifiée, mais pas la simple activation ou désactivation des triggers, même si la syntaxe utilise le mot clé ALTER.

Et bien j'avais tort ! En effet, pour en avoir le cœur net, j'ai analysé les événements CacheMiss, CacheInsert, CacheRemove etc, et je me suis aperçu avec un peu d'étonnement que les instructions telles que ALTER TABLE DISABLE/ENABLE TRIGGER ALL, invalident bien les Plan Cache !

Alors ma question est la suivante :
"Pourquoi les instructions comme ALTER TABLE ... DISABLE/ENABLE TRIGGER ALL" appliquées à une table ont pour effet d'invalider le Plan Cache des query et procédures afférentes à la dite table ?"

Remarque :
- L'utilisation des instructions telles que ALTER TABLE .... DISABLE/ENABLE TRIGGER ALL est assez courante dans certaines tâches planifiées ou autres traitements particuliers divers ! C'est une des rasions pour lesquelles j'ai voulu investiguer le sujet.

Si quelqu'un veut bien nous éclairer.

Merci,

A+

[elsuket]

Bonjour,

De ce que je viens d'expérimenter :

• Le plan du trigger est évincé du cache dès qu'on désactive le trigger
• Il est compilé lors de l'exécution d'une instruction correspondant à l'événement de déclenchement du trigger, après avoir été (ré-)activé

Votre question devient-elle donc la suivante ?
pourquoi le plan du trigger est évincé du cache de plans lorsqu'on désactive l'exécution du trigger sur la table ?

Intuitivement je dirai que comme il est désactivé, le moteur l'évince automatiquement car son code, la structure de la table, et le volume de données peut avoir changé lors de sa réactivation.
C'est donc pour forcer une nouvelle compilation, donc une nouvelle optimisation en adéquation avec ces changements.

@++

[hmira]

Bonjour elsuket, et merci pour vos réponses.

De ce que je viens d'expérimenter :

• Le plan du trigger est évincé du cache dès qu'on désactive le trigger
• Il est compilé lors de l'exécution d'une instruction correspondant à l'événement de déclenchement du trigger, après avoir été (ré-)activé

Oui, ce comportement ne m'aurait pas choqué, et je le trouve même normal puisque le trigger a été désactivé et qu'il n'y a pas de raison de le garder dans le Plan Cache.
Mais, ce n'est pas de cela dont je parle ! Je parle du plan d'exécution d'une simple requête SELECT. Par exemple :
SELECT * FROM dbo.Client WHERE IdClient = @IdClient

Après l'exécution de l' instruction ALTER ci-desous :
ALTER TABLE dbo.Client DISABLE TRIGGER ALL

Le plan préalablement compilé et stocké dans le Plan Cache de la requête SELECT * FROM dbo.Client WHERE IdClient = @IdClient est invalidé. Et donc à la prochaine exécution de la même requête SELECT ci-dessus, il y a une suppression du plan (CacheRemove) et une nouvelle compilation du Plan et c'est cela qui me gêne.

Votre question devient-elle donc la suivante ?
pourquoi le plan du trigger est évincé du cache de plans lorsqu'on désactive l'exécution du trigger sur la table ?

Non ! Ce n'est pas la question qui me préoccupe. Je trouve au contraire normal que le plan du trigger soit évincé du cache après sa désactivation.

Intuitivement je dirai que comme il est désactivé, le moteur l'évince automatiquement car son code, la structure de la table, et le volume de données peut avoir changé lors de sa réactivation.
C'est donc pour forcer une nouvelle compilation, donc une nouvelle optimisation en adéquation avec ces changements.

Je suis entièrement d'accord avec vous, mais ce n'est pas là le problème. Voir réponse ci-dessus.

Merci.

A+

[hmira]

Il faut se rendre à l'évidence que les instructions telles que
ALTER TABLE ... DISABLE/ENABLE TRIGGER ALL
ont pour effet d'invalider les plans d'exécution compilés, et donc de ce fait, elles ne doivent en aucun cas, faire partie des traitements applicatifs routiniers, susceptibles d'être exécutés plusieurs fois par jour.
Ces instructions doivent, à mon sens, être réservées à des traitements très particuliers, exceptionnels, par exemple lors du chargement initial des données, ou lors de mises à jour importantes de la base données.

A+