SQL Server から MSDE へのデータベースの移動は、その動作保証は受けられなかったと思います。

たまたま、ここで解説している手順で操作をしたら、『うまく動いた、ラッキー！』という程度の話として考えて下さい。

そのため、見落としている項目があると思います。お気付きの点がございましたら、ご指摘をお願いします。

まず最初にやるべきことは、運用中のSQL Server 2000のバージョンを確認して下さい。
ここで言うバージョンとは、サービスパックの適用状況のことです。

SQL Server 2000 に、サービスパック１（SP1）、SP2、SP3、SP4などの、どのサービスパックを当てている状態でしょうか？

具体的には、

あるいは、エラーログの内容からバージョン番号を調べる方法もあります。
この方法は、SQL文を実行しなくてもバージョン番号を調べることができるので、こちらの方法をおすすめします。

現在運用中の、SQL Server のバージョン番号を、まず最初に確認しましょう。

サービスパックを当てるとプログラムはもちろん修正されます。さらに、masterデータベースやmsdbデータベースなどのシステムデータベースの内容も一緒に修正が行なわれます。

このシステムデータベースを修正するという点が、非常にやっかいな問題を引き起こします。

サービスパック１番（SP1）が当たったmasterデータベースは、サービスパック１番（SP1）が当たったデータベースプログラムと一緒に運用をしなければいけません。サービスパック２番（SP2）が当たったデータベースプログラムに、サービスパックを当てていないmasterデータベースを復元することはできません。

このように、データベースプログラムに当てているサービスパック番号と、システムデータベースに当てているサービスパック番号は、必ず一致させないと、正しい動作保証は受けられないのです。

ですから、SQLServer や MSDE のデータベースシステムに新しくサービスパックを当てると言うことは、まったく新しいバージョンにするということと考えて、差し支えありません（そのような慎重姿勢で、サービスパックを当てましょう）。

サービスパックを当てると、それまでにバックアップをして保存したシステムデータベースは、新しいサービスパックを当てた環境では何の役にもなりません。サービスパックを当てた直後に、もう１度最初から、システムデータベースのバックアップを行ないます。

また、masterデータベースの再構築と呼ばれる特別な操作を行なうとき、データベースシステムのプログラムはサービスパックが当たった状態なのに、masterデータベースなどのシステムデータベースの物理ファイルを製品出荷時のCD-ROMを指定するといった誤った操作をしないためにも、サービスパックを当てた直後のシステムデータベースの物理ファイルを手元に保存しなければいけません。

masterデータベースの再構築とは、masterデータベースが壊れてデータベースサービスが立ち上がらなくなった場合の、最後の復旧手段です。システムデータベースの物理ファイルからシステムデータベースを構築します（データベースサービスが起動しないため、backup database文によってバックアップされたバックアップファイルは一切使うことができない最悪の状況に陥っています）。そのとき、サービスパックの適用状況が問われます。データベースシステムのプログラム側にサービスパックを当てているのであれば、そのサービスパックを当てた状態のシステムデータベースの物理ファイルが必要となります。サービスパックを当てた直後の、システムデータベースの物理ファイルのコピーは、お持ちですか？

今回は、SQLServer 2000 で運用しているデータベースを MSDE 2000 に移動します。このとき、masterデータベースの中に記録されている『ログイン情報』も一緒に、MSDE 2000 に、移動しました。masterデータベースを移動させるので、サービスパックの適用状況を、SQLServer と MSDE との間で、一致させたわけです（なお最初にも述べましたが、SQLServer データベースのmasterデータベースを MSDE 側に移動させることは、保証されておりません）。

なお、ユーザが作成したユーザデータベースに関しては、サービスパックの適用状況に関係なく、互換性が保たれます。システムデータベースを取り扱うときだけ、サービスパックの適用状況を強く意識するようにしましょう。

リリース	Sqlservr.exe
製品版（サービスパック無し）	2000.80.194.0
SQL Server 2000 SP1	2000.80.384.0
SQL Server 2000 SP2	2000.80.534.0
SQL Server 2000 SP3	2000.80.760.0
SQL Server 2000 SP3a	2000.80.760.0
SQL Server 2000 SP4	2000.8.00.2039

となります。

MSDE 2000 についても、サービスパックを当てたときのバージョン番号は同じです。

