(現在 過去ログ7 を表示中)

HOME HELP 新規作成 新着記事 トピック表示 ファイル一覧 検索 過去ログ

[ 最新記事及び返信フォームをトピックトップへ ]

■1007 / inTopicNo.1)  共有情報管理ファイル
  
□投稿者/ わかなまる -(2015/08/05(Wed) 22:21:56)
    桐の質問なのか…またはServer機の問題なのか…
    なのでこちらで質問させて下さい。
    しかも説明が下手なので長文となります。
    お許し下さい。

    ***環境説明***
    ネットワーク環境
    閉鎖(インターネット非接続)のローカルネットワーク。
    同一セグメントでルーター等もありません。

    Server機
    Windows2003Server SP2 32bit
    ファイアウォール等未設定。
    ファイルサーバーとして使用。
    「共有する.tbl」をWindowsの共有フォルダ上に置いてます。
    共有フォルダ設定はEveryOneに全権限(セキュリティも)渡してます。

    クライアント機
    Windows7 32bit 8台
    桐9-2012
    「共有する.tbl」の共有フォルダに8台とも同一の
    ネットワークドライブを割り当て、そのネットワークドライブ(Z:\)を
    桐の環境設定「共有情報管理ファイル」に設定しています。

    共有する.tbl
    顧客情報の基本データ[ID]、[氏名]、[性別]、[生年月日]など。
    [ID]は重複禁止項目です。
    この[ID]を比較項目としその他の項目を表引きや参照などで利用しています。

    **********

    この環境下で6〜7年ほど数多のトラブルと付き合いながら
    各部署が各部署に必要な.tblを作成し共通情報である顧客情報に付加すべき
    情報の入力を続けていました。

    各部署が作成する.tblは別部署でも閲覧する事が多いので、
    表をオープンする時に”共有で開く”設定をフォーム等で設定して
    .tblを共有状態で開き入力、運用しています。

    ところが今日、その共有状態で開く.tblを1レコード更新する際に
    Waitが非常に掛る自体となりました。
    (1レコードを削除する時も同様です。)
    カーソルがクルクルまわる、XPで言う砂時計状態が1〜2分程かかる状況です。
    8台どの.tblで行っても同一の現象が起きました。
    これでは業務に差し支えがでてきます。

    そこで、共有で.tblを開くことを止め専有で開きました。
    するとサクサク動きます。
    が、これではその.tblを別クライアント機から閲覧する時にイチイチ表を
    閉じてもらわなくてはなりません。

    次に共有で.tblを開くものの「共有情報管理ファイル」のチェックをはずし、
    共有する.tblをクライアント機上に移し表引き設定などもそこへ変更しました。
    するとサクサク動きます。
    が、これでは共有する.tblの更新が行われないので却下です。

    最後にServer上の共有フォルダ自体をServer上にコピーしフォルダ名を変え、
    フォルダの共有設定・アクセス権等を全く一緒(全権限許可)にして、
    各クライアント機にコピーしたフォルダを別途ネットワークドライブ(Y:\)に
    割り当て、そのネットワークドライブ(Y:\)を「共有情報管理ファイル」にしました。
    …サクサク動きました。

    結果的にはこれで改善ですが、全クライアント機の設定や.tblの表引きを変更…
    やるにはやるのですが、並行して

    1.なぜにこうなった?昨日まで平和だったのに…
    2.他に改善策は無いのか?
    3.将来また起きないのか?

    等を現在調べています。

    同様な現象、改善策を知っている、対処方法、参考すべきサイト等
    御存知の方居られましたらどんな情報でも結構ですので、
    御教授頂けましたら幸いです。
    よろしくお願い致します。

    長文駄文、最後まで御読み頂きありがとうございました。

