Lorsque j'ai dû examiner des problèmes de mise en cache de plan/de recompilation excessive des requêtes dans le passé, j'ai suivi les conseils fournis dans le livre blanc de Microsoft 'Planifier la mise en cache dans SQL Server 2008' et je suggérerais fortement de lire cela car il couvre la mise en cache du plan, la réutilisation du plan de requête, les causes des recompilations, l'identification des recompilations et d'autres sujets connexes.
Cela dit, SQL Server Profiler (devrait être situé sous Microsoft SQL Server 2008 -> Outils de performance si vous l'avez installé dans le cadre de l'installation de vos outils clients) expose trois événements directement liés à la compilation de requêtes qui peuvent vous être utiles :
- Curseur
- CurseurRecompile
- Performances
- Showplan XML pour la compilation de requêtes
- Procédure stockée
- SP :Recompiler
Vous utilisez des procédures stockées, il est donc probable que vous n'ayez qu'à vous soucier de SP :Recompiler un événement. Cet événement se déclenche chaque fois qu'une procédure stockée, un déclencheur ou une fonction définie par l'utilisateur a été recompilé. La colonne TextData affichera le texte de l'instruction tsql qui a provoqué la recompilation de l'instruction et la colonne EventSubClass affichera un code indiquant la raison de la recompilation.
Codes EventSubClass pour SP :recompiler dans SQL 2008
- 1 =Schéma modifié
- 2 =Statistiques modifiées
- 3 =Recompiler le DNR
- 4 =Définir l'option modifiée
- 5 =Table des températures modifiée
- 6 =Ensemble de lignes distant modifié
- 7 =Pour les autorisations de navigation modifiées
- 8 =Environnement de notification de requête modifié
- 9 =vue MPI modifiée
- 10 =Options du curseur modifiées
- 11 =Avec l'option de recompilation
Si vous surveillez les 5 événements suivants, vous pourrez voir quelles procédures stockées et instructions sont appelées sur le serveur SQL et lesquelles déclenchent des recompilations :
- Procédures de magasin
- SP :Démarrage
- SP:StmtStarting
- SP :Recompiler
- SP :Terminé
- Performances
- Statistiques automatiques
Je configure également généralement la trace du profileur pour capturer toutes les colonnes de ces événements. Je dirais que configurez une trace avec ces 5 événements, exécutez une trace pendant 30 à 60 secondes, puis mettez-la en pause, puis vous devriez avoir un bon aperçu de ce qui cause les recompilations.
S'il y a trop de bruit, vous pouvez commencer à ajouter des filtres de colonne aux propriétés de trace pour filtrer les événements d'entrée/sortie. Par exemple, si vous constatez que la plupart de vos recompilations se produisent sur une seule base de données, configurez un filtre de colonne sur la colonne databaseID ou databaseName afin que seules les requêtes exécutées sur cette base de données soient incluses dans votre trace.
Ensuite, commencez à rechercher des modèles dans lesquels les requêtes sont recompilées et utilisez le livre blanc de Microsoft comme guide pour savoir pourquoi elles pourraient déclencher la recompilation.
