当初は単一サーバー上でスタンドアロンのインスタンスとして SQL Server をインストールして使用していたが、可用性の要件が求められ、フェールオーバークラスター上のインスタンスとして SQL Server を動作させなくてはいけなくなったという場合、どのような手順でデータベースを移行すればよいのかを少しまとめてみたいと思います。
スタンドアロンもクラスターも SQL Server としてみればあまり変わらないので、基本的な考え方はスタンドアロンからスタンドアロンへの移行 (二つの筐体間の SQL Server の移行) と同じになるかと。
データベース ファイルの移動
ただし、システムデータベース系の復元に関しては控えておいた方が良いかと思います。
クラスター環境では起動しなくなった場合に、 クラスター環境の SQL Server をクラスターサービスが停止した状態で起動する方法 で検証したように多少特殊な方法を使用する必要が出てきてしまいますので。
なお、システムデータベースの復元に関しては以下の技術情報に記載されています。
システム データベースのバックアップと復元 (SQL Server)
master データベースの復元 (Transact-SQL)
Contents
■データベースの移行についての技術情報
Microsoft のサーバー製品はデータストアとして SQL Server を使用していることが多いと思います。
これらの製品のデータベースの移行について技術情報がいくつか公開されています。
[System Center Virtual Machine Manager]
VMM データベースのバックアップと復元
VMM データベースに関する情報を取得する方法
[System Center Data Protection Manager]
DPMDB のバックアップと復旧方法について教えてください。
[System Center Operations Manager]
Operations Manager 2007 データベースを復元する方法
[System Center Configuration Manager]
バックアップと回復の計画
サイト データベースを SQL Server クラスタ インスタンスに移行する方法
[SharePoint Server]
コンテンツ データベースを復元する (SharePoint Server 2010)
[Lync Server]
データベースが併置されたアーカイブ サーバーまたは監視サーバーの復元
スタンドアロンの監視またはアーカイブ データベースの復元
監視データまたはアーカイブ データの復元
Lync Server 2010 用 SQL Server の構成
■スタンドアロンインスタンスからクラスターインスタンスへのデータベース移行
検証環境にはスタンドアロンインスタンスの SQL Server を使用した SQL Server 2008 R2 のデータベースがありますので、これを フェールオーバークラスターインスタンスで作成した SQL Server 2012 のインスタンスに移行したいと思います。
SQL Server の移行を考える場合、基本としては以下の情報の移行を考える必要があります。
| 情報 | データベース | 種類 |
| ユーザーデータ | ユーザーデータベース | ユーザーデータベース |
| ログイン | master | システムデータベース |
| SQL Server Agent ジョブ | msdb | システムデータベース |
ユーザーデータに関してはユーザーデータベースのバックアップをリストアすることで移行することができます。
ログインの情報に関しては master データベースの移行が必要となります。
ただし、master データベースには SQL Server を起動するために必要となる様々な情報が格納されており、移行が一番難しいデータベースになると思います。
そのため、単純移行をする場合には移行先のデータベースでログインを再作成するのが早いです。
SQL Server Agent のジョブに関しては msdb に格納がされており、こちらもシステムデータベース上に存在しているデータになります。
SSIS のタスクを使用している場合には移行の手順を検討する必要が出てきますが、クエリベースのジョブが設定されているだけであれば、ジョブの内容をスクリプト化して移行するのが簡単だと思います。
それでは実際に各情報の移行について見ていきたいと思います。
なお、今回の環境ですがスタンドアロンインスタンス / フェールオーバークラスターインスタンスで同じインスタンス名を使用し、照合順序も同じ設定にしています。
■ユーザーデータベースの移行
SCVMM のユーザーデータベースの移行ですが、VMM データベースのバックアップと復元 の [別のコンピューター上に VMM データベースを復元するには] に手順が記載されています。
まずは SCVMM のデータベースのバックアップを取得する必要があります。
SCVMM の場合は、管理コンソールからバックアップを取得することができます。 
取得されるのは .bak になりますので、通常の SQL Server のバックアップと同じですね。
SCVMM では[VirutalManagerDB] というデータベースのみを使用していますので、このデータベースのバックアップがユーザーデータベースとなります。
# 以下の環境は App Controller のデータベースとしても使用しているため SCVMM 以外のデータベースも存在しています。 
このバックアップをクラスターインスタンスの SQL Server にリストアする必要があります。
技術情報には SCVMMReocer.exe を使用してデータベースをリストアするための手順が記載されていますが、今回使用している環境は諸事情から SCVMM をインストールすることができませんので、SSMS (SQL Server Management Studio) でリストアしたいと思います。
クラスターでリストアする場合の注意点ですが、
- リストア先はクラスターの共有ディスクを指定する
- SSMS の GUI でバックアップファイルを選択する場合、共有ディスクからしか選択することができない
という点があります。
クラスターインスタンスではデータベースは共有ディスク (SQL Server 2012 では共有フォルダを指定することも可能) に配置する必要があります。
そのためリストア先のファイルは共有ディスクを指定する必要があります。
また、SSMS の GUI でデータベースを復元する場合には、共有ディスクしか選択することができません。 
これは GUI を使用した場合の制約ですので、クエリで実行する場合はローカルディスクに格納したバックアップファイルを指定することができます。 
以上で、ユーザーデータベースの復元は完了です。
■ログインの移行
SQL Server のログインの情報は master データベースに格納されているため、、ユーザーデータベースのリストアだけでは、適切なログインを使用したユーザーが設定されていない状態となっています。
# SQL Server 2012 の包含ユーザーだと考え方が変わるのですが。
SQL Server のデータベースのユーザーとログインの関係は以下のようになっています。 
ユーザーデータベースのリストアだけではログインは復元されませんので、リストア直後はログインの設定しないユーザーが存在している状態となります。 
このような適切なログインが設定されていないユーザーのことを [孤立ユーザー] と呼ばれることがあります。
SQL Server 認証のユーザーの場合は、sp_change_users_login を使用することで孤立ユーザーを確認することができますが、Windows 認証を使用しているユーザーの場合の検知がうまくできませんでした…。
# こういう動きするんだっけな～というのがきちんと調べられていないのですが。
SCVMM の場合、SCVMM のサービスで使用しているユーザーがログインとして追加され、そのログインが SCVMM 用のデータベースの dbo (データベースオーナー) になっているかと思います。 
この設定を活かすためにクラスターの SQL Server にもログインを追加する必要があります。
SQL Server 2005 の情報になりますが KB としては SQL Server 2005 のインスタンス間でログインおよびパスワードを転送する方法 という情報があります。
# SQL Server のインスタンス間でログインおよびパスワードを転送する方法 という KB もありますね。
どのログインを移行すればわかっているのであれば、ログインのスクリプト化を使用して移行するという方法もあると思います。 
MS 製品で SQL Server を使用する場合、大抵はドメインユーザーをサービスアカウントとして設定し、そのサービスアカウントが SQL Server にアクセスをするという方法が取られると思います。
ドメインユーザーは AD で管理されているアカウントですので SID に関しては気にする必要はなく、単純にログインを作成すればよいと思います。
SQL Server 認証のユーザーが使用できる場合 (そういう製品があるかはわかりませんが) は SID を両インスタンスでそろえると楽に移行することができます。
SID の揃え方ですが、sys.sql_logins を SELECT して、対象のログインの SID を取得し、CREATE LOGIN でログインを作成する際に SID を明示的に指定することで SQL Server 認証のログインを同一の SID にすることができます。
SCVMM では Windows 認証を使用していますので、今回はスタンドアロンインスタンスで、ログインを CREATE するスクリプトを作成し、そのスクリプトをクラスターインスタンスで実行してログインを移行しています。 
■ジョブの移行
SQL Server Agent のジョブは msdb に格納されていますので、ジョブが使用されている場合は移行が必要となります。
今回はシステムデータベースのリストアは行わないで作業をしていますのでジョブの移行もスクリプトで行いたいと思います。
SQL Server Agent のジョブですがスクリプト化することができます。
SCVMM ではSQL Server Agent のジョブは使用されていないのですが、どのように移行するかだけ軽くまとめておきます。
オブジェクトエクスプローラーからジョブをスクリプト化することができるのですが、この方法では複数のジョブを一括で選択することができないため、ジョブが複数ある場合に、一つ一つスクリプト化する必要があります。 
[表示] から [オブジェクト エクスプローラーの詳細] を開いた場合は複数のジョブが選択できますのでスクリプト化する場合はこれを使用すると良いかと思います。 
後は作成したスクリプトをクラスターインスタンスで実行すればジョブの移行は完了です。 
■接続先の変更
これで ユーザーデータ / ログイン / ジョブの移行ができましたので、後は SQL Server を使用している製品からの接続先を変更すれば作業は完了です。
別サーバーからの接続になりますので適切なファイアウォールの設定を行っておきます。
| 既定のインスタンス | TCP 1433 (UDP 1434) |
| 名前付きインスタンス | (TCP 名前付きインスタンスの SQL Server の固定ポート) UDP 1434 |
接続先の変更に関しては製品に依存してしまうので何をすればよいかを一概に決めることはできないのですが、SCVMM の場合には VMM 用 SQL Server のリモート インスタンスの構成 に記載されているレジストリを変更することで使用する SQL Server を変更することができます。
# レジストリか構成ファイル (.config) 辺りに持っているのが大半だと思いますが。
SCVMM の場合は ConnectionString のレジストリの Server の設定を変更します。 
技術情報では上記のレジストリ値の変更しか言及されていないのですが、レジストリには他の値でサーバー名が指定されているものがありますので他も合わせて変更したほうが良いかと思います。
# ConnectionString を変更すると接続先は変わるのですが、他のレジストリを変更しないとSCVMM の管理コンソールでデータベース接続の情報を確認した際の表示内容が旧情報になってしまっていたので。なお、OnRemoteServer は 0 から 1 に変更しています。 
SQL Server のクラスターインスタンスは各インスタンスについて CNO (コンピューター名オブジェクト) が作成されますので、CNO のコンピューター名を指定します。 
設定を変更したら SCVMM のサービスを再起動します。 
SCVMM の場合は、管理コンソールが開ければ接続の変更は完了しています。
SQL Server から接続が変わっていることを確認したい場合は、[sys.dm_exec_sessions] を SELECT すると接続しているアプリケーションが確認できると思います。
# session_id が 50 より大きいものでフィルタリングすると SQL Server のシステム系のセッションを除外したものを表示できます。 
これで対象の製品からの接続があるようでしたら切り替えが行われています。
同様のクエリを切り替え前のインスタンスに対して実行し、対象の製品からのセッションが無いことを確認することでダブルチェックもできると思います。
クラスターインスタンスも基本は通常のスタンドアロンインスタンスと同じですのでデータベースを移行する際の作業はスタンドアロンインスタンス間と大差ないと思います。
そのため、今回の方法はスタンドアロンインスタンス間で SQL Server を移行する際にも使用できます。