David Barbarin – Maintenance des statistiques avec SQL Server
Nicolas Souquet – Tout savoir sur le Query Store
Amar Adghar – Azure, quelle architecture pour moi ?
Arian Papillon and Julien Pierre – Les fausses bonnes idées SQL Server
Christophe Laporte – Configurer SQL Server pour un dépannage efficace
Hugo Kornelis – T-SQL User-Defined Functions, or: How to kill performance in one, easy step
Frédéric Brouard – Passer de SQL Server à PostGreSQL … ou l’inverse ?

Les vidéos sont disponibles ici.
Retrouvez également les scripts que j’ai utilisés pour les démos ici.

Bonne visualisation

Il y a bien d’autres éléments qui ont été ajoutés aux fonctionnalités de SQL Server avec ce nouvel opus, que l’on peut télécharger à partir de cette page. Plus bas dans celle-ci, on trouve également les téléchargements de SQL Server Management Studio 2017, SQL Server Data Tools, et les connecteurs pour faire interagir une application avec SQL Server en .NET, Java, mais aussi Python et Ruby.

Notons que depuis SQL Server 2014, l’édition Developer de SQL Server est gratuite, ce qui fait qu’on peut la télécharger sur nos PCs et commencer à bricoler après quelques minutes d’installation, en faisant appel à toutes les possibilités et fonctionnalités du moteur de base de données : l’édition Developer, est, en termes de fonctionnalités, équivalente à l’édition Enterprise, qui les offre toutes.

Voyons donc ce qu’il en est :

A partir de la page, on obtient un petit installeur de 5Mo, et lors de sont exécution, on obtient la fenêtre suivante :

Ici j’ai choisi Download Media, puisque c’est l’option qui me permettra d’installer au besoin, avec seulement les fonctionnalités que je souhaite. Nous obtenons alors l’écran suivant :

Plus besoin donc de se soucier du langage, et on peut télécharger selon son envie et l’OS, soit sous le format ISO, soit en CAB. Un lien nous permet aussi créer une instance SQL Server dans Azure.

Une fois le tout validé, le téléchargement débute … et se termine par :

Un clic sur le bouton Open folder nous amène directement sur le fichier ISO fraîchement téléchargé. A l’exécution de ce dernier, on obtient la fenêtre suivante :

A partir de la page Installation, on peut bien sûr démarrer l’installation d’une instance SQL Server 2017, et ici encore accéder aux pages qui permettent de télécharger la dernière version de SQL Server Management Studio (SSMS) et SQL Server Data Tools (SSDT). Depuis SQL Server 2016, ces outils ne sont en effet plus contenus dans l’installeur de SQL Server : ceci permet à l’installeur de garder une taille relativement raisonnable (1.4 Go), étant donné que l’installeur de SSMS pèse à lui seul près de 800 Mo.

Les différences avec l’installation de SQL Server 2016 sont peu nombreuses, mais valent qu’on s’y arrête : alors que SQL Server 2016 supportait l’apprentissage automatisé avec le langage R, on pouvait installer en plus de SQL Server une instance de R Server. Comme SQL Server 2017 supporte en plus Python pour servir ce même besoin, l’installation de R Server a été remplacée dans ce nouvel opus par un Machine Learning Server :

Les écrans de clé de produit et de licence demeurent inchangés :

Idem pour le calcul des règles d’installation :

Nous voici maintenant à la sélection des fonctionnalités à installer : comme vu précédemment, nous pouvons ajouter les fonctionnalités d’Apprentissage Automatisé, soit en support de script (Machine-Learning Services (In-Database)), soit en instance dédiée (Machine-Learning Services (Standalone)) et choisir d’installer seulement R ou Python. Cocher la case de l’une de ces deux fonctionnalités génère une nouvelle page dans la liste à gauche : Consent to install Microsoft R Server/Python

L’écran de nommage de l’instance reste inchangé :

De même que celui de configuration des services de l’instance :

L’octroi du droit Perform Volume Maintenance Task au compte de service qui exécute SQL Server, introduite avec SQL Server 2016, est toujours bienvenu, et sa description est limpide.

En ce qui concerne la configuration du moteur de base de données, pas de surprise non plus …

… mais on apprécie toujours l’onglet qui permet de configurer plusieurs fichiers pour TempDB, introduite avec SQL Server 2016 :

Comme nous l’avons vu, l’acceptation de la licence pour R Server et Python est requise :

Comme d’habitude, un résumé des éléments qui vont être installés s’affiche, permettant de revoir le tout avant de cliquer sur le bouton Install

Et bien sûr, on peut récupérer l’emplacement du fichier de configuration de cette installation juste en-dessous du résumé, pour le passer en paramètre à une installation scriptée et silencieuse de SQL Server. Il se trouve toujours dans le répertoire C:\Program Files\Microsoft SQL Server\140\Setup Bootstrap\Log\AAAAMMJJ_HHmmss\ConfigurationFile.ini.

L’installation démarre alors, et, si nous avions choisi d’installer les fonctionnalités de Machine-Learning, on observera le téléchargement des éléments nécessaires à celles-ci par l’utilisation de la bande passante réseau/Internet. Une fois terminée, on peut démarrer SQL Server Management Studio 17.2, et obtenir alors :

Il ne nous reste plus qu’à nous amuser avec les nouvelles fonctionnalités de cette version, listées sur cette page, et dont les plus marquantes à mon sens sont :

• Reprise de reconstruction d’index en ligne, ce qui permet de la mettre en pause pour la reprendre plus tard
• Exécution adaptative des requêtes : adaptation de l’algorithme de jointure et feedback sur l’octroi de mémoire à l’exécution d’une requête
• Tuning automatisé : détection et correction automatique de régression de performance pour un plan de requête, et création/suppression de doublons d’index dans Azure
• Ajout du type de données graphe
• Groupes de disponibilité AlwaysOn sans cluster
• Nouvelles DMVs : sys.dm_db_log_stats, sys.dm_tran_version_store_space_usage, sys.dm_db_log_info et sys.dm_db_stats_histogram
• Amélioration du support In-Memory : colonnes calculées, JSON, CASE et CROSS APPLY
• Fonctions de chaîne : CONCAT_WS et TRIM (enfin !)
• Et bien sûr le niveau de compatibilité de base de données 140

