-1

デフォルト構成の SQL Server 2005 では、read_committed 分離レベルと read_committed スナップショットがオフになっています。デッドロックが原因でクエリが中止される可能性はありますか? もしそうなら、なぜですか？

分離レベルを反復可能読み取りに上げるとどうなりますか?

msdn のドキュメントによると、どのレベルの分離でも、このような状況が発生する可能性があります。

Transaction T_1 acquires a share lock on row 1.
Transaction T_2 acquires a share lock on row 2.
Transaction T_1 now requests an exclusive lock on row 2 ( because it wants to change it), and is blocked until transaction T_2 finishes and releases the share lock it has on row 2.
Transaction T_2 now requests an exclusive lock on row 1 ( because it wants to change it), and is blocked until transaction T_1 finishes and releases the share lock it has on row 1.
4

2 に答える 2

1

SQL Server はいくつかのタイプのロックを使用します。データを書き込む必要がある場合 (新しいデータの挿入や既存の行の更新など)、排他ロックを使用する必要があります。常に、どの分離レベルでも。

排他ロックが有効になっているという事実により、常にデッドロックの可能性があります。プロセス A はリソース A の排他ロックを保持しており、リソース B への排他アクセスが必要ですが、別のプロセス B はリソース B の排他ロックを保持しており、アクセスを要求しています。リソース A に。

これは、どの分離レベルでも発生する可能性があります( READ UNCOMMITTEDSQL Server は、データを書き込むために排他ロックを取得します!)。私が言いたいのは、分離レベルの制限が厳しいほど、これらのロックが長く残る傾向があるため、可能性が高くなるということです。デッドロックが発生する可能性があります。

まだ読んでいない場合は、SQL Server のロック メカニズムを十分に理解するまで、次の記事を必ず読んで、もう一度読んで、もう一度読んでください。

于 2012-11-11T19:44:12.863 に答える
0

ロックの一般的な理解については、ドキュメントを読むことをお勧めします。

ロックを取得しない唯一のタイプのステートメントは、コミットされていない読み取り (ダーティ) です。
そのため、read uncommitted を多用しています。

コミットされた読み取りは排他ロックを取得しませんが、排他ロックを防ぎます。
デッドロックを引き起こす可能性はありますか?
理論的には、更新はコミットされた読み取りロックがクリアされるのを常に待つことができるため、そうではありません。
実際には、クエリが非常に遅い場合、待機中の排他ロックがタイムアウトする可能性がありますが、技術的にはデッド ロックではない可能性があります。

そのため、デッドロックが原因でクエリが中止される可能性がありますが、クエリが直接デッドロックを引き起こす可能性はないと思います。

デッドロックする可能性のある更新がある場合、多数の読み取りロックが存在すると、更新のデッドロックの可能性が高くなります。非常にアクティブなテーブルを考えてみましょう。更新 A がページで読み取りロックがクリアされるのを待っている間に、更新 B が同じページで実行されます。アップデート A とアップデート B のデッドロック。更新 A が読み取りロックがクリアされるのを待っていなかった場合、それは出入りしていたでしょう。

于 2012-11-11T20:24:14.120 に答える