Le Blog SQL Server d'ElSüket » Non documenté

Auditer les processus bloqués : l’événement blocked process report

elsuket — Sat, 15 Jun 2013 10:46:31 +0000

SQL Server 2005 a introduit un évènement capturable par SQL Profiler et par les Notifications d’évènements, qui permet de retrouver les processus qui ont été bloqués. Avec la sortie de SQL Server 2008 et l’introduction des Évènements Étendus, il nous est également possible de capturer cet évènement.

Dans cet article, je vous propose de voir comment paramétrer SQL Server pour capturer cet évènement, puis de vous aider à interpréter le document XML qui décrit la situation de blocage.

Toute exécution de requête résulte en l’acquisition de verrous, dont la granularité (ligne, page, clé, partition, table, base de données, ou encore et plus rarement compilation) et le mode (partagé, exclusif, de mise à jour, ou d’intention) varient. Le verrouillage de ressources est une opération de base pour le moteur de stockage de tout moteur de bases de données SQL, qui garantit l’intégrité de la base de données à travers toutes les opérations de manipulation de données que celle-ci supporte. Cependant, il arrive que lorsqu’un processus a posé un verrou sur une ressource, d’autres processus doivent simultanément accéder à cette même ressource : ces processus sont alors bloqués. Comme il est possible que le processus bloquant ne libère ledit verrou qu’après une durée relativement longue, les effets possibles d’une telle situation sur nos applications peuvent aller de requêtes dont la durée d’exécution est élevée jusqu’à l’expiration du délai d’attente d’une réponse pour l’exécution d’un requête : le fameux timeout.

Il est néanmoins possible, à l’aide d’une trace SQL Profiler ou des Évènements Étendus, de capturer ces situations, qui sont décrites par un document XML.

Configurer l’instance SQL Server

Le seuil de durée de blocage à partir de laquelle on souhaite capturer un tel évènement est configurable à l’aide de l’option d’instance blocked process threshold. On accède à ce paramètre :

– soit à l’aide de SQL Server Management Studio (SSMS), après un clic-droit sur l’instance dans l’Explorateur d’Objets (F8), et avoir choisi l’option Propriétés :

– soit à l’aide de la procédure stockée système sp_configure :

1
2
3

SELECT *
FROM sys.configurations
WHERE name LIKE '%block%'

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

-- Activation de la modification d'options d'instance avancées
EXEC sys.sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO

-- Configuration du seuil de durée de blocage à 5 secondes
EXEC sys.sp_configure 'blocked process threshold', 5
GO
RECONFIGURE;
GO

-- Désactivation de la modification d'options d'instance avancées
EXEC sys.sp_configure 'show advanced options', 0
GO
RECONFIGURE
GO

La console de SSMS affiche, à l’exécution de ce lot de requêtes :

Veillez à ne pas mettre un seuil trop bas : sans cela, on aurait le processus d’arrière plan LOCK MONITOR qui s’exécuterait constamment. Or ce dernier, qui est aussi en charge de détecter les deadlocks, est gourmand en ressources CPU. En s’exécutant fréquemment, il pourrait donc impacter négativement les performances générales de l’instance SQL Server. D’un autre côté, 5 secondes est une durée très longue sur une base de données qui supporte une charge de travail OLTP conséquente. On trouve ce processus avec la requête suivante :

1
2
3
4
5
6
7
8

SELECT session_id
, status
, command
, wait_type
, wait_time
, last_wait_type
FROM sys.dm_exec_requests
WHERE command = 'LOCK MONITOR'

Si l’on exécute maintenant cette requête de façon répétée, on voit que la valeur de la colonne wait_time croit jusqu’à atteindre 5000, mais ne dépasse jamais cette valeur : cette colonne affiche sa valeur en millisecondes, et montre bien que le processus cherche les processus bloqués toutes les 5 secondes.

Il faut aussi noter qu’avec cette configuration, si un processus reste bloqué 15 secondes, l’évènement sera généré 3 fois pour la même situation de blocage.

Capture avec SQL Profiler

Une fois cela fait, nous démarrons SQL Profiler, et dans l’onglet de sélection des évènements, dans la catégorie Errors and Warnings (et non pas dans la catégorie Locks), nous trouvons l’évènement Blocked process report :

Nous configurons l’évènement comme suit, où le champ TextData contiendra le document XML décrivant la situation de blocage :

N.B. : N’oubliez pas le champ Mode, qui procure le type de verrou acquis.

Capture avec les Évènements Étendus (XE)

Pour les lecteurs qui n’ont pas encore eu le temps de se familiariser avec cette fonctionnalité, qui est vouée au remplacement futur de SQL Profiler, et dont la puissance en fait mon outil de diagnostic favori, vous pouvez vous aider de l’article que j’ai publié sur le sujet.

Si l’on souhaite capturer en permanence toute situation de blocage, l’avantage revient à XE, puisqu’on peut stocker ces évènements dans une cible dite anneau de mémoire (ring buffer). Cette structure consomme très peu de mémoire et fonctionne à l’image d’un FIFO : lorsqu’il est plein, la capture d’un nouvel évènement donne lieu à l’éviction du plus vieil évènement pour le stockage de celui-ci. Avec SQL Profiler, il est nécessaire de mettre en place une trace côté serveur et de gérer le fichier de trace et l’espace disque. En revanche, une fois que l’on a démarré la session XE, on peut « l’oublier ».

