今回の記事では、Microsoftのデータベース製品である、SQL Server 2000 から、SQL Server 2017 へ移行する場合の手順や作業におけるポイントを紹介していきます。
尚、記事のタイトルでも記載したとおり、2017ではなく2019へ移行する場合も作業内容は変わりません。
また、今回の記事で紹介する知識や技術については、レガシーなSQL Server からの移行だけではなく、一般的に使用されているバージョン間での移行や、SQL Server の本番環境用インスタンスからテスト環境用インスタンスへのデータ同期処理などでも活用できます。
是非参考にしてください。
SQL Server 2000から2017へ移行する場合のポイント
当項では、SQL Server 2000から2017へ移行する場合の抑えておく必要のあるポイントを紹介していきます。
各バージョンの後方互換と互換性レベル
SQL Server では、旧バージョンへの後方互換に対応しており、何世代古いバージョンまで対応しているかは、移行先のSQL Server のバージョンによって異なります。
| サポートされる互換性レベル | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 60 | 65 | 70 | 80 | 90 | 100 | 110 | 120 | 130 | 140 | 150 | |||
| 製品名 | Microsoft SQL Server 2000 | 〇 | 〇 | 〇 | 〇 | ||||||||
| Microsoft SQL Server 2005 | 〇 | 〇 | 〇 | 〇 | 〇 | ||||||||
| Microsoft SQL Server 2008 | 〇 | 〇 | 〇 | ||||||||||
| Microsoft SQL Server 2008 R2 | 〇 | 〇 | 〇 | ||||||||||
| Microsoft SQL Server 2012 | 〇 | 〇 | 〇 | ||||||||||
| Microsoft SQL Server 2014 | 〇 | 〇 | 〇 | ||||||||||
| Microsoft SQL Server 2016 | 〇 | 〇 | 〇 | 〇 | |||||||||
| Microsoft SQL Server 2017 | 〇 | 〇 | 〇 | 〇 | 〇 | ||||||||
| Microsoft SQL Server 2019 | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 | |||||||
この互換性レベルのマトリクスからわかるように、SQL Server 2000 の互換性レベルの最大値は80です。
また、SQL Server 2017 や SQL Server 2019 の互換性レベルの最小値は100です。
よって、2000から2017や2019にデータベースを移行するには、SQL Server 2008 又は SQL Server 2008 R2 を中継して移行する必要があります。
互換性レベルサポート範囲外のリストアをした場合
前項で説明したように、SQL Server 2000 と、SQL Sever 2017 は互換性レベルが乖離しており、SQL Server 2000 で作成したバックアップデータを、 SQL Server 2017 のインスタンスにリストアすることはできません。
もしそれをやろうとすると、以下のエラーメッセージが表示されてリストア処理は中断されます。
メッセージ 3169、レベル 16、状態 1、サーバー 自サーバー名、行 1
データベースはバージョン 8.00.0194 を実行中のサーバーにバックアップされました。このバージョンは、このサーバー (バージョ ン 14.00.1000 を実行) とは互換性がありません。バックアップをサポートしているサーバーでデータベースを復元するか、またはこのサーバーと互換性のあるバックアップを使用してください。
メッセージ 3013、レベル 16、状態 1、サーバー 自サーバー名、行 1
RESTORE DATABASE が異常終了しています。
よって、バージョンの異なるインスタンス間でデータベースのバックアップファイルをリストアしようとする場合は、必ず前項の互換性レベルのサポート範囲内で実施する必要があります。
中継サーバーの確保
前項で解説したように、SQL Server 2000 から 2017や2019へは直接データベースを移行できず、SQL Server 2008 を中継する必要があります。
その場合、そのSQL Server 2008を稼働させるWindows Server も必要になります。
SQL Server 2008 又は、SQL Server 2008 R2に対応したWindows Server の最新バージョンは Windows Server 2012です。
よって、SQL Server 2008と共に、Windows Server 2012も環境を構築する必要があります。
※尚、Windows Server 2012以外にも、Windows 8 や、Windows 8.1 にSQL Server 2008 をインストールすることも可能です。
都合良く、Windows Server 2012環境と、SQL Server 2008環境をSQL Serverのデータベース移行用として用意出来れば良いのですが、普通は難しいです。
よって、Microsoftが提供している評価版のインストーラーを利用して、この環境を作ります。
まず、Windows Server 2012 R2の評価版インストーラーは以下のリンク先から落とせます。※2022年6月現在
■Windows Server 2012 R2評価版
次にSQL Server 2008ですが、残念ながらこちらはMicrosoftが公開している評価版のダウンロードページが全てリンク切れでダウンロードができません。
もし移行対象のデータベースのサイズがあまり大きくないのであれば、以下のリンク先からダウンロードできるSQL Server 2008 Express(無償版SQL Server)を中継サーバーとして利用することは可能だと思います。
※当方では確認はできていません。
■Microsoft SQL Server 2008 Express with Advanced Services
尚、Expressで扱えるデータベースサイズの上限値はデータベース一つあたり4GBまでです。
※SQL Server 2012 Expressからはデータベース一つあたり10GBに上限値が増えています。
私は過去にダウンロードしたSQL Server 2008 の評価版インストーラーを使用して作業をしています。
移行対象のデータベースのサイズが4GBを超える場合は、SQL Server 2008 Expressでは扱えないため、SQL Server 2008の評価版及び正規製品版のインストーラーが必要になります。
何らかの方法で入手してください。
データベースのエクスポートとインポートの自動化
データベースを移行するにあたって、移行元のSQL Server 2000から、移行先であるSQL Server 2017や2019などの新しいデータベース環境にデータを移し、データや参照するシステムの検証をすることなく本番用のデータベースを切り替えてしまうことは通常あり得ません。
2017や2019環境にデータベースが移行できた後も、データに欠損や異常が無いかを検査し、新しいデータベースを既存の業務システムなどが参照しても問題無く動作するかのテストをすることは欠かせません。
その場合、データの移行作業を都度手作業でやっていては作業ミスなどが起こる可能性もあり、そもそも大きな手間です。
よって、SQL Server 2000からデータベースをエクスポートして、SQL Server 2008 の中継サーバーにインポートし、次に、中継サーバーで取り込んだデータベースを2008環境からエクスポートして、移行先である2017や2019の環境でデータベースをインポートする一連の流れをバッチ処理で自動化するべきです。
SQLServer 2000環境の本番データを毎日、新サーバー環境まで自動で取り込まれていれば、前述したテストも高い精度で実施することができて、いざ本番に切り替える作業もそのまま自動化されることになり、時短であり、且つ安全です。
移行処理の構成イメージと必要となる処理や設定
今回実施する移行処理の構成をイメージ図で説明します。
- 2000側DBの各データベースのフルバックアップファイルを出力して中継用サーバーに転送。
- 転送されてきた2000側DBのバックアップファイルを中継用サーバーに対してリストア。
- 中継用サーバーの各データベースのフルバックアップファイルを出力して移行先サーバーに転送。
- 転送されてきた中継用サーバーのバックアップファイルを移行先サーバーに対してリストア。
尚、④の処理でリストアの際に、SQL Server側で自動的に互換性レベルを80から100に変換してくれます。
上記の処理をさせるにあたって、以下の処理を作成、又は設定する必要があります。
- 自インスタンス内のすべてのデータベースのフルバックアップ処理
- 自インスタンスに対してのリストア処理
- ダンプしたファイル群の転送処理
データベースのバックアップ処理は移行元であるSQL Server 2000環境と、中継用サーバーのSQL Server 2008環境で必要になります。
データベースのリストア処理は、中継用サーバーのSQL Server 2008環境と、移行先であるSQL Server 2017や2019で必要になります。
尚、リストア処理では、データベースをリストアした後に、データベース内のユーザーを紐付けし直す処理も必要になります。
バックアップしたファイルの転送処理は移行元サーバーと中継用サーバーで必要になります。
尚、データベースのバックアップ処理やリストア処理、ユーザーデータのマッピング処理の自動化については、過去に当ブログで記事にしております。
今回のような異なるバージョン間での移行についても同じ処理を実施することになります。
新環境へのデータ移行を如何にして自動化するかが重要です。
そのやり方も解説していきます。
エクスポートとインポートを自動化するために必要な処理や設定
当項では、移行元サーバー、中継用サーバー、移行先サーバーで個々に設定する必要がある項目や、実装が必要な処理内容を解説していきます。
尚、ジョブを利用する場合や、CUI管理ユーティリティを使用する場合でも、SQL Serverのバックアップ用のコマンドを記述して実行することが必要です。
以下のリンク先にあるMicrosoftのドキュメントで「BACKUP」コマンドの詳細が確認できます。
各引数やオプションについてはこちらをご確認ください。
データベースのバックアップ処理自動化
自インスタンス内のデータベースをフルバックアップで出力する処理を自動化します。
実装する方法は色々なやり方があり、どんな方法でも良いのですが、各データベース領域のフルバックアップファイルが出力でき、且つそれを日次などで定期的に自動実行できれば結構です。
例えば以下の方法があります。
- 「メンテナンスプラン」でデータベースのバックアップ(完全)を設定
- SQL Server エージェントの「ジョブ」でバックアップコマンドを実行
- batファイルからsqlcmdやosqlを利用してバックアップコマンドを実行
「メンテナンスプラン」を使用する場合は、ウィザードを起動して、画面に指示に沿って設定していくだけなので割愛します。
※SQL Server 2000の場合は「データベース保守計画」
SQL Server エージェントの「ジョブ」からバックアップコマンドを実行する方法と、batファイルなどからSQL Serverのコマンド実行用ユーティリティである「sqlcmd」や「osql」を利用したバックアップコマンドの実行方法を次項で紹介していきます。
「ジョブ」をダンプコマンドを実行する方法
SQL Serverでは、「SQL Server エージェント」が持つ「ジョブ」を利用することで、特定の処理を自動的に実行させることができます。
SQL Serverの「ジョブ」については、当ブログの以下の記事で詳しく紹介しているので、こちらもご参照ください。
詳しいジョブの設定方法は上記のリンク先に記載しており割愛しますが、ジョブ内の「ステップ」に設定するバックアップコマンドとしては以下です。
BACKUP DATABASE [データベース名] TO DISK = N'C:\バックアップファイルフルパス.bak' WITH INIT
ジョブの各ステップに上記の様なコマンドを各データベースごとに登録していきます。
このオプションを付けないと、同じバックアップファイルに対して「追記」をするため、どんどんファイルサイズが肥大化していってしまいます。
この登録したジョブに対して、日次で実行されるようにスケジュールを登録しておけば、その指定した時間に自動的にジョブが実行されてバックアップデータが出力されます。
これが一番簡単かも知れません。
「sqlcmd」や「osql」を利用したバックアップコマンドの実行方法
SQL Serverをインストールすると、「osql」や「sqlcmd」が利用できるようになります。
この「osql」や「sqlcmd」はSQL Serverを外部のアプリケーションからコマンドで操作するためのユーティリティです。
このユーティリティを利用することで、Windowsのコマンドプロンプトなどを介してバックアップコマンドなどを実行させることができます。
尚、「osql」や「sqlcmd」は互換性があり、同じように使用できますが、以下の違いがあります。
| osql | 古いSQL Serverで利用されていたCUI管理ユーティリティ。 SQL Serverとは「ODBC」を介して接続する。 互換維持のために最新のSQL Serverでも利用できるが、非推奨とされている。 |
| sqlcmd | SQL Server 2005から利用できるCUI管理ユーティリティ。 SQL Serverとは「OLE DB」を介して接続する。 osqlとの互換性を維持しており、ほぼ同じ構文で利用できる。 |
データベースへの接続方式には違いがありますが、表面上の動作は殆ど違いがありません。
特に理由が無ければ「sqlcmd」を使用します。
ただ、今回の作業では、SQL Server 2000 からデータベースをバックアップする必要があるため、その処理を外部プログラムから実行させる場合は、「osql」を利用します。
sqlcmdの詳しい使い方は以下のMicrosoftの公式ドキュメントをご確認ください。
当記事では、バックアップをsqlcmdを使用して実行する場合のサンプルコマンドを紹介します。
コマンドプロンプトを使用してバックアップを実行する場合は以下になります。
sqlcmd -S サーバー名(インスタンス名) -U ユーザー名 -P パスワード -Q "BACKUP DATABASE [データベース名] TO DISK = N'出力先フルパス' WITH INIT"
例えば、SQL Serverのインスタンスが稼働しているサーバーでコマンドを実行し、そのインスタンスにはsaでログイン。
バックアップ対象のデータベース名は「SampleDB」とし、Cドライブの「backup_folder」に出力する場合のコマンドであれば以下になります。
sqlcmd -S localhost -U sa -P password -Q "BACKUP DATABASE [SampleDB] TO DISK = N'c:\backup_folder\SampleDB.bak' WITH INIT"
尚、SQL Server 2000 の場合、「sqlcmd」が対応していないため、以下のように「osql」に書き換えて実行します。
osql -S localhost -U sa -P password -Q "BACKUP DATABASE [SampleDB] TO DISK = N'c:\backup_folder\SampleDB.bak' WITH INIT"
コマンドプロンプトでの操作は、batファイル化することで自動化できますが、参考としてVBScriptでBACKUPコマンドを実行する場合の実装例も紹介しておきます。
Option Explicit
Dim Database_Name
Dim FileFullPath
Dim objShell
Database_Name = "SampleDB"
FileFullPath = "c:\backup_folder\SampleDB.bak"
Set objShell = CreateObject("WScript.Shell")
objShell.Run("sqlcmd -S localhost -U sa -P password -Q ""BACKUP DATABASE [" & Database_Name & "] TO DISK = N'" & FileFullPath & "' WITH INIT""")
Set objShell = Nothing
batファイルや上記のコードを記述したVBSファイルをタスクスケジューラーに登録しておくことで、前述したジョブと同様にバックアップ処理を自動化することができます。
タスクスケジューラーの設定方法に関しても過去に当ブログで記事にしております。
良ければこちらもご一読ください。
データベースのリストア処理自動化
前項で紹介したバックアップ処理で出力したファイルを中継用サーバー、及び移行先サーバーへリストアする処理です。
バックアップ処理と同様に、リストア処理も何らかの方法で自動化させる必要があります。
具体的には以下の方法が可能です。
- SQL Server エージェントの「ジョブ」でリストアコマンドを実行
- batファイルからsqlcmdやosqlを利用してリストアコマンドを実行
前項のバックアップ処理とはコマンド内容が異なるだけで、それをSQL Serverの「ジョブ」から実行させるのか、「osql」や「sqlcmd」から実行させるのかの違いなだけであり、個々の詳しい実装方法の解説は割愛します。
尚、SQL Serverのリストアにおいて重要なのは、別のインスタンスで作成したバックアップデータを使用してデータベースを復元した際には、リストアした個々のデータベースに対して、「ユーザーデータの再紐付け処理」を行う必要があります。
この処理を実施しないと、リストアしたデータベース内に存在するユーザーでデータベースにログインすることはできません。
当項では、リストア時に実行するコマンド内容とそのコマンドの実装部分のみ紹介しておきます。
また、併せて「ユーザーデータの再紐付け処理」についても紹介します。
まず、リストアコマンド構文は以下になります。
RESTORE DATABASE [データベース名] FROM DISK = N'出力先フルパス' WITH REPLACE
「ジョブ」で実行する場合は、上記の構文を元に、コマンドをステップに登録するだけです。
例えば、以下のコマンドをステップに登録します。
RESTORE DATABASE [SampleDB] FROM DISK = N'c:\restore_folder\SampleDB.bak' WITH REPLACE
複数のデータベースをリストアする場合は、リストア対象のデータベースごとに、ステップを追加していきます。
次に、「sqlcmd」を使用してリストアする場合は以下のコマンドをコマンドプロンプトから実行します。
sqlcmd -S localhost -U sa -P password -Q "RESTORE DATABASE [SampleDB] FROM DISK = N'c:\restore_folder\SampleDB.bak' WITH REPLACE"
もしVBSで実装する場合は、前項のバックアップ処理で紹介したコードの11行目を以下のように書き換えて、バックアップファイルの場所を指定している変数の値を書き換えるだけです。
objShell.Run "sqlcmd -S localhost -U sa -P password -Q ""RESTORE DATABASE [" & Database_Name & "] FROM DISK = N'" & FileFullPath & "' WITH REPLACE""" ,1,True
ユーザーのマッピング処理
前述した通り、SQL Serverでは、別のインスタンスで作成したバックアップデータを使用してリストアをした場合に、併せてユーザーデータのマッピングが必要になります。
SQL Serverでは、SQL Serverへのログオンアカウントなどのインスタンス全体の設定は、システムデータベースの一つである「master」で管理しています。
バックアップ取得先と異なるインスタンスに対して、システムデータベース以外のデータベースをリストアするのは問題無いのですが、システムデータベースの一つである「master」までリストアしてしまうと問題が起こり得ます。
よって、「master」のリストアは行わずに、SQL Serverへのログオンアカウントは、移行先サーバー側で作り直すことになるのですが、それをすることで、ユーザー毎に持っている内部的なID番号が、master側で持つIDとリストアされてきた個々のデータベース側で持つID番号で一致しなくなります。
そのID番号をユーザー名などの表面上の名前を元に上書きして、masterで持つユーザーごとのIDと各データベース側で持つユーザーごとのIDを紐付ける行為を「再マッピング」などと呼びます。
再マッピングでは以下のコマンドを使用します。
EXEC sp_change_users_login 'Update_One', 'データベースユーザー名', 'ログインユーザー名'
このコマンドをマッピング対象のデータベースに対して実行します。
また、パラメーターの「データベースユーザー名」と「ログインユーザー名」は今回の用途であれば同じ名前を指定します。
尚、「sp_change_users_login」はSQL Serverに元々組み込まれているストアドプロシージャです。
マッピング対象のデータベースの指定も一行で表現する場合は以下になります。
USE データベース名 EXEC sp_change_users_login 'Update_One', 'データベースユーザー名', 'ログインユーザー名'
コマンド「sp_change_users_login」に関する詳しい解説は以下のMicrosoftのドキュメントをご確認ください。
尚、Microsoftのドキュメントでも言及されていますが、「sp_change_users_login」は将来的に削除される予定の機能であり、ユーザーの再マッピング処理は以下の構文を使用して実行することをMicrosoftは推奨しています。
ALTER USER データベースユーザー名 WITH LOGIN = ログインユーザー名
今回の記事では、従来からのマッピング方法である「sp_change_users_login」で解説していきます。
尚、このマッピング処理を「sqlcmd」で実行する場合のコマンド例は以下になります。
sqlcmd -S localhost -U sa -P password -d SampleDB -Q "EXEC sp_change_users_login 'Update_One', 'SampleUser', 'SampleUser'"
sqlcmdでSQL Serverへ認証する際に、接続先のデータベースを「-d」オプションで指定したうえで、sp_change_users_loginを実行しています。
また、VBSから実行する場合は、前述したサンプルコードの11行目を以下のように書き換えます。
objShell.Run "sqlcmd -S localhost -U sa -P password -d " & Database_Name & " -Q ""EXEC sp_change_users_login 'Update_One', 'SampleUser', 'SampleUser'""",1,True
バックアップファイルの転送処理
移行元サーバーから中継用サーバー、中継用サーバーから移行先サーバーへバックアップファイルを転送する必要があります。
この操作も自動化が可能です。
自動化する場合も実装方法は幾つかあります。
サーバー間でファイルを転送する場合、その転送処理を実行するサーバーの相手側に「共有フォルダ」を作成しておく方法があります。
また、もし「管理共有」が有効な場合は、共有フォルダを作成していなくて、サーバー間でファイル転送が可能です。
「管理共用」については以下の記事で詳しく紹介しています。
尚、データベースのバックアップファイルはデータベースの規模によっては非常に大きい場合もあり、通常のファイル転送では、処理に時間が掛かります。
よって、当ブログで以前に紹介させていただいた、「FastCopy」を使用して転送することもオススメします。
中継用サーバー、移行先サーバーで必要な各設定
当項では、中継用サーバー及び移行先サーバーで必要な各設定を紹介していきます。
どれも最初に一度設定しておけば良く、データベースの同期処理の都度実施する作業ではありません。
SQL Serverのインストールと初期設定
中継用サーバーと、移行先サーバーでは、今回のはそれぞれ、SQL Server 2008とSQL Server 2017又は2019をインストールして初期設定をしておく必要があります。
中継用サーバーにおいては、あくまで一時的に利用する環境ということもあり、厳密な設定は不要です。
移行先サーバーについては、その環境が先々本番環境として利用することになるため、適切に設定する必要があります。
尚、SQL Serverのインストールに関する手順については、過去に当ブログの記事でまとめております。
良ければ参考にしてください。
空のデータベースの作成
中継用サーバーと移行先サーバーにSQL Serverをインストールしたら、それらのインスタンスには空のデータベース領域を手動で作成しておきます。
今回の一連の処理では、中継用サーバーと移行先サーバーに対してリストアを実施します。
前項で提示したリストアコマンドでは、末尾に「WITH REPLACE」が付与されています。
このオプションは、指定された名前のデータベースが既に存在していたら、丸っと既存データベースをバックアップデータで上書きする指定です。
この上書き対象のデータベースにテーブルなどのオブジェクトを作る必要はなく、空のデータベースで問題ありません。
ただし、データベース名は移行元インスタンスで使っていたものと同じ名前を付けてください。
尚、中継用サーバーは意識しなくても良いですが、移行先サーバーに作成するデータベースの各種設定は適切な値を登録しておきます。
※データベースの「プロパティ」の各設定項目
「ログオン」ユーザーの作成
「リストア」の項でも解説していますが、データベースごとに作成される「ユーザー」と、インスタンスに対して作成する「ログイン」のユーザーは別々で管理されており、データベースのリストアした場合に、データベース領域内のユーザーはテーブルのデータなどと一緒に復元されますが、「ログイン」のユーザーは復元されません。
この「ログイン」ユーザーは、リストアを実行する前に、予め手動で作成しておく必要があります。
作成方法は、SSMSを使用してGUIで作成する場合、「オブジェクトエクスプローラ」直下の「セキュリティ」→「ログイン」を右クリックして「新しいログイン」を選択します。
新規「ログイン」の作成画面は以下になります。
設定すべき項目は、通常「ログイン名」や「認証方式」、「パスワード」などの「全般」で指定する項目です。
ロールなど残りの設定項目は、リストア後にマッピングすれば値が入ります。
手順としては、データベースをリストアする前に、予め「ログイン」ユーザーを作成しておくと効率的ですが、「ログイン」ユーザーの作成を忘れて先にリストアした場合、「ログイン」を作成時に併せて「ユーザーマッピング」を設定するとエラーメッセージが表示されます。
ただ、エラーは出ても「ログイン」ユーザーの作成自体はできているため、その後は前述した「sp_change_users_login」のコマンドでの再マッピングができます。
「ログイン」の状態が「無効」なるケースに注意
「ログイン」ユーザーの作成方法によっては、作成後に以下の画像のようなアイコンになる場合があります。
この場合、「ログイン」ユーザーを選択して右クリック→プロパティから「状態」を表示すると、以下のように、ログインが「無効」になっています。
この場合、対象のユーザーに対して「sp_change_users_login」コマンドを実行してもエラーになります。
因みに、以下のようなエラーメッセージになります。
メッセージ 15291、レベル 16、状態 1、プロシージャ sp_change_users_login、行 139 [バッチ開始行 0]
このプロシージャを終了しています。User 名 ‘SampleUser’ が指定されていないか、無効です。
この場合、対象の「ログイン」ユーザーのプロパティで「状態」を「無効」→「有効」に変更してください。
このように、ログインが「無効」でデータが作成されるケースとして、「CREATE LOGIN」構文でスクリプトを作り「ログイン」ユーザーを作成した場合などです。
ご注意ください。
当記事で紹介した一連の作業や設定のまとめ
今回の記事では、SQL Server 2000 から、SQL Server 2017 や 2019 へリプレイスする場合に必要になる知識や、リプレイス作業を効率的に進めるために必要な作業や技術を色々と紹介させていただきました。
記事のなかで色々なやり方を提示したがために、内容が分かりにくくなっているのが否めないため、当項では今回の記事を整理します。
SQL Server の互換性レベル範囲外のデータ移行
SQL Serverのバージョンごとに後方互換の範囲は決まっており、それを超えたバージョン間では、古いバージョンのインスタンスから作成したバックアップデータを新しいバージョンのインスタンスに対してリストアできない。
それをするには、両方のバージョンに対する互換レベルをサポートするSQL Serverのインスタンスを中継して移行する必要がある。
旧インスタンスと新インスタンスが後方互換のサポート範囲内であれば、中継用サーバーは不要。
古いSQL Server から 新しいSQL Serverへのデータ同期処理
中継用サーバーを用意しつつ、古いSQL Serverからバックアップを行い、それを中継用サーバーにリストアし、更に中継用サーバーから作成したバックアップを新サーバーへリストアする作業を全て手作業で実施することもできるが、この処理を自動化しておけば、毎日自動で旧サーバーのデータが新サーバー側に反映できるようになる。
その環境を作っておけば、新サーバー側で動作検証をすることも容易であり、いざ新サーバーを本番環境として切り替える際にも安全に行える。
よって、古いSQL Server から 新しいSQL Serverへのデータ同期処理を予め作っておくことが非常に重要。
データベースのバックアップ、リストア、転送処理は何でも良い
前項のデータ同期処理は、色々なやり方があり、どのやり方でやらないといけないといった決まりはない。
当記事では、SQL Serverのバックアップとリストアのコマンドを実行することを前提として、その実行方法を幾つか紹介したが、自身のやりやすい実装方法を選んでもらえれば良い。
ログインユーザーの再マッピングは必ず必要
SQL Serverの仕様上、データベースのみ別のインスタンスにリストアした場合、必ずそのデータベース内のユーザーとインスタンスに対するログインユーザーのIDは不一致状態になり、再マッピングが必要になる。
データの同期処理を自動化する場合、リストア処理と併せて再マッピング処理も必ず実施する。
最後に
今回の記事では、SQL Server 2000 から SQL Server 2017や2019へリプレイスをする場合の手順や、データ同期環境を構築する場合の実装方法について紹介しました。
今回の記事内容はレガシーなSQL Serverからの移行を前提とした記事ですが、互換性レベルのサポート範囲内のバージョン間でのリプレイスでも同様の手順でデータ同期処理の実装が可能です。
互換性レベルのサポート範囲内であれば、中継用サーバーは不要となり、直接旧サーバーから新サーバーに対して、今回紹介したバックアップ処理とリストア＋マッピング処理を実装するだけです。
また、本番用のSQL Server のインスタンスから、テスト用の SQL Server インスタンスに対して、データベースのバックアップも兼ねて同期をとるといった目的でも利用できます。
また、当記事で紹介したバックアップやリストア、マッピングなどの処理自体は、異なるインスタンス間でのデータ同期に関わらず習得しておくと便利なので、是非活用してください。
長々と読んでいただきましてありがとうございました。
それでは皆さまごきげんよう！
