Jak wiadomo, głównym obowiązkiem administratora bazy danych jest monitorowanie wydajności SQL Server i interwencja w określonym czasie. Na rynku można znaleźć kilka narzędzi do monitorowania wydajności programu SQL Server, ale czasami potrzebujemy dodatkowych informacji o wydajności programu SQL Server, aby diagnozować i rozwiązywać problemy z wydajnością. Dlatego musimy mieć wystarczającą ilość informacji o widokach dynamicznego zarządzania SQL Server, aby poradzić sobie z problemami dotyczącymi SQL Server.
Dynamic Management View (DMV) to koncepcja, która pomaga nam odkrywać metryki wydajności SQL Server Engine. DMV został po raz pierwszy ogłoszony w wersji SQL Server 2005 i był kontynuowany we wszystkich wersjach SQL Server później. W tym poście porozmawiamy o konkretnym DMV, którego administrator bazy danych musi mieć wystarczającą ilość informacji. To jest sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats obsługuje podstawowe metryki do diagnozowania problemów z wydajnością programu SQL Server. Jeśli masz jakieś problemy (procesor, pamięć, I/O, blokada, zatrzask itp.) w silniku SQL Server, dane sys.dm_os_wait_stats pomagają nam zdefiniować problem. Monitor aktywności w SQL Server Management Studio zawiera panel o nazwie „Resource Waits ”. „Resource Waits” pobiera te metryki ze specjalnej procedury składowanej. Nazwa tej tymczasowej procedury składowanej to „#am_generate_waitstats ” i używa sys.dm_os_wait_stats. Tę tymczasową procedurę składowaną można znaleźć w „tempdb”. W tym miejscu chciałbym dodać kilka uwag dotyczących tymczasowej procedury składowanej. Ponieważ ten typ procedury składowanej nie ma wspólnego zastosowania.
Tymczasowa procedura składowana nie różni się od stałych procedur składowanych. Ma dwa typy:lokalne i globalne, takie jak tabele tymczasowe. Lokalna procedura składowana pozostaje aktywna w bieżącej sesji i jest usuwana po zamknięciu sesji. Można go utworzyć w następujący sposób:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
Globalna procedura składowana pozostaje również aktywna we wszystkich sesjach i usuwana po zamknięciu utworzonej sesji. Globalną procedurę składowaną można utworzyć jako:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Wskazówka: Kiedy otwieramy Monitor aktywności, tworzy on #am_generate_waitstats tymczasowa procedura składowana i porzuca ją po zamknięciu.
Teraz przyjrzymy się głównej idei i szczegółom sys.dm_os_wait_stats . Poniższe zapytanie zwróci wszystkie dane dotyczące SQL Server „Wait Statistics”. To zapytanie jest w najczystszej formie. Wykrycie problemów z taką formą jest niewygodne. W kolejnych sekcjach znajdziesz więcej przydatnych zapytań niż sys.dm_os_wait_stats. Teraz wyjaśnimy opis kolumn SQL Server „Statystyka oczekiwania”:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
Kolumna wait_type zawiera definicję lub nazwę statystyk oczekiwania. Dane kolumny wait_type są dla nas istotne, ponieważ definicja statystyki wait wskazuje główną przyczynę problemu. Waiting_tasks_count wskazuje częstotliwość typu oczekiwania występującego w SQL Server.
wait_time_ms wskazuje całkowity czas oczekiwania. Jednostką miary jest milisekunda.
max_wait_time_ms wskazuje maksymalny czas oczekiwania.
signal_wait_time_ms jest opisany w MSDN jako „Różnica między czasem, w którym oczekujący wątek został zasygnalizowany, a czasem, w którym zaczął działać”. Szczególnie wysoka wartość tej kolumny oznacza nacisk procesora. Tak więc zapytanie czeka w uruchomionej kolejce i jest gotowe do uruchomienia, ale procesor jest zajęty innymi zapytaniami. Z tego powodu zapytanie czeka w kolejce. Gdy zasoby procesora będą dostępne, procesor otrzyma nowe zapytanie z uruchamialnej kolejki i rozpocznie przetwarzanie. Krótko mówiąc, możemy opisać signal_wait_time_ms jako czas oczekiwania w kolejce do uruchomienia, który jest stanem, w którym można uruchomić.
Wskazówka: W najlepszej praktyce kilka statystyk oczekiwania jest ważniejszych niż inne. Można je wymienić jako:
• PAGEIOLATCH_*
• WRITELOG
• ASYNC_NETWORK_IO
• CXPACKET
• Procesor
• LCK_M_*
• PREEMPTIVE_*
• PAGELATCH_*
Spójrz na Pinal Dave'a lub Paula S. Randala, czekającego na zapytania statystyczne. Wyeliminowali ze swoich zapytań kilka typów statystyk oczekiwania. Poniższe typy oczekiwania na zasoby można wyeliminować w sys.dm_os_wait_stats zapytania:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_NADAJNIK
• KOLEJKA_KONTROLI
• CHKPT
• CENTLR_AUTO>
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRROR_CMD
•• DIRTY_P />• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION<•DR_HADR_br_>• • HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• PAMIĘĆ_ALOKACJA_EXT
• ONDEMAND_TASK_QUEUE
• PREEMPTIVE_HADR_LEASE_MEZ
• PREEMPTIVE_HADR_LEASE_MEZACJA_
• PREEMPTIVE_OS_COMOPS
• PREEMPTIVE_OS_CREATEFILE
• PREEMPTIVE_OS_CRYPTOPS
• PREEM PTive_OS_DeviceOps
• OPEMPEMPTIVE_OS_FILEOPS
• OPEMPEMPTIVE_OS_GEERERICOPS
• preemateve_os_libraryops
• prespive_os_pipeops
• preemptive_os_queryregistry
• enEptive_OS_VerifyTrust
• prepective_os_wesinging
PrespiTatherTather
• enEptive_os_verifyTrust
• prepective_os_witinging
PrespiTatherTatherThersing
PrespiteShter
PRZEDPOWIEDZIALNO. br />• PREEMPTIVE_SP_SERVER_DIAGNOSTICS
• PREEMPTIVE_XE_GETTARGETSTATE
• PWAIT_ALL_COMPONENTS_INITIALIZED
• PWAIT_DIRECTLOGCONSUMER_GETNEXT
• QDS_ASYNC_QUEUE
• QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP
• QDS_PERSIST_TASK_MAIN_LOOP_SLEEP
• QDS_SHUTDOWN_QUEUE
• REDO_THREAD_PENDING_WORK
• REQUEST_FOR_DEADLOCK_SEARCH
• RESOURCE_QUEUE
• SERVER_IDLE_CHECK
• SLEEP_BPOOL_FLUSH
• SLEEP_DBSTARTUP
•
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER_FLUSH
• SQLTRACE _INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• CZEKAJ_NA_ WYNIKI
• CZEKAJ_XTP_CKPT_CLOSE
• CZEKAJ_XTP_HOST_• CZEKAJ__br> br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Wskazówka: Program SQL Server rozpoczyna zbieranie danych DMV po uruchomieniu lub ponownym uruchomieniu. SQL Server automatycznie resetuje statystyki oczekiwania po ponownym uruchomieniu, a poniższe zapytanie wymusza zresetowanie statystyk oczekiwania od czasu ostatniego ponownego uruchomienia SQL Server:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Ponadto kluczową kwestią jest dokładność pomiaru statystyk oczekiwania. W tym momencie możemy rozważyć dwa podejścia:
• Zresetuj statystyki oczekiwania i przywołaj statystyki oczekiwania.
• Przechwyć dwie różne „statystyki czasu oczekiwania” i zmierz różnicę wartości.
Moim zdaniem przechwytywanie i przechowywanie statystyk oczekiwania dla dowolnego podejścia do tabeli historii jest lepsze niż inne. W tej metodzie możesz zmierzyć szczególnie interwał czasowy i nie stracić statystyk oczekiwania danych historycznych.
Teraz zrobimy próbkę przechwytywania statystyk oczekiwania i pokażemy przechwycone dane w Power BI z grafiką.
Stworzymy tabelę historii do przechowywania statystyk oczekiwania:
CREATE TABLE [dbo].[HistoryOfWaitStatistics]( [SQLStartTime] [datetime] NULL, [Dt] [datetime] NOT NULL, [WaitType] [nvarchar](60) NOT NULL, [WaitTimeSecond] [numeric](25, 6) NULL, [ResourcesWaitSecond] [numeric](25, 6) NULL, [SignalWaitSecond] [numeric](25, 6) NULL ) ON [PRIMARY]
Poniższy skrypt wstawia „statystyki oczekiwania” do tabeli historii. Ale musisz zaplanować to zapytanie w agencie SQL Server aby przechowywać tabelę historii:
DROP TABLE IF exists #eliminate_WS
CREATE TABLE #eliminate_WS (wait_type NVARCHAR(100));
INSERT INTO #eliminate_WS VALUES ('ASYNC_IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('CHECKPOINT_QUEUE');
INSERT INTO #eliminate_WS VALUES ('CHKPT');
INSERT INTO #eliminate_WS VALUES ('CXPACKET');
INSERT INTO #eliminate_WS VALUES ('DISKIO_SUSPEND');
INSERT INTO #eliminate_WS VALUES ('FT_IFTS_SCHEDULER_IDLE_WAIT');
INSERT INTO #eliminate_WS VALUES ('IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('KSOURCE_WAKEUP');
INSERT INTO #eliminate_WS VALUES ('LAZYWRITER_SLEEP');
INSERT INTO #eliminate_WS VALUES ('LOGBUFFER');
INSERT INTO #eliminate_WS VALUES ('LOGMGR_QUEUE');
INSERT INTO #eliminate_WS VALUES ('MISCELLANEOUS');
INSERT INTO #eliminate_WS VALUES ('PREEMPTIVE_XXX');
INSERT INTO #eliminate_WS VALUES ('REQUEST_FOR_DEADLOCK_SEARCH');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_QUERY_SEMAPHORE_COMPILE');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_SEMAPHORE');
INSERT INTO #eliminate_WS VALUES ('SOS_SCHEDULER_YIELD');
INSERT INTO #eliminate_WS VALUES ('SQLTRACE_BUFFER_FLUSH ');
INSERT INTO #eliminate_WS VALUES ('THREADPOOL');
INSERT INTO #eliminate_WS VALUES ('WRITELOG');
INSERT INTO #eliminate_WS VALUES ('XE_DISPATCHER_WAIT');
INSERT INTO #eliminate_WS VALUES ('XE_TIMER_EVENT');
INSERT INTO HistoryOfWaitStatistics
SELECT
(SELECT sqlserver_start_time FROM sys.dm_os_sys_info ) as SQLStartTime,GETDATE() AS Dt,Wait_type as WaitType,
wait_time_ms / 1000. AS WaitTimeSecond,
(wait_time_ms - signal_wait_time_ms)/1000. AS ResourcesWaitSecond,
signal_wait_time_ms/1000. AS SignalWaitSecond
FROM sys.dm_os_wait_stats
WHERE wait_type IN(SELECT wait_type FROM #eliminate_WS) Po zapisaniu danych historycznych otwieramy Power BI i rozwijamy nasz pulpit nawigacyjny statystyk oczekiwania.
Kliknij Pobierz dane i wybierz SQL Server :
Ustaw ustawienia połączenia, a następnie napisz zapytanie do instrukcji SQL (opcjonalnie, wymaga bazy danych) . Kliknij OK .
Kliknij Importuj z Marketplace
Znajdź Sparkline od OKViz komponent wizualny i Dodaj Power BI
Dodaj Sparkline do panelu projektu usługi Power BI oraz przeciągnij i upuść kolumny zestawu danych, jak na poniższym obrazku:
Dodaj dwa składniki tabeli do filtrowania:SQLStartTime i WaitType . Wreszcie panel powinien wyglądać tak:
Jak zdiagnozować problem z oczekiwaniem zasobów:
W tej sekcji omówimy metodologię i dyscyplinę diagnozowania problemów ze statystykami oczekiwania. W szczególności musimy ustalić jeden punkt dotyczący statystyk oczekiwania:po prostu określa główną strukturę problemu, ale nigdy nie podaje szczegółów. Z tego powodu musimy zbadać szczegóły i powody oczekiwania. Dlatego „statystyka oczekiwania” pozwala nam skierować nasze badania w tym kierunku. Następnie powinniśmy użyć innych narzędzi (PerfMon, Extended Events, narzędzia monitorujące innych firm itp.) i innych DMV, aby zdefiniować dokładne problemy.
Zakładając, że obserwujemy ASYNC_NETWORK_IO w SQL Server, to oczekiwanie na zasoby jest związane z wolnym połączeniem sieciowym od strony klienta do serwera. Ale te informacje nie pomagają w rozwiązaniu głównej przyczyny problemu, ponieważ możemy mieć kilka konfiguracji sieci między stroną serwera i klienta. W tym przykładzie musimy spojrzeć:
• Zapytania dotyczące dużych zestawów wyników
• Konfiguracje karty interfejsu sieciowego
• Ustawienia środowiska sieciowego pomiędzy stronami serwera a stroną klienta.
• Sprawdź przepustowość karty sieciowej.
Jak widać na przykładzie, musimy wykonać kilka zadań, aby zdefiniować dokładny problem. Statystyki oczekiwania nie wskazują celu problemu.
Wnioski
W tym poście omówiliśmy główną koncepcję dynamicznego widoku zarządzania sys.dm_os_wait_stats. Jednocześnie omówiliśmy prostotę użytkowania i istotne punkty, na które należy zwrócić uwagę.
Przydatne narzędzie:
dbForge Monitor – dodatek do Microsoft SQL Server Management Studio, który pozwala śledzić i analizować wydajność SQL Server.