Pour les lecteurs familiers de XE et de Profiler, sachez que le document XML produit par ces deux fonctionnalités pour un même évènement de blocage est identique, ce qui n’est pas le cas avec les deadlocks (XE produit un document XML mal formé, qui rend impossible son enregistrement en document de type .xdl en vue de son interprétation graphique dans SSMS).

La définition d’une telle session est simple :

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

-- Définition de la session
CREATE EVENT SESSION blocked_process_report_RB ON SERVER
ADD EVENT sqlserver.blocked_process_report
ADD TARGET package0.ring_buffer (SET MAX_MEMORY = 4096)
WITH (MAX_DISPATCH_LATENCY = 5 SECONDS)
GO

-- Démarrage de la session
ALTER EVENT SESSION blocked_process_report_RB ON SERVER
STATE = START

-- Vérification
SELECT name
, create_time
FROM sys.dm_xe_sessions
WHERE name = 'blocked_process_report_RB'

Le test

Pour l’exemple, nous avons la trace SQL Profiler et la session XE ci-dessus actifs.
Nous créons la table suivante :

1
2
3
4
5
6

CREATE TABLE blocked_process_report_test
(
cle varchar(16) NOT NULL
CONSTRAINT UQ_blocked_process_report_test UNIQUE CLUSTERED
, valeur tinyint NOT NULL
)

Puis, dans une première fenêtre de requête (A) sous SSMS, nous ajoutons la ligne suivante, sans valider la transaction :

1
2
3
4
5
6
7
8
9
10
11

BEGIN TRANSACTION
INSERT INTO dbo.blocked_process_report_test
(
cle
, valeur
)
VALUES
(
'TEST'
, 12
)

Dans une seconde fenêtre de requête (B), nous exécutons :

1
2
3

UPDATE dbo.blocked_process_report_test
SET valeur = 15
WHERE cle = 'TEST'

Ceci fait que la requête B doit attendre que la requête A soit terminée pour réaliser l’UPDATE, ce qui ne peut se faire que si l’on valide (COMMIT) ou annule (ROLLBACK) la transaction : nous ne le faisons pas ici, pour l’exemple. Nous laissons aussi la requête B s’exécuter 10 secondes, de façon à bien voir que l’évènement est capturé deux fois pour la même situation de blocage.

Ce que capture SQL Profiler

L’interface affiche bien deux captures de l’évènement :

Notez que les valeurs pour la colonne Duration sont données ici en microsecondes : on voit donc qu’il y a un léger décalage entre la détection du blocage et sa capture. Toutes les informations dont nous avons besoin sont donc sous nos yeux: la ressource à la source de la situation de blocage, ainsi que les requêtes impliquées dans celle-ci.

Il est possible de charger le fichier de trace dans une table à l’aide de la fonction sys.fn_trace_gettable(). Cela permet l’écriture d’une requête utilisant les méthodes SQLXML, qui extrait directement les informations intéressantes de chaque document XML. La requête est similaire à celle que je donne dans la section suivante.

Ce que capture la session XE

Ici il nous est nécessaire d’écrire une requête faisant appel aux fonctions SQLXML pour dépouiller le document XML sans se fatiguer :

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

SELECT DATEADD(hour, DATEDIFF(hour, GETUTCDATE(), GETDATE()), doc.value('(event/@timestamp)[1]', 'datetime')) AS log_date_time
, doc.value('(event/data[@name="transaction_id"]/value)[1]', 'bigint') AS transaction_id
, doc.value('(event/data[@name="database_name"]/value)[1]', 'nvarchar(128)') AS database_name
, doc.value('(event/data[@name="duration"]/value)[1]', 'int') / 1000 AS duration_ms
, doc.value('(event/data[@name="resource_owner_type"]/text)[1]', 'varchar(10)') AS resource_owner_type
, doc.value('(event/data[@name="lock_mode"]/text)[1]', 'varchar(10)') AS lock_mode
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocked-process/process/@waitresource)[1]', 'varchar(max)') AS wait_resource
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocked-process/process/@isolationlevel)[1]', 'varchar(max)') AS blocked_tran_iso_level
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocking-process/process/@isolationlevel)[1]', 'varchar(max)') AS blocking_tran_iso_level
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocked-process/process/inputbuf)[1]', 'varchar(max)') AS blocked_statement
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocking-process/process/inputbuf)[1]', 'varchar(max)') AS blocking_statement
FROM (
SELECT D.n.query('.') AS doc
FROM (
SELECT CAST(target_data AS xml) AS data
FROM sys.dm_xe_sessions AS S
INNER JOIN sys.dm_xe_session_targets AS ST
ON S.address = ST.event_session_address
WHERE S.name = 'blocked_process_report_RB'
AND ST.target_name = 'ring_buffer'
) AS sub
CROSS APPLY data.nodes('RingBufferTarget/event') AS D(n)
) AS T

La capture d’écran du résultat a été coupée en deux pour faciliter un peu la lecture :

Interprétation du résultat

Notre intérêt dans l’interprétation de ce document se portera sur la propriété waitresource, que l’on peut décrypter à l’aide de la documentation (Voir la section Waitresource).

Ici, waitresource est : KEY: 5:72057594039107584 (2158b2b5a6d5), ce qui signifie :

– Database ID : 5
– Partition ID : 72057594039107584
– (2158b2b5a6d5) : le hash de la clé d’index

Sur ce dernier point, il faut savoir que SQL Server utilise le hash, stocké sur 6 octets, de la clé de l’index qui supporte la requête. Ceci conduit SQL Server à générer des valeurs de hash identiques pour des valeurs de clé différentes, ce qui peut causer d’autre problèmes de concurrence d’accès. C’est une raison de plus pour choisir des clés d’index les plus « étroites » possible, de façon à éviter ce type de collisions.

