Access FE/BE構成による運用で気づいたこと

Access

はじめに

とある環境においてAccessDBをFE/BE構成にして運用しているのだが、あまり運用している情報がなさそうなので実運用の話も含めてメモしておく。

(SQLサーバ立てろよというのはまぁ置いといてもろて。閉鎖環境なので環境的に申請色々が面倒なのと、そこまで私は金もらってないからやりたくないし、後継者がいない問題が出そうなんで…)

FE/BE構成にした理由

あるチームが利用しているAcccessDBにおいて、共有モードをONにしているにも関わらずAccessDBが破損し、Accessによって作られた復旧・エラーメッセージファイルが配置元のフォルダに10個ほどできてしまっている状況が発生した。

まずどのように利用しているか聞いたところ、5人で同時アクセスをよくしていたらしく、よくわからないエラーもたまに発生していたということがわかった。

調査したところ、複数人がネットワーク上の同一Accessファイルを直接開いて利用していたことが、破損や動作不良の一因になっている可能性が高いと判断した。

MSも、複数人で共有するAccessDBについては、FE/BEに分割することでパフォーマンスが向上し、ファイル破損の可能性を低減できるとしているため、上長を説得してFE/BE構成を導入した。

職場での運用

今回の環境では、共有フォルダにBEを配置し、各端末にFEを配布して利用している。

言わずもがななのだが、ファイルサーバ側にFEをおくと、FE自体を同時起動してしまうことで不具合が発生する可能性があるため、各端末にFEを置いて起動する形で運用している。ファイルサーバ側のFEは各端末の更新用だから絶対さわらないでね!ってユーザに理解してもらっている形となる。
※一応間違えないところに置いてるけど、ファイルサーバ側を探されても困るので…

BEのメンテナンスの必要性とFE/BE化のデメリット

FEとBEの機能の違いについてはいろんなサイトで言及されているので説明は省く。

Acceessでは「閉じるときに最適化」という便利機能があるが、これはFE側で設定できても、BE側は最適化されないというデメリットがある。さらに、BEのメンテナンスについては「他のユーザが使用していないこと」を確認したうえで行うようにMSも明記している。

Compact and repair a database | Microsoft Support
Use the Compact and Repair Database command in Accecss to help prevent and correct the following problems: files growing…

ちなみに上長にBEメンテナンスをしたほうがいいと初期の段階で提案したところ、とりあえずいらんやろと言われてしまったため放置していたのだが、最終的にはBEが肥大化して動作不良を起こし、ユーザからの連絡があったことにより気づいたため、上長に報告した上でBEのメンテナンスを週1で行うことにした。

トラブル当初は70MほどあったBEもメンテナンスをすることで25Mほどに収まった。

ユーザからも動作がだいぶ軽くなったとの報告があったので、やはりFE/BE構成にする場合BEのメンテナンスは必須なんだなと私自身が勉強になった事案であった。

いつもの「閉じるときに最適化」が使えないというのは、割とデメリットな気がする。

今使われているAccessのFE/BE分割を考えている方は、これから先のメンテナンスのことも考えたうえで分割したほうがいいかもしれない。

実際のメンテナンス方法について

対象のAccess DBは、ほぼ毎営業日使用されており、利用頻度も高いため、勤務時間中にメンテナンスを行うのは現実的ではない。

そこで、タスクスケジューラを利用し、皆が退勤しているであろう夜間にPowerShellスクリプトを自動実行することにした。

処理の流れは以下のとおりである。

まず、ロックファイルが存在する場合は最終更新時刻を確認する。直近10分以内に更新されている場合は、利用中である可能性があるため処理を中止する。

一方、古いロックファイルが残っている場合は、BEファイルのリネーム可否を確認する。リネーム可能であり、ファイルを排他的に操作できることを確認したうえで、残留しているロックファイルを削除する。

その後、メンテナンス前のバックアップを1世代取得し、BEを最適化する。最適化後のファイルが正常に作成されたことを確認してから元ファイルと入れ替え、処理結果をログへ出力する。

翌朝には、作業ログの確認と、FEから正常に起動できることの確認を行っている。

上記のPowerShellスクリプトをタスクスケジューラへ登録し、メンテナンス実施日は端末を起動したまま退勤することで、夜間に自動実行させている。

現在のところ、ファイル容量30M前後に対してログ上の処理時間は10秒強である。処理内容自体は複雑ではないが、利用中判定、バックアップ、最適化後ファイルの確認、異常時の処理中止など、安全に実行するための判定を複数設けている。

まとめ

AccessのFE/BE構成は、複数人で利用する環境では非常に有効な構成だと思う。一方で、「分割したら終わり」ではなく、BEの定期的なメンテナンスやバックアップ、障害発生時の復旧方法まで考えておく必要がある。

私自身、当初はBEのメンテナンスは不要だと考えていたが、実際に運用してみると、定期的な最適化によってファイルサイズや動作速度に改善が見られた。また、自動化することで運用負荷もほとんどなくなった。

FE/BE構成を検討している方は、「分割方法」だけでなく、「運用方法」まで含めて設計することをおすすめしたい。

この記事が、これからFE/BE構成を導入・運用する方の参考になれば幸いである。