Le Blog SQL Server d'ElSüket » SQL Server 2014

Variables de type table, statistiques et drapeau de trace 2453

elsuket — Sun, 30 Jul 2017 21:39:01 +0000

M’étant arrêté d’écrire pendant un certain temps, mais certainement pas de lire, me voilà de retour au clavier pour partager sur mon sujet préféré : l’optimiseur de requêtes, et plus particulièrement l’estimation de cardinalités. En butinant des billets de blog ici et là à propos de SQL Server, je trouvais un billet détaillant le comportement des requêtes spécifiant des variables de type TABLE.

Qu’est-ce que l’estimation de cardinalités ? Pour faire très court, c’est l’ensemble des règles mathématiques qui permettent à SQL Server d’avoir une idée assez précise du nombre de lignes qu’il aura à traiter lors de l’exécution d’une requête. C’est avec ce calcul-là qu’il sélectionne les algorithmes de jointure, de regroupement, l’ordre et la façon d’accéder aux tables, et bien d’autres choses encore. Bien sûr, ces choix varient suivant le volume de données à traiter. On le comprend donc, c’est un sujet très important, puisqu’il impacte directement les performances de l’exécution de nos chères (parfois en IO et temps CPU !) requêtes.

Alors vous allez me dire, crevant d’impatience : « bon d’accord, mais il le sort de son chapeau magique ce calcul ? » : au risque de vous décevoir, non. Dès lors qu’on soumet une requête qui filtre une table par une colonne, ou l’utilise dans une jointure, un regroupement, alors par défaut, le moteur crée automatiquement des objets de statistique. C’est à dire qu’il va échantillonner les données des colonnes des tables participant à la requête pour évaluer la distribution des données dans les colonnes (et index) de ces tables. Fort de ces informations, il peut alors réaliser le fameux calcul. Bref, ce sont des mathématiques

L’auteur du billet en question partageait sur le fait que par défaut, SQL Server estime qu’il n’y a qu’une seule ligne dans une variable de type TABLE. Ceci s’explique par le fait que SQL Server ne maintient pas d’objet de statistique sur les variables de type TABLE (pour les curieux, il le fait néanmoins sur les tables temporaires). Quand on sait l’usage qui est fait des variables de type TABLE dans les applications, il est évident qu’il arrive rarement que ces tables ne soient en charge que d’une seule ligne; de là des performances qui ne sont pas toujours en adéquation avec le volume de données à traiter.

Voyons le comportement par défaut du moteur à l’aide de la base de données AdventureWorks2012 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

SET NOCOUNT ON
GO

USE AdventureWorks2012
GO

DECLARE @BusinessEntityId TABLE
(
BusinessEntityID INT NOT NULL
);

INSERT INTO @BusinessEntityId
(
BusinessEntityID
)
SELECT BusinessEntityID
FROM Person.Person;

SET STATISTICS IO, TIME, XML ON

SELECT COUNT(*)
FROM @BusinessEntityId b
INNER JOIN Person.Person p
ON b.BusinessEntityID = p.BusinessEntityID;

SET STATISTICS IO, TIME, XML OFF

L’option de session SET STATISTICS nous permet de collecter des métriques IO, temps CPU et durée en millisecondes de la requête. Son option XML expose le plan réel de requête en plus du résultat de la requête. La sortie de ce lot est, tronquée des lectures « physiques » (i.e. sur disque et pas en RAM), et des lectures LOB, puisqu’il n’y en a pas :

Table ‘Person’. Scan count 0, logical reads 59916
Table ‘#BEF1AB90′. Scan count 1, logical reads 33

SQL Server Execution Times:
CPU time = 47 ms, elapsed time = 56 ms.

Si l’on étudie le plan de requête, voici ce que l’on trouve pour notre variable de type TABLE :

Pour voir sur quelle base le moteur a réalisé ses calculs, il suffit de survoler l’opérateur Table Scan avec le curseur de la souris :

Le moteur a donc estimé qu’il n’y qu’une seule ligne dans la variable de type TABLE, puis il a exécuté le plan de cette requête. D’une certaine manière, il nous avoue s’être un peu trompé, puisqu’il nous indique qu’en réalité, il a lu 19972 lignes.

Mais, à la lecture du résumé l’article 2952444, on voit que ce comportement a été corrigé à l’aide d’un correctif dès SQL Server 2012 SP2 et le CU3 de SQL Server 2014, ce qui fait qu’il est dans les RTM des versions suivantes de SQL Server, à ce jour SQL Server 2016 et 2017 (bientôt !) :

When you populate a table variable with many rows and then join it with other tables, the query optimizer may choose an inefficient query plan, which may lead to slow query performance.

Voyons donc ce qu’il en est : nous rejouons le même lot de requête, mais avec le drapeau de trace activé cette fois :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

