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

Voici comment créer le raccourci :

Il suffit de créer un nouveau raccourci, et d’y coller la ligne suivante, pour SQL Server 2017 :

Pour les versions antécédantes de SQL Server, il suffit de changer le numéro dans SQLServerManager14.msc par celui de la version qui convient :

• pour SQL Server 2012, c’est SQLServerManager11.msc
• pour SQL Server 2014, c’est SQLServerManager12.msc
• pour SQL Server 2016, c’est SQLServerManager13.msc

Bonne configuration à tous !

ElSüket.

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 !

https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

Je donne le lien car il arrive qu’on obtienne la version 17.0 RC par exemple, alors que la version la plus actuelle est la 17.2. Cela évite d’avoir à télécharger 350 Mo en plus de 680 de la 17.0

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 !

Pour installer SQL Server Management Studio 2016 v16.5, c’est par ici.
Pour obtenir l’installation dans une autre langue, voyez la section Langues disponibles.

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 !

• On n’est plus tenté d’installer SSMS en même temps que SQL Server sur une machine : ceci fait donc moins d’ouvertures aux potentielles failles de sécurité et élimine de possibles instabilités de la machine. Cela oblige les acteurs de l’entreprise à se connecter une l’instance SQL Server directement depuis leur station de travail, ou mieux depuis une machine « de rebond » qui peut être monitorée très strictement en ce qui concerne la sécurité d’accès et l’audit des actions de l’utilisateur (par exemple enregistrement vidéo de la session bureau à distance)
• Les corrections et améliorations que SSMS mérite se feront plus fréquemment que le cycle de versionnement de SQL Server, qui est tous les deux ans depuis quelques opus.

Voici donc le lien de téléchargement : en Français et en Anglais

Bon upgrade SSMS !

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 !

Ils sont résumés dans le billet de Frédéric Brouard.

Bonne lecture, et merci de vos retours sur le forum !

Dans la catégorie base de données :

• Pascale Doz, experte en bases de données;
• Frédéric Brouard, alias SQLPro, expert en bases de données;
• Rudi Bruchez, alias Babaluga, expert en bases de données;
• David Barbarin, alias Mikedavem, expert SQL Server

Dans la catégorie recrutement IT : Clément Bocquentin, consultant indépendant en recrutement;

Dans la catégorie communautés :

• Toute l’équipe de Développez.com, et les participants au forum, sans qui je n’aurai pas le plaisir de connaître toutes ces personnes;
• Martine Thiphaine, Lead MVP Microsoft France;
• Les membres du Groupe des Utilisateurs de SQL Server

Last but not least : Arian Papillon, Sarah Bessard et Gilles Ducassou (encore des experts SQL Server ! :D)

A très bientôt dans la mécanique interne de SQL Server

Bonne lecture !

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é !

@++

Cet identifiant numérique est constitué de 14 chiffres, et est articulé en trois parties :

• le SIREN
• le Numéro Interne de Classement, à quatre chiffres : c’est l’ordre de création de l’établissement par l’entreprise Française
• une clé de contrôle, constituée d’un seul chiffre

Ce dernier est calculé à l’aide de l’algorithme de Luhn. Cet algorithme est aussi utilisé pour valider les numéros de carte bleue, et de nombreux identifiants distribués par les administrations de beaucoup de pays. Nous allons nous en servir pour vérifier la validité de SIRETs en l’implémentant spécifiquement pour ce type d’identifiant.

L’algorithme est descriptible comme suit :

1. Pour chaque chiffre dont l’index dans la chaîne est impair, on le multiplie par 2; si le résultat est supérieur à 9, on additionne les chiffes qui constituent ce résultat. Ceci revient à multiplier par 2 le chiffre, diviser le résultat par 10, puis ajouter la multiplication par 2 de ce même chiffre modulo 10.
2. On additionne ensuite les chiffres du résultat un à un, avec les chiffres de l’identifiant qui n’ont pas été traités, c’est à dire ceux dont l’index dans la chaîne est pair. Ceci inclut le chiffre de l’identifiant qui est clé.
3. Si le résultat obtenu est un multiple de 10, alors l’identifiant est valide. Ceci revient à vérifier que le résultat modulo 10 vaut zéro.

