Microsoft SQL Server 2016 実践シリーズ （HTML 版）
「SQL Server 2016 への移行とアップグレードの実践」

3.12　データベースの互換性レベルを 130 へ上げる（オプション）

アップグレード前の SQL Server でデータベースの互換性レベルが「90」（SQL Server 2005レベル）以下であったものは、SQL Server 2016 にアップグレードした後に、自動的に「100」（SQL Server 2008 に相当するレベル）に変更されています。

データベースの互換性レベルを確認するには、次のようにユーザー データベースの［プロパティ］を開いて、［オプション］ページを表示します。

SQL Server 2016 では、互換性レベル 100 以降がサポートされています。

◆ SQL Server 2016 で利用できるデータベースの互換性レベル

SQL Server 2016 で利用できるデータベースの互換性レベルは、次の 4つです。

• 100（SQL Server 2008／2008 R2 レベル）
• 110（SQL Server 2012 レベル）
• 120（SQL Server 2014 レベル）
• 130（SQL Server 2016 レベル）

SQL Server 2008／2008 R2 をアップグレードすると 100、SQL Server 2012 をアップグレードすると 110、SQL Server 2014 をアップグレードすると 120 が利用されます。

互換性レベルは、100 や 110、120 のまま利用しても問題はありませんが、より良い性能を考慮するのであれば、130（SQL Server 2016 レベル）に上げておくことがお勧めになります。130 に変更すれば、SQL Server 2016 からの新機能である「INSERT .. SELECT の並列処理」や「列ストア インデックスでのバッチ モードの性能向上」、「インメモリ OLTP での並列処理」などを利用することができるからです。

互換性レベルの 100、110、120 および 130 では、細かい修正はありますが（詳しくは後述します）、基本的な Transact-SQL ステートメントであれば同じように利用できるので、多くの環境では問題が出ないと思います（弊社のお客様では、今のところ 4社ほど SQL Server 2008 から SQL Server 2016 へのデータベースの移行を試していますが、何の問題もなく、ストアド プロシージャやアプリケーションを実行することができています）。

◆ データベースの互換性レベルを 130 へ上げる

互換性レベルを 130 へ上げるには、次のようにデータベースのプロパティの［オプション］ページで、［互換性レベル］に［SQL Server 2016 (130)］を選択して、［OK］ボタンをクリックします（互換性レベルを変更する前に、現在の実行プランの保存や、性能チェックを行いたい場合は、次の項で説明するクエリストア機能を利用してから、互換性レベルを変更してください）。

Transact-SQL ステートメントを利用して互換性レベルを変更したい場合には、次のように ALTER DATABASE ステートメントを実行します。

◆ 互換性レベルの違い

互換性レベルの違い（動作に変更のあったステートメント）に関しては、オンライン ブックの以下のトピックに記載されています。

ALTER DATABASE 互換性レベル
http://msdn.microsoft.com/ja-jp/library/bb510680.aspx

このトピックの主なものを取り上げると、次のようになります（関係ありそうな部分は、オンライン ブックを参照しておくことをお勧めします）。

130 との相違点（120以下と 130との差）

• INSERT .. SELECT が並列操作になるかどうか（130 では並列になる）
• インメモリ OLTP のメモリ最適化テーブルを並列処理できるかどうか（130 では並列になる）
• 列ストア インデックスの動作の違い（性能に関する動作の違いが発生。130 にすることで列ストア インデックスの性能が向上）
• SQL Server 2014 から提供された基数見積（CE: Cardinality Estimation）を利用して、実行プランを選択する（これについては、データベースごとに設定を変更することができるようになったので、詳しくは後述）
• 統計の自動更新の動作の違い
• 暗号化アルゴリズムは SHA2_256 と SHA2_512 のみが許可される（MD2 と MD4、MD5、SHA、SHA1 は許可されない）

120 との相違点（110以下と 120との差）

• SQL Server 2014 からの新しいクエリ オプティマイザーが利用されるかどうか（120 では利用される、100／110 では利用されない）
• date 型の文字列値で、言語設定が無視されるかどうか（120 では無視しない）
• 再帰 CTE（共通テーブル式）で重複する列名を使用できるかどうか（120 では使用できない）
• SELECT INTO が並列操作になるかどうか（120 では並列になる）

110 との相違点（100以下と 110以上との差）

• SQL CLR（CLR 統合）の動作の違い（100 と 110 以降で動作が異なる。Unicode 5.1 のサポートや、System.TimeSpan 値の扱いなど）
• XQuery 関数の string-length および substring の動作が 100 と 110以降で異なる（サロゲート ペアの場合の文字カウントの仕方が異なる）
• PIVOT が再帰 CTE で許可されるかどうか（110 以降では許可されない）
• RC4 または RC4_128 での暗号化がサポートされるかどうか（110 以降ではサポートされない）
• time および datetime2 データ型の計算列で、CAST または CONVERT で日付／時刻スタイルを省略したときの動作の違い（110 以降では既定のスタイルが 121 になる）
• パーティション ビューで参照するリモート テーブルが smalldatetime 型の列が datetime にマップされるかどうか（110 以降では、smalldatetime にマップされる）
• SOUNDEX 関数では動作の違い（110 以降では、大文字の H または大文字の W がある場合に、右側の子音は無視されるなど）

