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.

Il existe un drapeau de trace non-documenté, n° 8666, qui permet d’ajouter au document XML qui décrit le plan de requête les statistiques utilisées par l’optimiseur pour générer le plan de requêtes.

Voyons comment l’utiliser avec une requête sur la base de données AdventureWorks2012 :

Avant toute chose, notez que ce drapeau de trace n’est pas documenté. Comme toute fonctionnalité non-documentée, on ne doit JAMAIS utiliser celui-ci sur une base de données ou une instance qui sert une charge de production. Si tel devait être le cas, je ne peux en aucun cas être tenu pour responsable des conséquences. Vous devez limiter strictement l’usage de cette instruction aux environnements de test.

Utilisons la requête suivante :

Demandons maintenant à SQL Server de générer le plan de requête estimé. Celui-ci s’obtient soit en pressant CTRL + L, soit par un clic sur l’icône suivante, présente dans la barre d’outils :

On obtiendra aussi les informations ajoutées par le drapeau de trace 8666 avec le plan d’exécution réel, que l’on obtient soit en pressant CTRL + M, soit par un clic sur l’icône, suivante présente elle aussi dans la barre d’outils :

Nous devons maintenant explorer le document XML à l’origine du plan d’exécution graphique, ce qui se fait par un simple clic droit dans une zone vierge de ce dernier :

Il nous suffit maintenant de chercher la chaîne de caractères wszStatName, et nous obtenons :

On voit clairement les détails de ce que SQL Server utilise comme métriques pour calculer le plan, notamment :

– le nom de la statistique (ici c’est la statistiques sous-jacente à l’index qui supporte la clé primaire)
– le nom de la colonne la plus à gauche dans cette statistique (wszColName)
– le nombre de lignes échantillonnées lors de la génération de la statique (m_ullSnapShotModCtr)
– le nombre de lignes présentes dans la table (m_ullRowCount)
– le seuil de recalcul automatique de la statistique (ullThreshold)

Pour cette dernière valeur, on peut d’ailleurs faire le calcul suivant :

100.0 * 24,763 / 121,317 = 20.41181367821492

Soit environ 20%. Prenons la partie décimale de ce pourcentage :

(0.41181367821492 / 100.0) * 121,317 = 499.5999999999945

Soit environ 500 lignes. Ceci vérifie bien la règle du seuil de recalcul automatique des statistiques pour les tables de plus de 8MB : 500 lignes + 20% du nombre de lignes de la table.

Bons calculs de plans de requêtes et estimations de cardinalités !

ElSüket

Bon octroi de privilèges !

Bonne Lecture !

ElSüket

Attention : cet article comporte 6 pages

On notera tout d’abord qu’un objet de type SEQUENCE n’est utilisable qu’avec des types numériques précis : tinyint, smallint, int, bigint, decimal et numéric, les deux derniers avec une échelle à zéro.

Commençons donc par créer une SEQUENCE de la façon la plus simple qui soit :

CREATE SEQUENCE dbo.maSequence

C’est aussi simple que cela, mais nous allons voir par la suite qu’on peut aller un peu plus loin.

Maintenant, comment obtenir la « première » valeur de la SEQUENCE dbo.maSequence ?
Là encore, c’est relativement simple :

SELECT NEXT VALUE FOR dbo.maSequence

Donc si l’on crée un objet SEQUENCE sans aucune option, le type par défaut est bigint, et la valeur initiale attribuée à cette SEQUENCE est la plus petite valeur que peut stocker le type de données bigint.

Est-ce le cas avec les autres types de données ?

Rien de surprenant par rapport au comportement par défaut.
En revanche le fait que la SEQUENCE ne commence pas à 1 comme avec les colonnes de type entier auxquelles on confère la propriété d’auto-incrémentation à l’aide de la clause IDENTITY est appréciable.