引用返信 [メール受信/OFF] 削除キー/
■1008 / inTopicNo.2)  Re[1]: 共有情報管理ファイル
□投稿者/ ONnoji -(2015/08/05(Wed) 23:42:54)
    2015/08/06(Thu) 10:52:24 編集(投稿者)
    2015/08/05(Wed) 23:44:39 編集(投稿者)

    > そこで、共有で.tblを開くことを止め専有で開きました。
    > するとサクサク動きます。
    >
    > 次に共有で.tblを開くものの「共有情報管理ファイル」のチェックをはずし、
    > 共有する.tblをクライアント機上に移し表引き設定などもそこへ変更しました。
    > するとサクサク動きます。
    >
    > 最後にServer上の共有フォルダ自体をServer上にコピーしフォルダ名を変え、
    > フォルダの共有設定・アクセス権等を全く一緒(全権限許可)にして、
    > 各クライアント機にコピーしたフォルダを別途ネットワークドライブ(Y:\)に
    > 割り当て、そのネットワークドライブ(Y:\)を「共有情報管理ファイル」にしました。
    > …サクサク動きました。

    当方は、桐の共有は全く利用しないので、すべてタラレバの話となり恐縮ですが…。

    サクサク動く3つケースから、「共有情報管理ファイル」が原因なのかな?と予想してみました。

    「共有情報管理ファイル」がいかなる構成なのか当方は知りませんが、

    「共有情報管理ファイル」のデータが飽和して、メンテナンスに時間が掛かったと想像することも可能です。

    もちろん、これは確証もない予想にすぎませんが、「共有情報管理ファイル」が原因と疑うのも選択肢だろうと思います。

    > 1.なぜにこうなった?昨日まで平和だったのに…

    トラブルは突然やって来ます。

    「共有情報管理ファイル」が原因かもしれません。

    あくまでもタラレバですが…

    すべての利用者が一時的に共有を止めて、

    「共有情報管理ファイル」のフォルダをリセット出来れば良いのかもしれません。

    例えば、フォルダを削除して、同名フォルダを新規作成するとかです。

    ※実際に操作可能なのか、結果が改善するのかはタラレバなのでワカリマセン。

    以上ですが、当方は、桐の共有は全く利用しないので、すべてタラレバの話です。ご了承ください。

    p.s.

    たぶん外していると思います。m(__)m

引用返信 [メール受信/OFF] 削除キー/
■1009 / inTopicNo.3)  Re[2]: 共有情報管理ファイル
□投稿者/ わかなまる -(2015/08/06(Thu) 17:24:24)
    ONnoji様
    コメントありがとうございます。

    実は過去何度もこの「共有情報管理ファイルの場所」は
    痛い目に遭わされています。

    指定した「共有情報管理ファイルの場所」には、
    KIRI9.FSC
    KIRI9.SEM
    KIRI9.TXN
    KIRI9.USR
    なるファイルがあります。

    過去の経験より「このファイル削除して再接続したら直った!」を
    覚えてましたので同様の事を試みましたが結果は変わりませんでした・・・

    フォルダのリセットは思いつきませんでしたので明日にでもテスト
    してみようかと思います。
引用返信 [メール受信/OFF] 削除キー/
■1010 / inTopicNo.4)  Re[1]: 共有情報管理ファイル
□投稿者/ bonito -(2015/08/07(Fri) 12:12:04)
    > 全クライアント機の設定や.tblの表引きを変更…

    割り当てられたネットワークドライブのZとかYに特別根源的な意味がある訳では
    ないので、ネットワークドライブZを切断して、Yに割り当てられているフォルダ
    をZに変えれば、表引きの設定等はいぢる必要ないと思いますけど...

    あと、どこで見たか忘れたが、共有管理情報ファイルはネットワークドライブの
    ルートではなくその下にフォルダをつくってそこに置いた方がベターだという様
    な情報も昔あったような...

    もう一つ、桐が自動的につくる作業ファイル、○.$**の残留が多くなると○.tbl
    の動作が遅くなるというようなことも...(でもこれって共有だと当てはまらないか)
    共有管理情報ファイルにも同じような残留物が残るのかな???
    だとすると冒頭に書いたもう一度YをZに割り当てた場合、もとのもくあみか?
    (ファイル名が以前と同じになるから)

    以下K3の質問と回答から引用

    >9. データを入力し、その行を確定して次行を入力するのに数分待たされるように
    >  なってきました。
    >
    > 「共有管理情報ファイルの場所」にある次のファイルを削除してください。
    > ・KIRI9.FSC
    > ・KIRI9.SEM
    > ・KIRI9.TXN
    > ・KIRI9.USR
    > ・KIRI9.TX_(ファイルが存在しない場合もあります)
    > ・KIRI9.OR_(ファイルが存在しない場合もあります)
    >
    > なお、この作業は桐をすべて終了させてから行ってください。







