10

編集：解決しました。テーブルにループのあるトリガーがありました（以下の私自身の回答を読んでください）。

次のような単純な削除ステートメントがあります。

DELETE FROM tablename WHERE pk = 12345

これはハングアップするだけで、タイムアウトも何もありません。

実行計画を調べたところ、関連するテーブルの多くのルックアップで構成されており、外部キーが削除を失敗させないようにしていますが、他のテーブルにはその特定の行を参照する行がないことを確認しました.

現在、データベースに接続している他のユーザーはいません。

これに対して DBCC CHECKDB を実行したところ、0 個のエラーが報告されました。

の結果sp_whoとsp_lockクエリがハングしている間に、私の spid に多くの PAG および KEY ロックがあり、時折 TAB ロックがあることに気付きました。

テーブルには 1.777.621 行あり、はい、pk は主キーであるため、インデックスに基づく単一行の削除です。実行計画にテーブル スキャンはありませんが、Table Spool (Eager Spool)と書かれたものが含まれていることに気付きましたが、Estimated number of rows 1 と書かれています。主キー列を見ているとだけ言っています。

テーブルで DBCC DBREINDEX と UPDATE STATISTICS を試しました。どちらも妥当な時間内に完了しました。

残念ながら、この特定のテーブルには多数のインデックスがあります。これはシステムの中核となるテーブルであり、多数の列と、送信と受信の両方の参照があります。正確な数は、48 個のインデックス + 主キーのクラスター化インデックスです。

他に何を見るべきですか？

また、このテーブルには以前はこの問題がありませんでしたが、この問題は今日突然発生しました。また、同じテーブル設定 (顧客データベースのコピー) を持つ多くのデータベースがあり、それらは期待どおりに動作します。問題があるのはこの 1 つだけです。

4

3 に答える 3

5

欠落している情報の 1 つは、データを削除するテーブルのインデックスの数です。SQL Server はすべてのインデックスで主キーをポインターとして使用するため、主インデックスを変更すると、すべてのインデックスを更新する必要があります。ただし、高い数値を話している場合を除き、これは問題にはなりません。

あなたの説明から、これはデータベース内のプライマリ テーブルであり、FK 関係の他の多くのテーブルから参照されていると推測しています。これは、参照のために残りのテーブルをチェックするため、多数のロックを説明します。また、カスケード削除を有効にしている場合、これによりテーブル内の削除が発生し、いくつかのテーブルの深さのチェックが必要になる可能性があります。

于 2008-09-11T09:51:37.397 に答える
3

そのテーブルのインデックスを再作成し、統計を再生成してみてください。

DBCC 再インデックス

統計の更新

于 2008-09-11T09:30:05.950 に答える
1

わかりました、これは恥ずかしいです。

同僚がしばらく前にそのテーブルにトリガーを追加しましたが、トリガーにはバグがありました。彼はバグを修正しましたが、そのテーブルに対してトリガーが再作成されることはありませんでした。

つまり、サーバーは実際には何もしていませんでした。それは何回も行っただけです。

しかたがない...

これを読んで問題を熟考してくれたすべての人に目を向けてくれてありがとう。

ジョセフが最も近く、カスケード削除の問題を間接的に突き止めたので、私はジョセフの答えを受け入れるつもりです。

于 2008-09-11T12:38:56.417 に答える