次の方法で共有


互換性証明書

適用対象: SQL Server Azure SQL Database Azure SQL Managed Instance

互換性証明書を利用すると、企業はオンプレミス、クラウド、エッジに置いている SQL Server データベースをアップグレードし、最新化し、アプリケーションの互換性リスクをなくすことができます。

同じデータベース エンジンが SQL Server と Azure SQL Database (Azure SQL Managed Instance を含む) の両方を支援します。 このようにデータベース エンジンが共有されることで、ユーザー データベースをオンプレミスの SQL Server と Azure SQL Database の間でシームレスに移動できて、かつ、Transact-SQL としてデータベースで実行されるアプリケーション コードはそのソース システムで実行される場合と同様に機能します。

SQL Server が新しくリリースされるたびに、既定の互換性レベルが データベース エンジン のバージョンに設定されます。 ただし、以前のバージョンの互換性レベルが維持され、既存のアプリケーションの互換性が残ります。 この互換性マトリックスはこちらで確認できます。 そのため、特定の SQL Server バージョンで動作することが認定されているアプリケーションは、実際にはそのバージョンの既定の互換性レベルで動作することが認定されていました

たとえば、データベース互換性レベル 130 は SQL Server 2016 (13.x) の既定でした。 互換性レベルは Transact-SQL の特定の機能およびクエリ最適化動作を強制するものであるため、SQL Server 2016 (13.x) で動作することが認定されたデータベースはデータベース互換性レベル 130 で暗黙的に認定されていました。 このデータベースは、データベース互換性レベルが 130 で維持される限り、SQL Server (SQL Server 2019 (15.x) など) と Azure SQL データベース の最近のバージョンで現状のまま動作できます。

これは Microsoft Azure SQL データベース 継続的インテグレーション運用モデルの基本原則です。 データベース エンジン は Azure で継続的に改善され、アップグレードされますが、既存のデータベースで現行の互換性レベルが維持されるため、基礎となる データベース エンジン にアップグレードされた後でも、引き続き設計どおりに動作します。

SQL Server および Azure SQL Managed Instance での SharePoint Server 2016 と SharePoint Server 2019 の認定も、この方法で行われます。これにより、これらのバージョンの SharePoint Server に対して、サポートされているデータベース互換性レベルを使用できる SQL Server データベース エンジン を配置できるようになります。 詳細については、「SharePoint Server 2016 のハードウェア要件およびソフトウェア要件」と、「SharePoint Server 2019 のハードウェア要件およびソフトウェア要件」を参照してください。

互換性証明書を使用してアップグレード リスクを管理する

互換性証明書の使用は、データベースの最新化に役立つアプローチです。 互換性レベルに基づいて認定することで、開発者は SQL Server と Azure SQL データベース でサポートするアプリケーションの技術的要件を設定しつつ、アプリケーションのライフサイクルをデータベース プラットフォームのライフサイクルから切り離します。 そうすることで、企業はライフサイクル ポリシーの必要に応じて SQL Server データベース エンジンを継続的にアップグレードして、コードに依存しない新しい拡張性やパフォーマンス拡張機能を使用できます。また、接続しているアプリケーションは、アップグレードを通してその機能的ステータスを維持します。

機能性とパフォーマンスに悪影響を与える可能性は、いかなるアップグレードにおいても主要なリスク要因です。 互換性証明書は、そのようなアップグレード リスクの管理に安心を与えます。

  • Transact-SQL の動作に関連するものにおいて、あらゆる変更は、あるアプリケーションが正しいことを再認定する必要があることを意味します。 しかしながら、データベース互換性レベル設定は、サーバー全体ではなく、指定のデータベースに対してのみ、以前のバージョンの SQL Server との下位互換性を与えます。 データベース互換性レベルを現状のまま維持することで、データベース エンジン アップグレードの前後で、既存のアプリケーション クエリは引き続き同じ動作を示します。 Transact-SQL の動作と互換性レベルについては、「旧バージョンとの互換性を維持するための互換性レベルの使用」を参照してください。

  • パフォーマンスに関連するものにおいて、クエリ オプティマイザーの機能拡張がすべてのバージョンで導入されるため、データベース エンジン のバージョンが異なれば、クエリ プランが異なることが予想される可能性があります。 一部の変更が特定のクエリまたはワークロードにとって害になる可能性がある場合、1 つのアップグレードの範囲におけるクエリ プランの違いは通常、リスクとなります。 また、このリスクは通常、アプリケーションの再認証の必要性につながり、アップグレードを遅らせたり、ライフサイクルとサポートの問題を引き起こしたりすることがあります。

    アップグレード リスクの軽減は、クエリ オプティマイザーの機能拡張が新しいリリースの既定互換性レベルに制限される理由です (言い換えると、あらゆる新しいバージョンで最も高い互換性レベルを利用できます)。 互換性証明書には、クエリ プラン シェイプ保護が含まれます。データベース エンジン アップグレードの直後、データベース互換性レベルを現状のまま維持するという考えは、新しいバージョンでアップグレード前と同じクエリ最適化モデルを使用するということであり、クエリ プラン シェイプは変更されません。

    詳細については、この記事の「クエリ プラン シェイプを使用する理由」セクションを参照してください。

