ALTER DATABASE (Transact-SQL) 互換性レベル
適用対象: 
SQL Server Azure SQL Database Azure SQL Managed Instance
指定したバージョンの SQL エンジンと互換性があるように、Transact-SQL およびクエリ処理の動作を設定します。 ALTER DATABASE の他のオプションについては、「ALTER DATABASE」をご覧ください。
構文表記規則の詳細については、「Transact-SQL 構文表記規則」を参照してください。
構文
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 }
引数
database_name
変更するデータベースの名前。
COMPATIBILITY_LEVEL { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }
データベースの互換性の対象となる SQL Server のバージョンを指定します。 次の互換性レベルの値を構成することができます (上で示したすべての互換性レベルをすべてのバージョンがサポートしているわけではありません)。
| Product | データベース エンジンのバージョン | 既定の互換性レベルの指定 | サポートされている互換性レベル値 |
|---|---|---|---|
| Azure SQL データベース | 16 | 160 | 160, 150, 140, 130, 120, 110, 100 |
| Azure SQL Managed Instance | 16 | 150 | 160, 150, 140, 130, 120, 110, 100 |
| SQL Server 2022 (16.x) | 16 | 160 | 160, 150, 140, 130, 120, 110, 100 |
| SQL Server 2019 (15.x) | 15 | 150 | 150, 140, 130, 120, 110, 100 |
| SQL Server 2017 (14.x) | 14 | 140 | 140, 130, 120, 110, 100 |
| SQL Server 2016 (13.x) | 13 | 130 | 130, 120, 110, 100 |
| SQL Server 2014 (12.x) | 12 | 120 | 120, 110, 100 |
| SQL Server 2012 (11.x) | 11 | 110 | 110, 100, 90 |
| SQL Server 2008 R2 (10.50.x) | 10.5 | 100 | 100, 90, 80 |
| SQL Server 2008 (10.0.x) | 10 | 100 | 100, 90, 80 |
| SQL Server 2005 (9.x) | 9 | 90 | 90, 80 |
| SQL Server 2000 (8.x) | 8 | 80 | 80 |
重要
SQL Server と Azure SQL Database のデータベース エンジンのバージョン番号は類似のものではありません。別個の製品に与えられる内部製造番号になっています。 Azure SQL Database のデータベース エンジンは SQL Server データベース エンジンと同じコードに基づいています。 最も重要なことですが、Azure SQL Database のデータベース エンジンには常に最新の SQL データベース エンジン ビットが与えられます。 Azure SQL Database のバージョン 12 は SQL Server のバージョン 15 より新しくなります。
データベース互換レベルをアップグレードするためのベスト プラクティス
互換レベルをアップグレードする場合にお勧めするワークフローについては、「新しい SQL Server へのアップグレード中にパフォーマンスの安定性を維持する」を参照してください。 さらに、データベース互換性レベルのアップグレードでのアシスト付きエクスペリエンスについては、「クエリ調整アシスタントを使用したデータベースのアップグレード」をご覧ください。
解説
SQL Server のすべてのインストールで、既定の互換性レベルは データベース エンジン のバージョンと関連付けられています。 新しいデータベースはこのレベルに設定されますが、model データベースの互換性レベルがこれより低い場合は例外です。 以前のバージョンの SQL Server からデータベースを接続または復元した場合、そのデータベースの互換性レベルが SQL Server の該当するインスタンスに対して許可される最低レベル以上であれば、既存の互換性レベルが維持されます。 データベース エンジン で許可されるレベルより低い互換性レベルのデータベースを移動すると、許可される最も下の互換性レベルにデータベースが自動的に設定されます。 これはシステム データベースとユーザー データベースの両方に適用されます。
SQL Server 2017 (14.x) では、データベースがアタッチまたは復元されたとき、およびインプレース アップグレード後に、次の動作が想定されます。
- アップグレード前のユーザー データベースの互換性レベルが 100 以上の場合は、アップグレード後も互換性レベルは変わりません。
- アップグレード前のユーザー データベースの互換性レベルが 90 の場合、アップグレードされたデータベースの互換性レベルは 100 に設定されます。これは、SQL Server 2017 (14.x) でサポートされている下限の互換性レベルです。
tempdb、model、msdb、Resource データベースの互換性レベルは、指定されたデータベース エンジン バージョンの既定の互換性レベルに設定されます。masterシステム データベースの互換性レベルは、アップグレード前と同じです。 これは、ユーザー データベースの動作には影響しません。
低い互換性レベルで実行されている既存のデータベースの場合、より高いデータベース互換レベルでのみ使用できる拡張機能をアプリケーションで使用する必要がない限り、前のデータベース互換レベルを維持することは有効なアプローチです。 新しい開発作業の場合、またはインテリジェント クエリ処理のような新しい機能と一部の新しい Transact-SQL を既存のアプリケーションで使用する必要があるときは、データベース互換レベルを利用できる最新のレベルにアップグレードすることを計画します。 詳細については、「互換性レベルとデータベース エンジンのアップグレード」を参照してください。
Note
ユーザー オブジェクトと依存関係がない場合は、通常、既定の互換性レベルにアップグレードするのが安全です。 詳細については、master データベースの推奨事項に関する記事を参照してください。
ALTER DATABASE を使用し、データベースの互換性レベルを変更します。 データベースの新しい互換性レベル設定は USE <database> コマンドが発行されたときか、新しいログインがそのデータベースで既定のデータベース コンテキストとして処理されたときに有効になります。
データベースの現在の互換性レベルを確認するには、sys.databases カタログ ビューの compatibility_level 列をクエリします。
以前のバージョンの SQL Server で作成され、SQL Server 2016 (13.x) RTM または Service Pack 1 にアップグレードされるディストリビューション データベースは、互換性レベルが 90 であり、その他のデータベースではサポートされません。 これはレプリケーションの機能には影響がありません。 新しいバージョンのサービス パックと SQL Server にアップグレードすると、分散データベースの互換性レベルが増加し、master データベースの互換性レベルと一致します。
データベース全体ではデータベース互換レベル 120 以上を使用する一方で、データベース互換レベル 110 にマップされる SQL Server 2012 (11.x) のカーディナリティ推定モデルにオプトインする場合は、「ALTER DATABASE SCOPED CONFIGURATION」を参照してください。特にそのキーワード LEGACY_CARDINALITY_ESTIMATION = ON をご覧ください。
Azure SQL に関する注釈
既定の互換性レベルは、Azure SQL Database で新しく作成されたデータベースの SQL Server 2022 (160) です。
既定の互換性レベルは、Azure SQL Managed Instance で新しく作成されたデータベースの SQL Server 2019 (150) です。
Microsoft では、既存のデータベースのデータベース互換性レベルは自動的に更新されません。 それは、お客様の独自の裁量にまかされます。
Microsoft では、クエリ最適化に関する最新の改善点を利用するために、最新の互換性レベルへのアップグレードを計画することをお客様に強くお勧めいたします。 Azure SQL Database の 2 つの異なる互換性レベル間で最も重要なクエリのパフォーマンスの違いを評価する方法のヒントについては、「Azure SQL Database の互換性レベル 130 でのクエリパフォーマンスの向上を参照してください。 この記事では互換性レベル 130 と SQL Server を取り上げていますが、SQL Server と Azure SQL データベース で 140 以降にアップグレードする場合も同じ手法が適用されます。
Azure SQL データベース では、互換性レベルに依存する機能がすべてサポートされているわけではありません。
現在の互換性レベルを検索する
現在の互換性レベルを特定するには、compatibility_level の compatibility_level 列に対してクエリを実行します。
SELECT name, compatibility_level FROM sys.databases;
接続先であるデータベース エンジンのバージョンを特定するには、次のクエリを実行します。
SELECT SERVERPROPERTY('ProductVersion');
互換性レベルとデータベース エンジンのアップグレード
データベース互換レベルは、SQL Server データベース エンジンのアップグレードを可能にし、それと同時に、アップグレード前と同じデータベース互換レベルを維持することで接続するアプリケーションの同じ機能的な状態を維持するという点で、データベースの最新化をサポートするために不可欠なツールです。 これは、(データベース接続を除き) アプリケーションを変更することなく、古いバージョンの SQL Server (SQL Server 2008 (10.0.x) など) から SQL Server または Azure SQL Database (Azure SQL Managed Instance を含む) にアップグレードできることを意味します。 詳細については、「Compatibility Certification」 (互換性証明書) を参照してください。
上位のデータベース互換レベルでのみ利用できる拡張をアプリケーションで使用する必要がない限り、SQL Server データベース エンジンをアップグレードし、前のデータベース互換レベルを維持することは有効なアプローチです。 下位互換性のために互換性レベルを使用する方法については、「互換性証明書」を参照してください。
互換性レベルとストアド プロシージャ
ストアド プロシージャを実行すると、そのストアド プロシージャが定義されているデータベースの現在の互換性レベルが使用されます。 データベースの互換性設定が変更された場合、そのデータベースのすべてのストアド プロシージャは、設定に合わせて自動的に再コンパイルされます。
下位互換性のための互換性レベルの使用
データベース互換レベル設定では、サーバー全体ではなく指定のデータベースに対してのみ、Transact-SQL に関連するものとクエリ最適化動作において以前のバージョンの SQL Server との下位互換性が提供されます。
互換モード 130 以降、修正プログラムと機能に影響を与える新しいクエリ プランは、新しい互換性レベルにのみ意図的に追加されています。 これは、新しいクエリ最適化動作によって導入される可能性のあるクエリ プランの変更によるパフォーマンスの低下から発生する、アップグレード中のリスクを最小限に抑えるために追加されました。
アプリケーションの観点からは、関連する互換性レベル設定によって制御される動作では、安全な移行パスとして下位の互換性レベルを使用し、バージョンの違いに対処してください。 新しい機能 (インテリジェントなクエリ処理など) のいくつかを継承するために、ある時点で最新の互換性レベルにアップグレードすることは目的であり続けますが、それをコントロールされた方法で行います。
データベース互換レベルのアップグレードで推奨されるワークフローなど、詳細については、「データベース互換性レベルのアップグレードのベスト プラクティス」を参照してください。
特定の SQL Server バージョンで導入された機能が廃止されている場合、その機能は互換性レベルによって保護されません。 これは、SQL Server データベース エンジン から削除された機能に当てはまります。 たとえば、
FASTFIRSTROWヒントは SQL Server 2012 (11.x) で廃止され、OPTION (FAST n )ヒントに置き換えられました。 データベース互換レベルを 110 に設定すると、廃止されたヒントは復元されません。 廃止された機能の詳細については、「SQL Server で廃止されたデータベース エンジンの機能」を参照してください。特定の SQL Server バージョンで導入された破壊的変更互換性レベルで保護することはできません。 これは、SQL Server データベース エンジン のバージョン間の動作変更に当てはまります。 Transact-SQL の動作は、通常、互換性レベルで保護されます。 ただし、変更または削除されたシステム オブジェクトは、互換性レベルで保護されません。
互換性レベルによる破壊的変更 保護 の例として、 datetime から datetime2 データ型への暗黙的な変換があります。 データベース互換性レベル 130 では、これらの変換が行われると小数ミリ秒を考慮することで精度が上がり、結果的に異なる変換値が生成されます。 以前の変換動作を復元するには、データベース互換性レベルを 120 以下に設定します。
互換性レベルで保護されない重大な変更の例としては、次のような内容が挙げられます。
- システム オブジェクトで変更された列名。 SQL Server 2012 (11.x) では、
sys.dm_os_sys_info内の列single_pages_kbの名前がpages_kbに変更されました。 互換性レベルに関係なく、クエリSELECT single_pages_kb FROM sys.dm_os_sys_infoによってエラー 207 (無効な列名) が生成されます。 - 削除されたシステム オブジェクト。 SQL Server 2012 (11.x) では、
sp_dboptionが削除されました。 互換性レベルに関係なく、ステートメントEXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE';エラー 2812 (Couldn't find stored procedure 'sp_dboption') が生成されます。
重大な変更の詳細については、SQL Server 2019 におけるデータベース エンジン機能の重大な変更に関するページ、「SQL Server 2017 におけるデータベース エンジン機能の重大な変更」、「 SQL Server 2016 におけるデータベース エンジン機能の重大な変更」、「SQL Server 2014 におけるデータベース エンジン機能の重大な変更」を参照してください。
- システム オブジェクトで変更された列名。 SQL Server 2012 (11.x) では、
互換性レベルの相違点
SQL Server のすべてのインストールで、既定の互換性レベルは、この表で示されるように、データベース エンジン のバージョンと関連しています。 新しい開発作業では、常に最新のデータベース互換レベルでアプリケーションを認定するように計画します。
新しい Transact-SQL 構文は、データベース互換レベルによって制限されません。ただし、ユーザー Transact-SQL コードとの競合を作成して既存のアプリケーションを中断できる場合を除きます。 この記事の以降のセクションでは、特定の互換性レベル間の相違について説明しますが、これらの例外についても言及します。
以前のバージョンの SQL Server にアタッチされている、またはそこから復元されたデータベースは、(最小許容互換性レベル以上の場合) 既存の互換性レベルを保持しているため、データベース互換レベルによって、SQL Server の以前のバージョンとの下位互換性も提供されます。 これについては、この記事の「旧バージョンとの互換性を保持するための互換性レベルの使用」で説明しました。
データベース互換レベル 130 以降では、クエリ プランに影響を与える新しい修正プログラムと機能が、既定の互換性レベルとも呼ばれる、使用可能な最新の互換性レベルにのみ追加されています。 これは、新しいクエリ最適化動作によって導入される可能性のあるクエリ プランの変更によるパフォーマンスの低下から発生する、アップグレード中のリスクを最小限に抑えるために行われました。
新しいバージョンの データベース エンジン の既定の互換性レベルにのみ追加される、プランに影響する基本的な変更は次のとおりです。
トレース フラグ 4199 の以前の SQL Server バージョンでリリースされたクエリ オプティマイザーの修正プログラムは、より新しい SQL Server バージョンの既定の互換性レベルで自動的に有効になります。
適用対象: SQL Server (バージョン SQL Server 2016 (13.x) 以降)、Azure SQL Database。
たとえば、SQL Server 2016 (13.x) がリリースされた場合、以前の SQL Server バージョン (およびそれぞれの互換性レベル 100 から 120) に対してリリースされたクエリ オプティマイザーの修正プログラムがすべて、SQL Server 2016 (13.x) の既定の互換性レベル (130) を使用するデータベースに対して自動的に有効になります。 RTM 後のクエリ オプティマイザーの修正プログラムのみを明示的に有効にする必要があります。
クエリ オプティマイザーの修正プログラムを有効にするには、次の方法を使用できます。
- サーバー レベルでトレース フラグ 4199 を使用。
- データベース レベルで ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL) の
QUERY_OPTIMIZER_HOTFIXESオプションを使用。 - クエリ レベルで、クエリを変更することにより、
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'クエリ ヒントを使用します。 - クエリ レベルで、コードを変更せずに
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'を使用する場合は、クエリ ストア ヒント (プレビュー) 機能を使用します。
その後、SQL Server 2017 (14.x) がリリースされた場合、SQL Server 2017 (14.x) の既定の互換性レベル (140) を使用して、データベースに対して SQL Server 2016 (13.x) の RTM を自動的に有効にした後に、すべてのクエリ オプティマイザーがリリースされます。 これは、以前のバージョンの修正プログラムもすべて含まれる累積的な動作です。 ここでも、RTM 後のクエリ オプティマイザーの修正プログラムのみを明示的に有効にする必要があります。
次の表は、この動作をまとめたものです。
データベース エンジン (DE) のバージョン データベース互換レベル TF 4199 すべての以前のデータベース互換レベルからの QO の変更 DE バージョンの RTM 後の QO の変更 13 (SQL Server 2016 (13.x)) 100 から 120
130Off
On
Off
OnDisabled
Enabled
有効
有効無効
Enabled
無効
Enabled14 (SQL Server 2017 (14.x)) 100 から 120
130
140Off
On
Off
On
Off
OnDisabled
Enabled
有効
有効
有効
有効無効
Enabled
無効
Enabled
無効
Enabled15 (SQL Server 2019 (15.x)) と 12 (Azure SQL データベース) 100 から 120
130 から 140
150Off
On
Off
On
Off
OnDisabled
Enabled
有効
有効
有効
有効無効
Enabled
無効
Enabled
無効
Enabled16 (SQL Server 2022 (16.x)) および 12 (Azure SQL Database) 100 から 120
130 から 150
160Off
On
Off
On
Off
OnDisabled
Enabled
有効
有効
有効
有効無効
Enabled
無効
Enabled
無効
Enabled間違った結果やアクセス違反エラーに対処するクエリ オプティマイザーの修正プログラムは、トレース フラグ 4199 では保護されません。 これらの修正プログラムは、オプションとは見なされません。
SQL Server と Azure SQL データベース でリリースされたカーディナリティ推定機能の変更は、新しい データベース エンジン バージョンの既定の互換性レベルでのみ有効になりますが、以前の互換性レベルでは有効になりません。
たとえば、SQL Server 2016 (13.x) がリリースされたとき、カーディナリティの推定プロセスに対する変更は、SQL Server 2016 (13.x) の既定の互換性レベル (130) を使用しているデータベースに対してのみ使用できます。 以前の互換性レベルでは、SQL Server 2016 (13.x) 以前に使用できたカーディナリティ推定動作を保持していました。
その後、SQL Server 2017 (14.x) がリリースされたとき、カーディナリティの推定プロセスに対するより新しい変更は、SQL Server 2017 (14.x) の既定の互換性レベル (140) を使用しているデータベースに対してのみ使用できます。 データベース互換レベル 130 では、SQL Server 2016 (13.x) カーディナリティ推定動作が保持されます。
次の表は、この動作をまとめたものです。
データベース エンジンのバージョン データベース互換レベル 新しいバージョン CE の変更 13 (SQL Server 2016 (13.x)) < 130
130無効
Enabled14 (SQL Server 2017 (14.x))1 < 140
140無効
Enabled15 (SQL Server 2019 (15.x))1 < 150
150無効
Enabled16 (SQL Server 2022 (16.x))1 < 160
160無効
Enabled1Azure SQL データベース にも適用されます。
特定の互換性レベル間のその他の相違点については、この記事の次のセクションで入手できます。
互換レベル 150 とレベル 160 の相違点
このセクションでは、互換レベル 160 で導入された新しい動作について説明します。
| 互換レベル設定 150 以下 | 互換レベル設定 160 |
|---|---|
| パラメーター化されたクエリには、最初の実行に使用されるパラメーターに基づく 1 つのクエリ プランがあります。 1 つのクエリ プランのみがキャッシュされ、すべてのパラメーター値に対して使用されます。 これにより、クエリ プランは、パラメーターの一部の値について非効率的になる場合があります (パラメーター センシティビティ プランとも呼ばれます)。 | パラメーター化されたクエリは、パラメーターのさまざまな選択カテゴリで複数のキャッシュされたクエリ プランを含めることができます。 パラメーター センシティブ プランの最適化は、互換レベル 160 では既定で有効になっています。 詳しくは、「PSP 最適化」を参照してください。 |
| カーディナリティ推定では、すべてのデータベースとクエリの基になるデータ分散および使用パターンに関するモデルの既定の 1 つの前提条件セットだけが使用されます。 これらの前提条件のいずれかを変更または調整する唯一の方法は、クエリ ヒントを使用して、どのモデルの前提条件を使用する必要があるかを明示的に示す手動プロセスをユーザーが使用したときのみです。 クエリ プランが生成された後は、この既定のモデルに内部調整を行うことはできません。 | カーディナリティ推定は、基になるデータ分散および使用パターンに関するモデルの前提条件の既定セットで開始されますが、ある特定のクエリに数回実行すると、データベース エンジンは、モデル前提条件のどのセットの組み合わせでより適切な推定が生成される可能性があるかを学習し、これによって、クエリが実行されているデータ セットにより合致するよう使用中の前提条件を調整します。 CE フィードバックは、互換レベル 160 で既定で有効になっています。 詳細については、「CE フィードバック」を参照してください。 |
| 最適な程度の並列処理の自動的な決定は、データベース エンジンによって試行されません。 インスタンス、データベース、クエリ、またはワークロード レベルでの並列処理の最大限度 (MAXDOP) を手動で制御する方法については、「 Server の構成: 並列処理の最大限度」を参照してください。 | 並列処理の次数 (DOP) フィードバックにより、経過時間と待機時間に基づいて、反復するクエリの非効率な並列処理を特定することでクエリのパフォーマンスが向上します。 並列処理の利用が非効率であると思われる場合、構成された DOP の出所が何であれ、DOP フィードバックによってクエリの次回の実行で DOP が下がり、それが役立つか検証されます。 DOP フィードバックは、既定では有効になっていません。 DOP フィードバックを有効にするには、データベースで DOP_FEEDBACK データベース スコープ構成を有効にします。 詳細については、「DOP フィードバック」を参照してください。 |
互換性レベル 140 とレベル 150 の相違点
このセクションでは、互換性レベル 150 で導入された新しい動作について説明します。
| 互換性レベル設定 140 以下 | 互換性レベル設定 150 |
|---|---|
| OLTP のオーバーヘッド、ベンダーサポートの不足、またはその他の制限により、リレーショナル データ ウェアハウスと分析ワークロードで列ストア インデックスを使用できない場合があります。 列ストア インデックスがないと、これらのワークロードはバッチ実行モードの利点が得られません。 | 列ストア インデックスがなくても、分析ワークロードでバッチ実行モードが使用できるようになりました。 詳細については、「batch mode on rowstore (行ストアでのバッチ モード)」を参照してください。 |
| ディスクへのスピルにつながるメモリ許可サイズが不十分であることを要求する行モード クエリでは、連続実行で引き続き問題が発生する可能性があります。 | ディスクへのスピルにつながるメモリ許可のサイズが不十分であることを要求する行モード クエリでは、連続実行のパフォーマンスが向上する可能性があります。 詳細については、「行モード メモリ許可フィードバック」を参照してください。 |
| コンカレンシーの問題を引き起こす過剰なメモリ許可サイズを要求する行モード クエリでは、連続実行で引き続き問題が発生する可能性があります。 | コンカレンシーの問題が発生する過剰なメモリ許可サイズを要求する行モードクエリでは、連続実行のコンカレンシーが向上する可能性があります。 詳細については、「行モード メモリ許可フィードバック」を参照してください。 |
| T-SQL スカラー UDF を参照するクエリでは、反復呼び出しが使用され、コストが不足するため、シリアル実行が強制的に実施されます。 | T-SQL スカラー UDF は同等のリレーショナル式に変換され、この式は呼び出し側クエリに "インライン化" されます。これにより、多くの場合、パフォーマンスが大幅に向上します。 詳細については、「T-SQL scalar UDF inlining (T-SQL スカラー UDF のインライン化)」を参照してください。 |
| テーブル変数では、カーディナリティの推定で固定推定値が使用されます。 実際の行数が推定値よりはるかに大きい場合は、ダウン ストリーム操作のパフォーマンスが低下する場合があります。 | 新しいプランでは、固定推定値ではなく、最初のコンパイルで発生したテーブル変数の実際のカーディナリティが使用されます。 詳細については、「table variable deferred compilation (テーブル変数の遅延コンパイル)」を参照してください。 |
データベース互換レベル 150 で使用できるクエリ処理機能の詳細については、「What's new in SQL Server 2019」 (SQL Server 2019 の新機能) と「SQL データベースでのインテリジェントなクエリ処理」を参照してください。
互換性レベル 130 とレベル 140 の相違点
このセクションでは、互換性レベル 140 で導入された新しい動作について説明します。
| 互換性レベル設定 130 以下 | 互換性レベル設定 140 |
|---|---|
| 複数ステートメントのテーブル値関数を参照するステートメントのカーディナリティの推定値には、固定された行推定値が使用されます。 | 複数ステートメントのテーブル値関数を参照する対象のステートメントのカーディナリティの推定値には、関数出力の実際のカーディナリティが使用されます。 これは、複数ステートメントのテーブル値関数のインターリーブ実行を介して有効になります。 |
| メモリ許可のサイズが不十分でディスクへのスピルを要求するバッチ モード クエリでは、連続実行で引き続き問題が発生する可能性があります。 | メモリ許可のサイズが不十分でディスクへのスピルを要求するバッチ モード クエリでは、連続実行のパフォーマンスが向上する可能性があります。 これはバッチ モード メモリ許可フィードバックを介して有効になります。バッチ モード演算子に対してスピルが発生した場合、このフィードバックによりキャッシュ プランのメモリ許可サイズが更新されます。 |
| コンカレンシーの問題を引き起こす過剰なメモリ許可サイズを要求するバッチ モード クエリでは、連続実行で引き続き問題が発生する可能性があります。 | コンカレンシーの問題が発生する過剰なメモリ許可サイズを要求するバッチ モード クエリでは、連続実行のコンカレンシーが向上する可能性があります。 これはバッチ モード メモリ許可フィードバックを介して有効になります。過度な容量が元々要求されている場合、このフィードバックによりキャッシュ プランのメモリ許可サイズが更新されます。 |
| 結合演算子を含むバッチモード クエリは、3 つの物理結合アルゴリズム (入れ子になったループ、ハッシュ結合、マージ結合) の対象となります。 結合入力のカーディナリティ推定が正しくない場合は、不適切な結合アルゴリズムが選択されている可能性があります。 その場合は、パフォーマンスが低下し、キャッシュ プランが再コンパイルされるまで不適切な結合アルゴリズムが使用され続けます。 | その他に適応型結合と呼ばれる結合演算子もあります。 外部ビルド結合入力のカーディナリティ推定が正しくない場合は、不適切な結合アルゴリズムが選択されている可能性があります。 このような事態が発生し、ステートメントが適応型結合の対象である場合は、小さな結合入力には入れ子になったループが使用され、大きな結合入力にはハッシュ結合が使用されます。これは再コンパイルを要求することなく動的に行われます。 |
| 列ストア インデックスを参照する単純なプランは、バッチ モード実行の対象ではありません。 | 列ストア インデックスを参照する単純なプランは、バッチ モード実行の対象であるプランを優先するために廃止されます。 |
sp_execute_external_script UDX 演算子は、行モードでのみ実行できます。 |
sp_execute_external_script UDX 演算子は、バッチ モードでの実行に適しています。 |
| 複数ステートメントのテーブル値関数 (TVF) にはインターリーブ実行はありません | 複数ステートメントの TVF のインターリーブ実行で、プランの品質を向上。 |
SQL Server 2017 より前の SQL Server の初期のバージョンのトレース フラグ 4199 での修正プログラムは、既定で有効になりました。 互換モード 140 の場合。 トレース フラグ 4199 は、SQL Server 2017 の後にリリースされるクエリ オプティマイザーの新しい修正プログラムにも引き続き適用可能です。 トレース フラグ 4199 については、「トレース フラグ 4199」を参照してください。
互換性レベル 120 とレベル 130 の相違点
このセクションでは、互換性レベル 130 で導入された新しい動作について説明します。
| 互換性レベル設定 120 以下 | 互換性レベル設定 130 |
|---|---|
| INSERT-SELECT ステートメント内の INSERT はシングル スレッドです。 | INSERT-SELECT ステートメントの INSERT はマルチ スレッドであるか、並列プランを与えることができます。 |
| メモリ最適化テーブルに対するクエリでは、シングル スレッドを実行します。 | メモリ最適化テーブルに対するクエリで、並列プランを利用できるようになりました。 |
| SQL 2014 のカーディナリティ推定機能 CardinalityEstimationModelVersion="120" が導入されました。 | クエリ プランから表示できる、カーディナリティ推定モデル 130 を使ったカーディナリティの推定 (CE) のさらなる改善。 CardinalityEstimationModelVersion="130" |
列ストア インデックスで行モードがバッチ モードに変更:
|
列ストア インデックスで行モードがバッチ モードに変更:
|
| 統計情報を自動的に更新できます。 | 統計情報を自動的に更新するロジックは、大規模なテーブルでより積極的に活用されます。 実際には、これにより、クエリに関するパフォーマンス上の問題 (新たに挿入された行に対してクエリが頻繁に実行されるが、それらの値を取り込むための統計情報の更新が行われていない) に顧客が遭遇するケースが減少します。 |
| SQL Server 2014 (12.x) では、トレース 2371 は既定ではオフになっています。 | SQL Server 2016 (13.x) では、トレース 2371 は既定では ON です。 トレース フラグ 2371 は、多くの行を含むテーブル内で、小さくても有用な行のサブセットをサンプリングするように自動統計更新ツールに指示します。 1 つの改良点は、最近挿入された行をより多くサンプルに含めるというものです。 もう 1 つの改良点は、統計の更新プロセスが実行されている間に、クエリをブロックするのでなく、クエリが実行されるようにするというものです。 |
| レベル 120 の場合、統計情報はシングルスレッド プロセスによってサンプリングされます。 | レベル 130 の場合、統計情報はマルチスレッド プロセスによってサンプリングされます (並行処理)。 |
| 253 の入力方向の外部キーは制限です。 | 指定されたテーブルは、最大 10,000 個の入力方向の外部キーまたは類似の参照方法によって参照することができます。 制限については、「 Create Foreign Key Relationships」を参照してください。 |
| 非推奨の MD2、MD4、MD5、SHA、SHA1 のハッシュ アルゴリズムは許可されます。 | SHA2_256 と SHA2_512 のハッシュ アルゴリズムのみが許可されます。 |
| SQL Server 2016 (13.x) では、一部のデータ型変換と一部の (大抵は一般的ではない) 操作に改良が加えられました。 詳細については、「いくつかのデータ型と一般的でない操作を処理するときの SQL Server と Azure の SQL データベースの機能強化」をご覧ください。 | |
STRING_SPLIT 関数は利用できません。 |
STRING_SPLIT 関数は、互換性レベル 130 以上で利用できます。 データベース互換レベルが 130 未満の場合、SQL Server で STRING_SPLIT 関数を見つけて実行することができません。 |
SQL Server 2016 (13.x) より前の SQL Server の初期のバージョンのトレース フラグ 4199 での修正プログラムは、既定で有効になりました。 互換モードは 130 です。 トレース フラグ 4199 は、SQL Server 2016 (13.x) の後にリリースされる、クエリ オプティマイザーの新しい修正プログラムに対しても引き続き適用することができます。 SQL Database で古いクエリ オプティマイザーを使用するには、互換性レベル 110 を選択する必要があります。 トレース フラグ 4199 については、「トレース フラグ 4199」を参照してください。
より低い互換性レベルとレベル 120 の相違点
ここでは、互換性レベル 120 に導入された新しい動作について説明します。
| 互換性レベル設定 110 以下 | 互換性レベル設定 120 |
|---|---|
| 以前のクエリ オプティマイザーが使用されます。 | SQL Server 2014 (12.x) では、クエリ プランを作成し最適化するコンポーネントに大幅な改良が加えられました。 この新しいクエリ オプティマイザー機能は、データベース互換性レベル 120 を使用している場合にのみ利用できます。 これらの改良点を利用するには、データベースの互換性レベル 120 を使用して新しいデータベース アプリケーションを開発する必要があります。 以前のバージョンの SQL Server から移行されたアプリケーションについては、良好なパフォーマンスが維持されているか、またはパフォーマンスが向上していることを確認するために慎重にテストを実行する必要があります。 パフォーマンスが低下する場合は、データベースの互換性レベルを 110 以前に設定して、古いクエリ オプティマイザーの方法を使用することができます。 データベースの互換性レベル 120 に設定した場合は、最新のデータ ウェアハウスと OLTP ワークロード向けにチューニングされた新しいカーディナリティ推定機能が使用されます。 パフォーマンスの問題のため、データベース互換レベルを 110 に設定する前に、SQL Server 2014 (12.x) のデータベース エンジンの新機能に関する記事のクエリ プランのセクションで説明されている推奨事項を参照してください。 |
| 互換性レベルが 120 未満の場合、日付値を文字列値に変換すると、言語設定は無視されます。 この動作は date 型に固有です。 Examples セクションの B の例を参照してください。 | date 値を文字列値に変換するとき、言語設定は無視されません。 |
EXCEPT 句の右側にある再帰参照によって、無限ループが作成されます。 Examples セクションの例 C は、この動作を示しています。 |
EXCEPT句の再帰参照では、ANSI SQL 標準に準拠してエラーが生成されます。 |
| 再帰共通テーブル式 (CTE) では重複する列名を使用できます。 | 再帰 CTE では、重複する列名を使用できません。 |
| 無効化されたトリガーは、トリガーが変更されると有効になります。 | トリガーを変更しても、トリガーの状態 (有効または無効) は変更されません。 |
OUTPUT INTO テーブル句では、IDENTITY_INSERT SETTING = OFF が無視され、明示的な値を挿入できます。 |
IDENTITY_INSERT が OFF に設定されているときは、テーブルの ID 列に明示的な値を挿入できません。 |
データベースの包含状態が PARTIAL に設定されている場合、MERGE ステートメントの OUTPUT 句にある $action フィールドを検証すると、照合順序のエラーが確認されることがあります。 |
MERGE ステートメントの $action 句によって返される値の照合順序は、サーバー照合順序ではなく、データベース照合順序です。また、照合順序の競合エラーは返されません。 |
SELECT INTO ステートメントでは、常にシングル スレッドの挿入操作が作成されます。 |
SELECT INTO ステートメントでは、並列挿入操作を作成できます。 多数の行を挿入するときは、並列操作によってパフォーマンスを向上させることができます。 |
より低い互換性レベルとレベル 100 および 110 の相違点
このセクションでは、互換性レベル 110 で導入された新しい動作について説明します。 このセクションは、110 より大きい互換性レベルにも適用されます。
| 互換性レベル設定 100 以下 | 互換性レベル設定 110 以上 |
|---|---|
| 共通言語ランタイム (CLR) のデータベース オブジェクトは、CLR の Version 4 で実行されます。 ただし、CLR の Version 4 で導入されたいくつかの動作の変更が回避されます。 詳細については、CLR 統合の新機能に関するページを参照してください。 | CLR のデータベース オブジェクトは、CLR の Version 4 で実行されます。 |
| XQuery 関数の string-length と substring は、各サロゲートを 2 つの文字としてカウントします。 | XQuery 関数の string-length および substring は、各サロゲートを 1 つの文字としてカウントします。 |
PIVOT は再帰共通テーブル式 (CTE) のクエリで許可されます。 ただし、グループごとに複数の行がある場合、クエリからは誤った結果が返されます。 |
PIVOT は再帰共通テーブル式 (CTE) のクエリで許可されません。 エラーが返されます。 |
| RC4 アルゴリズムは、旧バージョンとの互換性のためにのみサポートされています。 データベース互換性レベルが 90 または 100 の場合、新しい素材は RC4 または RC4_128 を使用してのみ暗号化できます (非推奨)。SQL Server 2012 (11.x) では、どの互換性レベルでも、RC4 または RC4_128 を使用して暗号化された素材を暗号化解除できます。 | RC4 または RC4_128 を使用して新素材を暗号化することはできません。 AES アルゴリズムのいずれかなど、新しいアルゴリズムを使用してください。 SQL Server 2012 (11.x) では、どの互換性レベルでも、RC4 または RC4_128 を使用して暗号化された素材を暗号化解除できます。 |
time および datetime2 データ型に対する CAST および CONVERT 操作の既定のスタイルは、いずれかの型が計算列の式で使用されている場合を除き、121 です。 計算列の場合、既定のスタイルは 0 です。 この動作は、計算列が作成されるとき、自動パラメーター化を含むクエリで使用されるとき、または制約の定義で使用されるときに、計算列に影響を与えます。Examples セクションの例 D は、スタイル 0 と 121 の違いを示しています。 上記の動作は示しません。 date および time スタイルの詳細については、「CAST および CONVERT」を参照してください。 |
互換性レベル 110 では、time および datetime2 データ型に対する CAST および CONVERT 操作の既定のスタイルは常に 121 です。 クエリが古い動作に依存する場合は、110 より小さい互換性レベルを使用するか、または影響を受けるクエリで 0 スタイルを明示的に指定してください。データベースを互換性レベル 110 にアップグレードしても、ディスクに格納されているユーザー データは変更されません。 このようなデータは手動で適切に修正する必要があります。 たとえば、 SELECT INTO を使用して、前に説明した計算列の式を含むソースからテーブルを作成した場合は、計算列の定義自体ではなく、(スタイル 0 を使用する) データが格納されます。 このようなデータは、手動で更新してスタイル 121 に一致させる必要があります。 |
| + (加算)演算子は、date、time、datetime2、またはdatetimeoffset型がdatetimeまたはsmalldatetimeのオペランドに適用できます。 | 加算演算子を、date、time、datetime2、または datetimeoffset 型のオペランドと、datetime または smalldatetime 型のオペランドに適用しようとすると、エラー 402 が発生します。 |
| パーティション ビューで参照されるリモート テーブルの smalldatetime 型の列は、datetime としてマップされます。 ローカル テーブルの対応する列 (選択リストの同じ順番にある列) は、datetime 型であることが必要です。 | パーティション ビューで参照されるリモート テーブルの smalldatetime 型の列は、smalldatetime としてマップされます。 ローカル テーブルの対応する列 (選択リストの同じ順番にある列) は、smalldatetime 型であることが必要です。 110 にアップグレードした後は、データ型の不一致により、分散パーティション ビューは失敗します。 この問題を解決するには、リモート テーブルでのデータ型を datetime に変更するか、またはローカル データベースの互換性レベルを 100 以下に設定します。 |
SOUNDEX 関数では次のルールが実装されます。1) SOUNDEX コードで同じ数値が割り当てられている 2 つの子音を区切る場合、大文字の H または大文字の W は無視されます。2) character_expression の最初の 2 文字に SOUNDEX コードの同じ数値が割り当てられている場合は、両方の文字が含まれます。 または、並んでいる一連の子音に SOUNDEX コードの同じ数値が割り当てられている場合は、最初の文字を除いてすべて除外されます。 |
SOUNDEX 関数では次のルールが実装されます。1) SOUNDEX コードの同じ数値が割り当てられている 2 つの子音の間に大文字の H または大文字の W がある場合、右側の子音は無視されます。2) 並んでいる一連の子音に SOUNDEX コードの同じ数値が割り当てられている場合は、最初の文字を除いてすべて除外されます。追加の規則により、 SOUNDEX 関数によって計算された値が、以前の互換性レベルで計算された値とは異なる場合があります。 互換性レベル 110 にアップグレードした後、 SOUNDEX 関数を使用するインデックス、ヒープ、または CHECK 制約の再構築が必要になる場合があります。 詳細については、SOUNDEX に関するページを参照してください。 |
STRING_AGG は、<order_clause> なしで使用できます。 |
STRING_AGG は、省略可能な <order_clause> と共に使用できます。 詳細については、STRING_AGG に関する記事を参照してください |
互換性レベル 90 とレベル 100 の相違点
このセクションでは、互換性レベル 100 で導入された新しい動作について説明します。
| 互換性レベル設定 90 | 互換性レベル設定 100 | 影響度 |
|---|---|---|
| QUOTED_IDENTIFIER設定は、セッション レベルの設定に関係なく、複数ステートメントテーブル値関数が作成されるときに常に ON に設定されます。 | 複数ステートメントのテーブル値関数が作成されるとき、QUOTED IDENTIFIER のセッション設定が受け入れられます。 | Medium |
| パーティション関数を作成または変更するとき、関数の datetime リテラルおよび smalldatetime リテラルは、言語設定が US_English であることを前提に評価されます。 | パーティション関数の datetime リテラルおよび smalldatetime リテラルを評価する際、現在の言語設定が使用されます。 | Medium |
INSERT および SELECT INTO ステートメントで FOR BROWSE 句は許可されます (ただし無視されます)。 |
INSERT および SELECT INTO ステートメントで FOR BROWSE 句は許可されません。 |
Medium |
OUTPUT 句でフルテキスト述語を使用できます。 |
OUTPUT 句でフルテキスト述語を使用できません。 |
低 |
CREATE FULLTEXT STOPLIST、ALTER FULLTEXT STOPLIST、およびDROP FULLTEXT STOPLIST はサポートされています。 |
低 | |
MERGE は予約キーワードとして適用されません。 |
MERGE は完全に予約されたキーワードです。 MERGE ステートメントは、100 と 90 の両方の互換性レベルでサポートされます。 |
低 |
INSERT ステートメントの <dml_table_source> 引数を使用すると、構文エラーが発生します。 |
入れ子になった INSERT、UPDATE、DELETE、または MERGE ステートメント内の OUTPUT 句の結果をキャプチャして、対象のテーブルまたはビューに挿入することができます。 そのためには、INSERT ステートメントの <dml_table_source> 引数を使用します。 |
低 |
NOINDEX が指定されていない場合、DBCC CHECKDB または DBCC CHECKTABLE は、1 つのテーブルまたはインデックス付きビューとそのすべての非クラスター化インデックスおよび XML インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。 空間インデックスはサポートされません。 |
NOINDEX が指定されていない場合、DBCC CHECKDB または DBCC CHECKTABLE は、1 つのテーブルとそのすべての非クラスター化インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。 ただし、XML インデックス、空間インデックス、およびインデックス付きビューでは、既定で物理的な一貫性のみがチェックされます。WITH EXTENDED_LOGICAL_CHECKS が指定されている場合、インデックス付きビュー、XML インデックス、および空間インデックス (存在する場合) に対して論理チェックが実行されます。 既定では、論理的な一貫性のチェック前に物理的な一貫性がチェックされます。 NOINDEX も指定されている場合は、論理チェックのみが実行されます。 |
低 |
| データ操作言語 (DML) ステートメントで OUTPUT 句を使用した場合、ステートメントの実行時に実行時エラーが発生すると、トランザクション全体が終了し、ロールバックされます。 | データ操作言語 (DML) ステートメントで OUTPUT 句を使用した場合、ステートメントの実行時に実行時エラーが発生したときの動作は、SET XACT_ABORT 設定によって異なります。 SET XACT_ABORT が OFF の場合は、OUTPUT 句を使用している DML ステートメントでステートメント中断エラーが発生すると、ステートメントは終了しますが、バッチの実行は続行され、トランザクションはロールバックされません。 SET XACT_ABORT が ON の場合は、OUTPUT 句を使用している DML ステートメントで実行時エラーが発生すると、バッチが終了し、トランザクションはロールバックされます。 |
低 |
| CUBE および ROLLUP は予約されたキーワードとして適用されません。 | CUBE および ROLLUP は、GROUP BY 句内では予約されたキーワードです。 |
低 |
| XML の anyType 型の要素には厳密な検証が適用されます。 | anyType 型の要素には緩やかな検証が適用されます。 詳細については、「ワイルドカード コンポーネントと内容検証」を参照してください。 | 低 |
| 特殊な属性 xsi:nil および xsi:type は、データ操作言語ステートメントでクエリまたは変更できません。 つまり、 /e/@xsi:nil は失敗し、/e/@* では xsi:nil 属性と xsi:type 属性が無視されます。 ただし、/e の場合でも、SELECT xmlCol では xsi:nil = "false" との一貫性のために xsi:nil 属性と xsi:type 属性が返されます。 |
特殊な属性 xsi:nil および xsi:type は、標準属性として格納されるので、クエリも変更も可能です。 たとえば、クエリ SELECT x.query('a/b/@*') を実行すると、xsi:nil および xsi:type を含むすべての属性が返されます。 クエリでこれらの型を除外するには、@* を @*[namespace-uri(.) != "insert xsi namespace uri" に置き換え、(local-name(.) = "type" や local-name(.) ="nil". を避けてください。 |
低 |
| XML 定数文字列値を SQL Server datetime 型に変換するユーザー定義関数は、決定論的としてマークされます。 | XML 定数文字列値を SQL Server datetime 型に変換するユーザー定義関数は、非決定的としてマークされます。 | 低 |
| XML の union 型と list 型は、完全にはサポートされていません。 | union 型と list 型は、完全にサポートされています (次の機能を含む)。 リストの和集合 和集合の和集合 アトミック型のリスト 和集合のリスト |
低 |
| xQuery メソッドに必要な SET オプションは、メソッドがビューまたはインライン テーブル値関数に含まれる場合に検証されません。 | xQuery メソッドに必要な SET オプションは、メソッドがビューまたはインライン テーブル値関数に含まれる場合に検証されます。 メソッドの SET オプションが正しく設定されていない場合は、エラーが発生します。 | 低 |
| 行末文字 (復帰と改行) を含む XML 属性値は、XML 標準に従って正規化されません。 つまり、1 つの改行文字ではなく両方の文字が返されます。 | 行末文字 (復帰と改行) を含む XML 属性値は、XML 標準に従って正規化されます。 つまり、外部解析エンティティ (ドキュメント エンティティを含む) のすべての改行が、入力時に正規化されます。このとき、2 文字のシーケンス #xD #xA と、後ろに #xA がない #xD の両方について、1 つの #xA 文字に変換されます。 行末文字を含む文字列値を転送するための属性を使用しているアプリケーションは、このような文字が送信されても受け取りません。 正規化処理を回避するには、XML 数字エンティティを使用してすべての行末文字をエンコードしてください。 |
低 |
列プロパティ ROWGUIDCOL および IDENTITY は、制約として不適切に指定される可能性があります。 たとえば、ステートメント CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) は実行されますが、制約名は保持されず、ユーザーはその制約にアクセスできません。 |
列プロパティ ROWGUIDCOL および IDENTITY は、制約として指定できません。 エラー 156 が返されます。 |
低 |
UPDATE T1 SET @v = column_name = <expression> などの双方向の代入を使用して列を更新すると、予期しない結果が生じる可能性があります。これは、ステートメントの実行時に、WHERE 句や ON 句などの他の句でステートメントの開始値ではなく変数の有効期限の値を使用できるためです。 これにより、述語の意味が行ごとに予期せず変化することがあります。この動作は、互換性レベルが 90 に設定されている場合にのみ適用されます。 |
双方向の代入を使用して列を更新すると、予想どおりの結果が生じます。これは、ステートメントの実行時に、列のステートメントの開始値のみが利用されるためです。 | 低 |
最上位レベルの UNION 演算子を含むステートメントでは変数の代入が許可されますが、予期しない結果が返されます。 詳細については、例 E を参照してください。 |
変数代入は、最上位レベルの UNION 演算子を含むステートメントでは許可されていません。 エラー 10734 が返されます。 推奨される書き換えについては、例 E を参照してください。 | 低 |
ODBC 関数 {fn CONVERT()} では、言語の既定の日付形式が使用されます。 言語によっては、既定の形式が YDM の場合があります。この場合、CONVERT() を {fn CURDATE()} などの YMD 形式が想定されている他の関数と組み合わせて使用すると、変換エラーが発生する可能性があります。 |
ODBC 関数 {fn CONVERT()} では、ODBC データ型 SQL_TIMESTAMP、SQL_DATE、SQL_TIME、SQLDATE、SQL_TYPE_TIME、および SQL_TYPE_TIMESTAMP への変換時にスタイル 121 (言語に依存しない YMD 形式) が使用されます。 |
低 |
DATEPARTなどの Datetime 組み込み関数では、文字列入力値を有効な datetime リテラルにする必要はありません。 たとえば、SELECT DATEPART (year, '2007/05-30') は正常にコンパイルされます。 |
DATEPART などの datetime 組み込み関数では、文字列入力値が有効な datetime リテラルである必要があります。 無効な datetime リテラルを使用すると、エラー 241 が返されます。 |
低 |
REPLACE 関数の最初の入力パラメーターで指定された末尾のスペースは、パラメーターが char 型の場合にトリミングされます。 たとえば、ステートメント SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>'では、 'ABC ' 値が正しく 'ABC'として評価されません。 |
末尾のスペースは常に保持されます。 関数の以前の動作に依存するアプリケーションの場合は、関数の最初の入力パラメーターを指定するときに RTRIM 関数を使用します。 たとえば、次の構文は SQL Server 2005 の動作を再現します: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'。 |
低 |
予約されているキーワード
互換性設定では、データベース エンジンで予約されているキーワードも判別されます。 次の表に、各互換性レベルで使用される予約済みキーワードを示します。
| 互換性レベルの設定 | 予約済みキーワード |
|---|---|
130 |
決断される。 |
120 |
なし。 |
110 |
WITHIN GROUP、 TRY_CONVERT、 SEMANTICKEYPHRASETABLE、 SEMANTICSIMILARITYDETAILSTABLE、 SEMANTICSIMILARITYTABLE |
100 |
CUBE、 MERGE、 ROLLUP |
90 |
EXTERNAL、 PIVOT、 UNPIVOT、 REVERT、 TABLESAMPLE |
各互換性レベルの予約済みキーワードには、そのレベル以下で導入されるキーワードもすべて含まれています。 したがって、たとえばレベル 110 のアプリケーションの場合、上の表に一覧表示されているすべてのキーワードが予約されています。 それより下位の互換性レベルでは、レベル 100 のキーワードは有効なオブジェクト名ですが、そのキーワードに対応するレベル 110 の言語機能は使用できません。
キーワードはいったん導入されると、キーワードの予約が維持されます。 たとえば、互換性レベル 90 で導入された予約済みキーワード PIVOT は、レベル 100、110、および 120 でも予約済みとして扱われます。
互換性レベル設定でキーワードとして予約した識別子をアプリケーションで使用しようとすると、アプリケーションは失敗します。 この問題を回避するには、識別子をかっこ ( [] ) または引用符 ( "" ) で囲みます。たとえば、識別子 EXTERNAL を使用しているアプリケーションを互換性レベル 90 にアップグレードするには、識別子を [EXTERNAL] または "EXTERNAL" のいずれかに変更します。
詳細については、「予約済みキーワード」を参照してください。
アクセス許可
データベースに対する ALTER 権限が必要です。
例
A. 互換性レベルの変更
次の例では、sql Server 2019 (15.x) の既定値である AdventureWorks2022 サンプル データベース データベースの互換性レベルを 150 に変更します。
ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO
次の例では、現在のデータベースの互換性レベルを返します。
SELECT name, compatibility_level
FROM sys.databases
WHERE name = db_name();
GO
B. 互換性レベルが 120 以上の場合を除き、SET LANGUAGE ステートメントを無視する
次のクエリでは、互換性レベルが 120 以上の場合を除き、SET LANGUAGE ステートメントは無視されます。
SET DATEFORMAT dmy;
DECLARE @t2 date = '12/5/2011' ;
SET LANGUAGE dutch;
SELECT CONVERT(varchar(11), @t2, 106);
GO
互換性レベルが 120 未満の場合の結果: 12 May 2011
互換性レベルが 120 以上に設定されている場合の結果: 12 mei 2011
C. 互換性レベルが 110 以下に設定されている場合、EXCEPT 句の右側にある再帰参照によって、無限ループが作成されます。
WITH cte AS
(SELECT * FROM (VALUES (1),(2),(3)) v (a)),
r AS
(SELECT a FROM cte
UNION ALL
(SELECT a FROM cte EXCEPT SELECT a FROM r)
)
SELECT a
FROM r;
GO
D. スタイル 0 とスタイル 121 の相違点
互換性レベルが 110 未満の場合、time および datetime2 データ型に対する CAST および CONVERT 操作の既定のスタイルは、いずれかの型が計算列の式で使用されている場合を除き、121 です。 計算列の場合、既定のスタイルは 0 です。
互換性レベルが 110 以上の場合、time および datetime2 データ型に対する CAST および CONVERT 操作の既定のスタイルは常に 121 です。 詳細については、「より低い互換性レベルとレベル 100 および 110 の相違点」を参照してください。
日付および時刻のスタイルの詳細については、CAST および CONVERT に関するページを参照してください。
DROP TABLE IF EXISTS t1;
GO
CREATE TABLE t1 (c1 time(7), c2 datetime2);
GO
INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE());
GO
SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0
,CONVERT(nvarchar(16),c1,121)AS TimeStyle121
,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0
,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121
FROM t1;
GO
これにより、次のような結果が返されます。
| TimeStyle0 | TimeStyle121 | Datetime2Style0 | Datetime2Style121 |
|---|---|---|---|
| 3:15PM | 15:15:35.8100000 | Jun 7 2011 3:15PM | 2011-06-07 15:15:35.8130000 |
E. 変数代入 - 最上位レベルの UNION 演算子
データベース互換レベルの設定が 90 の場合、変数の代入は、最上位レベルの UNION 演算子を含むステートメントで許可されますが、予期しない結果が返されます。 たとえば、次のステートメントでは、2 つのテーブルの和集合からの列 BusinessEntityID の値がローカル変数 @v に割り当てられます。 定義上、SELECT ステートメントが複数の値を返した場合は、最後に返された値が変数に割り当てられます。 この場合は、最後の値が変数に正しく割り当てられますが、SELECT UNION ステートメントの結果セットも返されます。
ALTER DATABASE AdventureWorks2022
SET compatibility_level = 110;
GO
USE AdventureWorks2022;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;
データベース互換レベルの設定が 100 以上の場合、変数の代入は、最上位レベルの UNION 演算子を含むステートメントで許可されません。 エラー 10734 が返されます。
エラーを解決するには、次の例で示すようにクエリを書き直してください。
DECLARE @v int;
SELECT @v = BusinessEntityID FROM
(SELECT BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;