Le blog de SQLpro » SQL Server 2005

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

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

LIKE ‘%mot%’ ou les index rotatifs….

SQLpro — Thu, 05 Jan 2017 20:01:44 +0000

Qui n’a jamais rêvé d’obtenir des performances pour rechercher des mots partiels contenus dans d’autres mots, comme par exemple tous les mots contenant « bolo » ? Dans un dictionnaire de 128 918 mots, une telle recherche met moins de 50 millisecondes à l’aide des index rotatifs, contre ??? pour le LIKE ‘%bolo%’… Explications…

diabolos, hyperboloïde, bolonaise, bolomètre, diabolo, bolométriques, amphibologie, bolonais, paraboloïde, amphibologique, bolométrique… Tels sont les mots du dictionnaire LEXIQUE du CNRS contenant la chaine de caractères « boblo ».

LE PROBLÈME

Les index des bases de données relationnelles, de type BTree (arbre équilibrés) trient les chaines de caractères par rapport à l’ordre orthographique des chaines de caractères au regard du classement des lettres de l’alphabet et de la collation choisie, cette dernière pouvant être sensible ou non, à la casse, aux accents…. Du fait de cet ordre, il est donc possible de rechercher par intervalle comme c’est le cas de la recherche d’un mot commençant par… En effet, si nous recherchons les mots commençant par « fass » ils sont regroupés les uns à la suite des autres dans l’index, ce qui permet un accès immédiat et la solution est, par exemple la suivante :

fasse

fassent

fasses

fassiez

fassions

Pour ce qui est des mots finissant par, l’index ne nous est d’aucune utilité, mais une astuce consiste à créer les mots inversés (par exemple à l’aide d’une colonne calculée), les indexer et rechercher par le même type de LIKE sur l’inverse de la terminaison souhaitée. Par exemple, rechercher tous les mots se terminant par « aide’, il suffit de faire la recherche suivante :

LIKE 'edia%'

et de renvoyer le mot correspondant !
Bien entendu pour rechercher un mot commençant par… et finissant par…, il suffit de combiner les deux recherches !
Un exemple est apporté par l’extrait de requête suivant :

WHERE MOT_MOT LIKE 'enta%' AND MOT_INVERSE LIKE CONCAT(REVERSE('aient'), '%')

Mais comment être efficace lorsque l’on recherche une chaine à l’intérieur d’un mot ? C’est là qu’intervient la notion d’index « rotatif »…

LE CONCEPT

Un index « rotatif » est en fait une liste de mots pour laquelle on supprime successivement la lettre du début à chaque tour, d’où le nom d’index « rotatif ».
Par exemple le mot « locomotive » sera ainsi décliné :

locomotive

ocomotive

comotive

omotive

motive

otive

tive

ive

On numérote alors chaque rotation, y compris le mot racine dont par convention on attribuera l’indice 0 comme niveau de rotation. Par exemple le « sous-mot » « motive » aura un indice de rotation de 4 parce qu’on lui aura retiré les 4 premières lettres.
Une fois ces mots Ajoutés dans une table de mots, il suffit de les indexer et d’ajouter une table des références croisées entre les mots racine et les rotations. La recherche peut désormais se faire via un LIKE ‘mot%’ qui permet d’exploiter l’index ! Mais il faut ensuite remonter au mot racine par une jointure à l’aide de la table des références croisées.

LA MÉCANIQUE

Afin de bien distinguer ces objets techniques de votre base, objets qui n’ont rien à voir avec les objets fonctionnels de votre application, je vous conseille de créer un schéma SQL spécifique pour les y stocker logiquement

CREATE SCHEMA S_XRT;

Les tables pour ce faire.

Deux tables suffisent : la table des mots, et la table des références croisées.

CREATE TABLE S_XRT.T_MOT
(MOT_ID INT IDENTITY PRIMARY KEY,
--> doit être sensible aux accents mais pas à la casse ! Exemple maïs et
-- mais, sur et sûr, retraite et retraité, congres et congrès !
MOT_MOT VARCHAR(32) COLLATE French_BIN NOT NULL UNIQUE);

CREATE TABLE S_XRT.T_MOT_ROTATION_MRT
(MRT_ID INT IDENTITY PRIMARY KEY,
-- pointe vers la rotation du mot
MOT_ID INT NOT NULL REFERENCES S_XRT.T_MOT (MOT_ID),
-- pointe vers la racine du mot
MOT_ID_RACINE INT NOT NULL REFERENCES S_XRT.T_MOT (MOT_ID),
-- indice de rotation
MRT_ROTATION TINYINT NOT NULL,
UNIQUE (MOT_ID, MOT_ID_RACINE, MRT_ROTATION));