-- Activation du drapeau de trace 2453 pour toutes
-- les bases de données que l'instance héberge
DBCC TRACEON (2453, -1)
GO

SET NOCOUNT ON
GO

USE AdventureWorks2012
GO

DECLARE @BusinessEntityId TABLE
(
BusinessEntityID INT NOT NULL
);

INSERT INTO @BusinessEntityId
(
BusinessEntityID
)
SELECT BusinessEntityID
FROM Person.Person;

SET STATISTICS IO, TIME, XML ON

SELECT COUNT(*)
FROM @BusinessEntityId b
INNER JOIN Person.Person p
ON b.BusinessEntityID = p.BusinessEntityID;

SET STATISTICS IO, TIME, XML OFF

La sortie est :

Table ‘Workfile’. Scan count 7, logical reads 64, physical reads 0, read-ahead reads 64
Table ‘Worktable’. Scan count 0, logical reads 0
Table ‘Person’. Scan count 1, logical reads 67
Table ‘#A96F2843′. Scan count 1, logical reads 33

SQL Server Execution Times:
CPU time = 31 ms, elapsed time = 39 ms.

Le gain de temps pour une requête aussi simple n’est pas négligeable, mais c’est surtout le gain en IOs qui est très intéressant ! Voyons ce que nous dit le plan de requête :

L’ordre d’accès aux tables est le même, mais on voit bien que la façon de les traiter a changé : les jointures et agrégats sont exécutés par hachage. On note aussi les avertissements (petit point d’exclamation noir dans un triangle jaune) sur ces deux opérateurs : ils ont du accéder à TempDB pour exécuter la jointure et l’agrégat, d’où les Workfile et Worktable dans la sortie de SET STATISTICS : ce sont des structures créées à la volée dans TempDB, souvent à défaut d’index pouvant supporter la requête efficacement.

Voyons ce que nous indique l’opérateur Table Scan :

Ici on voit bien que l’estimation du nombre de lignes s’est faite correctement, et c’est donc bien cela qui a conduit le moteur à changer les algorithmes de jointure et de calcul de l’agrégat.

Pour ma part, la grande majorité des instances SQL Server que j’administre actuellement sont de version 2014, et j’ai activé ce drapeau de trace sur toutes celles-ci. En effet, l’application qui repose sur cette base de données fait souvent appel à des Tabled-Valued Parameters, qui sont des variables de type table que l’on peut passer en paramètre à une procédure stockée ou un appel à la procédure stockée système sp_executesql. Les performances générales de l’application s’en sont immédiatement ressenti positivement.

Je n’irai pas jusqu’à écrire qu’il faudrait que ce drapeau de trace soit activé sur toute les instances de production, car :

toutes les applications et leurs charges de travail sont différentes
il est toujours primordial de tester et de mesurer avant d’effectuer un quelconque changement de configuration sur une instance de production

Je vous engage vivement donc à tester pour en observer l’effet :

Pour savoir quels sont les drapeaux de trace actifs, il suffit d’exécuter DBCC TRACESTATUS seul, ou si l’on veut être plus spécifique : DBCC TRACESTATUS (2453, -1)
Pour désactiver un drapeau de trace, il faut exécuter : DBCC TRACEOFF ({traceFlag}, -1), soit dans le cadre de ce billet : DBCC TRACEOFF (2453, -1)

N’hésitez pas à me laisser un petit commentaire !

ElSüket.

sys.dm_exec_query_profiles : la DMV qui détaille les noeuds d’un plan d’exécution réel

elsuket — Tue, 09 Aug 2016 08:00:57 +0000

La lecture du plan d’exécution réel peut s’avérer être une tâche laborieuse, surtout lorsque le plan contient de nombreux opérateurs ou nœuds.

Introduite avec SQL Server 2014, la vue de gestion dynamique sys.dm_exec_query_profiles nous permet de voir quel(s) nœud(s) d’un plan d’exécution réel consomme le plus de ressources et /ou de temps. C’est donc un formidable outil qui peut faire largement diminuer la recherche des points noueux d’une requête à l’étude.

La documentation de cette DMV montre qu’elle expose de nombreuses colonnes, qui nous renseignent de façon très précise sur la consommation de ressources physiques de chaque opérateur du plan de requête, notamment avec le nombre de millisecondes après lequel un opérateur s’est exécuté pour la première et la dernière fois. Pour simplifier l’analyse des requêtes, on peut s’en tenir à quelques unes d’entre-elles, comme dans la requête suivante :

1
2
3
4
5
6
7
8
9
10
11
12

SELECT physical_operator_name
, node_id
, elapsed_time_ms
, cpu_time_ms
, row_count
, estimate_row_count
, logical_read_count
, rewind_count
, rebind_count
, end_of_scan_count
, scan_count
FROM sys.dm_exec_query_profiles