Pour voir les fonctionnalités devenues dépréciées, et notamment celles qui ne seront plus supportées dans la prochaine version de SQL Server (2018 ou 2019 ? les paris sont ouverts ! :)), c’est par ici.

Bon SQL Server 2017 à tous !

• A network-related or instance-specific error occurred while establishing a connection to SQL Server
• Login failed for user DOMAIN\user

Microsoft vient de publier un guide de résolution de ces erreurs, qui indique les sources du problème et les étapes de résolution.

Bonne connexion(s) !

Dès lors, comment retrouver les séquences référencées par de telles contraintes ? Voici un exemple et une petite requête pour nous y aider …

Pour l’exemple, supposons la séquence et la table suivantes :

Il est nécessaire d’utiliser la fonction de gestion dynamique sys.dm_sql_referencing_entities() pour retrouver les caractéristiques de la contrainte :

ce qui donne :

ElSüket.

SQL Sentry a annoncé hier que le fabuleux outil qui facilite grandement la lecture de plans de requête, SQL Sentry Plan Explorer, est maintenant gratuit dans son édition Pro.
Jusqu’ici, l’édition Express était déjà un bel outil, qui est maintenant complété par :

• L’ouverture de plusieurs documents de plan de requête (fichiers .sqlplan, .queryanalysis, .pesession)
• L’historique et ses commentaires au fur et à mesure du processus d’optimisation
• L’ouverture des graphes décrivant un deadlock (fichiers de type .xdl)
• La comparaison de l’impact des index pour une même requête
• L’aide à l’analyse de la distribution des valeurs dans un objet de statistique

Bonne analyse de plans !

Introduite avec SQL Server 2014, la vue de gestion dynamique sys.dm_exec_query_profiles nous permet de voir quel(s) nœud(s) d’un plan d’exécution réel consomme le plus de ressources et /ou de temps. C’est donc un formidable outil qui peut faire largement diminuer la recherche des points noueux d’une requête à l’étude.

La documentation de cette DMV montre qu’elle expose de nombreuses colonnes, qui nous renseignent de façon très précise sur la consommation de ressources physiques de chaque opérateur du plan de requête, notamment avec le nombre de millisecondes après lequel un opérateur s’est exécuté pour la première et la dernière fois. Pour simplifier l’analyse des requêtes, on peut s’en tenir à quelques unes d’entre-elles, comme dans la requête suivante :

La colonne node_id nous donne le numéro de l’opérateur dans le plan de requête. Il faut noter que l’opérateur racine de l’arbre de résolution qu’est le plan de requête, et qui se situe en haut et à gauche dans le plan d’exécution graphique, est le seul dans tout plan à ne pas porter de NodeID. L’opérateur qui le précède porte le NodeID 0, et celui qui précède ce dernier le NodeID 1, et ainsi de suite. Le plus grand numéro de NodeID est à l’opérateur qui est le plus à droite et en bas du plan d’exécution graphique.

La colonne session_id va nous permettre de spécifier sur quelle session porte notre étude : pour que cette vue expose des lignes, il est nécessaire que l’option de session SET STATISTICS XML soit positionnée à ON pour la requête à étudier. Ceci équivaut à l’activation de l’option d’inclusion du plan d’exécution réel dans la barre d’outil de SQL Server Management Studio (SSMS) avant l’exécution d’une requête. Ceci est normal, puisque comme pour toutes les tâches de monitoring, elle viennent avec un coût : celui-ci pourrait devenir trop élevé si toutes les requêtes étaient auditées à ce niveau de détail, d’autant que ce type d’information est utilisé par les DBAs, et pas par les applications qui interagissent avec la base de données.

Supposons que la requête (très simple) que l’on souhaite étudier est la suivante :

On peut récupérer le session_id de plusieurs manières :

• Il est indiqué dans la barre d’état de toute fenêtre de requête sous SSMS, en bas à droite;
• Si l’on a conservé les options par défaut de SSMS, il est aussi indiqué sur l’onglet de la fenêtre de requête;
• On peut exécuter SELECT @@SPID dans la même fenêtre de requête que celle à étudier.

Ne soyez pas perturbé par l’option de session SET STATISTICS IO, TIME ON positionné juste avant la requête : je l’utilise toujours pour diagnostiquer une requête, car cela expose le temps CPU, la durée totale, et surtout, le nombre d’IOs produit par la requête pour chaque table participant à celle-ci. On peut adjoindre l’option XML à la liste IO, TIME si on le souhaite.

Les lecteurs aux yeux affûtés auront remarqué que dans la capture d’écran ci-dessus, il y a un deuxième onglet ouvert : en effet, on doit utiliser une fenêtre de requête pour celle à étudier, et une autre pour lire la sortie de la vue sys.dm_exec_query_profiles pour cette session. Pour cet exemple, on peut reprendre la première requête, et rajouter la clause WHERE adéquate : la session qui va exécuter la requête à l’étude porte le session_id 51 :

L’exercice consiste donc à démarrer l’exécution de la requête à l’étude, puis à basculer vers la fenêtre de requête qui spécifie la vue sys.dm_exec_query_profiles avant la fin de l’exécution de la requête à l’étude. Pour la requête de cet exemple, cela nous donne :

On constate ainsi des écarts importants entre le nombre de lignes estimé et réel pour les opérateurs dont le NodeID est 0 et 4, mais il y a un problème : alors que la somme des valeurs de la colonne elapsed_time_ms nous donne 15, la sortie dans l’onglet Messages est la suivante (légèrement écourtée, notamment les IOs physiques et de LOBs, pour les besoins de l’article) :

