Le blog de SQLpro » Statistiques

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

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

Détecter les statistiques redondantes

SQLpro — Wed, 04 Nov 2015 20:22:55 +0000

Il est conseillé de ne jamais avoir de statistiques redondantes dans une base de données. Il est hélas assez facile d’en avoir sans s’en rendre compte. La requête présentée ici vous permet de les détecter et de les éradiquer…

Voici un exemple simple qui vous montre comment obtenir des statistiques redondantes :

1 – création de la base

CREATE DATABASE DB_TEST_STATS;
GO

ALTER DATABASE DB_TEST_STATS
SET AUTO_CREATE_STATISTICS ON;
GO

USE DB_TEST_STATS;
GO

CREATE TABLE T (C1 INT, C2 UNIQUEIDENTIFIER, C3 DATE)
GO

INSERT INTO T
SELECT FLOOR(RAND() * 123456), NEWID(), DATEADD(SECOND, RAND() * -100000000, GETDATE())
GO 1000

La base DB_TEST_STATS comporte une table de nom T avec 3 colonne. La dernière commande à remplie cette table avec 1000 lignes de manière aléatoire. À ce stade, aucune statistique n’existe sur cette table :

SELECT *
FROM sys.stats
WHERE object_id = OBJECT_ID('dbo.T');

2 – génération automatique des statistiques

En lançant différentes requêtes, nous allons maintenant avoir différents statistiques créées :

SELECT *
FROM T
WHERE C1 = 123

SELECT *
FROM T
WHERE C2 > 'F840197D-A7EE-41EF-84E6-023286970753'

SELECT *
FROM T
WHERE C3 '1990-12-31'

En relançant la requête précédente :

SELECT *
FROM sys.stats
WHERE object_id = OBJECT_ID('dbo.T');

Nous voyons maintenant apparaître 3 statistiques pour cette table (attention les valeurs de la colonne « name » peuvent différer).

object_id name stats_id auto_created
----------- ---------------------------------- ----------- ------------
245575913 _WA_Sys_00000001_0EA330E9 2 1
245575913 _WA_Sys_00000002_0EA330E9 3 1
245575913 _WA_Sys_00000003_0EA330E9 4 1

Ces statistiques sont des statistiques de colonne.

3 – ajout d’index=> statistiques redondantes

Si nous ajoutons un index sur une des colonnes, par exemple la colonne C3 :

CREATE INDEX X ON T (C3);

Nous voyons apparaître une nouvelle statistique dont le nom est le même que l’index.

Néanmoins, deux de ces statistiques portent sur la même colonnes…
Est-il bien raisonnable de maintenir ces deux statistiques ? N’oubliez pas que la maintenance des statistiques a un coût….

Le même problème peut survenir si vous créez des index inclus. Mais vous ne pourrez pas supprimer ces statistiques car les statistiques d’index ne sont pas supprimables…

4 – la requête de détection des statistiques redondantes

WITH T0 AS
(
SELECT s.object_id, s.name AS STAT_NAME, i.name AS INDEX_NAME,
CASE WHEN i.is_primary_key = 1 THEN 'PRIMAY KEY'
WHEN i.is_unique_constraint = 1 THEN 'UNIQUE'
END AS CONSTRAINT_TYPE,
i.has_filter AS HAS_FILTER,
(SELECT TOP 1 c.name
FROM sys.stats_columns AS sc
JOIN sys.COLUMNS AS c
ON sc.object_id = c.object_id
AND sc.column_id = c.column_id
WHERE s.object_id = sc.object_id
AND s.stats_id = sc.stats_id
ORDER BY sc.stats_column_id) AS STAT_COLUMN,
STUFF((SELECT ', ' + c.name
FROM sys.stats_columns AS sc
JOIN sys.COLUMNS AS c
ON sc.object_id = c.object_id
AND sc.column_id = c.column_id
WHERE s.object_id = sc.object_id
AND s.stats_id = sc.stats_id
ORDER BY sc.stats_column_id
FOR XML PATH('')), 1, 1, '') AS KEY_COLS
FROM sys.stats AS s
LEFT OUTER JOIN sys.indexes AS i
ON s.object_id = i.object_id
AND s.name = i.name
)
SELECT A.*, B.STAT_NAME AS STAT_NAME2, B.INDEX_NAME AS INDEX_NAME2,
B.CONSTRAINT_TYPE AS CONSTRAINT_TYPE2, B.HAS_FILTER AS HAS_FILTER2,
B.KEY_COLS AS KEY_COLS2,
N'DROP STATISTICS [' + s.name + N'].[' + o.name + N'].[' +
B.STAT_NAME + N'];' AS DROP_STAT
FROM T0 AS A
JOIN T0 AS B
ON A.STAT_COLUMN = B.STAT_COLUMN
AND A.STAT_NAME B.STAT_NAME
AND A.object_id = B.object_id
JOIN sys.objects AS o
ON A.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
WHERE B.INDEX_NAME IS NULL
AND o."type" IN ('V', 'U');

NOTA : l’éditeur de developpez.com ayant quelques défauts, si cette requête ne passe pas, utilisez le fichier joint :
Statistiques inutiles qui est en fait un fichier txt en non PDF !

À vous maintenant de décider !

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

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