SQL Server のことなら SQL Quality SQL Server パフォーマンス チューニング、コンサルティング、アドバイス、相談、定期診断、トレーニング

ホーム > 技術情報 > SQL Server 実践「SQL Server 2016 への移行とアップグレードの実践」

Microsoft SQL Server 2016 実践シリーズ (HTML 版)
「SQL Server 2016 への移行とアップグレードの実践」

松本美穂と松本崇博が執筆した SQL Server 2016 実践シリーズの「SQL Server 2016 への移行とアップグレードの実践」の HTML 版です。 日本マイクロソフトさんの Web サイトで Word または PDF 形式でダウンロードできますが、今回、HTML 版として公開する許可をいただきましたので、ここに掲載いたします。なお、記載している内容は、2016年 12月時点での情報になります。[2018年12月29日]

目次へ | 前のページへ | 次のページへ

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

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

00297

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

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

 

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

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

オフライン バックアップにかかる時間 = ファイル(.mdf/.ldf)をコピーするのにかかる時間

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

 

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

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

00298

ファイルのコピー中に、[詳細情報]をクリックすると、このように 1秒あたり何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秒)で済む、といった具合です。概算は、次のように計算することができます。

00299

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.03.1 ではなく、古い 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 ステートメントの実行)にかかる時間 + バックアップ ファイルをコピーするのにかかる時間

オンライン バックアップでは、バックアップ圧縮機能を利用して、(バックアップ時に)バックアップ ファイルを圧縮しておくのがお勧めです(後述)。

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

00300

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

00301

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

00302

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

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

00303

この例では、バックアップ時間は 約4秒(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 キーワードを付けるだけで実行できます。

00304

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

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

00305

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

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

00306

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

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

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

目次へ | 前のページへ | 次のページへ

事例1

SQLQualityは執筆とセミナーを通じて技術の啓蒙やエンジニアの育成支援も行っています
最新刊
SQL Server 2016 の教科書
SQL Server 2016 の教科書(ソシム)

弊社オリジナル制作の
SQL Server 2016 自習書も
マイクロソフトのサイトで公開中!
ダウンロードはこちら
セミナー風景
セミナー風景

ロングセラー
ASP.NET でいってみよう  SQL Server 2000 でいってみよう
ASP.NET でいってみよう
第7刷 16,500 部発行
SQL Server 2000 でいってみよう
第12刷 28,500 部発行
SQL Server 2014 CTP2 インメモリ OLTP 機能の概要
SQL Server 2014 CTP2 インメモリ OLTP 機能の概要(Amazon Kindle 書籍)

弊社執筆の
SQL Server 2014 自習書
マイクロソフトのサイトで公開中
目次はこちら

弊社執筆の
SQL Server 2012 自習書
マイクロソフトのサイトで公開中
ダウンロードはこちら
松本美穂のコラム
(公開活動などのお知らせ)

第60回:SQL Server 2017 自習書 No.3「SQL Server 2017 Machine Learning Services」のご案内
第59回:SQL Server 2017 自習書 No.2「SQL Server 2017 on Linux」のご案内
第58回:SQL Server 2017 自習書 No.1「SQL Server 2017 新機能の概要」のご案内
第57回:SQL Server 2017 RC 版とこれまでのドキュメントのまとめ
第56回:「SQL Server 2016 への移行とアップグレードの実践」完成&公開!
第55回:書籍「SQL Server 2016の教科書 開発編」(ソシム)が発刊されました
第54回:「SQL Server 2016 プレビュー版 Reporting Services の新機能」自習書のお知らせ
第 53 回:SQL Server 2016 Reporting Services の新しくなったレポート マネージャーとモバイル レポート機能
第 52 回:SQL Server 2016 の自習書を作成しました!
第 51 回:PASS Summit と MVP Summit で進化を確信!
第 50 回:新しくなった Power BI(2.0)の自習書を作成しました!
第49 回:Excel 2016 の Power Query を使う
第 48 回:新しくなった Microsoft Power BI ! 無料版がある!!
第 47 回:「Microsoft Azure SQL Database 入門」 完成&公開!
第 46 回:Microsoft Power BI for Windows app からの Power BI サイト アクセス
第 45 回:Power Query で取得したデータを PowerPivot へ読み込む方法と PowerPivot for Excel 自習書のご紹介
第44回:「SQL Server 2014 への移行とアップグレードの実践」ドキュメントを作成しました
第43回:SQL Server 2014 インメモリ OLTP 機能の上級者向けドキュメントを作成しました
第42回:Power Query プレビュー版 と Power BI for Office 365 へのクエリ保存(共有クエリ)
第41回:「SQL Server 2014 CTP2 インメモリ OLTP 機能の概要」自習書のお知らせです
第40回: SQL Server 2012 自習書(HTML版)を掲載しました
第39回: Power BI for Office 365 プレビュー版は試されましたか?
第38回: SQL Server 2014 CTP2 の公開
第37回: SQL Server 2014 CTP1 の自習書をご覧ください
第36回: SQL Server 2014 CTP1 のクラスター化列ストア インデックスを試す
第35回: SQL Server 2014 CTP1 のインメモリ OLTP の基本操作を試す
第34回: GeoFlow for Excel 2013 のプレビュー版を試す
第33回: iPad と iPhone からの SQL Server 2012 Reporting Servicesのレポート閲覧
第32回: PASS Summit 2012 参加レポート
第31回: SQL Server 2012 Reporting Services 自習書のお知らせ
第30回: SQL Server 2012(RTM 版)の新機能 自習書をご覧ください
第29回: 書籍「SQL Server 2012の教科書 開発編」のお知らせ
第26回: SQL Server 2012 の Power View 機能のご紹介
第25回: SQL Server 2012 の Data Quality Services
第24回: SQL Server 2012 自習書のご案内と初セミナー報告
第23回: Denali CTP1 が公開されました
第22回 チューニングに王道あらず
第21回 Microsoft TechEd 2010 終了しました
第20回 Microsoft TechEd Japan 2010 今年も登壇します
第19回 SQL Server 2008 R2 RTM の 日本語版が公開されました
第18回 「SQL Azure 入門」自習書のご案内
第17回 SQL Server 2008 自習書の追加ドキュメントのお知らせ
第16回 SQL Server 2008 R2 自習書とプレビュー セミナーのお知らせ
第15回 SQL Server 2008 R2 Reporting Services と新刊のお知らせ
第14回 TechEd 2009 のご報告と SQL Server 2008 R2 について
第13回 SQL Server 2008 R2 の CTP 版が公開されました
第12回 MVP Summit 2009 in Seattle へ参加

技術コミュニティでも活動中