(29382 row(s) affected)
Table ‘Workfile’. Scan count 0, logical reads 0
Table ‘Worktable’. Scan count 0, logical reads 0
Table ‘SalesOrderDetail’. Scan count 1, logical reads 1246
Table ‘Product’. Scan count 1, logical reads 15

SQL Server Execution Times:
CPU time = 156 ms, elapsed time = 1225 ms.

Il y a bien sûr le temps de consommation du jeu de lignes de résultat par SSMS. On peut le confirmer en éliminant le résultat une fois la requête exécutée : pour ce faire, il suffit de faire un clic-droit dans un zone vierge de la requête > Query options … > Results / Grid > et de cocher la case Discard results after execution.

La question qui vient maintenant est : comment faire pour les requêtes dont l’exécution est bien plus longue ? Et dans tous les cas, la durée d’exécution des requêtes n’étant pas précisément prédictible même après une ou deux exécutions, comment capturer les valeurs qu’expose cette DMV en s’approchant le plus possible de la fin de la requête ? On peut pour cela écrire une boucle qui va stocker le contenu de la DMV à intervalles réguliers et fréquents, et qui vérifie à chaque tour que la requête est toujours en cours d’exécution :

Ici on stocke le contenu de la DMV toutes les 10 ms. Le délai entre chaque boucle peut être adapté : si l’on sait que la requête dure environ quart d’heure, une récupération du contenu de la vue toutes les secondes est suffisante. Cette valeur peut donc être adaptée suivant la durée d’exécution globale de la requête. Il faut aussi veiller à exécuter ce lot de requêtes dans le même contexte de base de données que celui sous lequel on exécute la requête à étudier. En effet, cela permet d’obtenir le nom de l’objet de base de données accédé :

On constate dans la sortie du lot de requêtes interrogeant la DMV que, par exemple, l’opérateur de NodeID 4 est l’accès à l’index cluster de la table SalesOrderDetail, et qu’il a traité 121317 lignes. Voyons si cela est reflété par le plan d’exécution réel graphique de la requête :

Le numéro de NodeID 4 est bien l’opérateur exposé par la DMV, et si l’on lit la ligne de la bulle dont le libellé est Actual number of rows, on a bien 121317.

Pour l’étude des requêtes plus lourdes, la DMV sys.dm_exec_query_profiles nous permettra de repérer immédiatement les opérateurs les plus consommateurs de ressources, et donc de travailler directement sur ceux-ci en se reportant au plan de requête, puis à la requête elle-même pour en revoir l’écriture et éventuellement l’indexation.

Bonne optimisation !

Mais souvent, cela ne suffit pas. Voyons comment contourner ce petit problème :

Pour les besoins de la démonstration, créons une petite table, avec une pile d’exécution. C’est ce que l’on trouve parfois dans les bases de données lorsque celles-ci sont dédiées à une seule application et écrit les erreurs rencontrées directement dans une table :

Consultons maintenant la longueur de cette chaîne :

Nous obtenons 111640. Si nous exécutons maintenant :

Puis que l’on réalise un copier-coller de la valeur dans une nouvelle fenêtre de requête, nous allons voir que nous n’obtenons pas l’intégralité du texte :

On a remarqué cependant que les documents XML, notamment les plans de requête, sont récupérables dans leur intégralité, alors que ce sont généralement des documents sont relativement longs. Tentons donc :

Ceci se termine directement avec l’erreur suivante affichée dans la console :

Msg 9400, Level 16, State 1, Line 526
XML parsing: line 513, character 33, unexpected end of input

Si l’on en vient cependant à utiliser le marqueur de section texte CDATA, qui échappe l’interprétation XML du document considéré, on obtient :

En cliquant sur le lien proposé, un nouvel onglet s’ouvre, dans lequel l’intégralité du texte est exposée :

Bonne consultation de logs !

@++

Voici donc une requête qui permet de mesurer la fragmentation des index fulltext, et qui génère l’instruction de maintenance adéquate, le cas échéant :

Bonne maintenance d’index fulltext !

Bonne indexation fulltext !

Nous démarrons donc en ajoutant une Tâche de Flux de Données dans le Contrôle de Flux par simple glisser-déposer (je débute avec SSDT / SSIS !) :

Dans le panneau Flux de Données, nous ajoutons maintenant une source de données ADO.NET de la même façon, puis double-cliquons dessus pour la configurer.
Il nous faut tout d’abord créer une connexion à la base de données AdventureWorksDW2012. Pour cela, nous cliquons sur Nouveau …

Comme nous n’avons pas encore de connexion, nous cliquons une nouvelle fois sur le bouton Nouveau dans la fenêtre « Configurer un Gestionnaire de Connexion ADO.NET », et nous obtenons la fenêtre suivante :

Nous validons alors le tout, et nous retrouvons dans l’éditeur de Source ADO.NET, ou nous pouvons choisir de traiter les données extraites directement d’une table ou d’une vue, ou bien de spécifier une requête. Nous choisissons cette dernière option :

Voici donc la requête, que nous collons dans l’éditeur de Source ADO.NET, et son résultat sous SQL Server Management Studio :

Notre but des donc d’obtenir une jeu de données avec les colonnes suivantes :

– 4 lignes, dont la colonne contiendra des valeurs uniques suivantes (Components, Bikes, Clothing et Accessories)
– 5 colonnes, dont 4 pour les années 2005 à 2008, et une pour le volume de vente (SalesAmount)

Nous obtenons l’interface suivante, qui nous permet de spécifier les caractéristiques de l’opération de pivot :

Nous validons par le bouton OK, puis passons sous l’éditeur avancé :

En basculant sous l’onglet Propriétés d’entrée / sortie, on s’aperçoit qu’il va manquer des colonnes. En effet, les colonnes des années ne sont pas dans la sortie du pivot :

Notons ici la valeur LineageID, qui nous permettra d’indiquer par la suite la colonne de la source de données pour la sortie du pivot. Dans cet exemple, c’est 22. Nous ajoutons donc 4 colonnes, 2005, 2006, 2007 et 2008, avec le modèle suivant :

