Comme vous le savez, la principale responsabilité de l'administrateur de la base de données réside dans le suivi des performances de SQL Server et dans l'intervention dans un temps déterminé. Vous pouvez trouver plusieurs outils de surveillance des performances de SQL Server sur le marché, mais nous avons parfois besoin d'informations supplémentaires sur les performances de SQL Server pour diagnostiquer et résoudre les problèmes de performances. Nous devons donc disposer de suffisamment d'informations sur les vues de gestion dynamique de SQL Server pour gérer les problèmes liés à SQL Server.
Dynamic Management View (DMV) est un concept qui nous aide à découvrir les mesures de performances de SQL Server Engine. DMV a été annoncé pour la première fois dans la version SQL Server 2005 et il s'est poursuivi dans toutes les versions de SQL Server par la suite. Dans cet article, nous parlerons notamment de DMV dont l'administrateur de la base de données doit disposer de suffisamment d'informations. C'est sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats prend en charge les métriques essentielles pour diagnostiquer les problèmes de performances de SQL Server. Si vous rencontrez des problèmes (CPU, mémoire, E/S, verrouillage, verrouillage, etc.) dans SQL Server Engine, les données sys.dm_os_wait_stats nous guident pour définir le problème. Le moniteur d'activité dans SQL Server Management Studio inclut un panneau nommé "Resource Waits ”. "Resource Waits" obtient ces métriques à partir d'une procédure stockée spéciale. Ce nom de procédure stockée temporaire est "#am_generate_waitstats ” et il utilise sys.dm_os_wait_stats. Vous pouvez trouver cette procédure stockée temporaire dans "tempdb". À ce stade, je voudrais ajouter quelques notes sur la procédure stockée temporaire. Car ce type de procédure stockée n'a pas d'usage courant.
La procédure stockée temporaire ne diffère pas des procédures stockées permanentes. Il a deux types :local et global comme les tables temporaires. La procédure stockée locale reste active dans la session en cours et est supprimée après la fermeture de la session. Il peut être créé comme ceci :
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
La procédure stockée globale reste également active dans toutes les sessions et supprimée après la fermeture de la session créée. La procédure stockée globale peut être créée comme :
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Astuce : Lorsque nous ouvrons le moniteur d'activité, il crée les #am_generate_waitstats procédure stockée temporaire et la supprime après la fermeture.
Nous allons maintenant examiner l'idée principale et les détails de sys.dm_os_wait_stats . La requête ci-dessous renverra toutes les données sur les "statistiques d'attente" de SQL Server. Cette requête est dans la forme la plus pure. Il n'est pas pratique de détecter les problèmes avec un tel formulaire. Dans les sections suivantes, vous trouverez des requêtes plus utiles que sys.dm_os_wait_stats. Nous allons maintenant expliquer la description des colonnes "Statistiques d'attente" de SQL Server :
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
La colonne wait_type contient la définition ou le nom des statistiques d'attente. Les données de la colonne wait_type sont importantes pour nous car la définition des statistiques d'attente indique la principale raison du problème. wait_tasks_count indique la fréquence du type d'attente survenu dans SQL Server.
wait_time_ms indique le temps d'attente total. L'unité de mesure est la milliseconde.
max_wait_time_ms indique le temps d'attente maximum.
signal_wait_time_ms est décrit dans MSDN comme "Différence entre le moment où le thread en attente a été signalé et le moment où il a commencé à s'exécuter". La valeur particulièrement élevée de cette colonne signale la pression du processeur. Ainsi, la requête attend dans la file d'attente exécutable et est prête à être exécutée, mais le processeur est occupé par d'autres requêtes. Pour cette raison, la requête est en attente dans la file d'attente. Lorsque la ressource CPU sera disponible, la CPU obtiendra une nouvelle requête de la file d'attente exécutable et commencera le traitement. En bref, nous pouvons décrire signal_wait_time_ms comme temps d'attente dans la file d'attente exécutable qui est à l'état de devenir exécutable en exécution.
Astuce : Dans les meilleures pratiques, les différentes statistiques d'attente sont plus importantes que les autres. Ceux-ci peuvent être répertoriés comme :
• PAGEIOLATCH_*
• WRITELOG
• ASYNC_NETWORK_IO
• CXPACKET
• Processeur
• LCK_M_*
• PREEMPTIVE_*
• PAGELATCH_*
Jetez un oeil à l'attente de Pinal Dave ou Paul S. Randal pour les requêtes statistiques. Ils ont éliminé plusieurs types de statistiques d'attente dans leurs requêtes. Les types d'attente de ressource ci-dessous peuvent être éliminés dans sys.dm_os_wait_stats requêtes :
• 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
• DBMIRRORING_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
• PREEMPTIVE_OS_AUTHORIZATION
• 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_WAITFORSINGLEOBJECT
• PREEMPTIVE_OS_WAITFORSINGLEOBJECT 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
• WAIT_XTP_RECOVERY
• WAIT_XTP_RECOVERY
br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Astuce : SQL Server commence à collecter les données DMV lorsqu'il démarre ou redémarre. SQL Server réinitialise automatiquement les statistiques d'attente lors de son redémarrage et la requête ci-dessous oblige à réinitialiser les statistiques d'attente depuis le dernier redémarrage de SQL Server :
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) De plus, la précision de la mesure des statistiques d'attente est le point clé. À ce stade, nous pouvons envisager deux approches :
• Réinitialiser les statistiques d'attente et rappeler les statistiques d'attente.
• Capturez deux "statistiques de temps d'attente" différentes et mesurez la différence de valeurs.
À mon avis, la capture et le stockage des statistiques d'attente pour toute approche de table d'historique sont meilleures que les autres. Dans cette méthode, vous pouvez mesurer un intervalle de temps particulier et ne pas perdre les statistiques d'attente des données historiques.
Nous allons maintenant créer un exemple de capture des statistiques d'attente et afficher les données capturées dans Power BI avec des graphiques.
Nous allons créer une table d'historique pour stocker les statistiques d'attente :
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]
Le script ci-dessous insère des "statistiques d'attente" dans la table d'historique. Mais vous devez planifier cette requête dans SQL Server Agent pour stocker la table d'historique :
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) Une fois les données historiques stockées, nous ouvrons Power BI et développons notre tableau de bord des statistiques d'attente.
Cliquez sur Obtenir des données et sélectionnez SQL Server :
Définissez les paramètres de connexion, puis écrivez la requête dans l'instruction SQL (facultatif, nécessite une base de données) . Cliquez sur OK .
Cliquez sur Importer depuis Marketplace
Trouver Sparkline par OKViz composant visuel et Ajouter Power BI
Ajoutez Sparkline au panneau de conception Power BI et faites glisser et déposez les colonnes de l'ensemble de données comme dans l'image ci-dessous :
Ajoutez deux composants de table pour filtrer :SQLStartTime et WaitType . Enfin, le tableau de bord devrait ressembler à ceci :
Comment diagnostiquer un problème d'attente de ressources :
Dans cette section, nous mentionnerons la méthodologie et la discipline de diagnostic des problèmes de statistiques d'attente. En particulier, nous devons comprendre un point concernant les statistiques d'attente :elles définissent simplement la structure principale du problème, mais ne donnent jamais de détails. Pour cette raison, nous devons rechercher les détails et les raisons de l'attente. Par conséquent, les « statistiques d'attente » nous permettent d'orienter nos recherches dans cette direction. Après, nous devrions utiliser d'autres outils (PerfMon, Extended Events, outils de surveillance tiers, etc.) et d'autres DMV pour définir les problèmes exacts.
En supposant que nous observons ASYNC_NETWORK_IO dans SQL Server, cette attente de ressource est liée à une connexion réseau lente d'un client à un côté serveur. Mais ces informations ne permettent pas de dépanner la raison principale du problème car nous pouvons avoir plusieurs configurations réseau entre le côté serveur et le côté client. Pour cet exemple, nous devons regarder :
• Requêtes d'ensembles de résultats volumineux
• Configurations de la carte d'interface réseau
• Paramètres de l'environnement réseau entre les côtés serveur et côté client.
• Vérifiez la bande passante de la carte réseau.
Comme vous pouvez le voir dans l'exemple, nous devons effectuer certaines tâches pour définir le problème exact. Les statistiques d'attente n'indiquent pas la cible du problème.
Conclusion
Dans cet article, nous avons parlé du concept principal de la vue de gestion dynamique sys.dm_os_wait_stats. En même temps, nous avons discuté de la simplicité d'utilisation et des points significatifs, auxquels il faut faire attention.
Outil utile :
dbForge Monitor - complément pour Microsoft SQL Server Management Studio qui vous permet de suivre et d'analyser les performances de SQL Server.