Avant de continuer à nous éclairer sur SEQUENCE, voyons comment connaître les propriétés d’un tel objet : la vue système sys.sequences est là pour cela :

Ce qui retourne :

Je passerai sur la description des colonnes jusqu’à maximum_value, et sur current_value puisque leur nom est suffisamment explicite.

La colonne is_cycling nous montre qu’il est possible de faire boucler la SEQUENCE, c’est à dire de la faire revenir à sa valeur de départ.
La colonne cache_size indique le nombre de valeurs qui est mise en cache. Nous verrons la notion de cache de SEQUENCE par la suite.
Enfin la colonne is_exhausted indique s’il est encore possible de générer de nouveaux nombres à partir de celle-ci.

On retrouve les objets SEQUENCE dans l’Explorateur d’Objets, avec les fonctionnalités accessibles par clic-droit que l’on connaît :

Après un clic sur Propriétés :

On obtient la fenêtre suivante :

On peut aussi créer une SEQUENCE décrémentielle, simplement en spécifiant un incrément négatif :

On peut également changer l’incrément en cours de route à l’aide d’une instruction ALTER SEQUENCE :

Il est également possible, comme le suggère la colonne maximum_value de la vue sys.sequences, mettre une valeur maximale à cette séquence.
Il faut bien sûr dans ce cas que la valeur maximale de la séquence prenne en compte la valeur de départ, sinon celle-ci ne serait pas générable :

Ici comme la séquence est décrémentielle, SQL Server rejette l’instruction ALTER SEQUENCE puisque nous avions spécifié que la SEQUENCE démarre à zéro.

Si nous changeons par MINVALUE :

Voici un message d’avertissement intéressant : nous n’avons pas spécifié de valeur pour la taille du cache de la SEQUENCE, mais SQL Server en a mis une par défaut …
J’ai tenté de savoir quelle est la taille du cache par défaut, et comment SQL Server stocke celle-ci en utilisant une connexion d’administrateur dédiée (DAC), mais il semble que SQL Server réalise cela dans des tables internes.
Si quelqu’un découvre cela, merci de le poster en commentaire

Poursuivons avec FORMAT(), qui est une extension de CONVERT(), puisqu’elle est plus ouverte aux différentes cultures … et beaucoup plus !

Tout d’abord, la syntaxe :

FORMAT (valeur, format [, culture ])

Comme avec PARSE() :

– la nouveauté c’est qu’on peut formater une valeur suivant une culture (33 cultures disponibles !)
– les types supportés par cette fonction : bigint, int, smallint, tinyint, decimal, numeric, float, real, smallmoney, money, date, time, datetime, smalldatetime, datetime2 et datetimeoffset.
– on ne peut pas utiliser PARSE() pour exécuter une requête sur un serveur distant, car celle-ci dépend du .NET Framework 3.5 SP1 , et que rien ne garantit qu’il est présent sur la machine distante.

On remarquera que les types de données de chaînes de caractère, comme pour PARSE(), ne sont pas supportés.
Dès lors, on ne peut pas s’attendre à pouvoir passer une date au format ISO dans une chaîne de caractères, et que cela fonctionne :

=> Formatage des dates

Commençons avec quelques exemples sur les dates, qui sont généralement assez recherchés.
Voyons sans la culture d’abord :

Et avec la culture :

On peut maintenant apprendre les bases d’une langue tout en codant

En revanche le formatage composite n’est pas directement supporté :

Attention donc, car les lettres qui correspondent à des parties de date sont automatiquement remplacées, sans qu’une erreur ne soit levée.

Essayons d’éviter ces lettres :

Mais il s’agit là d’un jeu dangereux.
Voyons si on peut les échapper. Est-ce que le classique anti-slash va fonctionner ?

Il faut reconnaître que c’est assez tortueux pour ne pas dire spaghetti.
Par extension, on pourra créer une fonction en T-SQL qui effectue automatiquement l’échappement de ces caractères …

