Korzystanie z SQL Profiler w bazie danych, która jest produkowana

Jako programista często korzystam z SQL Profiler. To dobre narzędzie do debugowania, zarówno do śledzenia tego, co robi mój kod, jak i do analizy problemów z wydajnością.

Ale zawsze używałem go w moim środowisku programistycznym i w bardzo kontrolowany sposób.

• Uruchom moją aplikację i ustaw ją w określonym stanie
• Rozpocznij śledzenie w profilerze
• Wykonaj określoną sekwencję czynności w mojej aplikacji
• Zatrzymaj śledzenie i sprawdź wyniki.

Czy SQL Profiler może być praktycznie używany w środowisku produkcyjnym?

Moim pierwszym problemem jest pogorszenie wydajności.

Moja druga obawa dotyczy tego, że ponieważ jest produkowany, nie uruchamiasz samych interesujących działań. Musisz pozostawić profiler działający przez długi czas, a następnie przeanalizować wyniki. Czy zestaw wyników stałby się zbyt niewygodny? (Zajmuje zbyt dużo miejsca na dysku i jest zbyt trudne do zapytania).

Czy ktoś używa SQL Profiler w produkcji?

Użycie Sql Server Profiler (narzędzie GUI) do śledzenia serwera produkcyjnego nie jest dobrym pomysłem. Ale to zależy od obciążenia. Zamiast tego należy używać śledzenia SQL po stronie serwera (patrz procedury sp_trace_XXX ). Znalazłem także artykuły:

Wpływ na wydajność: śledzenie profilera vs. śledzenie SQL po stronie serwera ,

Automatyzacja śledzenia po stronie serwera w programie SQL Server

Unikaj powodowania problemów z Profiler

może będzie zainteresowany i przydatny.

Book Online mówi:

• Uruchom Profiler zdalnie zamiast bezpośrednio na serwerze
• Unikaj włączania zdarzeń, które występują często (np. Blokada: Nabyte), chyba że jest to absolutnie konieczne
• Uwzględnij tylko potrzebne klasy zdarzeń
• Określ filtry ograniczające, aby zmniejszyć liczbę zdarzeń
• Unikaj zbędnych danych (np. SQL: BatchStarting i SQL: BatchCompleted)
• Unikaj uruchamiania dużych śladów za pomocą Profiler; zamiast tego rozważ śledzenie SQL po stronie serwera
• Ogranicz rozmiar pliku śledzenia po stronie serwera i zarządzaj wykorzystaniem miejsca

Cały czas używam SQL Profilera przeciwko produkcji. Przy prawidłowym wykonaniu (filtrowanie w celu odzyskania bardzo małej ilości danych) na serwerze ryzyko jest minimalne. Śledzenie wszystkiego byłoby bezużyteczne.

1. Tak, akt monitorowania będzie wymagał pewnych zasobów. Uruchomienie go na przeciążonym serwerze może go zabić.

2. W rzeczywistości będziesz monitorować rzeczywiste obciążenie: twoje działania mogą zagubić się w hałasie tego obciążenia.

Czasami uruchamiamy go na produkcji. Głównie z filtrem tekstowym dla określonego kodu lub z filtrami procesora / czasu trwania w celu wychwytywania dłuższych zapytań. I nie próbujemy przechwytywać planów wykonania XML ani czegoś takiego

Kluczem do sukcesu jest wiedzieć, czego szukasz: nie pozwalamy, aby działał i wszystko uwięził.

W takim przypadku, jeśli chcesz zobaczyć wyniki niektórych działań, możesz to zrobić poza godzinami pracy?

Profiler zawsze wprowadza wpływ na wydajność.

Jeśli używasz programu SQL Server 2008R2 +, możesz używać zdarzeń rozszerzonych. Zapewnia to wiele informacji widocznych w profilerze z ułamkiem wydajności.

Wprowadzenie do książek online http://technet.microsoft.com/en-us/library/bb630354(v=sql.105).aspx

Ta funkcja otrzymała dużą aktualizację w SQL Server 2012, która teraz zawiera GUI w SSMS.