Come sapete, la principale responsabilità dell'amministratore del database risiede nel monitoraggio delle prestazioni di SQL Server e nell'intervenire in tempi determinati. Sul mercato sono disponibili diversi strumenti di monitoraggio delle prestazioni di SQL Server, ma a volte sono necessarie informazioni aggiuntive sulle prestazioni di SQL Server per diagnosticare e risolvere i problemi di prestazioni. Pertanto, è necessario disporre di informazioni sufficienti sulle viste a gestione dinamica di SQL Server per gestire i problemi relativi a SQL Server.
Dynamic Management View (DMV) è un concetto che ci aiuta a scoprire le metriche delle prestazioni di SQL Server Engine. DMV è stato annunciato per la prima volta nella versione di SQL Server 2005 e in seguito è continuato in tutte le versioni di SQL Server. In questo post parleremo di un particolare DMV il cui amministratore del database deve disporre di informazioni sufficienti. Questo è sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats supporta le metriche essenziali per la diagnosi dei problemi di prestazioni di SQL Server. In caso di problemi (CPU, memoria, I/O, Lock, Latch ecc.) in SQL Server Engine, i dati sys.dm_os_wait_stats ci guidano nella definizione del problema. Activity Monitor in SQL Server Management Studio include un pannello denominato "Risorsa in attesa ”. "Resource Waits" ottiene queste metriche da una procedura memorizzata speciale. Questo nome di procedura memorizzata temporanea è "#am_generate_waitstats ” e utilizza sys.dm_os_wait_stats. È possibile trovare questa procedura memorizzata temporanea in "tempdb". A questo punto, vorrei aggiungere alcune note sulla procedura memorizzata temporanea. Perché questo tipo di stored procedure non ha un utilizzo comune.
La procedura memorizzata temporanea non differisce dalle stored procedure permanenti. Ha due tipi:locale e globale come le tabelle temporanee. La stored procedure locale rimane attiva nella sessione corrente e viene eliminata dopo la chiusura della sessione. Può essere creato in questo modo:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
La stored procedure globale rimane inoltre attiva in tutte le sessioni e viene eliminata dopo la chiusura della sessione creata. La procedura memorizzata globale può essere creata come:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Suggerimento: Quando apriamo Activity Monitor, viene creato il #am_generate_waitstats stored procedure temporanee e la rilascia dopo la chiusura.
Ora esamineremo l'idea principale e i dettagli di sys.dm_os_wait_stats . La query seguente restituirà tutti i dati su SQL Server "Wait Statistics". Questa domanda è nella forma più pura. È scomodo rilevare problemi con tale modulo. Nelle sezioni seguenti troverai query più utili di sys.dm_os_wait_stats. Ora spiegheremo la descrizione delle colonne "Wait Statistics" di SQL Server:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
La colonna wait_type contiene la definizione o il nome delle statistiche di attesa. I dati della colonna wait_type sono significativi per noi perché la definizione delle statistiche di attesa che indica il motivo principale del problema. wait_tasks_count indica la frequenza del tipo di attesa che si è verificato in SQL Server.
wait_time_ms indica il tempo di attesa totale. L'unità di misura è un millisecondo.
max_wait_time_ms indica il tempo massimo di attesa.
signal_wait_time_ms è descritto in MSDN come "Differenza tra l'ora in cui è stato segnalato il thread in attesa e quando è iniziato a funzionare". Il valore particolarmente alto di questa colonna indica la pressione della CPU. Quindi la query è in attesa nella coda eseguibile ed è pronta per l'esecuzione, ma la CPU è occupata con altre query. Per questo motivo, la query è in attesa in coda. Quando la risorsa CPU è disponibile, la CPU riceverà una nuova query dalla coda eseguibile e inizierà l'elaborazione. In breve, possiamo descrivere signal_wait_time_ms come tempo di attesa nella coda eseguibile che è stato trasformato in eseguibile in esecuzione.
Suggerimento: Nella migliore pratica, le varie statistiche di attesa sono più importanti delle altre. Questi possono essere elencati come:
• PAGEIOLATCH_*
• REGISTRO SCRITTURA
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• PREVENTIVO_*
• PAGELATCH_*
Dai un'occhiata a Pinal Dave o Paul S. Randal in attesa di query statistiche. Hanno eliminato diversi tipi di statistiche di attesa nelle loro query. I seguenti tipi di attesa delle risorse possono essere eliminati in sys.dm_os_wait_stats domande:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_TRANSMITTER
• CHECKPOINT_QUEUE
• CHKPT
• CLR_AUTO_EVENT
• CLR_MANUAL_EVENT
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRROR_CMD
• DIRTY_PAGE_POLL
• DISPATCHER_QUEUE_SEMAPHORE
• />• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION
• HADR_LOGCAPTURE_WAIT
• HADR_NOTIFICATION_DEQUEUE
• HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
• PREEMPTIVE_HADR_LEASE_MECHANISM
• PREEMPTIVE_OS_AUTHENTICATIONOPS
_AUTHENTICATIONOPS
_AUTHENTICATIONOPS
• 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 PREEFILE_OS_J•WAIT_WAITFORSINGLE
• PREEMPTIVE_OS_WAITFORSINGLE
• PREEMPTIVE_OS_WAITFORSINGLE
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_DCOMSTARTUP
• SLEEP_MASTERDBREADY
• SLEEP_MASTERMDREADY
• 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
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT
• WAIT_XTP_OFFLINE_CKPT_NEW_LOG
_ITbr<• WAIT_XTP<• br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Suggerimento: SQL Server inizia a raccogliere dati DMV all'avvio o al riavvio. SQL Server reimposta automaticamente le statistiche di attesa al riavvio e la query seguente impone di reimpostare le statistiche di attesa dall'ultimo riavvio di SQL Server:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Inoltre, l'accuratezza della misurazione delle statistiche di attesa è il punto chiave. A questo punto possiamo considerare due approcci:
• Reimpostare le statistiche di attesa e ricordare le statistiche di attesa.
• Cattura due diverse "statistiche di attesa" e misura la differenza nei valori.
A mio parere, acquisire e archiviare le statistiche di attesa per qualsiasi approccio alla tabella della cronologia è meglio di altri. Con questo metodo, puoi misurare un intervallo di tempo particolare e non perdere le statistiche di attesa dei dati storici.
Ora faremo un esempio dell'acquisizione delle statistiche di attesa e mostreremo i dati acquisiti in Power BI con grafici.
Creeremo una tabella della cronologia per memorizzare le statistiche di attesa:
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]
Lo script seguente inserisce "statistiche di attesa" nella tabella della cronologia. Ma devi pianificare questa query in SQL Server Agent per memorizzare la tabella della cronologia:
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) Dopo che i dati storici sono stati archiviati, apriamo Power BI e sviluppiamo il nostro dashboard delle statistiche di attesa.
Fai clic su Ottieni dati e seleziona SQL Server :
Imposta le impostazioni di connessione, quindi scrivi la query in istruzione SQL (facoltativa, richiede un database) . Fai clic su OK .
Fai clic su Importa da Marketplace
Trova Sparkline di OKViz componente visivo e Aggiungi Power BI
Aggiungi Sparkline al pannello di progettazione di Power BI e trascina e rilascia le colonne del set di dati come nell'immagine seguente:
Aggiungi due componenti della tabella da filtrare:SQLStartTime e Tipo di attesa . Infine, la dashboard dovrebbe essere così:
Come diagnosticare il problema di attesa delle risorse:
In questa sezione, menzioneremo la metodologia e la disciplina per diagnosticare i problemi relativi alle statistiche di attesa. In particolare, dobbiamo capire un punto sulle statistiche di attesa:definisce semplicemente la struttura principale del problema ma non fornisce mai dettagli. Per questo motivo, dobbiamo ricercare i dettagli e le ragioni dell'attesa. Pertanto, "statistiche di attesa" ci consente di orientare la nostra ricerca in questa direzione. Successivamente, dovremmo utilizzare altri strumenti (PerfMon, Eventi estesi, strumenti di monitoraggio di terze parti, ecc.) e altri DMV per definire i problemi esatti.
Supponendo che osserviamo ASYNC_NETWORK_IO in SQL Server, questa attesa di risorse è correlata a una connessione di rete lenta da un client al lato server. Ma queste informazioni non aiutano a risolvere il motivo principale del problema perché potremmo avere diverse configurazioni di rete tra server e lato client. Per questo esempio dobbiamo guardare:
• Query di set di risultati di grandi dimensioni
• Configurazioni della scheda di interfaccia di rete
• Impostazioni dell'ambiente di rete tra il lato server e il lato client.
• Controllare la larghezza di banda della scheda di rete.
Come puoi vedere nell'esempio, abbiamo bisogno di completare alcune attività per definire il problema esatto. Le statistiche di attesa non indicano la destinazione del problema.
Conclusioni
In questo post abbiamo parlato del concetto principale della vista a gestione dinamica sys.dm_os_wait_stats. Allo stesso tempo, abbiamo discusso della semplicità di utilizzo e dei punti significativi, ai quali è necessario prestare attenzione.
Strumento utile:
dbForge Monitor:componente aggiuntivo per Microsoft SQL Server Management Studio che consente di monitorare e analizzare le prestazioni di SQL Server.