=> Examinons maintenant les formats raccourcis :

Attention donc à la casse dans les formats !
On notera que le zéro non-significatif disparaît au format Français, mais demeure au format Anglo-saxon.

J’ai trouvé ceux-ci à tâtons. Voyons les dans leur ensemble :

On voit donc que pour le formatage de données :

– numériques, la casse du format court n’a pas d’importance
– numériques, on peut ajouter un chiffre au format court qui indique soit le nombre de décimales, soit la largeur de la mantisse
– numériques de devise, la culture change bien évidemment le résultat
– de date, la casse est importante, de même que la culture

=> Étudions les devises plus en détails :

On voit que les formats de devises sont rigoureusement respectés, notamment en ce qui concerne les points et les virgules : les anglo-saxons utilisent la virgule comme séparateur des puissances de 10 multiples de 3, alors que les Latins utilisent le point; et inversement pour les parties décimales.
De même la prise en compte des pays membres de la Zone Euro ont tous leur devise préfixée ou suffixée par le symbole €, alors que le Royaume-Uni et la Suède, qui n’en sont pas membres, ont bien évidemment conservé respectivement les symboles de la Livre Sterling et de la Couronne Suédoise.

Une petite remarque : en Arabe, la notation retournée par SQL Server n’est strictement identique à ce que l’on observe rien qu’en collant cette valeur de fenêtre de résultats dans la fenêtre de requêtes de SQL Server Management Studio :

J’ai essayé de faire traduire automatiquement par Google Translate, mais le résultat retourné est R.. Q. 1,234.56.
Si vous pouvez expliquer ce qui s’est passé, n’hésitez pas à poster un commentaire !

=> Les masques pour les valeurs numériques

Les masques permettent de spécifier le nombre de décimales pour une valeur numérique, et si l’on en a besoin, d’ajouter des symboles dans la valeur formatée à l’aide de la position :

Dans les colonnes exemple_2 et exemple_10, on a respectivement placé :

– une virgule avant les trois derniers chiffres de la partie entière de la valeur décimale
– un pipe avant les deux derniers chiffres de la partie entière de la valeur décimale

Dans la colonne exemple_11, l’antislash étant un caractère d’échappement, il y a donc un symbole dièse qui sera intercalé entre le dernier et l’avant-dernier chiffre de la partie entière de la valeur décimale.

De la même façon que ce que nous avons vu avec les formats courts, on peut aussi préciser le nombre de chiffres significatifs de la partie décimale d’une telle valeur.
Si le nombre de chiffres significatifs de la partie décimale :

– est plus petit que celui de la valeur passée en paramètre, alors la valeur formatée est arrondie
– est plus grand que celui de la valeur passée en paramètre, alors la valeur formatée est suivie d’autant de zéros que la différence entre le nombre de chiffres significatifs de la partie décimale et le nombre de chiffres de la partie décimale du masque de formatage.

Bon FORMATage de données à tous !

Si c’est efficace et que l’on peut comprendre pourquoi Microsoft a décidé de ne plus inclure les fichiers d’aide dans le package d’installation de SQL Server (poids plus léger, simplicité de maintenance de l’aide, et tous les développeurs et DBAs en en général accès à Internet), que se passe-t-il si l’on a besoin de consulter la documentation de SQL Server sur un serveur de production, qui n’a généralement pas d’accès à Internet pour des raisons de sécurité ? C’est aussi pratique pour les favoris, qui permettent de consulter la syntaxe d’une commande fréquemment utilisée mais dont on ne retient pas forcément toutes les options et subtilités.

On peut toujours installer celle-ci localement. Voyons comment procéder …

Il faut d’abord paramétrer SQL Server Management Studio 2012 pour indiquer que l’on préfère consulter l’aide localement.
Pour ce faire, il suffit de cliquer sur Help puis Manage Help Settings :

Puis de choisir entre l’aide locale et l’aide en ligne :