Voyons comment retrouver la ressource qui a été verrouillée :

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

USE ELSUKET
GO

SELECT O.name AS table_name
, I.name AS index_name
, P.partition_number
, P.rows
FROM sys.partitions AS p
INNER JOIN sys.objects AS O
ON O.object_id = P.object_id
INNER JOIN sys.indexes AS I
ON P.object_id = I.object_id
AND P.index_id = I.index_id
WHERE p.partition_id = 72057594039107584

Voyons maintenant comment retrouver la clé qui a été utilisée :

1
2
3

SELECT *
FROM dbo.blocked_process_report_test WITH(INDEX = UQ_blocked_process_report_test)
WHERE %%lockres%% = '(2158b2b5a6d5)'

La fonction %%lockres%% n’est pas documentée : il est donc recommandé de l’utiliser avec parcimonie. La même méthodologie est utilisable dans le diagnostic des deadlocks.

Bon déblocage à tous !

ElSüket.

Quelles statistiques l’Optimiseur a-t-il utilisées pour calculer le plan de requête ?

elsuket — Thu, 06 Jun 2013 16:19:44 +0000

Si une bonne partie de votre temps de travail est consacrée à l’optimisation de requête et à la compréhension du fonctionnement de l’Optimiseur de Requêtes, vous vous êtes probablement demandé sur quelles statistiques celui-ci se base pour calculer le plan d’une requête.

Il existe un drapeau de trace non-documenté, n° 8666, qui permet d’ajouter au document XML qui décrit le plan de requête les statistiques utilisées par l’optimiseur pour générer le plan de requêtes.

Voyons comment l’utiliser avec une requête sur la base de données AdventureWorks2012 :

Avant toute chose, notez que ce drapeau de trace n’est pas documenté. Comme toute fonctionnalité non-documentée, on ne doit JAMAIS utiliser celui-ci sur une base de données ou une instance qui sert une charge de production. Si tel devait être le cas, je ne peux en aucun cas être tenu pour responsable des conséquences. Vous devez limiter strictement l’usage de cette instruction aux environnements de test.

Utilisons la requête suivante :

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

DBCC TRACEON (8666)
GO

USE AdventureWorks2012
GO

SELECT SOH.OrderDate
, SOH.DueDate
, SOH.ShipDate
, SOH.AccountNumber
, SOD.OrderQty
, SOD.UnitPrice
FROM Sales.SalesOrderHeader AS SOH
INNER JOIN Sales.SalesOrderDetail AS SOD
ON SOH.SalesOrderID = SOD.SalesOrderID

Demandons maintenant à SQL Server de générer le plan de requête estimé. Celui-ci s’obtient soit en pressant CTRL + L, soit par un clic sur l’icône suivante, présente dans la barre d’outils :

On obtiendra aussi les informations ajoutées par le drapeau de trace 8666 avec le plan d’exécution réel, que l’on obtient soit en pressant CTRL + M, soit par un clic sur l’icône, suivante présente elle aussi dans la barre d’outils :

Nous devons maintenant explorer le document XML à l’origine du plan d’exécution graphique, ce qui se fait par un simple clic droit dans une zone vierge de ce dernier :

Il nous suffit maintenant de chercher la chaîne de caractères wszStatName, et nous obtenons :

On voit clairement les détails de ce que SQL Server utilise comme métriques pour calculer le plan, notamment :

– le nom de la statistique (ici c’est la statistiques sous-jacente à l’index qui supporte la clé primaire)
– le nom de la colonne la plus à gauche dans cette statistique (wszColName)
– le nombre de lignes échantillonnées lors de la génération de la statique (m_ullSnapShotModCtr)
– le nombre de lignes présentes dans la table (m_ullRowCount)
– le seuil de recalcul automatique de la statistique (ullThreshold)

Pour cette dernière valeur, on peut d’ailleurs faire le calcul suivant :

100.0 * 24,763 / 121,317 = 20.41181367821492

Soit environ 20%. Prenons la partie décimale de ce pourcentage :

(0.41181367821492 / 100.0) * 121,317 = 499.5999999999945

Soit environ 500 lignes. Ceci vérifie bien la règle du seuil de recalcul automatique des statistiques pour les tables de plus de 8MB : 500 lignes + 20% du nombre de lignes de la table.

Bons calculs de plans de requêtes et estimations de cardinalités !

ElSüket

Une procédure stockée pour connaître l’état des fichiers du journal des transactions

elsuket — Mon, 11 Feb 2013 05:12:22 +0000

Ha ! le fichier du journal des transactions, l’option de récupération, son grossissement, … et bien sûr la fameuse transaction restée ouverte qui a provoqué une explosion de la taille de celui-ci, allant jusqu’à remplir le volume disque qui l’héberge : tout autant de paramétrages et d’investigations fastidieuses.

Alors comme je n’aime pas beaucoup répéter plusieurs fois les mêmes opérations sans avoir un script, ou mieux, une procédure stockée sous la main, j’ai créé la suivante, dont voici le script de création :

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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215

USE master
GO

-----------------------------------------------------------------
-- Nicolas Souquet - 09/02/2013
-- LA PROCEDURE STOCKEE SUIVANTE EST DONNEE EN TANT QUE TELLE
-- SON UTILISATION ET SA MODIFICATION EST A VOS RISQUES ET PÉRILS
-----------------------------------------------------------------
CREATE PROCEDURE [dbo].[sp__log_space_get]
@_database_name sysname = NULL
AS
BEGIN
SET NOCOUNT ON

