Le blog de SQLpro » SQL Server 2008

Une peste nommée NOLOCK… et comment l’éviter

SQLpro — Sun, 08 Jul 2018 14:55:07 +0000

L’utilisation du tag de table NOLOCK, hélas largement prisé par de nombreux développeurs, est, la plupart du temps, une absurdité conduisant à des résultats potentiellement faux. Est-il possible de faire autrement pour minimiser les blocages induit par les verrouillages dans SQL Server ? Réponse OUI !

À la suite de cette remarque :
« …je passe aussi sur le NOLOCK qui est une véritable connerie en production et donne des valeurs fausses ! »
Publiée ici :

Mon interlocuteur me répondais :
« Merci pour cette précision. Comme vous abordez le sujet du NOLOCK effectivement j’ai constaté certaines fois en production on avait des valeurs totalement erronées, mais je n’arrivais pas à me l’expliquer. J’ai maintenant une piste et je vais creuser du côté du NOLOCK que nous utilisons beaucoup en production sur une base de données CRM 2013. Aussi par quoi pouvons nous remplacer le NOLOCK ?? »

Je lui donnais donc l’explication suivante…

Le « NOLOCK » peut parfaitement se remplacer par le niveau d’isolation SNAPSHOT par exemple…

NOLOCK ne signifie pas « je ne pose pas de verrou« , mais plus précisément : « j’ignore qu’il y a des verrous et je lit ce que je peut » (ceci est plus connu dans la littérature professionnelle sous le nom de lecture dans le chaos…). Vous pouvez donc lire plusieurs fois les mêmes données ou encore ne pas lire certaines.

Quid du mode SNAPSHOT ?

SNAPSHOT fait du verrouillage optimiste pour les lectures. Par défaut SQL Server fait du verrouillage pessimiste, c’est à dire que les lectures posent des verrous qui permettent d’autres lectures concurrentes (verrous partagés, mode « SHARE »), mais empêchent les écritures des autres utilisateurs. Conceptuellement, le verrouillage optimiste (donc via le mode d’isolation SNAPSHOT) fait une copie (si besoin) des données avant de permettre leurs lectures. Comme vous travaillez sur une copie, les utilisateurs concurrent peuvent modifier les vraies ligne sans que cela vous concerne. Bien entendu il peut toujours y avoir des conflits, mais cela réduit considérablement le nombre de verrous bloquants tout en gardant l’intégrité et la consistante de la base, ce qui n’est pas du tout le cas du NOLOCK.

Alors, à quoi sert le NOLOCK ?

Cela peut servir pour certains cas ou l’on désire des résultats dont on se fout de l’intégrité ou de la précision. Souvent dans le domaine de la statistique.
par exemple si vous voulez savoir combien les français ont d’enfant par foyer et scrutez donc, pour ce faire, une table de 60 millions de lignes (population française), je ne suis pas sûr que dans un camembert représentant la chose, on fasse la distinction des quelques pixels de l’imprécision de la 6e décimale du résultat liées à quelques mauvaises lectures de lignes !
On utilise d’ailleurs très souvent le NOLOCK pour des tâches d’administration systèmes dans SQL Server afin d’éviter tout blocage au risque de perdre quelques lignes, ce qui n’a pas toujours une importance capitale lorsque l’on veut remonter quelques informations concernant les 20% de requêtes les moins performantes !

Mais alors, le SNAPSHOT fait la même chose en mieux ?

Oui et non… Certes il permet de garantir l’intégrité, la consistance, etc… mais son mécanisme est plus lourd (un peu moins rapide) et consomme des ressources pour générer les copies (SNAPSHOT). Rassurez-vous il est assez malin pour ne faire ces copies qui s’il a besoin de les faire… En d’autres termes si aucun utilisateur concurrent veut faire des modif sur le jeu de lignes que vous manipulez en mode SNAPSHOT, aucune copie ne sera générée. Mais si, lorsque vous avez démarré une lecture en mode SNAPSHOT, un utilisateur concurrent veut modifier des lignes, et bien la copie sera réalisée au cours de votre lecture sans que vous vous en aperceviez… En quelque sorte le système fonctionne à l’envers… Bien évidemment il faut un espace de stockage pour ces copies et c’est la base tempdb qui s’y colle. Il faut donc, la dimensionner correctement…
Tiens, à nouveau un travail de DBA !

Des conflits ! Quels conflits ?

J’ai précédemment parlé de conflits possible avec l’utilisation du mode SNAPSHOT. En effet, si vous voulez modifier des données lors d’une transaction en mode d’isolation SNAPSHOT, c’est possible, mais ces modifications seront faites sur la copie, et non sur la base originale, et seront reportées sur la base originale au moment du COMMIT. Deux hypothèses se font alors jour :
■ soit aucune ligne visée par vos modifications faites en mode SNAPSHOT n’a été modifié dans une autre session directement sur la base, alors la mise à jour est appliquée.
Ou alors :
■ s’il existe au moins une ligne qui a été modifiée par une autre session entre temps sur la base originale, alors vos modifications ne pourront être appliquées aux données originales et vont êtres abandonnées.
Dans ce dernier cas vous obtiendrez une message d’erreur (3960) assez abscons, qui indique :
« La transaction d’isolement d’instantané a été abandonnée en raison d’un conflit de mise à jour. … »

Notez qu’il existe un autre tag plus intéressant que le NOLOCK…. Le READPAST !… Qui fait presque la même chose, mais ignore tout ce qui est verrouillé !

Les modes d’isolation selon la norme SQL

Sachez que le mode d’isolation SNAPSHOT ne fait pas partie de la norme SQL qui n’autorise que les modes d’isolation suivants :
0 – READ UNCOMMITTED : lecture des données invalides (non « committées »)
1 – READ COMMITTED : lecture de données valides (ce qui n’empêche pas certaines anomalies transactionnelles comme la lecture non répétable, ou l’apparition de lignes fantômes)
2 – REPEATABLE READ : lecture répétable de données (ce qui n’empêche pas certaines anomalies transactionnelles comme l’apparition de lignes fantômes)
3 – SERIALIZABLE : lecture en mode série (aucun accès concurrent aux tables lors des mises à jour, ce qui empêche toute anomalies)
Évidemment plus on monte le niveau d’isolation, plus le verrouillage est important et moins les accès concurrents peuvent travailler.
La norme SQL considère que les manipulation des données doivent porter sur des valeurs « vivantes ». Hors, en utilisant le mode SNAPSHOT et son versionnement des lignes, ont est appelé à lire potentiellement des valeurs antérieurs des données, ce n’est donc pas une lecture de l’état actuel des valeurs dans la base…

Pour informations, des SGBRD comme Oracle, ou PostGreSQL fonctionnent nativement en mode d’isolation SNAPSHOT, autrement dit utilisent systématiquement le verrouillage optimiste et ne savent pas faire autres choses (verrouillage pessimiste en particulier) voir ne savent même pas utiliser certains autres niveau d’isolation. Par exemple PostGreSQL ne permet pas de faires des transaction en mode READ UNCOMMITTED et Oracle ne permettent pas d’utiliser le niveau d’isolation REPEATABLE READ…

Activer le mode s’isolation SNAPSHOT

Pour permettre ce mode d’isolation, vous devez d’abord autoriser la base à utiliser le mode SNAPSHOT. Ce paramétrage est à deux niveaux :

ALTER DATABASE { CURRENT | nom_base } SET ALLOW_SNAPSHOT_ISOLATION ON;

