過去の桐井戸端ＢＢＳ　（桐ver.８）

3491	障害対策について	初心者	1999/11/25-18:57
いままで桐ｖ5でLANによる販売管理をしてました。 売上入力処理はworkファイルに入力させて 登録時にのみ正データファイルをオープンして 登録後すぐクローズするという方法をとってました。 不便ですけど、途中でリセット等されても 正データファイルへの影響はありえないので そういう意味では安心でした。 ｖ8になって共有が可能になりましたが、迷ってます。 共有ファイルに複数端末から直接入力しているとして、 ある端末がハングアップ等したら、ファイルに対する 影響というのはどんな具合でしょうか？ 障害が起きるなんてのはあんまり考えなくて いいのでしょうか。 よろしくお願いします
3504	Re:障害対策について	佐田　守弘	1999/11/26-14:08
記事番号3491へのコメント 初心者さん これは桐(桐に限らないが)でシステムを組む際の基本設計の大きなテーマですね。 実際に運用していないので、細かい点まで詳しくはないのですが、私の考え方を述べさせて頂きます。 まず、LAN上でのデータベースの共有ですが、次の様な３つのケースがあると考えます。そして、それらについて個別 に考えるべきなのではと思います。ｌ �@オンラインで参照と入力とする場合 分かりやすい例が座席予約の様なケースです。その性格上、オンラインでの共有モードでの入力と参照が必要になり ますし、その方が便利です。ただし、これも考え方次第で、参照と書き込みを行う時だけファイルやレコード開いて書 き込みを行い、終わったら閉じるといった方法も不可能ではありません。 �Aオンラインで入力のみを行う場合 主として販売管理で売上を入力するケースです。レジと連動させてオンライン入力させたりするのも、このケースです。 売上の入の場合には、売上データを参照する必要がないので、共有モードでファイルを開いておく必要がないのでは と考えます。１顧客の入力が終わった後、あるいは一定時間毎に併合するといった形で処理する方が便利なのでは ないでしょうか。 �Bオンラインで参照のみを行う場合 データベース検索の様なケースです。共有モードで開く前提になりますが、更新を禁止した形で開かせることによって、 セキュリティが高くなると思います。 さて、共有端末がダウンした時のケースですが、これも実際に経験していないので、頭の中で考えただけの話になります。 まず共有更新時の表ファイルの扱われ方ですが、端末側でレコード更新されると、基本的には直ちに表ファイルが更 新されます。実際にはバッファ上で更新されただけで、ディスクへの書き込みはワンテンポ遅れる事はあります。しか しサーバが落ちていなｌければ、いずれはディスクに書き戻される訳なので、更新されているとみなして良いでしょう。 フリーズした端末からは、その後表操作が行えなくなるだけの事で、基本的には表ファイルは正常に稼働していると 考えて良いのだと思います。 しかし、万一端末側がフリーズでなく、暴走して勝手な事をやり出したとしたら、何が起きるかは分かりません。最悪 の場合、表ファイルが破壊される場合もないとは言えないでしょう。 このあたりは、実例ではどうだったのか、も含めて考える話かと思います。

戻る