SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Server 2016 SP1 で変わる Edition 間の機能差

leave a comment

先日の Connect(); 2016 で SQL Server 2016 SP1 が発表されました。

アナウンス

機能紹介

ブログ
Tiger Team

SQL Server Database Engine

SQL Server Reporting Services Team

 
 
これにより SQL Server の Edition 間の機能差が大きく変わりましたので一度まとめてみたいと思います。
今まで、Enterprise Edition のみの機能を使用しているかを確認する際に、sys.dm_db_persisted_sku_features を使用することがありましたが、今回の SP1 の変更により、以降は、この DMV からではなく、SQL Server 2016 SP1: Things you should know の方法を使用する必要があるようです。

基本的なコンセプト


今回の SP1 の基本的なコンセプトとしては以下のようなものがあります。

SQL Server 2016 SP1: the latest innovations now available in every edition
With SQL Server 2016 SP1, Microsoft will include key enterprise-class features in every edition of SQL Server 2016. These include the same features available with SQL Server on Linux: In-Memory OLTP, Columnstore, RLS, and DDM. The impact of this change is in the separation of functional features from operational requirements. For example, with SP1, an organization can develop data applications using In-Memory OLTP and DDM, and deploy the same

SQL Server 2016 SP1 では、すべてのエディション (Web / Express / Standard / Enterprise) で、主要なエンタープライズクラスの機能が使用できるようになりました。
これは、SQL Server のエディション間で一貫性のある、プログラム開発を提供することをできることを目的としているようで、開発 / パフォーマンスに影響を与える機能のエディション間の差については、今回の SP1 で大幅に緩和がされています。
 

エディション間の機能差の基本的な考え


今回の SP1 でエディション間の機能差が大幅に緩和されました。
ただし、すべての機能差がなくなったかというと、答えは「No」となります。
一般的なエディション間の機能差としては、

  • CPU / メモリ等のリソースの制限 / スケールリミット
  • 高可用性機能
  • セキュリティ機能
  • 運用機能
  • ハイパフォーマンスのための処理最適化

というようなものがあるかと思いますが、SP1 を適用してもこの差はいくつか発生します。
詳細については、Features Supported by the Editions of SQL Server 2016 から確認できますが、本投稿でも軽くまとめてみたいと思います。
機能として Standard Edition で追加されたものも、性能面や運用面では、Enterprise Edition 固有のものがいくつか出てきます。
ちなみに私のスコープは DB エンジン回りなので、それ以外はまとめていません。
 

クロスボックスのスケールの制限


CPU / メモリサイズに関しては、SP1 を適用してもリミットは変わっていないようです。

エディション CPU メモリ
Enterprise OS の上限 OS の上限
Standard 4 ソケットまたは 24 コア 128 GB
Web 4 ソケットまたは 16 コア 64 GB
Express 1 ソケットまたは 4 コア 1GB

 
引き続きエディションの選定には、ハードウェアのスペックも考慮する必要が出てきます。
 

RDBMS の高可用性


SP1 を適用することで、すべてのエディションで、

を使用することができるようになります。
以下のような機能については (一部記載していないものもあります)、引き続き Enterprise エディションでのみ使用可能です。

  • オンラインのインデックス操作
  • オンラインのスキーマ変更
  • オンラインリストア

オンライン系の操作については、Enterprise Edition のみの機能となるため、オフラインにせずにインデックスのメンテナンスやデータベースのリストア等を実施する必要がある場合は、Enterprise Edition を選択する必要があります。
AlwaysOn 等が使用できるエディション等に変更はありませんので、高可用性環境を作成する場合については、今までと同じ考え方になるかと。
 
