Le blog de SQLpro » SQLpro

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

Cosmos DB, la base NoSQL à tout faire !

SQLpro — Mon, 06 Aug 2018 16:19:14 +0000

Vous en rêviez ? Cosmos DB l’a fait ! Une seul base de données, permettant à la fois et dans un même espace de stockage de combiner les différentes technologies des bases de données NoSQL… « Wide Column », « Graph Database », « Key-Value » et « Document Stores », toutes ces technologies sont disponible dans une seule et même base de données de nom Cosmos DB…

Là ou certaines clients doivent jongler avec plusieurs SGBD pour satisfaire différentes facettes fonctionnelles, Cosmos DB fait la synthèses des plus importantes technologies utilisées de manière combinées dans un seul et même produit.

Je me suis amusé à comparer, via le célèbre site db-engines.com qui publie des résultats de collecte de données statistiques d’utilisation, les différents graphes de popularité des produits concurrents de Cosmos DB et n’ai retenu que les SGBD qui lui était encore supérieur… Force est de constater la progression fulgurante de Cosmos DB qui, en quelques mois à dépassé OrientDB, Oracle Berkely DB, CouchDB, Google Cloud, MarkLogic, Google Big Table…
Et Cosmos DB talonne Cassandra, HBase, Neo4J, MongoDB, Memcached, Amazon DynamoDB et Redis.

1 – Graphe de popularité Key-value stores

Cosmos DB progresse de 29 fois en 4 ans alors que Redis (leader) n’a fais que 4,6 sur la même période !

2 – Graphe de popularité Wide Columns stores

Cosmos DB progresse de 29 fois en 4 ans alors que Cassandra (leader) n’a fais que 1,4 sur la même période !

3 – Graphe de popularité Graph DBMS

Cosmos DB progresse de 29 fois en 4 ans alors que Neo4j (leader) n’a fais que 1,7 sur la même période !

4 – Graphe de popularité Document Stores

Cosmos DB progresse de 29 fois en 4 ans alors que MongoDB (leader) n’a fais que 1,46 sur la même période !

Allez, je fais un pari… Avant 2 ans, Cosmos DB sera au pire, la seconde base en popularité dans chacune de ces 4 catégories avec comme unique « sparring partner » :

Redis pour la partie Key-Value

MongoDB pour la partie Document Stores

Neo4J pour la partie « graph database » (et là je pense que Cosmos DB va le doubler)

Cassandra pour la partie « Wide Column »

Je parie aussi pour la disparition, à plus ou moins long terme, de produits comme OrientDB, CouchDB et MarkLogic…

Donc rendez vous début août 2020…

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

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/

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

Comparer deux requêtes aux résultats identiques

SQLpro — Mon, 28 May 2018 07:25:44 +0000

Comment savoir si deux requêtes donnent le même résultat ?

Il suffit d’une simple équation ensembliste pour ce faire. Sachant que la requête 1 donne comme résultat l’ensemble A et que la requête 2 donne comme résultat l’ensemble B, prouver que ces deux requêtes donnent le même résultat, nécessite d’appliquer l’équation :

A – B U B – A = Ø

Autrement dit que l’union de la soustraction des éléments de B à l’ensemble A et de la soustraction des éléments de A à l’ensemble B ne donne aucun résultat (ensemble vide).

Ceci s’exprime en SQL de la sorte :

WITH
TA AS (SELECT ....), -- requête 1
TB AS (SELECT ....) -- requête 2
SELECT * FROM TA
EXCEPT
SELECT * FROM TB
UNION ALL
SELECT * FROM TB
EXCEPT
SELECT * FROM TA;

Ne donne aucun résultat… CQFD

PS : pour oracle utilisez MINUS au lieu de EXCEPT….

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

SQL Server 2017 comparatif performances Linux vs Windows

SQLpro — Tue, 27 Mar 2018 09:38:20 +0000

Le but de cet article est de comparer les performances de Microsoft SQL Server 2017 sous Linux par rapport à Windows. Il a été élaboré sur des machines physiques strictement identiques pour ôter tout biais lié a l’utilisation de machines virtuelles.

Vous trouverez les détails de cet article dans le fichier pdf suivant :
sqlpro.developpez.com/article/sql_server_2017_linux_vs_windows/Benchmark_SQL_Server_2017_Linux_vs_Windows.pdf

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