DECLARE @sql varchar(256)

-- Récupération de l'espace disque disponible
-- sur tous les volumes visibles par l'instance SQL Server
DECLARE @free_disk_space TABLE
(
drive_letter char(1) NOT NULL
, free_space_MB int NOT NULL
)

INSERT INTO @free_disk_space
EXEC master.dbo.xp_fixeddrives

-- Récupération de l'occupation des fichiers des journaux de transaction
-- de toutes les bases de données hébergées par l'instance SQL Server
DECLARE @dbcc_sqlperf_logspace TABLE
(
database_name sysname
, log_size float
, log_space_used_pct decimal (5,2)
, status tinyint
)
INSERT INTO @dbcc_sqlperf_logspace
EXEC ('DBCC SQLPERF(logspace)')

-- Récupération de la liste de tous les fichiers virtuels
-- du fichier du journal des transactions de toutes les bases de données
-- disponibles, hébergées par l'instance SQL Server
DECLARE @dbcc_loginfo TABLE
(
recovery_unit_id tinyint -- new column in SQL Server 2012
, fileid tinyint NOT NULL
, file_size bigint NOT NULL
, start_offset bigint NOT NULL
, f_seq_no bigint NOT NULL
, status tinyint NOT NULL
, parity tinyint NOT NULL
, create_LSN varbinary(max) NOT NULL
)

-- Cas où l'on souhaite réaliser l'audit du fichier du journal des transactions
-- de toutes les bases de données hébergées par l'instance SQL Server
-- Dans ce cas le paramètre d'entrée @_database_name est à NULL
IF @_database_name IS NULL
BEGIN
DECLARE @dbcc_loginfo_all_db TABLE
(
database_name varchar(128)
, log_file_id tinyint
, vlf_count smallint
)

-- Récupération de liste de toutes les bases de données disponibles
-- (pas une capture iOFFLINE, SINGLE_USER, ou ... SUSPECT ;))
INSERT INTO @dbcc_loginfo_all_db
(
database_name
, log_file_id
, vlf_count
)
SELECT D.name
, MF.file_id
, 0
FROM sys.databases AS D
INNER JOIN sys.master_files AS MF
ON D.database_id = MF.database_id
WHERE D.source_database_id IS NULL -- ce n'est pas une capture instantanée de base de données
AND D.state_desc = 'ONLINE' -- la base de données est disponible
AND D.user_access_desc = 'MULTI_USER' -- la base de données est à l'écoute de connexions utilisateur
AND MF.type_desc = 'LOG' -- le type de fichier est "journal des transactions"

-- Pour chaque base de données, récupération de la liste des fichiers virtuels
-- du fichier du journal des transactions pour toutes les bases de données disponibles
WHILE EXISTS
(
SELECT *
FROM @dbcc_loginfo_all_db
WHERE vlf_count = 0
)
BEGIN
SELECT TOP 1 @_database_name = database_name
FROM @dbcc_loginfo_all_db
WHERE vlf_count = 0