Nous obtenons donc :

Comme nous ne souhaitons pas stocker les données en sortie, mais seulement voir ce que le moteur fait, nous pouvons ajouter comme destination un compteur de lignes :

Comme le libellé de l’erreur l’indique, nous devons créer une variable pour stocker le nombre de lignes retournés en sortie de l’opérateur pivot. Pour ce faire, il suffit d’utiliser la fenêtre des variables (Affichage > Autres fenêtres > Variables) du paquetage, que nous appelons rowCount.

Une fois fait, il nous suffit de double-cliquer sur la destination pour pouvoir spécifier la variable :

Après avoir validé par OK, nous pouvons activer la visionneuse de données sur les deux pipelines, par un simple clic-droit sur chacun d’entre-eux- Ceci nous permettra de visualiser la transformation :

Voici ce qui se passe à l’exécution du paquetage :

La visionneuse de gauche nous montre les données avant le pivot, et celle de droite après. On voit bien que la transformation est plus proche d’une matrice que d’un pivot. Ceci est dû au fait que l’on n’a pas ordonné les données suivant le libellé de la catégorie : dès lors, le groupement des lignes suivant ce critère n’est pas fait. Nous cliquons sur le bouton Lecture, et comme le tampon ne contient que quelques lignes, l’exécution du paquetage continue et se termine presque immédiatement, sans erreur.

Comme bien souvent dans l’environnement SQL Server, on dispose de plusieurs possibilités pour remédier à ceci : soit ajouter une clause ORDER BY PC.EnglishProductCategoryName à la requête, soit ajouter un opérateur de tri dans SSIS. C’est cette dernière option que nous choisissons, puisqu’en SQL, il n’y a normalement pas d’ordre.

Nous intercalons donc un opérateur de tri :

Et nous le configurons pour que le tri se fasse suivant la colonne EnglishProductCategoryName; par défaut le tri est ascendant :

Nous ré-exécutons le paquetage, dont il ne nous reste plus que la visionneuse de données en sortie du pivot. Nous obtenons alors le résultat escompté :

Bons pivots de données avec SSDT !

ElSüket.

Ce script donne :

– le nom de la table
– le nom de l’index actuel
– la liste des colonnes clé de l’index
– le script T-SQL de normalisation du nom de la contrainte d’unicité et de suppression de l’index actuel.

Bonne gestion des index !

– 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 connaî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

Bonne étude de table !

=> REORGANIZE ne fait que ré-arranger le niveau feuille de l’index, et n’alloue ou ne désalloue aucune page.
En revanche, REBUILD reconstruit tous les niveaux de l’index, et se sert au besoin de nouvelles pages, de façon à réduire la fragmentation interne et externe de l’index. REORGANIZE ne fait que réduire la fragmentation logique de l’index, de sorte à minimiser, si ce n’est éviter, les aller-retours dans les pages de l’index lors de la lecture de celui-ci.

=> REBUILD est exécutée hors-ligne par défaut.
Dans ce cas, on ne peut pas mettre à jour la table sous-jacente s’il s’agit de son index cluster, et on ne peut pas changer les colonnes qui participent à la définition d’un index non-cluster tant que l’instruction ALTER INDEX … REBUILD est en cours d’exécution.

REORGANIZE ne maintient pas ces verrous, et permet donc de continuer à effectuer des mises à jour sur la table cible de l’instruction, qui est toujours effectuée en ligne.

C’est donc pour cela que l’on doit utiliser :

=> REORGANIZE lorsque la fragmentation de l’index est faible (entre 5-10% et 25-30%)
=> REBUILD lorsque la fragmentation de l’index est plus élevée (plus de 25-30%).

Si l’on exécute une instruction ALTER INDEX … REBUILD en ligne avec l’option ONLINE, qui n’est disponible que dans les instances de SQL Server dont l’édition est Enterprise, deux index sont maintenus : l’ancien est supprimé et remplacé par le nouveau à la fin de l’opération. Cela permet l’accès en écriture sur la table, même si l’opération est plus longue et plus coûteuse. Mais cela est nécessaire lorsqu’on a une base de données dont la disponibilité doit être 24 x 7 x 366.

On notera qu’on ne peut pas reconstruire un index en ligne si :

– l’index est cluster et la table a au moins une colonne de type LOB (image, text, ntext varchar(max), nvarchar(max), varbinary(max)), spatial (geography et geometry) ou hierarchy, ou encore une colonne calculée,

– l’index est non-cluster, et porte sur des colonnes de type LOB, spatial ou hierarchy, ou que l’une des colonnes clé de l’index porte sur une colonne calculée.

Bonne maintenance des index !

ElSüket

– la liste de ses colonnes clé
– la liste de ses colonnes incluses
– la définition de son filtre
– le script de création de cet index

Voici une première requête qui retourne la définition de tous les index d’une base de données.
On peut bien sûr ajouter des filtres afin de voir la définition des index sur une table, ou la définition d’un index en particulier.

Et une autre donnant le script de définition de l’index :

On exclut les indexes sous-jacents à une clé primaire, puisque leur suppression obligerait celle de la contrainte.

Si l’on souhaite extraire la clé de l’index, il faudra alors créer la petite fonction suivante :

Que l’on peut utiliser directement comme suit :

Il ne reste alors plus qu’à juger de la pertinence de la suppression de l’index, car leur création est assez coûteuse.
En effet, si on supprime un index et qu’on se rend compte qu’il aurait pu servir des requêtes :

– dans le cas où on dispose d’une édition Standard de SQL Server, on doit recréer l’index et cela bloque la table
– dans le cas où on dispose d’une édition Enterprise de SQL Server, on peut recréer l’index en ligne, mais cela utilise massivement la base de données système TempDB dans laquelle est effectuée le tri, plus l’espace disque nécessaire à la copie de l’index, et enfin le coût de maintenance de deux index au lieu d’un.

