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 !

Qu’est-ce que l’estimation de cardinalités ? Pour faire très court, c’est l’ensemble des règles mathématiques qui permettent à SQL Server d’avoir une idée assez précise du nombre de lignes qu’il aura à traiter lors de l’exécution d’une requête. C’est avec ce calcul-là qu’il sélectionne les algorithmes de jointure, de regroupement, l’ordre et la façon d’accéder aux tables, et bien d’autres choses encore. Bien sûr, ces choix varient suivant le volume de données à traiter. On le comprend donc, c’est un sujet très important, puisqu’il impacte directement les performances de l’exécution de nos chères (parfois en IO et temps CPU !) requêtes.

Alors vous allez me dire, crevant d’impatience : « bon d’accord, mais il le sort de son chapeau magique ce calcul ? » : au risque de vous décevoir, non. Dès lors qu’on soumet une requête qui filtre une table par une colonne, ou l’utilise dans une jointure, un regroupement, alors par défaut, le moteur crée automatiquement des objets de statistique. C’est à dire qu’il va échantillonner les données des colonnes des tables participant à la requête pour évaluer la distribution des données dans les colonnes (et index) de ces tables. Fort de ces informations, il peut alors réaliser le fameux calcul. Bref, ce sont des mathématiques

L’auteur du billet en question partageait sur le fait que par défaut, SQL Server estime qu’il n’y a qu’une seule ligne dans une variable de type TABLE. Ceci s’explique par le fait que SQL Server ne maintient pas d’objet de statistique sur les variables de type TABLE (pour les curieux, il le fait néanmoins sur les tables temporaires). Quand on sait l’usage qui est fait des variables de type TABLE dans les applications, il est évident qu’il arrive rarement que ces tables ne soient en charge que d’une seule ligne; de là des performances qui ne sont pas toujours en adéquation avec le volume de données à traiter.

Voyons le comportement par défaut du moteur à l’aide de la base de données AdventureWorks2012 :

L’option de session SET STATISTICS nous permet de collecter des métriques IO, temps CPU et durée en millisecondes de la requête. Son option XML expose le plan réel de requête en plus du résultat de la requête. La sortie de ce lot est, tronquée des lectures « physiques » (i.e. sur disque et pas en RAM), et des lectures LOB, puisqu’il n’y en a pas :

Table ‘Person’. Scan count 0, logical reads 59916
Table ‘#BEF1AB90′. Scan count 1, logical reads 33

SQL Server Execution Times:
CPU time = 47 ms, elapsed time = 56 ms.

Si l’on étudie le plan de requête, voici ce que l’on trouve pour notre variable de type TABLE :

Pour voir sur quelle base le moteur a réalisé ses calculs, il suffit de survoler l’opérateur Table Scan avec le curseur de la souris :

Le moteur a donc estimé qu’il n’y qu’une seule ligne dans la variable de type TABLE, puis il a exécuté le plan de cette requête. D’une certaine manière, il nous avoue s’être un peu trompé, puisqu’il nous indique qu’en réalité, il a lu 19972 lignes.

Mais, à la lecture du résumé l’article 2952444, on voit que ce comportement a été corrigé à l’aide d’un correctif dès SQL Server 2012 SP2 et le CU3 de SQL Server 2014, ce qui fait qu’il est dans les RTM des versions suivantes de SQL Server, à ce jour SQL Server 2016 et 2017 (bientôt !) :

When you populate a table variable with many rows and then join it with other tables, the query optimizer may choose an inefficient query plan, which may lead to slow query performance.

Voyons donc ce qu’il en est : nous rejouons le même lot de requête, mais avec le drapeau de trace activé cette fois :

La sortie est :

Table ‘Workfile’. Scan count 7, logical reads 64, physical reads 0, read-ahead reads 64
Table ‘Worktable’. Scan count 0, logical reads 0
Table ‘Person’. Scan count 1, logical reads 67
Table ‘#A96F2843′. Scan count 1, logical reads 33

SQL Server Execution Times:
CPU time = 31 ms, elapsed time = 39 ms.

Le gain de temps pour une requête aussi simple n’est pas négligeable, mais c’est surtout le gain en IOs qui est très intéressant ! Voyons ce que nous dit le plan de requête :

L’ordre d’accès aux tables est le même, mais on voit bien que la façon de les traiter a changé : les jointures et agrégats sont exécutés par hachage. On note aussi les avertissements (petit point d’exclamation noir dans un triangle jaune) sur ces deux opérateurs : ils ont du accéder à TempDB pour exécuter la jointure et l’agrégat, d’où les Workfile et Worktable dans la sortie de SET STATISTICS : ce sont des structures créées à la volée dans TempDB, souvent à défaut d’index pouvant supporter la requête efficacement.

Voyons ce que nous indique l’opérateur Table Scan :

Ici on voit bien que l’estimation du nombre de lignes s’est faite correctement, et c’est donc bien cela qui a conduit le moteur à changer les algorithmes de jointure et de calcul de l’agrégat.

Pour ma part, la grande majorité des instances SQL Server que j’administre actuellement sont de version 2014, et j’ai activé ce drapeau de trace sur toutes celles-ci. En effet, l’application qui repose sur cette base de données fait souvent appel à des Tabled-Valued Parameters, qui sont des variables de type table que l’on peut passer en paramètre à une procédure stockée ou un appel à la procédure stockée système sp_executesql. Les performances générales de l’application s’en sont immédiatement ressenti positivement.

Je n’irai pas jusqu’à écrire qu’il faudrait que ce drapeau de trace soit activé sur toute les instances de production, car :

1. toutes les applications et leurs charges de travail sont différentes
2. il est toujours primordial de tester et de mesurer avant d’effectuer un quelconque changement de configuration sur une instance de production

Je vous engage vivement donc à tester pour en observer l’effet :

• Pour savoir quels sont les drapeaux de trace actifs, il suffit d’exécuter DBCC TRACESTATUS seul, ou si l’on veut être plus spécifique : DBCC TRACESTATUS (2453, -1)
• Pour désactiver un drapeau de trace, il faut exécuter : DBCC TRACEOFF ({traceFlag}, -1), soit dans le cadre de ce billet : DBCC TRACEOFF (2453, -1)