データベーススナップショットの利用
データベーススナップショットは読み取り専用の、特定タイミングの静的なデータベースとなりますが、これが全エディションで使用できるようになったことで大きなインパクトがあるものがあります。
それが、Standard Edition で使用することができる AlwaysOn 可用性グループの「基本的な可用性グループ」です
今まで「基本的な可用性グループ」では、セカンダリのデータベースを読み取りすることができませんでした。
今回の機能緩和でデータベーススナップショットが使用できるようになったことで、データベースミラーリングで利用することができていた、データベース ミラーリングとデータベース スナップショット (SQL Server) のシナリオを、基本的な可用性グループで実施することができるようになりました。
基本的な可用性グループで、セカンダリでデータベーススナップショットが取得できるかを試してみたのですが、実際に取得することができました。
以下の画像は、セカンダリレプリカでデータベーススナップショットを取得したものになります。
セカンダリレプリカでは、可用性データベースを直接参照することはできませんが、スナップショット経由では読み取りができていることができています。
image
SP1 を適用することで、セカンダリレプリカのスナップショットを利用したセカンダリ利用ができるようになったのは大きな変更ではないでしょうか。
 

RDBMS のスケーラビリティとパフォーマンス


SP1 を適用することで、すべてのエディションで、

  • インメモリ列ストア (列ストアインデックス)
  • インメモリ OLTP (メモリ最適化テーブル)
  • テーブルとインデックスのパーティション分割
  • データ圧縮 (行圧縮 / ページ圧縮)
  • 複数の Filestream コンテナー

を使用することができるようになります。
以下の機能に関しては Enterprise Edition のみ使用できる機能となります。

  • リソース ガバナー
  • パーティションテーブルの並列処理
  • NUMA 対応のラージ ページ メモリとバッファー配列の割り当て

リソースの使用制限や、パーティショニングされたテーブル / インデックスの複数コアを使用した処理効率化といった内容に関しては、Enterprise Edition でのみ使用可能ですので、高速な処理への対応については、引き続き Enterprise Edition を利用する必要ができてます。
 
インメモリ列ストア
Operational Analytics のシナリオの列ストアとインメモリ OLTP がフィーチャーされることが多いかと思いますが、個人的には、データ圧縮が全エディションで使用できるようになったのがかなりパフォーマンス面では大きいと思っています。
全エディションでパーティショニングが使用できますので、大量のデータ削除を伴うテーブルに関しては、パーティション単位の Truncate も有効に利用できそうです。
ただし、インメモリ列ストア に関しては、

  • Enterprise Edition 以外は、メモリのスケールリミットに対して 1/4 まで利用可能
    • Standard Edition : 32 GB
    • Web Editoin : 16 GB
    • Express Edition : 256 MB
  • インメモリ列ストアの並列度の上限が Standard : 2 /? Web , Express :1

というような制限があります。
使用できるデータサイズや、バッチ処理時の処理性能に関しては、差が出る形になるかと。
なお、列ストアのメモリのスケールリミットは、キャッシュとして使用できるリミットとなります。
列ストアインデックスのディスク上のデータサイズとしてはリミット以上のテーブルサイズとなることは可能ですが、メモリに制限があるエディションでは、行グループが 100 万行以下の小さなグループにまとめられることがあるようです。
Developers choice: Columnstore index in Standard and Express Edition with SQL Server 2016 (SP1)

Memory Limit: Columnstore index is restricted to 25% of max buffer pool limit of the edition (EXPRESS ~1GB, WEB-64GB and STD-128GB). It is possible that with memory limitations on your box, you may see compressed rowgroups with < 1 million rows. For example, on Standard edition, the object pool for columnstore index will have 32GB (25% of 128GB). This limit is for the entire instance. Given the memory limitation, you may find compressed rowgroups are of smaller size. To confirm this,? you can query the DMV Sys.dm_db_column_store_row_group_physical_stats to see if smaller rowgroup resulted because of memory pressure. Not having enough memory may slowdown your workload and you can fix this by upgrading your database to a higher edition of SQL Server.

 
Express Edition の場合、256 MB という制限がありますが、列ストアのデータとしては、256 MB 以上、ディスクに格納されていることが確認できます。
image
この状態で Enterprise / Standard / Express Edition の順で同一の DB / 同一のクエリを実行した後に列ストアのメモリ使用量を取得したものがこちらです。
Enterprise / Standard ではメモリの制限に達していないため、同一の値となっていますが、(同一の DB を使用していますので)、Express Edition では低い値を示していることが確認できます。
image
image
image
 