互換性レベルの詳細については、「旧バージョンとの互換性を維持するための互換性レベルの使用」を参照してください。

重要

特定の互換性レベルに対して既に認定されている既存のアプリケーションについては、SQL Server データベース エンジン をアップグレードし、以前のデータベース互換性レベルを維持します。 このシナリオでは、アプリケーションを再認定する必要はありません。 詳細については、この記事の後半に出てくる「互換性レベルとデータベース エンジンのアップグレード」を参照してください。

新しい開発作業の場合、またはインテリジェント クエリ処理のような新しい機能と一部の新しい Transact-SQL を既存のアプリケーションで使用する必要があるときは、データベース互換性レベルを SQL Server で利用できる最新のレベルにアップグレードすることを計画し、その互換性レベルでアプリケーションが動作することを再認定します。 データベース互換性レベルのアップグレードに関する詳細については、「データベース互換性レベルのアップグレードのベスト プラクティス」を参照してください。

クエリ プラン シェイプを使用する理由

クエリ プラン シェイプは、クエリ プランを構成するさまざまな演算子の視覚的表現を指します。 これには、シーク、スキャン、結合、並べ替えなどの演算子に加えて、データの流れを示す演算子間のつながりと、意図した結果セットを生成するために実行する必要がある演算の順序が含まれます。 クエリ プラン シェイプは、クエリ オプティマイザーによって決定されます。

アップグレード中のクエリ パフォーマンスを常に予測できるように、基本的な目標の 1 つは、同じクエリ プラン シェイプを使用することになります。 これは、基礎となる データベース エンジン のバージョンが異なる場合でも、アップグレードの直後にデータベース互換性レベルを変更しないことで達成できます。 他には、クエリ実行エコシステムで変更がない場合 (利用できるリソースの大幅な変更など)、または基礎データのデータ配布で変更がない場合、クエリのパフォーマンスを変えないでください。

ただし、クエリ プランのシェイプを維持することは、アップグレード後のパフォーマンスに影響を及ぼす唯一の要因ではありません。 データベースを新しい データベース エンジン に移動し、環境も変える場合、クエリ プランでバージョンに関係なく同じシェイプが維持されるとしても、クエリのパフォーマンスに直後に影響を与える要因が持ち込まれる可能性があります。 そのような環境の変更には、新しい データベース エンジン で利用できるメモリと CPU を増やす/減らす、サーバーまたはデータベースの構成オプションを変更する、クエリ プランの作成方法に影響を与えるデータ配布を変更するなどがあります。 このような理由から、データベース互換性レベルを維持するとクエリ プラン シェイプの変更の影響を受けずに済むが、クエリのパフォーマンスに影響を与える他の環境的変更 (ユーザーが変更を始めることもある) からは守られないということを理解しておくことが重要です。

詳細については、「クエリ処理アーキテクチャ ガイド」をご覧ください。

互換性証明書の利点