N’hésitez pas à me laisser un petit commentaire !

ElSüket.

• 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) !

Elle capture, entre autres, les événements d’échec d’authentification, la création d’objets dans TempDB, les warnings sur Hash et Sort, les grossissements de fichiers, et de nombreux autres événements. Ceux-ci peuvent aider à comprendre, a posteriori, ce qui a causé une grande consommation de CPU, des latences disque, …

Comme cette trace est écrite sur disque, il peut malencontreusement arriver que ce dernier devienne plein, provoquant alors l’arrêt automatique et forcé de la trace. Ce léger incident (l’arrêt de la trace, pas l’absence d’espace disque libre !) n’empêche aucunement l’instance de fonctionner, ou au moins d’être accessible. Cependant, comment peut-on redémarrer cette trace sans redémarrer l’instance SQL Server ?

En effet, la documentation nous indique que la trace par défaut n’est démarrée que lorsque l’instance démarre aussi … nous allons voir que c’est incomplet. Une fois le disque supportant la trace disposant à nouveau d’espace disque libre, on constate que la trace par défaut est arrêtée à l’aide de l’instruction suivante :

Lorsque la trace par défaut est active, cette requête retourne une ligne, dont la colonne id est à 1. On peut vérifier que c’est la trace par défaut à l’aide de la valeur de la colonne is_default : 1 si c’est le cas, 0 à l’inverse :

Dans la situation de l’incident que nous évoquons, cette même requête ne retournera pas de ligne (ou tout du moins aucune dont la colonne is_default est à 1). Pour démarrer la trace par défaut, il suffit de s’en remettre à l’option de configuration d’instance default trace enabled :

On voit que c’est une option avancée et dynamique, ce qui signifie qu’un redémarrage de l’instance SQL Server n’est pas nécessaire. Dès lors, pour réactiver la trace par défaut, il suffit de positionner cette option à 0, puis immédiatement ensuite à 1, ce qui est sa valeur par défaut :

Sur exécution de ce lot, l’onglet Messages du panneau de résultats de SQL Server Management Studio affiche :

Configuration option ‘show advanced options’ changed from 0 to 1. Run the RECONFIGURE statement to install.
Configuration option ‘default trace enabled’ changed from 1 to 0. Run the RECONFIGURE statement to install.
Configuration option ‘default trace enabled’ changed from 0 to 1. Run the RECONFIGURE statement to install.
Configuration option ‘show advanced options’ changed from 1 to 0. Run the RECONFIGURE statement to install.

Et l’on voit alors que la trace a été démarrée, en interrogeant une nouvelle fois la vue sys.traces.
On trouvera aussi dans les journal de SQL Server les lignes suivantes :

Ici on voit bien que la trace par défaut a été démarré par le système (le SPID est inférieur à 50), quelques millisecondes après le démarrage de celui-ci. Elle a ensuite été redémarrée par nos soins un peu plus tard.

Petite note finale : les fonctionnalités SQL Trace et SQL Profiler sont obsolètes, et remplacées par la fonctionnalité d'événements étendus, plus puissante et performante. Vous pouvez voir comment les utiliser dans cette vidéo, en gardant bien à l’esprit que dès SQL Server 2012, une interface graphique intégrée à SQL Server Management Studio permet de créer une session sans écrire de code, et de visualiser les événements capturés à la façon de ce que permet SQL Profiler.

Enfin, pour interroger un fichier de trace SQL Profiler, il suffit d’utiliser la fonction sys.fn_trace_gettable(). Donc pour en faire l’analyse, on peut utiliser le lot suivant :

Alors bon traçage à tous !

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.

La table suivante décrit ce changement de façon plus visuelle : le moins qu’on puisse dire, c’est qu’elle s’est éclairci avec ce Service Pack !

Mêmes les fonctionnalités introduites avec SQL Server 2016 RTM Enterprise ont été élargies aux autres éditions. Ceci permet bien sûr de programmer de façon plus uniforme, en ayant moins recours à la vérification de l’édition. C’est tout à fait avantageux pour les éditeurs de logiciels, mais aussi pour les scripts de maintenance, notamment PowerShell, qui devraient donc compter moins de if une fois toutes les bases de données migrées vers cette version (ce qui n’est pas une mince affaire :)). Mon seul regret ira peut-être à la reconstruction d’index en ligne, mais c’est un choix qui se justifie si l’on se place de l’autre côté du comptoir.

Pour avoir une vue plus complète, voici la page de comparaison des éditions de SQL Server 2016 SP1.

Ceci étant, c’est d’abord une excellente nouvelle, quoique la littérature actuelle sur ce sujet en dise du fait des limitations suivantes pour les index ColumnStore et les tables optimisées en mémoire (InMemory OLTP) :

• un quart de la quantité de RAM allouée à SQL Server
• degré de parallélisation maximal : 2 cores

Mais ne serait-ce que pour la sécurité des données, les fonctionnalités introduites avec SQL Server 2016 RTM sont bienvenues dans l’édition Standard en SP1. Ensuite ces deux fonctionnalités limitées couvrent des cas d’utilisation très courants, comme l’analytique simple que l’on développe pour une application OLTP, ou encore les variables de type TABLE et autres tables temporaires que l’on peut tenter de déplacer en InMemory pour alléger la charge d’IOs disque de TempDB.

Mais bien sûr ce n’est pas Black Friday tous les jours, donc il faut aussi voir ce qui justifie toujours l’achat d’une édition Enterprise ou Standard de SQL Server 2016 SP1 :

• L’Agent SQL Server n’est pas porté aux éditions Express et LocalDB;
• La parallélisation n’est pas disponible dans ces deux mêmes éditions;
• ALTER INDEX … REBUILD WITH (ONLINE = ON) est toujours réservé à l’édition Enterprise;
• Les groupes de disponibilité AlwaysOn prennent tout leur sens sous l’édition Enterprise; autrement, cela s’apparente à de la mise en mirroir;
• La prise en compte à chaud de CPU et de RAM additionnels est réservé à l’édition Enterprise;
• Le cryptage (Transparent Data Encryption) avec ou sans EKM (Extensible Key Management, qui permet de déplacer la gestion des clés à un petit serveur spécialisé (Hardware Security Module)) reste une fonctionnalité Enterprise;
• Le cryptage et la compression des sauvegardes n’est pas disponible en édition Express ou LocalDB;
• La quantité de RAM est toujours limitée à 128Go pour une édition Standard, quand l’Enterprise est à 24 To (!!!);