SP3 と SP3a は、大きな違いはありません。SP3 が当たっていれば、わざわざ SP3a にする必要はありません。

SQL Server 2000 のサービスパックの詳細は、マイクロソフトサポート文書番号306908を参照して下さい。

なお、2039番のSP4が当たっているMSDEは、SQL2000.MSDE-KB884525-SP4-x86.EXEというファイルからインストールすることができます。
マイクロソフト社のここから、ダウンロードできます。

MSDE 2000 Release-A のインストールについては、『MSDE 2000 Release-A インストール』を参照下さい。

MSDE 2000 SP4 の新規インストールについては、『MSDE2000 SP4 新規インスタンス インストール プログラム』を参照下さい。

MSDE側では、masterデータベースの内容を現在と違うものに復元しますので、万が一、失敗したら、大変なことになります。

そこで失敗しても、その影響が最小限になるように、新しいMSDEのデータベースサーバー（インスタンスという）を使って、その操作を行なって下さい。

移動先にまだMSDEがインストールされていなければ、問題はありません。

もし、すでにMSDEがインストールされているときは、すでにインストール済みのMSDEのデータベース環境を使わずに、もう１つ、新しいMSDEのインストールを行ないます（別のインスタンスのインストール）。

MSDE 2000から、同一コンピュータ上に、複数個のデータベースサーバーをインストールすることができます。この機能を使えば、万が一、今回のデータベースの移動操作で失敗事故が発生しても、すでにインストール済みのMSDEインスタンスに対しては、何の影響も与えることはありません。

このような安全策を取って、慎重に作業を進めて下さい。

インスタンスの名前を、ここでは、「MVTEST」とします。

次のような、インストールコマンドを、「ファイル名を指定して実行」で、入力して下さい。

C:\MSDERelA\setup.exe SAPWD="sa_password" INSTANCENAME="MVTEST" DISABLENETWORKPROTOCOLS=0 SECURITYMODE=SQL
(１行で入力します)

MVTESTという名前のインスタンスが、インストールされます。

C:\Program Filesフォルダの中の、Microsoft SQL Server フォルダに、MSDE2000 がインストールされます。 MSSQLサブフォルダは、MSDE2000の既定のインスタンスです（デフォルトのデータベースサーバー）。 MSSQL$MVTEST サブフォルダが、MVTESTインスタンス名に対応した、MSDE2000 のデータベースサーバーです。

MSDE 2000 をインストールしても、プログラムメニューには、サーバーネットワークユーティリティが作成されません。しかし、ユーティリティのコマンドは、MSDE 2000 と一緒に、インストールされます。

次のコマンドを、「ファイルイ名を指定して実行」で、入力します。

"C:\Program Files\Microsoft SQL Server\80\Tools\Binn\SVRNETCN.exe"
（１行です）

	サーバー ネットワーク ユーティリティ を使って、MSDE 2000 データベースサーバーの、サーバー側ネットワークのパラメータを設定します。 MVTESTインスタンスを選択して、TCP/IPネットワークのプロパティを表示します。
	TCP/IPネットワークの、ポート番号を、1500番に設定します。

サーバー ネットワーク ユーティリティで、ポート番号を変更したら、データベースサービスを再起動して下さい。

また、MSDE 2000をインストールしたコンピュータの、ネットワークカードのIPアドレスも調べておきます。

MSDE（データベースサーバー側）から見た場合、SQLServerが動作しているコンピュータは、クライアント側コンピュータに相当します。そのためネットワークの設定は、クライアント側のネットワーク環境の設定となります。

そのためのコマンドが、「クライアント ネットワーク ユーティリティ」（cliconfg.exeコマンド）です。このコマンドは、Windowsのコマンドとして組み込まれています。

C:\WINDOWS\system32\cliconfg.exe などにあります（Windowsのバージョンによってフォルダ名が多少違う）。

このコマンドを起動します。

	クライアント ネットワーク ユーティリティ を使って、MSDE 2000 データベースサーバーに接続を行なう、クライアント側コンピュータのネットワークを設定します。 「別名」の「追加」によって、サーバー別名を登録します。 クライアント側から、できる限り簡単にMSDE2000データベースサーバーへ接続するためには、インスタンス名をあまり意識しないで済むようにしたいと思います。 そこで、ポート番号1500番で待ち受けているMSDE2000のインスタンスに、クライアント側から勝手に名前を付けて（サーバー別名と言う）、この名前を使って接続ができるようにしたいと思います。
	サーバー別名を登録します。 別名の名前は、MSDE2000のインスタンス名と同じにします（異なる名前でも良い）。 サーバーのIPアドレスと、ポート番号（1500番)を入力します。

