データベースの破損事故から身を守るためには、データベースのバックアップが大事であることは言うまでもありません。

しかし思い立ったように、

「とりあえず、バックアップでもやろうか。。。」というような、行き当たりばったりのバックアップ作業では、システム管理者としては失格です。

データベースのバックアップ作業は、データベースのバックアップ計画に従って、正しく行なうべき重要な仕事なのです。

それでは、データベースのバックアップ計画はどのように立案したら良いものでしょうか？

その答えは、データベースが破損し壊れたとき、どのような手順に従ってデータベースを復元すれば速やかに復元できるかを考えることから始まります。

しかしながら、データベースの規模の大小によって、まったく復元手順は異なります。このためバックアップ計画と一言で言っても、

運用を行なっているデータベースごとにまったく異なる計画が立案されるものです。

またバックアップ装置に使用される記憶メディアの種類に応じても、バックアップ計画が異なります。

そこで本章では、中小規模で運用しているデータベースを想定し、

全体バックアップ

で十分間に合うデータベースの場合に、どのようなバックアップ計画を立案したらよいのか考えてみたいと思います。

全体バックアップで間に合っているデータベースが壊れたときの復元手順は、

（1） データベースが壊れた時点でのトランザクションログのバックアップを行なう
（2） 直近の全体バックアップを復元する
（3） （1）のトランザクションログを復元する

という手順になります。

ここで問題になるのは、（1）のトランザクションログのバックアップが失敗したときのデータ損失がどれくらいの被害を受けるのか？ということです。この被害をできるかぎり小さくなるようなバックアップ計画を立案することが大事です。

データ更新頻度が激しいデータベースであれば、その被害は大きくなるでしょう。また業務時間帯や、週日の作業内容、月間の作業内容によってもデータ更新頻度は異なると思います。

ただ全体バックアップで間に合うデータベースであるという条件なので、週日及び月間の作業内容は考慮する必要はありません。

1日の中で、どのような時間スケジュールに従って全体バックアップ命令を実行すればよいのかを検討します。そのためには、本来であれば、データベースを使用しているクライアント側オペレーターの本日の業務内容をデータベース管理者が把握し、今日はデータ更新が激しくなるのでバックアップ計画を修正しようとフレキシブルに対応することが求められます。しかしながら、そのような対応は現実的には無理な相談です。

そこで、ある程度の仮定を導入し、その仮定を実現するために、ある程度のお金を掛けることが必要となります。

その仮定として導入するものは、

データベースが壊れたときのトランザクションログのバックアップは常に成功する

という仮定です。この仮定が成立すれば、データ損失の危険性が無くなり、全体バックアップ計画の立案がしやすくなります。またデータ更新頻度に応じて、バックアップ計画をフレキシブルに変更する必要性も無くなります。

しかしながらこの仮定が常に成立するのであれば、1回だけ全体バックアップを取れば後は放っておいてもよいという意味にもなり、バックアップ計画は立案しなくてもよいことにもなります。

そこで実際に考えることは、この仮定を実現するために導入したハードウェア装置の信頼性を手がかりに判断することが大事です。

常にこの仮定が成立するものなのか？

それとも、

成立したらラッキー！

だと、考えるべきなのでしょうか？

購入したハードウェア装置によって、その立場が変わると思います。

そこで本章では、安価なRAID装置を購入したと考えて、「成立したらラッキー！」という立場で行きたいと思います。

例えばRAID装置上のコントローラーが故障し、その影響がDISKに波及してトランザクションログのバックアップが失敗することもあり得るわけです。

ですからこの仮定は、常に成立するものではないという立場です。

データベースが壊れてデータベースを復元したときに元通りにならなかった場合に、最大どれくらいのデータ損失が許容できるでしょうか？その時間を決めておく必要があります。

そのための試算として、データ入力業務に携わっている作業人員の人件費を基準に決める方法があります。データ再入力のために余計なコストが必要です。1時間の作業費はどれくらいでしょうか？何人ぐらいの方々がデータ入力業務に携わっているのでしょうか？

また、データ再入力を行なうために、1度入力した過去のデータを探さなければいけません。データは伝票のように、書式が整った形式になっているのでしょうか？それともオンラインで流れ込んでくるものでしょうか？オンラインなら入力されたデータのコピーはあるのでしょうか？またその保存期間は？

いろいろな条件を考慮しながら、このデータ損失の許容時間を算定して下さい。

大事なことは1度入力したデータを再入力の事態に備えて、しっかり記録しているかどうかです。記録が無いと再入力ができません。ですからデータベースアプリケーション側で、ある程度の再入力用データの保存が必要です。

この許容時間を保証するように、バックアップ計画が立案されます。

ここでは、許容時間は30分とします。

本章で立案するバックアップ計画では、2つの前提条件があります。この前提条件を満たさないデータベースシステムでは、別の立案が必要となります。

最初の前提条件は、全体バックアップの作業がマシンに与える負荷は小さいということです。バックアップ中にクライアント側データベースユーザに対して与える影響は小さいです。このため自由にバックアップ計画が立案できます。

そこで全体バックアップの作業頻度を多くすることも可能ですが、全体バックアップ頻度を下げる代わりに差分バックアップも活用したいと思います。

2番目の前提条件は、トランザクションログの継続管理は不必要なデータベースであるということです。

経営者側から、過去のある一時点でのデータベースのデータを調査して欲しいというような、データベース管理者としては辛い要求は拒否できると仮定します。

もしそのような作業を行なう場合は、トランザクションログの継続管理が求められます。

