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

4.11　アップグレード時間（ダウンタイム）の見積もり

アップグレードにかかる時間（ダウンタイム）は、次のように考えることができます。

この手順の場合は、マシン名の変更や Active Directory ドメインの参加、旧バージョンの SQL Server＋修正プログラムのインストールなどで、OS の再起動が必要になるので、その分の時間を加味しておく必要があります（∵最近のサーバー機は、OS の再起動に 10分程度かかるものもあるため）。

この手順の中で、作業時間（ダウンタイム）を大きく左右するのは、全データベースのオフライン バックアップと、そのバックアップ ファイルのコピーにかかる時間、これを新規サーバーへ上書きコピーするのにかかる時間です。これは、データベース サイズが大きい場合には、非常に時間がかかることになります。また、ストレージの性能（読み取りおよび書き込み速度）とネットワーク速度にも大きな影響を受けます。

◆ バックアップ時間の見積もり

オフライン バックアップの場合は、SQL Server を停止することで、ファイル（.mdf／.ldf）を直接操作できるようにするものなので、バックアップ時間は、次のとおりです。

オフライン バックアップにかかる時間 ＝ ファイル（.mdf／.ldf）をコピーするのにかかる時間

オンライン バックアップの場合は、オンライン バックアップ（BACKUP ステートメントの実行）にかかる時間とファイルのコピーにかかる時間が、バックアップにかかる時間になりますが、オフライン バックアップの場合は、ファイルをコピーする時間のみがバックアップにかかる時間になります。

◆ ファイルのコピーにかかる時間の見積もり

ファイルのコピーにかかる時間は、Windows Server 2008 以降の OS であれば、次のように確認することができます。

ファイルのコピー中に、［詳細情報］をクリックすると、このように １秒あたり何MBが転送されているか（MB/sec）を確認することができます。したがって、事前に数GB～数十GBレベルの実際のデータベースよりも小さいファイルをコピーして、転送時間を確認しておくことが重要です。この転送時間をもとに、オフライン バックアップにかかる時間を（かなり正確に）見積もることができます（コピーをネットワーク経由で行う場合は、移行当日のネットワーク利用状況を加味する必要もあるので、本番を想定したネットワーク利用状況で、転送時間をチェックしておくことをお勧めします）。

見積もりの考え方としては、オフライン バックアップのファイル サイズ（コピー対象のファイルの総サイズ）が 100GBで、転送速度が 100MB/sec の場合には、約 1,000秒（16分 40秒）の時間がかかり、転送速度が半分の 50MB/sec だったとすると、転送時間は 2倍の 2,000秒（33分 20秒）かかってしまう、転送速度が 2倍の 200MB/sec の場合は、転送時間は半分の 500秒（8分 20秒）で済む、といった具合です。概算は、次のように計算することができます。

1Gbps（ギガビット）の LAN 環境で、標準以上のストレージを利用している場合は、80～110MB/sec ぐらいは転送速度が出るので、仮に 100MB/sec と想定すると、100GB の転送には 1,000秒（16分40秒）ぐらいだろうと推測できます。事前に、10GB 程度のサイズのファイルをコピーしてみて、これが 10分の 1の 100秒（1分 40秒）ぐらいで完了するのであれば、その見積もりはかなり正しいということになります。

このように、LAN 環境であれば、400GB のファイル サイズであっても、1時間程度で完了することを考慮すると、オフライン バックアップでも（ネットワークが安定していれば）問題ありません。ただし、ファイル コピーの場合は、もしコピーの途中でネットワークが切れた場合には、ファイルのコピーをイチからやり直さなければいけない可能性があるので、そのリスクも考慮しておく必要があります。

例えば、ネットワーク経由だけでなく、USB HDD にも二重でコピーしておいて、万が一ネットワークが切れた場合には、USB HDD からも復旧できるようにしておくなどです。ただ、USB HDD の場合には、現状の多くのサーバー機では、最近のデスクトップ／ノートPCでの主流である USB 3.0 ではなく、古い USB 2.0 のみを搭載しているということがあります。USB 3.0 であれば、接続する USB HDD のスピードにもよりますが 70MB/sec 程度は出るところを、USB 2.0 だと 20～25MB/sec ぐらいしか出ません（USB 3.0 より 3倍ぐらい遅いことが多い）。また、USB 2.0 の古い USB メモリを利用する場合には、10MB/sec ぐらいしか出ないものもあります。

