Arbeitsspeicherbeschränkungen in SQL Server 2016 SP1

Vor ein paar Wochen habe ich eine ziemlich große Sache über SQL Server 2016 Service Pack 1 gemacht. Viele Funktionen, die zuvor der Enterprise Edition vorbehalten waren, wurden für niedrigere Editionen freigegeben, und ich war begeistert, von diesen Änderungen zu erfahren.

Trotzdem sehe ich ein paar Leute, die, sagen wir mal, etwas weniger aufgeregt sind als ich.

Es ist wichtig zu bedenken, dass die Änderungen hier nicht dazu gedacht waren, eine vollständige Feature-Parität über alle Editionen hinweg bereitzustellen; Sie dienten dem speziellen Zweck, eine konsistentere Programmieroberfläche zu schaffen. Jetzt können Kunden Funktionen wie In-Memory OLTP, Columnstore und Komprimierung nutzen, ohne sich Gedanken über die angestrebte(n) Edition(en) machen zu müssen – nur darüber, wie gut sie skalieren. Einige Sicherheitsfunktionen, die nicht wirklich etwas mit der Edition zu tun zu haben schienen, werden ebenfalls geöffnet. Am wenigsten verstand ich Always Encrypted; Ich konnte nicht verstehen, warum nur Unternehmenskunden Dinge wie Kreditkartendaten schützen mussten. Die transparente Datenverschlüsselung ist in Versionen vor SQL Server 2019 immer noch nur für Unternehmen verfügbar, da es sich nicht wirklich um eine Programmierfunktion handelt (entweder aktiviert oder nicht).

Was ist also wirklich drin für Kunden der Standard Edition?

Ich denke, das größte Problem, das die meisten Leute haben, ist, dass der maximale Speicher in der Standard Edition immer noch auf 128 GB begrenzt ist. Sie sehen sich das an und sagen:„Mensch, danke für all die Funktionen, aber die Speicherbegrenzung bedeutet, dass ich sie nicht wirklich nutzen kann.“

Die Oberflächenänderungen bringen jedoch Möglichkeiten zur Leistungsverbesserung mit sich, auch wenn dies nicht ihre ursprüngliche Absicht war (oder selbst wenn es so war – ich war in keinem dieser Meetings). Werfen wir einen genaueren Blick auf einen kleinen Abschnitt des Kleingedruckten (aus den offiziellen Dokumenten):

Speicherlimits für Enterprise/Standard in SQL Server 2016 SP1

Der aufmerksame Leser wird feststellen, dass sich der Wortlaut des Pufferpoollimits geändert hat, von:

An:

Dies ist eine bessere Beschreibung dessen, was wirklich in der Standard Edition passiert:ein 128-GB-Limit nur für den Pufferpool, und andere Speicherreservierungen können darüber hinausgehen (denken Sie an Pools wie den Plan-Cache). Ein Standard Edition-Server könnte also tatsächlich 128 GB Pufferpool verwenden, dann könnte der maximale Serverspeicher höher sein und mehr Speicher unterstützen, der für andere Reservierungen verwendet wird. In ähnlicher Weise ist die Express Edition jetzt ordnungsgemäß dokumentiert, um 1,4 GB für den Pufferpool zu verwenden.

Möglicherweise bemerken Sie auch einige sehr spezifische Formulierungen in dieser Spalte ganz links (z. B. „pro Instanz“ und „pro Datenbank“) für die Funktionen, die zum ersten Mal in der Standard Edition bereitgestellt werden. Genauer gesagt:

• Die Instanz ist auf 128 GB Arbeitsspeicher für den Pufferpool beschränkt .
• Die Instanz kann eine zusätzliche haben 32 GB, die Columnstore-Objekten über das Pufferpoollimit hinaus zugewiesen werden.
• Jede Benutzerdatenbank auf der Instanz kann eine zusätzliche haben 32 GB für speicheroptimierte Tabellen über das Pufferpoollimit hinaus.