SET @sql = 'DBCC LOGINFO (''' + @_database_name + ''')'

INSERT INTO @dbcc_loginfo
EXEC (@sql)

;WITH
CTE AS
(
SELECT fileid
, COUNT(*) AS vlf_count
FROM @dbcc_loginfo
GROUP BY fileid
)
UPDATE @dbcc_loginfo_all_db
SET vlf_count = C.vlf_count
FROM @dbcc_loginfo_all_db AS DLAD
INNER JOIN CTE AS C
ON DLAD.log_file_id = C.fileid
WHERE DLAD.database_name = @_database_name

DELETE FROM @dbcc_loginfo
END

-- Résultat final, avec addition de quelques détails
SELECT LS.database_name
, D.recovery_model_desc
, MF.name AS logical_name
, FDS.drive_letter AS transaction_log_file_stored_on
, FDS.free_space_MB AS volume_free_space_MB
, CAST(LS.log_size AS decimal(38,2)) AS transaction_log_file_size_MB
, LS.log_space_used_pct
, CAST((LS.log_space_used_pct / 100.0) * LS.log_size AS decimal(38,2)) AS log_used_size_MB
, CASE MF.is_percent_growth
WHEN 1 THEN CAST(MF.growth AS varchar(3)) + ' %'
ELSE CAST(MF.growth / 128 AS varchar(20)) + ' MB'
END AS growth
, D.log_reuse_wait_desc
, DLAD.vlf_count
, MF.physical_name
FROM sys.master_files AS MF
INNER JOIN @dbcc_sqlperf_logspace AS LS
ON LS.database_name = DB_NAME(MF.database_id)
INNER JOIN @free_disk_space AS FDS
ON FDS.drive_letter = LEFT(MF.physical_name, 1) COLLATE database_default
INNER JOIN sys.databases AS D
ON D.name = LS.database_name COLLATE database_default
INNER JOIN @dbcc_loginfo_all_db AS DLAD
ON DLAD.database_name = D.name COLLATE database_default
AND DLAD.log_file_id = MF.file_id
AND DLAD.database_name = DB_NAME(MF.database_id)
WHERE MF.type_desc = 'LOG'
AND D.source_database_id IS NULL
AND D.state_desc = 'ONLINE'
AND D.user_access_desc = 'MULTI_USER'
END
ELSE
BEGIN
-- Si la base de données que l'on souhaite auditer n'existe pas ==> exception
IF DB_ID(@_database_name) IS NULL
BEGIN
RAISERROR('The database named ''%s'' does not exist', 16, 1, @_database_name)
RETURN
END

-- récupération de la liste des fichiers virtuels
-- du fichier du journal des transactions de la base de données choisie
DECLARE @vlf_count int
SET @sql = 'DBCC LOGINFO (''' + @_database_name + ''')'

INSERT INTO @dbcc_loginfo
EXEC (@sql)

-- Résultat final, avec addition de quelques détails
;WITH
CTE AS
(
SELECT fileid
, COUNT(*) AS vlf_count
FROM @dbcc_loginfo
GROUP BY fileid
)
SELECT LS.database_name
, D.recovery_model_desc
, MF.name AS logical_name
, FDS.drive_letter AS transaction_log_file_stored_on
, FDS.free_space_MB AS volume_free_space_MB
, CAST(LS.log_size AS decimal(38,2)) AS transaction_log_file_size_MB
, LS.log_space_used_pct
, CAST((LS.log_space_used_pct / 100.0) * LS.log_size AS decimal(38,2)) AS log_used_size_MB
, CASE MF.is_percent_growth
WHEN 1 THEN CAST(MF.growth AS varchar(3)) + ' %'
ELSE CAST(MF.growth / 128 AS varchar(20)) + ' MB'
END AS growth
, D.log_reuse_wait_desc
, C.vlf_count AS VLF_count
, MF.physical_name
FROM sys.master_files AS MF
INNER JOIN @dbcc_sqlperf_logspace AS LS
ON LS.database_name = DB_NAME(MF.database_id)
INNER JOIN @free_disk_space AS FDS
ON FDS.drive_letter = LEFT(MF.physical_name, 1) COLLATE database_default
INNER JOIN sys.databases AS D
ON D.name = LS.database_name COLLATE database_default
INNER JOIN CTE AS C
ON C.fileid = MF.file_id
WHERE MF.type_desc = 'LOG'
AND LS.database_name = @_database_name
AND D.source_database_id IS NULL
AND D.state_desc = 'ONLINE'
AND D.user_access_desc = 'MULTI_USER'
END
END
GO

-- On marque la procédure stockée comme objet système
-- Dès lors, on pourra l'exécuter dans n'importe quel contexte de base de données
EXEC sp_ms_marksystemobject 'sp__log_space_get'

Elle donne un résultat comme le suivant :

à savoir :

– le nom de la base de données
– l’option de récupération de la base de données
– le nom logique du fichier du journal des transactions (utile pour un DBCC SHRINKFILE après que le journal ait explosé en taille)
– le volume sur lequel est hébergé le fichier du journal des transactions
– la quantité d’espace disque libre restant sur ce volume
– la taille actuelle du fichier du journal des transactions
– le pourcentage d’utilisation de ce fichier (taille occupée dans le fichier par rapport à la taille totale du fichier)
– la taille équivalente à ce pourcentage
– le paramètre de grossissement de ce fichier
– ce qui empêche actuellement la troncature de l’espace occupé dans ce fichier
– le chemin complet du fichier

On peut utiliser cette procédure stockée sous SQL Server 2005, 2008 et 2012.
Elle fonctionne également pour les bases de données ayant plusieurs fichiers du journal des transactions

Bonne gestion des fichiers du journal des transactions !

ElSüket

Marquer une procédure stockée comme objet système : la procédure stockée sp_MS_marksystemobject

elsuket — Tue, 19 Oct 2010 04:55:58 +0000

Il peut être intéressant de pouvoir utiliser une procédure stockée dans n’importe quel contexte de base de données (sur la même instance SQL Server).
Voyons comment faire cela à l’aide de la procédure stockée système non documentée sp_MS_marksystemobject

Je cherchai à fournir à mes collègues développeurs SQL un moyen de générer des instructions CRUD (INSERT, SELECT, UPDATE, DELETE) de façon propre et générique.
Voici donc l’exemple de l’INSERT (je publierai les autres dans un billet à venir) :

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

USE master
GO

CREATE PROCEDURE dbo.sp__generate_INSERT
@_table_name sysname,
@_nb_tab tinyint = 0
AS
BEGIN
SET NOCOUNT ON

DECLARE @sql varchar(max)
SELECT @sql = CASE
WHEN @sql IS NULL THEN REPLICATE(CHAR(9), @_nb_tab) + 'INSERT' + CHAR(9) + @_table_name + CHAR(13) + CHAR(10) + REPLICATE(CHAR(9), @_nb_tab) + '(' +
CHAR(13) + CHAR(10) + REPLICATE(CHAR(9), @_nb_tab) + CHAR(9) + name
ELSE @sql + CHAR(13) + CHAR(10) + REPLICATE(CHAR(9), @_nb_tab) + CHAR(9) + ', ' + name
END
FROM sys.columns
WHERE object_id = OBJECT_ID(@_table_name)
AND is_computed = 0
ORDER BY column_id

SET @sql = @sql + CHAR(13) + CHAR(10) + REPLICATE(CHAR(9), @_nb_tab) + ')'

PRINT @sql
END

Vous remarquerez que je me place dans le contexte de la base de données système master, qui est la seule dans laquelle vous pouvez marquer des procédures stockées comme objet système.

Un autre requis pour pouvoir utiliser une procédure stockée marquée comme objet système dans n’importe quel contexte de base de données de l’instance en cours, est de faire commencer le nom de la procédure stockée par « sp ».
Rien ne vous empêche de marquer la procédure stockée comme objet système, mais lorsque vous exécuterez une telle procédure stockée (dont le nom ne commence donc pas par « sp »), SQL Server « feindra » de ne pas trouver celle-ci.

Le marquage se fait de façon extrêmement simple, mais n’est pas documenté :

EXEC sp_MS_marksystemobject 'sp__generate_INSERT'

Et le tour est joué : vous pouvez générer le script d’INSERT en exécutant tout simplement :

1
2
3
4

USE maBD
GO

EXEC sp__generate_INSERT 'maTable'

Bonne génération !

ElSüket

Trouver l’espace disque occupé par les fichiers, et l’espace libre dans ceux-ci

elsuket — Wed, 12 May 2010 09:08:49 +0000

Voici quelques requêtes pour vous permettre d’auditer vos fichiers de base de données :

=> Par une requête

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

-------------------------------
-- Nicolas SOUQUET - 26/01/2010
-------------------------------
;WITH
CTE AS
(
SELECT name AS nomLogique,
physical_name AS nomPhysique,
CASE is_percent_growth
WHEN 0 THEN CAST(growth * 8 / 1024 AS VARCHAR(8)) + ' MB'
ELSE CAST(growth AS VARCHAR(3)) + ' %'
END AS accroissement,
CAST((size * 8) / CAST(1024 AS NUMERIC(14, 2)) AS NUMERIC(14, 2)) AS tailleFichier_MB,
CAST((FILEPROPERTY(name, 'SpaceUsed') * 8) / CAST(1024 AS NUMERIC(14, 2)) AS NUMERIC(14, 2)) AS espaceOccupe
FROM sys.database_files
)
SELECT nomLogique,
nomPhysique,
tailleFichier_MB,
accroissement,
espaceOccupe AS espaceOccupe_MB,
tailleFichier_MB - espaceOccupe AS espaceLibre_MB,
CAST((CAST(espaceOccupe AS NUMERIC(14, 2)) / tailleFichier_MB) * 100 AS NUMERIC(14, 2)) AS [%occupe],
CAST((CAST(tailleFichier_MB - espaceOccupe AS NUMERIC(14, 2)) / tailleFichier_MB) * 100 AS NUMERIC(14, 2)) AS [%libre]
FROM CTE

=> Avec l’instruction DBCC SHOWFILESTATS (non documentée):

Elle donne le nombre d’étendues (extents) occupées et le nombre total d’étendues allouées pour le fichier.
Une étendue étant constituée de 8 pages, et une page faisant 8192 octets, il vous faudra donc multiplier les nombres obtenus par 64Ko.

=> Avec la procédure stockée système sp_spaceused :

Elle retourne deux ensemble de résultats :
– l’espace occupé pour toute la base de données, mais attention seulement l’espace libre dans le fichier de données.
– le nombre de Ko réservés (= taille du fichier), utilisés (colonne data), dédiés aux index et inutilisés.

=> Avec l’instruction DBCC SQLPERF(logspace)

Celle-ci ne procure que la taille totale du fichier du journal des transactions, ainsi que son pourcentage d’occupation.

Bonne gestion d’espace disque

ElSuket.

=>=>=> 12/05/2010 : MAJ : un script pour connaître l’espace occupé par et dans les fichiers, pour toutes les bases de données d’une instance SQL Server :

-------------------------------
-- 12/05/2010 - Nicolas SOUQUET
-------------------------------
SET NOCOUNT ON
GO

DECLARE @sql varchar(1024)
SET @sql = 'SELECT name AS file_logical_name,' + CHAR(13) + CHAR(10) + CHAR(9) +
'physical_name AS file_physical_name,' + CHAR(13) + CHAR(10) + CHAR(9) +
'CASE is_percent_growth' + CHAR(13) + CHAR(10) + CHAR(9) + CHAR(9) +
'WHEN 0 THEN CAST(growth * 8 / 1024 AS varchar(8)) + '''' MB''''' + CHAR(13) + CHAR(10) + CHAR(9) + CHAR(9) +
'ELSE CAST(growth AS varchar(3)) + '''' %''''' + CHAR(13) + CHAR(10) + CHAR(9) +
'END AS file_growth,' + CHAR(13) + CHAR(10) + CHAR(9) +
'CAST((size * 8) / CAST(1024 AS numeric(14, 2)) AS numeric(14, 2)) AS file_size_MB,' + CHAR(13) + CHAR(10) + CHAR(9) +
'CAST((FILEPROPERTY(name, ''''SpaceUsed'''') * 8) / CAST(1024 AS numeric(14, 2)) AS numeric(14, 2)) AS file_used_space_MB' + CHAR(13) + CHAR(10) +
'FROM sys.database_files''' + CHAR(13) + CHAR(10)