100 との相違点（90以下と 100以上との差）

• 複数ステートメントのテーブル値関数が作成されるときの QUOTED_IDENTIFER 設定の違い（100 以降ではセッションの設定が利用される）
• パーティション関数での datetime および smalldatetime リテラルが言語設定を利用するかどうか（100 以降では利用する）
• INSERT または SELECT INTO ステートメントでの FOR BROWSE 句（100 以降では許可される）
• OUTPUT 句でのフルテキスト述語（100 以降では使用できない）
• フルテキスト インデックスでの STOPLIST（100 以降でサポートされる）
• MERGE が予約されたキーワードかどうか（100 以降では予約されたキーワードになる）
• INSERT ステートメントでの dml_table_source>、OUTPUT 句（100 以降でサポートされる）
• DBCC CHECKDB での NOINDEX の動作の違い
• データ操作言語 (DML) ステートメントで OUTPUT 句を使用した場合の実行時エラーの動作の違い
• CUBE および ROLLUP が予約されたキーワードかどうか（100 以降では GROUP BY 句内では予約されたキーワードになる）
• XML の anyType 型が厳密な検証かどうか（100 以降では緩やかな検証）
• 特殊な属性 xsi:nil および xsi:type が変更可能かどうか
• XML 定数文字列値を datetime 型に変換するユーザー定義関数が "決定的" とマークされるかどうか
• XML の union 型と list 型が完全にサポートされているかどうか
• xQuery メソッドでの SET オプションが検証されるかどうか
• XML 属性値で行末文字（復帰と改行）を含む場合の動作の違い
• ROWGUIDCOL または IDENTITY を制約として指定できるかどうか（100 以降では指定できない）
• UPDATE T1 SET @v = column_name = のような双方向代入を行った場合の動作の違い
• 変数代入のステートメントを UNION で連結する場合の動作の違い
• ODBC 関数 {fn CONVERT()} での日付への変換時の動作の違い
• ODBC 関数 {fn CURDATE()} の動作の違い
• DATEPART 関数での無効な datetime リテラルが与えられた場合の動作（例えば、100 以降では、'2007/05-30' はエラー 241 が返り、90 では正常にコンパイルされる）

いずれも細かい修正点ばかりで、XML や再帰 CTE、OUTPUT 句、フルテキスト検索、ODBC など、関係ないものが多いのではないでしょうか。弊社のお客様のデータベースでは、上記に該当するステートメントはほとんどなく、INSERT .. SELECT および SELECT INTO の並列処理のみが該当しました。INSERT .. SELECT と SELECT INTO のパラレル処理に関しては、非常に便利な機能で、これは互換性レベルを 130 にしないと利用できないので、ぜひ 130 へ上げることを検討してみることをお勧めします。また、130 レベルを利用することで、インメモリ OLTP と列ストア インデックスの性能向上を実現することができるので、130 レベルを利用することをお勧めします。

◆ Data Migration Assistant で事前に互換性レベルの違いを簡単に確認可能

第2章で紹介した Data Migration Assistant（旧アップグレード アドバイザー）を利用すれば、アップグレード前の SQL Server に対して、SQL Server 2016 にアップグレードしたときの互換性レベルの問題点（130 や 120 を利用したときにどういった問題が発生するのか）を簡単に見つけることができます。

◆ クエリ ストアで互換性レベルの違いを確認

詳しくは次項で説明しますが、互換性レベルの違いについては、SQL Server 2016 から提供された「クエリ ストア」機能を利用することで、期待した動作になるかどうかをチェックできるので、お勧めです。特に互換性レベルを 130 に上げたことによる性能向上や予期せぬ性能低下（想定外の実行プランが選択されたことによる性能低下など）を確認することができます。

◆ 互換性レベル 80（SQL Server 2000 レベル）を利用していた場合

アップグレード前の SQL Server で、互換性レベル 80（SQL Server 2000 との互換性があるレベル）を利用していたデータベースは、SQL Server 2016 にアップグレードしたタイミングで、自動的に 100（SQL Server 2008 レベル）に変更されます。

この場合は、互換性レベル 80 では利用できていたものが、100 以降では利用できないということが発生します。例えば、外部結合演算子の「*=」と「=*」は、80 では利用できますが、100以降では利用できないなどです。80（および SQL Server 2000）に関しては、SQL Server 2012 から未サポートになっているので、オンライン ブックの以下のトピックが参考になります。

SQL Server 2016 で廃止されたデータベース エンジンの機能　- SQL Server 2012 で廃止されたデータベース エンジンの機能
http://msdn.microsoft.com/ja-jp/library/ms144262.aspx

SQL Server 2008 R2 のオンライン ブックでのALTER DATABASE 互換性レベルの「互換性レベル 80 とレベル 90 の相違点」
http://msdn.microsoft.com/ja-jp/library/bb510680(v=sql.105).aspx