Pas grand chose de choquant donc, si ce n’est peut-être le dernier élément de cette liste : l’écart entre Enterprise et Standard frise le gouffre. Ceci est accentué lorsqu’on trouve des PC portables disposant de 32 voire 64Go de RAM. On peut donc avoir bonne espérance que cette limite sera repoussée dans un avenir relativement proche.

Dès lors il est simple de voir que le volume de licences Standard de SQL Server 2016 va forcément augmenter, sans pour autant marcher sur les plates-bandes de celui de l’édition Enterprise.

En ce qui concerne la consolidation du code à travers les éditions, nous les verrons dans un prochain billet.

Bonne migration vers SQL Server 2016 SP1 à tous !

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 !

On notera comme très bienvenues :

• le fait de ne plus avoir à activer le drapeau de trace 2371 pour voir le ré-échantillonnage des statistiques de colonnes et d’index se faire lorsque la table a subi 20% du nombre de ses lignes en affectation
• le drapeau de trace est l’un de ceux qu’on n’ose pas activer, parce qu’il peut être bénéfique à certaines requêtes et pas à d’autres : sous le mode de compatibilité 130, ce sera le cas par défaut
• la parallélisation de la mise à jour des statistiques échantillonnées, qui vient compléter avantageusement celles qui ne l’étaient pas (FULLSCAN)

Bonne lecture et optimisation de requêtes !

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 !

@++

Bien entendu ce n’est pas aussi simple que cela. Démarrons donc une série de billets sur les attentes au sein du moteur de bases de données de SQL Server, en détaillant un peu le mode d’exécution des requêtes.

Modes d’exécution des processus : avant et après SQL Server 2000

Sur les versions antérieures à SQL Server 2005, une grande partie des opérations étaient effectuées par le système d’exploitation lui-même. Ceci fait que jusqu’à SQL Server 2000, il était difficile de comprendre un problème de performance, c’est à dire d’obtenir des détails sur le traitement interne des processus par Windows. Cinq ans et une tétra-volée de lignes de code plus tard, Microsoft nous livre un nouvel opus de SQL Server, estampillé 2005, avec un nouveau composant majeur : SQL Operating System (SQLOS). Celui-ci est la fondation du succès actuel du moteur, et il nous permet, à l’aide des vues et fonctions de gestion dynamique (DMVs, DMFs, ou DMOs dans la littérature), de mieux comprendre ce qui se passe lorsque l’on trouve que l’instance, la base de données, ou une requête se comportent anormalement.

Outre le fait que le moteur est, avec cette version, devenu hautement configurable, il implémente un mode d’exécution simultané de processus en mode coopératif, à la différence de Windows, qui les exécute par préemption. En effet, le système d’exploitation exécute un processus en octroyant à celui-ci un certain temps, qu’on appelle quantum, et une priorité par rapport aux autres processus. Cette priorité varie en fonction des ressources matérielles disponibles, de l’activité courante, … Il fait donc s’exécuter tour à tour des processus en interrompant l’exécution d’autres.

On voit donc que cela se pose directement en opposition à la concurrence d’accès que doit supporter un moteur de bases de données relationnelles SQL : les interruptions d’exécutions peuvent se produire pour plusieurs processus de SQL Server, mais aussi être générés par les processus d’autres applications s’exécutant sur la même machine (antivirus par exemple, …). De là le mode coopératif, qui laisse le soin au moteur de gérer ses propres processus, à de rares exceptions près (création des fichiers d’une base de données, …). Ce mode procure un excellent gain de performance observable dès la fin de la migration d’une base SQL Server 2000 à 2005, mais pose aussi une nouvelle problématique : la concurrence d’accès aux ressources logiques ou physiques que gère le moteur, qui doivent souvent être sérialisées.

Planificateurs, tâches, et unités d’exécution
Le mode coopératif d’exécution de processus est supporté par un modèle de traitement différent, qui suit le schéma suivant :

Les sessions
C’est la connexion d’une application cliente à l’instance SQL Server. On peut connaître le détail de chacune des sessions ouvertes sur l’instance en interrogeant la vue de gestion dynamique sys.dm_exec_sessions. Les sessions dont la colonne session_id ont une valeur inférieure à 50 sont des sessions ouvertes par le système lui même, pour la gestion de ses processus d’arrière-plan. Il est possible que, lorsqu’une charge de travail importante s’exécute, le moteur ouvre une session dont la valeur de session_id est supérieur à 50. Si on veut donc être sûr de ne requêter que les sessions utilisateur, on peut filtrer par la colonne is_user_process.

Les requêtes
Ce sont, au sens logique, les requêtes en cours d’exécution par le moteur. Elles sont elles aussi exposées par une vue de gestion dynamique : sys.dm_exec_requests. Ici aussi, on retrouve de nombreuses caractéristiques, parmi lesquelles le type et la durée d’attente (wait_type, last_wait_type, et wait_time), le numéro de la session qui bloque l’exécution de la requête (blocking_session_id). A ce stade du modèle d’exécution des requêtes, on voit donc que la gestion des accès concurrentiels aux ressources est au cœur du moteur de base de données.

En suivant le schéma ci-dessus, on peut lier sys.dm_exec_sessions à sys.dm_exec_requests sur la colonne session_id, et cette dernière à sys.dm_os_tasks sur la colonne task_address. Et la colonne task_address, me direz-vous ? voici …

Les tâches
Elles incarnent le travail qui doit être effectué par SQLOS pour résoudre une requête; à une requête peuvent correspondre plusieurs tâches. Lorsque le moteur soumet une requête à exécution, il crée une série de tâches. On peut en obtenir les détails en interrogeant la vue sys.dm_os_tasks. Même sur une instance où aucune requête n’est en cours d’exécution, l’interrogation de cette vue nous retourne quelques lignes : comme évoqué, SQL Server exécute ses propres processus en arrière-plan; c’est d’ailleurs ce que l’on peut constater en observant la colonne session_id : nombreuses sont les lignes pour lesquelles la valeur est inférieure à 50. Ceci correspond à ce que nous avons observé à l’interrogation de sys.dm_exec_sessions. Il en va de même pour la colonne request_id : elle nous permet de réaliser une jointure avec la vue sys.dm_exec_requests. Et la colonne worker_address, me direz-vous ? voici …

