Le blog de SQLpro » SQL server

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 !

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

Estimation des IO (ES) en lecture et écriture table par table d’une base SQL

SQLpro — Wed, 21 Feb 2018 18:07:18 +0000

Les deux requêtes que je vous présente permettent d’estimer le nombres de pages lues et écrites table par table tenant compte de tous les index des tables. Attention : il ne s’agit pas d’une mesure exacte. Une telle mesure est impossible mais bien d’une estimation pour connaître les tables les plus écrites et celles les plus lues de manières relatives les unes aux autres.

Elle se base sur le nombre d’opération unitaire d’accès effectué sur chaque table et index. En gros, il y a trois types d’accès :
1) un accès par balayage de la table ou de l’index (scan) appelé « analyse » dans les plans de requête en français;
2) un accès pour recherche dichotomique dans l’index (seek) appelé « recherche » dans les plans de requête en français;
3) un accès multi recherche dans l’index (lookup) appelé « recherche de clés » dans les plans de requête en français;

Nous avons compter qu’un SCAN balayait toutes les pages de l’index ou de la table, ce qui est faux dans certains cas particulier (par exemple recherche TOP n)
Nous avons compter qu’un SEEK parcourait un nombre de page équivalent à la profondeur de l’arbre ce qui n’est pas vrai pour les recherches de type « range » (par exemple lors d’un BETWEEN)
Nous avons compter qu’un LOOKUP était l’équivalent de 10 seeks. Mais cela peut être plus ou moins et dans certains cas, ce n’est même pas réellement l’équivalent d’un seek.

Ces approximations nous permettent quand même une bonne évaluation de la surface d’attaque des données des tables en production, dans un but comparatif, voir les tables les plus accédées en lecture ou en écriture.

La requête pour les lectures :

WITH
idx_details AS
(
SELECT ius.object_id, ius.index_id, user_seeks, user_lookups, user_scans,
COALESCE(INDEXPROPERTY(i.object_id, i.name, 'IndexDepth '), 0)
AS index_depth,
(SELECT SUM(used_page_count) AS pages
FROM sys.dm_db_partition_stats AS s
WHERE s.object_id = ius.object_id
AND s.index_id = ius.index_id) AS page_count
FROM sys.dm_db_index_usage_stats AS ius
JOIN sys.indexes AS i
ON ius.object_id = i.object_id
AND ius.index_id = i.index_id
WHERE database_id = DB_ID()
AND ius.index_id 0 OR user_lookups > 0 OR user_scans > 0)
),
TOPT AS
(
SELECT s.name AS TABLE_SCHEMA, o.name AS TABLE_NAME,
SUM(user_seeks + 10 * user_lookups * index_depth) +
SUM(user_scans * page_count) AS IO_READS_ESTIMATE,
100.0 * (SUM(user_seeks + 10 * user_lookups * index_depth) +
SUM(user_scans * page_count)) /
SUM(NULLIF(SUM(user_seeks + 10 * user_lookups * index_depth) +
SUM(user_scans * page_count), 0)) OVER() AS PERCENT_READS_ESTIMATE
FROM idx_details AS id
JOIN sys.objects AS o
ON id.object_id = o.object_id
JOIN sys.schemas AS s
ON s.schema_id = o.schema_id
GROUP BY s.name, o.name
HAVING SUM(user_seeks + 10 * user_lookups * index_depth) +
SUM(user_scans * page_count) > 0
)
SELECT TABLE_SCHEMA, TABLE_NAME, IO_READS_ESTIMATE,
CAST(PERCENT_READS_ESTIMATE AS DECIMAL(5, 2)) AS PERCENT_READS_ESTIMATE,
CAST(SUM(PERCENT_READS_ESTIMATE)
OVER(ORDER BY PERCENT_READS_ESTIMATE DESC) AS DECIMAL(5, 2))
AS CUMUL_PERCENT,
CAST((SELECT sqlserver_start_time
FROM sys.dm_os_sys_info) AS datetime2(0)) AS SINCE
FROM TOPT
ORDER BY IO_READS_ESTIMATE DESC;

La requête pour les écritures :

