Jet データベース (MDB) のバックアップについて

Superdyn ML にて定期的にやりとりされる話題ではありますが、特にＯＳのテクノロジーについては進歩がないのでメモ程度にまとめておきます。

■大前提
マイクロソフト社は、Jet Database EngineをMicrosoft SQL Sever Desktop Engine (MSDE)にいずれ置き換えたいと思っている。
ただし、その割にはフロントエンドとしてのMicrosoft Accessは進化していない。Accessの最大かつ、唯一の特徴で、Wordに実装されるべきなのに未だ実装されていない「印刷条件の記憶」は、Access2007で一旦反古にされそうになったくらい。

■MDBファイルが壊れないバックアップ方法は、VSSを使う方法だ。
VSSとはMicrosoftのVolume Shadow Copy Serviceの事。使用中のファイルであっても一瞬安全に入出力をロックして壊れないようにバックアップ出来るテクノロジーだ。このAPIを直接我々がいじる方法は私は見つけていない。しかし商用のバックアップソフト、例えばAcronis True ImageはこのAPIを使っているようだ。したがって、これらの商用ソフトを細かくチューンアップして、MDBファイルのタイムスタンプを記録しておけば、ストレスがないだろう。

■RAIDの意味のなさ
MDBをバックアップするそもそもの理由は、データの不整合が起きたときに元に戻すことが出来るようにである。しかしRAIDを使用中は、データの不整合は両方のファイルに起きる。そう、律儀に両方壊れるのだ。だからRAIDは意味がない。

■しかし、ユーザーがそれほど神経質でない場合は、定期的なバッチファイルによるバックアップで十分だ。
WSHを使うも良し、バッチファイルを使うも良し、手作業で行うも良し、拙作CompMDBを使うも良し。
実は手作業で行うというのはフールプルーフとしては有用だ。自動化させるとどんどん自分が馬鹿になる事を経験しているユーザーは、手作業でのバックアップにこだわるべきかも知れない。

■最適化はどうするか。
レセプト作成時に特にインデックスが肥大化する。レセプト作成時は基本的には他ユーザーは接続しない運用が良く、必然的にそれが最適化に良いタイミングだ。レセプト作成時に最適化をするのはお勧めです。CompMDBは自動で最適化してくれる。

■トラブル時の書き戻しは考慮してあるのか。
トラブルが起きたとき、どのバックアップまでさかのぼるか、トライアンドエラーで素早く調査する必要があろう。それがすぐ出来るのは拙作CompMDB以外には見当たらない。

■クエリを使ったデータベースの多重化も良い方法ではあるし、datadyna.mdbの分割も一法ではあるが。
バージョンアップに対応するのが面倒で、今はやめてしまったが、受付テーブルを別mdbにするのは有効だし、患者～テーブル群、診療～テーブル群を定期的に二重化したデータベースに書き出す方法も悪くはないと思う。

■ただしMSDEないし、他のDatabase Engineに進化した場合、これらの努力は意味がなくなる。
いつまでJet Database Engineの寿命があるかわからないので、自分も根本的にいじる事のコストとベネフィットを考えて、手を出せずにいるし、そもそも・・・

■良いコンピューターを使っていれば、MDBファイルなんて、壊れない。
値段は張るけれど、良いPCを使い始めてからは、MDBファイルが壊れたことなんて、ない。これが結論だ。