みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
FMS19とFMP19でWindows環境、ServerはMACMini（10.14.6）の構成です。
データ容量が40万件近くになってしまいました。
実際のところデータ容量と速度はどの程度影響するのでしょうか？
今のところ速度についてはそれほど不都合を感じておりません。
また計算フィールドがあると時間がかかる気がするのですが、これもどうでしょうか。
集計フィールドがある画面はソートをします。このソートに時間がかかります。集計のときは、ソートが必要なのですが、ファイルはソートはしておくべきなのでしょうか？
最適化するというのは、別名で保存する以外にないのでしょうか？
よろしくお願いします
Offline
> 計算フィールドがあると時間がかかる気がするのですが、これもどうでしょうか。
その計算フィールドの内容次第でしょう。全て保存のものでしたら再計算させる時以外は速度に大きな影響はないはずですが、非保存でしたら、場合によっては遅くなります。
> 集計フィールドがある画面はソートをします。このソートに時間がかかります。集計のときは、ソートが必要なのですが、ファイルはソートはしておくべきなのでしょうか？
対象が多くなるとソートに時間がかかるのは仕方ないでしょう。集計レイアウトに配置されたフィールドによっては、速度に影響することがあります。
また、元ファイルでソートしておいても意味はありません。
ソートのキーとなるフィールドの索引を全てにしておかないと遅くなることもあります。
> 最適化するというのは、別名で保存する以外にないのでしょうか？
索引の整理、という意味でしたら、目標のフィールドの索引をなしにして一旦保存、もう一度ありに戻すと、索引テーブルそのものは最適化されます。
ストレージが SSD でしたら、最適化しても容量は整理されますが、劇的には早くならないです。
Last edited by Shin (2022-09-30 15:39:36)
Offline
ありがとうございます。別名で保存しても、容量がさほどかわりませんね。
あまりに多いデータ量は削除したほうがいいのでしょうか。15年にわたるデータがあるので、あまりに昔のものはいらないのです。
Offline
> あまりに多いデータ量は削除したほうがいいのでしょうか。
業種によるのでは。また、図面の管理をされているようですが、大昔の図面が出てきたりすると、実は取引先に感心されたりします。それで、信頼度が上がったりすることもあります。40万レコードくらいなら、古いデータも保存できる限りはおいておくのもありだと思います。
私が運用していたレコード数は500万レコードくらいでした。
Last edited by Shin (2022-09-30 18:29:51)
Offline
速度に影響するほどのレコード数ではないので、削除の理由としては不適当ですね。
もし現在のレコード数で極端にパフォーマンスが落ちているとしたら構造の問題のほうが大きいでしょう。
Offline
ありがとうございます。40万件ぐらいでは問題ないですか。運用上は遅いとかは感じておりません。このごろちょっと他のファイルへ移動できなかったり、ハングアップしたりしているもので、容量的な問題があるのかと思いました。40万件あるのは受注伝票関連で図面などはマスターで2万件程度です。
あと、最適化というのはやはりやっておくべきだと思うのですが、名前を変えて保存ではちょっと実行しにくいです。いい方法はないのでしょうか？
ファイルメーカサーバを使用していますが、このデータベースの「検証」というのがありますね。これはなにをしているのでしょうか。
Offline
> 他のファイルへ移動できなかったり、ハングアップしたりしている
ファイルの一部が損傷しているのでしょう。
問題がなかった頃のバックアップからクローンを取り出して、データを移行しましょう。損傷が大きくなっていくと、ファイルが完全に破壊されることもあります。
それでも起こるようでしたら、データが損傷していると思われます。そのレコードを探し出しましょう。データの移動ができないようですので、部分的にデータを移動させていくと、探し出せると思います。
最適化は、FM13だったかな、サーバーのファイルをそのままでクライアントから最適化できたバージョンがあったのですが、やはり不具合が出たのでしょうね。次のバージョンでは消えていました。
ファイルそのものを触ることになるので、サーバーから落として、別作業にしないと無理でしょう。時々のメンテナンスは、面倒でもサーバーでしておいたほうがいいですよ。
検証は、ファイルのデータベース構造に矛盾がないかどうかを検証する機能です。バックアップファイルに対して行うオプションもあります。ただ、データについては検証していないようなので、わからないかしれません。
Offline
了解しました。いつのバックアップが問題なかったかは、もう検討つきません。データの損傷を見つけるのはむずかしいですねー。
このへんで様子をみることとします
Offline
少なくとも、ちょっと古めのバックアップからクローンを作って、データを移行させておいた方がいいど思いますよ。
エラーを出すのでしたら、データの損傷を見るけるのは簡単です。クローンにデータを半分移行します。エラーが出なければ、残りの半分に損傷があります。さらに半分に対して作業します。それを20回ほど繰り返すと、データ数は数個以内になりますよ。
Offline
Pages: 1
[ Generated in 0.042 seconds, 9 queries executed - Memory usage: 564.42 KiB (Peak: 579.91 KiB) ]