Les routines

Une procédure va permettre d’indexer un mot. En voici le code en Transact SQL :

CREATE PROCEDURE S_XRT.P_INDEXATION_ROTATIVE @MOT VARCHAR(32)
AS

SET NOCOUNT ON;

SET @MOT = LOWER(LTRIM(RTRIM(@MOT)));

DECLARE @L TINYINT = LEN(@MOT), @ID_MOT INT;

DECLARE @ROTATIONS TABLE
(MOT VARCHAR(32) COLLATE French_BIN,
ROT TINYINT);

-- calcul des rotations, racine comprise (0)
WITH T AS
(SELECT @MOT AS M, 0 AS I
UNION ALL
SELECT RIGHT(M, @L-I - 1), I + 1
FROM T
WHERE I < @L - 1
)
INSERT INTO @ROTATIONS
SELECT * FROM T;

-- insertions des mots manquants
INSERT INTO S_XRT.T_MOT
SELECT MOT
FROM @ROTATIONS
WHERE MOT NOT IN (SELECT MOT_MOT
FROM S_XRT.T_MOT);

-- récupération de l'ID du mot racine
SELECT @ID_MOT = MOT_ID
FROM S_XRT.T_MOT
WHERE MOT_MOT = @MOT;

-- insertions des rotations manquantes
INSERT INTO S_XRT.T_MOT_ROTATION_MRT
SELECT M.MOT_ID, @ID_MOT, R.ROT
FROM @ROTATIONS AS R
JOIN S_XRT.T_MOT AS M
ON R.MOT = M.MOT_MOT
WHERE NOT EXISTS(SELECT *
FROM S_XRT.T_MOT_ROTATION_MRT AS MR
WHERE MR.MOT_ID = M.MOT_ID
AND MR.MOT_ID_RACINE = @ID_MOT
AND MR.MRT_ROTATION = R.ROT);

Enfin, une fonction table constituée d’une simple requête paramétrée, va permettre de retrouver les mots racine à partir des partiels :

CREATE FUNCTION S_XRT.F_SUPER_LIKE (@MOT VARCHAR(32))
RETURNS TABLE
AS
RETURN (SELECT MR.MOT_ID, MR.MOT_MOT
FROM S_XRT.T_MOT AS M
JOIN [S_XRT].[T_MOT_ROTATION_MRT] AS R
ON M.MOT_ID = R.MOT_ID
JOIN S_XRT.T_MOT AS MR
ON R.MOT_ID_RACINE = MR.MOT_ID
WHERE M.MOT_MOT LIKE LOWER(RTRIM(LTRIM(@MOT))) + '%');

QUELQUES TESTS

Nous sommes partis d’une base contenant le dictionnaire LEXIQUE du CNRS, comportant 128 918 mots.
Notre méthode pour les indexer tous a été d’utiliser un curseur pour connaitre le temps moyen mis par la procédure d’indexation. Ce traitement a été effectué sur une machine ayant les caractéristiques suivantes : 2 processeurs XEON, 48 cœurs , 128 Go de RAM, 8 disques SAS en RAID 10 avec SQL Server 2016.
Le temps de traitement a été de 26 minutes et 21 secondes, soit, pour 128 918 mots, 12 ms par mot.
Le traitement a généré :
* 376 567 entrées de mots dans la table S_XRT.T_MOT (représentant 24 Mo)
* 1 168 547 lignes dans la table S_XRT.T_MOT_ROTATION_MRT (représentant 62 Mo)
À noter qu’après réindexation, on observe une diminution du volume des données : 22 et 57 Ko respectivement.

