Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Avantages des performances de SQL Server 2016 Enterprise Edition

Le 16 novembre 2016, Microsoft a annoncé des modifications très importantes pour SQL Server 2016 Standard Edition, qui ont été implémentées dans SQL Server 2016 Service Pack 1 (Build 13.0.4001.0). De nombreuses fonctionnalités très utiles liées à la programmabilité qui n'étaient auparavant disponibles que dans Enterprise Edition seront désormais disponibles dans Standard Edition (ainsi que dans Web Edition et même Express Edition).

Une fois que vous avez une application de base de données utilisant SQL Server 2016 Standard Edition Service Pack 1 (ou même une édition inférieure), vous pouvez simplement effectuer une mise à niveau d'édition vers Enterprise Edition pour obtenir encore plus d'évolutivité et de performances, en profitant des limites de licence plus élevées pour les sockets. , les cœurs et la mémoire dans Enterprise Edition, comme détaillé ici.

Vous bénéficierez également des nombreux autres avantages intrinsèques en termes de performances présents dans Enterprise Edition, ainsi que de multiples améliorations de la gérabilité qui vous facilitent la vie en tant que DBA.

Index de magasin de colonnes

Si vous utilisez des index Columnstore, vous bénéficiez automatiquement des avantages de performances suivants lorsque vous utilisez Enterprise Edition :

  • Réduction agrégée : Cette fonctionnalité de performances offre souvent un gain de performances de requête 2X-4X en poussant les agrégats qualifiants vers le nœud SCAN, ce qui réduit le nombre de lignes sortant de cet itérateur.
  • Création/Reconstruction d'index : Enterprise Edition peut créer/reconstruire des index columnstore avec plusieurs cœurs de processeur, tandis que Standard Edition n'utilise qu'un seul cœur de processeur. Cela a un effet assez significatif sur les temps écoulés pour ces opérations, en fonction de votre matériel.
  • Agrégats locaux : Enterprise Edition peut utiliser des agrégations locales pour filtrer le nombre de lignes sortant d'un nœud SCAN, réduisant ainsi la quantité de travail devant être effectuée par les nœuds de requête suivants. Vous pouvez le confirmer en recherchant l'attribut "ActualLocallyAggregatedRows" dans le XML du plan d'exécution de la requête.
  • Optimisations SIMD (Single Instruction Multiple Data) : Cette fonctionnalité utilise un ensemble d'instructions matérielles capables de traiter un tableau de données en une seule instruction, ce qui accélère considérablement les opérations d'agrégation. Ces instructions matérielles sont présentes sur tous les processeurs modernes (qui prennent en charge AVX), mais elles ne sont utilisées que par Enterprise Edition.
  • Réduction du prédicat de chaîne : Cette fonction de performance peut améliorer les performances des requêtes utilisant des prédicats sur des colonnes de chaîne en poussant ces prédicats vers le nœud SCAN. Cela peut réduire considérablement la quantité de travail qui doit être effectuée par les nœuds suivants.
  • Degré de parallélisme : Les requêtes en mode batch sont limitées à MAXDOP =2 sur l'édition Standard. Enterprise Edition peut utiliser tous les cœurs présents pour l'instance. Cela peut être très important pour les requêtes plus importantes sur du matériel de serveur moderne et typique.
  • Limites de mémoire : Le pool d'objets Columnstore est limité à 32 Go par instance sur l'édition Standard. Enterprise Edition n'a aucune limitation de mémoire pour le pool d'objets Columnstore.

Afin de tester ces assertions de performances, j'ai effectué des tests assez simples sur la base de données Microsoft ContosoRetailDW sur mon poste de travail Intel Core i7-6700K. J'ai installé deux instances nommées de SQL Server 2016 SP1, l'une utilisant Standard Edition et l'autre utilisant Developer Edition (qui équivaut à Enterprise Edition).

Toutes les configurations et propriétés au niveau de l'instance et au niveau de la base de données sont identiques entre les deux instances, et les emplacements des fichiers de base de données utilisateur et tempdb se trouvent dans des répertoires distincts sur le même périphérique de stockage flash distinct pour chaque instance. Le niveau de compatibilité de la base de données a été modifié à 130 dans les deux cas, et la configuration et le matériel Windows sous-jacents sont les mêmes pour les deux instances. La seule différence ici est l'édition de chaque instance.

Le premier test est une requête simple (adaptée de Niko Neugebauer) qui permet à SQL Server 2016 d'utiliser le refoulement agrégé sur la table FactOnlineSales. Les résultats sont présentés dans le tableau 1.

Édition Temps écoulé (ms)
Édition standard 30
Édition développeur 1
Décalage horaire 29
% d'amélioration 96,7 %

Tableau 1 :Comparaison de refoulement agrégé