La traduction en SQL donne :

On peut l'utiliser directement dans une vue, comme dans le pseudo code suivant :

Si l'on souhaite l'utiliser en colonne calculée, on peut utiliser ce CASE directement dans la définition de ladite colonne, ou bien définir une fonction scalaire comme suit :

Et en ce qui concerne la création de la colonne calculée, on peut l'ajouter à l'aide du pseudo-T-SQL suivant :

Enfin, si l'on souhaite exécuter cette vérification au sein d'une requête, on peut s'en remettre à une fonction de table en ligne. Ce type de fonction n'étant appelé qu'une seule fois, il s'avérera plus performant à l'exécution sur un grand nombre de lignes que l'appel à une fonction scalaire : ces dernières sont appelées autant de fois qu'il y a de lignes de résultat. Ce qui donne :

On peut alors l'utiliser à l'aide de l'opérateur APPLY, comme dans l'exemple suivant :

Bonne validation de SIRETs !

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.

Bonne lecture !

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 !

On trouve l’outil de recherche et de remplacement de texte en suivant le menu Edit, ou en pressant CTRL + F pour la recherche, et CTRL + H pour le remplacement :

Dans le simple but de standardiser le code, l’expression régulière :b+\n, qui signifie tout espace ou tabulation avant le retour à la ligne, peut simplement être remplacée par \n :

Un simple clic sur Replace All, et les vilains espaces et tabulations sont soustraits.

Au-delà de ceci, vous pouvez considérer que je pinaille, voire même que je suis maniaque. C’est probablement vrai ! Mais il faut aussi considérer le cache de requêtes. Si l’on prend une requête et qu’on lui ajoute un espace, une tabulation, ou tout autre caractère sans effet sur la syntaxe ou le résultat de cette requête, SQL Server considère ceci, au niveau du cache de requêtes, comme deux requêtes différentes, étant donné que leur valeur de hachage sera différente. C’est à l’aide de cette valeur que le moteur vérifie s’il existe déjà un plan en cache pour cette requête ou non.

En effet, cette « trousse à outils » est générique, et ne propose aucun contrôle, et nous offre l’amical message suivant :

Quelle ne fut pas ma joie de retrouver ce panneau après avoir cliqué sur le petit bouton en haut et à droite du panneau de conception !

Bonne création de paquetages SSIS !

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

Je tiens donc à remercier les co-auteurs du livre sur SQL Server 2014, à paraître le 10 Juillet 2014 chez Eyrolles :

• Frédéric Brouard, alias SQLPro, qui a eu l’idée géniale d’écrire ce livre
• Christian Soutou, par ailleurs auteur de plusieurs ouvrages autour de SQL
• David Barbarin, alias Mikedavem, pour la fréquence et la qualité de nos discussions

Ce fut un gros challenge que d’écrire ce livre. J’espère que c’est le premier d’une longue série !

Mais aussi :

• Ma compagne, qui m’a supporté dans l’écriture de ce livre;
• Katherine Chen, MVP Lead à Singapour pour toute l’Asie du Sud-Est;
• Toutes les personnes que j’ai rencontrées aux Journées SQL Server à Paris en Décembre 2013, notamment Arian Papillon, Pascale Doz et Christophe Laporte;
• Toute l’équipe de Développez.com, qui ne cesse d’améliorer le site, et qui a la patience de corriger nos erreurs dans les billets que nous publions;
• Panjaporn Vittayalerdpun, Senior Product Manager – Server and Application Platform chez Microsoft à Bangkok, qui organise les conférences SQL Server
• Fukiat Julnual, Évangéliste chez Microsoft à Bangkok, PASS Chapter Thailand, qui organise la communauté SQL Server en Thaïlande;

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 !

Bon visionnage !

• 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.