Ce qui sera fait très simplement après avoir changé le bouton radio sur :

Il faut ensuite procéder au téléchargement des fichiers :

La recherche de fichiers d’aide s’effectue en quelques secondes :

et l’on obtient la liste de nombreuses aides de produits Microsoft :

Il suffit de faire défiler jusqu’à trouver celle de SQL Server, et de cliquer sur Add :

S’ensuit le téléchargement qui dure quelques secondes :

Après un clic sur le bouton Finish, on peut quitter :

Voyons maintenant comment tout cela se présente : essayons de consulter l’aide de CREATE TABLE :

Après avoir surligné l’instruction et pressé F1, l’application Help Viewer démarre (c’est très rapide).
L’application demeure accessible à partir de zone de notification (regardez bien en bas à droite de la capture ci-dessous) :

L’application s’ouvre directement sur la documentation de l’instruction CREATE TABLE :

Et on retrouve le bouton d’ajout aux favoris :

La recherche de la documentation d’autres instructions se fait tout aussi aisément et rapidement : voyons CREATE INDEX :

Toutes les instructions contenant les deux mots apparaissent dans le panneau de navigation, à gauche, avec un extrait du début de la documentation de chacune des instructions trouvées :

Cliquons sur la première, puisque c’est celle qui nous intéresse :

Documentez-vous bien, car les ajouts de fonctionnalités et nouvelles fonctions T-SQL dans SQL Server 2012 sont nombreux !

ElSüket

Commençons avec la fonction PARSE() …

La syntaxe d’utilisation de cette fonction est la suivante :

PARSE('<uneValeur>' AS <data_type> [USING '<culture>'])

La nouveauté c’est la possibilité de formater une valeur suivant une culture, et ce n’est pas moins de 33 cultures qui sont disponibles !
De façon générale, cette fonction est une extension de ce que l’on peut faire avec CONVERT().
Rappelons dans les deux cas qu’il s’agit de fonctions de formatage de données.

On notera que :

– data_type est limité aux types suivants : bigint, int, smallint, tinyint, decimal, numeric, float, real, smallmoney, money, date, time, datetime, smalldatetime, datetime2 et datetimeoffset.

– On ne peut pas utiliser PARSE() pour exécuter une requête sur un serveur distant, car celle-ci dépend du .NET Framework 3.5 SP1 , et que rien ne garantit qu’il est présent sur la machine distante.

Faisons quelques essais !

SELECT PARSE ('100.000' AS int)

Alors qu’un SELECT CONVERT(int, '100.000') :

Essayons un SELECT PARSE('Lundi 16 Avril 2012' AS datetime USING 'fr-FR')

Voyons au format Anglo-Saxon : SELECT PARSE('Monday 16 April 2012' AS datetime USING 'en-US')

Quid du format que l’on nous a donné à l’école ? SELECT PARSE('Monday, April 16 2012' AS datetime USING 'en-US')

En revanche SELECT PARSE('Monday, April 16th 2012' AS datetime USING 'en-US')

Essayons SELECT PARSE('April, 16 2012' AS datetime USING 'en-US')

Voyons avec une date du calendrier Grégo-Thaï : en effet, le calendrier Grégo-Thaï à 543 ans d’avance sur le calendrier Grégorien :
SELECT PARSE(N'16 เมษายน 2555' AS datetime USING 'Th-TH')

Et avec des variables ?

Et dans une table :

Vous vous demandez s’il sera possible de retourner une valeur décimale avec le symbole de la devise suivant une culture ? la réponse est oui : avec la fonction FORMAT(), que nous verrons au prochain épisode

Bon formatage de données !

ElSüket

La fenêtre du journal s’ouvre alors :

Et ce nouveau lien nous permet d’accéder directement à la définition du job, ce qui n’était pas la cas jusqu’à SQL Server Management Studio 2008 :

Bonne gestion des jobs !

@++