none
SQLServer Express Edition 2005にてあるレコード数以上になると検索・更新処理が遅延することがある。 RRS feed

  • 質問

  • 皆様

    ひらひらと申します。

    当方、SQLServer Express Edition 2005(SP2)を使っており、表記の件について皆様のお知恵をお借りしたく。

    【状況】

    ①テーブルには、6002件程度(すべて、数値、文字でバイナリ列はなし)が格納されています。

    ②ADOを経由して、insert , select , updateが実施されます。

     その際、where句で主キーを選択しています。(全件検索ではない)

    ③ある環境下で、6002件からinsertなどを100セット繰り返すと、特定の回数では無いですが

     15ms程度で通常レスが帰ってくる(ADO経由でSQLを発行→結果受信まで)が

     異常が発生すると200msなどのずれで大きく乖離が発生する。

    という現象が起きます。

    疑ったのはtempDBの自動拡張などですが、ErrorLogを確認する分には

    特に目立った動きは無いように見えます。

    ちなみにデータベースのファイルとして、物理ファイルサイズは53MB程度で、件数も少ないので

    特別大きい(むしろ小さい)サイズではないです。

    どのような観点からアプローチすれば良いか?お知恵をお借り出来ませんでしょうか?

    以上、よろしくお願いします。

    【追加です】

    yottun8さん

    ありがとうございます。

    その後の調査結果踏まえて報告します。

    まず、このテーブルはクラスタインデックス、非クラスタインデックスの2つで構成されています。

    このインデックスの断片化がそれぞれ、20.96%、59.01%発生しています。

    インデックスの再構築や、テーブルのエキスポート、インポートすることで、上記断片化が解決されるため

    レスポンスダウンは解決できそうです。

    問題は、断片化をいつ、どういうタイミングで判断して皆様は再構築などを実施されているのでしょうか?

    マニュアルなどを見ると30%を超える程度の場合は、インデックスの再構築または再構成が必要との記載があるようです。

    また、自動で実施する手段は、皆様はスクリプトなどで仕込んで実施していると思って良いでしょうか?

    以上、よろしくお願いします。


    2012年7月20日 7:38

すべての返信

  • まずは、テーブル構造や実行しているクエリの例などを示してみてはどうでしょう?
    回答が付き易くなると思います。

    あと 2 について、「where句で主キーを選択」と「全件検索ではない」は
    クエリの書き方によってはイコールにはならない場合もあります。
    実行しているクエリについて、ちゃんとインデックスが使われているかどうか
    実行プランを確認してみるといいかもしれません。

    2012年7月20日 9:48