また、並列度についてですが、Features Supported by the Editions of SQL Server 2016 の情報だと

1 The max memory used by columnstore is limited 1/4 of the memory limit. The max degrees of parallelism is limited. The degrees of process parallelism (DOP) for an index build is limited to 2 DOP for the Standard Edition and 1 DOP for the Web and Express Editions.

と書かれていたので、インデックス作成時の並列度の制限かと思っていたら、これ、検索性能みたいですね。
上が、Standard、下が Enterprise で列ストアインデックスの作成を実施したものになります。
# 再構築時も同じ動作となります。
Standard Edition は並列インデックス操作ができないエディションとなっているので、maxdop 1 が強制的に設定されていますが、Enterprise Edition では並列インデックス操作が可能ですので、インデックス作成時の操作が、並列スキャンで行われていることが確認できます。
image
image
 
検索時についても比較してみます。
Standard Edition の環境は 8 コアの環境なのですが、2 スレッドしか使用されていないことが確認できます。
# この制限は列ストアに対してですので行ストアに関しては 2 スレッド以上使用できます。
image
image
列ストアインデックスの詳細な違いについては、以下に記載されており、上記の違いの他に、Standard では、プッシュダウンの集計が使用できなかったりと性能面では差が出る形となっています。
Developers choice: Columnstore index in Standard and Express Edition with SQL Server 2016 (SP1)
Columnstore Indexes ? part 91 (“SQL Server 2016 Standard Edition Limitations”)
上が Enterprise / 下が Standard に対して同じクエリを実行した結果となるのですが、プッシュダウンの利用有無によって、スキャン後の集計処理にわたるデータ件数が異なっていることが確認できます。
# 集計プッシュダウンできる場合は、データ検索時に集計をしながら検索なる動作のようで、計算に対してのコストが減ります。
image
image
 
In-Memory OLTP
In-Memory OLTP で利用可能なメモリサイズについては、以下の制限があります。

  • Enterprise Edition 以外は、メモリのスケールリミットに対して 1/4 まで利用可能
    • Standard Edition : 32 GB
    • Web Editoin : 16 GB
    • Express Edition : 256 MB

リミット以上のサイズのデータは、メモリ最適化テーブルに格納できません。
 
In-Memory OLTP については、テンポラリの領域、揮発性のあるデータとして使用する場合は、データサイズの予想がつけやすくメモリのスケールリミット内で収まる可能性があるかと思いますが、ある程度のサイズの永続化したテーブルでの利用については、リミットにあたる可能性がありますので、テーブルの利用サイズは意識しておく必要があるかと。
メモリのスケールリミットに達すると以下のようなエラーが発生します。
image
リンク先の情報は インメモリ OLTP ストレージの監視 と SQL Databas のものとなっていますが動作は同じようです。
詳細はこちらも参照。
In-Memory OLTP in Standard and Express editions, with SQL Server 2016 SP1
メモリの制限ですが、SP1 からは、カタログスペックのメモリはインスタンス当たりのバッファプールサイズという形になり、列ストアと、In-Memory OLTP 用のメモリがさらに別として追加される形となるようですね。
 
