Som ni vet ligger databasadministratörens huvudansvar i övervakningen av SQL Server-prestanda och att ingripa i bestämd tid. Du kan hitta flera verktyg för SQL Server-prestandaövervakning på marknaden, men ibland behöver vi ytterligare information om SQL Server-prestanda för att diagnostisera och felsöka prestandaproblemen. Så vi måste ha tillräckligt med information om SQL Server Dynamic Management Views för att hantera problem om SQL Server.
Dynamic Management View (DMV) är ett koncept som hjälper oss att upptäcka prestandamått för SQL Server Engine. DMV tillkännagavs först i SQL Server 2005-versionen och det fortsatte i alla versioner av SQL Server efteråt. I det här inlägget kommer vi att prata om just DMV vars databasadministratör måste ha tillräckligt med information. Det här är sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats stöder viktiga mätvärden för att diagnostisera SQL Server-prestandaproblem. Om du har några problem (CPU, Memory, I/O, Lock, Latch etc.) i SQL Server Engine, guidar sys.dm_os_wait_stats data oss för att definiera problemet. Activity Monitor i SQL Server Management Studio innehåller en panel som heter "Resource Waits ”. "Resource Waits" hämtar dessa mätvärden från en speciell lagrad procedur. Detta temporärt lagrade procedurnamn är "#am_generate_waitstats ” och den använder sys.dm_os_wait_stats. Du kan hitta denna tillfälligt lagrade procedur i "tempdb". Vid det här laget skulle jag vilja lägga till några anteckningar om den tillfälligt lagrade proceduren. Eftersom denna typ av lagrad procedur inte har en vanlig användning.
Den tillfälligt lagrade proceduren skiljer sig inte från permanent lagrade procedurer. Den har två typer:lokala och globala som tillfälliga tabeller. Lokalt lagrad procedur förblir aktiv i den aktuella sessionen och tas bort efter att sessionen stängs. Det kan skapas så här:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
Den globala lagrade proceduren förblir också aktiv i alla sessioner och försvinner efter att den skapade sessionen stängs. Den globala lagrade proceduren kan skapas som:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Tips: När vi öppnar Activity Monitor skapar den #am_generate_waitstats tillfälligt lagrad procedur och släpper den efter stängningen.
Nu ska vi undersöka huvudidén och detaljerna för sys.dm_os_wait_stats . Frågan nedan kommer att returnera all data om SQL Server "Vänta statistik". Denna fråga är i den renaste formen. Det är obekvämt att upptäcka problem med en sådan form. I följande avsnitt hittar du fler användbara frågor än sys.dm_os_wait_stats. Nu kommer vi att förklara beskrivningen av SQL Server-kolumnerna "Vänta statistik":
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
Kolumnen wait_type innehåller definitionen eller namnet på väntestatistik. wait_type kolumndata är betydande för oss eftersom definitionen av väntestatistik som indikerar huvudorsaken till problemet. waiting_tasks_count indikerar frekvensen av väntetyp som inträffade i SQL Server.
väntetid_ms anger den totala väntetiden. Måttenheten är en millisekund.
max_wait_time_ms anger maximal väntetid.
signal_wait_time_ms beskrivs i MSDN som "Skillnaden mellan den tid då den väntande tråden signalerades och när den började köras". Speciellt högt värde på denna kolumn tecken på CPU-tryck. Så frågan väntar i den körbara kön och redo att köras men CPU är upptagen med andra frågor. Av denna anledning väntar frågan i kön. När CPU-resursen är tillgänglig kommer CPU att få en ny fråga från den körbara kön och börjar bearbeta. Kortfattat kan vi beskriva signal_wait_time_ms som väntetid i den körbara kön som är tillståndet som är körbar till att köras.
Tips: I bästa praxis är statistiken över flera väntetider viktigast än de andra. Dessa kan listas som:
• PAGEIOLATCH_*
• WRITELOG
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• PREEMPTIVE_*
• PAGELATCH_*
Ta en titt på Pinal Dave eller Paul S. Randal vänta på statistikfrågor. De eliminerade flera typer av väntestatistik i sina frågor. Nedanstående resursväntetyper kan elimineras i sys.dm_os_wait_stats frågor:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• MROKER_TASK_STOP
• BROKER_TO_FLUSH
• MÄKLAR_SÄNDARE
• CHECKPOINT_QUEUE
• CHKPT
• CLRENT_AUTO /_EV CLRENT_AUTO />• 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_WAIT /
• HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
• PREEMPTIVE_METOSIVE_AUTHREMONT /
(PREEMPTIVE_METOSIVE_AUTHREMONT_MEMOSIVE_
)
• 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
• PREEMPTIVE_OS_VERIFYTRUST
• PREEMPTIVE_OS_WAITFORSINGLEOBJECT
• PREEMPTIVE_OS_WRITEFILEGATHER
• 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__DEADLOCK_SEARCH
• RESOURCE_QUEUE
• SERVER_IDLE_CHECK
• SLEEP_BPOOL_FLUSH
• SLEEP_DBSTARTUP__DEADLOCK_SEARCH
• SLEEP_DBSTARTUP_BR />• SLEEP_DBSTARTUP_
• SLEEP_DBSTARTUP_BR />• SLEEP_DBSTARTUP_BR />• SLEEP_DBSTARTUP_BR />• SLEEP_DBSTARTUP_B /> 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_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_XITY /• WAIT_XTP_X_WIT_WAIT_XTP_X_VÄNTA /> br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Tips: SQL Server börjar samla in DMV-data när den startar eller startar om. SQL Server återställer automatiskt väntestatistiken när den startade om och frågan nedan tvingar återställa väntestatistiken sedan SQL Server senast startade om:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Dessutom är mätnoggrannheten för väntestatistik nyckelpunkten. Vid denna tidpunkt kan vi överväga två tillvägagångssätt:
• Återställ väntestatistiken och hämta väntestatistiken.
• Fånga två olika "tidsväntestatistik" och mäta skillnaden i värden.
Enligt min åsikt är det bättre att fånga och lagra väntestatistik för alla historiktabeller än andra. Med den här metoden kan du mäta särskilt tidsintervall och inte förlora väntestatistik över historiska data.
Nu kommer vi att göra ett urval av insamlingen av väntestatistik och visa infångad data i Power BI med grafik.
Vi kommer att skapa en historiktabell för att lagra väntestatistik:
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]
Skriptet nedan infogar "väntestatistik" i historiktabellen. Men du måste schemalägga den här frågan i SQL Server Agent för att lagra historiktabell:
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) Efter att den historiska informationen har lagrats öppnar vi Power BI och utvecklar vår väntestatistik-instrumentpanel.
Klicka på Hämta data och välj SQL-server :
Ställ in anslutningsinställningarna och skriv sedan frågan till SQL-sats (valfritt, kräver en databas) . Klicka på OK .
Klicka på Importera från Marketplace
Hitta Sparkline av OKViz visuell komponent och Lägg till Power BI
Lägg till Sparkline i Power BI-designpanelen och dra och släpp datauppsättningskolumner som i bilden nedan:
Lägg till två tabellkomponenter för att filtrera:SQLStartTime och WaitType . Slutligen bör instrumentpanelen se ut så här:
Hur man diagnostiserar resursvänteproblem:
I det här avsnittet kommer vi att nämna metodiken och disciplinen för att diagnostisera väntestatistikproblem. Särskilt måste vi ta reda på en punkt om väntestatistik:den definierar helt enkelt huvudstrukturen för problemet men ger aldrig detaljer. Av denna anledning måste vi undersöka vänta detaljer och skäl. Därför tillåter "väntestatistik" oss att vända vår forskning i denna riktning. Därefter bör vi använda andra verktyg (PerfMon, Extended Events, övervakningsverktyg från tredje part, etc.) och andra DMV:er för att definiera exakta problem.
Om vi antar att vi observerar ASYNC_NETWORK_IO i SQL Server, är denna resursväntan relaterad till långsam nätverksanslutning från en klient till serversidan. Men den här informationen hjälper inte till att felsöka huvudorsaken till problemet eftersom vi kan ha flera nätverkskonfigurationer mellan server- och klientsidan. För det här exemplet måste vi titta på:
• Stora resultatuppsättningar frågor
• Konfigurationer för nätverkskort
• Inställningar av nätverksmiljö mellan serversidorna till klientsidan.
• Kontrollera nätverksadapterns bandbredd.
Som du kan se i exemplet måste vi slutföra några uppgifter för att definiera det exakta problemet. Väntestatistik indikerar inte målet för problemet.
Slutsatser
I det här inlägget pratade vi om huvudkonceptet för den dynamiska hanteringsvyn sys.dm_os_wait_stats. Samtidigt diskuterade vi enkelheten i användningen och viktiga punkter där det är nödvändigt att vara uppmärksam.
Användbart verktyg:
dbForge Monitor – tillägg för Microsoft SQL Server Management Studio som låter dig spåra och analysera SQL Server-prestanda.