Bonne indexation !

Bonne indexation !

ElSuket

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

Voici le code :

Et deux exemples d’utilisation :

=> EXEC ps_get_index_stats

Collecte les statistiques de tous les index de la base de données

=> EXEC ps_get_index_stats 'maTable'

Collecte les statistiques de tous les index de la table maTable

Vous pouvez bien sûr modifier son code pour pouvoir filtrer par base de données, par index et par partition.

Attention en revanche, car si l’on passe des paramètres incorrects (valeurs négatives ou pas de valeur (NULL)) aux fonctions DB_ID() et OBJECT_ID(), cela a pour effet de collecter toutes les statistiques avec comme granularité la plus élevée.

On peut utiliser ce script pour décider de la reconstruction ou de la réorganisation d’un index …

Bonne indexation

ElSüket

ElSuket

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 ?

Si nous tentons de créer la table suivante :

Nous obtenons l’erreur :

Msg 1919, Niveau 16, État 1, Ligne 1
La colonne ‘geoPositionVille’ dans la table ‘TbCoordonneeVille’ n’est pas d’un type valide lui permettant d’être utilisée en tant que colonne clé dans un index.
Msg 1750, Niveau 16, État 0, Ligne 1
Impossible de créer la contrainte. Voir les erreurs précédentes.

Nous sommes donc contraints de créer la table sans la contrainte d’unicité sur la colonne geoPositionVille :

Comment faire pour garantir l’unicité des positions des villes sans perdre les avantages offerts par le type GEOGRAPHY ?
Il est possible de créer une contrainte d’unicité sur des colonnes calculées persistantes.

Ajoutons donc deux colonnes calculées, une pour la latitude, et une autre pour la longitude.
Attention, la casse sur les méthodes CLR est importante.

Il nous suffit ensuite de créer une contrainte d’unicité sur ces deux colonnes :

Essayons maintenant d’insérer deux villes dont le nom est différent, mais dont les coordonnées sont identiques :

La première instruction se passe sans problèmes.
En revanche la seconde échoue, et nous obtenons l’erreur suivante :

Msg 2627, Niveau 14, État 1, Ligne 1
Violation de la contrainte UNIQUE KEY ‘UQ_TbCoordonneeVille_latitudeVille_longitudeVille’. Impossible d’insérer une clé en double dans l’objet ‘dbo.TbCoordonneeVille’.
L’instruction a été arrêtée.

Vérifions le contenu de la table :

Une solution alternative est de créer une vue indexée, ce qui présentera un bon avantage si la table est souvent lue.
Supprimons la table puis recréons-la :

Créons ensuite la vue :

Puis indexons-la :

Et tentons les mêmes insertions que celles que nous avons faites pour tester la contrainte d’unicité sur les colonnes calculées persistantes :

Là encore, la première instruction se passe sans problème, mais la seconde échoue, provoquant l’erreur suivante :

Msg 2601, Niveau 14, État 1, Ligne 1
Impossible d’insérer une ligne de clé en double dans l’objet ‘dbo.VwCoordonneeVille’ avec un index unique ‘IXUQC_VwCoordonneeVille_latitudeVille_longitudeVille’.
L’instruction a été arrêtée.

Interrogeons néanmoins la vue :

ElSuket

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 …

Supposons que nous avons plusieurs applications qui doivent se connecter à notre base de données, et que l’authentification des utilisateurs est gérée dans cette base de données à l’aide de la table suivante :

Il est nécessaire que l’identifiant qui permet à nos utilisateurs de se connecter soit unique.
Notre application donne le droit aux administrateurs d’enregistrer les nouveaux salariés.
Lors de la première connexion de ceux-ci, il doivent spécifier un identifiant et un mot de passe que les administrateurs ne peuvent pas choisir à leur place, et il a été décidé que ces deux valeurs seront laissées à NULL jusqu’à la première connexion de l’utilisateur.

Le contenu de la table pourrait dont être le suivant :

Essayons maintenant d’enregistrer un nouvel utilisateur :

Cela provoque l’erreur suivante :

Msg 2627, Niveau 14, État 1, Ligne 1
Violation de la contrainte UNIQUE KEY ‘UQ_TbUtilisateur_identifiantUtilisateur’. Impossible d’insérer une clé en double dans l’objet ‘dbo.TbUtilisateur’.
L’instruction a été arrêtée.

Remplaçons donc la contrainte d’unicité par un index filtré :

Tentons de nouveau l’insertion de ce nouvel utilisateur :

Pour vérifier, tentons d’insérer un nouvel utilisateur avec le même identifiant de connexion que M. Brouard :

Cela provoque l’erreur suivante :

Msg 2601, Niveau 14, État 1, Ligne 1
Impossible d’insérer une ligne de clé en double dans l’objet ‘dbo.TbUtilisateur’ avec un index unique ‘IUXQ_TbUtilisateur_F_identifiantUtilisateur’.
L’instruction a été arrêtée.

L’unicité des identifiants de connexion est donc bien vérifiée, et laisse la place aux nouveaux entrants

ElSuket

Quand on parle de fragmentation logique de l’index, on parle aussi de fragmentation interne : c’est le cas lorsque la quantité de données stockée dans les pages de l’index est plus petite que la quantité maximale de données que peut stocker une page.

ElSuket

Considérons le DDL des tables suivantes :

Manifestement il manque toutes les contraintes :

– de valuation obligatoire (NOT NULL),
– de clé primaire,
– de clé étrangère,
– d’unicité,
– de valeur par défaut
– de domaine (CHECK)

Le squelette d’ajout de contraintes est le suivant :

=> contraintes de valuation obligatoire

=> contraintes de clé primaire

=> contraintes de clé étrangère

=> contraintes d’unicité

=> contraintes de valeur par défaut :

