- PR -

SQL Server 2000におけるタイムアウトエラー

1
投稿者投稿内容
sin
会議室デビュー日: 2006/08/14
投稿数: 14
投稿日時: 2008-07-17 11:52
いつもお世話になっております。

現在、Visual Studio .NET、SQL Server 2000を用いて開発を行っております。

現在、あるテーブルに対してInsert処理を行った際に、以下のexception.Messageが返される場合が有ります。
「タイムアウトに達しました。操作が完了する前にタイムアウト期間が過ぎたか、またはサーバーが応答していません。」

上記メッセージは、SQL Server内で処理に時間がかかり、設定されたCommandTimeOut時間をオーバーした場合に出ると考えています。
処理に時間がかかる場合とは、大量のデータ（一千万件以上）のテーブルに対して
SELECT、DELETE、INSERTなどを行った場合などを想定していました。

現に、1500万件のデータを保持するテーブルに対して、
SELECTやDELETEを行なったところ、処理に30秒を超える時間がかかり、
上記エラーが返されることを確認しました。

しかし、より詳細に原因を追っていくと、
INSERT時に上記エラーが返されていることがわかりました。

しかも、対象テーブルのデータ件数は数千〜数万件程度で、
かつ、エラーが発生するのは同一のテーブルへのINSERTのみでした。

INSERT時は、数千万件のテーブルに対して一件のINSERTを行なっても、時間がほとんどかからない（1秒以下）ことを確認しております。

また、INSERT対象テーブルにテーブルロックはかけておらず、
編集する際のみ、対象のデータ一件のみに行ロックをかけている状態です。

INSERT時に上記エラーが発生する原因として、
何か考えられることはございますでしょうか？

ちなみに、再現性は無く、数ヶ月発生しないことも有ります。
しかし、一度発生すると、数日の間は頻発するという状況です。


そもそも、
「タイムアウトに達しました。操作が完了する前にタイムアウト期間が過ぎたか、またはサーバーが応答していません。」
のメッセージが出る原因というのは、どのような場合がありえるのかも
こちらで調査する上で必要な情報ですので、
それだけでもご存知の方がいらっしゃいましたら
教えていただけますでしょうか。
さかもと
ぬし
会議室デビュー日: 2004/05/14
投稿数: 586
投稿日時: 2008-07-17 16:25
さかもとと申します。

まず、SqlCommand.CommandTimeoutプロパティについては以下を。

http://msdn.microsoft.com/ja-jp/library/system.data.sqlclient.sqlcommand.commandtimeout(VS.80).aspx

現象が発生するのはサーバー側の負荷が高くなっている、ネットワークが混雑している、ようなケースが考えられると思います。特に今回は発生タイミングに一貫性がなく出たり出なかったりするようですので、エラーが起こる時期のサーバーの負荷、トラフィックなどを計測してみると良いかもしれません。（業務上異常に負荷が高まる季節があるなど）


INSERTが失敗するケースですが、プログラム上から実行しても、クエリアナライザで実行しても同じ結果になりますか？また、インデックスなどが多いテーブルだったりしませんか？

明確な回答でなくて申し訳ないです。
_________________
------------------------------------------
拝啓、さかもとと申します♪
sin
会議室デビュー日: 2006/08/14
投稿数: 14
投稿日時: 2008-07-21 04:31
さかもとさま

ご回答ありがとうございます。
返信が遅くなり申し訳ありません。

やはり、環境面から発生時の状況を洗い出して
調査の材料を見つけていくのがスタンダードでしょうか・・・

Insertについては、少し言葉が足らず申し訳ありません。
本現象は納品先の実運用中に発生しているものです。
さらに、弊社開発環境では完全な再現が出来ておりません。

Insert時に発生していると判断できたのは、
ログより、どこの処理の時点で発生しているかが明確になったためであり
弊社環境ではどちらも正常に成功します。
（納品先の実運用環境でも平時の発生率は相当に低い）

インデックスも、対象のテーブルより
多量に設定しているテーブルもあるのにもかかわらず、
それらでは起こらずに
対象のテーブルにInsert時のみに発生します。
さかもと
ぬし
会議室デビュー日: 2004/05/14
投稿数: 586
投稿日時: 2008-07-21 10:02
さかもとです

>>やはり、環境面から発生時の状況を洗い出して
>>調査の材料を見つけていくのがスタンダードでしょうか・・・

そうですね、開発環境での再現性がないとすればやはり本番環境でモニターしてつぶしていくのが一番かと思います。

開発環境で再現しない場合というのは、

１：ある一部のユーザーが想定されていない操作をしている。（開発環境では仕様通りの運用でテストを行うので気付かない）

２：開発環境での負荷が本番環境とは違うので発見しづらい。（開発環境と本番環境が１００％同一ではない）

３：システム以外の要因がある。（インフラの不備、異常）

などが考えられます。こうなるといくら開発環境でテストしても発見できないケースがあるのではないでしょうか？（持ち帰りで原因特定できるのがベストではありますが）


ちなみに、Insertが失敗するテーブル（in本番環境）だけ再作成等は既に試されていますでしょうか？
_________________
------------------------------------------
拝啓、さかもとと申します♪
sin
会議室デビュー日: 2006/08/14
投稿数: 14
投稿日時: 2008-07-22 09:18
ご回答ありがとうございます。

２，３に関しては、こちらでも想定しておりました。
特にお客様側では３を疑っていらっしゃるようで、
実際にサーバーの配置場所を変えてからは起こっていないということでした。
ただ、特定のテーブルのみに偏って現象が発生していることから
ハード面ではないのではないかと考えています。
（インフラによる影響であれば他のテーブルへのINSERT時にも起きそうなものだと
考えていますが、いかがでしょうか）

１については、ある一部のユーザ、もしくは複数のユーザ同時利用による
想定されていない動き、というのが一番可能性が高いのではないかと考えています。
明示的にテーブルロックは行なっていませんが、
SQL Server操作時に内部で何らかのロックがかかっているなど、
同時接続による影響（２の負荷にも関わりますが）が
原因ではないかと考えています。

テーブルの再作成は、本件に直接関係してでは有りませんが、
行なっております。
システム導入後、本件が発生（当時は頻度が相当低かった）した後に
改造をし、納品時にＤＢごと新規に作成などを行なっています。

1

スキルアップ／キャリアアップ（JOB@IT）