シス開発：使いやすいデータベースの構築法 |
パソコンを長く使っていると、いろいろなトラブルを経験する。その中で最も困るのは、大切なファイルを失うことだ。ハードディスクのクラッシュやマシンのフリーズといったトラブルだけが、原因とは限らない。単純な操作ミスで、大事なファイルを削除してしまうこともある。
アプリケーションならば再インストールするで容易に修復できるが、ユーザーが作ったファイルは失ったら終わりだ。とくにデータベースのファイルは、長い時間をかけて多くのレコードを入力したため、簡単には復旧できない。それに、再入力が終わるまで業務を停止すると、非常に大きな損害を与えてしまう。仕事で使っているデータベースでは、最悪のケースまで考慮すると、バックアップ・ファイルを保存するの当然のことである。
バックアップをやらない最大の理由は、作業を面倒に感じることだ。自動化しようとしても、データベース・ソフトによっては、簡単に作れない。そのため、一般のファイル操作でできる方法を中心に取りあげる。もっとも簡単であり、誰でもできるからだ。ただし、最悪のケースで困らないように、いくつかの注意点を理解しておきたい。
かなり多くの人は、バックアップしていることで、安心してしまいがちだ。ところが、あまり深く考えずにバックアップ方法を決めていると、最悪の事態でデータを失うことがある。
たとえば、次のようなケースを考えてみてほしい。バックアップ方法として、データベースのファイルを、MOなどのリムーバブル・メディアへ単純にコピーしていたとする。バックアップ作業を開始して、ファイルのコピー途中で読み込みエラーが発生した。元のデータベース・ファイルが壊れていたのだ。単純なコピーによるバックアップでは、前日のバックアップ・ファイルに上書きする方法なので、コピー開始時点で前日のファイルを消してしまっている。もとのデータベース・ファイルは読み込みエラーで壊れているのに加え、前日のバックアップは消えてしまい、正常なファイルは１つも残っていない状況だ。バックアップ時点でエラーが出るなんて、考えもしていなかった。さあ、どのようにして回復させればよいのだろうか．．。これは、現実に起こった話である。幸いにも、１カ月前のバックアップがあったので、それをもとに不足分を再入力して復旧させた。もちろん、作業は非常に大変だった。
この事例から分かるように、バックアップをすればよいというものではない。最悪の状況まで考慮して、より安全なバックアップ方法を採用すべきなのだ。すべてのトラブルに対応できる方法などないが、バックアップ中にトラブルが発生してもできるだけ大丈夫なように、バックアップ方法を考えなければならない。
【内容】最も簡単なバックアップ方法は、通常のファイル操作で行うこと。ただし、より安全な操作手順を採用することが大切。まず、少し大きめのバックアップ媒体を用意する。最低でも、バックアップするファイル容量の２倍は必要で、それが大前提となる。さて方法だが、まず最初に、バックアップ媒体の中に「前日分」フォルダを用意する。毎日のバックアップ作業では、前日のバックアップ・ファイルが最上位階層に入っている。そのファイルを、「前日分」フォルダへ移動する（図１）。そこには前々日のファイルがあるので、上書きする形で移動する。次に、バックアップ媒体の最上位階層に元ファイルをコピーする。この２段階の操作だけで、バックアップ作業は終わりだ。
【理由】前述のように、バックアップ作業でエラーが出ても大丈夫なコピー方法が必要だ。もっとも注意すべきなのは、バックアップが正しく終了するまで、前のバックアップ・データが消えないこと。バックアップを開始してコピー元ファイルにエラーが発見されても、「前日分」フォルダに前日のファイルが残っている。元ファイルとバックアップ媒体の両方が壊れない限り、データを失うことはない。また、別なメリットも生まれる。前日のバックアップに加え、前々日のバックアップも残っているので、より古いファイルからデータを復活されたいときにも役立つ。
【作成上の注意点】この考えを延長すると、３日以上のバックアップを残せる。「前日分」フォルダに加えて「前々日分」フォルダを用意すればよい。ただし、フォルダの数が増えるほど、コピーする操作が増えて面倒になる。また、バックアップ媒体の記憶容量も多く必要だ。
図１、まず最初に「前日分」フォルダへ上書き移動して、次にバックアップを取る。この方法なら、コピー元が壊れて読めなくても、前日のバックアップが消えない。
【内容】数回分のバックアップを保存する方法（前述）では、順番に移動する代わりに、各曜日のフォルダを用意して、実行する曜日のフォルダへ上書きコピーする（図２）。この方法なら、１回の操作で済み、１週間分のバックアップを保存できる。
【理由】数回分のバックアップを保存する方法も、３回程度なら、順番に上書きする操作もそれほど面倒ではない。しかし、１週間分の６回や７回を保存する場合では、上書きや移動の操作だけで数回になる。単純にフォルダを移動する操作なので、一番古いファイルに最新を上書きすれば済むはずだ。ここで問題なのは、一番古いものを見付ける簡単な手段だけである。１週間分を残すのなら、フォルダ名の曜日で消すファイルを見付けられる。もし曜日を間違えたとしても、最新は必ず残っているし、最悪でも前日の分が消えるだけなので、それほど大きな問題にはならない。
【作成上の注意点】同じような考えで、５回分を残すなら、５日ごとに日付をフォルダ名に付ける方法もある（図３）。もっと幅広く考えれば、面白い分け方やサイクルも思い付くだろう。
図２、１週間分を保存するときは、曜日ごとのフォルダを用意して、実施する曜日のフォルダへ上書きコピーする。日曜日にも実行するなら「日曜」フォルダも作る。
図３、５日分を保存するなら、日付の下１桁の数字でフォルダを用意する。月末だけは困るので、「31日」専用のフォルダを作るとか、使用するフォルダを一時的に変えるといった工夫が少し必要だ。
【内容】もし作業に余裕があるなら、１カ月単位のバックアップも保存する。毎月の第１営業日とか、決まったルールでバックアップを取る。それを１年分保存すれば、古いファイルからデータを取り出すことも可能となる。
【理由】この作業は、必ず実行するような性質のものではない。あくまで、もしかして困るかも知れないときのことを考えてのことだ。たとえば、誤って削除したことに気付いたが、削除してから１週間も経過してしまったとき、古いバックアップがあれば復旧が可能だ。再入力する方法もあるので、手間と効果を考えて決める。
【作成上の注意点】１カ月ごとにバックアップでも、ファイル容量が多くないなら、バックアップ媒体を１つか２つで済ませられる。１つで済ませるなら、１月から12月までのフォルダを用意して、対象月のフォルダへ上書きする。２つなら前半と後半で分け、前半の媒体には１月から６月までのフォルダを、後半の媒体には７月から12月までのフォルダを用意する。バックアップ方法は１枚のときと同じだ。３枚以上に分けるときも、同じ考え方が適応できる。
【内容】データベースのファイルをバックアップするときは、データベースが使っていないときに行う。もし使っているファイルが分からない場合は、データベースを終了して実行する。また、バックアップするタイミングは、１日分のデータを入力し終わったとか、入力作業が一区切り付いたときが望ましい。
【理由】データベース・ソフトの中には、入力したデータを自動保存するタイプもある。入力データが全部保存されたと確認するのは大変なので、ファイルを閉じてからバックアップする。もう１つ、入力の区切りでタイミングを決めるのは、リカバリー作業を考慮してのこと。どのデータまで入力したのか分からなければ、そのバックアップからデータを戻したとき、不足分として再入力すべき対象データを特定できない。
【作成上の注意点】データベース・ソフトを終了するためには、サービスを停止する必要がある。バックアップが毎日確実に取れるように、サービス停止時間帯を設けたほうがよい。その場合でも、処理時間を短くする工夫は可能だ。別なハードディスへいったんファイルをコピーし、すぐにデータベースを起動する。その後にゆっくりと、コピー用ハードディスクからバックアップ媒体へコピーし直す。この方法なら、データベースの停止時間を短くできる。なお、高度なデータベースソフトでは、起動したまま正確にバックアップする機能があるため、サービスを停止する必要はない。
【内容】バックアップは、１日分の入力件数を確認するなど、毎日の定常作業の中に組み入れる。また、誰でもできるように、可能な限り自動化したうえで、作業の手順書を用意する。
【理由】トラブルはいつ発生するか予測できないので、バックアップは毎日に取ることが重要だ。定常作業の中に組み入れることで、作業のし忘れを防止できる。
【作成上の注意点】バックアップ作業を簡略化するためには、操作の回数を減らすことが一番だ。ファイル操作でバックアップする場合には、対象ファイルを１つのディレクトリに入れておくことで、作業が簡単になる。複雑な操作が必要なら、専用の処理を作成するか、バックアップ用ユーティリティを活用する。
【内容】リカバリーの方法を詳しく説明した手順書を作成する。トラブルはいつ発生するか分からないので、データベースを運用し始める前に用意する。
【理由】トラブル時は頭が混乱していて、正常なときよりも作業ミスが発生しやすい。リカバリーを失敗すると、さらに悲惨な状況に追い込まれる。そのような失敗を防ぐためには、リカバリー手順書を事前に用意するのが一番だ。手順書どおりに作業することで、慌てている場合でも、作業ミスを少なくできる。
【作成上の注意点】リカバリー手順書の作成では、どのような内容を含めるかが重要だ。バックアップ、原因の調査方法など、関係する事項をできるだけ幅広く盛り込む（表）。
表、リカバリー手順書の代表的な内容。対象となる現象、リカバリー前の準備、リカバリーの手順などを含む。これは全体を示すための要約で、実際には、もっと詳しく操作手順を説明する。
１、リカバリー対象となるトラブル現象 ａ、データベース・ファイルを全く開けない
◇開くとシステムエラー
◇エラーで開けないとのメッセージｂ、開けるけれどエラーが発生し、修復できない
◇データベース内蔵の修復機能で修復できず２、リカバリー作業を始める前にチェックする項目 ａ、バックアップは、いつの時点のものか
◇更新日付を見て確認するｂ、トラブル発生の原因時の現象を確認
◇システムエラーかｃ、最近追加したシステムへの変更
◇ハードウェアの追加
◇システム機能拡張ファイルの追加
◇システムエラーの最近の発生頻度３、今後のことを考えた準備作業 ａ、壊れたファイルも念のための残しておく
◇バックアップとしてコピーする
（別なディスクにコピーしておく）４、ハードとソフトが正常かを確認 ａ、マシンとシステムは正常に動いているか？
◇いろいろなソフトを動かしてみて確認するｂ、ハードディスクの状態は正常か？
◇ディスク・ユーティリティでチェックするｃ、データベース・ソフトは正常に動いているか？
◇他のデータベース・ファイルをバックアップする
◇その後にファイルを開いて、各種機能を動かしてみる５、バックアップしてあるファイルのインストール ａ、バックアップをハードディスクにコピーする ｂ、データベース・ソフトで正常かを確認する
◇各機能を使用して確認するｃ、レコード件数を記録する ６、不足分のデータを再入力 ａ、不足分のデータを入力する
◇登録用紙のデータをタイプするｂ、入力後のレコード数を確認する
◇追加/更新/削除で、最終件数が一致するか？ｃ、入力後のデータベースをバックアップする
◇通常とは別のディスクにコピーする７、実際に使用を開始 ａ、実際と同じ状況で使用する ｂ、正常に動いているかを、決められた時間だけ観察する
【内容】リカバリーの手順書は、作業手順ごとに区切って説明する。その各行程では、作業が成功したかどうかを判断するための確認方法も含める。
【理由】リカバリーのような重要な作業では、各行程が本当に成功したかどうか、確認しながら慎重に進めることが求められる。どのようにして確認するかまで記述しておくと、リカバリー時点で困ることが少ない。ただし、細かく調べていると時間がかかるので、素早く判断できる確認方法を採用する。完全に正しいかを調べるのではなく、大きな間違いを起こしていないことを調べるのが主な目的。データを細かく見るのは、最後の工程で詳しく調べるときだけ。
【作成上の注意点】作業成功の確認には、２つの要素がある。何を調べるかと、どのようにして調べるかだ。調べる内容としてよく用いられるのはレコード件数で、全体の件数だけでなく、特定の条件を満たす件数なども使用する。また、より細かく調べる場合には、いくつかのレコードの値を一覧表で見て、データが正しいかどうかを判断する方法も用いる。調べる方法に関しては、ソフトのメッセージのどの部分を見るかを示す。
【内容】リカバリー手順書を作成したら、記述した手順どおりに実行できるかどうか、事前に試してみる。このとき、手順書を作成した人でなく、別な人にやってもらうことが非常に重要だ。間違いが見つかった場合には、手順書を修正する。システム環境が変わったときも、リカバリーを再び試すのがベスト。この意味からも、システムやデータベース・ソフトのむやみなバージョンアップは避ける。安定したのを確認してから使い始めたい。
【理由】もっとも困るのは、実際にリカバリーを始めてから手順書の間違いに遭遇すること。トラブル発生時は平静ではないため、手順書どおりに進められないと、余分なミスを起こしやすい。また、実際に試して初めて気付くこともある。手順書の分かりにくい表現、予想外の操作、などだ。まれにだが、バックアップやリカバリーのソフトが正常に動作しないこともある。実際のリカバリー中に、うまく動かないことが判明したのでは、取り返しがつかない。
【作成上の注意点】実際に試す意味の半分は、手順書の内容を手直しすること。そのため、どんな小さなことであっても、気付いたら手順書を修正する。正確さと分かりやすさに注意しながら、手順書の内容を良くする。
【内容】リカバリーを始める前に、データベースのファイルをバックアップする。たとえ壊れていても、ファイルのままコピーしておく。ただし、最後のバックアップ・ファイルとデータの中身が同じ場合は、バックアップする必要がない。
【理由】壊れたファイルの中に、重要なデータが含まれていることもある。また、バックアップしたファイルが使えないことも、可能性は低いがあり得る。データを取り出せる可能性がある限り、最悪のケースも考えてコピーする。使えるかどうかは、後で判断すればよい。
【作成上の注意点】間違って使われないように、壊れたデータであることをラベルに明記する。
【内容】最初にデータベースを設計するときから、トラブル時の調査に役立つ専用レイアウトを用意する。全部の項目を含んだ一覧表レイアウト、複数のデータの関連を調べるレイアウト、通常は表示しない項目（更新日や更新時刻など）を含んだレイアウト、などが考えられる。また、データが正しいか調べるレイアウトは、リカバリーが成功したか確認するときに役立つ。
【理由】トラブルが発生してから、調査に必要なレイアウトを作っていたのでは、非常に効率が悪い。早く復旧したいと慌てることが多いので、余分な作業を減らす準備が重要だ。
【作成上の注意点】調査専用のレイアウトは、データ入力用のレイアウトと同じように、各項目の値を変更できるように作る。誤って使われないように、通常の操作では呼び出せないように組み込む。
【内容】リカバリーの最終段階では、データ型だ私意かどうかを必ず確認する。全体のレコード件数、トラブルで壊れたデータの値、その日に入力したレコードが存在するかなど、代表的な事項を調べる。
【理由】全データを調べるのは無理なので、主だったデータだけを見るしかない。全体のレコード件数が正しく、トラブルに関係したレコードの値が間違っていないのなら、きちんと修復できた可能性は高い。ここでの作業は、単純なミスをしていないか確かめる意味もある。
【作成上の注意点】確認するためには、正しい値が分かっている必要がある。レコード件数であれば、前日までの総レコード数や、その日の入力件数などをハッキリさせる。日頃から記録することも大切だ。
【内容】リカバリーが終了し、データベースの中身が正しくなった直後には、まずバックアップを取る。それが終わってから正式な運用を開始する。
【理由】トラブルの原因を解明しないと、データベースが再び壊れることもある。また、原因を突き止めたと思っても、別な原因が大本だったりすると、やはり再発する。正しいデータを保存しておくと、またリカバリーするときに作業が簡単だ。
【作成上の注意点】ここで終了だという判断は難しいので、何度もバックアップすることもある。いつの時点のバックアップなのか分かるように、ラベルを付けて日付や時刻を書いておく。
【内容】トラブル発生前の最後のバックアップ・ファイルは、リカバリーが終わっても削除しない。最低でも１週間は保存しておく。
【理由】リカバリーが成功したように見えて、実は細かな部分で失敗していることもあり得る。本当に成功したかどうかは、ある程度の期間で使ってみないと判断できない。失敗だと分かれば、最後のバックアップ・ファイルを使うことになる。成功したと判断できるまで、最後のバックアップは保存すべき。
【作成上の注意点】非常に大切なファイルなので、誤って上書きされないように、注意書きを付けるなどの対処も必要。保存媒体の保管場所も、通常のバックアップ媒体とは別にする。
【内容】以上のように、途中で何回もバックアップするので、保存媒体は十分な数を用意する。トラブル時のバックアップ用として、事前に確保しておくのがベスト。
【理由】保存媒体が少ないと、前のデータに上書きする機会が増える。単純なミスだけではなく、予想外の原因や動作によって、途中のデータが必要になることもある。大切なデータを失わないためには、媒体の枚数は多いほど良い。
【作成上の注意点】媒体の枚数が増えると、どれに何が入っているのか把握しにくい。きちんとラベルを付け、中身をハッキリと記述する。日付や時刻だけでなく、どんな目的でバックアップしたのかも加える。
ファイルメーカーProには、ファイルサイズを小さく機能が組み込まれている。ただし、開いているデータベースのファイル自体を直接小さくする方法ではなく、別なファイルとして保存する方法だ。「ファイル」メニューの「別名で保存」を選び、「保存種別」を「最適化コピー」に設定して保存すると、ファイルサイズが最小になる。レコードやレイアウトの削除した領域を詰めることで、ファイルサイズを小さくする。欠点は、簡単なコピーよりも保存時間が長いことだけ。ファイルサイズが小さくなれば、より多くのファイルを１枚のディスクに収めることが可能だ。この機能を定期的に用いて、元のデータベース・ファイルと入れ替えれば、ファイルサイズの増大を防げる。データ量が多く、更新や削除が多いデータベースでは、試してみる価値がある。
（1996年12月９日）
より安全なバックアップ＆リカバリー方法 |