Voici le batch que nous avons utilisé (la table du dictionnaire LEXIQUE du CNRS est dbo.TS_MOT_MOT :

DECLARE @T DATETIME = GETDATE();

DECLARE C CURSOR
LOCAL FORWARD_ONLY STATIC READ_ONLY
FOR
SELECT MOT_MOT
FROM dbo.TS_MOT_MOT
WHERE MOT_LONGUEUR > 1;

DECLARE @MOT VARCHAR(32);

OPEN C;

FETCH C INTO @MOT;

WHILE @@FETCH_STATUS = 0
BEGIN

EXEC S_XRT.P_INDEXATION_ROTATIVE @MOT;
FETCH C INTO @MOT;

END;

CLOSE C;

DEALLOCATE C;

SELECT DATEDIFF(ms, @T, GETDATE());

L’utilisation de la fonction table en ligne S_XRT.F_SUPER_LIKE, met en moyenne 50 ms quelques soit la racine cherchée si elle est constituée d’au moins 3 caractères. Exemple :

SELECT * FROM S_XRT.F_SUPER_LIKE('moti');

Pour la pire des recherches, le système met moins d’une seconde à trouver les 130 162 mots contenant la lettre e !

Pour comparaison, la recherche des mots comprenant les caractères « eta », d’une part directement dans le dictionnaire à l’aide d’un LIKE ‘%eta%’ et d’autres part dans l’index rotatif donne les métriques suivantes :
* Dictionnaire, LIKE’%eta%’ : temps UC = 652 ms, temps écoulé = 430 ms.
* Index rotatif, S_XRT.F_SUPER_LIKE (‘eta’) : Temps UC = 265 ms, temps écoulé = 50 ms.

Paradoxalement les plans de requête ne reflètent pas vraiment cette différence. les couts des plans apparaissent ainsi :
* Index rotatif, S_XRT.F_SUPER_LIKE (‘eta’) : 3,79 (soit 86 % de l’ensemble
* Dictionnaire, LIKE’%eta%’ : 0,61 (soit 14% de l’ensemble)

Plan de requête SQL Server utilisant une fonction table en ligne et l’index rotatif

Utilisation directe du LIKE ‘%toto%’

UN PEU D’ASTUCE

Au fur et à mesure de son utilisation, les index rotatifs grandissent de moins en moins, car ils contiennent déjà des rotations utilisables pour d’autres mots. On peut donc prévoir certaines manœuvres pour les rendre plus efficaces encore, comme le précalcul de certaines données, la compression des index ou encore l’utilisation de vues matérialisées (ou indexées sur SQL Server).

À titre d’exemple, nous avons obtenus la métrique suivante : temps UC = 63 ms, temps écoulé = 67 ms, à l’aide de l’une de ces techniques !

LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE
Le code SQL

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

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

Qui est leader dans les bases de données en 2016 ?

SQLpro — Thu, 27 Oct 2016 14:43:33 +0000

Selon l’étude 2016 du groupe Gartner au sujet des bases de données opérationnelles d’entreprise (OPDBMS), Microsoft est le n°1 sur les deux axes de mesure : facilité d’utilisation et visionnaire.

Source : Gartner – Magic Quadrant for Operational Database Management Systems 2016

Microsoft détient l’un des systèmes de bases de données relationnelles les mieux conçu, les plus utilisés et le plus fiable avec SQL Server, incorporant un moteur « in memory » (IMDBMS).
Mais il se trouve que Microsoft est aussi le numéro deux du cloud derrière Amazon (Azure SQL Database).
Il offre aussi différentes technologies complémentaire de type NoSQL avec Azure DocumentDB (un SGBD de type « document ») et Azure Tables (un SGBDR de type paire clef/valeur).
Très présent dans le cloud, y compris de manière hybride (une base SQL Serveur locale peut avoir une partie de ses données dans le cloud via le concept de « stretch tables« ), Microsoft offre aussi de nombreuses possibilité analytiques ou mobile.

Pour la troisième année consécutive Mictrosoft est numéro 2 en part de marché sur le plan financier, derrière Oracle dont le Gartner Group a remonté comme point négatif de l’étude, les problèmes de coûts, de complexité de licences et noté un rapport qualité prix jugé négatif par les clients.

Mais ce qui fait la force de Microsoft depuis toujours, et celle en particulier de ses solutions de bases de données, c’est la facilité d’utilisation (l’un des meilleurs scores de l’étude) et de migration de version (80% des clients ont trouvés que la migration des bases était plus facile que prévue ou autant que prévu)…

Les seuls problèmes pointés du doigt de manière négatives par le Gartner Group sont exclusivement celles liées au marketing, canaux de vente et distribution des solutions Microsoft ou l’éditeur reste encore perçut par certains comme un acteurs pour de petites solutions…
Finalement aucune critique technique ni financière ne vient ternir l’image d’excellence de Microsoft dans le domaines des bases de données d’entreprise ce qui tend à prouver que ce classement de leader est largement mérité !

***

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