過去の桐井戸端ＢＢＳ　（桐ver.７）
3704 使用者数の異常 神田　 1999/12/11-17:16
　桐ver7.1を25台ほどで使っています。サーヴァーはＮＴです。他の書き込み
にもあるように私のところも、ロールバックがあふれた、というメッセージに
頻繁に遭遇しその処置にたいがい嫌気がさしています。
　システムのチェックに簡単な帳票のモニタをつくって監視を始めたところ、
ロールバックのメッセージが頻繁にでるネットワーク上のデレクトリーで、使
用者数の異常が発生しました。最初2台しか使っていないのに3台と出たりして
いました。やがてロールバックが頻繁に出るようになると、もちろん例の2個
のファイルはそのたびに消していたのですが1台しか使っていない状況で30台
以上に使用者数が表示されるようになりました。管理工学社に問い合わせても
親切に対応はしていただいたのですがそういった事例はないということでした。
もう1つ仮想のドライブを作ってすべてを転送してみても同じ結果でした。
ほかの仮想ドライブに情報管理情報を設定すれば問題はありません。ファイル
のチェックもしてみましたが異常なし、ネットワークをダウンさせても同じで
したのでいちかばちか kiri7.usrを消したところ使用者数の異常はなおりました。
いまのところかわったトラブルもありません。
　どなたか同じトラブルに遭遇してませんか？
　ついでに、ファイル共有をしているファイルに4人とか5人が選択や並べ替え
をするとどうもロールバックがでやすいようですがどうでしょうか？

3707 Re: MIT 1999/12/12-13:16
記事番号3704へのコメント
MITと申します。
「ロールバック領域があふれました」の異常に関して桐Ｖ７系では
私も随分悩まされましたがＶ８を使用するようになって発生する事
が無くなりました。よってこの件について真剣に調査しなくなりま
したが、理屈としては各桐が共有ファイルに対して自分の現状を書
き込みする時に利用しているネットワークシステムとうまく連動し
ていないと言うことだと思います。こうなると共有ファイル情報を
読み取ってもおかしな結果しか返してくれません。
桐の共有ファイルに自己修復機能は無いのでおかしくなった共有
ファイルは神田さんのように手動で削除後、桐に再構成させてやる
必要はあると思います。
ちなみに私のネットワーク構成は（エラー発生当時）
サーバー：WindowsNT4.0(SP3)
クライアント：Windows95(OSR2又はそれ以降)
プロトコル：MicrosoftTCP/IPによるLAN(外部ルーティング無)
IPアドレスおよびサブネットはプライベートアドレスで各指定。
故にDHCPや名前解決関係の指定無し
です。
私の場合このエラーは共有ファイルを一括処理の繰り返しコマンド
などによるレコードの更新を実行した時、つまり
「共有ファイルに対して複数レコードの更新を高速に実行する」
時に発生していました。
実際にトランザクションをかけていた訳ではないので中途半端に
更新されて後始末に随分苦労しました。その後
*処理前にバックアップを取る
*この手の更新処理はクライアントによる更新が無い時間帯を選ぶ
*毎朝共有ファイルを削除してから最初の桐を起動する
などの対処療法的な対応策を取っていました。

以上、先に述べた通り私はＶ８にアップデートする事により問題解決
しましたので神田さんの期待される内容ではありませんがご参考まで
MIT

3711 Re: 神田 1999/12/12-19:05
記事番号3707へのコメント
　早々の返答ありがとうございました。ネットワークの構成も本校（三重県の
高田高校）と同じです。ただ違うところは私が全くのしろうとで、トランザク
チョンやロールバックも多分ネットワークにおける複数のファイルに対するセ
キュリティなのかな？という認識しかありません。もちろんこのあたりのこと
に対してのプログラムの対応の方法も未体験でおそらくプロからみればそうと
うあぶないことをしているのだろうと思います。
　ご返答のなかで私が確認したかったのはver８でのこのようなトラブルの発
生の状況です。実は管理工学のかたとお話したときにver８での改善はどうで
すか？と聞きましたが、幾分改善されたという状況です。ということでした。
　しかし、あれほど激しくver6からver7に無料グレードアップしたのにver７
からはほとんどなしのつぶていうのはひどすぎるとおもいませんか？

3716 Re: MIT 1999/12/13-00:08
記事番号3711へのコメント
神田さん
私の方ではＶ８にしてから「ロールバック..」のエラーが発生した
ことはありません。ただしクライアント台数は４台です。
しかし共有ファイルに対する編集はこの台数で毎日数時間は行って
います。
なお、編集している共有ファイルで大きいものは
件数：約３万件
容量：約８ＭＢ
です。
トランザクションとはデータ更新する処理を１つのブロック単位
で考えると言うものです。トランザクション内に追加、訂正、削除
など一連のデータ操作を定義し、もし完結すれば本当にデータ更新
となりこれをコミットと言い、もし途中で失敗すれば更新される
以前にデータを戻しこれをロールバックと言います。
身近な例では桐で１つの項目を訂正中にＥＳＣキー等で中止すると
訂正前の値に戻るのも一種のロールバックと考えて良いと思います。
オラクルなど少し上位のＲＤＢシステム以上ではトランザクション
の為にテーブルとは別に編集結果などを記録するログファイルがあり
桐などパソコン用ＲＤＢとこれらを区別する時このログファイルの
有無を挙げる人もいます。

ところで神田さんのお話ではクライアント２５台で利用されている
との事ですが、共有するユーザーは少ない方がトラブルは少ないので

共有ファイルの中で通常更新されることが無いものがあれば起動時に
各クライアントに読み込む。表引きされるテーブルなどはこうするの
が良いと思います。

学年、クラス、或いは先生単位でテーブルを分けていても支障無い場合
はこれらを同じ項目のある別テーブルとする事で共有されるユーザー数
を減らし、総合的な集計が必要な時に１テーブルに読み込む。

おそらく一括処理が必要となりますが、新規レコード追加は各クライア
ントに作業テーブルを用意してこれに入力し、入力終了後に共有テーブル
に書き出すようにする。作業テーブルが一種のトランザクションにもなります。

など、ご検討されてはいかがでしょうか？
また、サーバーで起動中のサービスで不必要と思われるものがあれば
負荷低減の意味でこれらを停止するのも有効かもしれません。ただし
サーバーチューニングは知識が必要ですので手馴れた業者に依頼され
た方が無難です。

ところで桐の発売元の対応ですが私の所にはバージョンアップ通知など
滞り無く郵送されて来ます。何かのミスで「なしのつぶて」なのだと
思いますのでその件を連絡されてはいかがでしょうか？
やや無骨ながら桐の発売元の対応は良いほうだと思いますよ。
以上ご参考までMIT

戻る