Le blog de SQLpro » SQL Server 2017

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

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

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

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

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

Je lui donnais donc l’explication suivante…

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

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

Quid du mode SNAPSHOT ?

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

Alors, à quoi sert le NOLOCK ?

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

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

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

Des conflits ! Quels conflits ?

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

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

Les modes d’isolation selon la norme SQL

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

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

Activer le mode s’isolation SNAPSHOT

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

ALTER DATABASE { CURRENT | nom_base } SET ALLOW_SNAPSHOT_ISOLATION ON;

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

ALTER DATABASE { CURRENT | nom_base } SET READ_COMMITTED_SNAPSHOT ON;

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

Appendice :

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

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

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

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

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

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

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

Deadlock graph
Lock: Deadlock
Lock Deadlock Chain

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

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

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

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

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

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

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

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

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

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

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

Visualisation des requêtes en jeu dans un verrou mortel

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

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

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

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

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