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

4.2　現在のマスター環境を新規サーバーへ複製（HWリプレース）

1. 現在のマスター環境を丸ごと新規サーバーへ複製する（ハードウェア リプレースを行う）具体的な手順は、次のとおりです。

2. 現在のマスターの SQL Server サービスを停止する（∵オフライン バックアップのため）

3. 現在のマスターでオフライン バックアップ（全データベース）を取得する（ユーザー データベースに関しては、オンライン バックアップでも可）

4. 現在のマスターを停止して、ネットワークから切り離す（旧マスターとなる）

5. 新規サーバーに OS をインストールし、マシン名を旧マスターと同じ名前へ変更する（インストールする OS は、旧マスターと異なるものでも可）

6. 新規サーバーを Active Directoryドメインへ参加させる

7. 新規サーバーへ旧マスターと同じバージョンの SQL Server をインストールする

8. 旧マスターの SQL Server にインストール済みの修正プログラムを、新規サーバーにもインストールする

9. 新規サーバーの SQL Server を停止する

10. 旧マスターで取得したオフライン バックアップを上書きコピーする（復元する）ユーザー データベースをオンライン バックアップで取得している場合は、SQL Server の起動後に、該当データベースを復元する

11. 新規サーバーの SQL Server を起動する

12. レジストリに格納されている情報を再設定する

13. OS の設定で、旧マスターで変更しているものがある場合は、それらを再設定する

以降では、これらの手順を詳しく説明します。

◆ 1.　現在のマスターの SQL Server サービスを停止

まずは、現在のマスターでオフライン バックアップを取得するために SQL Server サービスを停止します。SQL Server サービスは、構成マネージャー ツールを利用して、次のように停止します（SQL Server Agent サービスも停止します）。

SQL Server 2005 のフルテキスト検索機能を利用している場合は、SQL Server FullText Search サービスも停止します（SQL Server 2008 以降の場合は SQL Full-text Filter Daemon Launcher サービスを停止します）。

Reporting Services を利用している場合は、次のように Reporting Services サービスも停止します（Analysis Services に関しては停止しなくても大丈夫です）。

Reporting Services や Analysis Services の場合の丸ごと複製を行う手順については、この章の後半でまとめて説明します。ここでは、まず SQL Server のデータベース エンジンを丸ごと複製する方法について説明します。

◆ 2.　現在のマスターでオフライン バックアップを取得する

SQL Server サービスの停止が完了したら、すべてのデータベース（システム データベースとユーザー データベースをすべて）のデータ ファイル（.mdf）とトランザクション ログ ファイル（.ldf）を、Windows エクスプローラーからファイル コピーで取得します。

SQL Server 2005 の場合は、既定ではシステム データベースは、次のフォルダーに格納されています。

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data

SQL Server 2008／2008 R2／2012 の場合は、既定では次のフォルダーになります。

SQL Server 2008 の場合
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA

SQL Server 2008 R2 の場合
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

SQL Server 2012 の場合
C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA

システム データベースを含めた、ユーザー データベースが格納されているフォルダーは、次のように sysdatabases 互換ビューの filename 列を参照することで確認することができます。

ここにリストされるデータベースのファイル（.mdf）とそれに対応したログ ファイル（.ldf）をすべてコピーするようにします。このビューでは、.ldf ファイルの場所が分からないので、これを確認したい場合は、次のように sys.database_files システム ビューの physical_name 列を参照するようにします。

フルテキスト検索機能を、SQL Server 2005 で利用している場合には、既定で以下のフォルダーにフルテキスト カタログが作成されるので、これもコピーしておく必要があります。

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData

SQL Server 2008 以降で、フルテキスト検索機能を利用している場合は、フルテキスト検索機能がデータベース エンジンに統合されているので、データベース ファイル（.mdf／.ldf）のコピーだけがあれば大丈夫です（FTData フォルダー内のコピーは不要です）。

ファイルのコピー先には、ファイル サーバー（新規サーバーからもアクセス可能なマシン）や、USB 接続の HDD など持ち運びが可能なメディアを利用します（∵現在のマスターはこの後ネットワークから切り離すため）。ただし、USB 接続の場合は、データベース サイズが大きい場合には、転送スピードが遅いので（特に USB 2.0 の場合）、アップグレード時のダウンタイムの増加に繋がることになります（これについては非常に重要なので後述します）。

なお、ユーザー データベースに関しては、オンライン バックアップ（BACKUP ステートメント）で取得することも可能ですが、これもダウンタイムとの兼ね合いがあるので、詳しくは後述します。

◆ 3.　現在のマスターを停止して、ネットワークから切り離す

