アクセスデータベースを分割した後のパフォーマンスの低下

Question

アクセスデータベースアプリケーションがあります。 （免責事項：我々は異なる技術が好まれていましたが、状況は起こります...）。データベースを並行して使用および開発するために、アクセスDBのベストプラクティスのように、DBを「バックエンド」と「アプリケーション」の部分に分割しました。

パフォーマンスが低下していましたが、これまでは瞬間的になっていたクエリは数秒かかっています。これは少し驚くべきことでした。なぜなら、「より良いパフォーマンス」はDBを分割するプロの1つになっていたからです。パフォーマンスを元のレベルに戻すにはどうすればよいですか？

---

UPDATE

私たちはこれを理解するためにいくつかのより多くのテストを行ってきました。問題は、永続的にアクセスされ、かなりのネットワークトラフィック（避けられないレイテンシの問題を伴う）を引き起こすワークグループファイル（.mdw）によって引き起こされるようです。 .mdwをローカルファイルにコピーして代わりに使用すると、パフォーマンスが向上します。明らかに、ファイルをコピーすることは良い解決策ではありません（私たちは、アクセスDBを未知数のユーザーにネットワーク上で利用可能にしたいので）。どんな良いアイデアですか？

Answer 1

唯一の唯一の答えは、アクセスの使用から他の技術の使用への切り替えです。

Answer 2

各ユーザーにフロントエンドのコピーがあることを確認する必要があります。また、バックエンドへのパスが短くなるようにする必要があります。 Tony Toews, MVPにはパフォーマンスに関するヒントがあります。

Answer 3

何か注目すべき点は、本番アプリがリンクテーブルの接続文字列を更新するだけであるかどうかです。アクセスによっては、リンクされたテーブルにメタデータがキャッシュされるため、データのクエリが非常に効率的ではありません。解決策は、リンクされたテーブルを完全に削除し、その場合はゼロから作成することです。

これは、プロダクション・サーバーとは異なるテストベッド・サーバーを使用している場合にのみ重要です。両方が同じサーバー上にある場合、これははるかに少ない可能性がありますが、長いパスでパフォーマンスのボトルネックが発生する可能性があります。

これは、Tony's Performance FAQの提案の1つですが、バックエンドを置く場所に違いがあることを指摘しておきます。私は長いパス名を避け、すべてのバックエンドMDBをサーバー上のトップレベルストアに格納しようとします。つまり、\ Server \ Data \ My Files \ My Workgroup \ Myの長いパス名の代わりに\ Server \ Databasesをスペースやもので置き換えます。