Trouver et corriger les index uniques (non filtrés) sans contrainte

Exception faite des index unique filtrées, il n’y aucune différence en termes de performances entre l’ajout d’un index unique, et l’ajout d’une contrainte d’unicité (qui est elle-même supportée par un index unique).
La contrainte d’unicité permet de signifier que l’intégrité des données est le but, alors que le but premier d’un index est l’accélération des requêtes.
La majorité des index unique étant ajoutés pour renforcer l’intégrité des données, voici donc un script pour trouver tous les index unique non filtrés qui n’ont pas de contrainte d’unicité.

Lire la suite

Etude de table : retourner les caractéristiques des statistiques et index d’une table (ou vue indexée)

Voici un script qui retourne :

– l’en-tête des statistiques d’une table
– la liste des colonnes qui participent à la statistique, ou des colonnes clé de l’index (incluses et filtrées)
Рle vecteur de la statistique, qui permet de connątre sa s̩lectivit̩
– optionnellement, le niveau de fragmentation des index
– le nombre d’utilisation des index
– la date de dernière mise à jour de chaque statistique scrutée par le script

Lire la suite

Rechercher les index inutiles

Si les index représentent l’optimisation la plus simple à mettre en place, on souhaite néanmoins conserver le minimum d’entre-eux, car leur maintenance lors de l’exécution de requêtes de modifications de données (INSERT, UPDATE, DELETE) peut être coûteuse, surtout sur des tables volumineuses.
Voyons comment collecter cette information …
Lire la suite

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

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

Vérifier l’unicité de tuples NULLables avec les index filtrés sous SQL Server 2008

Toute contrainte d’unicité entraîne la création implicite d’une index unique sur la table, dont la clé est constituée des colonnes spécifiées dans la contrainte d’unicité.

Or, lors de l’insertion d’une nouvelle ligne ou de la modification d’une des colonnes constituant la clé unique, SQL Server considère NULL comme une valeur.
Cela est faux puisque NULL n’est pas une valeur : c’est l’absence de valeur.

Avec SQL Server 2008 ont été introduits les index filtrés, qui permettent de spécifier les lignes candidates à l’indexation, par l’ajout d’une simple clause WHERE.
Dès lors, il est possible de contourner le problème posé par les contraintes d’unicité en se servant de ce type d’index …

Lire la suite