次の方法で共有

データベース エンジンのアップグレード メソッドの選択

  • [アーティクル]

適用対象: SQL Server - Windows only

SQL Server の以前のリリースからデータベース エンジンのアップグレードを計画している場合、ダウンタイムとリスクを最小限に抑えるために、考慮すべきいくつかのアプローチがあります。 インプレース アップグレードの実行、新規インストールへの移行、またはローリング アップグレードの実行が可能です。 次のダイアグラムは、これらのアプローチから選択する場合に役立ちます。 ダイアグラム中の各アプローチについては記事の中でも説明します。 図の意思決定ポイントについては、「データベース エンジンのアップグレード計画の策定およびテスト」もご覧ください。

データベース エンジンのアップグレード方法デシジョン ツリーを示す図。

ダウンロード

  • SQL Server をダウンロードするには、Evaluation Center にアクセスしてください。

  • Azure アカウントをすでにお持ちですか? 既にお持ちの場合は、Azure Marketplace にアクセスして、SQL Server Developer エディション がインストール済みの仮想マシンをすぐにご利用いただけます。

Azure SQL のアップグレード オプション

また、アップグレード計画の一環として、Azure SQL Database、Azure SQL Managed Instance のアップグレード、またはSQL Server 環境の仮想化を考慮する場合もあります。 オプションの詳細については、次のリンクを参照してください。

インプレース アップグレード

このアプローチでは、SQL Server セットアップ プログラムは、既存の SQL Server ビットを新しい SQL Server ビットで置き換えて、既存の SQL Server インストールをアップグレードし、次に各システム データベースとユーザー データベースをアップグレードします。

インプレース アップグレード アプローチは最も簡単ですが、ある程度のダウンタイムを必要とし、フォールバックが必要な場合はフォールバックに時間がかかるため、すべてのシナリオでサポートされるわけではありません。 インプレース アップグレードがサポートされるシナリオとサポートされないシナリオの詳細については、「 サポートされているバージョンとエディションのアップグレード」を参照してください。

このアプローチは、次のシナリオでよく使われます。

  • 高可用性 (HA) 構成のない開発環境。

  • ダウンタイムを許容でき、最新のハードウェアとソフトウェアで実行されている非ミッション クリティカル運用環境。 ダウンタイムの長さは、データベースのサイズと、I/O サブシステムの速度によって異なります。 メモリ最適化テーブルを使用している場合、SQL Server 2014 (12.x)をアップグレードすると、余分な時間がかかります。 詳細については、「 データベース エンジンのアップグレード計画の策定およびテスト」を参照してください。

大まかに言うと、データベース エンジンのインプレース アップグレードに必要な手順は次のとおりです。

非 HA インプレース アップグレードのデータベース エンジン アップグレードを示す図。

詳細な手順については、「Upgrade SQL Server Using the Installation Wizard (Setup)」(インストール ウィザードを使用した SQL Server のアップグレード (セットアップ)) を参照してください。

考慮事項

この SQL Server セットアップ プログラムは、アップグレード前のチェックの一環として、SQL Server インスタンスを停止して再起動します。

SQL Serverをアップグレードすると、以前の SQL Server インスタンスは上書きされて、コンピューター上に存在しなくなります。 アップグレードする前に、 SQL Server データベースおよび以前の SQL Server インスタンスに関連するその他のオブジェクトをバックアップしてください。

新しいインストールへの移行

このアプローチでは、多くの場合に、新しいハードウェア上に、新しいバージョンのオペレーティング システムで新しい SQL Server 環境をビルドしながら、現在の環境を維持します。 新しい環境に SQL Server をインストールしたら、いくつかのステップを実行して、既存の環境から既存のユーザー データベースを新しい環境に移行し、ダウンタイムを最小限に抑えることができるように、新しい環境を準備します。 これらの手順では、以下の移行が含まれます。

  • システム オブジェクト: アプリケーションによっては、シングル ユーザー データベースのスコープの外部にある情報、エンティティ、オブジェクトに依存することがあります。 通常、アプリケーションには、master データベースと msdb データベースへの依存関係があり、ユーザー データベースにも依存関係があります。 ユーザー データベースの外部に格納される (ユーザー データベースを正しく機能させるために必要な) すべてのデータは、対象のサーバー インスタンスで使用できるようにする必要があります。 たとえば、アプリケーションのログインが、master データベースにメタデータとして格納されているため、それらを宛先サーバーで再作成する必要があります。 アプリケーションまたはデータベースのメンテナンス プランが、メタデータが msdb データベースに格納される SQL Server エージェント ジョブに依存している場合、宛先サーバー インスタンスでこれらのジョブを再作成する必要があります。 同様に、サーバーレベルのトリガーのメタデータは master に格納されます。

    アプリケーションのデータベースを別のサーバー インスタンスに移動するときは、移行先サーバー インスタンス上のmasterおよび msdb に、依存しているエンティティとオブジェクトのすべてのメタデータを再作成する必要があります。 たとえば、データベース アプリケーションでサーバー レベルのトリガーを使っている場合、そのデータベースを新しいシステムでアタッチまたは復元するだけでは不十分です。 このデータベースは、master データベース内にそれらのトリガー用のメタデータを手動で作成し直さない限り、正常に動作しません。 詳細については、「データベースを別のサーバー インスタンスで使用できるようにするときのメタデータの管理 (SQL Server)」を参照してください。

  • msdb に格納されている 統合サービス パッケージ:msdb にパッケージを格納する場合、dtutil ユーティリティ を使用してそれらのパッケージをスクリプトに記述するか、新しいサーバーにそれらを再デプロイする必要があります。 新しいサーバーでパッケージを使用する前に、パッケージを SQL Serverにアップグレードする必要があります。 詳細については、「 Upgrade Integration Services Packages」を参照してください。

  • Reporting Services 暗号化キー: レポート サーバー構成で重要なのは、機密情報の暗号化に使用される対称キーのバックアップ コピーの作成です。 キーのバックアップ コピーは多くのルーチン処理で必要とされ、キーのバックアップ コピーにより新しいインストールで既存のレポート サーバー データベースを再利用できます。 詳細については、「 Reporting Services の暗号化キーのバックアップと復元 」および「 Upgrade 」および「 Migrate Reporting Services」を参照してください

