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

1.4　アップグレードと移行の主なケース

アップグレードと移行は、次のように 4つのケースに分類できます。

• ケース１　同一マシンでのアップグレード（インプレース アップグレード）
  単純なアップグレード（以前の SQL Server を上書き）
• ケース２　新規サーバー（別マシン）へのアップグレード
  ケース１との違いは別マシンかどうか（ハードウェア リプレースによって新規サーバーを購入した場合のアップグレード）
• ケース３　新規サーバー（別マシン）への移行（マイグレーション）
  アップグレードではなく、別マシンへの移行
• ケース4　同一マシンでの移行（別インスタンスをサイド バイ サイドで実行）
  ケース２との違いは別マシンかどうか（ケース４ は同じマシン内）

◆ ケース１　同一マシンでのアップグレード（インプレース アップグレード）

これは、単純なアップグレード（インプレース アップグレード）で、以前のバージョンの SQL Server を SQL Server 2014 に完全に置き換える（上書きする）ものです。

この方法のメリットは、以前のバージョンで利用していた機能をほとんどすべてそのまま利用できることです。データベースを以前と変わらずに利用できることはもちろん、ログイン アカウントや、ジョブ、警告、暗号化、リンク サーバー、メンテナンス プラン（保守計画）、リソース ガバナー、SQL Server Audit、ポリシー ベースの管理、データベース メール、サーバーの構成オプション、Reporting Services、Analysis Services など、以前の SQL Server で設定／利用していた機能を、そのまま SQL Server 2014 上でも利用することができます。

また、レプリケーションやログ配布、データベース ミラーリング、可用性グループといったサーバー間の連携機能や、WSFC（Windows Server フェールオーバー クラスタリング）上の SQL Server インスタンスに関しても、アップグレードをすることができます。ログ配布／データベース ミラーリング／可用性グループに関しては、セカンダリを先にアップグレードすることで、ローリング アップグレードも可能です（ローリング アップグレードによって、セカンダリをアップグレード中でも、プライマリを利用することができるので、ダウンタイムを最小限に抑えることができます）。

一方で、この方法のデメリットは、アップグレード後に、旧システム環境が利用できなくなってしまう（以前のバージョンの SQL Server が完全に利用できなくなってしまう）ことです。これだと、万が一アップグレードに失敗してしまった場合には、元の環境に戻すのが大変になり、失敗時は、（最悪は）OS のインストールからやり直して、バックアップからすべてを復元しなければならない場合があります。

したがって、このケースを利用する場合は、万が一のアップグレード失敗時に備えて、元の環境でしっかりとバックアップを取得しておくこと、元へ戻す手順（ロールバック手順）をしっかりと計画しておくことが重要になります。また、次の「ケース２」のように、ハードウェア リプレースを伴うアップグレードの場合であれば、元の環境をそのまま残しておくことができるので、万が一の失敗時にもすぐに元の環境に戻せるようになります。

◆ ケース２　新規サーバー（別のマシン）へのアップグレード

ケース１は、同一マシンでのアップグレードでしたが、このケースは別マシンを利用したアップグレードです。ハードウェアの保守切れや老朽化などによって、新規サーバーの購入（ハードウェア リプレース）を行って、そのマシンへ旧システム環境を丸ごと複製して、それを SQL Server 2014 へアップグレードする方法です。

このケースは、弊社のお客様に多く、現在のマスターと同じ名前の新規サーバーを、同じ Active Directoryドメイン内に構築したい場合には、この方法が一番簡単で確実になります。ただし、この方法は、あくまでも同じ名前の新規サーバーを同じ Active Directoryドメイン内に作成できること、サービス アカウントが同じドメイン ユーザーであることが条件になるので、異なるドメインやワークグループ環境、違う名前の新規サーバーを構築する場合には、次の「ケース３ 別マシンへの移行」（マイグレーション）を利用する必要があります。