このように、サーバー別名を登録したら、このクライアントコンピュータからMSDE2000のMVTESTインスタンスに接続ができるようになります。

	クライアント ネットワーク ユーティリティ で定義された、サーバー別名を使って、クエリアナライザから接続を行ないます。 接続先のSQLServerの名前は、サーバー別名で定義を行なった、MVTESTです。
	接続先サーバーの、サーバー名を表示します。 MVTESTインスタンスとして動いているサーバーに、正しく接続していることがわかります。
osqlコマンドを使って、MSDEデータベースサーバーに接続を行なうときは、-Sスイッチに指定する接続先サーバー名に、サーバー別名で定義したMVTESTを指定します。
C:\>osql -S MVTEST -U sa -P sa_password 1> SELECT CAST(@@SERVERNAME AS VARCHAR(50)) 2> GO -------------------------------------------------- SUPER\MVTEST (1 件処理されました) 1> QUIT

データベースユーザが、dboユーザとguestユーザだけから構成されていれば、このユーザ情報はどのデータベースサーバー環境でも一致するため、特別な配慮は必要ありません。

ところが、その他のユーザ名が登録されているのが普通です。

ユーザデータベースを現在の運用環境から、別のデータベースサーバーに移動した場合、ログイン情報とユーザ情報との対応関係が一致しない部分が発生します。

このようなトラブルを防ぐためには、ユーザデータベースだけを移動する操作では不十分で、ログイン情報も一緒に移動しないといけません。

ログイン情報は、masterデータベースのsysxloginsシステムテーブルによって管理されます。

このテーブルの内容を、移動先のMSDEデータベースサーバーの同じsysxloginsシステムテーブルに上書きすれば、ログイン情報が一致することになります。

この上書き操作をできる限り簡単に済ませようと考えて、ここでは、SQL Server 側でバックアップされたmasterデータベースを、MSDE側で復元する操作を取りたいと思います。

『masterデータベースの復元操作』を行ないます。

masterデータベースの復元操作を行なうときは、データベースサービスを『シングルユーザモード』と呼ばれる特別な起動方法で立ち上げる必要があります。

C:\>cd "C:\Program Files\Microsoft SQL Server\MSSQL$MVTEST\Binn" C:\Program Files\Microsoft SQL Server\MSSQL$MVTEST\Binn>

MVTESTインスタンスの場合に、カレントディレクトリ位置を変更します。

データベースサービスが動いていないことを確認してから、そのカレントディレクトリ位置から、次のようなコマンドを入力して、シングルユーザモード専用のデータベースサービスを立ち上げます。

C:\Program Files\Microsoft SQL Server\MSSQL$MVTEST\Binn>sqlservr -s MVTEST -c -m (リターンキー)

-s スイッチで、インスタンス名を指定します
-c スイッチで、起動時間を短縮します
-m スイッチで、シングルユーザモードで立ち上げます

シングルユーザモードで起動したデータベースサーバーのサービスを止めるときは、CTRL+Cのキー操作をします

masterデータベースの中には、そのデータベースサーバーで運用している個々のデータベースのファイル名が、完全パスの形式で記録されています。
例えば、あるデータベースの物理ファイルは、ドライブE:の、あるディレクトリの中の、あるファイルだというような情報です。

そのファイルが存在しないと、masterデータベースを復元した後に、様々なトラブルが発生します。

データベースサービスを立ち上げたとき、masterデータベースの中に記録されているこれらの物理ファイルの情報を参照して、該当するデータベースを開きます。

もし、一般ユーザが作成したデータベースを構成する物理ファイルが見つからない場合は、そのデータベースは利用できないと判断して、そのデータベースをスキップします。

ところが、システムデータベースであるmsdbとmodelを構成する物理ファイルが見つからないと、事情が異なります。致命的なエラーが発生したと判断し、データベースサービスは起動しません。

ここで、問題があります。masterデータベースをバックアップしたSQL Server上にある、msdbとmodelシステムデータベースの物理ファイルと同じファイルが、復元を行うMSDEのコンピュータ上に存在しますか？（物理的なパスが一致しますか？）

