Śledzenie danych w ADO.NET
ADO.NET oferuje wbudowane funkcje śledzenia danych obsługiwane przez dostawców danych platformy .NET dla programów SQL Server, Oracle, OLE DB i ODBC, a także protokołów sieciowych ADO.NET DataSeti programu SQL Server.
Śledzenie wywołań interfejsu API dostępu do danych może pomóc zdiagnozować następujące problemy:
Niezgodność schematu między programem klienta a bazą danych.
Problemy z niedostępnością bazy danych lub biblioteką sieci.
Niepoprawny kod SQL niezależnie od tego, czy kodowany w sposób twardy, czy generowany przez aplikację.
Niepoprawna logika programowania.
Problemy wynikające z interakcji między wieloma składnikami ADO.NET lub między ADO.NET a własnymi składnikami.
Aby obsługiwać różne technologie śledzenia, śledzenie jest rozszerzalne, więc deweloper może śledzić problem na dowolnym poziomie stosu aplikacji. Chociaż śledzenie nie jest ADO. Funkcja tylko dla platformy NET, dostawcy firmy Microsoft korzystają z uogólnionych interfejsów API śledzenia i instrumentacji.
Aby uzyskać więcej informacji na temat ustawiania i konfigurowania śledzenia zarządzanego w ADO.NET, zobacz Śledzenie dostępu do danych.
Uzyskiwanie dostępu do informacji diagnostycznych w dzienniku zdarzeń rozszerzonych
W programie .NET Framework Dostawca danych dla programu SQL Server zaktualizowano śledzenie dostępu do danych (śledzenie dostępu do danych), aby ułatwić korelowanie zdarzeń klienta z informacjami diagnostycznymi, takimi jak błędy połączenia, z buforu pierścienia łączności serwera i informacji o wydajności aplikacji w dzienniku zdarzeń rozszerzonych. Aby uzyskać informacje na temat odczytywania dziennika zdarzeń rozszerzonych, zobacz Wyświetlanie danych sesji zdarzeń.
W przypadku operacji połączenia ADO.NET wyśle identyfikator połączenia klienta. Jeśli połączenie nie powiedzie się, możesz uzyskać dostęp do buforu pierścienia łączności (Połączenie ivity troubleshooting in SQL Server 2008 with the Połączenie ivity Ring Buffer) i znaleźć ClientConnectionID pole i uzyskać informacje diagnostyczne dotyczące błędu połączenia. Identyfikatory połączeń klienta są rejestrowane w buforze pierścienia tylko wtedy, gdy wystąpi błąd. (Jeśli połączenie nie powiedzie się przed wysłaniem pakietu przedlogin, identyfikator połączenia klienta nie zostanie wygenerowany). Identyfikator połączenia klienta to 16-bajtowy identyfikator GUID. Identyfikator połączenia klienta można również znaleźć w danych wyjściowych docelowych zdarzeń rozszerzonych, jeśli client_connection_id akcja zostanie dodana do zdarzeń w sesji zdarzeń rozszerzonych. Możesz włączyć śledzenie dostępu do danych i ponownie uruchomić polecenie połączenia i obserwować ClientConnectionID pole w śladzie dostępu do danych, jeśli potrzebujesz dalszej pomocy diagnostycznej sterownika klienta.
Identyfikator połączenia klienta można uzyskać programowo przy użyciu SqlConnection.ClientConnectionID właściwości .
Obiekt ClientConnectionID jest dostępny dla SqlConnection obiektu, który pomyślnie ustanawia połączenie. Jeśli próba połączenia nie powiedzie się, ClientConnectionID może być dostępna za pośrednictwem .SqlException.ToString
ADO.NET również wysyła identyfikator działania specyficzny dla wątku. Identyfikator działania jest przechwytywany w sesjach zdarzeń rozszerzonych, jeśli sesje są uruchamiane z włączoną opcją TRACK_CAUSALITY. W przypadku problemów z wydajnością aktywnego połączenia można uzyskać identyfikator działania ze śledzenia dostępu do danych klienta (ActivityID pole), a następnie zlokalizować identyfikator działania w danych wyjściowych zdarzeń rozszerzonych. Identyfikator działania w zdarzeniach rozszerzonych to 16-bajtowy identyfikator GUID (nie taki sam jak identyfikator GUID dla identyfikatora połączenia klienta) dołączony z numerem sekwencji czterech bajtów. Numer sekwencji reprezentuje kolejność żądania w wątku i wskazuje względną kolejność instrukcji wsadowych i RPC dla wątku. Element ActivityID jest obecnie opcjonalnie wysyłany dla instrukcji wsadowych SQL i żądań RPC, gdy śledzenie dostępu do danych jest włączone, a 18 bit w słowie konfiguracji śledzenia dostępu do danych jest włączony.
Poniżej przedstawiono przykład, który używa języka Transact-SQL do uruchomienia sesji zdarzeń rozszerzonych, która będzie przechowywana w buforze pierścieniowym i rejestruje identyfikator działania wysyłany z klienta w ramach operacji RPC i wsadowych.
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)