WITH
idx_details AS
(
SELECT ius.object_id, SUM(user_updates * 100) AS user_updates
FROM sys.dm_db_index_usage_stats AS ius
JOIN sys.indexes AS i
ON ius.object_id = i.object_id AND ius.index_id = i.index_id
WHERE database_id = DB_ID()
AND ius.index_id 0
GROUP BY ius.object_id
),
TOPT AS
(
SELECT s.name AS TABLE_SCHEMA, o.name AS TABLE_NAME,
user_updates AS IO_WRITES_ESTIMATE,
100.0 * user_updates / SUM(user_updates) OVER()
AS PERCENT_WRITES_ESTIMATE
FROM idx_details AS id
JOIN sys.objects AS o
ON id.object_id = o.object_id
JOIN sys.schemas AS s
ON s.schema_id = o.schema_id
GROUP BY s.name, o.name, user_updates
)
SELECT TABLE_SCHEMA, TABLE_NAME, IO_WRITES_ESTIMATE,
CAST(PERCENT_WRITES_ESTIMATE AS DECIMAL(5, 2))
AS PERCENT_WRITES_ESTIMATE,
CAST(SUM(PERCENT_WRITES_ESTIMATE)
OVER(ORDER BY PERCENT_WRITES_ESTIMATE DESC) AS DECIMAL(5, 2))
AS CUMUL_PERCENT,
CAST((SELECT sqlserver_start_time
FROM sys.dm_os_sys_info) AS datetime2(0)) AS SINCE
FROM TOPT
ORDER BY PERCENT_WRITES_ESTIMATE DESC;

Un exemple de résultat pour la lecture :

TABLE_SCHEMA TABLE_NAME IO_READS_ESTIMATE PERCENT_READS_ESTIMATE CUMUL_PERCENT SINCE
-------------- --------------------------- -------------------- ----------------------- --------------- ---------------------------
S_GEO COMMUNE 748792 55.59 55.59 2018-01-16 16:17:28
S_RTE TRONCON_ROUTE 520044 38.61 94.19 2018-01-16 16:17:28
S_ADR CODE_INSEE_CODE_POSTAL 42147 3.13 97.32 2018-01-16 16:17:28
S_GEO DEPARTEMENT 36057 2.68 100.00 2018-01-16 16:17:28

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

Les tables temporelles avec SQL Server (présentation)

SQLpro — Wed, 25 Jan 2017 14:00:36 +0000

Arrivée avec la norme SQL 2011, le concept de tables temporelles permet une historisation automatique des données et propose des opérateurs temporels pour « voir » vos données telles qu’elles étaient à un point ou une période du temps passé. Paradoxe : plus besoin de faire des sauvegardes ! Cette présentation montré au Microsoft Cloud Summit 2017 à paris le 24 janvier 2017, vous montre l’essentiel sur le sujet, avec SQL Server 2016 et est assortie de nombreux exemples.

La présentation PowerPoint sous forme PDF est téléchargeable ici : SQL Server et les tables temporelles

Les exemples l’accompagnant, sont téléchargeable ici :

DEMO 001 – table temporelles sans historique (fichier SQL)
DEMO 002 – table temporelles avec historique (fichier SQL)
DEMO 003 – stockage (fichier SQL)
DEMO 004 – Récupération (fichier SQL)
DEMO 005 – Purge (fichier SQL)
DEMO 005b – Purge métadonnées blocage (fichier SQL)
DEMO 006 – interrogation (fichier SQL)
DEMO 007 – In Memory (fichier SQL)
DEMO ANNEXE temporal tables (fichier SQL)

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES
Expert S.G.B.D relationnelles et langage S.Q.L
Most 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

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

Métadonnées des index (sp__helpindex)

SQLpro — Tue, 17 Jan 2017 15:51:08 +0000

La procédure stockée master.sys.sp_helpindex, décrivant les index d’une table, fournit par Microsoft, est aujourd’hui fortement obsolète et Microsoft n’a pas souhaité donné suite aux demandes de modification (1). Voici une procédure inspirée de cette dernière bien plus complète et prenant en compte tous les types d’index (spatiaux, XML, columstore, fulltext).

(1) Dans l’outil CONNECT consacré aux amélioration de SQL Server, il est dit par Microsoft, que, malgré les multiples demandes, la procédure stockée sp_helpindex, ne sera pas améliorée…
Cependant cette procédure est bien pratique pour comparer les index d’une même table afin de savoir s’il n’existe pas déjà tel ou tel index, au moment d’en créer de nouveaux, ou encore, s’il existe des index inclus ou redondants.
Voici donc une nouvelle procédure intitulée sp__helpindex (notez le double blanc souligné afin de ne pas écraser l’ancienne) qui permet de pallier à la déficience de l’ancienne et qui rajoute :

d’un point de vu « horizontal » : nom de table, colonnes incluses, filtre et l’essentiel de la clause WITH
d’un point de vue vertical : les index columnstore, xml, spatiaux et fulltext

Voici le code de cette procédure :