Les unités d’exécution
Les unités d’exécution effectuent le travail de résolution de la requête que l’on vient de soumettre, qui leur est ordonné par les tâches. A une tâche correspond une seule unité d’exécution.

Elles sont groupées dans un pool, et à tout instant, on peut (généralement !) les classer en deux catégories : soit elles sont inoccupées (elles bullent, potentiellement en regardant les copines travailler), soit elles exécutent une tâche. Lorsque toutes les unités d’exécution sont occupées, la tâche est alors mise en attente jusqu’à ce que l’une d’entre-elles devienne disponible.

Le nombre d’unités d’exécution est automatiquement calculé par SQL Server durant l’installation. Pour connaître le nombre d’unités d’exécution créées par SQL Server, il suffit de s’en remettre à la table exposée sur cette page de la documentation.

Le nombre d’unités d’exécution est configurable, et est par défaut à zéro : c’est à dire qu’on laisse SQL Server avec la configuration d’installation. Dans la très grande majorité des cas, il n’y a aucun besoin de modifier le nombre d’unités d’exécution. Bien sûr, un fil d’exécution nécessite un peu de mémoire pour s’exécuter : 2 Mo sur les machines dont le CPU fonctionne avec des mots de 64 bits.

On peut en obtenir les détails en interrogeant la vue de gestion dynamique sys.dm_os_workers. Celle-ci expose plusieurs colonnes renseignant sur l’état de l’unité, avec ses statistiques d’exécution, et expose deux colonnes : scheduler_address, qui permet de faire la jointure avec la vue sys.dm_os_schedulers, et task_address avec la vue sys.dm_os_tasks. La colonne la plus intéressante pour le sujet que nous traitons est state, qui peut prendre les valeurs suivantes :

• INIT : SQLOS prépare l’unité d’exécution
• RUNNING : l’unité d’exécution exécute actuellement un travail sur un processeur
• RUNNABLE : l’unité d’exécution est en attente d’un processeur pour exécuter un travail
• SUSPENDED : l’unité d’exécution est en attente de l’accès à une ressource

Comme nous le verrons plus loin dans cet article, les unités d’exécution passent de l’état RUNNING à SUSPENDED, puis à RUNNABLE, et de nouveau à RUNNING jusqu’à ce que le travail qu’elles ont à exécuter soit terminé.

Et la colonne thread_address, me direz-vous ? voici …

Les fils d’exécution
L’unité d’exécution ne réalise pas précisément l’exécution elle-même : elle demande un fil au système d’exploitation. C’est ce qu’expose la vue de gestion dynamique sys.dm_os_threads.

Les planificateurs
Un planificateur est en charge de gérer les unités d’exécution. En ce sens, c’est un peu le chef d’orchestre de l’exécution concurrente des requêtes, qu’elles proviennent d’applications ou des processus internes à SQL Server. Lorsqu’une tâche requiert un core pour s’exécuter, c’est le planificateur qui assigne la tâche à un des cores disponibles.

C’est aussi ce composant qui s’assure que les unités d’exécution coopèrent en cédant le core auxquels elles sont attachées lorsqu’elles atteignent leur quantum. On pourrait alors argumenter que ce mode d’exécution n’est pas si coopératif que son nom le laisse entendre. Le quantum est en fait en place parce que le planificateur ne permet qu’à une seule unité d’exécution d’occuper un core. S’il n’existait pas, alors l’unité d’exécution pourrait occuper un core indéfiniment.

Chaque core de CPU, qu’il soit logique ou physique, dispose d’un (et d’un seul) planificateur. Par exemple, supposons que l’on dispose d’une machine équipée de deux processeurs à huit cœurs chacun : il y a aura donc 16 planificateurs.

On peut obtenir les détails de chaque planificateur en interrogeant la vue de gestion dynamique sys.dm_os_schedulers :

On peut y voir à quel core le planificateur est attaché, son statut (VISIBLE ONLINE : utilisé pour les requêtes utilisateur, HIDDEN ONLINE : utilisé par les processus d’arrière plan du moteur), le quantum qui lui est attribué (toujours à 4000 µs, et ce n’est pas configurable), et le temps CPU consommé par chaque planificateur. Si l’on rajoute les colonnes :

• current_workers_count
• active_workers_count
• current_tasks_count
• runnable_tasks_count
• work_queue_count

On a alors une idée de la charge que supporte l’instance SQL Server étudiée. Par exemple, si la dernière colonne de cette liste montre des nombres élevés, il est probable que SQL Server soit actuellement sous pression CPU.

Vous remarquerez aussi un planificateur dont le statut est VISIBLE ONLINE (DAC) : la fonctionnalité Dedicated Administrator Connection permet de se connecter à une instance SQL Server lorsqu’elle ne réagit plus (surcharge CPU par exemple, …). Ce planificateur lui est dédié.

Nous avons vu comment le moteur distribue le travail aux CPUs pour maximiser la concurrence d’exécution des requêtes. Voyons ce qui se passe lorsque le planificateur doit placer une requête en attente, que ce soit pour l’accès à une ressource, l’acquisition d’un verrou, ou tout simplement lorsque le quantum est atteint …

Les attentes

Les fils d’exécution suivent les phases et les états suivant les deux graphes suivants, qui sont superposables :

Comme nous l’avons vu, les unités d’exécution passent de l’état RUNNING à SUSPENDED à RUNNABLE, dans cet ordre (à de rares exceptions près, notamment lors de l’utilisation de la fonctionnalité Resource Governor). Les attentes représentent le temps que les unités d’exécution participant à l’exécution d’une requête on passé entre le passage d’un de ces états à un autre. Ce temps est subdivisé en deux catégories :