一般的には、SQL Server では、システムデータベースの記憶場所を、既定のフォルダ位置からその場所を変更したりします。例えば、D:\DATABASE\MSSQL\Data に変更するなど。

このように、システムデータベースを既定の位置から変更している場合は、その変更された位置と同じ場所に、システムデータベース（msdbとmodel）の物理ファイルを置いておく必要があります。

もしMSDE側で、その位置に物理ファイルを置いておくのに何か支障がある場合は、データベースサービスを起動した後に、物理ファイル位置の変更を行なうことができます。しかし、データベースサービスそのものが起動しなければ、何の操作をすることもできませんので、masterデータベースを復元した直後のデータベースサービスの起動では、支障のある位置に、物理ファイルを置いて下さい。

どうしても、同じ位置に、物理ファイルを置くことができない場合（例えばドライブ名が存在しないなど）は、トレースフラグ3608番を付けて、データベースサービスを起動することができます。

マイクロソフトサポート文書番号224071

C:\Program Files\Microsoft SQL Server\MSSQL\Data のフォルダの中に、システムデータベースが収録されていました。

この場合、このフォルダと同じものが、MSDE側にも存在し、MSDE側の既定のデータベースサーバーとなっています。

MSDE側のMVTESTインスタンスを使ってmasterデータベースを復元すると、MVTESTインスタンスのmsdbとmodelシステムデータベースを使うのではなく、物理パスが一致する既定のサーバーのmsdbとmodelシステムデータベースを使うことになります。

MSDE側の既定のデータベースサーバーが動いているときには、MVTESTインスタンスサーバーは、立ち上がりません。

このような問題を考慮し、MVTESTインスタンスを立ち上げるときは、既定のサーバーを止めて、速やかに、物理ファイルの移動などの復旧処理を行なって下さい。

ところが、backupフォルダが、MSDEをインストールした直後には、存在しません。

このためシステムファイルが作成できずに、エラーメッセージが表示されます（このエラーは無視しても大丈夫だが、念のため、backupフォルダを作成しておきます）。

MVTESTインスタンスの場合は、

msdbデータベースの中には、ジョブが含まれているので、そのジョブもMSDE側に移します（移したジョブが正しく動く保証はありません。通常は、ジョブの中のSQL文等の修正が必要になります）。

バックアップを実行する命令は、

backup database master to disk = 'バックアップファイル名 master.bak'
backup database msdb to disk = 'バックアップファイル名 msdb.bak'

です。このバックアップファイルをMSDE側に持ってきます。

MSDEのMVTESTインスタンスをシングルユーザモードで起動して下さい。

シングルユーザモードでデータベースサーバーを立ち上げたら、OSQLコマンドやクエリアナライザ等で、次のmasterデータベースを復元する命令を入力します。

C:\>osql -S MVTEST -U sa -P sa_password 1> restore database master from disk='d:\bak\master.bak' 2> go master データベースが正常に復元されました。SQL Server をシャットダウンしています。 SQL Server がこのプロセスを終了中です。 C:\>

OSQLコマンドを実行するクライアントでは、サーバー別名MVTESTを登録しています。

d:\bak\master.bakバックアップファイルから、masterデータベースが復元されます。

これで、masterデータベースが復元されましたので、ログイン情報がMSDEのMVTESTインスタンスに移ったことになります。

masterデータベースを復元したので、SQL Serverログインに必要なパスワードが、変更された可能性があります。

SQL Server で運用しているときのログイン情報となります。

saログインのパスワードも変わっていると思います。SQL Server側で使っているパスワードを使います。

なお、MSDE側とSQL Server側と、saのパスワードが違う場合は、その変更処理をしましょう。

C:\>osql -S MVTEST -U sa -P sa_password ユーザー 'sa' はログインできませんでした。 C:\>osql -S MVTEST -E 1> exec sp_password @new='sa_password' , @loginame='sa' 2> go パスワードは変更されました。 1> quit C:\>osql -S MVTEST -U sa -P sa_password 1> quit C:\>

saログインのパスワードを、MVTESTインスタンスをインストールしたときに指定したパスワードに戻しました。

ジョブを定義しているSQL文の中には、サーバー名などが埋め込まれている場合がありますので、そのままでは正しく動きません。

msdbシステムデータベースを別の環境の上に復元したときは、ジョブの中身を１つ１つ確認して修正を行なって下さい。