permet d’utiliser à tout moment le mode d’isolation SNAPSHOT qui doit être introduit préalablement par la commande SET TRANSACTION ISOLATION SNAPSHOT ou par un tag de table (SNAPSHOT)
… et :

ALTER DATABASE { CURRENT | nom_base } SET READ_COMMITTED_SNAPSHOT ON;

qui place d’office toutes les lectures en mode SNAPSHOT (comme le fait Oracle ou PostGreSQL);
ATTENTION : pour assurer le versionnement des lignes, SQL Server rajoute à toutes les lignes de toutes les tables une information de version qui est codé sur 14 octets. Ceci peut prendre du temps à mettre en œuvre, en particulier sur de grosses bases.

Appendice :

Pour une démonstration des effets du NOLOCK : http://mssqlserver.fr/les-dangers-du-nolock/

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES
Expert S.G.B.D relationnelles et langage S.Q.L
Moste Valuable Professionnal Microsoft SQL Server
Société SQLspot : modélisation, conseil, formation,
optimisation, audit, tuning, administration SGBDR
Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Extraire le code des requêtes d’un verrou mortel traqué par un graphe « deadlock » du profiler

SQLpro — Thu, 22 Feb 2018 18:26:45 +0000

L’outil profiler de SQL Server permet de partir à la chasse au verrous mortel et peut récupérer le graphe du verrouillage des éléments concurrents et notamment les données technique de la victime. Mais ce graphe est en fait un document XML contenant toutes les informations sur les processus en jeu, la victime et les survivants. Il est alors intéressant d’en extraire les requêtes fautives afin de corriger son code ou d’indexer les tables, quelques un des moyens de se débarrasser des interblocages…

Pour détecter les verrous mortels, il suffit de demander au profiler de tracer les événements de type « deadlock » de la catégorie « locks », à savoir :

Deadlock graph
Lock: Deadlock
Lock Deadlock Chain

Événements à cocher pour auditer les verrous mortels de SQL Server

Une foi enregistrés, les données du profiler peuvent être vues par le client graphique sous cette forme :

Lecture des informations de verrous mortels dans le client graphique du profiler de SQL Server

Néanmoins, il faut passer à l’aide de sa souris sur chacune des bulles représentant les processus pour obtenir le texte des requêtes en jeu. Les rectangles visualisant les verrous, les pattes formant le graphe, qui lorsqu’il présente un cycle contient un interblocage.

Dès lors, on peut récupérer les fichiers générés sous forme SQL via la fonction table sys.fn_trace_gettable dont le premier argument est le chemin de stockage des fichiers de trace du profiler et le second le numéro du fichier concerné. On peut aussi tous les obtenir en mettant le mot clef DEFAULT.
L’événement de graphe de verrouillage étant de classe 148, il suffit ensuite de filtrer sur ces lignes.
Exemple :

SELECT *
FROM sys.fn_trace_gettable('C:\SQL_TRACE\20180219_14H30_DEADLOCK_.trc', default)

La colonne TextData de cette table virtuelle contient alors le XML donnant toutes les informations sur le verrou mortel. En voici un exemple :

Document XML montrant toutes les informations d’un verrou mortel survenu dans SQL Server

Avec une requête mêlant du SQL et du XML via XQuery et XPath, il est possible d’extraire ce qui nous intéresse, à savoir, le texte des requêtes en jeu ainsi qu’une indication disant quelle est la victime et les survivants. Et comme il n’y a pas qu’un seul interblocage en général, alors on les identifie par un numéro. la requête au final ressemble à cela :

WITH
TX AS
(
SELECT StartTime, CAST(TextData AS xml) AS TextData
FROM sys.fn_trace_gettable('C:\! FB\Rhenus\2018-02-19\20180219_14H30_DEADLOCK_.trc', DEFAULT)
WHERE EventClass = 148
),
TVM AS
(
SELECT StartTime,
v.VALUE('(./inputbuf)[1]','nvarchar(max)') AS Query,
i.VALUE('(./deadlock/@victim)[1]','varchar(32)') AS ProcessVictim,
v.VALUE('(./@id)[1]','varchar(32)') AS ProcessID
FROM TX
CROSS APPLY TextData.nodes('/deadlock-list') AS X(i)
CROSS APPLY TextData.nodes('/deadlock-list/deadlock/process-list/process') AS V(v)
),
TVV AS
(
SELECT DENSE_RANK() OVER (ORDER BY StartTime) AS ID,
StartTime,
Query,
CASE WHEN ProcessVictim = ProcessID THEN 'Victim!' ELSE 'Alive' END AS FinalState
FROM TVM
),
TQV AS
(
SELECT ID, Query
FROM TVV
WHERE FinalState = 'Victim!'
)
SELECT TVV.ID, TVV.StartTime, TVV.Query,
CASE WHEN TQV.ID IS NOT NULL THEN 'Victim!' ELSE 'Alive' END AS FinalState
FROM TVV
LEFT OUTER JOIN TQV
ON TVV.ID = TQV.ID AND TVV.Query = TQV.Query
ORDER BY 1;

Au final une telle requête permet de présenter les informations suivantes :

Visualisation des requêtes en jeu dans un verrou mortel

Notez au passage le colonne « FinalState » indiquant quelle requête a été victime et celles ayant survécus.

Le code ! Le code ! Le code ! Le code ! Le code ! Le code ! Le code ! Le code ! Le code ! Le code !

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Métrique de volumétrie du stockage par table, index et partition

SQLpro — Wed, 07 Feb 2018 09:19:04 +0000

Voici une petite requête complémentaire pour mesurer les volumes stockées par partition, index et tables d’une base :

SELECT s.name AS TABLE_SCHEMA, o.name AS TABLE_NAME, i.name AS INDEX_NAME,
fs.name AS FILEGROUP_NAME, f.name AS FILE_NAME, f.physical_name, p.partition_number,
p.ROWS, p.data_compression_desc, au.total_pages * 8 AS SIZE_TOTAL_KO,
SUM(au.total_pages * 8) OVER(PARTITION BY i.name, s.name, o.name) AS SIZE_TOTAL_INDEX_KO,
SUM(au.total_pages * 8) OVER(PARTITION BY s.name, o.name) AS SIZE_TOTAL_TABLE_KO
FROM sys.partitions AS p
JOIN sys.allocation_units AS au
ON p.hobt_id = au.container_id
JOIN sys.filegroups AS fs
ON au.data_space_id = fs.data_space_id
JOIN sys.database_files AS f
ON fs.data_space_id = f.file_id
JOIN sys.objects AS o
ON p.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.indexes AS i
ON p.object_id = i.object_id
AND p.index_id = i.index_id;

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Vérification de la dernière sauvegarde d’une base

SQLpro — Thu, 01 Feb 2018 10:51:55 +0000

Parmi les opérations importantes à systématiser, la vérification de consistance d’une sauvegarde est une opération à ne pas négliger. Mais compte tendu qu’une sauvegarde peut être multi-famille (donc répartie sur plusieurs fichiers), multi-support (donc redondées dans plusieurs destinations) ou intégré dans un « device » (donc noyée au milieu de plusieurs sauvegarde dans un fichier), la complexité augmente d’autant. Voici donc une petite procédure pour ce faire…

CREATE PROCEDURE P_VERIFY_LAST_BACKUP @DB sysname
AS

SET NOCOUNT ON;

DECLARE @SQL NVARCHAR(MAX) = N'';