CREATE PROCEDURE dbo.sp__HELPINDEX @OBJ NVARCHAR(133)
AS
/******************************************************************************
* METADONNÉES DES INDEX *
* Procédure listant sous forme de tables les métadonnées logique des index *
*******************************************************************************
* Frédéric Brouard - SQLpro@SQLspot.com - Sté SQL SPOT http://www.sqlspot.com *
* Plus d'info. sur http://sqlpro.developpez.com - 2017-01-17 - 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) et renvoie un *
* jeu de données contenant le descriptif logique de constitution d'un index *
* ou de tous les index de la base *
* NOTA substitut à la procédure stockée système sp_helpindex *
*******************************************************************************
* ATTENTION : procédure système ! Exécutable depuis n'importe quelle base *
* *
* Paramètre en entrée : *
* @OBJ type NVARCHAR(133) : nom de table dont on veut connaître les index *
* si vide, la procédure renvoie la liste de tous les index *
* *
* COLONNE de la table en sortie : *
* TABLE_NAME : nom de la table en deux parties (schéma SQL + nom) *
* INDEX_NAME : nom de l'index (1) *
* INDEX TYPE : type d'index *
* INDEX_STORAGE : type et nom de l'espace de stockage *
* INDEX_KEY : liste des colonnes composant la clef d'index (2) *
* INDEX_INCLUDE : liste des colonnes incluses (3) *
* INDEX_FILTER : filtre d'index s'il y a lieu *
* INDEX_WITH : principaux paramètres de la clause WITH *
* *
* NOTA : *
* (1) certains index n'ont pas de nom. C'est le cas des index "fulltext" *
* (2) certains index n'ont pas de clef. C'est le cas des index *
* "columnstore" et "fulltext". Dans ce cas les colonnes indexées *
* figurent dans la clause INDEX_INCLUDE *
* (3) pour les index CLUSTERED de type BTree, toutes les colonnes autre *
* que celles de la clef étant présente, la valeur présentée est : *
* * - (INDEX_KEY) *
* pour les index CLUSTERED COLUMNSTORE toutes les colonnes de la table *
* étant présente, la valeur présentée est : * *
* *
* EXEMPLE : *
* EXEC dbo.sp__HELPINDEX NULL *
* ... donne la liste de tous les index de la base ... *
* EXEC dbo.sp__HELPINDEX '[client]' *
* ... donne la liste des index de la table client ... *
* EXEC dbo.sp__HELPINDEX 'ventes.client' *
* ... donne la liste des index de la table client du schéma SQL vente... *
* *
******************************************************************************/

