Traçage de données dans ADO.NET
ADO.NET propose une nouvelle fonctionnalité intégrée de traçage de données prise en charge par les fournisseurs de données .NET pour SQL Server, Oracle, OLE DB et ODBC, de même que l’objet DataSet ADO.NET et les protocoles réseau SQL Server.
Le traçage d'appels API d'accès aux données peut aider à diagnostiquer les problèmes suivants :
discordance de schéma entre le programme client et la base de données ;
problèmes d'indisponibilité de base de données ou de bibliothèque réseau ;
SQL incorrect qu'il soit en codage dur ou généré par une application ;
logique de programmation incorrecte ;
problèmes résultant de l'interaction entre plusieurs composants ADO.NET ou entre ADO.NET et vos propres composants.
Pour prendre en charge plusieurs technologies de traçage, le traçage est extensible, de sorte qu'un développeur peut tracer un problème à tout niveau de la pile d'applications. Bien que le traçage ne soit pas une fonctionnalité purement ADO.NET, les fournisseurs Microsoft tirent parti des API de suivi et d’instrumentation généralisées.
Pour plus d’informations sur la définition et la configuration du traçage managé dans ADO.NET, consultez Tracing Data Access (en anglais).
Accès aux informations de diagnostic dans le journal des événements étendus
Dans le fournisseur de données .NET Framework pour SQL Server, le suivi d’accès aux données a été mis à jour pour faciliter la mise en corrélation des événements clients avec les informations de diagnostic, telles que les échecs de connexion, les informations de performance des applications et de la mémoire tampon en anneau de connectivité du serveur dans le journal des événements étendus. Pour plus d’informations sur la lecture du journal des événements étendus, consultez Afficher des données de session d’événements.
Pour les opérations de connexion, ADO.NET envoie un ID de connexion client. Si la connexion échoue, vous pouvez accéder à la mémoire tampon de l’anneau de connectivité (Résolution des problèmes de connectivité dans SQL Server 2008 avec la mémoire tampon de l’anneau de connectivité) et consulter le champ ClientConnectionID pour obtenir les informations de diagnostic sur l’échec de connexion. Les ID de connexion du client sont enregistrés dans la mémoire tampon en anneau uniquement en cas d'erreur. (Si une connexion échoue avant d'envoyer le paquet de préconnexion, un ID de connexion client ne sera pas généré.) L'ID de connexion client est un GUID à 16 octets. Vous pouvez également rechercher l'ID de connexion client dans la sortie cible d'événements étendus, si l'action client_connection_id est ajoutée aux événements dans une session d'événements étendus. Vous pouvez activer le traçage d'accès aux données, réexécuter la commande de connexion et observer le champ ClientConnectionID dans la trace d'accès aux données, si vous avez besoin d'obtenir une aide supplémentaire pour le diagnostic du pilote client.
Vous pouvez obtenir l'ID de connexion client par programme à l'aide de la propriété SqlConnection.ClientConnectionID.
ClientConnectionID est disponible pour un objet SqlConnection qui établit une connexion. Si une tentative de connexion échoue, ClientConnectionID peut être disponible via SqlException.ToString.
ADO.NET envoie également un ID d'activité propre au thread L’ID d’activité est capturé dans les sessions d’événements étendus si les sessions sont démarrées alors que l’option TRACK_CAUSALITY est activée. En cas de problèmes de performances avec une connexion active, vous pouvez obtenir l'ID d'activité de la trace d'accès aux données du client (champ ActivityID), puis rechercher l'ID d'activité dans la sortie des événements étendus. L'ID d'activité dans des événements étendus est un GUID de 16 octets (différent du GUID de l'ID de connexion client) ajouté à un numéro séquentiel à quatre octets. Le numéro séquentiel représente l'ordre d'une demande dans un thread et indique l'ordre relatif du traitement par lot et des instructions RPC pour le thread. ActivityID est actuellement éventuellement envoyé pour les instructions par lots SQL et les demandes RPC lorsque le suivi de l'accès aux données est activé et le 18e bit dans le mot de configuration de suivi d'accès aux données est activé.
Voici un exemple qui utilise Transact-SQL pour démarrer une session d'événements étendus qui sera stockée dans une mémoire tampon en anneau et enregistrera l'ID d'activité envoyé d'un client sur des opérations de traitement par lot et RPC.
create event session MySession on server
add event connectivity_ring_buffer_recorded,
add event sql_statement_starting (action (client_connection_id)),
add event sql_statement_completed (action (client_connection_id)),
add event rpc_starting (action (client_connection_id)),
add event rpc_completed (action (client_connection_id))
add target ring_buffer with (track_causality=on)