パーティション分割
これについては一般的なパーティション分割のシナリオが Enterprise Edition 以外でも利用することができるようになりました。
SQL Server 2008 以降は、各パーティションに対して複数のスレッドを使用した検索ができるようになりました。
パーティション・テーブルにおけるパフォーマンスの考察
Partitioned Tables, Parallelism & Performance considerations
# 2005 の動作
パーティション テーブルとパーティション インデックスに対するクエリ処理の機能強化
SQL Server 2016 SP1 では、Partition Table Parallelism は Enterprise Edition のみ YES となっていたのでこの動作を確認してみたところ、以下のような動作となっていました。
1,2 の 2 パーティションに対してのアクセスを行った際の実行プランが以下になるのですが、2 パーティションの操作に対して、8 スレッドが使用されており、パーティションテーブルの並列処理が行われているように見受けられるのですよね。
# 個々が 2 パーティションに対して 2 スレッドであれば、並列操作ではないのでしょうが。
image
「SET STATISTICS PROFILE ON」の結果がこちらになるのですが、Index Scan の実行回数が 8 となっていますので、こちらからも並列で操作されているように見受けられます。
image
 
同一のクエリを Express Edition に対して実行した場合がこちらになります。
SP1 で Express Edition もパーティショニングが使えるようになりましたので、こちらの実行プランも複数のパーティションにアクセスできています。
今まで、あまり意識していなかったのですが、Express Edition は複数の CPU を使うことはできますが並列クエリって実行されないんですね…。
image
image
SQL Server 2016 では、パーティション単位の TRUNCATE TABLE も可能となりましたので、データを効率よく格納するためのシナリオとして、パーティションを全エディションで使えるようになったことのメリットが出てくるのかなと。
 
データの圧縮
この機能追加はかなりインパクトがあるのではないでしょうか。
データの圧縮
全エディションで行 / ページ圧縮が使うことができますので、ストレージ領域 / メモリ使用量の削減の手法としてデータ圧縮を使うことができます。
 
複数の Filestream コンテナー
Non SP では、FILESTREAM のファイルグループを使用した以下のような構成をとるためには、Enterprise Edition の構成が必要でした。
image
これが Standard Edition SP1 だと設定可能になります。
FILESTREAM に対しての書き込みの分散をさせるときのシナリオとして使用する形でしょうかね。
image
 
RDBMS のセキュリティ


SP1 を適用することで、すべてのエディションで、

  • 行レベルのセキュリティ
    • 以前から Standard Edition でも使用できたが、Web / Express でも利用可能に
  • Always Encrypted
  • 動的なデータ マスキング
    • 以前から Standard Edition でも使用できたが、Web / Express でも利用可能に
  • 詳細な監査 (データベースレベルの監査)

を使用することができるようになります。
Standard Edition を使用している場合は、Always Encrypted とデータベースレベルの監査が利用できるようになったのが大きな変更点かと思います。
Express Edition で、行レベルのセキュリティや動的なデータマスキングが使用できるようになったのは、パッケージとして、SQL Server 2016 Express を使用する上ではうれしいかもしれないですね。
以下の機能に関しては Enterprise Edition のみ使用できる機能となります。

  • 透過的なデータベースの暗号化 (TDE)
  • 拡張キー管理 (EKM)

TDE に関しては、引き続き Enterprise Edition でのみ使用することができますので、データ / ログファイルといったデータベースのファイル全体に対してのセキュリティに関しては、Enterprise Edition の利用検討が必要になる個所となります。
また、拡張キー管理に関しても Enterprise Edition の機能となります。EKM 対応というと Key Vault との連携が該当する気がしますので、暗号化キーのストアとして Key Vault が使用できるかについては、要検証かと。
# 私は現時点では Standard で使えるか、使えないかの検証はしていません。
 

レプリケーション


レプリケーションに関しては、SP1 を適用しても機能の変更はありません。
ピアツーピアトランザクションレプリケーションに関しては、引き続き Enterprise Edition のみの機能ですので、レプリケーションを使用する場合は、エディション間の機能差は意識する必要があります。
 
 

管理ツール


管理ツールに関しては、SP1 を適用しても機能の変更はありません。
SQL Server エージェントに関しては引き続き Express Edition で利用することはできません。
 

RDBMS の管理の容易性


表内には SP1 で増えた機能の注釈がありますが、投稿時点では注釈に該当する項目がないような気がします。

  • インデックス付きビューに対してのクエリ実行時の NOEXPAND ヒント
  • 並列インデックス操作
  • バッファプール拡張
  • パフォーマンスデータコレクション

