経緯

以前、Windows Server 2003 上で SQL Server 2000 が動くシステムの構築に関わっていたのだが、Microsoft のサポート切れのため、Windows Server 2012 + SQL Server 2014 に移行することになった。最近は開発の仕事がメインなので、こうしたサーバー構築系の仕事はしてなかったんだけど、元システムの構築に関わった手前、断るのも悪いし、受けることにした。

移行方法概要

基礎知識

SQL Server 2000 から直接移行のパスが用意されているのは SQL Server 2008 R2 まで。SQL Server 2014 などは、一度 2008 R2 以前のバージョンを挟まなければいけない。

Windows も同様で、Windows Server 2003 から Windows Server 2012 に直接アップグレードすることはできず、一度 Windows Server 2008 を挟むか、新規インストールを行う必要がある。

移行対象

移行すべき情報は以下の通り。

• データベース（ユーザーが作成したもの）
  • テーブル
  • ストアドプロシージャ
  • etc.
• アカウント情報

移行方法概略説明

データベースの移行に関しては、以下の2通り。

• データベースのバックアップ＆復元を利用する
• スクリプトとして出力し、移行先でそれを実行

アカウント情報に関しては、こちらの KB246133 にあるように、移行元でストアドプロシージャによりアカウント情報をテキストとして出力して、それを移行先で実行する。ただし、この方法だけではうまくいかなかった。

バックアップ＆復元でデータベースを移行

さて、データベースの移行方法その1は、データベースのバックアップを使用するもの。SQL Server には、データ移行に関して色んな方法やら用語があるので紛らわしいけど、ここで使うのは所謂普通のバックアップ。夜間とかに別ディスクやテープドライブなどに出力しているあれ。

まずは、移行元の SQL Server 2000 でバックアップを取得。db_foo.bak などというファイルが出来るはず。

で、これをそのまま SQL Server 2014 で復元出来ればいいが、前述の通りそれは出来ないので、一度 SQL Server 2008 （あるいは 2008 R2）で復元し、それを再度バックアップファイルとして出力し、それを SQL Server 2014 で復元する。

長所

• トラブルは少ない

短所

• SQL Server 2008 の環境を作るのが若干面倒

DBをスクリプトとして出力し、移行先で実行

MySQL や PostgreSQL では一般的な方法。それぞれ、mysqldump と pg_dump で出力した SQL ファイル（＝テキストファイル）を、移行先の環境で実行するというもの。

一見、これが一番簡単そうに思えるのだが、落とし穴（？）が2点あった。それに関しては後述する。

SQL Server 2000 のDBをスクリプト出力する方法

まず結論から書くと、 SQL Server Management Studio （以下 SSMS ） 2008 を使えばいい。SQL Server 2014 付属の SSMS はバージョンが新しすぎてダメ。

SSMS 2008 は、SQL Server 2008 に付属のもののExpress 版が無償でダウンロードできる。正式名称は Microsoft® SQL Server® 2008 Management Studio Express らしいので、ググッてダウンロードする。

なお、SQL Server 2000 についてくる Enterprise Manager では、データも含んだ形でDBをスクリプトに出力することはできず、スキーマだけしか出力できない。（CREATE TABLE文は出力できてもINSERT文は出力できない。）

スクリプト出力に関するちょっとしたハマリポイント

SSMS 2008 のインストールには、.NET Framework が必要

じゃ、さっそく SSMS 2008 をインストールしよう。で、次に、どこにインストールするのか、という問題になる。移行先のサーバーに入れられればそれが簡単だが、移行先のサーバーに、移行時に1回だけしか使わないツールを入れるのは嫌な人もいるはず。

移行元に入れればいいかというと、そうもいかない。というのも、SSMS 2008 は、.NET Framework 3.5 以上(?) が必要だが、Windows Server 2003 という大昔の OS では、.NET Framework 3.5 がインストール出来ない。

自分は、結局、一時的に Windows 2008 （SSMS 2008 が動けばなんでもいい）の環境を作って、そこに SSMS 2008 をインストールした。

非常に分かりにくい

ちなみに、データも含んだ形でスクリプトを出力する方法が非常に分かりにくい。このページにある”Approach #3″ なんだけど、SSMS のバージョンによっては、このオプションの位置が違っていて見つからない。2008じゃ使えないのか？と思って2016を確認してみたりとかでかなり時間を使ってしまった。自分の手元のバージョンだと、こんな画面だった。

出力したスクリプトを実行

さて、苦労して出力したスクリプトだが、あとはこれを実行するだけなので簡単。って訳にはいかない。いくつか手動でファイルを変更する必要がある。

• データファイルのパス
• SQL Server の互換性バージョン

ま、たいしたことではないので、ささっと修正を済ませて、さぁ実行。

すると、スクリプトのサイズが大きくてメモリが足りない、みたいなエラーが出てきて実行できない。手動で分割して実行すれば出来るのだろうけど、面倒なので諦めた。

アカウントの移行方法

前提として、今回は SQL Server 認証のアカウントを移行する。

これに関しては、KB246133 をまずはじっくり読むことをおすすめする。まとめると、以下のような作業になる。

1. 移行元サーバーに、アカウント情報エクスポートの為のストアドプロシージャを追加
2. 移行元サーバーで、そのストアドプロシージャを実行
3. 出力結果の SQL を、移行先サーバーで実行
4. 必要に応じて、データ補正等の追加の作業

1〜3 の作業は問題なく終わったが、移行先で、普段使っているアカウントで試しにログインしてみようと思ったら、ログイン出来ず。SQL Server のログをみたところ、パスワードが違うらしい。

調べてみると、上の手順3のSQLには、以下のようなハッシュ化されたパスワードがあるが、

SET @pwd = CONVERT (varbinary(256), 0x01003174C637180CF64F526E65E3135189E69CA7E8962C4D69C4687643B24D5E2ADE5231E359FFD5120B83D9FFAC)

この値に対して、移行先サーバーのテーブルに入っている値は、以下のように後半が切れている形になっている。

select name, CONVERT (varbinary(256), password) from sys.syslogins;
-- 以下、結果
foo    0x01003174C637180CF64E526E65E3135189E69CA7E8962BBD69C4

原因を調べたけどよく分からなかったので、結局、SSMS からパスワードを直接変更した。（今回は、使うのは SQL Server 認証のみで、パスワードも全て知っていたので問題なかった。）

SQL Server 2000 と 2014 ではハッシュ化の形式が違うのが原因なのかも、と思ったけど、確証なし。こっちの KB918992 も参考になるかも。

まとめ

SQL Server 2000 から 2014 のようにバージョンが離れていると、直接アップグレード出来なくて、色々面倒。システムのマイグレーションの計画はお早めに。