ケース１では、同一マシンでのアップグレードによって、元の環境を残せないのがデメリットであると説明しましたが、このケースでは、旧システム環境をそのまま残すことができるのがメリットです。具体的な手順は後述しますが、旧システム環境が SQL Server 2005 の場合は、SQL Server 2005 が全く同じように動作するように、丸ごと複製します（システム データベースを移動するなどして、各種の設定を完全複製し、マシン名も同じ、同じ Active Directoryドメイン内に参加するようにします）。丸ごとの複製が完了したら、旧システム環境をネットワークから切り離して、新規サーバー（新マスター）を SQL Server 2014 へアップグレードします。これによって、万が一アップグレードの失敗があったとしても、旧システム環境が残っているので、すぐに元の環境に戻せるようになります。

実際、弊社のお客様では、この方法（ケース２）を利用してアップグレードを行ったときに、ハードウェア リプレースだけでなく、データセンターの変更（別のデータセンター内のハードウェアに変更）も行ったのですが、当日の作業で、SQL Server へのアップグレードは完了したものの、（データセンター側の）ネットワーク機器の設定ミスによって、ネットワークの移行が失敗してしまうということがありました。このままでは予定停止時間をオーバーしてしまって、翌朝のサービス インには間に合わなくなってしまうことから、この日は残っている旧システム環境を利用して元に戻して、アップグレードを断念したということがありました（後日、再度作業を行って、今度は無事にアップグレードが完了しました）。

このように、万が一に備えて、旧システム環境がそのまま残っていることは、大変便利です。もし、旧システム環境が残っておらず、OS をイチからインストールし直さなければならなかったとすると、とても停止時間内には元に戻すことはできませんでした。

◆ ケース３　新規サーバー（別マシン）への移行（マイグレーション）

このケースは、新規サーバー（ハードウェア リプレースなど）を利用して、そのマシンへ SQL Server 2014 をインストールし、データベースや各種の設定を移行（マイグレーション）する方法です。弊社のお客様で一番多いのがこのケースです。ハードウェア リプレースを機会に、32ビットから 64ビット環境へ移行したり、SSD やフラッシュ ストレージなどの高速ストレージ環境へ移行したりするというお客様も多くいらっしゃいます。

最近では、32ビット環境の SQL Server 2008 を、Microsoft Azure 上の仮想マシン（Windows Server 2012 R2）の SQL Server 2014（64ビット）への移行を検討していて、既にバッチ処理（ストアド プロシージャ）の実行時間などを検証しているお客様にお会いしました。バッチ処理は、クラスター化列ストア インデックスに変更することで、性能が上がることを確認できたとおっしゃっていました。

こうしたマシンをまたがった場合でも、SQL Server では簡単に移行を行うことができます。データベースの移行は、標準のバックアップと復元機能で行うことができ、バックアップと復元機能を利用すれば、別マシンであっても簡単にデータベースを複製することができ、32ビットから 64ビットへ変更したとしても、移行先の OS が変わったとしても、オンプレミスからクラウドに変わったとしても、簡単に移行することができます。

各種の設定（ログイン アカウントやジョブ、警告、リンク サーバーなどの設定）に関しても、スクリプト生成機能を利用することで、簡単に移行することができます。

ケース１ やケース２ との大きな違いとしては、サーバー管理に関する機能（リソース ガバナーやSQL Server Audit、ポリシー ベースの管理、パフォーマンス データ コレクションなど）や、サーバー間の連携機能（ログ配布やレプリケーション、データベース ミラーリング、可用性グループなど）に関しては、再設定をする必要がある点です。

◆ ケース4　同一マシンでの移行（別インスタンスをサイド バイ サイドで実行）

このケースでは、同じマシン内に、新しいインスタンスとして、SQL Server 2014 をインストールし、旧システム環境（旧バージョンの SQL Server インスタンス）からデータベースや各種の設定を移行（マイグレーション）します。ケース３ との違いは、同じマシンかどうかだけになります。

以降では、これらのケース1～3での具体的な手順を説明します（ケース4 に関しては、ケース３ とほとんど同じなので省略します）。