次に、現在のマスター（OS）をシャットダウンして、ネットワークから切り離します。これにより、現在のマスターを完全停止状態にし、万が一のアップグレード失敗時まで寝かせておきます（以降の手順では、現在のマスターを旧マスターと呼びます）。なお、アップグレードの成功後は、OS を再インストールすることで、新しいマシン（完全な別マシン）として利用することもできます。

◆ 4.　Active Directory ドメインから旧マスターを削除する

次に、旧マスターを Active Directory ドメインのコンピュータ アカウントから削除します。これは「Active Directory ユーザーとコンピューター」ツールで行います。

◆ 5.　新規サーバーへ OS をインストールして、マシン名を同じにする（最も重要）

次に、新規サーバーへ OS をインストールして、マシン名を旧マスターと同じ名前にします。OS をインストールするときは、同じドライブ構成（旧マスターが C: ドライブへインストールしているなら、新規サーバーも C: ドライブへインストール）になるようにします。

マシン名の変更は、コンピューターを右クリックして、［プロパティ］から［システムの詳細設定］をクリックし、［システムのプロパティ］ダイアログから、次のように行います。

旧マスターと同じ名前に変更することは、一連の作業（丸ごと複製作業）の中で最も重要になります。また、名前の変更は、SQL Server をインストールする前に行っておくことも非常に重要になります。もし、SQL Server をインストールした後に、名前を変更した場合には、いくつかの機能で正しく動作しない場合があるので、必ず SQL Server をインストールをする前にマシン名を同じにしておくようにします。

インストールする OS は、旧マスターと同じ OS でも、異なる OS でもかまいません。ただし、SQL Server 2005 は Windows Server 2012／2012 R2 では動作しないこと、SQL Server 2014 は Windows Server 2003／2003 R2 では動作しないことを考慮すると、次のように考える必要があります。

SQL Server 2005＋Windows Server 2003／2003 R2 環境の場合は、新規サーバーの OS を旧マスターと同じにすると、そのままでは SQL Server 2014 へアップグレードすることができません。SQL Server 2014 へアップグレードする前に、OS のアップグレード（Windows Server 2008 SP2 または 2008 R2 SP1 へのアップグレード）をしなければなりません。

その後の Windows Server 2012 R2 へのアップグレードを見据えると、Windows Server 2012 R2 へのアップグレード条件である Windows Server 2008 R2 SP1 にアップグレードするのがお勧めになりますが、OS のアップグレードには 30分以上かかってしまうので（SP1 を含んだ With SP1 パッケージではない場合は、さらに SP1 をインストールする時間がかかります）、Windows Server 2003／2003 R2 環境の場合は、同じ OS を選択することはお勧めではありません。

次のように、最初から新規サーバーに Windows Server 2008 R2 SP1 をインストールしてしまうのがお勧めになります。

OS が変わることに不安を持つ方もいらっしゃると思いますが、SQL Server は、「SQL Server だけで完結した製品」なので、OS の影響をほとんど受けません（OS が変わったとしても、SQL Server の動作にはほとんど影響ありません。SQL Server 2005 の Reporting Services だけは、OS の IIS の機能を利用しているので影響を受けますが、データベース エンジンであれば OS の影響をほとんど受けません）。このように、新規サーバーに Windows Server 2008 R2 SP1 をインストールしておけば、SQL Server 2014 へのアップグレードが完了した後に、Windows Server 2012 R2 へアップグレードすることも可能になるので（Windows Server 2012 R2 へのアップグレードは、R2 ではない Windows Server 2008 からはサポートされていないので）、お勧めです。

また、新規サーバーに Windows Server 2012 R2 SP1 をインストールするときは、SP1 を含んだ With SP1 パッケージを利用することで、インストール時間を短縮することができます。

SQL Server 2008／2008 R2 環境の場合は、次のように考えることができます。

SQL Server 2008／2008 R2 を Windows Server 2008／2008 R2 で動作させている場合には、新規サーバーの OS は旧マスターと同じでももちろん大丈夫ですが、Windows Server 2012 R2 をインストールしてしまうこともできます（ハードウェア リプレースを機会に、OS をアップグレードしてしまう良い機会になります）。

なお、新規サーバーへの OS のインストールは、一番最初の作業（手順1 の旧マスターでのオフライン バックアップよりも前）として行っておくこともできます。この場合は、任意のマシン名を設定してインストールしておき、この手順のタイミング（現在のマスターをネットワークから切り離したタイミング）でマシン名を旧マスターと同じ名前へ変更します。あるいは、新規サーバーをネットワークから切り離しておいて、OS をインストールし、マシン名を旧マスターと同じ名前にしておきます（この場合は、旧マスターが起動している間は、新規サーバーをネットワークへ接続しないように注意します）。

