RDBMSの復旧にかかる時間を計測した。リストアやリカバリにかかる時間と同じくらい，管理者の作業に時間がかかった。差分/増分バックアップはリカバリ時間を短縮するが，バックアップにかかる時間は予想より長い。
RDBMS（リレーショナル・データベース管理システム）のデータを意図的に消去し，復旧にかかった時間を計測した。論理バックアップ＊1からの復旧ではリストアに一番時間がかかり（図1[拡大表示]左），物理バックアップ＊2からの復旧ではリカバリに一番時間がかかった（図1[拡大表示]右）。ここでリストアとは，テープのデータを，RDBMSが稼働するディスク上にコピーする処理。リカバリは，コピーしたデータをRDBMSが使えるようにする処理である＊3。
一般的な方法で実験
実験の狙いは，RDBMSのバックアップと復旧にかかる時間を計測すること。これらの時間を知ることで，最適なバックアップ方法を選択できるようにする。実験はアシストに依頼した。利用したRDBMSは明らかにしていないが＊4，実験では一般的なRDBMSに備わっていると思われる機能のみを利用した。物理バックアップと論理バックアップの両方を行い，それぞれのデータから復旧させた。
24時間稼働するレンタルCD管理システムを想定。Linuxを搭載したサーバー機を1台用意し，テスト専用マシンとしてRDBMSを稼働させた。テープ装置は，実験マシンと同一LAN上のサーバーに接続している装置を利用した（図2[拡大表示]）。
実験項目は，「RDBMSの復旧にかかる時間と処理の内訳」（実験1），「物理バックアップ方法の違いによる復旧時間の差」（実験2），「バックアップ/復旧時間を変動させる要素」（実験3）---の3つ。実験1のバックアップと復旧はテープを利用したが，実験2と実験3はテープを使っていない。データベース・サーバー上のディスクにバックアップ・ファイルをコピーさせ，そこから復旧させた。
管理者の作業時間は半分弱
実験1では，RDBMSの復旧作業の内訳と，それらの作業にかかる時間を計測（図1[拡大表示]）。RDBMSの復旧作業は大きく，RDBMSが処理している時間と，データベース管理者が作業している時間に分けることができる。前者は「リストア」と「リカバリ」で，後者はそれら以外になる。今回の実験では，RDBMSの処理に約55％，データベース管理者の作業に約45％の時間がかかった。想像していたより，管理者の作業時間が大きな割合を占めた。
復旧作業におけるデータベース管理者の処理は，「障害認識」，「障害調査」，「リカバリ確認」，「アプリケーションからの確認」---など（図3[拡大表示]）。これらは，管理者の知識や経験，ノウハウなどによって時間の長さが変わる。言い換えれば，時間を短くすることが可能な処理である。
それに対してRDBMSが処理する時間は，基本的にはハードウエアのスペックやデータ量などで決まる。リストア時間は，テープに保管していたデータをRDBMSが利用しているディスク上にコピーする時間であり，リカバリ時間はそのデータをRDBMSが使えるようにするまでの時間である。
リストアとリカバリの時間は，バックアップ方法によってその比率が大きく違った。論理バックアップからの復旧ではリストアとリカバリの時間比は3対1で，リカバリ時間の方が短い。一方の物理バックアップでは時間比が4対5で，リカバリ時間の方が長くなった＊5。物理バックアップからの復旧では，リストア時間よりリカバリ時間に注意が必要だ。
増分と差分の違いは小さい
実験2では，物理バックアップ方法の違いによるバックアップ時間と復旧時間の差を計測した。実験した方法は，(1)全データベース・ファイルの複製を週に1回だけ取得（週1フル），(2)(1)に加えて毎日前回のバックアップからの変更情報のみを取得（増分），(3)(1)加えて毎日!)からの変更情報のみを取得（差分），(4)毎日全データベース・ファイルの複製を取得（毎日フル）---の4つ。(1)～(4)のバックアップ時間と，(1)～(3)の復旧時間を計測した（図4[拡大表示]）。
最初に注目したいのは，(1)週1フルのリカバリ時間の長さ。(2)増分と(3)差分の土曜日のリカバリ時間は約2分だが，(1)週1フルの土曜日のリカバリ時間は30分以上（図4[拡大表示]下の棒グラフ）。(2)増分や(3)差分に比べて，(1)週1フルのリカバリ時間は10倍以上も長い。
(2)増分と(3)差分は，バックアップ時間に注意したい。これらのバックアップ方法は変更情報だけを毎日取得するため，バックアップ対象のファイル・サイズは小さいが，バックアップ時間はファイル・サイズほど短くならない。フルバックアップのファイル・サイズは約363.3Mバイトで，月曜日の増分のファイル・サイズは約41Mバイト（図4[拡大表示]上の棒グラフ）。その差は大きいが，フルバックアップの時間は13分27秒，月曜日の増分バックアップの時間は11分48秒と，その差は小さい（図4[拡大表示]上の折れ線グラフ）。
(2)増分と(3)差分のリカバリ時間は，ほとんど差がなかった。最も時間差があった土曜日でも，(2)増分が2分15秒に対し(3)差分は1分42秒。その差は33秒あるが，リストア処理に約14分かかっているため，復旧時間全体で見るとわずかな差でしかない。
インデックスの作成時間は長い
実験3では，バックアップや復旧にかかる時間が，環境の違いでどのくらい変動するかを調べた。具体的には，(1)オンライン処理の有無によるバックアップ時間の違いと，(2)インデックスや参照整合性制約＊6の有無による復旧時間の違いを検証した。
(1)オンライン処理中のバックアップ時間の実験は，図2[拡大表示]で示した3つのテーブルをバックアップ対象にした。論理バックアップと物理バックアップの両方で実施し，バックアップ中にテーブルへのINSERT処理を行った。INSERT処理は一定時間間隔で繰り返し行い，バックアップが終わるまで繰り返した。結果は，バックアップ処理の時間は，オンライン処理中でもほとんど変動しなかった。論理バックアップを単独で取得した場合は1分10秒，同じ処理をオンライン処理中に実施しても1分11秒だった（図5[拡大表示]左）。物理バックアップでも同様の結果になった。
バックアップ処理に与える影響は小さかったものの，INSERTの処理時間に与える影響は大きかった。1万件のレコードを追加する時間は33秒だったが，論理バックアップ処理を並行稼働させると同じ処理が1分51秒かかった。3倍以上の時間がかかっている。物理バックアップを並行稼働させた場合は，約2倍の時間がかかった。
(2)論理バックアップからの復旧ではインポートした後でインデックスや参照整合性制約をつけることが多いので，それらの有無による復旧時間の差を検証した。図2[拡大表示]で示したレンタル履歴テーブルに対して，インデックスを1つ，インデックスを3つ，インデックス3つと参照整合性制約を2つ---の3つのパターンで，インポート時間，インデックスと制約をつける時間を計測した。結果は，予想よりもインデックスの作成時間が長かった。インデックスが3つある場合，インデックスの作成時間はインポート時間の約60％（図6[拡大表示]パターン2）。参照整合性制約をつける時間は，インデックスをつける時間に比べると無視できるくらい短い（図6[拡大表示]パターン3）。