DECLARE @exec_sql varchar(1024)

DECLARE @instance_database_file_space TABLE
(
database_name sysname
, file_logical_name sysname
, file_physical_name nvarchar(260)
, file_growth varchar(8)
, file_size_MB numeric(14,2)
, file_used_space_MB numeric(14,2)
, file_free_space_MB numeric(14,2)
, file_used_space_percent numeric(5,2)
, file_free_space_percent numeric(5,2)
)

DECLARE @database_file_space TABLE
(
file_logical_name sysname
, file_physical_name nvarchar(260)
, file_growth varchar(8)
, file_size_MB numeric(14,2)
, file_used_space_MB numeric(14,2)
)

DECLARE db_cur CURSOR LOCAL FAST_FORWARD FOR
SELECT name
FROM sys.databases
WHERE source_database_id IS NULL
FOR READ ONLY

DECLARE @database_name sysname

OPEN db_cur
FETCH NEXT FROM db_cur INTO @database_name
WHILE @@fetch_status = 0
BEGIN
DELETE @database_file_space

SET @exec_sql = 'EXEC ' + @database_name + '.dbo.sp_executeSQL N''' + @sql + ''

BEGIN TRY
INSERT @database_file_space
EXEC (@exec_sql)
END TRY
BEGIN CATCH
PRINT @database_name + ' : ' + ERROR_MESSAGE()
END CATCH