したがって、USB HDD などに保存する場合には、ファイルを gzip や 7zip などで圧縮してからコピーすることを検討するのをお勧めします。もちろん、圧縮には別途時間がかかりますが、コピー先の媒体が遅い場合には、圧縮をしてファイル サイズを小さくした方が全体として速く実行できる場合があります（事前に、圧縮にどれぐらいに時間がかかるのかを調査して、どちらが速く実行できるかを比較しておくことをお勧めします）。

上の転送速度の表には「1MB/sec」の場合も入れていますが、これはデータセンター間をまたがったデータ転送（WAN 環境）などを想定しています。WAN 環境だと「1MB/sec」程度しか出ないという場合もまだまだ多いと思います。この場合は、10GBのサイズでも 2時間 46分ぐらいかかてしまうことになります。これであれば、USB 2.0 が 20MB/sec（20倍のスピード）ぐらい出るので、10GB でも 8分 20秒という見積もりになります。

以前の弊社のデータセンターを変更した案件では、データセンター間の転送速度が 1MB/sec だったので、ユーザー データベースに関しては、オフライン バックアップではなく、後述のオンライン バックアップ（BACKUP ステートメント）で実行して、それを gzip に圧縮（∵SQL Server 2005 だったのでバックアップ圧縮が利用できなかったため）、圧縮したファイルを 1MB/sec の転送速度でコピーを行いました。このとき、万が一ネットワークが切れた場合を考慮して、並行して USB HDD へもファイルをコピーして（変更前のデータセンター内での作業）、コピー完了後に、それをタクシーで新しいデータセンターまで運ぶということを行いました。幸い、深夜だったので、ネットワークが切れることもなく、タクシーが渋滞にハマることもなく、どちらもスムーズだったのですが、ネットワークに遅れること 10分で、USB HDD が到着した、ということがありました。いずれにしても、二重、三重で万が一の事態に備えることは重要なので、実際の移行やアップグレードにあたっては、事前にいろいろなパターンを検証しておくことが重要です。

◆ tempdb をコピーしないという選択も有り

オフライン バックアップでは、システム データベースを丸ごと複製する、と説明しましたが、実は tempdb データベースに関しては、旧マスター側でバックアップを取得していなくても、新規サーバー側で復元することができます。弊社のお客様では、tempdb は、（性能のために）あらかじめ大きいサイズへ設定していることがほとんどなのですが、これをオフライン バックアップする（ファイル コピーする）となると、それだけで大変な時間がかかってしまいます。例えば、1MB/sec の WAN 環境で 50GB の tempdb をコピーしようとすると、それだけで 13時間53分もかかってしまうわけです。このような場合には、tempdb はコピーしなくても大丈夫です。

tempdb データベースは、SQL Server の起動時に再作成されるので、tempdb データベースのファイル（tempdb.mdf、templog.ldf）が存在しなくても、作成先となるフォルダー パスへの NTFS アクセス許可（サービス アカウントに対する NTFS アクセス許可）があれば、tempdb データベースを復活させることができます。このとき、SQL Server サービスの起動が完了した後に、tempdb データベースの復旧作業が行われるので、この復旧が完了するまでは、tempdb データベースへアクセスすることができません。また、.mdf ファイルの復旧には、瞬時初期化機能が有効であれば、あっという間に完了しますが、これが有効になっていない場合は復旧にも時間がかかります（復旧時間は、ストレージの書き込み性能に左右されます）。瞬時初期化機能を有効化するには、サービス アカウントに対して「ボリュームの保守タスクを実行」権利を付与しておきます。

◆ オンライン バックアップ時間の見積もり（ユーザー データベースの場合）

1MB/sec など低速な WAN 環境の場合には、ユーザー データベースに関しては、オフライン バックアップで取得するよりも、オンライン バックアップ（完全バックアップ）で取得した方が速く完了する場合があります。オンライン バックアップにおけるバックアップ時間は、次のように考えることができます。

オンライン バックアップにかかる時間 ＝ オンライン バックアップ（BACKUP ステートメントの実行）にかかる時間 （＋ バックアップ ファイルを圧縮するのにかかる時間。SQL Server 2005 の場合） ＋ バックアップ ファイルをコピーするのにかかる時間

オンライン バックアップで取得したバックアップ ファイルを圧縮するかどうかは、低速回線かどうかにもよりますが、低速回線の場合は、圧縮したほうが速くコピーが完了できる場合が多くなります。SQL Server 2008 以降であれば、バックアップ圧縮機能を利用して、（バックアップ時に）バックアップ ファイルを圧縮することもできます（後述）。