=> contraintes de domaine (CHECK)
ALTER TABLE maTable
ADD CONSTRAINT CHK_maTable_maColonne
CHECK(maColonne [formuleDeVerification]

Définissons les dans cet ordre :

=> Contraintes de valuation obligatoire

Une clé primaire ne pouvant logiquement pas être NULL, nous devons définir toute les colonnes qui vont servir de clé primaire aux tables comme ne pouvant pas être NULL.
Nous devons également obliger la valuation des colonnes qui sont des clés naturelles, et celles qui seront clé étrangère :

=> Contraintes de clé primaire

=> Contraintes de clé étrangère

=> Contraintes d’unicité

Elles permettent de s’assurer qu’aucune valeur ne sera pas insérée en double dans des colonnes qui ne constituent pas la clé primaire.
Bien qu’une clé primaire permette également d’assurer l’unicité, on ne peut bien sûr en définir qu’une seule par table, pour qu’il soit possible de la référencer par des clés étrangères dans d’autres tables.
Au contraire, on peut définir plusieurs contraintes d’unicité par table.

Similairement, des indexes sont créés implicitement lors de la création d’une clé primaire ou d’une contrainte d’unicité.
Mais seul l’index de clé primaire est toujours cluster : l’index sous-jacent à une contrainte d’unicité est cluster si la table n’a pas de clé primaire définie, et non-cluster à l’inverse.
Comme pour une clé primaire, il est nécessaire de mettre la colonne qui a la sélectivité la plus élevée en premier dans la définition de la contrainte d’unicité, car cet ordre sert dans la définition de l’index.
Comme les recherches à travers les indexes se font suivant la valeur de la première clé, l’index sera d’autant plus efficace que la valeur de sa première clé sera sélective.

=> Contraintes de valeur par défaut :

Il peut être intéressant de définir une valeur par défaut pour l’insertion (mais pas à l’UPDATE) d’une nouvelle ligne à une table si la colonne est omise dans la spécification de l’instruction INSERT :

Ainsi si nous écrivons :

la colonne dateAbonnementClient sera valuée à la date actuelle du système.

=> Contraintes de domaine

Elles permettent de limiter ou de vérifier les valeurs que peuvent contenir une colonne.
Elles nécessitent une formule de vérification, qui peut être spécifiée directement lors de la définition de la contrainte, ou bien à travers une fonction définie par l’utilisateur.
L’utilisation d’une fonction pour la définition d’une contrainte de domaine permet bien souvent de ne pas avoir recours à un déclencheur pour vérifier la validité des données.

Ici, nous souhaitons vérifier que les numéros de téléphone que nous stockons dans la base de données contiennent le préfixe du pays du client, et que la longueur des numéros de téléphone est correcte.
Pour cela nous créons la fonction suivante :

La contrainte de domaine sera alors définie comme suit :

Nous souhaitons également vérifier que les valeurs de la colonne referenceAbonnement de la table TbAbonnement aient le format XXX-nnn-nn.
Là nous pouvons définir celui-ci directement dans la spécification de la contrainte :

ElSuket

En choisissant l’option « Propriétés » par clic-droit sur la node « SQL Server Agent » sous SQL Server Management Studio, voici ce que l’on trouve :

Autre désagrément : l’historique concernant un job est assez long, par exemple si vous exécutez un job une fois par semaine depuis des mois.
Vous souhaitez maintenant purger l’historique, pour voir ce qui se passera la semaine prochaine, d’un coup d’oeil :

Vous pouvez également supprimer de l’historique les lignes qui sont plus vieilles qu’une date de votre choix, avec l’option « Supprimer l’historique avant » :

SQL Server has encountered n occurrence(s) of cachestore flush for the (partie du cache de plans) cachestore due to some database maintenance or reconfigure operations »

Ce message n’apparaît qu’à partir du SP2 de SQL Server 2005, et il est écrit par intervalles de 5 minutes.
La purge du cache de plans peut se produire dans les cas suivants :

Avec l’instruction ALTER DATABASE :

- Lors du détachement d'une base de données,
- ALTER DATABASE maBD SET AUTO_CLOSE ON,
- ALTER DATABASE maBD COLLATE nouvelleCollation,
- ALTER DATABASE maBD SET READ_ONLY,
- ALTER DATABASE maBD SET READ_WRITE,
- ALTER DATABASE maBD SET ONLINE,
- ALTER DATABASE maBD SET OFFLINE,
- ALTER DATABASE maBD MODIFY NAME = maNouvelleBD,
- ALTER DATABASE maBD MODIFY FILEGROUP GroupeDeFichiers DEFAULT,
- ALTER DATABASE maBD MODIFY FILEGROUP GroupeDeFichiers READ_WRITE,
- ALTER DATABASE maBD MODIFY FILEGROUP GroupeDeFichiers READ_ONLY,
- DROP DATABASE nomDeBDCaptureeParSnapshot.

Ou bien lorsqu’une des options d’instance suivante est modifiée à l’aide de sp_configure avec RECONFIGURE :

- cross db ownership chaining,
- index create memory (KB),
- remote query timeout (s),
- user options,
- max text repl size (B),
- cost threshold for parallelism,
- max degree of parallelism,
- min memory per query (KB),
- query wait (s),
- min server memory (MB),
- max server memory (MB),
- query governor cost limit

ou encore avec l’une de ces commandes DBCC :

- DBCC CHECKDB
- DBCC FREEPROCCACHE,
- DBCC FREESYSTEMCACHE.

Et enfin lors du succès de la reconstruction d’un fichier de journal des transactions.

ElSuket

	1. Présentation

Le moteur de base de données comprend, en outre, un optimiseur de requêtes : c’est un des modules pilier d’un SGBD.
Celui-ci est chargé de trouver le meilleur moyen d’exécuter une requête en un minimum de temps et en consommant un minimum de ressources.
Il génère pour cela, à l’enregistrement d’une nouvelle procédure stockée par exemple, un plan de requête qu’il conserve dans
le cache de procédures. Ce plan de requête est généré en fonction des statistiques de colonnes.
Au fur et à mesure que la base de données vit, que les requêtes évoluent, il est possible que les indexes posés il y a quelques temps ne soient plus optimaux.
Dans un tel cas, le moteur de base de données génère un « mauvais » plan de requête.
Cette nouvelle fonctionnalité introduite par SQL Server permet de conserver ces « mauvaises » informations pour nous
faciliter la complexe tâche du paramétrage de base de données.
Il nous reste donc à décider de les implémenter ou non.

	2. Vues de gestion dynamiques impliquées dans la recherche d’indexes manquants

SQL Server 2005 met à notre disposition quatre vues de gestion dynamique.
Nous utiliserons trois de ces vues pour nous aider à la recherche d’indexes manquants :

	- sys.dm_db_missing_index_group_stats:

	Cette vue nous renseignera sur le gain de performances que l’on pourrait obtenir si nous implémentions l’index conseillé.
	Les colonnes qui nous intéressent sont :

		• user_seeks : Nombre de recherches pour lesquelles des requêtes auraient pu tirer profit de l’index 	recommandé.

		• user_scans : Nombre d’analyses d’index pour lesquelles des requêtes auraient pu tirer profit de l’index recommandé.

		• unique_compiles : Nombre de (re)compilations qui auraient pu tirer profit de l’index recommandé. Une recompilation est très coûteuse.

		• avg_total_user_cost : C’est ce que coûte, en moyenne, au moteur de base de données, d’exécuter une requête sans l’index recommandé.

		• avg_user_impact : C’est le gain, en pourcentage, que le moteur de base de données estime pouvoir gagner sur le coût de la requête
		(avg_total_user_cost).

		• last_user_seek : de type DATETIME, elle renseigne sur la date de la dernière occurrence de recherche qui aurait pu profiter
		de l’index conseillé.

		• last_user_scan : même commentaire que pour last_user_seek, excepté qu’il s’agit de la dernière recherche.

	- sys.dm_db_missing_index_groups: 

	Cette vue nous servira à faire le lien entre la vue précédente, qui nous renseigne sur les gains de performance possibles,
	et la vue suivante, qui va nous permettre de créer la commande CREATE INDEX …

	- sys.dm_db_missing_index_details: 

	Cette vue nous éclairera sur les colonnes des tables à indexer. Les colonnes qui nous intéressent sont :

		• equality_columns : liste des colonnes qui constituent un prédicat d’égalité
		 dans l’expression de la requête (WHERE maColonne = maValeur, JOIN maTableB ON maTableA.IDA = maTableB.IDB).

		• inequality_columns : liste des colonnes qui constituent un prédicat d’inégalité
		 (WHERE maColonne < maValeur, JOIN maTableB ON maTableA.IDA > maTableB.IDB).

		• included_columns : liste de colonnes qui permettront de couvrir la requête.

		• statement : nom qualifié de la table sur laquelle l’index doit être posé.

La quatrième vue de gestion dynamique est sys.dm_db_missing_index_columns.
Elle permet d’associer les colonnes de l’index conseillé par sys.dm_db_missing_index_groups et de montrer « en colonne » dans quelle clause de la commande de création des indexes la colonne en question doit se trouver.
C’est ce que propose sys.dm_db_missing_index_details par une liste de colonnes de table, séparées par des virgules.

	3. Une première approche

Relions donc toutes ces informations avec les jointures appropriées :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
------------------------------ 

- Nicolas SOUQUET - 08/09/2008 

------------------------------ 

 

  SELECT MIGS.unique_compiles Comp, 

      MIGS.user_seeks, 

      MIGS.user_scans, 

      MIGS.avg_total_user_cost, 

      MIGS.avg_user_impact, 

      MIGS.last_user_seek, 

      MIGS.last_user_scan, 

      REPLACE(REPLACE(MID.Statement, '[', ''), ']', '') 'Database.Schema.Table', 

      REPLACE(REPLACE(MID.equality_columns, '[', ''), ']', '') Egalite, 

      REPLACE(REPLACE(MID.inequality_columns, '[', ''), ']', '') Inegalite, 

      REPLACE(REPLACE(MID.included_columns, '[', ''), ']', '') Incluse 

  FROM sys.dm_db_missing_index_group_stats MIGS 

  JOIN sys.dm_db_missing_index_groups MIG ON MIGS.GROUP_HANDLE = MIG.index_group_handle 

  JOIN sys.dm_db_missing_index_details MID ON MIG.INDEX_HANDLE = MID.index_handle 

  WHERE DB_NAME(MID.database_id) NOT IN ('master', 'msdb', 'model', 'ReportServer', 'ReportServerTempDB', 'Distribution', 'TempDB')

Nous avons maintenant toutes les informations pour créer les indexes qui manquent à notre base de données. Mais dans cette foule d’informations, lesquels sont vraiment nécessaires ?
J’ai le souvenir que cette requête m’ait parfois retourné plus de 300 lignes …
Pour trouver dans un premier temps les indexes les plus nécessaires à une base de données pauvrement indexée, il faudrait associer le coût de chaque requête au nombre de recherches et d’analyses d’indexes,
et de (re)compilations de plans de requête, et tenir compte de la « fraîcheur » des données retournées par ces vues de gestion dynamique.

Soit donc la requête suivante :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
------------------------------ 

- Nicolas SOUQUET - 08/09/2008 

------------------------------ 

 

  SELECT ROUND((MIGS.user_seeks + MIGS.user_scans + MIGS.unique_compiles) * MIGS.avg_total_user_cost * MIGS.avg_user_impact, 0) Avantage, 

      MIGS.last_user_seek, 

      MIGS.last_user_scan, 

      REPLACE(REPLACE(MID.Statement, '[', ''), ']', '') 'Database.Schema.Table', 

      REPLACE(REPLACE(MID.equality_columns, '[', ''), ']', '') Egalite, 

      REPLACE(REPLACE(MID.inequality_columns, '[', ''), ']', '') Inegalite, 

      REPLACE(REPLACE(MID.included_columns, '[', ''), ']', '') Incluse 

  FROM sys.dm_db_missing_index_group_stats MIGS 

  JOIN sys.dm_db_missing_index_groups MIG ON MIGS.GROUP_HANDLE = MIG.index_group_handle 

  JOIN sys.dm_db_missing_index_details MID ON MIG.INDEX_HANDLE = MID.index_handle 

  WHERE CONVERT(CHAR(10), MIGS.LAST_USER_SEEK, 103) = CONVERT(CHAR(10), GETDATE(), 103) 

  AND DB_NAME(MID.database_id) NOT IN ('master', 'msdb', 'model', 'ReportServer', 'ReportServerTempDB', 'Distribution', 'TempDB') 

  ORDER BY Avantage DESC

Maintenant, nous avons les indexes manquants qui ont coûté le plus cher à notre serveur, et qui auraient même été nécessaires aujourd’hui.
Si l’on ré-exécute cette requête quelques secondes après l’avoir exécutée une première fois sur une base de données OLTP,
ou sur un serveur OLAP très utilisé, et que l’on constate que les premières lignes (c’est-à-dire celles qui nous renseignent
sur les indexes les plus nécessaires) ont un «avantage » bien supérieur à celui de la première exécution, c’est très
certainement que si votre serveur était doué de parole, il vous remercierait de l’avoir créé.
Mais alors, comment créer ces indexes ?

	4.Création des indexes nécessaires

Vous aurez certainement dénoté la simplicité avec laquelle SQL Server 2005 nous expose les indexes qu’il serait nécessaire de créer. Prenons la syntaxe de la commande CREATE INDEX, sans ses options :

En supposant que nous avons au moins l’index de clé primaire, cluster, sur les tables montrées par les premières lignes de la requête précédente, nous créerons simplement notre commande en remplaçant :

– column par les colonnes de table listées dans les colonnes Egalite et Inegalite de la précédente requête,
– column_name dans la clause INCLUDE par les colonnes de table listées dans la colonne Incluse de la précédente requête

Il y a une dernière petite subtilité : nous devons placer les colonnes d’égalité avant celles d’inégalité dans la clause ON, mais également veiller à ordonner les colonnes d’égalité dans l’ordre décroissant de leur sélectivité.

En effet, l’optimiseur de requête de SQL Server 2005 (et d’autres SGBD) est basé sur les coûts, c’est-à-dire la quantité de ressources qui vont être nécessaires à l’exécution d’une requête.
Il se base sur la sélectivité des colonnes, c’est-à-dire le nombre de valeurs différentes que contiennent chacune des colonnes de nos tables, pour estimer ce coût.
Ces statistiques sont conservées soit au niveau colonne (node « Statistiques » des tables dans SQL Server Management Studio), soit dans les indexes.
Par opposition à une colonne de type BIT qui est très peu sélective, une colonne auto-incrémentée est très sélective.

Pour rechercher les données qui sont la réponse à notre requête, l’optimiseur de requêtes va commencer par rechercher nos
critères (clause WHERE de la commande SELECT, par exemple) dans les colonnes ayant la sélectivité la plus élevée, de sorte
qu’il aura ensuite un jeu de données le plus petit possible pour vérifier les autres contraintes de la requête.
Nous veillerons donc à vérifier l’ordre dans lequel nous allons ordonner nos colonnes d’ « égalité » : les vues de gestion dynamique les retournent souvent dans le bon ordre, mais une requête :

SELECT COUNT(DISTINCT maColonne) FROM maTable

nous ôtera les doutes.

Comme le moteur de bases de données ne peut pas maintenir des statistiques sur des données qui ne sont pas
contenues dans les colonnes, il découle que les colonnes d’inégalité révélées par notre dernière requête devront se
trouver à la suite des colonnes répertoriées comme colonnes d’ « égalité ».

Qu’en est-il des colonnes répertoriées « Incluse » ? Ces colonnes, qui sont répertoriées dans le SELECT de nos requêtes,
à l’exception des colonnes participant à un calcul agrégé (SUM, MIN, MAX, …) permettent de couvrir nos requêtes en évitant
les bookmarks lookups, eux-aussi très coûteux.
Les colonnes incluses sont également une nouvelle fonctionnalité introduite avec SQL Server 2005.

Finalement, la trame de notre requête d’index sera :

	5.Limitations de la fonctionnalité d’indexes manquants

Cette fonctionnalité a cependant quelques revers : 

	- Comme nous l’avons vu, elle retourne une liste de colonnes mais ne précise pas dans quel ordre elles doivent constituer la clé de l’index,

	- Elle ne constitue pas une aide à la configuration d’un index (options FILLFACTOR et PAD_INDEX),

	- Dans certains cas, elle ne renseigne que sur les colonnes incluses. Il faudra donc chercher quelle(s) est la
	 requête à l’origine  de ce groupe d’index manquant, puis optimiser la requête en conséquence

	- Elle ne renseigne pas sur la « fraîcheur » des données : la requête que je vous propose peut tout à fait montrer un
	 « avantage » énorme, qui a été généré par une requête que nous avons modifiée il y a quelques jours. 

	En effet, ces informations sont purgées :
		• Lors du redémarrage du serveur ou du service SQL Server,
		• Lors de la création d’un index sur une table pour laquelle la fonctionnalité nous conseille la création de plusieurs indexes.

	6.Conclusion

Comme nous venons de le voir, cette fonctionnalité permet d’indexer très rapidement une base de données qui ne l’est que très pauvrement, mais elle permet aussi de suivre la vie de la base de données.

Même si cette fonctionnalité ne constitue pas un outil précis de paramétrage de base de données (en existe-t-il ?), elle nous aidera à vérifier, en plus des options d’instruction (SET STATISTICS)
et du plan de requête (accessible par CTRL+L sous SQL Server Management Studio) si, lorsque l’on doit optimiser une requête, on doit se tourner vers la création d’un index approprié,
ou bien vers une autre expression de la même requête (parfois ce sera les deux)

ElSuket