INSERT @instance_database_file_space
SELECT @database_name
, file_logical_name
, file_physical_name
, file_growth
, file_size_MB
, file_used_space_MB
, file_size_MB - file_used_space_MB AS file_free_space_MB
, CAST((CAST(file_used_space_MB AS numeric(14, 2)) / file_size_MB) * 100 AS numeric(14, 2)) AS file_used_space_percent
, CAST((CAST(file_size_MB - file_used_space_MB AS numeric(14, 2)) / file_size_MB) * 100 AS numeric(14, 2)) AS file_free_space_percent
FROM @database_file_space

FETCH NEXT FROM db_cur INTO @database_name
END
CLOSE db_cur
DEALLOCATE db_cur

SELECT *
FROM @instance_database_file_space

Il arrive que la procédure stockée système sp_executeSQL ne soit pas trouvée dans la base de données.
Quand tel est le cas, la liste des bases de données est affichée dans la console de SSMS.

Nomination MVP

elsuket — Thu, 01 Oct 2009 21:52:02 +0000

Je viens d’être nominé MVP SQL Server, et je souhaite associer à ce titre, et remercier toutes les personnes qui maintiennent ce site, et qui participent aux forums.

Je tiens à remercier plus particulièrement SQLPro qui m’a parrainé pour l’obtention de ce titre.

Je continuerai à contribuer à ce forum aussi fidèlement que je le fais depuis deux ans, tout simplement parce que cela me fait plaisir, et en me concentrant plus sur la publication d’articles complets.

@++

ElSuket

Les dangers de la vérification de l’intégrité des données : la commande DBCC CHECKDB

elsuket — Thu, 17 Sep 2009 21:16:20 +0000

La plupart du temps, lorsqu’on pose la question à des personnes qui débutent sous SQL Server, la réponse à la question : « comment faites-vous pour résoudre une erreur de page déchirée ou de somme de contrôle « , la réponse est bien souvent : « j’utilise la commande DBCC CHECKDB avec l’option REPAIR_ALLOW_DATA_LOSS » …

Et là, c’est le drame, car il existe avant cette options bien d’autres solutions.

Comme vous allez le voir, l’option REPAIR_ALLOW_DATA_LOSS est une option à utiliser en dernier recours, tellement les dégâts qu’elle peut causer sont dangereux …

Comment, dès lors, utiliser la commande DBCC CHECKDB, dont l’utilité n’est ici pas remise en cause, bien au contraire !
Si vous avez choisi la bonne stratégie de sauvegarde suivant le métier qui fait vivre la base de données, vous devez en plus effectuer, au pire par abus de conscience, un contrôle d’intégrité, à une fréquence adaptée elle aussi au métier de l’entreprise.
Pour une base de données utilisée qui doit être hautement disponible, on peut préférer par exemple vérifier l’intégrité de celle-ci tous les jours à l’aide de l’instruction suivante :

DBCC CHECKDB ('maBD') WITH NO_INFOMSGS

L’option WITH NO_INFOMSGS ne montre pas tous les messages d’information qui sont normalement retournées sans cette option (nombre de pages vérifiées par table, …).
En revanche, on verra toujours les erreurs apparaître.
Il sera donc pratique de faire exécuter cela par un job à une heure de faible activité sur la base de données, et d’adjoindre au job un fichier de sortie pour pouvoir consulter a posteriori ce fichier.

Comme cette option peut consommer une quantité de ressources système élevée, on peut tout à fait se rabattre sur :

DBCC CHECKDB ('maBD') WITH PHYSICAL_ONLY, NO_INFOMSGS

Cette instruction permet de ne vérifier les structures sur disque, sans scruter les structures logiques internes aux pages de la base de données.

Revenons à nos moutons : nous avons détecté un problème d’intégrité dans la base de données, et maintenant, que fait-on ?

Si, comme nous l’avons vu un peu plus haut, nous avons choisi la bonne stratégie de sauvegarde, alors nous sommes sauvés.
Restaurer une base de données corrompue est de loin la meilleure solution à employer pour passer outre une corruption de données, mais il existe encore, avant de prendre cette décision qui peut être lourde de conséquences dans certains contextes, bien d’autres possibilités.
Voyons à quoi ressemble une erreur de corruption de page :

Msg 8928, Level 16, State 1, Line 1
Object ID 2078435228, index ID 0, partition ID 72342401522583797, alloc unit ID 72385201253561693 (type In-row data): Page (1:62418) could not be processed. See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 2078435228, index ID 0, partition ID 72342401522583797, alloc unit ID 72385201253561693 (type In-row data), page (1:62418). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed.
CHECKDB found 0 allocation errors and 2 consistency errors in table ‘elsuket’ (object ID 2078435228).
CHECKDB found 0 allocation errors and 2 consistency errors in database ‘elsuket’.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (ELSUKET).

Comme on le voit, la page corrompue nous est précisée.
Il serait avantageux de savoir à quel objet appartient cette page, car :

