Hovedanvendelse af sys.dm_os_wait

Som du ved, ligger databaseadministratorens hovedansvar i overvågningen af SQL Server-ydeevnen og at gribe ind på fastsat tid. Du kan finde adskillige værktøjer til overvågning af SQL Server-ydelse på markedet, men nogle gange har vi brug for yderligere oplysninger om SQL Server-ydeevne for at diagnosticere og fejlfinde ydeevneproblemerne. Så vi skal have nok information om SQL Server Dynamic Management Views til at håndtere problemer om SQL Server.

Dynamic Management View (DMV) er et koncept, der hjælper os med at opdage SQL Server Engine-ydelsesmålinger. DMV blev først annonceret i SQL Server 2005-versionen, og det fortsatte i alle versioner af SQL Server bagefter. I dette indlæg vil vi tale om bestemte DMV, hvis databaseadministrator skal have nok information. Dette er sys.dm_os_wait_stats .

sys.dm_os_wait_stats

sys.dm_os_wait_stats understøtter væsentlige målinger til diagnosticering af SQL Server-ydeevneproblemer. Hvis du har nogle problemer (CPU, Memory, I/O, Lock, Latch osv.) i SQL Server Engine, guider sys.dm_os_wait_stats data os til at definere problemet. Aktivitetsovervågning i SQL Server Management Studio indeholder et panel med navnet "Resource Waits ”. "Resource Waits" henter disse metrics fra en speciel lagret procedure. Dette midlertidige lagrede procedurenavn er "#am_generate_waitstats ” og den bruger sys.dm_os_wait_stats. Du kan finde denne midlertidigt lagrede procedure i "tempdb". På dette tidspunkt vil jeg gerne tilføje nogle bemærkninger om den midlertidige lagrede procedure. Fordi denne type lagret procedure ikke har en almindelig brug.

Den midlertidigt lagrede procedure adskiller sig ikke fra permanente lagrede procedurer. Det har to typer:lokale og globale som midlertidige tabeller. Lokal lagret procedure forbliver aktiv i den aktuelle session og slettes, når sessionen lukkes. Det kan oprettes sådan her:

CREATE PROCEDURE #LocalTestSP
AS
PRINT Hello Local Stored Procedure

Den globale lagrede procedure forbliver også aktiv i alle sessioner og forsvinder efter den oprettede session lukker. Den globale lagrede procedure kan oprettes som:

CREATE PROCEDURE ##GlobalTestSP
AS
PRINT Hello Global Stored Procedure

Tip: Når vi åbner aktivitetsovervågningen, opretter den #am_generate_waitstats midlertidigt gemt procedure og dropper den efter lukningen.

Nu vil vi se på hovedideen og detaljerne i sys.dm_os_wait_stats . Nedenstående forespørgsel vil returnere alle data om SQL Server "Ventstatistik". Denne forespørgsel er i den reneste form. Det er ubelejligt at opdage problemer med en sådan form. I de følgende afsnit finder du flere nyttige forespørgsler end sys.dm_os_wait_stats. Nu vil vi forklare beskrivelsen af SQL Server "Vent statistik"-kolonnerne:

SELECT *
FROM sys.dm_os_wait_stats
ORDER BY wait_time_ms DESC

Kolonnen wait_type indeholder definitionen eller navnet på ventestatistikker. wait_type kolonnedata er vigtige for os, fordi definitionen af ventestatistikker, der angiver hovedårsagen til problemet. waiting_tasks_count angiver frekvensen af ventetypen, der fandt sted i SQL Server.

wait_time_ms angiver den samlede ventetid. Måleenheden er et millisekund.

max_wait_time_ms angiver den maksimale ventetid.

signal_wait_time_ms beskrives i MSDN som "Forskellen mellem det tidspunkt, hvor den ventende tråd blev signaleret, og hvornår den begyndte at køre". Særlig høj værdi af denne kolonne tegner til CPU-tryk. Så forespørgslen venter i køen, der kan køres og er klar til at køre, men CPU'en er optaget med andre forespørgsler. Af denne grund venter forespørgslen i køen. Når CPU-ressourcen er tilgængelig, vil CPU få en ny forespørgsel fra køen, der kan køres, og vil begynde at behandle. Kort sagt kan vi beskrive signal_wait_time_ms som ventetid i køen, der kan køres, hvilket er tilstand, der kan køres til at køre.

Tip: I bedste praksis er flere ventestatistikker vigtigst end de andre. Disse kan angives som:

• PAGEIOLATCH_*
• WRITELOG
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• PREEMPTIVE_*
• PAGELATCH_*

Tag et kig på Pinal Dave eller Paul S. Randal, vent på statistikforespørgsler. De eliminerede flere typer ventestatistik i deres forespørgsler. Nedenstående ressourceventetyper kan elimineres i sys.dm_os_wait_stats forespørgsler:

• MÆGLER_EVENTHANDLER
• MÆGLER_MODTAGER_WAITFOR
• MÆGLER_OPGAVE_STOP
• MÆGLER_TO_FLUSH
• MÆGLER_SENDER
• CHECKPOINT_QUEUE
• CHKPT
• CLRENT_AUTO-MAN
• CLRENT_AUTO
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRRORING_CMDIRTY_
• DBMIRRORING_CMDIRTY_
/>• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION INGENINING

• HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
• PREEMPTIVE_MEMOTION_AUTHRETION /
• PREEMPTIVE_MEADIZATION_AUTHREVING /
• PREEMPTIVE_OS_COMOPS
• PREEMPTIVE_OS_CREATEFILE
• PREEMPTIVE_OS_CRYPTOPS
• PREEM PTIVE_OS_DEVICEOPS
• Preemptive_OS_Fileops
• Preemptive_os_genericops
• Preemptive_os_Libraryops
• Preemptive_os_pipeops
• Preemptive_os_QueryRegistry
• Preforemptive_S_VerifyTrust
• Preemptive_S_QueryRegistry
• Preemptive_OS_VerifyTrust
• Preemptive_WAIPE 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_
•START SLEEP_DBSTARTUP_
•START SLEEP_DBSTARTUP_
• SLEEP_DBSTARTUP_
•START SLEEP_DB SLEEP_MASTERMDREADY
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER_FLUSHTRA• / SQLTRACE_BUFFER_FLUSHTRA _INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• WAIT_POR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_XITY /• WAIT_XTP_XITY/ br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF

Tip: SQL-serveren begynder at indsamle DMV-data, når den starter eller genstarter. SQL Server nulstillede automatisk ventestatistikken, når den genstartede, og nedenstående forespørgsel tvinger til at nulstille ventestatistikken, siden SQL Server sidst blev genstartet:

DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR)

Derudover er målenøjagtigheden af ventestatistikker nøglepunktet. På dette tidspunkt kan vi overveje to tilgange:

• Nulstil ventestatistikken og genskab ventestatistikken.

• Optag to forskellige "tidsventestatistikker", og mål forskellen i værdier.

Efter min mening er det bedre at fange og gemme ventestatistikker for enhver historiktabeltilgang end andre. I denne metode kan du måle særligt tidsinterval og ikke miste ventestatistikker over historiske data.

Nu vil vi lave et eksempel på registrering af ventestatistikker og vise opsamlede data i Power BI med grafik.

Vi opretter en historiktabel til at gemme ventestatistikker:

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]

Nedenstående script indsætter "ventestatistikker" i historiktabellen. Men du skal planlægge denne forespørgsel i SQL Server Agent for at gemme historiktabel:

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)

Når de historiske data er blevet gemt, åbner vi Power BI og udvikler vores ventestatistik-dashboard.

Klik på Hent data og vælg SQL-server :

Indstil forbindelsesindstillingerne, og skriv derefter forespørgslen til SQL-sætning (valgfrit, kræver en database) . Klik på OK .

Klik på Importer fra markedsplads

Find Sparkline af OKViz visuel komponent og Tilføj Power BI

Tilføj Sparkline til Power BI-designpanelet, og træk og slip datasætkolonner som på billedet nedenfor:

Tilføj to tabelkomponenter til filtrering:SQLStartTime og WaitType . Endelig skal dashboardet være sådan her:

Sådan diagnosticeres ressourceventeproblem:

I dette afsnit vil vi nævne metodologien og disciplinen til diagnosticering af ventestatistikproblemer. Især er vi nødt til at finde ud af et punkt om ventestatistikker:det definerer simpelthen hovedstrukturen af problemet, men giver aldrig detaljer. Af denne grund er vi nødt til at undersøge ventedetaljer og årsager. Derfor giver "ventestatistikker" os mulighed for at vende vores forskning i denne retning. Derefter bør vi bruge andre værktøjer (PerfMon, Extended Events, 3. parts overvågningsværktøjer osv.) og andre DMV'er til at definere nøjagtige problemer.

Hvis vi antager, at vi observerer ASYNC_NETWORK_IO i SQL Server, er denne ressourcevent relateret til langsom netværksforbindelse fra en klient til serversiden. Men disse oplysninger hjælper ikke med at fejlfinde hovedårsagen til problemet, fordi vi kan have flere netværkskonfigurationer mellem server og klientside. For dette eksempel skal vi se:

• Store resultatsæt forespørgsler

• Konfigurationer af netværksinterfacekort

• Indstillinger af netværksmiljø mellem serversider til klientsiden.

• Tjek netværksadapterens båndbredde.

Som du kan se i eksemplet, skal vi udføre nogle opgaver for at definere det nøjagtige problem. Ventestatistikker angiver ikke målet for problemet.

Konklusioner

I dette indlæg talte vi om hovedkonceptet for den dynamiske administrationsvisning sys.dm_os_wait_stats. Samtidig diskuterede vi enkelheden i brugen og væsentlige punkter, hvor det er nødvendigt at være opmærksom.

Nyttigt værktøj:

dbForge Monitor – tilføjelsesmodul til Microsoft SQL Server Management Studio, der giver dig mulighed for at spore og analysere SQL Server-ydeevne.

Hovedanvendelse af sys.dm_os_wait_stats

sys.dm_os_wait_stats

Sådan diagnosticeres ressourceventeproblem:

Konklusioner

Nyttigt værktøj: