Le blog de SQLpro » performance

Modèle générique vs modèle spécifique

SQLpro — Fri, 10 Aug 2018 08:04:43 +0000

Dans le cadre d’un héritage de données ayant de multiples enfants aux caractéristiques très diverses, est-il préférable de concevoir un modèle de données générique ou un modèle de données spécifique ? De nombreux jeunes développeurs pensent naïvement qu’un modèle générique est plus facile… Mais c’est souvent une erreur qu’il faudra payer au prix fort une fois l’application fonctionnelle. Démonstration…

Je suis partit initialement de ce post :

Avis sur l’architecture de ma base de données (choix de l’option)

La demande étant la suivante :

J’ai 30 familles de critères. Chaque famille comporte un nombre variable de critères pour un total d’environ 600 critères.
Chaque critère appartient à une seule famille de sorte que les 600 sont à répartir dans les 30 familles.
Ma question:
– devrais-je créer une table par famille et insérer dans chaque table les critères qui lui appartiennent; (solution 1)
ou alors:
– créer une table contenant les 30 familles et une autre contenant les 600 critères. Ensuite, créer les relations qui lient chaque famille à ses critères et/ou inversement. (solution 2)

et ma réponse :

Pour qu’une base réponde bien en terme de performances, on doit tout faire pour minimiser les IO.
– Dans votre solution 1, les performances seront bonne si la plupart des requêtes portent sur plusieurs critères d’une même famille
– Dans votre solution 2, les performances seront bonne si la plupart des requêtes portent sur un seul critère.

Cependant un jeune internaute peu avisé, affirmait avec force que :

pour moi la solution 2 est la + simple à mettre en place.
et le nombre d’enregistrements ne justifie pas la solution 1..
tout dépend de votre SGBD (pas précisé..), mais dans tous les cas, il suffit de mettre des ID numérique pour que les requêtes soient optimisées. Créez vos tables avec des id uniques (sous Oracle on peux utiliser les séquences) et vous aurez des traitements optimisées au mieux… mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb..
si je vois bien, vous aurez donc 3 tables avec les clef suivante :
– FAMILLE (Pk : ID_FAMILLE)
– FAMILLE_CRITERE (Pk : ID_FAMILLE, ID_CRITERE)
– CRITERE (Pk : ID_CRITERE)
Relations :
¤ Famille –> FAMILLE_CRITERES <— CRITERE
famille_critere ne contenant que le couple ID_FAMILLE, ID_CRITERE (on parle de table intermédiaire)

Ce à quoi je répondais :

La solution 2 est correcte si vous ne requêtez JAMAIS plus d’un critère à la fois. Elle est déjà moins performante à l’insertion/la mise à jour des données…
La solution 2 est imbécile, complexe et peu performantes si vous avez plusieurs critères a rechercher…
En sus, elle ne permet pas facilement de typer les informations, donc, vous aurez beaucoup de problématique de contrôle de qualité… et des performances catastrophiques

DÉMONSTRATION

Partons d’une table d’animaux :

CREATE TABLE T_ANIMAL_ANM
(ANM_ID INT PRIMARY KEY,
ANM_DATA CHAR(8000) NOT NULL);
GO

INSERT INTO T_ANIMAL_ANM VALUES (1, 'Mytilus Edulis')

█ █ █ 1ere solution : une seule table pour toute une même famille :

CREATE TABLE T_MOLUSQUE_MSQ
(ANM_ID INT PRIMARY KEY REFERENCES T_ANIMAL_ANM (ANM_ID),
MSQ_CARAPACE VARCHAR(32),
MSQ_SYMETRIE VARCHAR(32),
MSQ_COULEUR VARCHAR(32),
MSQ_DIAMETRE_MM FLOAT);

█ █ █ 2e solution (pour toutes familles), des tables « génériques » :

CREATE TABLE T_CARATERISTIQUE_CRT
(CRT_ID INT PRIMARY KEY,
CRT_LIBELLE VARCHAR(256));

CREATE TABLE T_VALEUR_VLR
(ANM_ID INT NOT NULL REFERENCES T_ANIMAL_ANM (ANM_ID),
CRT_ID INT NOT NULL REFERENCES T_CARATERISTIQUE_CRT(CRT_ID),
VLR_VALEUR VARCHAR(256),
PRIMARY KEY (ANM_ID, CRT_ID));

Ajoutons les caractéristiques identiques à celle de la solution 1

INSERT INTO T_CARATERISTIQUE_CRT VALUES (111, 'Carapace');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (222, 'Symétrie');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (333, 'Couleur');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (444, 'Diamètre mm');

█ █ █ Voici maintenant les insertions :

Pour la solution 1 :

INSERT INTO T_MOLUSQUE_MSQ (ANM_ID, MSQ_CARAPACE, MSQ_SYMETRIE, MSQ_COULEUR, MSQ_DIAMETRE_MM)
VALUES (1, 'Creatine', 'Mono', 'Bleu', '82.5')

Notez que nous n’avons fait qu’une seule requête d’insertion avec correspondance caractéristique / valeur et typage des données

Pour la solution 2 :

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Creatine' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Carapace';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Mono' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Symétrie';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Bleu' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Couleur';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, '82,5' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Diamètre mm';

Pour stocker les mêmes informations, nous avons fait 4 requêtes au lieu d’une seule….

█ Comparons maintenant le coût des 2 solutions au niveau de l’insertion :

Y’a pas à tortiller 4 requêtes coutant deux fois plus cher qu’une seule et unique requête cela est donc 8 fois plus couteux…

█ █ █ Voyons maintenant la facilité de requêtage :

interrogation multicritères ET avec solution 1

SELECT *
FROM T_ANIMAL_ANM AS A
JOIN T_MOLUSQUE_MSQ AS M
ON A.ANM_ID = M.ANM_ID
WHERE MSQ_CARAPACE = 'Creatine'
AND MSQ_SYMETRIE IN ('Mono', 'Double')
AND MSQ_COULEUR LIKE 'Bleu%' --> peut être Bleue, Bleu-marine...
AND MSQ_DIAMETRE_MM BETWEEN 75 AND 92;

la requête fait 8 lignes et 1 jointure. Elle en fera une de plus pour chaque critère supplémentaire avec juste quelques chose à rajouter à la clause WHERE…

interrogation multicritères ET avec solution 2

SELECT *
FROM T_ANIMAL_ANM AS A
JOIN T_VALEUR_VLR AS V1
ON A.ANM_ID = V1.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C1
ON V1.CRT_ID = C1.CRT_ID
JOIN T_VALEUR_VLR AS V2
ON A.ANM_ID = V2.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C2
ON V2.CRT_ID = C2.CRT_ID
JOIN T_VALEUR_VLR AS V3
ON A.ANM_ID = V3.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C3
ON V3.CRT_ID = C3.CRT_ID
JOIN T_VALEUR_VLR AS V4
ON A.ANM_ID = V4.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C4
ON V4.CRT_ID = C4.CRT_ID
WHERE C1.CRT_LIBELLE = 'Carapace'
AND V1.VLR_VALEUR = 'Creatine'
AND C2.CRT_LIBELLE = 'Symétrie'
AND V2.VLR_VALEUR IN ('Mono', 'Double')
AND C3.CRT_LIBELLE = 'Couleur'
AND V3.VLR_VALEUR LIKE 'Bleu%'
AND C4.CRT_LIBELLE = 'Diamètre mm'
AND V4.VLR_VALEUR BETWEEN '75' AND '92'

La requête fait 26 lignes avec 8 jointures… Il faudra rajouter 6 lignes à chaque critère supplémentaire, dont 4 dans la clause FROM et 2 dans le WHERE, et encore, on ne sait pas dans la clause SELECT à quelle caractéristique se réfère chacune des valeurs… Il faudrait aussi customiser la clause SELECT…

Y’a pas à tortiller la solution 1 est bien plus simple en matière d’écriture…

█ Quelles sont les performances des requêtes de recherches des deux solutions ?

Évidemment la première solution est 4,5 fois moins couteuse…

Mais il y a pire… J’ai du mettre des chiffres en chaine de caractères pour le diamètre (AND V4.VLR_VALEUR BETWEEN ’75’ AND ’92’). Si je tente de les typer en entier ou réel (AND V4.VLR_VALEUR BETWEEN 75 AND 92), cela provoque une erreur d’exécution (SQL Server) :
Msg*245, Niveau*16, État*1, Ligne*75
Échec de la conversion de la valeur varchar ‘Creatine’ en type de données int.
Logique car pour effectuer une comparaison avec une valeur numérique, il faut convertir la colonne en numérique, mais comme il y a autres chose que de purs nombres (chaines de caractères) cela se passe mal.
Bref certaines requêtes seront impossible à faire !

Plus catastrophique encore… mettre des index ne servira quasiment à rien ! En effet un index sur une chaine de caractères n’ordonne pas les valeurs de la même façon que s’il s’agissait de nombre…

En sus rien n’interdira à quelqu’un de saisir 8,2 au lieu de 8.2 (une virgule au lieu d’une point) comme diamètre, dans ce modèle inepte, alors qu’avec le bon modèle les types sont respectés…. Si tel était le cas, la valeur ne pourra pas être retrouvée !!! Il existe bien évidemment une solution pour contourner, un tout petit peu, ce modèle pourri, pour le typage. Il consiste à rajouter autant de tables de valeurs que de type… Mais il n’est pas possible de rajouter des contraintes spécifique à chaque type (par exemple vérifier qu’une pourcentage est bien entre 0 et 100 – notion de domaine SQL), ni, bien entendu, de rajouter des contraintes multicritères (une valeur dépendant d’une autre) comme c’est le cas par exemple de la chronologie des temporels de type « début » et « fin ».
Et dans tous les cas, les requêtes seront encore plus complexes à élaborer et les performances encore plus lamentables…

En guise de conclusion

Nous vous avons démontré les performances lamentable et la complexité horrifiante d’un tel modèle….

Complexité d’insertion des données

Mauvaise performances à l’insertion des données

Complexité d’écriture des recherches

Mauvaise performances pour la recherches de données

Impossibilité de typer finement (notion de domaine)

Impossibilité de placer des contraintes multicritères

Difficultés pour l’indexation

Mais comment se fait-il que des internautes osent affirmer de pareilles stupidités ?

Il est amusant de voir que certains développeur incultes affirment n’importe quoi, par ignorance, ou par bêtise, ne prenant même pas la peine de tester ce qu’ils disent… Ensuite ces mêmes développeurs, sans aucune expérience, iront vous raconter que les SGBDR c’est pas performant… Ils vous vendrons alors du NoSQL, ce qui, dans beaucoup de cas, sera pire encore !

Comme disent les américains : « garbage in, garbage out » qui peut se traduire si tu fais de la merde en entrée, tu auras de la merde en sortie ! Autrement dit, si le modèle de données est inepte, la qualité des données sera pourrie et les performances lamentables…

Décortiquons d’ailleurs les affirmations de l’internate que nous avons cité :
« tout dépend de votre SGBD (pas précisé..), mais dans tous les cas, il suffit de mettre des ID numérique pour que les requêtes soient optimisées. Créez vos tables avec des id uniques (sous Oracle on peux utiliser les séquences) et vous aurez des traitements optimisées au mieux… mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb.. »

Première affirmation stupide : « tout dépend de votre SGBD (pas précisé..) »
Comme nous sommes dans un forum sur les SGBDR, sachez cher monsieur, que tout les SGBDR fonctionnent de la même façon. Certains allant plus vite que d’autre (une Ferrari va généralement plus vite qu’une Peugeot), certains avec plus de qualité que d’autres (une Rolls-Royce est généralement de meilleure qualité qu’une Dacia).