◆ 6.　新規サーバーを Active Directory ドメインへ参加させる

次に、新規サーバーを Active Directory ドメインへ参加させます。

◆ 7.　新規サーバーへ旧マスターと同じ SQL Server をインストールする

次に、新規サーバーへ旧マスターと同じバージョンの SQL Server をインストールします（SQL Server 2014 をインストールするわけではないことに注意してください）。

旧マスターが SQL Server 2005 の場合には、次のように SQL Server 2005 をインストールします。

SQL Server をインストールする際の注意点は、インストール先のフォルダーを、旧マスターをインストールしたときのパスとまったく同じにするという点です。SQL Server 2005 であれば、インストール先のフォルダーは、次のページで設定しています。

もし、インストール先のフォルダーを旧マスターと違うものにしてしまうと、後述の手順でオフライン バックアップを復元した後に、SQL Server サービスが正しく起動しなくなるので、注意してください（∵master データベース内には、msdb や tempdb、ユーザー データベースへのファイル パスが格納されているので、インストール先のフォルダーが異なるとデータベースを認識することができなくなります）。

また、インストール時は、インスタンス名やサービス アカウント、認証モード、照合順序なども旧マスターと同じ設定にする必要があります。サービス アカウントは、ドメイン ユーザーである必要があり、旧マスターで設定しているドメイン ユーザーと同じにする必要もあります。

SQL Server 2005 の場合のインストール時の設定画面（旧マスターと同じにすること）

完全複製（後述のオフライン バックアップからの復元）をするには、旧マスターと全く同じように SQL Server をインストールすることが非常に重要になります。

◆ 8.　旧マスターへインストール済みの修正プログラムをインストールする

SQL Server のインストールが完了した後は、旧マスターへインストール済みの SQL Server の修正プログラム（Service Pack や CU など）を、新規サーバーにもインストールします。

このときにインストールする修正プログラムは、旧マスターへインストールしているものとまったく同じもののみをインストールすることに注意してください。例えば、旧マスターが SQL Server 2005 の SP3 である場合は、SP3 をインストールします。

もし、旧マスターよりも最新版の修正プログラムをインストールした場合には、オフライン バックアップからの復元後に、SQL Server サービスが正しく起動しない場合があるので、必ず同じものをインストールするようにします（∵システム データベースは、修正プログラムの影響を受けるため）。

◆ 9.　新規サーバーの SQL Server を停止する

次に、旧マスターで取得したオフライン バックアップを新規サーバーへ適用するために、SQL Server サービスを停止します。SQL Server サービスは、構成マネージャー ツールを利用して、次のように停止します（SQL Server Agent サービスも停止します）。

SQL Server 2005 のフルテキスト検索機能を利用している場合は、SQL Server FullText Search サービスも停止します（SQL Server 2008 以降の場合は SQL Full-text Filter Daemon Launcher サービスを停止します）。

◆ 10.　新規サーバーのシステム データベースを丸ごとオフライン バックアップする

この作業は、万が一、次の手順が失敗したときのために、念のため実施します。SQL Server のインストールおよび修正プログラムを適用した後の、現在のシステム データベースをオフライン バックアップしておき、いつでもこの状態へ戻せるようにしておきます。

◆ 11.　旧マスター上で取得したオフライン バックアップを新規サーバーへ復元する

次に、旧マスターで取得したすべてのデータベース（システム データベースとユーザー データベース）のオフライン バックアップ（.mdf と .ldf）を、Windows エクスプローラーから新規サーバー上にすべてコピー（上書きコピー）します。

システム データベースは同じファイルが存在しますが、前の手順で念のためバックアップをしているので、安心して上書きコピーしてください。SQL Server 2005 のフルテキスト検索機能を利用している場合は、コピーしておいたフルテキスト カタログを同じ場所へコピーします。

なお、ユーザー データベースをオンライン バックアップで取得している場合は、次の手順で SQL Server を起動した後に、RESTORE ステートメントでバックアップから復元します。

◆ 12.　新規サーバーの SQL Server を起動する

上書きコピーが完了したら、新規サーバーの SQL Server サービスを起動します。

もし、SQL Server サービスが起動しない場合は、OS のフォルダー構成やドライブ構成が、旧マスターと同じになっていない場合（tempdb データベースを別ドライブへ移動しているなど）に起こり得ます（OS のフォルダー構成やドライブ構成は、旧マスターと全く同じにしておく必要があります）。

SQL Server サービスが起動した後は、SQL Server Agent サービスも起動します（フルテキスト検索機能を利用している場合は、SQL Server FullText Search サービスも開始します）。