Le test suivant consiste à chronométrer le temps nécessaire pour créer un index cluster columnstore sur la table FactOnlineSales de 12,6 millions de lignes. Les résultats sont présentés dans le tableau 2.

Édition Temps écoulé (ms)
Édition standard 42 197
Édition développeur 14 384
Décalage horaire 27 813
% d'amélioration 65,9 %

Table 2 : Comparaison de l'index clustered Columnstore

Le test suivant consiste à chronométrer le temps nécessaire pour reconstruire un index cluster columnstore sur la même table FactOnlineSales. Les résultats sont présentés dans le tableau 3.

Édition Temps écoulé (ms)
Édition standard 33 105
Édition développeur 11 460
Décalage horaire 21 645
% d'amélioration 65,4 %

Table 3 :Reconstruire la comparaison d'index clustered Columnstore

Le test suivant est une autre requête simple qui permet à SQL Server 2016 d'utiliser l'agrégation locale sur la table FactOnlineSales. Les résultats sont présentés dans le tableau 4.

Édition Temps écoulé (ms)
Édition standard 122
Édition développeur 83
Décalage horaire 39
% d'amélioration 32,0 %

Tableau 4 :Comparaison des agrégations locales

Le test suivant est une autre requête simple qui permet à SQL Server 2016 d'utiliser le refoulement de prédicat de chaîne sur les tables FactOnlineSales et DimPromotion. Les résultats sont présentés dans le tableau 5.

Édition Temps écoulé (ms)
Édition standard 2 683
Édition développeur 1 221
Décalage horaire 1 466
% d'amélioration 54,6 %

Tableau 5 :Comparaison de la liste déroulante des prédicats de chaîne

Ce ne sont là que quelques exemples simples des avantages de performances intégrés pour les index Columnstore dans SQL Server 2016 Enterprise Edition par rapport à SQL Server 2016 Standard Edition sur le même matériel. Si vous voulez vraiment vous plonger dans les index Columnstore (qui peuvent être une fonctionnalité très efficace pour certaines charges de travail), vous devriez mettre en signet et lire la longue série de publications de Niko Neugebauer sur columnstore.net.

Performances DBCC CHECKDB

Une autre amélioration des performances de gestion présente sur SQL Server 2016 Enterprise Edition est la performance de DBCC CHECKDB. Sur Standard Edition, DBCC CHECKDB n'utilise qu'un seul cœur de processeur, alors qu'il peut utiliser tous les cœurs disponibles sur Enterprise Edition. Ce comportement est inchangé par rapport aux versions précédentes de SQL Server. SQL Server 2016 vous permet de restreindre le nombre de cœurs que DBCC CHECKDB peut utiliser avec une nouvelle option WITH (MAXDOP =x).

L'exécution de DBCC CHECKDB avec l'option WITH PHYSICAL_ONLY sur une base de données un peu plus grande (environ 38 Go) que j'ai, a donné les résultats indiqués dans le tableau 6.

Édition Temps écoulé (ms)
Édition standard 58 492
Édition développeur 24 897
Décalage horaire 33 595
% d'amélioration 57,4 %

Tableau 6 :Comparaison DBCC CHECKDB AVEC PHYSICAL_ONLY

L'exécution d'un DBCC CHECKDB standard sur la même base de données a donné les résultats indiqués dans le tableau 7.

Édition Temps écoulé (ms)
Édition standard 435 039
Édition développeur 119 767
Décalage horaire 315 272
% d'amélioration 72,5 %

Tableau 7 :Comparaison DBCC CHECKDB

Un facteur très important dans les performances de DBCC CHECKDB est la performance de lecture séquentielle de tous les LUN où se trouvent vos fichiers de données de base de données. Vous pouvez facilement vérifier cela en exécutant une commande BACKUP DATABASE sur un périphérique NUL (en veillant à utiliser les options COPY_ONLY et NO_COMPRESSION). Cela vous montrera vos performances de lecture séquentielle effectives, comme le montre cet exemple de mon poste de travail :

BACKUP DATABASE a traité avec succès 5048514 pages en 16,115 secondes (2447,502 Mo/sec).

Gardez à l'esprit que tous ces tests ont été effectués sur un seul processeur de bureau quadricœur. Un serveur multi-socket avec beaucoup plus de cœurs de processeur au total montrera encore plus d'amélioration des performances dans bon nombre de ces tests.

Le but de tout cela est de montrer quelques exemples tangibles des améliorations de performances que vous pouvez voir, simplement en mettant à niveau de SQL Server 2016 Standard Edition SP1 vers SQL Server 2016 Enterprise Edition SP1, sur le même matériel, sans apporter de modifications à la base de données ou à l'application. . Cette liste n'est en aucun cas exhaustive, car il existe également de nombreux autres avantages.