引用返信 [メール受信/OFF] 削除キー/
■1011 / inTopicNo.5)  Re[3]: 共有情報管理ファイル
□投稿者/ ONnoji -(2015/08/07(Fri) 22:40:13)
    > フォルダのリセットは思いつきませんでしたので明日にでもテスト
    > してみようかと思います。

    当方は、桐の共有は全く利用しないので、すべてタラレバの話となり恐縮ですが…。

    「共有情報管理ファイル」のデータの問題とは別に、

    共有する表ファイル( .tbl )のページ分割のメンテナンス時間の可能性が考えられます。

    DOSの頃から、表ファイル( .tbl )はページ単位で管理されています。

    例えば、レコードの挿入が起こると、ページをオーバーフローした場合に、ページの分割(分裂と同じ)が起こります。

    今回の質問は、共有のマルチユーザの環境ですが、

    実は、専有のシングルユーザ環境でも、ページ分割によって結構なウエイト時間が発生することがあります。

    DOS桐に比べて、Windows桐はページサイズが大きく獲られていますが、

    表ファイル( .tbl )の構造上、ページの分割(分裂と同じ)は起こるハズです。

    ましてや、マルチユーザ環境なので、複数の人が好き勝手に行を挿入しているのかもしれません。

    ※行追加よりも、行挿入の方がページ分割を発生させると思われます。
    ※レコードは挿入するよりも追加する方が桐システムの負担が少ないハズです。

    今回も、あくまでもタラレバですが…

    すべての利用者が一時的に共有を止めて、

    表を専有で開き、

    ・[ファイル]メニュー→[表整理]を実行してください。
     または
    ・[表整理]コマンド

    ※余白率は、10%が標準です。0%ではページ分割が直ちに発生します。

    を実行してください。

    p.s

    >ところが今日、その共有状態で開く.tblを1レコード更新する際に
    >Waitが非常に掛る自体となりました。
    >(1レコードを削除する時も同様です。)
    >カーソルがクルクルまわる、XPで言う砂時計状態が1〜2分程かかる状況です。

    私は実際に経験がありませんが、専有のシングルユーザ環境でも、
    ページ分割によってこのようなウエイト時間が発生すると聞いたことがありますよ。

    当該の表ファイル( .tbl )に、[表整理]を実行することで改善するかもしれません(しないかもしれません。m(__)m)。



引用返信 [メール受信/OFF] 削除キー/
■1012 / inTopicNo.6)  Re[1]: 共有情報管理ファイル
□投稿者/ 尾形 -(2015/08/08(Sat) 03:55:07)
    どうも、こんにちは

    可能であれば
    サーバ・クライアント・ハブ・ルータ等
    全てのネットワーク機器の再起動

    お試しください

引用返信 [メール受信/OFF] 削除キー/
■1013 / inTopicNo.7)  Re[4]: 共有情報管理ファイル
□投稿者/ わかなまる -(2015/08/08(Sat) 16:25:49)
    ONnoji様

    再三のコメントありがとうございます。

    フォルダのリセットはフォルダの整理に時間が掛かっているので
    まだ試せていません。

    > ましてや、マルチユーザ環境なので、複数の人が好き勝手に行を挿入しているのかもしれません。
    各部署が利用している表は強制的に共有で開かせ、
    入力しているので行挿入は使用できない仕様となります。

    > ・[ファイル]メニュー→[表整理]を実行してください。
    主要な表で表整理も実施した後、再度共有で開いても
    結果は同じでした・・・


    ただ表整理のヘルプに
    「余白の割合は、多くするほどファイルサイズが大きくなり、
    少なくするほどファイルサイズが小さくなります。
    表のファイルサイズをもっとも小さくする場合は、余白割合を 0 にします。
    ただし、余白の割合を小さくすると、行の更新に時間がかかることがあります。」
    とありました。

    ここにもヒントがあるような、ないような、あるような・・・

    もう少し掘って見ます。

    ありがとうございました。
