こんにちは、青山です。

> 谷口です。
> 
> 杉本誠 wrote:
> > パススルークエリを使えば、レコードセットをごっそり持って
> > くることもなく、比較的軽い処理にできるのではないのでしょうか？
> 
> それともフロントエンドをAccess、DBをMySQLなどのクライアント-サーバ型の
> DBで、という意味でしょうか?
> (福田さんの件で言うクライアントとサーバ側１間をダイレクトで)

クライアントPCに負荷がかかるのか、サーバ側に負荷がかかるのかは
ケースバイケースですので、まず最初に、
・1回のクエリーに対する結果セットの期待行数
・クエリー発行の頻度
・クライアントPCの台数
・発行するクエリの複雑さ
あたりについて何らかの想定がないと考えようがない話だと思います。

闇雲に対策したのでは、クライアント側のプログラムをいじっても、
負荷について改善効果はなかったという話になる可能性もあります。


今回のケースと同じ構成ではないのですが、以前DBサーバと
クライアントの負荷を測定したことがあります。
RDBMSとしてはDB2(Linux & Win)とかSQL Serverとかだったので、
どこまで参考になるかは不明ですが。。

テストの構成としては、DBサーバ1台と、クライアントPCが1台
という構成です。
クライアントPCはWindows/Linuxで、プログラムは自作です。
また、１回のクエリーによる結果セットの行数は百万行としました。
クエリーは単純な全件検索で、WHERE条件はなしです。

結果としては、クライアント側の作りにもよる話ですが、
クライアントを単純な結果セット取出しのループ処理とした場合は、
サーバにはほとんどCPU負荷がかからず、クライアント側の
負荷がボトルネックとなりました。
# クライアント側の カーネル(TCP/IP処理) + プログラム(ループ処理)
# を足して常時ほぼ100%。
# ＆クライアントPCのCPU性能が高いほど処理時間が短くなる。

このため、ネットワーク帯域が十分であり、クライアントPCの数が
少ない場合は、クライアントPCの処理性能がボトルネックになる
可能性があるということになります。

このことから、結果セット行数が多い場合や、クライアントPCの
台数が比較的少ない場合は、Access側の処理を最適化する
(パススルークエリを使う等)のが効果的である可能性はある、
と言えると思います。


一方、サブクエリー等を含んだ複雑なSQL文を発行する場合は、
結果セットの行数にかかわらず、サーバ側の実行計画の作成時に
サーバマシンにかなりのCPU負荷がかかります。
また、クライアントの数が多くなったり、クエリーを頻繁に大量に
発行したりすることによっても、DBサーバ側に負荷が集中してくる
ことになりますが、今回のご質問では大規模なシステムを想定して
いるということですので、このパターンになる可能性も十分に
考えられると思います。

サーバ側の負荷が高い場合は、当然ながら、Accessの処理を多少
いじったところであまり意味がありませんので、
SQL文のチューニングや、DBのパラメータ調整や、場合によっては
マシンを高性能のものに置き換えたり、テーブル構成の見直し等も
必要になってくるかもしれません。


-- 
-----------------------------------
Hirokazu Aoyama <aoyama@xxxxxxxxxx>