オフライン バックアップよりも、オンライン バックアップのほうが手順が増えますが、オンライン バックアップを利用するメリットは、次のようになります。

オフライン バックアップでは、.mdf／.ldf ファイルをコピーで取得するので、ファイル内の使用領域と未使用領域に関係なく、ファイル サイズの分だけコピーをする必要があるのに対して、オンライン バックアップであれば、使用領域のみ（使用中のエクステントのみ）のバックアップで済みます。データベース内の使用領域は、Management Studio で次のように確認できます。

該当データベースを右クリックして、［レポート］メニューの［ディスク使用量］からこのレポートを参照することができます（画面は SQL Server 2008 R2 ですが、他のバージョンでも同じように操作できます）。このレポートでは、［データ ファイルの使用領域］が .mdf ファイルのサイズで、下の円グラフが実際の使用領域（データやインデックスで利用している領域）なのか、未使用領域（未割り当て／未使用）なのかを確認できます。円グラフのほとんどが「緑」の場合は、ほとんどが未使用領域という意味になります。このデータベースは、.mdf ファイルが 10GBで、そのうちの使用領域（使用中のエクステント）が 1GB 程度、.ldf ファイル（ログ）が 5GBで、そのほぼすべてが未使用領域の状態です。このとき、オフライン バックアップを実行する場合は、10GB と 5GBの合計 15GB分のファイルをコピーしなければなりません。

仮に、ファイルの転送測度が 20MB/sec（USB 2.0 を想定）だとすると、12分30秒かかることになります。

これに対して、オンライン バックアップであれば、使用領域（使用中のエクステント）のみのバックアップで済むので、次のようにバックアップ ファイルのサイズは、わずか 832MB で済みます。

この例では、バックアップ時間は 約４秒（3.757秒）で、ファイル サイズが 832MB だったので、ファイルの転送速度が 20MB/sec だとすると、42秒でファイルのコピーが完了することになります（合計で 46秒）。これは極端な例になりますが、データ ファイル（.mdf／.ldf）と使用領域に差があるような場合には、このような差が生まれることになるので、ユーザー データベースに関しては、低速回線の場合や、USB 2.0 などの低速ストレージにコピーする場合には、オンライン バックアップを利用することを検討してみてください。

オンライン バックアップでは、SQL Server 2008 Enterprise または SQL Server 2008 R2 Standard エディション以上であれば、バックアップ圧縮機能を利用することもできます（SQL Server 2008 のときは Enterprise エディションが必要でしたが、SQL Server 2008 R2 以降では Standard エディションでも利用できるようになりました）。バックアップ圧縮は、次のように WITH COMPRESSION キーワードを付けるだけで実行できます。

バックアップ時間は 約2.5秒（2.478秒）に短縮でき、ファイル サイズが 245MB（1/3以下）にまで圧縮できているので、ファイルの転送速度が 20MB/sec だとすると、12秒でファイルのコピーが完了することになります（合計で 13.5秒）。圧縮なしの場合は 45秒、オフライン バックアップの場合は 12分30秒かかることを考えると、バックアップ圧縮の効果が分かると思います。

オンライン バックアップでは、次のように UNC（共有フォルダー）を指定して、ネットワーク上のサーバーへ直接バックアップすることも可能です。

これを利用すれば、バックアップをしつつ、ネットワーク コピーも行ってしまうということができます。LAN 環境などのネットワークが安定している場合には、お勧めのバックアップ方法です。一方、WAN 環境などのネットワークが安定していない場合には、万が一ネットワークが切れてしまった場合にバックアップをイチからやり直さなければならなくなるので、お勧めではありません。

オンライン バックアップからの復元時（RESTORE DATABASE ステートメント）も、次のように UNC を指定して実行することができます。

このように UNC を直接利用することでも、実行時間を短くできる場合があるので、検討してみることをお勧めします（ネットワークを介す場合は圧縮も重要になります）。

別マシンへの環境の丸ごと複製では、ユーザー データベースのバックアップおよび復元にかかる時間が大きな時間を占めることになるので、事前に入念なテストを行って、しっかりと実行時間を見積もっておくことが重要になります。

なお、オンライン バックアップに関しては、日々の定期バックアップにかかる時間を測定している場合は、そこからバックアップにかかる時間を見積もることができます。また、完全バックアップとログ バックアップを定期的に取得している環境の場合は、データベースの複製時には、最後のログ バックアップ以降の（未取得の）ログ バックアップのみを取得するだけで、最新の状態へ複製していくことも可能です。