というようなものについては、今までと同じになっています。
インデックス付きビューの利用時のオプション設定については従来通りのようです。
Enterprise Edition の場合は、自動的にインデックス付きビューを使用するか判断されています。
image
Standard Edition の場合はオプションを指定しないと使用されませんでした。
image
 

管理ツール


この辺も今までと同じですね。
 

プログラミング


SP1 を適用することで、すべてのエディションで、

  • Polybase コンピューティングノード

が使用できるようになっています。
今までは、Standard Edition をコンピューティングノードに追加することが可能でしたが、SP1 を適用することで、すべてのエディションをコンピューティングノードとして使用することができるようになっています。
また、コンピューティングノードとしての利用だけでなく、スタンドアロンの Polybase としても利用可能となっているようです。
左が、SQL Server 2016 Standard Edition 、右が、SQL Server 2016 SP1 Standard Edition をスリップストリームインストールした場合の Polybase のインストール選択の画面となります。
Non SP の場合、スタンドアロンの Polybase 対応インスタンスのラジオボタンはグレーアウトしているのですが、SP1 をスリップストリームインストールした場合、スタンドアロンのノードを選択することができるようになっています。
imageimage
これは、Express Edition も同様で、Non SP では Polybase をインストールできませんが、SP1 だとインストールできるようになっています。
imageimage
 

データウェアハウス


SP1 を適用することで、Standard / Web エディションで、

  • 変更データ キャプチャ (CDC)

を使用することができるようになっています。
CDC については SQL Server エージェントを使っていた気がしますので、これについては Express では使えない感じですかね。
 

SP1 の新機能


ここまでは、エディションの機能差について書いていきましたが、SP1 の新機能もいくつか実装されています。
SQL Server 2016 Service Pack 1 (SP1) released !!!
大きなものとしては CLONE DATABASE とCREATE OR ALTER 構文のサポートでしょうか。
CLONEDATABASE
DBCC CLONEDATABASE は SQL Server 2014 SP2 で実装されたものですが、SP1 で SQL Server 2016 にも実装が行われました。
こちら、2014 の実装がそのまま使えるようになっただけでなく機能強化が行われています。
How to use DBCC CLONEDATABASE to generate a schema and statistics only copy of a user database in SQL Server 2014 SP2 and SQL Server 2016 SP1
SQL Server 2016 では、NO_STATISTICS / NO_QUERYSTORE というオプションが追加されているのですが、デフォルトのクローンデータベースとして、クエリストアの情報もコピーされるようになりました。
# 統計情報を含まないスキーマのみのクローンや、クエリストアを含めないクローンの作成ができるようになっています。
クエリストアの情報を含むクローンを作成し、そのデータベースをバックアップして他の環境で解析用に使用するということも可能になっています。
先日、SQL Server 2016 RTM 向けに Cumulative update 3 for SQL Server 2016 が提供されましたが、こちらには CLONEDATABASE のような機能は追加されていないようでした。
SQL Server 2016 Service Pack 1 release information には CLONEDATABASE についての記載が明記されていますが、CU3 では明記されていないため、SP1 を導入しない状態では新機能の利用ができない可能性があるかもしれないですね。
 
CREATE OR ALTER
SQL Server 2016 では、DROP IF EXISTS という構文が追加されましたが、存在している場合は ALTER を実施する、CREATE OR ALTER では存在している場合は変更ということができます。
CREATE PROCEDURE (Transact-SQL)
CREATE TRIGGER (Transact-SQL)
CREATE FUNCTION (Transact-SQL)
CREATE VIEW (Transact-SQL)
そのほかには以下のようなものがあるようです。

情報取得に影響しそうなものをピックアップして確認しましたが、このほかにも機能がいくつか追加されています。

Share

Written by Masayuki.Ozawa

11月 20th, 2016 at 1:04 pm

Posted in SQL Server

Tagged with

Leave a Reply