Une procédure pour connaître l’état physique et l’utilisation des index

Voici une petite procédure stockée qui permet de connaître l’état physique des index (nombre de pages du niveau feuille, fragmentation et taux d’utilisation des pages) en même temps que la façon dont ils sont utilisés (nombres de seeks et de scans, …).

Elle est utilisable pour collecter ces statistiques sur l’ensemble d’une base de données, ou bien sur une table en particulier
Lire la suite

Trouver le nombre de lignes de toutes les tables d’une base de données

Il est intéressant, pour suivre l’évolution d’une base de données, et pour prévoir l’espace disque nécessaire, de connaître le nombre de lignes que contient chaque table.

Ce qui vient en premier à l’esprit lorsqu’on souhaite quantifier les lignes, c’est d’exécuter un SELECT COUNT(*) sur chacune des tables à travers un curseur sur chacune des tables de la base de données, ou encore d’user de la procédure stockée système sp_spaceused sur le même modèle.
Mais il est évident que ce n’est pas performant et le résultat est long à obtenir.
Voyons comment obtenir cela sans effort, ni pour nous, ni pour le moteur de base de données …

Lire la suite

Trouver les contraintes qui ne sont pas fiables

Pour faciliter le chargement de données, il est parfois nécessaire de désactiver une contrainte de domaine (CHECK) ou de clé étrangère, puis de la réactiver dès la fin du chargement.

Si l’on écrit :

ALTER TABLE maTable CHECK CONSTRAINT maContrainte

La contrainte est alors marquée comme non-fiable, et le moteur de bases de données ne s’en sert plus dans ses plans de requête.
Pire, cela signifie que l’intégrité des données qui ont été importées est alors mise en défaut.

Il faut donc écrire :

ALTER TABLE maTable WITH CHECK CHECK CONSTRAINT maContrainte

Pour que les valeurs ajoutées pendant que la contrainte était désactivée soient vérifiées.

Voici donc une petite requête pour trouver les contraintes qui ne sont plus fiables pour le moteur de base de données …

Lire la suite

Vérifier l’unicité d’une position avec le type GEOGRAPHY sous SQL Server 2008

SQL Server 2008 a introduit de nombreux nouveaux types de données, dont le type de données géographiques GEOGRAPHY.
Ce n’est pas un type habituel, puisque c’est un type CLR.NET intégré à SQL Server.

L’avantage présenté par l’intégration de ce type est l’ensemble des méthodes standard « livrées » avec ce type, qui permettent d’extraire très simplement une latitude (attribut Lat), une longitude (attribut Long), ou encore de connaître la distance entre deux points géographiques avec la méthode STDistance.

Mais il devient alors plus complexe de garantir l’unicité de positions dans une table où l’on stocke la celle de plusieurs villes.
En effet, si une colonne de ce type est spécifiée comme clé d’une contrainte d’unicité, le moteur de base de données SQL Server lève une exception.

Est-il possible de contourner ce problème ?

Lire la suite

Les jointures triangulaires

Nous avons tous entendu qu’écrire du code ensembliste pour gérer des données dans une base de données est la meilleure façon d’obtenir des performances correctes.

Il est vrai qu’il est difficile pour un développeur ayant une expérience du développement d’applications, en quelque langage de programmation que ce soit, de passer du code procédural, qui, en outre, traite des jeux de données extraits de bases de données « ligne par ligne », à un langage conçu pour manipuler des ensembles de données.

Nous n’aborderons pas ici l’utilisation, à proscrire, des curseurs et des boucles utilisant la commande WHILE, mais nous allons voir que, si l’on croit avoir écrit du code ensembliste, il s’agit en fait de code procédural, et qu’il peut s’avérer être contre-performant. Lire la suite