– si c’est un index non-cluster, il suffit de reconstruire celui-ci (ce n’est pas le cas avec un index cluster)
– si c’est un autre type d’objet, nous pouvons utiliser l’option PAGE de l’instruction RESTORE DATABASE.

Notons que cette dernière possibilité n’est possible que dans le mode de restauration FULL.
Examinons maintenant la page qui est corrompue.
Malheureusement cela nécessite de connaître des drapeaux de trace et instructions qui ne sont pas documentés :

1
2
3
4

DBCC TRACEON (3604, -1)
GO
DBCC PAGE('ELSUKET', 1, 62418, 3)
GO

Le drapeau de trace 3604 est utilisé ici pour remonter les traces d’exécution de toute commande DBCC au client de la session de l’utilisateur.

La commande DBCC PAGE est ici spécifiée comme suit :

– ‘ELSUKET’ est le nom de la base de données,
– 1 est le numéro de fichier (c’est le même numéro que celui qui précède le numéro de page dans le résultat de la commande DBCC CHECKDB )
– 62418 est le numéro de page
– 3 est l’option de suivi de scrutation des pages : on aura l’en-tête de buffer, l’en-tête de page, chaque ligne de données que stocke la page, la table des offsets de lignes.

Dans le listing, nous trouverons des repères nommés MetaData, et nous pourrons trouver, par exemple :

1
2
3
4

MetaData: AllocUnitId = 72385201253561693
MetaData: PartitionId = 72342401522583797
MetaData: ObjectId = 2078435228
Metadata: IndexId = 1

C’est plus précisément Metadata: IndexId qui nous intéresse ici :

– S’il est plus grand que 1, il s’agit d’une index non-cluster, donc il suffit de le supprimer et de la reconstruire
– S’il vaut 0 ou 1, nous devons résoudre le défaut d’intégrité de façon plus complexe.

=> Restauration de pages à partir d’une sauvegarde de la base de données

On peut tout simplement restaurer la page concernée à partir de notre sauvegarde, en ayant au préalable sauvegardé la queue du fichier du journal des transactions, c’est à dire le journal des transactions courant.
Il faut alors restaurer la dernière sauvegarde complète, puis l’éventuelle dernière sauvegarde différentielle, puis les journaux de transaction dans l’ordre où ils ont été sauvegardés, pour enfin restaurer la queue de celui-ci, mais avec l’option NORECOVERY de l’instruction RESTORE.

Si peu de pages sont corrompues, on peut alors décider de les restaurer une à une à partir de la base de données fraîchement restaurée :

1
2
3

RESTORE DATABASE ELSUKET PAGE = '1:62418'
FROM DISK = 'C:\ELSUKET.bak'
WITH NORECOVERY

Rappelons que cela n’est possible que dans le mode de restauration FULL.
Si la base de données utilise le mode de restauration SIMPLE, alors on devra restaurer la base de données à partir de la dernière sauvegarde complète et des éventuelles sauvegardes différentielles, mais on perdra les données qui ont été ajoutées ou modifiées entre l’heure de terminaison des sauvegardes et maintenant.

=> La réparation automatique, et ses dangers

Il est important, avant de choisir parmi les options de réparation de corruption, l’option qui convient :

– REPAIR_ALLOW_DATA_LOSS
– REPAIR_REBUILD

Si nous revenons à la trace produite par l’exécution de la commande DBCC CHECKDB, on trouve dans celle-ci le niveau de correction à adopter :

repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (ELSUKET)

Si l’option proposée est REPAIR_REBUILD, vous l’avez échappé belle : il n’y aucun risque de perte de données : il s’agira pour le moteur de base de données de réparer des clés manquantes dans les index non-cluster, ou bien de reconstruire un index.

Si en revanche vous avez, comme ici, l’option REPAIR_ALLOW_DATA_LOSS, comme le dit si bien cette options, il est possible que vous perdiez des données (d’où l’importance des sauvegardes).
En effet, cette commande peut par exemple supprimer la page et la ré-allouer pour faire « croire » que celle-ci n’a en fait jamais existé…

En conclusion : bichonnez vos sauvegardes !

Pour aller plus loin, je vous propose cet article de Mikedavem : La vérification d’intégrité et les problématiques liées aux VLDB

Connaître l’état d’un service : xp_servicecontrol

elsuket — Sat, 27 Jun 2009 06:32:18 +0000

Comment connaître simplement l’état d’un service ?
Est-il possible d’arrêter et de démarrer un service avec une requête ?

La procédure stockée système étendue non documentée xp_servicecontrol permet de connaître l’état d’un service :

EXEC master.dbo.xp_servicecontrol 'QUERYSTATE', 'MSSQLServer'

Retourne bien sûr :

mais peut retourner les états suivants :

1
2
3
4
5
6

- "Stopped."
- "Running."
- "Stopping."
- "Starting."
- "Unknown."
- "ErrorRetrieving."

On peut aussi démarrer un service :

EXEC master.dbo.xp_servicecontrol 'START', 'MSSQLServer'

ou encore l’arrêter :

EXEC master.dbo.xp_servicecontrol 'STOP', 'MSSQLServer'

Il peut être pratique de connaître l’état de services par ce biais, lorsque l’on administre une instance de SQL Server avec l’utilitaire en ligne de commande SQLCMD (ancien OSQL) et une connexion DAC, ou encore encapsuler ce résultat dans un rapport SSRS sur l’état d’un serveur et de ses applications …

ElSuket