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.

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 !