データベースサービスの運営時間帯を決めておく必要があります。ここでは早朝出勤を行なう社員が存在することを想定し、また残業も考慮し、データベースサービスは、午前6時から夜中午前0時までとします。また休日に出社する社員が存在することを考慮し、平日と休日の区別は無いものとします。

データ損失は最大30分という条件なので、30分単位で何らかしらのバックアップ命令を実行しなければいけません。

最初に全体バックアップ命令を実行する時間を決めます。前提条件から30分単位で全体バックアップを実行することも許されますが、ここでは、全体バックアップは2時間間隔で実行することにします。

全体バックアップのスケジュールが決まったら、最大データ損失時間を考慮し、それを満足するように差分バックアップ命令を入れます。ここでは30分単位で差分バックアップ命令を投入します。

また差分バックアップを実行するときは、トランザクションログのバックアップも合わせて実行するようにしましょう。これは、万が一、差分バックアップを記録した物理メディアが破損した場合の保険として、トランザクションログのバックアップのメディアが活用できるためです。

以上により、バックアップ計画は、

全体バックアップは、2時間間隔

差分バックアップは、30分間隔

トランザクションログのバックアップは30分間隔

と、決まりました。

さて次に考慮することは、バックアップ命令で作成されたバックアップデータの更新期間です。最大何日間のバックアップデータを保持する必要があるでしょうか？

過去1日だけでよいでしょうか？1週間でしょうか？それとも1ヶ月でしょうか？

あるいは永遠でしょうか？必要な日数を決めなければいけません。

ここでは全体バックアップの更新期間は特に定めず、管理者判断によって不要になったバックアップデータを適時削除することにします。

全体バックアップのバックアップファイル名は、

データベース名_FULL_日付.BAK

とします。

1日単位で新しいファイルを作成していくことにします。

また1日の中では、追記形式でバックアップセットを作成します。データベースの復元作業では、最後に記録されたバックアップセットを使います。

差分バックアップで作成されるバックアップデータは、どれくらい保存しなければいけないでしょうか？

本バックアップ計画では、全体バックアップ計画を補うために差分バックアップを使用しているので、継続管理は不要です。このため常にメディアの新規作成でバックアップを実行することにします。

差分バックアップのバックアップファイル名は、

データベース名_DIFF.BAK

とします。

トランザクションログのバックアップで作成されるバックアップデータも、同様にその保存期間を考える必要があります。ここでは継続管理は要求されません。

そこで差分バックアップと同様に、常に最新のバックアップだけを保存することにします。

またトランザクションログのバックアップを行なうときは、バックアップを行なったログを切り捨てるかどうか決めなければいけません。

もし切捨てを実行した場合は、データベースが壊れたときの復元方法で、このバックアップされたログが必要になります。

ここではログファイルの肥大化を防ぐために、ログの切捨てを実行することにします。

トランザクションログのバックアップファイル名は、

データベース名_LOG.BAK

とします。

バックアップを実行するストアドプロシージャを作成します。DB_BACKUP.SQLです。

DB_BACKUP 動作モード,データベース名,書き込み先ディレクトリ名

の書式です。

動作モードは、0が全体バックアップ、1が差分バックアップ、2がトランザクションログのバックアップです。

なおここでは、ジョブの開始時刻が午前6時で終了時刻が午前0時となりますが、ジョブスケジューリング定義では終了時刻は23時59分59秒までとなっております。

そこで開始時刻を午前0時、終了時刻を23時59分59秒までの2時間間隔として定義を行い、細かな微調整はストアドプロシージャの中で行なうことにします。

Enterprise Managerを使用してジョブを登録します。

図1：新規ジョブの作成

図1のように、新規ジョブを作成します。

図2：ジョブの全般の定義

図2のように、ジョブの全般を入力します。

図3：ジョブステップの定義

図4：ジョブ実行時のユーザ定義

図3、図4のように、新規ジョブステップを作成します。ジョブの実行時のユーザを、dboと定義しましょう。

図5：ジョブスケジューリングの定義

図6：定期的実行ジョブのスケジューリング

図5、図6のように、ジョブのスケジューリングを定義します。

以上で、全体バックアップのジョブの登録ができます。

差分バックアップとトランザクションログバックアップを実行するジョブの登録も、同様に行なってください。1つのジョブの中で、差分バックアップとトランザクションログのバックアップを実行します。トランザクションログのバックアップを先に実行するようにします。

EXEC DB_BACKUP 2 , ‘sample’ , ‘D:\BACKUP’

EXEC DB_BACKUP 1 , ‘sample’ , ‘D:\BACKUP’

このように実行すれば、差分バックアップの中にトランザクションログのバックアップ部分の効果が含まれるので、このログのバックアップはデータベースの復元操作時には使用せずに済みます。

データベースが壊れたときには、

（1） データベースが壊れた時点でのトランザクションログのバックアップを行なう
（2） 直近の全体バックアップを復元する
（3） 直近の差分バックアップを復元する
（4） (1)のトランザクションログを復元する

の操作手順となります。

もちろん差分バックアップを先に実行しても構いませんが、トランザクションログを切り捨てて実行している関係上、復元手順が次のようになります。

（1） データベースが壊れた時点でのトランザクションログのバックアップを行なう
（2） 直近の全体バックアップを復元する
（3） 直近の差分バックアップを復元する
（4） 直近のトランザクションログを復元する
（5） （1）のトランザクションログを復元する

このように、バックアップ手順の違いによって復元手順が多少異なるので注意してください。

またジョブのスケジューリング間隔は、午前0時から23時59分59秒までの30分間隔として登録を行ないます。細かな時間調整はストアドプロシージャの中で実行します。

以上により、バックアップ計画に従ったジョブの登録ができました。

第5回の学習のまとめ