La colonne node_id nous donne le numéro de l’opérateur dans le plan de requête. Il faut noter que l’opérateur racine de l’arbre de résolution qu’est le plan de requête, et qui se situe en haut et à gauche dans le plan d’exécution graphique, est le seul dans tout plan à ne pas porter de NodeID. L’opérateur qui le précède porte le NodeID 0, et celui qui précède ce dernier le NodeID 1, et ainsi de suite. Le plus grand numéro de NodeID est à l’opérateur qui est le plus à droite et en bas du plan d’exécution graphique.

La colonne session_id va nous permettre de spécifier sur quelle session porte notre étude : pour que cette vue expose des lignes, il est nécessaire que l’option de session SET STATISTICS XML soit positionnée à ON pour la requête à étudier. Ceci équivaut à l’activation de l’option d’inclusion du plan d’exécution réel dans la barre d’outil de SQL Server Management Studio (SSMS) avant l’exécution d’une requête. Ceci est normal, puisque comme pour toutes les tâches de monitoring, elle viennent avec un coût : celui-ci pourrait devenir trop élevé si toutes les requêtes étaient auditées à ce niveau de détail, d’autant que ce type d’information est utilisé par les DBAs, et pas par les applications qui interagissent avec la base de données.

Supposons que la requête (très simple) que l’on souhaite étudier est la suivante :

1
2
3
4
5

SELECT *
FROM Sales.SalesOrderDetail AS SOD
INNER JOIN Production.Product AS P
ON SOD.ProductID = P.ProductID
WHERE P.ListPrice > 1000

On peut récupérer le session_id de plusieurs manières :

Il est indiqué dans la barre d’état de toute fenêtre de requête sous SSMS, en bas à droite;
Si l’on a conservé les options par défaut de SSMS, il est aussi indiqué sur l’onglet de la fenêtre de requête;
On peut exécuter SELECT @@SPID dans la même fenêtre de requête que celle à étudier.

Ne soyez pas perturbé par l’option de session SET STATISTICS IO, TIME ON positionné juste avant la requête : je l’utilise toujours pour diagnostiquer une requête, car cela expose le temps CPU, la durée totale, et surtout, le nombre d’IOs produit par la requête pour chaque table participant à celle-ci. On peut adjoindre l’option XML à la liste IO, TIME si on le souhaite.

Les lecteurs aux yeux affûtés auront remarqué que dans la capture d’écran ci-dessus, il y a un deuxième onglet ouvert : en effet, on doit utiliser une fenêtre de requête pour celle à étudier, et une autre pour lire la sortie de la vue sys.dm_exec_query_profiles pour cette session. Pour cet exemple, on peut reprendre la première requête, et rajouter la clause WHERE adéquate : la session qui va exécuter la requête à l’étude porte le session_id 51 :

1
2
3
4
5
6
7
8
9
10
11
12
13

L’exercice consiste donc à démarrer l’exécution de la requête à l’étude, puis à basculer vers la fenêtre de requête qui spécifie la vue sys.dm_exec_query_profiles avant la fin de l’exécution de la requête à l’étude. Pour la requête de cet exemple, cela nous donne :

On constate ainsi des écarts importants entre le nombre de lignes estimé et réel pour les opérateurs dont le NodeID est 0 et 4, mais il y a un problème : alors que la somme des valeurs de la colonne elapsed_time_ms nous donne 15, la sortie dans l’onglet Messages est la suivante (légèrement écourtée, notamment les IOs physiques et de LOBs, pour les besoins de l’article) :

(29382 row(s) affected)
Table ‘Workfile’. Scan count 0, logical reads 0
Table ‘Worktable’. Scan count 0, logical reads 0
Table ‘SalesOrderDetail’. Scan count 1, logical reads 1246
Table ‘Product’. Scan count 1, logical reads 15

SQL Server Execution Times:
CPU time = 156 ms, elapsed time = 1225 ms.

Il y a bien sûr le temps de consommation du jeu de lignes de résultat par SSMS. On peut le confirmer en éliminant le résultat une fois la requête exécutée : pour ce faire, il suffit de faire un clic-droit dans un zone vierge de la requête > Query options … > Results / Grid > et de cocher la case Discard results after execution.

La question qui vient maintenant est : comment faire pour les requêtes dont l’exécution est bien plus longue ? Et dans tous les cas, la durée d’exécution des requêtes n’étant pas précisément prédictible même après une ou deux exécutions, comment capturer les valeurs qu’expose cette DMV en s’approchant le plus possible de la fin de la requête ? On peut pour cela écrire une boucle qui va stocker le contenu de la DMV à intervalles réguliers et fréquents, et qui vérifie à chaque tour que la requête est toujours en cours d’exécution :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115

SET NOCOUNT ON
GO