Seconde affirmation stupide : « il suffit de mettre des ID numérique pour que les requêtes soient optimisées »
Si c’était le cas alors, pas besoin d’index ni de contraintes… On se demande donc pourquoi les éditeurs de SGBDR font de tels effort en R&D pour trouver de nouvelles formes d’index toujours plus performant… Et la plupart des informaticiens ignorent que les contraintes permettent de mieux optimiser les plans de requête… Hélas ceci est très rarement enseigné par les professeurs des universités et encore moins ceux des écoles d’ingénieurs… (je le sais pertinemment puisque j’en étais un…).

Troisième affirmation stupide : « mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar »
Et bien, non, plus une clef est longue en nombre d’octets, plus ses performances décroissent. Pour avoir la même longueur qu’un entier auto incrémenté il faudrait se limiter à 4 caractères… En sus certaines phénomènes apparaissent avec des clefs non numériques et en particulier pour des clefs littérales :

distribution peu aléatoire (parce que concentrées sur les 26 lettres et 10 chiffres parmi les 256 caractères disponibles) induisant des statistiques d’optimisation mal réparties (histogrammes erratiques)

extra-overhead lié à la gestion de la collation (sensibilité ou non à la casse, aux accents…)

façon de stocker physiquement les VARCHAR induisant des octets suplementaires et de la fragmentaion en cas d’UPDATE

Quatrième affirmation stupide : « sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb.. »
Nous avons déjà dit précédemment que les clef littérales (VARCHAR) étaient une plaie… Mais ce qui ne va pas dans cette phrase est le terme « enregistrement« … Cet internaute sait-il au moins que les SGBDR ne travaillent pas avec des « enregistrement » propre aux bases de données de type « fichier » comme c’était las cas dans les années 50 à 70 ? Les SGBDR structurent les lignes des tables dans des pages qui sont modifiées en mémoire et non pas directement sur le disque (notion physique d’enregistrement). Les pages étant physiquement écrites de temps à autres quand il y en a suffisamment à écrire par un processus asynchrone travaillant en tâche de fond.

Bref voici q’un internaute ne connaissant ni la modélisation des données ni les technologies des SGDB, vient donner des conseils stupides hélas parfois repris dans certaines applications….

CQFD

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

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

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

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

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

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

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

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

La requête pour les lectures :

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

La requête pour les écritures :

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

Un exemple de résultat pour la lecture :

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

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

Détecter les index obèses

SQLpro — Wed, 09 Dec 2015 09:59:02 +0000