• L’attente de l’accès à une ressource : la ressource peut être un planificateur, le gestionnaire de ressources pour les requêtes parallélisées, un objet de verrouillage (pose d’un verrou sur base de données, fichier de base de données, un schéma, une table, une page, une clé, une étendue, les métadonnées, les unités d’allocation, la CLR, ou pose de loquets (latch dans la littérature) … On l’appelle compendieusement attente de ressource.
• L’attente de la disponibilité d’un processeur après que la ressource soit devenue disponible : c’est ce qu’on appelle de façon plus concise l’attente de signal.

Le temps d’attente est la somme de ces deux temps. Forts de cela, votre œil avisé vous a certainement amené à vous demander : Pourquoi avoir utilisé les deux termes Liste et Queue sur le schéma ci-dessus ?

La liste des unités d’exécution
Cette liste des unités d’exécution à l’état SUSPENDED n’a pas d’ordre ni de priorité de traitement. Toute unité d’exécution peut y rester sans limite de temps, et le nombre d’éléments que cette liste peut contenir n’a pas non plus de limite.

L’unité d’exécution est ajoutée à cette liste lorsque son état passe de RUNNING à SUSPENDED. Elle en est retirée lorsque son état passe de SUSPENDED à RUNNABLE : ceci se produit lorsque cette dernière est notifiée que la ressource qu’elle attendait est maintenant disponible, et ce toujours sans ordre ni priorité de traitement.

Ces attentes sont exposées par la vue de gestion dynamique sys.dm_os_waiting_tasks.

Si cela vous a fait penser à l’attente de pintes au zinc d’un bar bondé, sachez que vous n’êtes pas seul !

La queue des unités d’exécution en attente d’un core
Cette queue contient la liste des unités d’exécution dont l’état est RUNNABLE, et fonctionne comme un FIFO. L’unité d’exécution qui se trouve donc être entrée la première dans la queue est la première à être attachée à un core disponible.

Une unité d’exécution entre dans cette queue lorsque son état passe de SUSPENDED à RUNNABLE. Ceci se produit par exemple lorsqu’une autre unité d’exécution en cours de traitement par l’un des cores alloués à l’instance SQL Server dépasse son quantum, ou que son état devient SUSPENDED.

Le nombre d’éléments de cette queue est exposé par la vue de gestion dynamique sys.dm_os_schedulers, à travers la colonne runnable_tasks_count.

Si cela vous a fait penser à l’attente pour l’accès aux toilettes d’un bar bondé, sachez que vous n’êtes pas seul !

Pour illustrer tout cela, le schéma plus haut peut être complété par les deux losanges rouges ci-dessous :

Voilà pour la description du fonctionnement de l’exécution des requêtes.
Dans un billet à venir, nous verrons les types d’attentes les plus communs, et comment on peut les interpréter.

A bientôt, et bonne gestion des attentes. N’hésitez pas à commenter cet article !

Cela recoupe l’article et la partie du livre sur SQL Server 2014 consacrée à cette fonctionnalité.

Bonne visualisation !

J’ai eu l’honneur et l’avantage de faire la rencontre de la très célèbre Sarah Bessard, dont j’entendais régulièrement parler depuis mon rapatriement en France, sans pour autant l’avoir encore vue de mes yeux. Elle a résumé avec un humour qui n’a d’égal que son talent pour l’animation par une mise en scène d’un excellente session sur le Query Store en compagnie de Philippe Geiger, et d’une autre sur le processus de migration d’une version à l’autre de SQL Server, avec Arian Papillon, en sombrero et collier de fleurs … Preuve, s’il en fallait encore, de la nécessité de femmes dans ce mondes de barbus !

Je vous laisse donc vous délecter de ce résumé, car je n’aurais pas pu l’écrire mieux qu’elle. Croyez-le ou non, il colle très bien à la réalité !

@++

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 !

Quelle que soit la version de SQL Server, les caractéristiques des 256 dernières situations de blocage qui ont conduit à l’annulation de la transaction détenant le moins de ressources (puisque la moins « chère » à annuler) sont retenus par une cible de type anneau de mémoire (qui fonctionne sur le principe d’un FIFO) par une session d’évènements étendus que l’on pourrait qualifier de « système », et nommée system_health.

On peut s’en tenir au document XML exposé par ces requêtes pour comprendre quelles ressources étaient en jeu, et procéder à l’optimisation adéquate qui permettra d’éviter que de telles situations se reproduisent. Néanmoins, comme un schéma vaut souvent mieux que mille mots, on peut aussi récupérer le document XML de chaque ligne généré par ces requêtes, et le sauvegarder dans un fichier de type texte, dont on changera l’extension par « .xdl » : ceci permet de voir la situation de blocage sous la forme d’un graphe; ce type de fichier s’ouvre avec SQL Server Management Studio (cf. Livre SQL Server 2014)

Ces graphes ont évolué avec les sorties des opus de SQL Server, si bien que, par exemple, la requête qui permet de les récupérer sous SQL Server 2008R2 ne fonctionne pas pour les versions suivantes de SQL Server. En revanche, la structure de ce document est stable depuis SQL Server 2012.

Voici donc les requêtes :

Bonne lecture et déblocage !

ElSüket.

Pour la documentation relative à cette version, c’est par ici : fr / en.

Bonne évaluation!

Un plan de requête expose la façon dont l’optimiseur de requêtes de SQL Server a calculé la résolution d’une requête que nous lui avons soumis. Ce dernier fait un excellent travail dans la très grande majorité des cas, et pour les autres, il a parfois besoin de l’aide d’un DBA lorsque l’indexation n’est pas l’origine du problème.

SQL Server Management Studio (SSMS) expose les plans de requête estimés et réels.
Le plan de requête estimé expose la suite d’opérateurs logiques et physiques que le moteur a trouvé optimale pour résoudre une requête, c’est à dire celle qui consommera le moins de ressources. Ce plan est basé sur les statistiques de colonnes et d’index. La maintenance et la qualité des statistiques est un un sujet vaste que nous n’aborderons pas ici. On peut obtenir le plan de requête estimé sans exécuter celle-ci en pressant CTRL+L, ou en cliquant sur le bouton ci-dessous, après avoir surligné la requête en question s’il y en a plusieurs dans la fenêtre de requêtes de SSMS.

Le DBA peut se servir du plan de requête estimé pour comprendre un problème de performances, mais il arrive qu’un autre type de plan, dit réel, soit nécessaire. Ce plan peut être généré juste après la fin de l’exécution d’une requête, et permet d’exposer les différences entre le plan estimé et ce qui s’est passé lors de son exécution. De façon similaire au plan de requête estimé, on peut obtenir ce plan de requête en pressant CTRL+M, ou en pressant le bouton suivant dans SSMS avant l’exécution de la requête à étudier.

Visuellement, avec SSMS, aussi bien avec le plan de requête estimé que réel, nous obtenons, pour la requête suivante exécutée sur la base de données exemple AdventureWorks2012 proposée par Microsoft ici (voir les détails de l’installation ici) :

Bien qu’utile, le fait d’avoir à constamment déplacer les curseurs de parcours, surtout lorsque le plan est constitué de nombreux opérateurs, devient vite peu confortable.

Alternativement, SQL Sentry nous offre la possibilité d’utiliser la version gratuite de son outil Plan Explorer, que j’avais exposé ici, et qui continue d’évoluer. On peut télécharger le logiciel ici (en toute fin de page), et il s’intègre automatiquement à SSMS. En effet, il suffit d’effectuer un clic-droit dans une zone vierge du plan et de sélectionner l’option View in SQL Sentry Plan Explorer …

… pour voir l’interface de SQL Sentry Plan Explorer s’ouvrir, et observer une façon différente de disséquer un plan de requête :

Le nombre de lignes échangé entre les opérateurs est exposé directement dans le plan, exposé de façon plus compacte. Par ailleurs, le coût relatif des opérateurs est affiché directement au-dessus de ceux-ci, avec une couleur qui s’assombrit suivant la dépense de ressources qu’ils engendrent. Outre le fait que l’on puisse zoomer sur le plan (utile lorsque le plan de requête est tentaculaire, ou en conférence), les divers onglets présents au bas du panneau du plan d’exécution graphique décrivent des informations souvent utiles, notamment :

• le document XML sous-jacent au plan graphique
• L’arbre du plan, similaire à la sortie que l’on obtient avec SSMS lorsque l’option de session SHOWPLAN_TEXT est positionnée à ON
• Les opérations les plus consommatrices de ressources, comparées à toutes les autres opérations du plan
• Les colonnes spécifiées dans la requête, quel opérateur elles subissent et à travers quel index elles sont accédées
• Le diagramme de jointure, qui permet bien souvent de se rentre compte d’une auto-jointure inopportune
• Les paramètres de la requêtes et leur valeur au moment de la compilation et au moment de l’exécution
• Les expressions (par exemple Expr10NN, où N est un entier, que l’on rencontre parfois dans le plan graphique dans SSMS comme substitut à une expression dans la requête, et que l’on arrive à comprendre seulement en décortiquant le plan XML. Cela permet aussi de détecter les conversions implicites, parfois néfastes aux performances d’exécution d’une requête.)

Les diverses requêtes sont exposées une à une, avec leur coût relatif au coût total du plan : il suffit de cliquer sur l’une des requêtes dans le panneau Results pour les parcourir. Enfin, si l’optimiseur suggère d’ajouter un index (fonctionnalité de suggestion d’index manquants), il suffit de cliquer sur l’opérateur final du plan (le plus en haut et à gauche) pour que l’outil ouvre une fenêtre séparée qui donne, comme dans SSMS, l’instruction de création de l’index.

Passons maintenant au plan d’exécution réel :

Avec la possibilité de montrer l’estimation du nombre de lignes (cardinalité) par rapport au nombre de lignes manipulé par les opérateurs lors de l’exécution de la requête par un simple clic-droit, on détecte très rapidement les problèmes d’estimation de cardinalités : c’est bien souvent à cause de cela que la requête étudiée s’exécute lentement ou consomme beaucoup de ressources. Dans ce cas, l’épaisseur des flèches est largement affectée, et c’est l’effet visuel généré par le passage d’un plan à l’autre qui permet la détection visuelle.

Cerise sur le gâteau : SQL Sentry Plan Explorer permet aussi d’anonymiser un plan de requête, c’est à dire de remplacer le nom réel des tables et autres objets exposés par le plan par un nom générique, et ce en conservant toute la logique du plan. Après un clic sur le bouton suivant, qui se trouve dans la barre d’outils de SQL Sentry Plan Explorer …

… une autre fenêtre s’ouvre, exposant le plan anonymisé : au lieu de trouver le nom des objets réels, on trouve par exemple ObjectN.IndexP, où N et P sont des entiers.

On peut ensuite sauvegarder un tel plan (qu’il soit anonymisé ou non) en vue de le partager sur le forum Développez.com dédié à SQL Server sans exposer d’informations sensibles : un clic sur File > Save As ouvre la fenêtre suivante :

• L’extension .queryplananalysis est le format propriétaire de SQL Sentry. Si vous sauvegardez sous ce type, assurez-vous que la personne avec qui vous partagez le plan de requête dispose aussi de SQL Sentry Plan Explorer.
• L’extension .sqlplan est le format propriétaire de SQL Server Management Studio. Après la sauvegarde, si vous double-cliquez sur un tel document, il s’ouvrira automatiquement avec ce dernier
• L’extension .xml est le format générique de description de documents bien connu. Le document résultant est identique à son homologue .sqlplan. On peut l’utiliser pour automatiser l’extraction de données de plusieurs plans.

Bonne capture de plans !

• Définition des plans XML : schémas XSD : expose le schéma XSD des plans de requête XML, ce qui permet de trouver les améliorations au niveau de l’optimiseur en comparant le schéma de deux versions de SQL Server
• Guide de référence des opérateurs Showplan : une liste exhaustive de tous les opérateurs que l’on peut trouver dans un plan de requête graphique
• Une autre liste, publiée par Fabiano Amorim, avec la liste des opérateurs de plan d’exécution graphique les plus communs, expliquant leur fonctionnement, et pourquoi ils sont choisis par l’optimiseur de requêtes

Bonne lecture !

En plus du fonctionnement du cryptage des sauvegardes, j’y détaille les étapes pour :

1. Sauvegarder une base de données en cryptant le fichier de sauvegarde
2. Restaurer une base de données à partir d’une fichier de sauvegarde crypté
3. Réaliser des sauvegardes cryptées dans Azure
4. Restaurer une base de données à partir d’une sauvegarde cryptée stockée dans Azure

Finalement, j’y aborde l’impact des divers algorithmes de cryptage sur l’utilisation CPU et la taille des fichiers de sauvegarde.

L’article est en Anglais, et je vais le traduire en Français.

Bonne lecture !

• On ne dispose pas de l’Agent SQL Server
• On ne peut pas utiliser des plans de maintenance pour gérer les sauvegardes
• On ne peut pas envoyer d’emails
• La compression des fichiers de backup, introduite avec SQL Server 2008, n’est pas prise en charge

Si donc on souhaite planifier les sauvegardes de base de données, et envoyer un email en cas d’échec, on peut :

• Remplacer un job de l’Agent SQL Server par une tâche du Planificateur de Tâches de Windows
• Écrire une procédure stockée d’assembly pour envoyer des emails

Cet article détaille les étapes à suivre pour ce faire.

Une procédure stockée d’assembly pour envoyer des emails

Si l’Agent SQL Server n’est pas disponible, l’intégration CLR l’est. Ainsi en quelques lignes de code C#, on peut envoyer des e-mails de façon assez similaire à ce qu’on peut faire sous les éditions non-Express de SQL Server avec la procédure stockée système msdb.dbo.sp_send_dbmail.

Pour créer une procédure stockée d’assembly sous Visual Studio 2012 ou ultérieur, il faut tout d’abord installer SQL Server Data Tools. Pour ce faire, vous pouvez lire ce billet. Notez qu’il n’est pas nécessaire d’avoir Visual Studio déjà installé.

Une fois Visual Studio démarré, il suffit de créer un nouveau projet à partir de la page de démarrage, ou bien de suivre File > New > Project, et de choisir un projet SQL Server :

Il faut faire attention à la version du framework .NET. Par exemple, si l’on souhaite que l’assembly soit exécutable par SQL Server 2008, il faut spécifier la version 3.5. Une fois que l’on a validé le tout par OK, nous pouvons ajouter une procédure stockée :

Comme je préfère C# à VB.NET, j’ai choisi une procédure stockée C#, mais si vous préférez VB.NET, rien ne s’y oppose. Notons que par défaut, le langage de la procédure stockée n’est pas pré-sélectionné.

Une fois que l’on a validé le tout par un clic sur Add, on peut écrire :

Ce qui, même pour l’ultra-débutant C# que je suis, est loin d’être complexe. Avant de builder le projet, il nous faut configurer l’assembly pour lui permettre d’accéder à des ressources externes, ce qui se fait après un clic-droit sur le projet, et choisi Properties (ou pour les aficionados du raccourci clavier, ALT + Entrée). Dans la page SQLCLR, nous commutons donc la liste déroulante Permission Level sur EXTERNAL_ACCESS. De la même façon, dans la page SQLCLR Build, nous commutons la liste déroulante Configuration sur Release, ce qui permet un léger gain de performances. Ce n’est pas très important dans notre cas, mais si l’assembly est plus complexe, cela peut le devenir.

Après un clic sur Build > Build Solution, nous pouvons aller chercher le fichier dll dans le dossier de la solution. Dans cet exemple, il s’agit de D:\SQLServer\Assemblies\SQLServerExpressDatabaseMail\SQLServerExpressDatabaseMail\bin\Debug, et le fichier est nommé SQLServerExpressDatabaseMail.dll.

De retour dans SQL Server Management Studio, une fois connecté à l’instance SQL Server Express, il est tout d’abord nécessaire d’activer la prise en charge de la CLR par cette dernière. Cela se fait sans redémarrage de l’instance, en quelques instruction :

Il est maintenant requis de déclarer la base de données dans laquelle nous allons enregistrer la procédure stockée d’assembly comme « digne de confiance ». Ceci nous permet d’emprunter l’identité de SQL Server pour exécuter cette procédure qui va accéder à des ressources en dehors de la base de données : en l’occurrence, un serveur de mails (mais ce peut être le système de fichiers, un webservice, …). Là encore, une simple commande suffit :

Nous devons maintenant enregistrer l’assembly dans la base de données, ce que l’on peut faire une fois que l’on a copié l’assembly dans un dossier de notre choix, sur le serveur hébergeant l’instance SQL Server Express / WSUS. Dans cet exemple, nous utilisons le dossier C:\SQLServer\.

On peut vérifier l’enregistrement de l’assembly en interrogeant la vue système sys.assemblies. En ce point, on n’a plus besoin du fichier dll : le binaire de celle-ci est maintenant enregistré dans la base de données (de nom DBA dans cet exemple).
Créons maintenant la procédure stockée :

Et testons enfin :

Une procédure stockée pour gérer les sauvegardes

Voici une procédure stockée générique qui permet de sauvegarder une base de données en particulier, ou toutes les bases de données hébergées par une instance SQL Server. Dans le second cas, les sauvegardes du fichier du journal des transactions n’est pas supportée. En revanche, on peut exécuter cette procédure stockée sur toutes les versions de SQL Server, à partir de 2005. Enfin, le cryptage des sauvegardes, introduit avec SQL Server 2014 n’est pas supporté non plus. Cela exige que quelques prérequis soient en place, et ceux-là sortent du cadre de cet article.

La procédure stockée d’assembly est référencée dans le bloc CATCH final : pour toute erreur, on envoie un email.

Remplacer l’Agent SQL Server par le Planificateur de Tâches de Windows

Nous voilà à l’étape finale : prendre des sauvegardes de base de données régulièrement. Pour ce faire, on peut tout à fait utiliser le Planificateur de Tâches de Windows : en effet, on peut appeler l’utilitaire en ligne de commandes SQLCMD (la documentation, l’utilisation, et un exemple), qui permet d’interagir avec une instance SQL Server. Cet outil permet de passer en paramètre un script, d’exécuter une requête, mais surtout d’enregistrer la sortie dans un fichier. Cette dernière fonctionnalité facilite la tâche d’investigation sur l’échec d’exécution de code.

Une fois l’application Planificateur de Tâches démarrée, on créé une tâche assez simplement :

Une fois passé la première page ou nous nommons la tâche, un clic sur Next nous amène à la planification. Pour Windows Server Update Services, on peut estimer qu’une sauvegarde complète par jour est suffisante. Évidemment, cela varie avec la criticité de l’application. Nous spécifions donc une exécution quotidienne :

Nous planifions l’exécution à minuit et une minute :

Et nous choisissons de démarrer une application :

Dans la saisie texte Program / Script, nous spécifions l’invite de commandes. En ce qui concerne les arguments, nous écrivons :

• Pour SQL Server 2008 :
  "C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE"
• Pour SQL Server 2012 :
  "C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.EXE"
• Pour SQL Server 2014 :
  "C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\SQLCMD.EXE"

En ce qui concerne les arguments, nous passons :

sqlcmd -E -S WSUS -i "C:\SQLServer\WSUSBackup.sql" -o "C:\SQLServerBackup\FullBackupLog.txt"

Attention, la casse des options est importante.

• -E pour spécifier une connexion approuvée
• -S : l’instance SQL Server à laquelle on souhaite se connecter
• -i : le chemin et le nom du fichier de script T-SQL
• -o : le fichier qui capturera les libellés des messages d’information, d’avertissement ou d’erreurs, le cas échéant

Ce qui donne :

Un clic sur Next nous offre une fenêtre de résumé, et on peut valider le tout. Si l’on souhaite ajouter des planifications ou modifier d’autres options pour cette tâche, il suffit de cocher la case Open the Properties dialog for this task when I click Finish.

Nous créons ensuite un fichier WSUSBackup.sql dans un répertoire C:\SQLServer\ sur la machine qui héberge l’application WSUS. Ce fichier appelle la procédure stockée DBA.dbo.databaseBackup_manage comme suit :

EXEC DBA.dbo.databaseBackup_manage 'FULL', NULL, '\\monPartageDeBackup\', 0

Et voilà nos sauvegardes de base de données en place.

Utiliser PowerShell pour supprimer les fichiers de sauvegardes trop anciens

Dans la liste des actions de la tâche que nous venons de créer, nous pouvons en ajouter une qui aura :

• Pour programme : powershell
• Pour arguments : -file "C:\SQLServer\DeleteOldBackupFiles.ps1"

Le fichier DeleteOldBackupFiles.ps1 contient la commande suivante, qui supprime tous les fichiers créés il y a plus de 7 jours, y compris dans les sous-dossiers du partage de backup (-Recurse) :

Get-ChildItem '\\monPartageDeBackup\' -Recurse | Where {$_.CreationTime -lt (Get-Date).AddDays(-7)} | Remove-Item -Force

Par défaut, PowerShell ne permet pas l’exécution de scripts. Pour l’autoriser, il faut démarrer l’interface PowerShell, et exécuter Set-ExecutionPolicy RemoteSigned (en accord avec votre Administrateur Systèmes !).

Retenons également que les statistiques de colonne et d’index de la base de données supportant WSUS ne sont pas maintenues. Ce sera probablement suffisant pour générer une lenteur après quelques mois d’exploitation, dont votre Administrateur Systèmes vous demandera l’origine

ElSüket.

SSDT a été mis en ligne pour la première fois pour Visual Studio 2010, qu’il installait en mode Shell. Cette version n’est maintenant plus disponible, mais on la trouve bien entendu pour Visual Studio 2012 (fr/en) et 2013 (fr/en).

Ce dernier est en fait décliné en deux opus, l’un dédié à la Business Intelligence, abrévié en SSDT-BI, et l’autre SSDT tout court. Les deux versions installent toujours Visual Studio en mode Shell, mais la version BI n’installe pas les composants nécessaires au développement d’un projet d’assembly SQL Server. Et inversement.

J’avais donc installé SSDT-BI 2012 sans noter que le projet de type SQL Server n’était pas présent. J’ai donc installé SSDT 2012 (téléchargeable ici en version 2012 et 2013), et j’ai maintenant ce qui me manquait :

Bon développement SQL Server !

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.

Lorsque l’on a le service SQL Browser désactivé, on peut se connecter à une instance nommée en précisant le nom du serveur + virgule + le numéro de port. Par exemple, si nous disposons d’un serveur ELSUKETW8 doté d’une instance nommée SQL2012 qui écoute les connexions sur le port 62549, alors dans la chaîne de connexion de nos applications, nous devons remplacer Server=ELSUKETW8\SQL2012 par Server=ELSUKETW8,62549.

Bon routage à tous !

ElSüket

Qu’est-ce que le verrouillage ?

Le verrouillage est un mécanisme qui permet à plusieurs utilisateurs d’accéder à des ressources, tout en évitant que cela résulte en des incohérences de données. Des verrous sont acquis lorsque le moteur de base de données a besoin d’accéder à une ressource pour la lire ou la modifier. Sous SQL Server, cette opération est purement logique, et sert le support de l’ACIDité de toute transaction.

Ce mécanisme est entièrement géré par le moteur de stockage de SQL Server, avec lequel l’utilisateur n’a que peu de moyens d’interagir (et tant mieux !).
On peut bien sûr affecter le comportement d’une transaction en indiquant le niveau d’isolation de transaction sous lequel elle doit être traitée. Il est rarement nécessaire d’indiquer à SQL Server quel doit être le type de verrouillage à choisir à l’aide d’indicateurs de table ou de requête. SQL Server a de toute façon la primauté sur ce choix, puisqu’il outrepasse parfois les recommandations du développeur ou du DBA. Globalement, le moteur de base de données SQL Server effectue le meilleur choix.

Tout ceci fait qu’outre le niveau d’isolation de transaction, lorsqu’on code pour SQL Server, on n’a pas à se soucier de ce que telle ou telle opération DML va produire en termes de verrouillage. Cependant, l’accès concurrent à une même ressource provoque parfois des situations de blocage, voire d’étreinte mortelle (deadlock) : il est alors nécessaire de comprendre ce qui a provoqué cette situation pour pouvoir orienter les choix de SQL Server, de sorte à éviter qu’un tel phénomène se reproduise. A ce titre, il est nécessaire de savoir :