L'équipe SQLskills adore les statistiques d'attente. Si vous parcourez les messages sur ce blog (voir les messages de Paul sur les statistiques d'attente de genou) et sur le site SQLskills, vous verrez des messages de nous tous discutant de la valeur des statistiques d'attente, de ce que nous recherchons et pourquoi un particulier attendre est un problème. Paul écrit le plus à ce sujet, mais nous commençons tous généralement par des statistiques d'attente lors du dépannage d'un problème de performances. Qu'est-ce que cela signifie en termes de proactivité ?
Afin d'obtenir une image complète de la signification des statistiques d'attente lors d'un problème de performances, vous devez connaître vos attentes normales. Cela signifie capturer ces informations de manière proactive et utiliser cette ligne de base comme référence. Si vous ne disposez pas de ces données, alors lorsqu'un problème de performances survient, vous ne saurez pas si les attentes de PAGELATCH sont typiques de votre environnement (tout à fait possible) ou si vous rencontrez soudainement un problème lié à tempdb en raison d'un nouveau code qui a été ajouté .
Les données statistiques d'attente
J'ai déjà publié un script que j'utilise pour capturer les statistiques d'attente, et c'est un script que j'utilise depuis longtemps pour les clients. Cependant, j'ai récemment apporté des modifications à mon script et légèrement modifié ma méthode. Laissez-moi vous expliquer pourquoi…
Le principe fondamental derrière les statistiques d'attente est que SQL Server suit chaque fois qu'un thread doit attendre "quelque chose". En attente de lecture d'une page à partir du disque ? PAGEIOLATCH_XX attendez. En attente d'un verrouillage pour apporter une modification aux données ? LCX_M_XXX attendez. Vous attendez une allocation de mémoire pour qu'une requête puisse s'exécuter ? RESOURCE_SEMAPHORE patientez. Toutes ces attentes sont suivies dans le DMV sys.dm_os_wait_stats, et les données s'accumulent au fil du temps... c'est un représentant cumulatif des attentes.
Par exemple, j'ai une instance SQL Server 2014 dans l'une de mes machines virtuelles qui est opérationnelle depuis environ 9h30 ce matin :
SELECT [sqlserver_start_time] FROM [sys].[dm_os_sys_info];
Heure de démarrage de SQL Server
Maintenant, si je regarde à quoi ressemblent mes statistiques d'attente (rappelez-vous, cumulées jusqu'à présent) en utilisant le script de Paul, je vois que TRACEWRITE est mon attente "standard" actuelle :
Attentes agrégées actuelles
Ok, maintenant introduisons cinq minutes de conflit tempdb et voyons comment cela affecte mes statistiques d'attente globales. J'ai un script que Jonathan a utilisé précédemment pour créer un conflit tempdb, et je l'ai configuré pour qu'il s'exécute pendant 5 minutes :
USE AdventureWorks2012; GO SET NOCOUNT ON; GO DECLARE @CurrentTime SMALLDATETIME = SYSDATETIME(), @EndTime SMALLDATETIME = DATEADD(MINUTE, 5, SYSDATETIME()); WHILE @CurrentTime < @EndTime BEGIN IF OBJECT_ID('tempdb..#temp') IS NOT NULL BEGIN DROP TABLE #temp; END CREATE TABLE #temp ( ProductID INT PRIMARY KEY, OrderQty INT, TotalDiscount MONEY, LineTotal MONEY, Filler NCHAR(500) DEFAULT(N'') NOT NULL ); INSERT INTO #temp(ProductID, OrderQty, TotalDiscount, LineTotal) SELECT sod.ProductID, SUM(sod.OrderQty), SUM(sod.LineTotal), SUM(sod.OrderQty + sod.UnitPriceDiscount) FROM Sales.SalesOrderDetail AS sod GROUP BY ProductID; DECLARE @ProductNumber NVARCHAR(25), @Name NVARCHAR(50), @TotalQty INT, @SalesTotal MONEY, @TotalDiscount MONEY; SELECT @ProductNumber = p.ProductNumber, @Name = p.Name, @TotalQty = t1.OrderQty, @SalesTotal = t1.LineTotal, @TotalDiscount = t1.TotalDiscount FROM Production.Product AS p JOIN #temp AS t1 ON p.ProductID = t1.ProductID; SET @CurrentTime = SYSDATETIME() END
J'ai utilisé une invite de commande pour démarrer 10 sessions qui ont exécuté ce script, et exécuté simultanément un script qui a capturé mes statistiques d'attente globales, un instantané des attentes sur une période de 5 minutes, puis à nouveau les statistiques d'attente globales. Tout d'abord, un petit secret, puisque nous ignorons tout le temps les attentes bénignes, il peut être utile de les mettre dans une table afin que vous puissiez référencer un objet au lieu d'avoir constamment à coder en dur une liste de chaînes d'exclusion dans une requête. Donc :
USE SQLskills_WaitStats; GO CREATE TABLE dbo.WaitsToIgnore(WaitType SYSNAME PRIMARY KEY); INSERT dbo.WaitsToIgnore(WaitType) VALUES(N'BROKER_EVENTHANDLER'), (N'BROKER_RECEIVE_WAITFOR'), (N'BROKER_TASK_STOP'), (N'BROKER_TO_FLUSH'), (N'BROKER_TRANSMITTER'), (N'CHECKPOINT_QUEUE'), (N'CHKPT'), (N'CLR_AUTO_EVENT'), (N'CLR_MANUAL_EVENT'), (N'CLR_SEMAPHORE'), (N'DBMIRROR_DBM_EVENT'), (N'DBMIRROR_EVENTS_QUEUE'), (N'DBMIRROR_WORKER_QUEUE'), (N'DBMIRRORING_CMD'), (N'DIRTY_PAGE_POLL'), (N'DISPATCHER_QUEUE_SEMAPHORE'), (N'EXECSYNC'), (N'FSAGENT'), (N'FT_IFTS_SCHEDULER_IDLE_WAIT'), (N'FT_IFTSHC_MUTEX'), (N'HADR_CLUSAPI_CALL'), (N'HADR_FILESTREAM_IOMGR_IOCOMPLETIO(N'), (N'HADR_LOGCAPTURE_WAIT'), (N'HADR_NOTIFICATION_DEQUEUE'), (N'HADR_TIMER_TASK'), (N'HADR_WORK_QUEUE'), (N'KSOURCE_WAKEUP'), (N'LAZYWRITER_SLEEP'), (N'LOGMGR_QUEUE'), (N'ONDEMAND_TASK_QUEUE'), (N'PWAIT_ALL_COMPONENTS_INITIALIZED'), (N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP'), (N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP'), (N'REQUEST_FOR_DEADLOCK_SEARCH'), (N'RESOURCE_QUEUE'), (N'SERVER_IDLE_CHECK'), (N'SLEEP_BPOOL_FLUSH'), (N'SLEEP_DBSTARTUP'), (N'SLEEP_DCOMSTARTUP'), (N'SLEEP_MASTERDBREADY'), (N'SLEEP_MASTERMDREADY'), (N'SLEEP_MASTERUPGRADED'), (N'SLEEP_MSDBSTARTUP'), (N'SLEEP_SYSTEMTASK'), (N'SLEEP_TASK'), (N'SLEEP_TEMPDBSTARTUP'), (N'SNI_HTTP_ACCEPT'), (N'SP_SERVER_DIAGNOSTICS_SLEEP'), (N'SQLTRACE_BUFFER_FLUSH'), (N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP'), (N'SQLTRACE_WAIT_ENTRIES'), (N'WAIT_FOR_RESULTS'), (N'WAITFOR'), (N'WAITFOR_TASKSHUTDOW(N'), (N'WAIT_XTP_HOST_WAIT'), (N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG'), (N'WAIT_XTP_CKPT_CLOSE'), (N'XE_DISPATCHER_JOIN'), (N'XE_DISPATCHER_WAIT'), (N'XE_TIMER_EVENT');
Nous sommes maintenant prêts à saisir nos attentes :
/* Capture the instance start time (in this case, time since waits have been accumulating) */ SELECT [sqlserver_start_time] FROM [sys].[dm_os_sys_info]; GO /* Get the current time */ SELECT SYSDATETIME() AS [Before Test 1]; /* Get aggregate waits until now */ WITH [Waits] AS ( SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM sys.dm_os_wait_stats WHERE [wait_type] NOT IN (SELECT WaitType FROM SQLskills_Waits.WaitsToIgnore) AND [waiting_tasks_count] > 0 ) SELECT MAX ([W1].[wait_type]) AS [WaitType], CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S], CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S], CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S], MAX ([W1].[WaitCount]) AS [WaitCount], CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage], CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S], CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S], CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S] FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum] GROUP BY [W1].[RowNum] HAVING SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 95; -- percentage threshold GO /* Get the current time */ SELECT SYSDATETIME() AS [Before Test 2]; /* Capture a snapshot of waits over a 5 minute period */ IF EXISTS (SELECT * FROM [tempdb].[sys].[objects] WHERE [name] = N'##SQLskillsStats1') DROP TABLE [##SQLskillsStats1]; IF EXISTS (SELECT * FROM [tempdb].[sys].[objects] WHERE [name] = N'##SQLskillsStats2') DROP TABLE [##SQLskillsStats2]; GO SELECT [wait_type], [waiting_tasks_count], [wait_time_ms], [max_wait_time_ms], [signal_wait_time_ms] INTO ##SQLskillsStats1 FROM sys.dm_os_wait_stats; GO WAITFOR DELAY '00:05:00'; GO SELECT [wait_type], [waiting_tasks_count], [wait_time_ms], [max_wait_time_ms], [signal_wait_time_ms] INTO ##SQLskillsStats2 FROM sys.dm_os_wait_stats; GO WITH [DiffWaits] AS ( SELECT -- Waits that weren't in the first snapshot [ts2].[wait_type], [ts2].[wait_time_ms], [ts2].[signal_wait_time_ms], [ts2].[waiting_tasks_count] FROM [##SQLskillsStats2] AS [ts2] LEFT OUTER JOIN [##SQLskillsStats1] AS [ts1] ON [ts2].[wait_type] = [ts1].[wait_type] WHERE [ts1].[wait_type] IS NULL AND [ts2].[wait_time_ms] > 0 UNION SELECT -- Diff of waits in both snapshots [ts2].[wait_type], [ts2].[wait_time_ms] - [ts1].[wait_time_ms] AS [wait_time_ms], [ts2].[signal_wait_time_ms] - [ts1].[signal_wait_time_ms] AS [signal_wait_time_ms], [ts2].[waiting_tasks_count] - [ts1].[waiting_tasks_count] AS [waiting_tasks_count] FROM [##SQLskillsStats2] AS [ts2] LEFT OUTER JOIN [##SQLskillsStats1] AS [ts1] ON [ts2].[wait_type] = [ts1].[wait_type] WHERE [ts1].[wait_type] IS NOT NULL AND [ts2].[waiting_tasks_count] - [ts1].[waiting_tasks_count] > 0 AND [ts2].[wait_time_ms] - [ts1].[wait_time_ms] > 0 ), [Waits] AS ( SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM [DiffWaits] WHERE [wait_type] NOT IN (SELECT WaitType FROM SQLskills_WaitStats.dbo.WaitsToIgnore) ) SELECT [W1].[wait_type] AS [WaitType], CAST ([W1].[WaitS] AS DECIMAL (16, 2)) AS [Wait_S], CAST ([W1].[ResourceS] AS DECIMAL (16, 2)) AS [Resource_S], CAST ([W1].[SignalS] AS DECIMAL (16, 2)) AS [Signal_S], [W1].[WaitCount] AS [WaitCount], CAST ([W1].[Percentage] AS DECIMAL (5, 2)) AS [Percentage], CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgWait_S], CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgRes_S], CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgSig_S] FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum] GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS], [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage] HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold GO -- Cleanup IF EXISTS (SELECT * FROM [tempdb].[sys].[objects] WHERE [name] = N'##SQLskillsStats1') DROP TABLE [##SQLskillsStats1]; IF EXISTS (SELECT * FROM [tempdb].[sys].[objects] WHERE [name] = N'##SQLskillsStats2') DROP TABLE [##SQLskillsStats2]; GO /* Get the current time */ SELECT SYSDATETIME() AS [After Test 1]; /* Get aggregate waits again */ WITH [Waits] AS ( SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM sys.dm_os_wait_stats WHERE [wait_type] NOT IN (SELECT WaitType FROM SQLskills_WaitStats.dbo.WaitsToIgnore) AND [waiting_tasks_count] > 0 ) SELECT MAX ([W1].[wait_type]) AS [WaitType], CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S], CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S], CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S], MAX ([W1].[WaitCount]) AS [WaitCount], CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage], CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S], CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S], CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S] FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum] GROUP BY [W1].[RowNum] HAVING SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 95; -- percentage threshold GO /* Get the current time */ SELECT SYSDATETIME() AS [After Test 2];
Si nous regardons la sortie, nous pouvons voir que pendant que les 10 instances du script pour créer un conflit tempdb étaient en cours d'exécution, SOS_SCHEDULER_YIELD était notre type d'attente le plus répandu, et nous avons également eu des attentes PAGELATCH_XX, comme prévu :
Si nous regardons les attentes moyennes APRÈS la fin du test, nous voyons à nouveau TRACEWRITE comme l'attente la plus élevée, et nous voyons SOS_SCHEDULER_YIELD comme une attente. En fonction de ce qui est en cours d'exécution dans l'environnement, cette attente peut ou non persister longtemps dans nos principales attentes, et elle peut ou non apparaître comme un type d'attente à enquêter.
Capture proactive des statistiques d'attente
Par défaut, les statistiques d'attente sont cumulées . Oui, vous pouvez les effacer à tout moment en utilisant DBCC SQLPERF, mais je trouve que la plupart des gens ne le font pas régulièrement, ils les laissent simplement s'accumuler. Et c'est bien, mais comprenez comment cela affecte vos données. Si vous ne redémarrez votre instance que lorsque vous la corrigez, ou lorsqu'il y a un problème (ce qui, espérons-le, se produit rarement), ces données pourraient s'accumuler pendant des mois. Plus vous avez de données, plus il est difficile de voir de petites variations… des choses qui pourraient être des problèmes de performances. Même lorsque vous avez un "gros problème" qui affecte l'ensemble de votre serveur pendant plusieurs minutes, comme nous l'avons fait ici avec tempdb, cela peut ne pas créer suffisamment de changement dans vos données pour être détecté dans les données cumulées. Au lieu de cela, vous devez prendre un instantané des données (capturez-les, attendez quelques minutes, capturez-les à nouveau, puis comparez les données) pour voir ce qui se passe réellement en ce moment .
En tant que tel, si vous ne faites qu'un instantané des statistiques d'attente toutes les quelques heures, les données que vous avez collectées montrent simplement l'agrégation continue au fil du temps. Vous pouvez diff ces instantanés pour comprendre les performances entre les instantanés, mais je peux vous dire que d'avoir à écrire ce code sur un grand ensemble de données, c'est pénible (mais je ne suis pas un développeur, alors peut-être que c'est facile pour vous ).
Ma méthode traditionnelle de capture des statistiques d'attente consistait simplement à prendre un instantané de sys.dm_os_wait_stats toutes les quelques heures à l'aide du script original de Paul :
USE [BaselineData]; GO IF NOT EXISTS (SELECT * FROM [sys].[tables] WHERE [name] = N'SQLskills_WaitStats_OldMethod') BEGIN CREATE TABLE [dbo].[SQLskills_WaitStats_OldMethod] ( [RowNum] [bigint] IDENTITY(1,1) NOT NULL, [CaptureDate] [datetime] NULL, [WaitType] [nvarchar](120) NULL, [Wait_S] [decimal](14, 2) NULL, [Resource_S] [decimal](14, 2) NULL, [Signal_S] [decimal](14, 2) NULL, [WaitCount] [bigint] NULL, [Percentage] [decimal](4, 2) NULL, [AvgWait_S] [decimal](14, 4) NULL, [AvgRes_S] [decimal](14, 4) NULL, [AvgSig_S] [decimal](14, 4) NULL ); CREATE CLUSTERED INDEX [CI_SQLskills_WaitStats_OldMethod] ON [dbo].[SQLskills_WaitStats_OldMethod] ([CaptureDate],[RowNum]); END GO /* Query to use in scheduled job */ USE [BaselineData]; GO INSERT INTO [dbo].[SQLskills_WaitStats_OldMethod] ( [CaptureDate] , [WaitType] , [Wait_S] , [Resource_S] , [Signal_S] , [WaitCount] , [Percentage] , [AvgWait_S] , [AvgRes_S] , [AvgSig_S] ) EXEC ('WITH [Waits] AS (SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM sys.dm_os_wait_stats WHERE [wait_type] NOT IN (SELECT WaitType FROM SQLskills_WaitStats.dbo.WaitsToIgnore) ) SELECT GETDATE(), [W1].[wait_type] AS [WaitType], CAST ([W1].[WaitS] AS DECIMAL(14, 2)) AS [Wait_S], CAST ([W1].[ResourceS] AS DECIMAL(14, 2)) AS [Resource_S], CAST ([W1].[SignalS] AS DECIMAL(14, 2)) AS [Signal_S], [W1].[WaitCount] AS [WaitCount], CAST ([W1].[Percentage] AS DECIMAL(4, 2)) AS [Percentage], CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgWait_S], CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgRes_S], CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgSig_S] FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum] GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS], [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage] HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95;' );
Je parcourrais ensuite et regarderais le haut attendre pour chaque instantané, par exemple :
SELECT [w].[CaptureDate] , [w].[WaitType] , [w].[Percentage] , [w].[Wait_S] , [w].[WaitCount] , [w].[AvgWait_S] FROM [dbo].[SQLskills_WaitStats_OldMethod] w JOIN ( SELECT MIN([RowNum]) AS [RowNumber] , [CaptureDate] FROM [dbo].[SQLskills_WaitStats_OldMethod] WHERE [CaptureDate] IS NOT NULL AND [CaptureDate] > GETDATE() - 60 GROUP BY [CaptureDate] ) m ON [w].[RowNum] = [m].[RowNumber] ORDER BY [w].[CaptureDate];
Ma nouvelle méthode alternative consiste à différencier quelques instantanés de statistiques d'attente (avec deux à trois minutes entre les instantanés) toutes les heures environ. Ces informations me disent alors exactement ce que le système attendait à ce moment :
USE [BaselineData]; GO IF NOT EXISTS ( SELECT * FROM [sys].[tables] WHERE [name] = N'SQLskills_WaitStats') BEGIN CREATE TABLE [dbo].[SQLskills_WaitStats] ( [RowNum] [bigint] IDENTITY(1,1) NOT NULL, [CaptureDate] [datetime] NOT NULL DEFAULT (sysdatetime()), [WaitType] [nvarchar](60) NOT NULL, [Wait_S] [decimal](16, 2) NULL, [Resource_S] [decimal](16, 2) NULL, [Signal_S] [decimal](16, 2) NULL, [WaitCount] [bigint] NULL, [Percentage] [decimal](5, 2) NULL, [AvgWait_S] [decimal](16, 4) NULL, [AvgRes_S] [decimal](16, 4) NULL, [AvgSig_S] [decimal](16, 4) NULL ) ON [PRIMARY]; CREATE CLUSTERED INDEX [CI_SQLskills_WaitStats] ON [dbo].[SQLskills_WaitStats] ([CaptureDate],[RowNum]); END /* Query to use in scheduled job */ USE [BaselineData]; GO IF EXISTS (SELECT * FROM [tempdb].[sys].[objects] WHERE [name] = N'##SQLskillsStats1') DROP TABLE [##SQLskillsStats1]; IF EXISTS (SELECT * FROM [tempdb].[sys].[objects] WHERE [name] = N'##SQLskillsStats2') DROP TABLE [##SQLskillsStats2]; GO /* Capture wait stats */ SELECT [wait_type], [waiting_tasks_count], [wait_time_ms], [max_wait_time_ms], [signal_wait_time_ms] INTO ##SQLskillsStats1 FROM sys.dm_os_wait_stats; GO /* Wait some amount of time */ WAITFOR DELAY '00:02:00'; GO /* Capture wait stats again */ SELECT [wait_type], [waiting_tasks_count], [wait_time_ms], [max_wait_time_ms], [signal_wait_time_ms] INTO ##SQLskillsStats2 FROM sys.dm_os_wait_stats; GO /* Diff the waits */ WITH [DiffWaits] AS ( SELECT -- Waits that weren't in the first snapshot [ts2].[wait_type], [ts2].[wait_time_ms], [ts2].[signal_wait_time_ms], [ts2].[waiting_tasks_count] FROM [##SQLskillsStats2] AS [ts2] LEFT OUTER JOIN [##SQLskillsStats1] AS [ts1] ON [ts2].[wait_type] = [ts1].[wait_type] WHERE [ts1].[wait_type] IS NULL AND [ts2].[wait_time_ms] > 0 UNION SELECT -- Diff of waits in both snapshots [ts2].[wait_type], [ts2].[wait_time_ms] - [ts1].[wait_time_ms] AS [wait_time_ms], [ts2].[signal_wait_time_ms] - [ts1].[signal_wait_time_ms] AS [signal_wait_time_ms], [ts2].[waiting_tasks_count] - [ts1].[waiting_tasks_count] AS [waiting_tasks_count] FROM [##SQLskillsStats2] AS [ts2] LEFT OUTER JOIN [##SQLskillsStats1] AS [ts1] ON [ts2].[wait_type] = [ts1].[wait_type] WHERE [ts1].[wait_type] IS NOT NULL AND [ts2].[waiting_tasks_count] - [ts1].[waiting_tasks_count] > 0 AND [ts2].[wait_time_ms] - [ts1].[wait_time_ms] > 0 ), [Waits] AS ( SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM [DiffWaits] WHERE [wait_type] NOT IN (SELECT WaitType FROM SQLskills_WaitStats.dbo.WaitsToIgnore) ) INSERT INTO [BaselineData].[dbo].[SQLskills_WaitStats] ( [WaitType] , [Wait_S] , [Resource_S] , [Signal_S] , [WaitCount] , [Percentage] , [AvgWait_S] , [AvgRes_S] , [AvgSig_S] ) SELECT [W1].[wait_type], CAST ([W1].[WaitS] AS DECIMAL (16, 2)) , CAST ([W1].[ResourceS] AS DECIMAL (16, 2)) , CAST ([W1].[SignalS] AS DECIMAL (16, 2)) , [W1].[WaitCount] , CAST ([W1].[Percentage] AS DECIMAL (5, 2)) , CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) , CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) , CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum] GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS], [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage] HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold GO /* Clean up the temp tables */ IF EXISTS (SELECT * FROM [tempdb].[sys].[objects] WHERE [name] = N'##SQLskillsStats1') DROP TABLE [##SQLskillsStats1]; IF EXISTS (SELECT * FROM [tempdb].[sys].[objects] WHERE [name] = N'##SQLskillsStats2') DROP TABLE [##SQLskillsStats2];
Ma nouvelle méthode est-elle meilleure ? Je pense que oui, car c'est une meilleure représentation de ce à quoi ressemblent les attentes au moment de la capture, et c'est toujours un échantillonnage à intervalle régulier. Pour les deux méthodes, je regarde généralement quelle était l'attente la plus élevée au moment de la capture :
SELECT [w].[CaptureDate] , [w].[WaitType] , [w].[Percentage] , [w].[Wait_S] , [w].[WaitCount] , [w].[AvgWait_S] FROM [dbo].[SQLskills_WaitStats] w JOIN ( SELECT MIN([RowNum]) AS [RowNumber], [CaptureDate] FROM [dbo].[SQLskills_WaitStats] WHERE [CaptureDate] > GETDATE() - 30 GROUP BY [CaptureDate] ) m ON [w].[RowNum] = [m].[RowNumber] ORDER BY [w].[CaptureDate];
Résultats :
Haut attendre pour chaque instantané (exemple de sortie)
L'inconvénient, qui existait avec mon script d'origine, c'est que c'est toujours juste un instantané . Je peux suivre les attentes les plus élevées au fil du temps, mais si un problème survient entre les instantanés, il ne s'affichera pas. Alors que pouvez-vous faire ?
Vous pourriez augmenter la fréquence de vos captures. Peut-être qu'au lieu de capturer des statistiques d'attente toutes les heures, vous les capturez toutes les 15 minutes. Ou peut-être tous les 10. Plus vous capturez les données fréquemment, plus vous avez de chances de détecter un problème de performances.
Votre autre option serait d'utiliser une application tierce, telle que SQL Sentry Performance Advisor, pour surveiller les attentes. Performance Advisor extrait exactement les mêmes informations du DMV sys.dm_os_wait_stats. Il interroge sys.dm_os_wait_stats toutes les 10 secondes avec une requête très simple :
SELECT * FROM sys.dm_os_wait_stats WHERE wait_time_ms > 0;
Dans les coulisses, Performance Advisor prend ensuite ces données et les ajoute à sa base de données de surveillance. Lorsque vous voyez les données, les attentes bénignes sont supprimées et les deltas sont calculés pour vous. De plus, Performance Advisor a un affichage fantastique (regarder le tableau de bord est beaucoup plus agréable que le texte ci-dessus) et vous pouvez personnaliser la collection si vous le souhaitez. Si nous regardons Performance Advisor et regardons les données de toute la journée, je peux facilement voir où j'ai eu un problème dans le volet SQL Server Waits :
Tableau de bord Performance Advisor du jour
Et je peux ensuite explorer cette période après 15 h 00 pour enquêter davantage sur ce qui s'est passé :
Explorer vers le bas dans PA lors d'un problème de performances
Surveillant moi-même, à moins que je n'arrive à capturer des statistiques d'attente en même temps avec un script, j'aurai manqué de capturer des données sur ce problème de performances. Étant donné que Performance Advisor stocke les informations pendant une période prolongée, si vous avez une baisse de performances, vous faites disposez des données statistiques d'attente (ainsi que de nombreuses autres informations) pour vous aider à rechercher le problème, et vous disposez également de données historiques afin de comprendre quelles attentes normales existent dans votre environnement.
Résumé
Quelle que soit la méthode que vous choisissez pour surveiller les attentes, il est d'abord important de comprendre comment SQL Server stocke les informations d'attente, afin que vous compreniez les données que vous voyez si vous les capturez régulièrement. Si vous devez lancer vos propres scripts pour capturer les attentes, vous êtes limité dans la mesure où vous ne pouvez pas capturer les écarts aussi facilement qu'avec un logiciel tiers. Mais ce n'est pas grave :avoir une certaine quantité de données de base pour commencer à comprendre ce qui est "normal" est mieux que de ne rien avoir du tout . Au fur et à mesure que vous construisez votre référentiel et que vous commencez à vous familiariser avec un environnement, vous pouvez personnaliser vos scripts de capture selon les besoins pour résoudre les problèmes qui peuvent exister. Si vous bénéficiez d'un logiciel tiers, utilisez ces informations au maximum et assurez-vous de comprendre comment les attentes sont collectées et stockées.