Voici en complément des 20 requêtes pour auditer la qualité de votre modèle de données (voir 20 requêtes pour auditer la qualité de votre modèle de données) une requête destinée à déceler les index obèses (c’est à dire, ceux ayant trop de colonnes dans leur définition.

Voici la requête :

WITH
T0 AS
(
SELECT o.object_id, i.index_id,
s.name AS TABLE_SCHEMA,
o.name AS TABLE_NAME,
i.name AS INDEX_NAME,
is_included_column,
COUNT(*) AS NOMBRE
FROM sys.objects AS o
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
JOIN sys.indexes AS i
ON o.object_id = i.object_id
JOIN sys.index_columns AS ic
ON i.object_id = ic.object_id
AND i.index_id = ic.index_id
WHERE i.index_id > 0
AND is_ms_shipped = 0
GROUP BY o.object_id, i.index_id, s.name, o.name, i.name, is_included_column
)
SELECT T1.TABLE_SCHEMA,
T1.TABLE_NAME,
T1.INDEX_NAME,
T1.NOMBRE + T0.NOMBRE AS NOMBRE_COLONNES,
T0.NOMBRE AS NOMBRE_COLONNES_CLEFS,
T1.NOMBRE AS NOMBRE_COLONNES_INCLUSES
FROM T0
JOIN T0 AS T1
ON T0.object_id = T1.object_id
AND T0.index_id = T1.index_id
WHERE T0.is_included_column = 1
AND T1.is_included_column = 0
AND T1.NOMBRE + T0.NOMBRE > 10 --> seuil limite du nombre de colonnes dans l'index à ne pas dépasser

Le seuil étant fixé à 10 colonnes, vous pouvez être plus sévère encore ou plus laxiste à votre choix !!!

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

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

Métriques du stockage de vos bases

SQLpro — Sun, 04 Oct 2015 10:19:41 +0000

Il est important pour un DBA de vérifier régulièrement le stockage de ses bases et anticiper sur les volumes afin de ne jamais avoir d’opérations de croissance qui pénalise fortement les performances (capacity planning). Pour cela il est nécessaire de vérifier régulièrement l’adéquation des « enveloppes » du stockage et du volume qui y figure afin de réagir avant qu’une croissance automatique ait lieu.

Pour ce faire vous devez mesurer régulièrement les volumes des fichiers, des données (tables et index) des transactions et réajuster les tailles de fichiers.
Voici une procédure qui vous donne ces métriques.

LA PROCÉDURE :

USE master;
GO

CREATE PROCEDURE dbo.sp__METRIQUE_STOCKAGE @REAJUSTE BIT = 0
AS
SET NOCOUNT ON;

IF @REAJUSTE = 1
--> réajustement des statistiques des espaces de stockage
DBCC UPDATEUSAGE (0);

--> volume des transactions
DECLARE @T TABLE (database_name sysname, log_size_mb FLOAT, log_space_used_percent FLOAT, STATUS bit);
DECLARE @TRANSACTIONS_RESERVEES_MO BIGINT,
@TRANSACTIONS_UTILISEES_MO BIGINT,
@TRANSACTIONS_UTILISEES_POURCENT DECIMAL(5,2);
INSERT INTO @T
EXEC ('DBCC SQLPERF(LOGSPACE)')
SELECT @TRANSACTIONS_RESERVEES_MO = ROUND(log_size_mb, 0),
@TRANSACTIONS_UTILISEES_MO = ROUND(log_size_mb * log_space_used_percent / 100.0, 0),
@TRANSACTIONS_UTILISEES_POURCENT = CAST(log_space_used_percent AS DECIMAL(5,2))
FROM @T WHERE database_name = DB_NAME();

-- taille de l'enveloppe de stockage :
WITH
T_FILES AS (
SELECT CAST(ROUND(SUM(CASE WHEN "type" = 1
THEN SIZE
ELSE 0
END) / 128.0, 0) AS BIGINT) AS TRANSACTIONS_RESERVEES_MO,
CAST(ROUND(SUM(CASE WHEN "type" != 1
THEN SIZE
ELSE 0
END) / 128.0, 0) AS BIGINT) AS DONNEES_RESERVE_MO
FROM sys.database_files),
T_DB AS (
SELECT TRANSACTIONS_RESERVEES_MO + DONNEES_RESERVE_MO AS BASE_TAILLE_MO,
DONNEES_RESERVE_MO, TRANSACTIONS_RESERVEES_MO
FROM T_FILES),
T_PAGES AS (
-- taille des pages données et index
SELECT CAST(ROUND(SUM(au.used_pages) / 128.0, 0) AS BIGINT) AS DONNEES_UTILISEES_MO,
CAST(ROUND(SUM(CASE
WHEN it.internal_type IN (202, 204, 211, 212, 213, 214, 215, 216)
THEN 0
WHEN au.TYPE != 1
THEN au.used_pages
WHEN p.index_id < 2
THEN au.data_pages
ELSE 0
END) / 128.0, 0) AS BIGINT) AS TABLES_MO
FROM sys.partitions AS p
INNER JOIN sys.allocation_units au
ON p.partition_id = au.container_id
LEFT OUTER JOIN sys.internal_tables AS it
ON p.object_id = it.object_id)
SELECT BASE_TAILLE_MO,
DONNEES_RESERVE_MO,
DONNEES_UTILISEES_MO,
CAST(100.0 * CAST( DONNEES_UTILISEES_MO AS FLOAT)
/ DONNEES_RESERVE_MO AS DECIMAL(5,2)) AS DONNEES_UTILISEES_POURCENT,
TABLES_MO,
DONNEES_UTILISEES_MO - TABLES_MO AS INDEX_MO,
CAST(100.0 * CAST( TABLES_MO AS FLOAT)
/ DONNEES_UTILISEES_MO AS DECIMAL(5,2)) AS TABLES_POURCENT ,
CAST(100.0 * CAST( DONNEES_UTILISEES_MO - TABLES_MO AS FLOAT)
/ DONNEES_UTILISEES_MO AS DECIMAL(5,2)) AS INDEX_POURCENT,
TRANSACTIONS_RESERVEES_MO,
@TRANSACTIONS_UTILISEES_MO AS TRANSACTIONS_UTILISEES_MO,
@TRANSACTIONS_UTILISEES_POURCENT AS TRANSACTIONS_UTILISEES_POURCENT
FROM T_PAGES CROSS JOIN T_DB;
GO

Pour pouvoir l'exécuter de n'importe quelle base, nous pouvons la marquer comme procédure système :

EXEC sp_MS_marksystemobject 'sp__METRIQUE_STOCKAGE';
GO

Les métriques fournies par cette procédure sont les suivantes :
BASE_TAILLE_MO : taille globale de la base y compris transactions
DONNEES_RESERVE_MO : taille réservée pour les données de la base
DONNEES_UTILISEES_MO : volume effectif des données de la base (tables et index)
DONNEES_UTILISEES_POURCENT : taux de remplissage des données dans les fichiers de la base
TABLES_MO : volume des données des tables (à titre indicatif)
INDEX_MO : volume des index (à titre indicatif)
TABLES_POURCENT : proportion du volume des tables en % (à titre indicatif)
INDEX_POURCENT : proportion du volume des index en % (à titre indicatif)
TRANSACTIONS_RESERVEES_MO : taille réservée pour le journal de transaction de la base
TRANSACTIONS_UTILISEES_MO : volume effectif des transactions de la base
TRANSACTIONS_UTILISEES_POURCENT : taux de remplissage des transactions dans les fichiers de la base

Les deux métriques les plus importantes sont indiquées en gras. C’est sur celles-ci qu’il faut réagir au plus vite en redimensionnant les fichiers ou en rajoutant de nouveaux fichiers…
Il est d’usage de se poser des questions lorsque les taux de remplissage dépasse 70%, de planifier la croissance à 80 et d’agir impérativement à 90%.

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

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

Où et comment sont stockées mes données avec PostGreSQL ?

SQLpro — Thu, 07 Mar 2013 10:46:25 +0000

Comme tous les SGBD relationnel, PostGreSQL stocke les données des tables et des index dans des fichiers organisés sous forme de pages. Que les données soient dans le cache (donc en mémoire vive), ou bien sur le disque, ces pages sont structurées d’une manière bien particulière afin d’exploiter au mieux les lectures et écritures physiques et logiques ainsi que la gestion des versions de ligne.
L’ensemble des pages figurent dans des fichiers.
Cet article a pour but de vous présenter comment et où PostGreSQL stocke les données et compare sa façon de faire aux autres SGBDR que sont Oracle et MS SQL Server.
Mais contrairement à ses grands frères, PostGreSQL ne dispose pas d’une gestion des espaces de stockage… Voyons ce que cela induit notamment sur le plan des performances et de la volumétrie.

L’étude est disponible sous format PDF à l’URL suivante : Ou sont stockées mes données avec PostGreSQL

Le site web sur le SQL et les SGBDR


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’ntreprise SQL Spot