WITH
T0 AS
(
SELECT TOP 1 media_set_id, POSITION
FROM msdb.dbo.backupset
WHERE database_name = @DB
ORDER BY backup_start_date DESC
)
SELECT @SQL = @SQL + N'RESTORE VERIFYONLY FROM DISK = '''
+ physical_device_name + N''' WITH FILE = '
+ CAST(POSITION AS VARCHAR(32)) + N';'
FROM msdb.[dbo].[backupmediafamily] AS mf
JOIN T0 ON mf.[media_set_id] = T0.media_set_id;

PRINT @SQL;

EXEC (@SQL);

GO

Exemple d’utilisation :

EXEC P_VERIFY_LAST_BACKUP ‘master';

Le code !

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Développez et administrez pour la performance avec SQL Server 2014

Agrégation des statistiques d’IO d’une requête

SQLpro — Thu, 28 Dec 2017 18:55:58 +0000

Si le paramétrage SET STATISTICS IO ON de Microsoft SQL Server permet de savoir, table par table les statistiques d’entrées/sorties (IO pour Input/Output) des requêtes, il n’est pas toujours facile de s’y repérer lorsque la requête est complexe et fait appel à de multiples tables. Voici une procédure qui en effectue la synthèse.

Rappelons que les statistiques IO sont le nombre de pages lues par le moteur SQL pour exécuter une requête. Le paramètre de session STATISTICS IO peut être mis à ON ou OFF. Par défaut il est à OFF. Mis sur ON, il permet, dans SQL Server Management Studio (SSMS), de voir le nombre de pages accédées pour une requête ou un lot de requête. C’est une série de message d’une ligne commençant par « Table… » qui suit immédiatement le message indiquant le nombre de lignes affectées par la requête.

SQL Server onglet message STATISTICS IO

Néanmoins il est assez difficile de lire tout cela et d’en déduire une tendance globale.
Ne serait-ce pas plus intéressante de les présenter de cette manière :

Statistiques IO SQL Server avec totaux et agrégation

La petite procédure que voici permet justement d’effectuer cette tâche. Il suffit de lui passer le texte complet des message d’IO et elle vous retournera tout cela, formaté, totalisé et agrégé !

USE msdb;
GO

CREATE SCHEMA S_DBA;
GO

CREATE PROCEDURE S_DBA.P_SPLIT_STATS_IO @DATA NVARCHAR(MAX)
AS
SET NOCOUNT ON;
DECLARE @LINE NVARCHAR(MAX), @SQL NVARCHAR(MAX) = N'';
DECLARE @L TABLE (LINE NVARCHAR(800));
DECLARE @T TABLE (TABLE_NAME sysname,
SCAN_COUNT BIGINT,
LOGICAL_READS BIGINT,
PHYSICAL_READS BIGINT,
READ_AHEAD_READS BIGINT,
LOB_LOGICAL_READS BIGINT,
LOB_PHYSICAL_READS BIGINT,
LOB_READ_AHEAD_READS BIGINT);

WHILE CHARINDEX(NCHAR(13) + NCHAR(10), @DATA) > 0
BEGIN
SET @LINE = LEFT(@DATA, CHARINDEX(NCHAR(13) + NCHAR(10), @DATA) - 2);
INSERT INTO @L SELECT @LINE;
SET @DATA = RIGHT(@DATA, LEN(@DATA) - CHARINDEX(NCHAR(13) + NCHAR(10), @DATA) - 1);
END;
INSERT INTO @L SELECT @DATA;
DELETE @L WHERE LINE = N'' OR LINE NOT LIKE N'%Table %' COLLATE French_BIN;

IF NOT EXISTS(SELECT *
FROM @L
WHERE LINE NOT LIKE '%Nombre d''analyses%')
--> français
BEGIN
UPDATE @L SET LINE = REPLACE(LINE, 'Table ', '');
UPDATE @L SET LINE = REPLACE(LINE, '. Nombre d''analyses ', ',');
UPDATE @L SET LINE = REPLACE(LINE, ' lectures logiques ', '');
UPDATE @L SET LINE = REPLACE(LINE, ' lectures physiques ', '');
UPDATE @L SET LINE = REPLACE(LINE, ' lectures anticipées ', '');
UPDATE @L SET LINE = REPLACE(LINE, 'de données d''objets volumineux ', '');
UPDATE @L SET LINE = REPLACE(LINE, '.', '');
END;

IF NOT EXISTS(SELECT *
FROM @L
WHERE LINE NOT LIKE '%Scan count%')
--> anglais
BEGIN
UPDATE @L SET LINE = REPLACE(LINE, 'Table ', '');
UPDATE @L SET LINE = REPLACE(LINE, '. Scan count ', ',');
UPDATE @L SET LINE = REPLACE(LINE, ' logical reads ', '');
UPDATE @L SET LINE = REPLACE(LINE, ' physical reads ', '');
UPDATE @L SET LINE = REPLACE(LINE, ' read-ahead reads ', '');
UPDATE @L SET LINE = REPLACE(LINE, 'lob', '');
UPDATE @L SET LINE = REPLACE(LINE, '.', '');
END;

SELECT @SQL = @SQL + 'SELECT ' + LINE + ' UNION ALL ' FROM @L;
SET @SQL = LEFT(@SQL, LEN(@SQL) - 10)

INSERT INTO @T
EXEC (@SQL);

WITH
T AS
(
SELECT *
FROM @T
UNION ALL
SELECT '°°° TOTAL °°°', SUM(SCAN_COUNT),
SUM(LOGICAL_READS), SUM(PHYSICAL_READS), SUM(READ_AHEAD_READS),
SUM(LOB_LOGICAL_READS),SUM(LOB_PHYSICAL_READS),SUM(LOB_READ_AHEAD_READS)
FROM @T
)
SELECT *
FROM T
ORDER BY CASE WHEN TABLE_NAME = '°°° TOTAL °°°' THEN 1 ELSE 0 END,
LOGICAL_READS DESC;

SELECT SUM(SCAN_COUNT) AS TOTAL_SCANS,
SUM(LOGICAL_READS + LOB_LOGICAL_READS) AS TOTAL_LOGICAL_READS,
SUM(PHYSICAL_READS + READ_AHEAD_READS +
LOB_PHYSICAL_READS + LOB_READ_AHEAD_READS) AS TOTAL_PHYSICAL_READS
FROM @T;

GO

Exemple d’utilisation :

EXECUTE msdb.S_DBA.P_SPLIT_STATS_IO 'Table ''PARAM_EAC''. Nombre d''analyses 13, lectures logiques 26, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''Worktable''. Nombre d''analyses 0, lectures logiques 0, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''VAL_PARAM_EAC''. Nombre d''analyses 1, lectures logiques 59, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''ESP''. Nombre d''analyses 49, lectures logiques 31, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''TL_EXP_COOP''. Nombre d''analyses 49, lectures logiques 178, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''UC''. Nombre d''analyses 49, lectures logiques 5633, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''TL_PP_UC''. Nombre d''analyses 49, lectures logiques 1254, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''PG''. Nombre d''analyses 49, lectures logiques 85289, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''Worktable''. Nombre d''analyses 0, lectures logiques 0, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''PG''. Nombre d''analyses 1, lectures logiques 437, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''PP''. Nombre d''analyses 49, lectures logiques 7271, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''EXP''. Nombre d''analyses 49, lectures logiques 1996, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.
Table ''VAR''. Nombre d''analyses 49, lectures logiques 866, lectures physiques 0, lectures anticipées 0, lectures logiques de données d''objets volumineux 0, lectures physiques de données d''objets volumineux 0, lectures anticipées de données d''objets volumineux 0.'

Le résultat :

Les statistiques d’IO d’une requête, sous forme tabulaire, totalisés et agrégés

QUELQUES EXPLICATIONS SUR LES MÉTRIQUES

analyses (scan count) : nombre de fois ou l’exécuteur de requête a du pénétrer dans un index de la table ou dans la table (en cas de parallélisme, autant de fois que de threads…)

lectures logiques (logical reads) : nombre de pages lues en RAM

lectures physiques (physical reads) : nombre de pages lues depuis le disque (avec transfert en RAM) en mode aléatoire.

lectures anticipées (read-ahead physical read) : nombre de pages lues depuis le disque (avec transfert en RAM) en mode continu.

…d’objets volumineux (lob …) : nombre de pages … pour les « Large OBjects ».

NOTA : cet outil fonctionne que votre serveur soit en anglais ou français.

LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE
Le code !

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Développez et administrez pour la performance avec SQL Server 2014

Une fonction de comptage d’occurrence

SQLpro — Thu, 16 Nov 2017 17:51:42 +0000

La petite fonction qui suit permet de compter le nombre de fois ou un caractère est présent dans une chaine de caractères.

CREATE FUNCTION F_COUNT_CHAR(@STR NVARCHAR(MAX), @CHR NCHAR(1))
RETURNS INT
WITH RETURNS NULL ON NULL INPUT
AS
BEGIN
DECLARE @NBR INT, @POS INT;
SELECT @NBR = 0, @POS = CHARINDEX(@CHR, @STR);
WHILE @POS > 0
BEGIN
SET @NBR = @NBR + 1;
SET @POS = CHARINDEX(@CHR, @STR, @POS + 1);
END;
RETURN @NBR;
END;
GO

Exemples d’utilisation :

-- exemple -- résultat
------------------------------------------- ------------

SELECT dbo.F_COUNT_CHAR('abracadabra', 'a') --> 5

SELECT dbo.F_COUNT_CHAR('', 'a') --> 0
SELECT dbo.F_COUNT_CHAR('a', '') --> 0
SELECT dbo.F_COUNT_CHAR('', '') --> 0

SELECT dbo.F_COUNT_CHAR(NULL, 'a') --> NULL
SELECT dbo.F_COUNT_CHAR('a', NULL) --> NULL
SELECT dbo.F_COUNT_CHAR(NULL, NULL) --> NULL

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Développez et administrez pour la performance avec SQL Server 2014

Métadonnées de l’utilisation d’une colonne

SQLpro — Mon, 23 Oct 2017 07:07:13 +0000

Certaines modifications de type de données d’une colonne nécessitent une suppression préalable des contraintes et index. Pour vous y aider, la procédure suivante indique dans quels objets (index ou contraintes) une colonne d’une table passée en argument est enrôlée.

Dans le cas ou vous voudriez changer le type d’une telle colonne, il faudrait agir manuellement avec le scénario suivant :

1) Scripter la création des contraintes par clic droit sur le nom de chacune des contraintes et les supprimer
2) Scripter la création des index par clic droit sur le nom de chacun des index et les supprimer
3) Modifier le type de données de la colonne avec la commande ALTER TABLE … ALTER COLUMN …
4) Recréer les index
5) Recréer les contraintes

Cette procédure à été créée pour vous y aider. Elle indique pour un couple d’information table/colonne dans quels index ou contrainte cette dernière est enrôlée…
Cette procédure est créée en tant que procédure système afin d’être exploitable dans n’importe quelle base de l’instance SQL Server.

USE master;
GO

IF EXISTS(SELECT *
FROM sys.all_objects
WHERE name = 'sp__COLUMN_IS_USED'
AND schema_id = SCHEMA_ID('dbo'))
EXEC ('ROP PROCEDURE dbo.sp__COLUMN_IS_USED;');
GO

--===========================================================================--
-- METADONNÉES D'UTILISATION D'UNE COLONNE --
--===========================================================================--
-- Fredéric Brouard alias SQLpro http://sqlpro.developpez.com --
-- Société SQL SPOT - http://www.sqlspot.com 2017-10-13 - version 1.0 --
--===========================================================================--

--▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄--
-- PHASE 1 : création de la procédure --
--▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀--

USE master;
GO

CREATE PROCEDURE dbo.sp__COLUMN_IS_USED @OBJ NVARCHAR(261),
@COL NVARCHAR(128) = NULL
AS
/******************************************************************************
* METADONNÉES D'UTILISATION D'UNE COLONNE *
* Procédure listant sous forme de tables dans quels objets est utilisé une *
* colonne d'une table *
*******************************************************************************
* Frédéric Brouard - SQLpro@SQLspot.com - Sté SQL SPOT http://www.sqlspot.com *
* Plus d'info. sur http://sqlpro.developpez.com - 2017-10-13 - version 1.0 *
*******************************************************************************
* Cette procédure prend en argument le nom d'une table avec son schéma SQL *
* (sinon le schéma par défaut de l'utilisateur qui la lance) ainsi qu'un nom *
* de colonne et renvoie un jeu de données contenant le descriptif des cas *
* d'utilisation de cette colonne dans les index et les contraintes *
*******************************************************************************
* ATTENTION : procédure système ! Exécutable depuis n'importe quelle base *
* *
* Paramètre en entrée : *
* @OBJ type NVARCHAR(261) : nom de table dont on veut connaître les index *
* @COL nom de la colonne dont on veut connaître l'usage *
* *
* COLONNE de la table en sortie : *
* COLUMN_NAME nom de la colonne passée en paramètre *
* OBJECT_TYPE type d'objet (nature de la contrainte ou INDEX) *
* OBJECT_NAME nom de la contrainte ou de l'index *

* *
* EXEMPLE : *
* EXEC dbo.sp__COLUMN_IS_USED 'CC', 'Idx' *
* ... donne la liste de tous les index et contrainte de la table CC *
* incluant la colonne Idx *
* *
******************************************************************************/

SET NOCOUNT ON;
WITH T AS (
SELECT COLUMN_NAME, CONSTRAINT_TYPE AS OBJECT_TYPE, KCU.CONSTRAINT_NAME AS OBJECT_NAME
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE AS KCU
JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS AS TC
ON KCU.TABLE_SCHEMA = TC.TABLE_SCHEMA
AND KCU.TABLE_NAME = TC.TABLE_NAME
AND KCU.CONSTRAINT_NAME = TC.CONSTRAINT_NAME
WHERE OBJECT_ID(KCU.TABLE_SCHEMA + '.' + KCU.TABLE_NAME) = OBJECT_ID(@OBJ)
AND REPLACE(REPLACE(RTRIM(LTRIM(@COL)), ']', ''), '[', '') = COLUMN_NAME
UNION ALL
SELECT REPLACE(REPLACE(RTRIM(LTRIM(@COL)), ']', ''), '[', ''), CONSTRAINT_TYPE AS OBJECT_TYPE, CK.CONSTRAINT_NAME AS OBJECT_NAME
FROM INFORMATION_SCHEMA.CHECK_CONSTRAINTS AS CK
JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS AS TC
ON CK.CONSTRAINT_SCHEMA = TC.CONSTRAINT_SCHEMA
AND CK.CONSTRAINT_NAME = TC.CONSTRAINT_NAME
WHERE OBJECT_ID(TC.TABLE_SCHEMA + '.' + TC.TABLE_NAME) = OBJECT_ID(@OBJ)
AND CHECK_CLAUSE LIKE '%' + REPLACE(REPLACE(RTRIM(LTRIM(@COL)), ']', ''), '[', '') + '%'
UNION ALL
SELECT c.name, 'INDEX', i.name
FROM sys.indexes AS i
JOIN sys.index_columns AS ic
ON i.object_id = ic.object_id AND i.index_id = ic.index_id
JOIN sys.COLUMNS AS c
ON ic.object_id = c.object_id AND ic.column_id = c.column_id
WHERE i.object_id = OBJECT_ID(@OBJ)
AND REPLACE(REPLACE(RTRIM(LTRIM(@COL)), ']', ''), '[', '') = c.name)
SELECT *
FROM T
ORDER BY CASE OBJECT_TYPE WHEN 'PRIMARY KEY' THEN 1
WHEN 'UNIQUE' THEN 2
WHEN 'FOREIGN KEY' THEN 3
WHEN 'CHECK' THEN 4
WHEN 'INDEX' THEN 5
ELSE 99 END, OBJECT_NAME;
GO

--▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄--
-- PHASE 2 : traduction en procédure système --
--▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀--

EXEC sp_MS_marksystemobject 'sp__COLUMN_IS_USED';

Pour utiliser cette procédure, lancez la avec EXEC et passez le nom de table éventuellement préfixé par son schéma SQL ainsi que le nom de la colonne. Exemple :

EXEC sp__COLUMN_IS_USED 'matable', 'macolonne';

LE CODE ! LE CODE ! LE CODE ! LE CODE ! LE CODE ! LE CODE ! LE CODE ! LE CODE ! LE CODE ! LE CODE !

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Développez et administrez pour la performance avec SQL Server 2014

Audit trail générique

SQLpro — Fri, 13 Jan 2017 14:53:54 +0000

L’ « audit trail », littéralement « piste d’audit » est un audit destiné à pister les événements qui se passe dans un système. Dans une base de données, il est, la plupart du temps, destiné à vérifier ce qui s’est passé, notamment sur le plan des valeurs avant ou après la modification. Il peut à la fois servir pour la sécurité (qui à fait quoi ?), comme sur le plan fonctionnel (pourquoi cette valeur ?, À quelle date un tel changement ?…).
En dehors des outils lourds comme CDC (Change Data Capture) et Change Tracking (tous deux destiné à savoir quoi, donc fonctionnel) ou Database Audit (destiné à savoir qui, donc sécurité), voici une méthode basée sur un déclencheur et une seule et unique table, facile et rapide à mettre en œuvre et qui permet de tracer qui et quoi…

la principe est simple : chaque table reçoit un unique déclencheur lancé sur tous les événements de mise à jour (INSERT, UPDATE, DELETE) et concatène les images avant et après des données (tables inserted et deleted) puis les transforme en un unique document XML, quelque soit le nombre de lignes. Il est alors facile de stocker cette information das une ligne d’une table, accompagnée de métadonnées, notamment, date et heure de survenance, application cliente, compte de connexion, utilisateur SQL, machine hôte, login windows, etc…

Il ne reste plus qu’à lire la table de trace pour savoir qui à fait quoi et quand ! Comme les données sont sous forme XML, il est possible des les interroger par des requêtes SQL mêlant XQuery et XPath. Une astuce consistant à publier certaines vues pour les demandes de contrôle les plus fréquentes (en général quelques tables).

Les objets sont créé dans un schéma SQL de nom S_ADT et la table à scruter est la table S_ADT.T_MAJ.

Voici l’ensemble du code pour se faire…

1 – LA TABLE

Pour recueillir les données tracées

CREATE SCHEMA S_ADT
CREATE TABLE T_MAJ
(MAJ_ID BIGINT IDENTITY PRIMARY KEY,
MAJ_DHU DATETIME2 DEFAULT SYSUTCDATETIME() NOT NULL,
MAJ_DHL DATETIME2 DEFAULT SYSDATETIME() NOT NULL,
MAJ_CNX sysname DEFAULT SYSTEM_USER,
MAJ_USR sysname DEFAULT USER,
MAJ_APPLICATION NVARCHAR(128),
MAJ_HOST NVARCHAR(128),
MAJ_WINLOGIN NVARCHAR(128),
MAJ_WINDOMAIN NVARCHAR(128),
MAJ_SCHEMA NVARCHAR(128),
MAJ_OBJECT NVARCHAR(128),
MAJ_TYPE CHAR(1),
MAJ_DATA XML);
GO

2 – LE TRIGGER

Exemple de création de trigger sur une table pour tracer tous les événements

CREATE TRIGGER E_auditTrail_???
ON ???
FOR INSERT, UPDATE, DELETE
AS
SET NOCOUNT ON;

DECLARE @S sysname, @O sysname,
@A NVARCHAR(128), @H NVARCHAR(128), @L NVARCHAR(128), @D NVARCHAR(128);

SELECT @S = s.name, @O = o.name
FROM sys.objects AS o
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.objects AS t
ON t.parent_object_id = o.object_id
WHERE t.object_id = @@PROCID;

SELECT @A program_name, @H host_name, @L login_name, @D domain_name
FROM sys.dm_exec_sessions
WHERE session_id = @@SPID;

-- cas d'insertion
IF NOT EXISTS(SELECT * FROM deleted)
BEGIN
INSERT INTO S_ADT.T_MAJ (MAJ_SCHEMA, MAJ_OBJECT, MAJ_TYPE, MAJ_DATA,
MAJ_APPLICATION, MAJ_HOST, MAJ_WINLOGIN, MAJ_WINDOMAIN)
SELECT @S, @O, 'I',
CAST((SELECT * FROM inserted FOR XML AUTO, ELEMENTS, ROOT('insert'), BINARY BASE64) AS XML),
@A, @H, @L, @D;
RETURN;
END;

-- cas de la suppression
BEGIN
IF NOT EXISTS(SELECT * FROM inserted)
INSERT INTO S_ADT.T_MAJ (MAJ_SCHEMA, MAJ_OBJECT, MAJ_TYPE, MAJ_DATA,
MAJ_APPLICATION, MAJ_HOST, MAJ_WINLOGIN, MAJ_WINDOMAIN)
SELECT @S, @O, 'D',
CAST((SELECT * FROM deleted FOR XML AUTO, ELEMENTS, ROOT('delete'), BINARY BASE64) AS XML),
@A, @H, @L, @D;
RETURN;
END;

-- cas de la modification
INSERT INTO S_ADT.T_MAJ (MAJ_SCHEMA, MAJ_OBJECT, MAJ_TYPE, MAJ_DATA,
MAJ_APPLICATION, MAJ_HOST, MAJ_WINLOGIN, MAJ_WINDOMAIN)
SELECT @S, @O, 'I',
CAST((SELECT *
FROM (SELECT 'OLD' AS _old_, * FROM deleted
UNION ALL
SELECT 'NEW' AS _new_, * FROM inserted) AS _auditTrail_
FOR XML AUTO, ELEMENTS, ROOT('update'), BINARY BASE64) AS XML),
@A, @H, @L, @D;
GO

Pour vous faciliter la tâche, quelques scripts complémentaires…

3 – Un batch de création des triggers sur toutes les tables…

DECLARE @SQL NVARCHAR(MAX) =
'CREATE TRIGGER E_auditTrail_~1
ON ~2
FOR INSERT, UPDATE, DELETE
AS
SET NOCOUNT ON;

DECLARE @S sysname, @O sysname,
@A NVARCHAR(128), @H NVARCHAR(128), @L NVARCHAR(128), @D NVARCHAR(128);

SELECT @S = s.name, @O = o.name
FROM sys.objects AS o
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.objects AS t
ON t.parent_object_id = o.object_id
WHERE t.object_id = @@PROCID;

SELECT @A program_name, @H host_name, @L login_name, @D domain_name
FROM sys.dm_exec_sessions
WHERE session_id = @@SPID;

IF NOT EXISTS(SELECT * FROM deleted) --> cas d''insertion
BEGIN
INSERT INTO S_ADT.T_MAJ (MAJ_SCHEMA, MAJ_OBJECT, MAJ_TYPE, MAJ_DATA,
MAJ_APPLICATION, MAJ_HOST, MAJ_WINLOGIN, MAJ_WINDOMAIN)
SELECT @S, @O, ''I'',
CAST((SELECT * FROM inserted FOR XML AUTO, ELEMENTS, ROOT(''insert''), BINARY BASE64) AS XML),
@A, @H, @L, @D;
RETURN;
END;

BEGIN
IF NOT EXISTS(SELECT * FROM inserted) --> cas de la suppression
INSERT INTO S_ADT.T_MAJ (MAJ_SCHEMA, MAJ_OBJECT, MAJ_TYPE, MAJ_DATA,
MAJ_APPLICATION, MAJ_HOST, MAJ_WINLOGIN, MAJ_WINDOMAIN)
SELECT @S, @O, ''D'',
CAST((SELECT * FROM deleted FOR XML AUTO, ELEMENTS, ROOT(''delete''), BINARY BASE64) AS XML),
@A, @H, @L, @D;
RETURN;
END;

-- cas de la modif
INSERT INTO S_ADT.T_MAJ (MAJ_SCHEMA, MAJ_OBJECT, MAJ_TYPE, MAJ_DATA,
MAJ_APPLICATION, MAJ_HOST, MAJ_WINLOGIN, MAJ_WINDOMAIN)
SELECT @S, @O, ''I'',
CAST((SELECT *
FROM (SELECT ''OLD'' AS _old_, * FROM deleted
UNION ALL
SELECT ''NEW'' AS _new_, * FROM inserted) AS _auditTrail_
FOR XML AUTO, ELEMENTS, ROOT(''update''), BINARY BASE64) AS XML),
@A, @H, @L, @D;'
DECLARE @T NVARCHAR(261), @N VARCHAR(38), @CMD NVARCHAR(MAX);
DECLARE C CURSOR
LOCAL FORWARD_ONLY STATIC READ_ONLY
FOR
SELECT '[' + TABLE_SCHEMA + '].[' + TABLE_NAME + ']' AS T,
REPLACE(REPLACE(CAST(NEWID() AS VARCHAR(38)), '-', '_'), '-', '_') AS N
FROM INFORMATION_SCHEMA.TABLES AS T
WHERE TABLE_TYPE = 'BASE TABLE'
AND TABLE_SCHEMA 'S_ADT'
AND NOT EXISTS(SELECT *
FROM INFORMATION_SCHEMA.COLUMNS AS C
WHERE T.TABLE_SCHEMA = C.TABLE_SCHEMA
AND T.TABLE_NAME = C.TABLE_NAME
AND C.DATA_TYPE IN ('text', 'ntext', 'image', 'xml', 'geometry', 'geography'));
OPEN C;
FETCH C INTO @T, @N;
WHILE @@FETCH_STATUS = 0
BEGIN
SET @CMD = REPLACE(REPLACE(@SQL, '~1', @N), '~2', @T);
EXEC (@CMD);
FETCH C INTO @T, @N;
END;
CLOSE C;
DEALLOCATE C;
GO

4 – Un batch de suppression de tous les triggers de tracabilité mis en place

DECLARE @SQL NVARCHAR(MAX) = N''
SELECT @SQL = @SQL + 'DROP TRIGGER [' + s.name + '].' + d.name + ';'
FROM sys.triggers AS d
JOIN sys.objects AS o
ON d.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
WHERE d.name LIKE 'E?_auditTrail?_%' ESCAPE '?'
AND LEN(d.name) = 49
AND REPLACE(RIGHT(d.name, 36), '_', '') LIKE REPLICATE('[0-9A-F]', 32);
EXEC (@SQL);
GO

5 – Un batch de désactivation des déclencheurs de traçabilité

DECLARE @SQL NVARCHAR(MAX) = N''
SELECT @SQL = @SQL + 'DISABLE TRIGGER [' + s.name + '].' + d.name
+ ' ON [' + s.name + '].[' + t.name + '];'
FROM sys.triggers AS d
JOIN sys.objects AS o
ON d.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.objects AS t
ON d.parent_id = t.object_id
WHERE d.name LIKE 'E?_auditTrail?_%' ESCAPE '?'
AND LEN(d.name) = 49
AND REPLACE(RIGHT(d.name, 36), '_', '') LIKE REPLICATE('[0-9A-F]', 32);
EXEC (@SQL);
GO

6 – Un batch de réactivation des déclencheurs de tracabilité

DECLARE @SQL NVARCHAR(MAX) = N''
SELECT @SQL = @SQL + 'ENABLE TRIGGER [' + s.name + '].' + d.name
+ ' ON [' + s.name + '].[' + t.name + '];'
FROM sys.triggers AS d
JOIN sys.objects AS o
ON d.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.objects AS t
ON d.parent_id = t.object_id
WHERE d.name LIKE 'E?_auditTrail?_%' ESCAPE '?'
AND LEN(d.name) = 49
AND REPLACE(RIGHT(d.name, 36), '_', '') LIKE REPLICATE('[0-9A-F]', 32);
EXEC (@SQL);
GO

NOTA :

Conseil important : si vous avez attribué des privilèges très fermés, il faut autoriser les utilisateurs à voir les DMV d’état du serveur pour recueillir les données système, sinon les déclencheurs vont planter.pour cela vous devez attribuer le privilège « VIEW SERVER STATE » à tous les utilisateurs de la base à travers leur compte de connexion.
Vous pouvez faire ceci à l’aide du script SQL suivant :

DECLARE @SQL NVARCHAR(MAX) = N'USE master;'
SELECT @SQL = @SQL + 'GRANT VIEW SERVER STATE TO [' + L.name + '];'
FROM sys.database_principals AS U
INNER JOIN sys.server_principals AS L
ON L.sid = U.sid
WHERE L.name 'sa'
AND U.name NOT IN ('dbo', 'INFORMATION_SCHEMA', 'sys');
EXEC (@SQL);
GO

LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE
Le code !

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Développez et administrez pour la performance avec SQL Server 2014

Déblocage d’une instance SQL Server bloquée

SQLpro — Thu, 12 Jan 2017 14:12:46 +0000

Il arrive, souvent à cause d’un mauvais développement (voir en gras italique plus loin), qu’un serveur SQL se bloque du fait des verrous. Une session en bloque autre qui en bloque plusieurs autres… et c’est l’effet boule de neige. La plupart du temps, les développeurs ou pseudo DBA réagissent mal en relaçant le service SQL Server ce qui fait perdre une grande partie des mises à jour demandées, empêchent les utilisateurs de travailler et pour peu qu’une longue transaction n’ai pas encore enregistrées les données, rend indisponible la base après le redémarrage du serveur, souvent pendant de longues minutes… Tout cela pouvant être évité avec un peu d’analyse et surtout la bonne requête que je vous présente, destinées à débloquer sans frustrer !

Un blocage est une situation normale dans une base de données, comme dans la vie courante. Les feux rouges, l’accès à des toilettes, les portiques de sécurité des aéroports, sont autant de points ou vous pouvez vous retrouvé bloqué pendant un certain temps, et cela est normal et fait partie de la vie. Les bases de données devant assurer la cohérence entre ceux qui lisent les données et ceux qui les écrivent, doivent poser des verrous afin de bloquer les utilisateurs concurrents dans certaines situations. Le principe est le suivant :

un utilisateur qui lit des données, doit bloquer l’accès aux utilisateurs qui veulent modifier les mêmes données, mais n’empêchent pas d’autres utilisateurs de lire en même temps les mêmes données. Dans ce cas la base pose un verrou partagé (shared), qui peut être pessimiste (posé préventivement) ou optimiste (actionné après coup).
un utilisateur qui écrit des données doit empêcher toute lecture et toute écriture concurrente. On parle alors de verrou exclusif.

Si une session doit faire différentes modification au sein d’une même transaction, les verrous vont être maintenus jusqu’à ce qu’intervienne la finalisation de la transaction, par un COMMIT (validation) ou un ROLLBACK (annulation). Pendant ce temps, si d’autres utilisateurs doivent accéder à ces données, il faut qu’ils patientent. C’est la notion de blocage. Un blocage est donc une situation normale dans une base de données, comme c’est le cas de madame Michu qui patiente dans sa 4L au feu rouge pour laisser passer les automobiliste de la voie latérale.
Ce qui n’est pas toujours normal, c’est un blocage qui dure, longtemps, voire, très, très longtemps… mais jamais de manière éternelle, car la situation doit se débouquer à la fin du traitement bloquant, c’est une certitude !
Dans ce cas, il est possible que d’autres utilisateurs se retrouvent bloqués, alors que même, ils ont déjà entamé des modification de données, susceptible d’entrainer d’autres blocages ! D’où l’effet boule de neige… Là encore cette situation peut être normale, si le bloqueur de tête met à jour une très importante quantité de données alors que beaucoup d’utilisateurs sont en train de parcourir ces mêmes données ! Mais dans bien des cas, c’est une situation anormale, généralement due à des mauvaises pratiques de développement, tel que des transaction démarré côté client, des transactions avec interactions de l’utilisateur, le forçage de verrous (les SGBDR se débrouillent généralement mieux tous seuls), des transactions non finalisées, l’usage d’un niveau d’isolation inappropriée, l’utilisation de code itératif eu lieu de code ensembliste, l’oubli de poser les index adéquats, l’utilisation de tables obèses, le recours systématique aux curseur, l’usage immodéré des déclencheurs, etc !
Bref, la question est, en présence d’un tel blocage, comment faire ?

LA SOLUTION

Elle consiste tout simplement à recherche qui bloque qui, et remonter jusqu’à bloqueur de tête pour le forcer à abandonner son traitement. Problème, cela nécessite de parcourir récursivement l’arbre de blocage de blocage… Second problème, il peut y avoir plusieurs chaines de blocage !
La DMV sys.dm_exec_requests permet de savoir qui bloque qui dans l’état actuel de l’instance. Les deux colonnes qui nous intéressent pour ce faire sont :

session_id : l’identifiant de la session en cours
blocking_session_id : l’identifiant de la session qui bloque

Différentes chaines de blocage de sessions dans SQL Server (en fait des arbres)

Dans la figure ci avant, les sessions 53 et 57 sont les leaders et bloquent respectivement :

pour le 53, 11 session avec une profondeur maximale de 5
pour le 57, 3 sessions avec une profondeur maximale de 3

Il faudrait débloquer en priorité le 53, attendre quelques instants pour voir si cela ne débloque pas le 57.

À partir de ces seules deux informations (session_id et blocking_session_id), nous pouvons remonter jusqu’aux bloqueurs de tête. L’écriture de cette requête doit procéder en deux temps :
rechercher les bloquers de tête, c’est à dire ceux qui ne sont pas bloqués par d’autres, mais qui en bloque d’autres. Une fois ces « leaders » trouvés, il suffit de descendre dans l’arbre de blocage pour comptabiliser le nombre de sessions bloquées et la profondeur du blocage.
Il suffit alors de tuer les « lead blockers » les plus prégnants, c’est à dire en général ceux qui bloquent le plus de session, ceux qui ont la plus grande profondeur de blocage, ceux dont le temps de traitement a été le plus long, ceux ayant consommé le plus d’IO, ceux ayant la requête la moins critique…. À vous de choisir !

La requête !

WITH
T_SESSION AS
(
-- on récupère les sessions en cours des utilisateurs
SELECT session_id, blocking_session_id
FROM sys.dm_exec_requests AS tout
WHERE session_id > 50
),
T_LEAD AS
(
-- on recherche les bloqueurs de tête
SELECT session_id, blocking_session_id
FROM T_SESSION AS tout
WHERE session_id > 50
AND blocking_session_id = 0
AND EXISTS(SELECT *
FROM T_SESSION AS tin
WHERE tin.blocking_session_id = tout.session_id)
),
T_CHAIN AS
(
-- requête récursive pour trouver les chaines de blocage
SELECT session_id AS lead_session_id, session_id, blocking_session_id, 1 AS p
FROM T_LEAD
UNION ALL
SELECT C.lead_session_id, S.session_id, S.blocking_session_id, p+1
FROM T_CHAIN AS C
JOIN T_SESSION AS S
ON C.session_id = S.blocking_session_id
),
T_WEIGHT AS
(
-- calculs finaux
SELECT lead_session_id AS LEAD_BLOCKER,
COUNT(*) -1 AS BLOCKED_SESSION_COUNT,
MAX(p) - 1 AS BLOCKED_DEEP,
'KILL ' + CAST(lead_session_id AS VARCHAR(16)) + ';' AS SQL_CMD
FROM T_CHAIN
GROUP BY lead_session_id
)
SELECT T.*,
DB_NAME(r.database_id) AS database_name, host_name, program_name,
nt_user_name,
q.text AS sql_command,
DATEDIFF(ms, last_request_start_time,
COALESCE(last_request_end_time, GETDATE())) AS duration_ms,
s.open_transaction_count,
r.cpu_time, r.reads, r.writes, r.logical_reads, r.total_elapsed_time
FROM T_WEIGHT AS T
JOIN sys.dm_exec_sessions AS s
ON T.LEAD_BLOCKER = s.session_id
JOIN sys.dm_exec_requests AS r
ON s.session_id = r.session_id
OUTER APPLY sys.dm_exec_sql_text(sql_handle) AS q
ORDER BY BLOCKED_SESSION_COUNT DESC, BLOCKED_DEEP DESC;

Cette requête présente les sessions bloquant les autres sessions, en déterminant la session à la tête d’une chaine de blocage (LEAD_BLOCKER), avec le nombre de sessions bloquées (BLOCKED_SESSION_COUNT) et la longueur maximale de la chaîne de blocage (BLOCKED_DEEP). Ceci permet de déterminer quelle session est à annuler en priorité en cas de blocage intempestif et d’utiliser la commande KILL (SQL_CMD) qui termine la session fautive en forçant un ROLLBACK. Les autres colonnes donnent des informations sur la requête qui a bloqué (texte SQL, base, origine du code, métriques diverses…)

ATTENTION
Ne pas confondre blocage et interblocage (ou étreinte fatale, ou encore verrou mortel…). Dans un interblocage, une session bloque des ressources qu’une autre session veut obtenir, tandis que cette même session demandeuse a bloqué des objets que la première a besoin. Dans ce cas, nous pouvons atteindre éternellement, car le blocage ne peut être résolu par l’attente. Le seul moyen consiste donc à sacrifier une des victimes de ce blocage et lui forçant une annulation de la transaction. Ceci est détecté automatiquement dans les bons SGBDR, qui procèdent automatiquement à l’achèvement d’une des victimes. Dans SQL Server, le message est intentionnellement significatif : « La transaction (ID de processus %1!) a été bloquée sur les ressources … par un autre processus et a été choisie comme victime. Réexécutez la transaction. »

LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE
Le code !

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Développez et administrez pour la performance avec SQL Server 2014

Calcul de la « bouding box » appropriée pour l’indexation spatiale

SQLpro — Mon, 09 Jan 2017 13:51:50 +0000

SQL Server dispose d’index spatiaux qui nécessitent l’utilisation d’une « bounding box » pour le type geometry. Une « bounding box » est en fait un rectangle qui délimite la surface à indexer. Mais comment déterminer les limites de cette « boite » ? Cet article vous propose une procédure stockée capable de calculer les meilleurs paramètres de ces « bounding box » et vous donne le code de création des index spatiaux à ajouter à votre base.

Bounding box pour l’indexation géométrique de la france

Dans le principe, tous les points de toutes vos géométries dans une même colonne de table devraient être situés dans la bounding box de l’index pour que certaines recherches bénéficient de l’indexation. Pour ce faire il faut déterminer le point le plus bas, le plus haut (en y) le plus à gauche et le plus à droite (en x) de l’ensemble des points formant toutes vos géométries.
Pour effectuer ce calcul il existe une astuce qui consiste à calculer l’enveloppe d’une géométrie, comme le montre l’image suivante :

Calcul de l’enveloppe de Paris à l’aide de la fonction STEnvelope

Notez que le calcul des limites de Paris a été effectué par concaténation des polygones des différentes arrondissements dans une premier temps (geometry::UnionAggregate(GEOM)).

À partir de là on peut obtenir les valeurs min et max de X et Y, car, comme le rectangle est formé de 4 points, il suffit de prendre les coordonnées de X et Y du point 1 et du point 3, les points étant spécifiées par chainage !

Enveloppe de Paris et ses points

Dès lors la méthode pour obtenir les coordonnées de la bounding box est d’obtenir les valeurs de X et Y comme ceci :

MaGeometrie.STPointN(1).STX => Xmin

MaGeometrie.STPointN(1).STY => Ymin

MaGeometrie.STPointN(3).STX => Xmax

MaGeometrie.STPointN(3).STY => Ymax

Mais il faut concaténer toutes les entrées de toutes les géométries de la colonnes à l’aide de la fonction EnvelopeAggregate.

la requête finale ressembles à celle-ci (calcul de la bounding box pour toutes les communes de la France métropolitaine) :

WITH T AS
(
SELECT geometry::EnvelopeAggregate(GEOM) AS GEO
FROM [S_GEO].[COMMUNE]
)
SELECT geometry::EnvelopeAggregate(GEO).STPointN(1).STX AS MIN_X,
geometry::EnvelopeAggregate(GEO).STPointN(3).STX AS MAX_X,
geometry::EnvelopeAggregate(GEO).STPointN(1).STY AS MIN_Y,
geometry::EnvelopeAggregate(GEO).STPointN(3).STY AS MAX_Y
FROM T

Au final nous pouvons automatiser ce calcul pour toutes les colonnes geometry de toute la base. Ceci conduit à la procédures suivantes :

CREATE PROCEDURE P_AUTOBOUND_SPATIAL_INDEX @DELTA FLOAT
AS

DECLARE @T TABLE (SCH sysname, TBL sysname, COL sysname, XMIN FLOAT, XMAX FLOAT, YMIN FLOAT, YMAX FLOAT);
-- le delate doit être 1 (bornes strictes) ou supérieur à 1
IF @DELTA < 1 OR @DELTA IS NULL
SET @DELTA = 1;

-- recherches des colonnes spatiales non indexées de type GEOMETRY
INSERT INTO @T (SCH, TBL, COL)
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE DATA_TYPE = 'geometry'
EXCEPT
SELECT s.name, o.name, c.name
FROM sys.objects AS o
JOIN sys.indexes AS i
ON o.object_id = i.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.spatial_indexes AS si
ON i.object_id = si.object_id
AND i.index_id = si.index_id
JOIN sys.index_columns AS ic
ON i.object_id = ic.object_id
AND i.index_id = ic.index_id
JOIN sys.COLUMNS AS c
ON ic.object_id = c.object_id
AND ic.column_id = c.column_id
JOIN sys.systypes AS t
ON c.system_type_id = t.TYPE
WHERE t.name = 'geometry';

DECLARE @TXY TABLE (XMIN FLOAT, XMAX FLOAT, YMIN FLOAT, YMAX FLOAT);
DECLARE @TBL sysname, @SCH sysname, @COL sysname,
@XMIN FLOAT, @XMAX FLOAT, @YMIN FLOAT, @YMAX FLOAT,
@SQL NVARCHAR(MAX);

DECLARE C CURSOR
LOCAL
FORWARD_ONLY
STATIC
READ_ONLY
FOR
SELECT SCH, TBL, COL
FROM @T;

OPEN C;

FETCH C INTO @SCH, @TBL, @COL;

WHILE @@FETCH_STATUS = 0
BEGIN
DELETE FROM @TXY;
SET @SQL = N'WITH T AS (SELECT geometry::EnvelopeAggregate([' + @COL + N']) AS GEO FROM [' + @SCH + '].[' + @TBL + ']) '
+ N'SELECT geometry::EnvelopeAggregate(GEO).STPointN(1).STX / ' + CAST(@DELTA AS VARCHAR(16)) + N' AS MIN_X, '
+ N'geometry::EnvelopeAggregate(GEO).STPointN(3).STX * ' + CAST(@DELTA AS VARCHAR(16)) + N' AS MAX_X, '
+ N'geometry::EnvelopeAggregate(GEO).STPointN(1).STY / ' + CAST(@DELTA AS VARCHAR(16)) + N' AS MIN_Y, '
+ N'geometry::EnvelopeAggregate(GEO).STPointN(3).STY * ' + CAST(@DELTA AS VARCHAR(16)) + N' AS MAX_Y '
+ N'FROM T;'
INSERT INTO @TXY
EXEC (@SQL);
UPDATE T
SET XMIN = TT.XMIN, XMAX = TT.XMAX, YMIN = TT.YMIN, YMAX = TT.YMAX
FROM @T AS T
CROSS JOIN @TXY AS TT
WHERE SCH = @SCH
AND TBL = @TBL
AND COL = @COL;
FETCH C INTO @SCH, @TBL, @COL;
END

CLOSE C;

DEALLOCATE C;

SELECT N'CREATE SPATIAL INDEX XS_' + LEFT(SCH, 16) + N'_' + LEFT(TBL, 30) + N'_' + LEFT(COL, 30) + N'_'
+ REPLACE(CAST(NEWID() AS NVARCHAR(38)), N'-', N'_') + '_' + CONVERT(CHAR(8), GETDATE(), 112)
+ NCHAR(13) + NCHAR(10)
+ N' ON [' + SCH + N'].[' + TBL + '] ([' + COL + N']) '
+ NCHAR(13) + NCHAR(10)
+ N' WITH ( BOUNDING_BOX = ('
+ CAST( XMIN AS NVARCHAR(32)) + N', '
+ CAST( YMIN AS NVARCHAR(32)) + N', '
+ CAST( XMAX AS NVARCHAR(32)) + N', '
+ CAST( YMAX AS NVARCHAR(32)) + N') );'
FROM @T;

GO

Le paramètre @DELTA sert à rajouter un peu de "mou" sur la périphérie de la bounding box et doit être égale à 1 (pas de "mou") ou supérieur.
par exemple avec 1.1, on ajoute 10% de distance en périphérie de la bounding box.

LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE
Le code !

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Développez et administrez pour la performance avec SQL Server 2014