DECLARE @session_id int = 51
, @delay varchar(8) = '00:00:00.010'
, @i int = 1

IF OBJECT_ID('TempDB.dbo.#query_profile_global') IS NOT NULL
DROP TABLE #query_profile_global

CREATE TABLE #query_profile_global
(
physical_operator_name nvarchar(256) NULL
, node_id int NULL
, elapsed_time_ms bigint NULL
, cpu_time_ms bigint NULL
, row_count bigint NULL
, estimate_row_count bigint NULL
, logical_read_count bigint NULL
, rewind_count bigint NULL
, rebind_count bigint NULL
, end_of_scan_count bigint NULL
, object_name sysname NULL
, index_name sysname NULL
, scan_count bigint NULL
, time_stamp datetime NULL
)

DECLARE @query_profile TABLE
(
physical_operator_name nvarchar(256) NULL
, node_id int NULL
, elapsed_time_ms bigint NULL
, cpu_time_ms bigint NULL
, row_count bigint NULL
, estimate_row_count bigint NULL
, logical_read_count bigint NULL
, rewind_count bigint NULL
, rebind_count bigint NULL
, end_of_scan_count bigint NULL
, object_name sysname NULL
, index_name sysname NULL
, scan_count bigint NULL
, time_stamp datetime NULL
)

WHILE EXISTS
(
SELECT *
FROM sys.dm_exec_requests
WHERE session_id = @session_id
)
BEGIN
INSERT INTO @query_profile
SELECT QP.physical_operator_name
, QP.node_id
, QP.elapsed_time_ms
, QP.cpu_time_ms
, QP.row_count
, QP.estimate_row_count
, QP.logical_read_count
, QP.rewind_count
, QP.rebind_count
, QP.end_of_scan_count
, O.name AS object_name
, I.name AS index_name
, QP.scan_count
, GETDATE() AS time_stamp
FROM sys.dm_exec_query_profiles AS QP
LEFT JOIN sys.objects AS O
ON QP.object_id = O.object_id
LEFT JOIN sys.indexes AS I
ON QP.index_id = I.index_id
AND QP.object_id = I.object_id
WHERE QP.session_id = @session_id -- spid running query

IF @i = 1
BEGIN
INSERT INTO #query_profile_global
SELECT *
FROM @query_profile
END
ELSE
BEGIN
UPDATE #query_profile_global
SET physical_operator_name = QP.physical_operator_name
, node_id = QP.node_id
, elapsed_time_ms = QP.elapsed_time_ms
, cpu_time_ms = QP.cpu_time_ms
, row_count = QP.row_count
, estimate_row_count = QP.estimate_row_count
, logical_read_count = QP.logical_read_count
, rewind_count = QP.rewind_count
, rebind_count = QP.rebind_count
, end_of_scan_count = QP.end_of_scan_count
, object_name = QP.object_name
, index_name = QP.index_name
, scan_count = QP.scan_count
, time_stamp = QP.time_stamp
FROM @query_profile AS QP
INNER JOIN #query_profile_global AS QFG
ON QFG.node_id = QP.node_id
END

WAITFOR DELAY @delay

DELETE FROM @query_profile

SET @i += 1
END

SELECT DISTINCT *
FROM #query_profile_global
ORDER BY node_id
--ORDER BY elapsed_time_ms DESC

Ici on stocke le contenu de la DMV toutes les 10 ms. Le délai entre chaque boucle peut être adapté : si l’on sait que la requête dure environ quart d’heure, une récupération du contenu de la vue toutes les secondes est suffisante. Cette valeur peut donc être adaptée suivant la durée d’exécution globale de la requête. Il faut aussi veiller à exécuter ce lot de requêtes dans le même contexte de base de données que celui sous lequel on exécute la requête à étudier. En effet, cela permet d’obtenir le nom de l’objet de base de données accédé :

On constate dans la sortie du lot de requêtes interrogeant la DMV que, par exemple, l’opérateur de NodeID 4 est l’accès à l’index cluster de la table SalesOrderDetail, et qu’il a traité 121317 lignes. Voyons si cela est reflété par le plan d’exécution réel graphique de la requête :

Le numéro de NodeID 4 est bien l’opérateur exposé par la DMV, et si l’on lit la ligne de la bulle dont le libellé est Actual number of rows, on a bien 121317.

Pour l’étude des requêtes plus lourdes, la DMV sys.dm_exec_query_profiles nous permettra de repérer immédiatement les opérateurs les plus consommateurs de ressources, et donc de travailler directement sur ceux-ci en se reportant au plan de requête, puis à la requête elle-même pour en revoir l’écriture et éventuellement l’indexation.

Bonne optimisation !

Le ebook gratuit Introducing SQL Server 2014

elsuket — Sun, 06 Apr 2014 12:29:34 +0000

C’est par ici !

Bonne lecture !