データベースのバックアップ／リカバリー
万一のトラブルによりデータの整合性を失ったとき，データベースを正しく回復する機能が必要になります。それには，バックアップとリカバリーを行います。
バックアップ
定期的に（それをチェックポイントといいます）に，データベース全体をバックアップファイルにコピーします。その間は，更新が行われるたびに，更新前と更新後の情報をジャーナルファイル（ログファイルともいう）に記録しておきます。
- フルバックアップ
フルアップバックとは、対象となるファイル全体をバックアップすることです。 - 差分バックアップ
フルアップバックには時間がかかります。それで、フルアップバックした後から次にフルアップバックするまでの期間は、フルバック以降に変更のあったすべての情報をジャーナルファイルに記録します。障害が発生したときは、直前のジャーナルファイルと前回のフルバックアップの二つを用いて復旧します。 - 増分バックアップ
フルバック以降は、毎日の変更のあった分だけを、ジャーナルファイルに記録します。毎回のバックアップは差分バックアップよりも少ない情報ですみます。しかし、障害発生時には、前回のフルバックアップとそれからの増分バックアップのジャーナルファイルをすべて用います。復旧作業が面倒になるだけでなく、期間中のジャーナルファイルの一つにでも破損があると復旧できなくなります。
バックアップ関連
- 多重バックアップ
複数の媒体にバックアップします。バックアップのいずれかが生きていれば回復できます。 - バックアップの世代管理
世代管理とは、最新データをバックアップするだけではなく、それ以前のバックアップデータも保存しておくことをいいます。例えば、1日1度バックアップをとる場合、１世代といえば１日前のデータに、3世代といえば３日前のデータにさかのぼれるように管理することを指します。しかし、これは毎回フルバックをするときであり、差分バックアップなどと組み合わせるときは、それに応じた世代管理が必要になります。
バックアップでの留意事項
- バックアップすべきデータを検討する。
すべてのデータをバックアップするのでは、バックアップ量が膨大になってしまいます。逆に、リカバリー時に、あるシステムが一部のデータが欠けているために復旧できないのでは困ります。業務遂行の観点から検討する必要があります。 - いつバックアップするかを検討する。
バックアップ処理は長時間かかります。それが業務処理の効率を下げるのは不適切です。それで、業務時間外に実施するのが一般的です。 - 別媒体にバックアップする。
対象ファイルとバックアップファイルを同じ磁気ディスクに作成すると、その磁気ディスクが損傷するとバックアップファイルも失われ、リカバリーができません。 - バックアップファイルの容量を減らす。
一般にバックアップ量は大量になります。また、ランダムアクセスファイルはよりも大容量になりますし、それを保管するには磁気ディスクや光ディスクなど高価と媒体が必要になります。業務ではランダムアクセスファイルであっても、バックアップファイルはシーケンシャルファイルにして、安価な磁気テープを用いるのが一般的です。 - バックアップファイルの保管場所を検討する。
同一室内、建物内に保管すると、災害発生時には使えません。そのため、重要なバックアップファイルは自社の遠隔地コンピュータセンターや社外のデータセンターなど遠隔地にコピーを保管する必要があります。インターネットで遠隔地のファイルサーバをアクセスできるＮＡＳやＳＡＮの技術を用いることが普及しています。
（注）ホットサイトとコールドサイト
遠隔地バックアップセンターは、大きくホットサイトとコールドサイトに区分できます。
ホットサイトとは、日常から待機状態にしておき障害発生時に直ちに再開できるサイトです。例えば東京と大阪に拠点を置き、双方が互いの処理を代行できる環境にしておき、互いにバックアップデータを交換して、最新の状況にしておきます。
コールドサイトとは、障害発生時に必要なハードウェアやソフトウェアを持ち込み業務を再開する形態です。社外データセンターのなかには、単にバックデータの保管だけでなく、このようなサービスを提供することもあります。
リカバリー処理
トラブルが発生したときには，リカバリー処理をします。
リカバリーに似た用語にリストアがありますが、リストアはバックアップしたデータを物理的に「復元」することで、リカバリーは、リストアしたデータに対して、その後の変更内容を反映させ最新の状態（障害発生直前の状態）に「復旧」することです。
リカバリーには，ロールフォワードとロールバックがあります。
- ロールフォワード
- データベースがハードウェア的に障害が発生したときの対応です。このディスクは使えないので、バックアップしていたファイルを別のディスクにコピーして、そのディスクでデータベースを復元することになります。
バックアップファイルからデータベースを復元して，ジャーナルファイルにより更新を行い，障害直前の状態にまで回復します。リカバリーの順序が更新と同じ順序でやり直すことになります。 - ロールバック
- 更新中に、何らかの原因で異常終了したときの対応です。この場合でもロールフォワードにより復元できますが、異常終了するまでの状態は生きた（ディスクが読める）状態になっているのですから、ロールフォワードをするのは無駄です。原因となったトランザクションの処理をやらなかったことにして、その直前の状態に巻き戻すことになります。
図では，状態２は正常に完了し，状態３になるときに障害が発生したことを示しています。このときは，ジャーナルファイルに状態２と状態３の違いが残っているので，それを用いて状態２にまで戻します。リカバリーの順序は更新の順と逆になります。
トランザクションから見た検討
次のように更新トランザクションＴ１～Ｔ５があり、チェックポイントを過ぎて障害が発生したとします（〇印は正常に更新されたことを示します）。
ロールフォワードのときは、チェックポイント時から障害発生時までの間が抜けているのですからＴ２・Ｔ５が対象になります。そのうち、Ｔ３は状態が同じですから、バックアップファイルから戻しただけで済むこともあります。またＴ５はまだ処理が完了していないので、単にトランザクションを再発生するだけで済みます。
ロールバックでは、既に処理が完了しているトランザクションは修正する必要はありません。障害発生時に更新処理中であるＴ３とＴ５が対象になります。
チェックポイント 障害発生 異常終了 ハード故障終了
──────┬───────┬─→
Ｔ１ ───○ │ │ 対象外 対象外
Ｔ２ ────┼──○ │ 対象外 ロールフォワード
Ｔ３ ───┼───────┤ ロールバック 注
Ｔ４ │ ────○ │ 対象外 ロールフォワード
Ｔ５ │ ─────┤ ロールバック 注
データベースの再編成・再構築
上記の障害ではなく通常の利用時でもデータベースの保守が必要になることがあります。その対応に再編成と再構築があります。なお、ここではテーブルについて記述しますが、インデックスでも同様なことが起こり、それらを同時に行う必要があります。
データベースの再編成（再構成）
通常のファイルを削除しても、その領域に消去フラグがつけられるだけで解放されません。そのため、ファイルの創成や削除を繰り返している間に、磁気ディスクには虫食い的な空き領域が散在します。これは磁気ディスクの容量を無駄にするし、処理効率を低下させます。空き領域をまとめて連続領域に並び変える作業がデフラグメンテーション（デフラグ）です。
これと同じ現象がデータベースでも発生します。データの追加、更新、削除を繰り返すと、テーブル内に再利用されない領域が発生します。それを整理する作業をデータベースの再編成あるいは再構成といいます。
データベースの再構築
データベースの再構築とは、データベースを作り直すことで、次の手順で行います。
・既存のデータベースをテキストファイルにダンプ（データベースダンプという）し、
・必要ならば、新スキーマを作成し、
・新スキーマにより、テキストファイルをデータベースにする
次のような場合に再構築が必要になります。
- データベース領域の拡大
データベースを創成するとき、データベースが確保する最大領域を決めます。データ量が増大し最大領域をオーバーするとエラーになります。最大領域に近づくと頻繁に再編成が必要になります。そのため、データベース領域を拡大しなければなりません。 - 列の追加、削除
既存のデータベースに対して直接に列の追加や削除をすることはできます。しかし、これも再編成と同じ現象が起こりますし、大規模になると作業が煩雑になります。このようなときは、再構築をするほうが効果的です。 - ページサイズの変更など
データベースは、内部ではページという単位で管理されメモリに出し入れされています。ページサイズの大小が処理時間に影響します。データベースの運用環境が変化すると、ページサイズを変えるのが適切な場合があります。このような、データベースの創成時に設定したパラメタを変更するには、再構築が必要になることが多いのです。
再構築の作業中に旧データベースの更新処理があると、新データベースと整合性がとれなくなるので、作業期間中は利用を止めることになります。そのため、再構築を頻繁に行うのは不適切です。