Limites de mémoire dans SQL Server 2016 SP1

Il y a quelques semaines, j'ai fait toute une histoire à propos de SQL Server 2016 Service Pack 1. De nombreuses fonctionnalités auparavant réservées à Enterprise Edition ont été déployées dans des éditions inférieures, et j'étais ravi d'apprendre ces changements.

Néanmoins, je vois quelques personnes qui sont, disons, un peu moins excitées que moi.

Il est important de garder à l'esprit que les changements ici n'étaient pas destinés à fournir une parité complète des fonctionnalités dans toutes les éditions ; ils avaient pour but spécifique de créer une surface de programmation plus cohérente. Désormais, les clients peuvent utiliser des fonctionnalités telles que l'OLTP en mémoire, Columnstore et la compression sans se soucier de la ou des éditions ciblées, mais uniquement de leur capacité à évoluer. Plusieurs fonctionnalités de sécurité qui ne semblaient pas vraiment avoir quelque chose à voir avec l'édition sont également ouvertes. Celui que j'ai le moins compris était Always Encrypted; Je ne comprenais pas pourquoi seuls les clients Enterprise avaient besoin de protéger des éléments tels que les données de carte de crédit. Transparent Data Encryption est toujours réservé aux entreprises, sur les versions antérieures à SQL Server 2019, car il ne s'agit pas vraiment d'une fonctionnalité de programmabilité (qu'elle soit activée ou non).

Qu'y a-t-il vraiment dedans pour les clients de l'édition Standard ?

Je pense que le plus gros problème que la plupart des gens ont est que la mémoire maximale de l'édition Standard est toujours limitée à 128 Go. Ils regardent cela et disent :"Merci, merci pour toutes les fonctionnalités, mais la limite de mémoire signifie que je ne peux pas vraiment les utiliser."

Cependant, les changements de surface apportent des opportunités d'amélioration des performances, même si ce n'était pas leur intention initiale (ou même si c'était le cas – je n'étais à aucune de ces réunions). Examinons de plus près une petite section des petits caractères (de la documentation officielle) :

Limites de mémoire pour Enterprise/Standard dans SQL Server 2016 SP1

Le lecteur avisé remarquera que la formulation de la limite du pool de tampons a changé, passant de :

À :

Ceci est une meilleure description de ce qui se passe réellement dans l'édition Standard :une limite de 128 Go pour le pool de mémoire tampon uniquement, et d'autres réservations de mémoire peuvent être au-delà de cela (pensez aux pools comme le cache du plan). Ainsi, en effet, un serveur Standard Edition pourrait utiliser 128 Go de pool de mémoire tampon, alors la mémoire maximale du serveur pourrait être plus élevée et prendre en charge plus de mémoire utilisée pour d'autres réservations. De même, Express Edition est désormais correctement documenté pour utiliser 1,4 Go pour le pool de mémoire tampon.

Vous remarquerez peut-être également une formulation très spécifique dans cette colonne la plus à gauche (par exemple, "par instance" et "par base de données") pour les fonctionnalités qui sont exposées dans l'édition Standard pour la première fois. Pour être plus précis :

• L'instance est limitée à 128 Go de mémoire pour le pool de mémoire tampon .
• L'instance peut avoir un élément supplémentaire 32 Go alloués aux objets Columnstore, au-delà de la limite du pool de mémoire tampon.
• Chaque base de données utilisateur sur l'instance peut avoir un supplémentaire 32 Go alloués aux tables à mémoire optimisée, au-delà de la limite du pool de mémoire tampon.

Et pour être parfaitement clair :Ces limites de mémoire pour ColumnStore et OLTP en mémoire ne sont PAS soustraites de la limite du pool de mémoire tampon , tant que le serveur dispose de plus de 128 Go de mémoire disponible. Si le serveur a moins de 128 Go, vous verrez ces technologies entrer en concurrence avec la mémoire du pool de mémoire tampon, et en fait être limitées à un % de la mémoire maximale du serveur. Plus de détails sont disponibles dans cet article de Parikshit Savjani de Microsoft.

Je n'ai pas de matériel sous la main pour tester l'étendue de cela, mais si vous aviez une machine avec 256 Go ou 512 Go de mémoire, vous pourriez théoriquement tout utiliser avec une seule instance Standard Edition, si vous pouviez - par exemple - répartir votre In -Données de mémoire sur les bases de données en <=32 Go de morceaux, pour un total de 128 Go + (32 Go * (# de bases de données)). Si vous vouliez utiliser ColumnStore au lieu de In-Memory, vous pourriez répartir vos données sur plusieurs instances, ce qui vous donnerait (128 Go + 32 Go) * (nombre d'instances). Et vous pouvez combiner ces stratégies pour ((128 Go + 32 Go ColumnStore) * (# d'instances)) + (32 Go In-Memory * (# de bases de données * # d'instances)).

Je ne suis pas sûr que diviser vos données de cette manière soit pratique pour votre application. Je suggère seulement que c'est possible. Certains d'entre vous font peut-être déjà certaines de ces choses pour tirer un meilleur parti de l'Édition Standard sur des serveurs dotés de plus de 128 Go de mémoire.

Avec ColumnStore en particulier, en plus d'être autorisé à utiliser 32 Go en plus du pool de mémoire tampon, gardez à l'esprit que la compression que vous pouvez obtenir ici signifie que vous pouvez souvent tenir beaucoup plus dans cette limite de 32 Go que vous ne le pourriez avec les mêmes données en traditionnel magasin de ligne. Et si vous ne pouvez pas utiliser ColumnStore pour une raison quelconque (ou s'il ne tient toujours pas dans 32 Go), vous pouvez désormais implémenter la compression traditionnelle de page ou de ligne - cela ne vous permettra peut-être pas d'adapter l'intégralité de votre base de données au pool de mémoire tampon de 128 Go, mais cela pourrait permettre à plus de vos données d'être en mémoire à tout moment.

Des choses similaires sont possibles dans Express (à une échelle inférieure), où vous pouvez disposer de 1,4 Go pour le pool de mémoire tampon, mais d'environ 352 Mo supplémentaires par instance pour ColumnStore et d'environ 352 Mo par base de données pour l'OLTP en mémoire.

Mais Enterprise Edition a encore beaucoup d'avantages

Il existe de nombreux autres différenciateurs pour maintenir l'intérêt pour Enterprise Edition, mis à part les limites de mémoire illimitées tout autour - des reconstructions en ligne et des analyses de manège aux groupes de disponibilité complets et à tous les droits de virtualisation auxquels vous pouvez vous serrer la main. Même les index ColumnStore ont des améliorations de performances bien définies réservées à Enterprise Edition.

Donc, ce n'est pas parce qu'il existe certaines techniques qui vous permettront de tirer le meilleur parti de l'édition Standard qu'elle s'adaptera comme par magie pour répondre à vos besoins de performances. Comme mes autres articles sur "le faire avec un budget" (par exemple, le partitionnement et les secondaires lisibles), vous pouvez certainement passer du temps et des efforts à trouver une solution, mais cela ne vous mènera que très loin. Le but de cet article était simplement de démontrer que vous pouvez aller plus loin avec l'édition Standard en 2016 SP1 que vous n'auriez jamais pu le faire auparavant.