データベースの認定には、名前付きバージョン手法ではなく互換性基準手法として直接の利点があります。

  • アプリケーション認定をプラットフォームから分離します。 データベース エンジンを共有することで、Transact-SQL クエリを実行する必要があるだけのアプリケーションの場合、Azure とオンプレミスで別々の認定プロセスを維持する必要はありません。
  • アップグレード リスクを減らします。データベース プラットフォームを最新化するとき、アプリケーションとプラットフォーム レイヤーのアップグレード サイクルを分離できるため、中断が少なくなり、変更管理が改善されます。
  • コードを変更せずにアップグレードします。 互換性レベルをソース システムと同じに維持することで、コードを変更せずに、SQL Server または Azure SQL Database の新しいバージョンにアップグレードできます。より高いデータベース互換性レベルでのみ利用できる拡張機能をアプリケーションで使用する必要がない限り、すぐに再認定する必要はありません。
  • 管理性とスケーラビリティを向上させます。データベース互換性レベルで制限されない拡張機能を使用することで、アプリケーションを変更しなくても、これらを向上させることができます。 SQL Server の場合、次のような例があります。

新しいデータベースは データベース エンジン バージョンの既定の互換性レベルに引き続き設定されます。 ただし、データベースを以前のバージョンの SQL Server から新しいバージョンの SQL Server または Azure SQL Database に復元またはアタッチする場合、データベースは既存の互換性レベルを維持します。

重要

SQL Server または Azure SQL データベース の新しいバージョンにデータベースを移す前に、データベース互換性レベルが引き続きサポートされることを確認します。 データベース互換性レベル サポート マトリックスはこちらで確認できます。

許可されるレベル (たとえば、SQL Server 2005 (9.x) の既定値であった 90) より低い互換性レベルのデータベースをアップグレードすると、許可される最も下の互換性レベル (100) にデータベースが設定されます。

現在の互換性レベルを特定するには、sys.databasescompatibility_level 列に対してクエリを実行します。

互換性レベルとデータベース エンジンのアップグレード

アップグレード前に存在したデータベース互換性レベルとそのサポート可能なステータスを維持しながら、データベース エンジン を最新バージョンにアップグレードするには、データベース (ストアド プロシージャ、関数、トリガーなどのプログラミング オブジェクト) およびアプリケーション (アプリケーションによって送信される動的コードをキャプチャするワークロード トレースを使用) において、アプリケーション コードの攻撃可能な領域に静的な機能検証を実行することをお勧めします。

これは、Microsoft Data Migration Assistant ツール (DMA) を使用して簡単に行うことができます。 DMA ツールの出力でエラーが見つからなければ、あるいは機能性に不足や非互換性がなければ、新しいターゲット バージョンでアプリケーションの機能が退化することはありません。 データベースが新しいバージョンで動作することを保証するために変更が必要な場合は、DMA を使用して、変更が必要な箇所と使用できる回避策を特定できます。 詳細については、「Data Migration Assistant の概要」を参照してください。

ヒント

この機能検証は、レガシ バージョン (SQL Server 2008 R2 (10.50.x) や SQL Server 2012 (11.x) など) から新しいバージョンの SQL Server または Azure SQL Database にデータベースを移動する場合に特に重要です。データベース互換性レベルで保護されていない、廃止された Transact-SQL がアプリケーション コードで使用される可能性があるためです。 ただし、より新しいバージョン (SQL Server 2016 (13.x) など) から SQL Server 2019 (15.x) または Azure SQL Database に移行する場合は、廃止された Transact-SQL について心配する必要はありません。 廃止された Transact-SQL の詳細については、「旧バージョンとの互換性を維持するための互換性レベルの使用」を参照してください。

注意

DMA は、レベル 100 以降のデータベース互換性レベルに対応しています。 ソース バージョンとしての SQL Server 2005 (9.x) は除外されます。

重要

Microsoft では、最小限のテストをいくつか行い、アップグレードが成功し、さらに前のデータベース互換性レベルが維持されていることを確認することをお勧めしています。 自分のアプリケーションとシナリオでは何が「最小限のテスト」に相当するのかは、ご自身で判断してください。

重要

Microsoft は、次の場合にクエリ プラン シェイプ保護を提供します。

  • 前の SQL Server バージョン (ソース) が実行されていたハードウェアに相当するハードウェアで新しい SQL Server バージョン (ターゲット) が実行されるとき。
  • ターゲット SQL Server とソース SQL Server の両方で同じサポートされているデータベース互換性レベルが使用されるとき。
  • ターゲット SQL Server とソース SQL Server の両方で、同じデータベースとワークロードが使用されます。

上の条件で発生する (ソース SQL Server と比較したときの) クエリ プラン シェイプ退化は対処されます。 このような場合は、Microsoft カスタマー サポートにお問い合わせください。

こちらもご覧ください