none
MDBに対するSELECT実行が極端に遅くなる現象について

    質問

  • GUIアプリケーションからODBCを利用してMDBと接続していますが、SELECT文によるデータ検索に非常に時間が掛かることが稀に発生して困っています。
    アプリケーションとMDBは同じPCに配置しています。アプリケーションはVC++で作成しています。
    原因と解決策をご教授いただきたくお願いします。

    ■詳細
    本現象を調査するため、SELECT文の実行時間をロギングする仕組みをアプリケーションに実装して1週間ほど運用。
    運用中はMDBへのデータ登録も行われる。
    その時の結果は次の通り。最短で200ミリ秒で完了する処理が、最大で4分かかることがある。

    <SELECT文の処理時間>
     最短の処理時間:200ミリ秒
     最長の処理時間:4分
     ※SELECT文の試行回数は600回
     ※試行回数に対する処理時間の割合
        1秒以内    11%
        1~30秒   30%
       30~60秒    8%
       60~120秒  26%
       120~360秒 24%
          360秒以上   1%

    <SELECT文発行プログラム例>
      CDatabase db;
      db.Open(lpszDSN, FALSE, FALSE, _T("ODBC;PWD=****"), FALSE);
      CRecordset rs( &db );
      rs.Open(CRecordset::snapshot, lpszSQL, CRecordset::readOnly);…①
     (以下、省略)
     ※①行を呼び出して戻るまでの処理時間を計測。

    <SELECT文 例>
     SELECT No, DataTimeStop, msecStop
        FROM ( SELECT * FROM Table1 WHERE Key = 1 AND DataTime <= #2018-02-14 14:28:10# AND DataTimeStop >= #2018-02-12 14:28:10# ORDER BY DataTime ASC ,msec ASC )
        UNION SELECT No, DataTimeStop, msecStop
          FROM ( SELECT * FROM Table2 WHERE Key = 1 AND DataTime <= #2018-02-14 14:28:10# AND DataTimeStop >= #2018-02-12 14:28:10# ORDER BY DataTime ASC ,msec ASC )

    <MDBの情報>
      Access 2010 or 2013
     MDB ファイルサイズ     :1GB
     SELECT文の対象テーブル数:2
     テーブルのレコード数    :Table-A 56, Table-B 137600
     1レコードのサイズ      :400B
     ※上記以外に複数のテーブルがあるためMDBファイルサイズは大きい。
     ※MDBの最適化は運用前に一度だけ実施。

    <動作環境>
     OS 名  Microsoft Windows 7 Professional 
     バージョン 6.1.7601 Service Pack 1 ビルド 7601 
     システムの種類 X86-ベース PC 
     プロセッサ Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz、3700 Mhz、2 個のコア、4 個のロジカル プロセッサ 
     ロケール 日本 
     物理メモリ (RAM) 4.00 GB 
     利用可能な物理メモリ 2.22 GB 
     仮想メモリ  7.16 GB 
     利用可能な仮想メモリ 5.86 GB 

    ■気になる現象
     SELECT文の実行時間が極端に遅くなたとき(1分以上)、アプリケーションの使用メモリが一気に増加(500KB~1MB)する現象が何度かありました。
     推測で申し訳ないのですが、Accessが使用中のメモリを拡張するためにSELECT文の実行を待たせたということはないのでしょうか。
     それにしても、分単位で掛かるのが解せないですが。(メモリ使用量は、Windowsリソースモニタのプライベートメモリをロギングしています)

    2018年2月15日 4:48

すべての返信