Und um es ganz klar zu sagen:Diese Speichergrenzen für ColumnStore und In-Memory OLTP werden NICHT von der Grenze des Pufferpools abgezogen , solange der Server über mehr als 128 GB Arbeitsspeicher verfügt. Wenn der Server über weniger als 128 GB verfügt, konkurrieren diese Technologien mit dem Pufferpoolspeicher und sind tatsächlich auf einen Prozentsatz des maximalen Serverspeichers begrenzt. Weitere Details finden Sie in diesem Beitrag von Parikshit Savjani von Microsoft.

Ich habe keine Hardware zur Hand, um das Ausmaß davon zu testen, aber wenn Sie eine Maschine mit 256 GB oder 512 GB Speicher hätten, könnten Sie theoretisch alles mit einer einzigen Standard Edition-Instanz verwenden, wenn Sie beispielsweise Ihre In - Speicherdaten über Datenbanken hinweg in Blöcken von <=32 GB, für insgesamt 128 GB + (32 GB * (Anzahl der Datenbanken)). Wenn Sie ColumnStore anstelle von In-Memory verwenden möchten, können Sie Ihre Daten auf mehrere Instanzen verteilen, wodurch Sie (128 GB + 32 GB) * (Anzahl der Instanzen) erhalten. Und Sie könnten diese Strategien für ((128 GB + 32 GB ColumnStore) * (Anzahl der Instanzen)) + (32 GB In-Memory * (Anzahl der Datenbanken * Anzahl der Instanzen)) kombinieren.

Ob das Aufteilen Ihrer Daten auf diese Weise für Ihre Anwendung praktikabel ist, bin ich mir nicht sicher; Ich schlage nur vor, dass es möglich ist. Einige von Ihnen tun möglicherweise bereits einige dieser Dinge, um die Standard Edition auf Servern mit mehr als 128 GB Arbeitsspeicher besser zu nutzen.

Denken Sie insbesondere bei ColumnStore daran, dass Sie zusätzlich zum Pufferpool 32 GB verwenden dürfen, und denken Sie daran, dass die Komprimierung, die Sie hier erhalten können, bedeutet, dass Sie oft viel mehr in dieses 32-GB-Limit passen als mit den gleichen Daten in herkömmlicher Weise Reihenladen. Und wenn Sie ColumnStore aus irgendeinem Grund nicht verwenden können (oder es immer noch nicht in 32 GB passt), können Sie jetzt traditionelle Seiten- oder Zeilenkomprimierung implementieren – dies erlaubt Ihnen möglicherweise nicht, Ihre gesamte Datenbank in den 128-GB-Pufferpool zu passen, aber Dadurch können jederzeit mehr Ihrer Daten im Speicher sein.

Ähnliche Dinge sind in Express (in einem geringeren Maßstab) möglich, wo Sie 1,4 GB für den Pufferpool haben können, aber zusätzlich ca. 352 MB pro Instanz für ColumnStore und ca. 352 MB pro Datenbank für In-Memory-OLTP.

Aber die Enterprise Edition hat noch viele Vorteile

Es gibt viele andere Unterscheidungsmerkmale, um das Interesse an der Enterprise Edition aufrechtzuerhalten, abgesehen von allumfassenden unbegrenzten Speicherbeschränkungen – von Online-Neuaufbauten und Karussell-Scans bis hin zu vollständigen Verfügbarkeitsgruppen und all den Virtualisierungsrechten, an denen Sie einen Stock schütteln können. Sogar ColumnStore-Indizes haben klar definierte Leistungsverbesserungen, die der Enterprise Edition vorbehalten sind.

Nur weil es einige Techniken gibt, mit denen Sie mehr aus der Standard Edition herausholen können, bedeutet das nicht, dass sie sich auf magische Weise an Ihre Leistungsanforderungen anpassen lässt. Wie in meinen anderen Beiträgen zum Thema "Kostengünstiges Arbeiten" (z. B. Partitionieren und lesbare Sekundärdateien) können Sie sicherlich Zeit und Mühe aufwenden, um eine Lösung zusammenzubasteln, aber Sie werden nur so weit kommen. Der Zweck dieses Beitrags war einfach zu demonstrieren, dass Sie mit der Standard Edition in 2016 SP1 weiter kommen als je zuvor.