引用返信 [メール受信/OFF] 削除キー/
■1014 / inTopicNo.8)  Re[2]: 共有情報管理ファイル
□投稿者/ わかなまる -(2015/08/08(Sat) 16:28:43)
    bonito様

    コメントありがとうございます。

    > ないので、ネットワークドライブZを切断して、Yに割り当てられているフォルダ
    > をZに変えれば、表引きの設定等はいぢる必要ないと思いますけど...

    !?もう設定を弄り回しました。
    おっしゃる通り、サーバー側でなんとでもなる事ですね。
    時間を浪費しましたが良い経験と前向きに・・・(自己満足とも)


    > あと、どこで見たか忘れたが、共有管理情報ファイルはネットワークドライブの
    > ルートではなくその下にフォルダをつくってそこに置いた方がベターだという様
    > な情報も昔あったような...

    長い年月の後付け工法が祟ったのか「表引き元となる共有すべきファイル」が複数あり、
    ネットワークドライブ下にてフォルダ分けされています。
    Z:\hoge1\ID.tbl
    Z:\hoge2\ID2.tbl
    Z:\hoge3\ID3.tbl
    のようになっており、横着者でして(Z:\)丸ごと「共有管理情報ファイルの場所」としてます。
    各hogeフォルダにも.FSC.SEM.TXMなどのファイルがあり削除してみたりしても変化無しでした。


    > もう一つ、桐が自動的につくる作業ファイル、○.$**の残留が多くなると○.tbl
    > の動作が遅くなるというようなことも...(でもこれって共有だと当てはまらないか)

    表作業中?後?のTEMP的なファイルの.$OO的なファイルも削除しても変化無しです。

    先人の知恵をお借りしてhabata様掲示板や、この多遊様掲示板を巡って見たものの
    同様の症例が少なく凹んでいる次第です・・・

    ありがとうございました。
    もう少し悩んでみます。
引用返信 [メール受信/OFF] 削除キー/
■1015 / inTopicNo.9)  Re[2]: 共有情報管理ファイル
□投稿者/ わかなまる -(2015/08/08(Sat) 16:29:33)
    尾形様

    コメントありがとうございます。

    > 可能であれば
    > サーバ・クライアント・ハブ・ルータ等
    > 全てのネットワーク機器の再起動

    サーバ再起動は試みましたが効果はありませんでした。

    全ネットワーク機器リセットは現状では難しいですが確かにやってみたいです。
    たまたま来月に建物全体の計画停電があります。
    そこで色々試してみようと思います。
    (そういいながら忘れてUPS確認だけで終わりそうですが・・・)
引用返信 [メール受信/OFF] 削除キー/
■1016 / inTopicNo.10)  Re[1]: 共有情報管理ファイル
□投稿者/ わかなまる -(2015/08/08(Sat) 18:56:41)
    改善方法がありました(?)ので報告です。

    最後のクライアント機の設定を施している際に以下を試しました。

    1.(Z:\)のネットワークドライブを切断
    2.再度(Z:\)に切断前と同じフォルダをネットワークドライブに割り当て

    サクサク動きました!
    たったコレだけの事で改善はできました。

    最後のクライアント機なので「共有するPCが減ったから」かもしれませんが、
    この切断再接続をする前は同様の現象、Wait掛っていたのを確認しました。
    なので「共有するPCが減ったから」は若干否定的です。

    ただ「簡単な解決方法」が見つかっただけで、結局なぜ?って疑問は残りっぱなし、
    かつ、各クライアント機の設定変更終了のため闇に葬り去られそうです。

    解決済み!と致しますが今後も時間を見つけて究明したいと思います。

    コメントを頂きましたONnoji様、bonito様、尾形様
    ありがとうございました。
解決済み!
引用返信 [メール受信/OFF] 削除キー/



トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

Mode/  Pass/

HOME HELP 新規作成 新着記事 トピック表示 ファイル一覧 検索 過去ログ

- Child Tree -
- Antispam Version -