数週間前、私はSQL Server 2016 Service Pack 1についてかなり大したことをしました。以前はEnterpriseEdition用に予約されていた多くの機能が下位版に解き放たれ、これらの変更について学ぶことに夢中になりました。
それでも、私より少し興奮していない人が何人かいます。
ここでの変更は、すべてのエディションで完全な機能の同等性を提供することを意図したものではないことに注意してください。それらは、より一貫性のあるプログラミング表面積を作成するという特定の目的のためのものでした。これで、お客様は、対象となるエディションを気にすることなく、インメモリOLTP、列ストア、圧縮などの機能を使用できます。エディションとはまったく関係がないように思われるいくつかのセキュリティ機能も公開されています。私が最も理解していなかったのはAlwaysEncryptedでした。なぜエンタープライズの顧客だけがクレジットカードデータのようなものを保護する必要があるのか理解できませんでした。透過的データ暗号化は、SQL Server 2019より前のバージョンでは、エンタープライズ専用です。これは、実際にはプログラマビリティ機能ではないためです（オンかどうかにかかわらず）。
では、Standard Editionのお客様にとって実際には何が含まれているのでしょうか？
ほとんどの人が抱えている最大の問題は、StandardEditionの最大メモリがまだ128GBに制限されていることだと思います。彼らはそれを見て、「ねえ、すべての機能に感謝しますが、メモリ制限は私がそれらを実際に使用できないことを意味します」と言います。
ただし、表面積の変更は、それが本来の意図ではなかったとしても（または、そうだったとしても、私はそれらの会議のいずれにも参加していなかったとしても）、パフォーマンス向上の機会をもたらします。 （公式ドキュメントからの）細かい印刷物の小さなセクションを詳しく見てみましょう：
SQL Server2016SP1のEnterprise/Standardのメモリ制限
賢明な読者は、バッファプール制限の文言が次のように変更されたことに気付くでしょう：
メモリ：インスタンスごとに使用される最大メモリ宛先：
メモリ：最大バッファプールサイズ インスタンスごとこれは、Standard Editionで実際に何が起こるかについてのより良い説明です。バッファープールのみの128GBの制限、および他のメモリ予約はそれを超える可能性があります（プランキャッシュのようなプールを考えてください）。したがって、実際には、Standard Editionサーバーは128GBのバッファープールを使用でき、最大サーバーメモリはより高くなり、他の予約に使用されるより多くのメモリをサポートできます。同様に、Express Editionは、バッファプールに1.4GBを使用するように適切に文書化されています。
また、Standard Editionで初めて公開される機能について、左端の列（「インスタンスごと」や「データベースごと」など）に非常に具体的な表現があることに気付くかもしれません。具体的には：
- インスタンスは、バッファプール用に128GBのメモリに制限されています 。
- インスタンスは追加を持つことができます バッファプールの制限を超えて、列ストアオブジェクトに32GBが割り当てられました。
- インスタンス上の各ユーザーデータベースには、追加を含めることができます。 バッファプールの制限を超えて、メモリ最適化テーブルに32GBが割り当てられました。
そして明確にするために：ColumnStoreとインメモリOLTPのこれらのメモリ制限はバッファプール制限から差し引かれません 、サーバーに128GBを超えるメモリが使用可能である限り。サーバーの容量が128GB未満の場合、これらのテクノロジーがバッファープールメモリと競合し、実際には最大サーバーメモリの％に制限されていることがわかります。詳細については、MicrosoftのParikshitSavjaniからのこの投稿を参照してください。
この範囲をテストするのに便利なハードウェアはありませんが、256GBまたは512GBのメモリを搭載したマシンを使用している場合、理論的には、単一のStandard Editionインスタンスですべてを使用できます。たとえば、Inを拡張できます。 -データベース間で32GB未満のチャンクのメモリデータ、合計128GB +（32GB *（データベースの数））。インメモリの代わりにColumnStoreを使用する場合は、データを複数のインスタンスに分散して、（128GB + 32GB）*（インスタンスの数）を得ることができます。そして、これらの戦略を（（128GB + 32GB ColumnStore）*（インスタンス数））+（32GBインメモリ*（データベース数*インスタンス数））に組み合わせることができます。
この方法でデータを分割することがアプリケーションにとって実用的かどうかはわかりません。私はそれが可能であることを示唆しているだけです。 128GBを超えるメモリを搭載したサーバーでStandardEditionをより有効に活用するために、すでにこれらの作業を行っている方もいらっしゃるかもしれません。
特にColumnStoreでは、バッファープールに加えて32GBの使用が許可されていることに加えて、ここで取得できる圧縮により、従来の同じデータを使用した場合よりも多くの場合、32GBの制限に収まる可能性があることに注意してください。行ストア。また、何らかの理由でColumnStoreを使用できない場合（または32 GBに収まらない場合）、従来のページまたは行の圧縮を実装できるようになりました。これにより、データベース全体を128 GBのバッファープールに収めることができない場合がありますが、これにより、いつでもより多くのデータをメモリに保存できるようになる可能性があります。
Express（小規模）でも同様のことが可能です。バッファプール用に1.4GBを使用できますが、ColumnStoreの場合はインスタンスあたり最大352MB、インメモリOLTPの場合はデータベースごとに最大352MB追加されます。
しかし、EnterpriseEditionにはまだ多くの利点があります
オンライン再構築やメリーゴーランドスキャンから完全な可用性グループ、そしてあなたが固執することができるすべての仮想化権まで、あらゆる場所で無制限のメモリ制限を除いて、EnterpriseEditionに関心を持ち続ける他の多くの差別化要因があります。 ColumnStoreインデックスでさえ、EnterpriseEdition用に予約された明確に定義されたパフォーマンスの強化があります。
つまり、Standard Editionをさらに活用できるテクニックがあるからといって、パフォーマンスのニーズに合わせて魔法のように拡張できるわけではありません。 「予算内でそれを行う」（たとえば、パーティション分割と読み取り可能なセカンダリ）に関する他の投稿と同様に、ソリューションをまとめるのに時間と労力を費やすことができますが、これまでのところしか得られません。この投稿のポイントは、2016SP1のStandardEditionをこれまで以上に活用できることを示すことだけでした。