C:\>osql -S MVTEST -U sa -P sa_password 1> restore database msdb from disk='d:\bak\msdb.bak' 2> go ファイル 1 で、データベース 'msdb'、ファイル 'MSDBData' の 2072 ページが処理され ました。 ファイル 1 で、データベース 'msdb'、ファイル 'MSDBLog' の 1 ページが処理されまし た。 RESTORE DATABASE は 2073 ページを 0.830 秒で正常に処理しました (20.452 MB/秒)。 1> quit C:\>

msdbシステムデータベースを復元しました。

その中で困るのは、データベースサーバー名です。データベースサーバー名の名前が、SQL Server側と同じ名前になっています。

具体的にはSQL文の@@servernameの値です。

C:\>osql -S MVTEST -U sa -P sa_password 1> select cast(@@servername as varchar(30)) 2> go ------------------------------ ここに表示される名前がSQL Server側の名前と一致する (1 件処理されました) 1> quit

本来の正しい名前は、「コンピュータ名\インスタンス名」の形式です。

そこで、@@servernameが返す値を正します。

次のような操作によって、正しい名前が返るようになります。

C:\>osql -S MVTEST -U sa -P sa_password 1> exec sp_dropserver 'SQLServer側のサーバー名です（削除を行なうサーバー名です）' 2> go (1 件処理されました) (1 件処理されました) 1> exec sp_addserver 'SUPER\MVTEST' , 'local' 2> go (1 件処理されました) (1 件処理されました) (1 件処理されました) (1 件処理されました) (1 件処理されました) 1> quit

sp_dropserverで、サーバー名を削除します。@@servernameが表示した名前をそのまま指定します。

sp_addserverで、サーバー名を登録します。インスタンス名付きの正しい名前を登録します。この例のコンピュータ名はSUPERとしています。インスタンス名は、MVTESTです。
２番目のパラメータは、必ずlocalとして下さい。

C:\>osql -S MVTEST -U sa -P sa_password 1> select cast(@@servername as varchar(30)) 2> go ------------------------------ SUPER\MVTEST (1 件処理されました) 1> quit C:\>

データベースサーバー名が、正しくなりました。

MVTESTインスタンスでは、現在のところ、ユーザデータベースは１個も存在しません（システムデータベースだけあります）。

しかしmasterデータベースの中には、SQL Server側で運用していたユーザデータベースの名前が覚えられており、そのユーザデータベースが存在しないというエラーが発生しています。

そこでこの亡霊のようなユーザデータベースを全部削除して、きれいな状態にしましょう。

C:\>osql -S MVTEST -U sa -P sa_password 1> select cast(name as varchar(30)) from master.dbo.sysdatabases 2> go ------------------------------ master tempdb model msdb ユーザデータベース名 ユーザデータベース名 ユーザデータベース名 ユーザデータベース名 ユーザデータベース名 ユーザデータベース名 (10 件処理されました) 1> drop database ユーザデータベース名 2> go 1> drop database ユーザデータベース名 2> go （以下、同様） 1> quit

データベース名の一覧表を表示して、その中で、システムデータベースを除いたユーザデータベースを、１件１件削除します。

SQL Server側でバックアップされたユーザデータベースを、MSDE側のMVTESTインスタンスで復元します。

C:\>osql -S MVTEST -U sa -P sa_password 1> restore database データベース名 from disk='バックアップファイル名' 2> go

移動を行なうユーザデータベースを復元します。ファイル移動のオプション指定が無いときは、バックアップ命令を実行したときと同じフォルダの中に、ファイルが復元されますので、物理ファイルのパス情報が一致します。

もしドライブ構成などが異なる場合は、restore命令で、ファイル移動のオプションを定義して下さい。

ユーザデータベースの復元ができたら、念のため、データベースチェックをしましょう。

1> dbcc checkdb('データベース名') 2> go （メッセージが表示されます。途中省略） CHECKDB はデータベース 'データベース名' で 0 個のアロケーション エラーと 0 個の一貫性エラーを見つけました。 DBCC の実行が完了しました。DBCC がエラー メッセージを出力した場合は、システム管 理者に相談してください。

エラーが０個（エラーが存在しない）であることを、確認して下さい。

以上の操作によって、SQL Server で運用しているデータベースを、MSDE側のMVTESTインスタンス環境に移動することができました。