以上で、（これだけで）旧マスターとほぼ同じ状態の SQL Server として動作させることができます。データベースを以前と変わらずに利用できることはもちろん、ログイン アカウントやオブジェクト権限、ジョブ、警告、暗号化、リンク サーバー、メンテナンス プラン（保守計画）、リソース ガバナー、監査（SQL Server Audit）、ポリシー管理、データベース メール、サーバーの構成オプション、パフォーマンス データ コレクションなど、旧マスターで設定／利用していた機能を、そのまま新マスター上でも利用することができます。

SQL Server は、起動時に master データベースから各種の動作情報を取得するので、システム データベースを上書きするだけで、環境をガラリと変更することができます（システム データベースに含まれているものに関しては、第５章でも詳しく説明しています）。

もし、SQL Server サービスや SQL Server Agent サービスが起動しない場合には、手順7 でのインストール パスが正しいこと（旧マスターと同じパスであること）などを確認してみてください。また、旧マスターで tempdb データベースを別ドライブへ移動している場合には、そのドライブと同じドライブ文字のドライブを新規サーバー上でも作成しておく必要があります。

サービス アカウントに NTFS アクセス許可があることの確認

SQL Server サービスおよび SQL Server Agent サービスを開始した後に、次のようにデータベースが開けない場合は、SQL Server サービスのサービス アカウントに対する NTFS アクセス許可があるかどうかを確認してみてください。

フルテキスト検索機能を利用している場合は、SQL Server 2005 の場合は、前述の FTData フォルダーに対して、サービス アカウントへ NTFS アクセス許可が与えられているかどうかを確認してみてください。それでも、フルテキスト検索で、次のようにエラーが出る場合は、フルテキスト インデックスを再構築してみてください。

フルテキスト インスタンスの再構築は、次のように行えます。

ユーザー データベースを同じドライブへ配置できない場合（アタッチで認識することも可能）

もし、新規サーバー上で同じドライブを作成できない場合には、前述と同様の「ファイルにアクセスできない」エラーが表示されて、ユーザー データベースを開くことができません。この場合は、データベース（.mdf／.ldf ファイル）を認識させられる代替案があります。例えば、旧マスターで F: ドライブに作成していたユーザー データベースが、新規サーバーでは M: ドライブになっているような場合には、次のように「アタッチ］操作をすることで、新しい場所にある .mdf／.ldf ファイルをデータベースとして認識させることができます（アタッチ前に、開けなかったデータベースを削除してから、アタッチ操作を実行します）。

◆ 追加の作業（レジストリ、OS の設定）

以上で、ほとんどの機能をそのまま動作させることができますが、次の 2つの作業を追加で行っておく必要があります。

• レジストリに格納されている情報を再設定する
  TCP ポート番号や起動時パラメーターでのトレースフラグの設定などのうち、旧マスターで設定を変更しているものがある場合は、それらを再設定する
• OS の設定で、旧マスターで変更しているものがある場合は、それらを再設定する
  フォルダー構成や NTFS アクセス許可、ユーザーの権利、共有フォルダーなど

OS を変更したことによって、レジストリに格納される設定や、OS の設定に関しては、再設定が必要になります（どういったものに再設定が必要になるかは、後述します）。

◆ Windows のローカル ユーザーを利用している場合の注意点

旧マスター環境で、次のように Windows のローカル ユーザーを利用している場合には、注意点があります。

• データベースの所有者が Windows のローカル ユーザーの場合には、SQL CLR オブジェクトで権限セットを「UNSAFE」または「外部」に設定しているものが動作しない。また、データベース ダイアグラムも表示できない
• ジョブの所有者が Windows のローカル ユーザーの場合には、ジョブが実行エラーになる
• ログイン アカウントが Windows のローカル ユーザーの場合は、ログイン アカウントおよびそれに紐付いたデータベース ユーザー／オブジェクト権限／データベース ロールが動作しなくなる
• 管理者アカウント（sysadmin ロール）が Windows のローカル ユーザーのみの場合で、認証モードが「Windows 認証」の場合には、SQL Server へログインできるユーザーがいなくなってしまう（ただし、SQL Server 2005 の場合は、既定ではAdministrators グループが sysadmin ロールとして登録されるので、Administrators グループのメンバーであればログインが可能）
• サービス アカウントが Windows のローカル ユーザーの場合には、サービス マスター キーが関連するものが動作しなくなる（リンク サーバーやデータベース メール、透過的なデータ暗号化など）
• その他、Windows のローカル ユーザーを利用している設定があるものは動作しない

Windows のローカル ユーザーは、OS が変わると別のユーザーになるため（内部的な Security ID が異なるため）、こういったことが起こりますが、これらの対処方法については、後述します。