Datenablaufverfolgung in ADO.NET
In ADO.NET stehen integrierte Datenablaufverfolgungsfunktionen zur Verfügung, die von den .NET-Datenanbietern für SQL Server, Oracle, OLE DB und ODBC sowie vom ADO.NET DataSet- und den SQL Server-Netzwerkprotokollen unterstützt werden.
Die Ablaufverfolgung von Aufrufen der Datenzugriffs-API kann bei der Diagnose der folgenden Probleme helfen:
Fehlende Schemaübereinstimmung zwischen Clientprogramm und Datenbank.
Nicht verfügbare Datenbank oder Probleme mit der Netzwerkbibliothek.
Fehlerhafte SQL-Anweisungen (sowohl hart codiert als auch von einer Anwendung generiert).
Fehlerhafte Programmierlogik.
Probleme, die sich aus der Interaktion mehrerer ADO.NET-Komponenten oder aus der Interaktion zwischen ADO.NET und Ihren eigenen Komponenten ergeben.
Zur Unterstützung verschiedener Ablaufverfolgungstechnologien ist die Ablaufverfolgung erweiterbar, sodass Entwickler eine Ablaufverfolgung für Probleme auf jeder Ebene des Anwendungsstapels ausführen können. Obwohl die Ablaufverfolgung nicht auf ADO.NET beschränkt ist, nutzen Microsoft-Anbieter die Vorteile generalisierter Ablaufverfolgungs- und Instrumentierungs-APIs.
Weitere Informationen zum Festlegen und Konfigurieren der verwalteten Ablaufverfolgung in ADO.NET finden Sie unter Datenzugriffs-Ablaufverfolgung.
Zugreifen auf Diagnoseinformationen im Protokoll der erweiterten Ereignisse
Im .NET Framework-Datenanbieter für SQL Server wurde die Datenzugriffs-Ablaufverfolgung (Data Access Tracing) aktualisiert, um die Zuordnung von Clientereignissen zu Diagnoseinformationen, z. B. Verbindungsfehlern, aus dem Verbindungsringpuffer des Servers und Informationen zur Anwendungsleistung im Protokoll für erweiterte Ereignisse zu vereinfachen. Informationen dazu, wie Sie das Protokoll für erweiterte Ereignisse lesen, finden Sie unter View Event Session Data.
Für Verbindungsvorgänge sendet ADO.NET eine Clientverbindungs-ID. Bei einem Verbindungsfehler haben Sie die Möglichkeit, auf den Konnektivitätsringpuffer zuzugreifen (Konnektivitätsproblembehebung in SQL Server 2008 mit dem Konnektivitätsringpuffer) und über das Feld ClientConnectionID Diagnoseinformationen zum jeweiligen Verbindungsfehler abzurufen. Clientverbindungs-IDs werden nur im Ringpuffer protokolliert, wenn ein Fehler auftritt. (Wenn vor dem Senden des prelogin-Pakets keine Verbindung hergestellt werden kann, wird keine Clientverbindungs-ID generiert.) Die Clientverbindungs-ID ist eine 16-Byte-GUID. Sie finden die Clientverbindungs-ID auch in der Zielausgabe für erweiterte Ereignisse, wenn die client_connection_id-Aktion den Ereignissen in einer Sitzung für erweiterte Ereignisse hinzugefügt wurde. Sie können die Ablaufverfolgung für den Datenzugriff aktivieren, den Verbindungsbefehl erneut ausführen und das ClientConnectionID-Feld in der Datenzugriffs-Ablaufverfolgung beobachten, wenn Sie weitere Diagnoseinformationen zum Clienttreiber benötigen.
Sie können die Clientverbindungs-ID programmgesteuert abrufen, indem Sie die SqlConnection.ClientConnectionID-Eigenschaft verwenden.
ClientConnectionID ist für ein SqlConnection-Objekt verfügbar, das erfolgreich eine Verbindung herstellt. Wenn ein Verbindungsfehler auftritt, ist ClientConnectionID u. U. über SqlException.ToString verfügbar.
ADO.NET sendet zudem eine threadspezifische Aktivitäts-ID. Die Aktivitäts-ID wird in den Sitzungen für erweiterte Ereignisse aufgezeichnet, wenn die Sitzungen bei aktivierter TRACK_CAUSALITY-Option gestartet werden. Bei Leistungsproblemen mit einer aktiven Verbindung können Sie die Aktivitäts-ID aus der Datenzugriffs-Ablaufverfolgung des Clients abrufen (ActivityID-Feld) und dann die Aktivitäts-ID in der Ausgabe für die erweiterten Ereignisse suchen. Die Aktivitäts-ID in den erweiterten Ereignissen ist eine 16-Byte-GUID (nicht identisch mit der GUID für die Clientverbindungs-ID), an die eine 4-Byte-Sequenznummer angefügt wurde. Die Sequenznummer steht für die Reihenfolge einer Anforderung innerhalb eines Threads und gibt die relative Reihenfolge des Batches und der RPC-Anweisungen für den Thread an. ActivityID wird derzeit optional für SQL-Batchanweisungen und RPC-Anforderungen gesendet, wenn die Ablaufverfolgung für den Datenzugriff aktiviert ist und das 18. Bit im Konfigurationswort der Datenzugriffs-Ablaufverfolgung ON lautet.
Im folgenden Beispiel wird Transact-SQL zum Starten einer Sitzung für erweiterte Ereignisse verwendet, die in einem Ringpuffer gespeichert werden und die von einem Client in RPC- und Batch-Vorgängen gesendete Aktivitäts-ID aufzeichnen.
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)