新しい SQL Server 環境に既存の環境と同じシステム オブジェクトを設定したら、既存のシステムのダウンタイムを最小限に抑える方法で、ユーザー データベースを既存のシステムから、SQL Server インスタンスに移行します。 データベースの移行を実行するには、バックアップと復元を使用するか、SAN 環境内の場合は LUN を再指定します。 次の図は両方の方法の手順を示したものです。

注意事項

ダウンタイムの長さは、データベースのサイズと、I/O サブシステムの速度によって異なります。 メモリ最適化テーブルを使用している場合、SQL Server 2014 (12.x) をアップグレードすると、余分な時間がかかることがあります。 詳細については、「 データベース エンジンのアップグレード計画の策定およびテスト」を参照してください。

ユーザー データベースを移行した後、いくつかの方法 (サーバー名の変更、DNS エントリの使用、接続文字列の変更など) のいずれかを使って、新しいユーザーを新しい SQL Server インスタンスに誘導します。 新規インストール アプローチでは、インプレース アップグレードと比べて、リスクとダウンタイムが減り、SQL Server へのアップグレードに伴うのハードウェアとオペレーティング システムをアップグレードするのが容易になります。

Note

既に高可用性 (HA) ソリューションを設置しているなど、 SQL Serverインスタンスが複数ある環境の場合は、「 ローリング アップグレード」に進みます。 高可用性ソリューションを設定していない場合は、データベース ミラーリングを一時的に構成して、ダウンタイムを最小にして、このアップグレードを容易にするか、またはこの機会を利用して、永続的な HA ソリューションとして、Always On 可用性グループを構成することを考慮できます。

たとえば、このアプローチは、次をアップグレードする場合に使用できます。

  • サポートされていないオペレーティング システムへの SQL Server のインストール。
  • SQL Server 2016 (13.x) 以降のバージョンは x86 インストールをサポートしていないため、SQL Server の x86 (32-bit) インストール。
  • SQL Server 新しいハードウェアや新しいバージョンのオペレーティング システムへ。
  • SQL Server のサーバー統合。
  • SQL Server 2005 (9.x) は、SQL Server 2016 (13.x) 以降のバージョンでは、SQL Server 2005 (9.x) のインプレース アップグレードをサポートしていません。 詳細については、古いバージョンの SQL Server からアップグレードしているかに関するページを参照してください。

新規インストール アップグレードに必要な手順は、アタッチされたストレージを使用するか、または SAN Storageを使用するかどうかによってやや異なります。

  • アタッチされたストレージ環境: アタッチされたストレージを使用する SQL Server 環境がある場合、次の図と図内のリンクで、データベース エンジン の新規インストール アップグレードに必要な手順を示しています。

    アタッチされた記憶域のバックアップと復元を使用した新規インストール アップグレード方法を示す図。

  • SAN ストレージ環境: SAN ストレージを使用した SQL Server 環境がある場合、次の図と図内のリンクで、データベース エンジンの新規インストール アップグレードに必要な手順を示しています。

    SAN ストレージのアタッチとデタッチを使用した新規インストール アップグレード方法の図。

ローリング アップグレード

ローリング アップグレードは、特定の順序でアップグレードする必要がある複数の SQL Server インスタンスを含む SQL Server ソリューション環境で、アップタイムを最大にし、リスクを最小にして、機能を維持するために必要です。 ローリング アップグレードは、基本的に、複数の SQL Server インスタンスを特定の順序でアップグレードすることです。 既存の各 SQL Server インスタンスでインプレース アップグレードを実行するか、またはアップグレード プロジェクトの一環としてハードウェアやオペレーティング システムのアップグレードを容易にするために、新規インストール アップグレードを実行します。 ローリング アップグレード アプローチを使用する必要があるシナリオがいくつかあります。 これらを以下の各記事で説明します。