Zoals u weet, ligt de belangrijkste verantwoordelijkheid van de databasebeheerder bij het bewaken van de SQL Server-prestaties en het ingrijpen binnen een bepaalde tijd. U kunt verschillende hulpprogramma's voor het bewaken van de prestaties van SQL Server op de markt vinden, maar soms hebben we aanvullende informatie over de prestaties van SQL Server nodig om de prestatieproblemen te diagnosticeren en op te lossen. We moeten dus voldoende informatie hebben over SQL Server Dynamic Management Views om problemen met SQL Server op te lossen.
Dynamic Management View (DMV) is een concept dat ons helpt de prestatiestatistieken van SQL Server Engine te ontdekken. DMV werd voor het eerst aangekondigd in de versie van SQL Server 2005 en ging daarna door in alle versies van SQL Server. In dit bericht zullen we het hebben over bepaalde DMV waarvan de databasebeheerder voldoende informatie moet hebben. Dit is sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats ondersteunt essentiële meetgegevens voor het diagnosticeren van prestatieproblemen met SQL Server. Als u problemen heeft (CPU, geheugen, I/O, vergrendeling, vergrendeling enz.) in SQL Server Engine, helpen sys.dm_os_wait_stats-gegevens ons om het probleem te definiëren. Activity Monitor in SQL Server Management Studio bevat een paneel met de naam "Resource Waits ”. "Resource Waits" haalt deze statistieken uit een speciale opgeslagen procedure. De naam van deze tijdelijke opgeslagen procedure is "#am_generate_waitstats ” en het gebruikt sys.dm_os_wait_stats. U kunt deze tijdelijk opgeslagen procedure vinden in "tempdb". Op dit punt zou ik enkele opmerkingen willen toevoegen over de tijdelijk opgeslagen procedure. Omdat dit type opgeslagen procedure niet algemeen wordt gebruikt.
De tijdelijk opgeslagen procedure verschilt niet van permanent opgeslagen procedures. Het heeft twee soorten:lokale en globale, zoals tijdelijke tabellen. Lokaal opgeslagen procedure blijft actief in de huidige sessie en wordt verwijderd nadat de sessie is gesloten. Het kan als volgt worden gemaakt:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
De globale opgeslagen procedure blijft ook actief in alle sessies en valt weg nadat de gemaakte sessie is gesloten. De globale opgeslagen procedure kan worden aangemaakt als:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Tip: Als we de Activity Monitor openen, wordt de #am_generate_waitstats gemaakt tijdelijke opgeslagen procedure en laat deze vallen na het sluiten.
Nu gaan we kijken naar het hoofdidee en de details van sys.dm_os_wait_stats . De onderstaande query retourneert alle gegevens over SQL Server "Wachtstatistieken". Deze vraag is in de puurste vorm. Het is onhandig om problemen met een dergelijk formulier te detecteren. In de volgende secties vindt u meer nuttige vragen dan sys.dm_os_wait_stats. Nu zullen we de beschrijving van de SQL Server “Wachtstatistieken” kolommen uitleggen:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
De kolom wait_type bevat de definitie of naam van wachtstatistieken. wait_type kolomgegevens zijn belangrijk voor ons omdat de definitie van wachtstatistieken de belangrijkste reden voor het probleem aangeeft. wait_tasks_count geeft de frequentie van het type wacht aan in SQL Server.
wait_time_ms geeft de totale wachttijd aan. De maateenheid is een milliseconde.
max_wait_time_ms geeft de maximale wachttijd aan.
signal_wait_time_ms wordt in MSDN beschreven als "Verschil tussen de tijd dat de wachtende thread werd gesignaleerd en wanneer deze begon te lopen". Vooral hoge waarde van deze kolom wijst op CPU-druk. Dus de query wacht in de uitvoerbare wachtrij en is klaar om te worden uitgevoerd, maar de CPU is bezig met andere query's. Om deze reden staat de query in de wachtrij te wachten. Wanneer de CPU-bron beschikbaar is, krijgt de CPU een nieuwe query van de uitvoerbare wachtrij en begint de verwerking. In het kort kunnen we signal_wait_time_ms . beschrijven als wachttijd in de uitvoerbare wachtrij die van de staat is, draai uitvoerbaar naar actief.
Tip: In de beste praktijk zijn de verschillende wachtstatistieken belangrijker dan de andere. Deze kunnen worden weergegeven als:
• PAGEIOLATCH_*
• SCHRIJFLOG
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• PREEMPTIVE_*
• PAGELATCH_*
Kijk eens naar de Pinal Dave of Paul S. Randal die wacht op statistische vragen. Ze hebben verschillende typen wachtstatistieken in hun zoekopdrachten geëlimineerd. De onderstaande typen wachten op resources kunnen worden geëlimineerd in sys.dm_os_wait_stats vragen:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_TRANSMITTER
• CHECKPOINT_QUEUE
• CHKPT
• TLR_AUTO_EVENH
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_CHUE
• DBMIRROR_WORKER_CHUE
• DBMIRRORING_CMDTYbr />• DIROR />• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION
• CAP HADR_IT • HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
• PRESMPTIVE_HADRNILEASE_
• PRESMPTIVE_HADRNILEASE_
•
• PREEMPTIVE_OS_COMOPS
• PREEMPTIVE_OS_CREATEFILE
• PREEMPTIVE_OS_CRYPTOPS
• PREEM Ptive_os_deviceops
• preemptive_os_fileops
• preemptive_os_genericops
• premptive_os_libraryop 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
• START
• SLEEP_D>COM SLEEP_MASTERMDREADY
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER_FLUSH SQL _INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Tip: SQL Server begint DMV-gegevens te verzamelen wanneer deze start of opnieuw wordt opgestart. SQL Server reset automatisch de wachtstatistieken wanneer het opnieuw wordt opgestart en de onderstaande query dwingt om de wachtstatistieken opnieuw in te stellen sinds SQL Server voor het laatst opnieuw is opgestart:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Bovendien is de meetnauwkeurigheid van wachtstatistieken het belangrijkste punt. Op dit punt kunnen we twee benaderingen overwegen:
• Reset de wachtstatistieken en onthoud de wachtstatistieken.
• Leg twee verschillende "tijdwachtstatistieken" vast en meet het verschil in waarden.
Naar mijn mening is het vastleggen en opslaan van wachtstatistieken voor elke benadering met een geschiedenistabel beter dan andere. Met deze methode kunt u een bijzonder tijdsinterval meten en verliest u geen wachtstatistieken van historische gegevens.
Nu zullen we een voorbeeld maken van het vastleggen van wachtstatistieken en vastgelegde gegevens in Power BI met afbeeldingen weergeven.
We zullen een geschiedenistabel maken om wachtstatistieken op te slaan:
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]
Het onderstaande script voegt "wachtstatistieken" toe aan de geschiedenistabel. Maar u moet deze query plannen in SQL Server Agent om de geschiedenistabel op te slaan:
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) Nadat de historische gegevens zijn opgeslagen, openen we Power BI en ontwikkelen we ons dashboard met wachtstatistieken.
Klik op Gegevens ophalen en selecteer SQL Server :
Stel de verbindingsinstellingen in en schrijf de query vervolgens naar SQL-instructie (optioneel, vereist een database) . Klik op OK .
Klik op Importeren uit Marketplace
Zoek Sparkline van OKViz visuele component en Toevoegen Power BI
Voeg Sparkline toe aan het Power BI-ontwerppaneel en versleep de kolommen met gegevenssets zoals in de onderstaande afbeelding:
Voeg twee tabelcomponenten toe om te filteren:SQLStartTime en Wachttype . Ten slotte zou het dashboard er zo uit moeten zien:
Hoe een probleem met wachten op hulpbron te diagnosticeren:
In deze sectie zullen we de methodologie en discipline vermelden voor het diagnosticeren van problemen met wachtstatistieken. We moeten in het bijzonder één punt bedenken over wachtstatistieken:het definieert eenvoudig de hoofdstructuur van het probleem, maar geeft nooit details. Om deze reden moeten we wachtdetails en redenen onderzoeken. Daarom stellen "wachtstatistieken" ons in staat ons onderzoek in deze richting te sturen. Daarna moeten we andere tools (PerfMon, Extended Events, monitoringtools van derden, enz.) en andere DMV's gebruiken om exacte problemen te definiëren.
Ervan uitgaande dat we ASYNC_NETWORK_IO in SQL Server waarnemen, is deze resource wait gerelateerd aan een trage netwerkverbinding van een client naar een server. Maar deze informatie helpt niet om de belangrijkste reden van het probleem op te lossen, omdat we mogelijk verschillende netwerkconfiguraties hebben tussen server en client. Voor dit voorbeeld moeten we kijken:
• Zoekopdrachten met grote resultatensets
• Configuraties van netwerkinterfacekaarten
• Instellingen van de netwerkomgeving tussen serverzijden en clientzijde.
• Controleer de bandbreedte van de netwerkadapter.
Zoals u in het voorbeeld kunt zien, moeten we enkele taken uitvoeren om het exacte probleem te definiëren. Wachtstatistieken geven niet het doel van het probleem aan.
Conclusies
In dit bericht hebben we het gehad over het hoofdconcept van de dynamische beheerweergave sys.dm_os_wait_stats. Tegelijkertijd bespraken we de eenvoud van gebruik en belangrijke punten waarop moet worden gelet.
Handig hulpmiddel:
dbForge Monitor – add-in voor Microsoft SQL Server Management Studio waarmee u de prestaties van SQL Server kunt volgen en analyseren.