データベース エンジンのアップグレード プランの策定およびテスト
適用対象: SQL Server - Windows only
SQL Server のアップグレードを成功させるには、どんな手法であろうと、適切な計画を立てる必要があります。
リリース ノートとアップグレードの既知の問題
データベース エンジン をアップグレードする前に次を確認してください。
- SQL Server 2022 リリース ノート
- SQL Server 2019 リリース ノート
- SQL Server 2017 リリース ノート
- SQL Server 2016 リリース ノート
- 「SQL Server データベース エンジンの後方互換対応」の記事。
アップグレード前の計画チェックリスト
データベース エンジンをアップグレードする前に、次のチェックリストと関連する記事を確認します。 これらの記事は、アップグレードの方法に関係なく、すべてのアップグレードに適用され、次の中から最適なアップグレード方法を決定するのに役立ちます: ローリング アップグレード、新しいインストールのアップグレード、またはインプレース アップグレード。 たとえば、オペレーティング システムのアップグレード、SQL Server 2005 (9.x) からのアップグレード、または SQL Server の 32 ビット バージョンからアップグレードの場合、インプレース アップグレードまたはローリング アップグレードは実行できない場合があります。 デシジョン ツリーについては、「 Choose a Database Engine Upgrade Method」を参照してください。
ハードウェアとソフトウェアの要件: SQL Server をインストールするためのハードウェアとソフトウェアの要件を確認します。 これらの要件は、「SQL Server のインストールに必要なハードウェアおよびソフトウェア」で確認できます。 アップグレード計画サイクルの一環として、ハードウェアとオペレーティング システムのアップグレードを検討する必要があります。 新しいハードウェアはより高速で、プロセッサ数の縮小やデータベースとサーバーの統合によりライセンス数を減らすことができます。 この種のハードウェアとソフトウェアの変更は、アップグレード方法の種類の選定に影響を与えます。
現在の環境: 現在の環境を調査して、使用されている SQL Server コンポーネントと、実際の環境に接続されているクライアントを把握します。
クライアント プロバイダー: アップグレード中はクライアントごとにプロバイダーを更新する必要はありませんが、更新してもかまいません。 SQL Server 2014 (12.x) 以前からアップグレードする場合、次の SQL Server 2016 (13.x) 機能では、クライアントごとに更新されたプロバイダー、または追加機能を利用するために更新されたプロバイダーが必要です。
-
重要
拡張データベースは、SQL Server 2022 (16.x) および Azure SQL Database では非推奨になります。 この機能は、データベース エンジンの将来のバージョンで削除される予定です。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。
TLS セキュリティ更新プログラム
サードパーティ コンポーネント: 統合バックアップなどのサードパーティ製のコンポーネントの互換性を確認します。
ターゲット環境: ターゲット環境がハードウェアとソフトウェアの要件を満たしていることと、元のシステム要件をサポートできることを確認します。 たとえば、アップグレードでは、複数の SQL Server インスタンスを 1 つの新しい SQL Server インスタンスに統合すること、または SQL Server 環境をプライベートまたはパブリック クラウドに対して仮想化することが必要な場合があります。
エディション: アップグレードで必要な SQL Server の適切なエディションを決定し、アップグレードのための有効なアップグレード パスを決定します。 詳細については、「 Supported Version and Edition Upgrades」をご覧ください。 SQL Server のいずれかのエディションから別のエディションへアップグレードする前に、現在使用している機能がアップグレード先のエディションでサポートされているかどうかを確認します。
Note
SQL Server を前バージョンの SQL Server Enterprise エディションからアップグレードする場合、Enterprise Edition: コアベース ライセンスもしくは Enterprise Editionのいずれかを選ぶことができます。 これらの Enterprise エディションは、ライセンス モードのみが異なります。 詳細については、「 Compute Capacity Limits by Edition of SQL Server」を参照してください。
後方互換対応: SQL Server データベース エンジンの後方互換対応に関する記事を参照して、SQL Server とアップグレード対象の SQL Server バージョンとの間の動作の違いについて確認します。 「 SQL Server Database Engine Backward Compatibility」を参照してください。
Data Migration Assistant: アップグレード プロセスを妨げるおそれのある問題、あるいは破壊的変更により既存のスクリプトまたはアプリケーションの修正が必要な問題について、Data Migration Assistant を実行して診断を行うことができます。
Data Migration Assistant はここからダウンロードできます。
システム構成チェッカー: アップグレードをスケジュールする前に、SQL Server システム構成チェッカー (SCC) を実行して、SQL Server セットアップ プログラムでセットアップに支障をきたす問題が検出されていないか判定します。 詳細については、「 Check Parameters for the System Configuration Checker」を参照してください。
メモリ最適化テーブルのアップグレード: メモリ最適化テーブルを含む SQL Server 2014 (12.x) インスタンスを SQL Server 2016 (13.x) 以降にアップグレードする場合、アップグレード プロセスでは、メモリ最適化テーブルをディスク上の新しいフォーマットに変換するために、さらに時間が必要になります。 このプロセス中、データベースはオフラインです。 メモリ最適化テーブルのサイズとI/O サブシステムの速度により、所要時間が異なります。 インプレース アップグレードと新規インストール アップグレードの場合は、3 種類のデータ操作が必要です (ローリング アップグレードでは手順 1 は不要、手順 2 と手順 3 は必要です)。
古いディスク上のフォーマットを使用してデータベースの回復を実行する (メモリ最適化テーブル内のすべてのデータを、ディスクからメモリに読み込む操作を含む)
データを新しいディスク上のフォーマットでディスクにシリアル化する
新しいフォーマットを使用してデータベースの回復を実行する (メモリ最適化テーブル内のすべてのデータを、ディスクからメモリに読み込む操作を含む)
さらに、このプロセス中にディスク上に十分な空き領域がないと、回復は失敗します。 既存のデータベースを格納するのに十分な領域がディスク上に存在することに加えて、インプレース アップグレードを実行する場合、または SQL Server 2016 (13.x) 以降を実行しているインスタンスに SQL Server 2014 (12.x) データベースをアタッチする場合は、データベースの
MEMORY_OPTIMIZED_DATA
ファイル グループにあるコンテナーの現在のサイズと同じ容量のストレージが別途存在することを確認してください。 次のクエリを使用すると、MEMORY_OPTIMIZED_DATA
ファイル グループ用に現在必要なディスク領域と、アップグレードを正常に行うために必要なディスクの空き領域を確認できます。
SELECT CAST(SUM(size) AS FLOAT) * 8 / 1024 / 1024 AS [size in GB] FROM sys.database_files WHERE data_space_id IN ( SELECT data_space_id FROM sys.filegroups WHERE type = N'FX' );
アップグレード計画の作成とテスト
最良の手法は、IT プロジェクトの場合と同様に、アップグレードを処理することです。 アップグレードを行う上で必要なスキル (データベース管理、ネットワーク、抽出、変換、読み込み (ETL) など) を備えたアップグレード チームを編成してください。 チームは次のことを行う必要があります。
アップグレード方法を選択する: 「データベース エンジンのアップグレード方法の選択」を参照してください。
ロールバック計画を作成する: ロールバックする必要がある場合、この計画を実行すると、元の環境を復元できます。
受け入れ基準を決定する: アップグレードが正常に完了したことを確認してから、ユーザーをアップグレードされた環境にカットオーバーします。
アップグレード計画をテストする: 実際のワークロードを使用してパフォーマンスをテストするには、Microsoft SQL Server 分散再生ユーティリティを使用します。 このユーティリティでは、複数のコンピューターを使用してトレース データを再生し、ミッションクリティカルなワークロードをシミュレートできます。 SQL Server のアップグレードの前後でテスト サーバーの再生を実行することで、パフォーマンスの差を測定したり、アップグレード時にアプリケーションに非互換性が発生するかどうかを調べたりすることができます。 詳細については、SQL Server 分散再生と管理ツール コマンド ライン オプション (分散再生ユーティリティ) に関する記事を参照してください。
関連するコンテンツ
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示