SET NOCOUNT ON;
WITH
T0 AS
(
SELECT i."type", s.name + '.' + o.name AS TABLE_NAME,
i.name AS INDEX_NAME,
CASE WHEN i.is_unique = 1 THEN 'UNIQUE ' ELSE '' END +
CASE WHEN xi.xml_index_type = 0 THEN 'PRIMARY ' ELSE '' END +
i.type_desc + CASE WHEN xi.xml_index_type > 0
THEN ' FOR ' + xi.secondary_type_desc ELSE ''
END AS INDEX_TYPE,
COALESCE('FILEGROUP: ' + fg.name,
'PARTITION: ' + ps.name COLLATE database_default +'('
+ STUFF((SELECT N', ' + cp.name
FROM sys.index_columns AS icp
LEFT OUTER JOIN sys.COLUMNS AS cp
ON icp.object_id = cp.object_id
AND icp.column_id = cp.column_id
WHERE icp.object_id = i.object_id
AND icp.index_id = i.index_id
AND icp.partition_ordinal >= 1
ORDER BY icp.partition_ordinal
FOR XML PATH(N'')), 1, 1,'') +')' )
AS INDEX_STORAGE,
LTRIM(STUFF((SELECT N', ' + CONCAT(c.name, ' '
+ CASE
WHEN i.type_desc
IN ('XML',
'SPATIAL',
'COLUMNSTORE')
THEN ''
WHEN is_descending_key = 1
THEN 'DESC'
WHEN is_descending_key = 0
THEN 'ASC'
ELSE ''
END)
FROM sys.index_columns AS ic
JOIN sys.COLUMNS AS c
ON ic.object_id = c.object_id
AND ic.column_id = c.column_id
WHERE ic.object_id = i.object_id
AND ic.index_id = i.index_id
AND is_included_column = 0
ORDER BY key_ordinal
FOR XML PATH(N'')), 1, 1,'')) AS INDEX_KEY,
LTRIM(STUFF((SELECT N', ' + c.name
FROM sys.index_columns AS ic
JOIN sys.COLUMNS AS c
ON ic.object_id = c.object_id
AND ic.column_id = c.column_id
WHERE ic.object_id = i.object_id
AND ic.index_id = i.index_id
AND is_included_column = 1
ORDER BY c.name
FOR XML PATH(N'')), 1, 1,'')) AS INDEX_INCLUDE,
i.filter_definition AS INDEX_FILTER,
'FILL_FACTOR = ' + CAST(i.fill_factor AS VARCHAR(32)) +
', PAD_INDEX = ' + CAST(i.is_padded AS CHAR(1)) +
', ALLOW_ROWLOCK = ' + CAST(i.allow_row_locks AS CHAR(1)) +
', ALLOW_PAGELOCK = ' + CAST(i.allow_page_locks AS CHAR(1))
AS INDEX_WITH
FROM sys.indexes AS i
JOIN sys.objects AS o
ON i.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.data_spaces AS ds
ON i.data_space_id = ds.data_space_id
LEFT OUTER JOIN sys.filegroups AS fg
ON ds.data_space_id = fg.data_space_id AND ds."type" = 'FG'
LEFT OUTER JOIN sys.partition_schemes AS ps
ON ds.data_space_id = ps.data_space_id AND ds."type" = 'PS'
LEFT OUTER JOIN sys.partition_functions AS pf
ON ps.function_id = pf.function_id
LEFT OUTER JOIN sys.xml_indexes AS xi
ON i.object_id = xi.object_id
AND i.index_id = xi.index_id
WHERE o.object_id = COALESCE(NULLIF(OBJECT_ID(@OBJ), 0), o.object_id)
AND i.index_id > 0
AND o.is_ms_shipped = 0
)
SELECT TABLE_NAME, INDEX_NAME, INDEX_TYPE, INDEX_STORAGE, INDEX_KEY,
CASE "type" WHEN 1 THEN '* - (INDEX_KEY)'
WHEN 5 THEN '*' END AS INDEX_INCLUDE,
INDEX_FILTER, INDEX_WITH
FROM T0
UNION ALL
SELECT s.name + '.' + o.name AS TABLE_NAME,
NULL AS INDEX_NAME, 'FULL TEXT' AS INDEX_TYPE,
'FULLTEXT CATALOG: ' + ftc.name AS INDEX_STORAGE,
NULL AS INDEX_KEY,
LTRIM(STUFF((SELECT N', ' + c.name
FROM sys.fulltext_index_columns AS ftic
JOIN sys.COLUMNS AS c
ON c.object_id = ftic.object_id
AND c.column_id = ftic.column_id
WHERE ftic.object_id = fti.object_id
FOR XML PATH(N'')), 1, 1,'')) AS INDEX_INCLUDE,
NULL AS INDEX_FILTER,
'CHANGE_TRACKING = ' + change_tracking_state_desc +
', STOPLIST = ' + CASE
WHEN fti.stoplist_id = 0 THEN 'SYSTEM'
WHEN fti.stoplist_id IS NULL THEN 'OFF'
ELSE (SELECT name
FROM sys.fulltext_stoplists AS ftsl
WHERE fti.stoplist_id = ftsl.stoplist_id)
END +
COALESCE(', SEARCH PROPERTY LIST = ' +
(SELECT name
FROM sys.registered_search_property_lists AS ftpl
WHERE fti.property_list_id = ftpl.property_list_id)
COLLATE French_BIN, '') AS INDEX_WITH
FROM sys.fulltext_indexes AS fti
JOIN sys.objects AS o
ON fti.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.fulltext_catalogs AS ftc
ON fti.fulltext_catalog_id = ftc.fulltext_catalog_id
WHERE o.object_id = COALESCE(NULLIF(OBJECT_ID(@OBJ), 0), o.object_id)
ORDER BY TABLE_NAME, INDEX_KEY, INDEX_INCLUDE;
GO

Il convient de la créer dans la base master et de la rendre procédure système, à l’aide de la commande :

EXEC sp_MS_marksystemobject 'sp__HELPINDEX';

Les colonnes du jeu de données en sortie de procédure sont :

TABLE_NAME : nom de la table en deux parties (schéma SQL + nom)
INDEX_NAME : nom de l’index. Certains index n’ont pas de nom. C’est en particulier le cas des index « fulltext »
INDEX TYPE : type d’index
INDEX_STORAGE : type et nom de l’espace de stockage
INDEX_KEY : liste des colonnes composant la clef d’index. Certains index n’ont pas de clef. C’est le cas des index « columnstore » et « fulltext ». Dans ce cas les colonnes indexées figurent dans la clause INDEX_INCLUDE
INDEX_INCLUDE : liste des colonnes incluses. Pour les index CLUSTERED de type BTree, toutes les colonnes autre que celles de la clef étant présente, la valeur qui y figure est : * – (INDEX_KEY). Pour les index CLUSTERED COLUMNSTORE toutes les colonnes de la table étant présente dans l’index, la valeur qui y figure est : *
INDEX_FILTER : filtre d’index s’il y a lieu
INDEX_WITH : principaux paramètres de la clause WITH

Si vous l’exécutez sans spécifier le nom d’une table (le paramètre sera donc NULL) alors la procédure sort la liste des tous les index de toutes les tables, vues indexées comprises.

Vous pouvez transformer aisément cette procédure en une fonction table en ligne avantageuse.

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