La trace SQL a été abandonnée et il est important de passer aux événements étendus pour garantir une fonctionnalité continue. Cependant, changer manuellement toutes les traces en sessions d’événements étendus peut être une tâche ardue. Heureusement, il existe une procédure créée par Jonathan Kehayias de SQLskills qui peut automatiser ce processus pour vous.

Pour utiliser cette procédure, vous devez être sur SQL Server 2012 ou une version ultérieure. Si vous utilisez SQL Server 2008 ou 2008 R2, il est peu probable que la plupart de vos traces puissent être directement converties en événements étendus en raison du manque de parité complète entre les deux.

Pour convertir un script de trace SQL en une session d’événements étendus, vous pouvez suivre ces étapes :

1. Mettez en œuvre la procédure fournie par Jonathan Kehayias sur votre système.
2. Exécutez la procédure avec les paramètres nécessaires, tels que TraceID, SessionName, PrintOutput et Execute.
3. Démarrez la session d’événements étendus en utilisant l’instruction ALTER EVENT SESSION.

Une fois que la session d’événements étendus est créée et démarrée, vous pouvez vérifier qu’elle capture le même type de données que la trace par défaut. Vous pouvez exécuter un lot de requêtes pour générer des événements, puis rechercher à la fois le fichier de trace par défaut et le fichier cible de la session pour ces événements.

Il est important de noter que bien que les événements étendus soient destinés à être un remplacement proche de la trace SQL, il peut y avoir certains événements qui n’ont pas d’équivalent dans les événements étendus. Dans de tels cas, vous devrez peut-être trouver d’autres moyens de capturer ces événements, tels que l’utilisation de l’audit SQL Server.

L’interrogation de la session d’événements étendus à l’aide de la fonction fn_xe_file_target_read_file peut être plus fastidieuse par rapport à l’utilisation de la fonction fn_trace_gettable. De plus, cela peut être plus lent et peut nécessiter le dumping de la sortie XML dans une table temporaire distincte avant d’exécuter XQuery dessus.

Il convient également de mentionner qu’il est préférable d’éviter d’utiliser le Profiler et “Watch Live Data” pour afficher les données de trace et de session en temps réel, en particulier dans des scénarios de production, car cela peut avoir des conséquences désastreuses.

Que vous choisissiez de continuer à utiliser la trace SQL ou de passer aux événements étendus, il est important de prendre en compte l’impact sur le serveur surveillé, souvent appelé “l’effet observateur”. Dans un article séparé, Jonathan a démontré qu’une session d’événements étendus a moins d’impact sur l’observateur par rapport à une trace côté serveur équivalente. Par conséquent, en plus de l’aspect de l’obsolescence, les performances peuvent également être un facteur motivant pour passer de la trace aux événements étendus.

En suivant les étapes décrites ci-dessus et en utilisant la procédure fournie, vous pouvez facilement convertir vos traces SQL en sessions d’événements étendus, garantissant ainsi une fonctionnalité continue et améliorant potentiellement les performances.