SQL Server ロック エスカレーションに関する MSDN ページから SQL Server ロック エスカレーションを読んでいます。
私の質問は、ロックのエスカレーションがある主な理由は、より多くのロックを維持するためにオーバーヘッドを削減することです (たとえば、テーブルに対してより多くの行ロックが取得されると、行レベルのロックがテーブルレベルにエスカレートされます)。私の質問は、より多くのロックを維持すると同時実行性が向上するということです。これは利点ですが、なぜオーバーヘッドになるのでしょうか? 私の謙虚な考えでは、ロックは、並行性を改善することによってデータベースのパフォーマンスを向上させるのに十分なほど小さくする必要があります。ロックエスカレーションが必要な理由と、いわゆるロックオーバーヘッドとは何かを簡単に説明できる人はいますか?
前もって感謝します、ジョージ
ロックのエスカレーションが必要な理由と、いわゆるロックオーバーヘッドとは何かを簡単に説明できますか？
テーブルを更新して行をロックするときは、この事実を何らかの方法で記録する必要があります。これは行であり、更新されてロックされています。
百万行を更新する場合、これを百万回行う必要があるため、百万のロックを保持するためのスペースがあります。
SQL Serverはロックのリストをメモリに保持しますが、Oracleはテーブルスペースに保持します。
これはおそらく、Oracleが古く（私より古い）、SQLServerがOracleに比べて若いためです。
一時的なリソース（ロックなど）を永続的なストレージに保持することは、設計者の観点からはそれほど明白な解決策ではありません。言及するのは1つだけです。を実行するには、ディスクへの書き込みが必要になる場合がありますSELECT FOR UPDATE。
オラクルのコア機能は、物事をメモリに保持することがまったく選択肢になかった80年代初頭に開発されました。彼らはどういうわけかディスクスペースを使わなければなりませんでした。
とにかくディスクスペースを使用する場合は、ディスクのどこかにロックを設定する必要がありました。
そして、行自体の中にない場合、どこで行のロックを維持するのですか？
SQL Serverのロックシステムの開発者は、Sybaseと呼ばれるRDBMSの設計を考案したときに、一時的なもの（つまり、ロック）を一時的なストレージ（つまりRAM）に格納することにしました。
ただし、Oracleの設計は常にバランスが取れています。データベースに1,000,000行ある場合は、1,000,000ロック用のストレージスペースがあり、10億行ある場合は、10億ロックを保存できます。
この意味で、SQL Serverの設計には欠陥があります。これは、RAMとHDDのスペースが不均衡である可能性があるためです。16MのRAMと数テラバイトのディスクスペースを簡単に使用できます。そして、あなたの記憶はすべてのロックを保持することはできません。
そのため、ロックカウントが特定の制限に達すると、SQL Serverはロックをエスカレーションすることを決定します。たとえば、データページの10行（10レコードが必要）のロックを保持する代わりに、データページ全体（必要な1レコード）。
一方、Oracleは、行を更新するときに、ロックをデータページに直接書き込むだけです。
これが、Oracleのロックが行レベルである理由です。
Oracleは、常識的な意味でロックを「管理」しません。たとえば、Oracleでロックされたページのリストを取得することはできません。
トランザクションが行を更新する必要がある場合、トランザクションはその行に移動し、ロックされているかどうかを確認します。
そうである場合、どのトランザクションがロックを保持しているかを調べ（この情報はデータページのロック記述子に含まれています）、そのトランザクションの通知キューに追加されます。ロックしているトランザクションが終了すると、元のトランザクションに通知が届き、データがロックされます。
同時実行性の観点からは、ロックのエスカレーションは完全に貧弱な人の解決策です。それは同時実行性に何も追加しません。たとえば、触れていない行をロックすることができます。
もちろん、パフォーマンスの観点からは、メモリ内で実行する方が、ディスク上で実行するよりも高速です。
ただし、Oracleはデータブロックをキャッシュし、上記の実際の操作はとにかくメモリ内で実行されるため、パフォーマンスは同じかそれに近いものになります。
SQL Server オプティマイザーが、クエリが特定の範囲内のすべての行を「訪問」すると推定/決定した場合、多くのロックをネゴシエートするよりも、その範囲で単一のロックを保持する方が効率的です (ロックはテストする必要があります)。タイプ）。これは、消費するロック リソース (システム全体のリソース) が少なくなることに加えてです。
適切に設計されたスキーマとクエリ ワークロードに適したインデックスがあり、それらが定期的に維持されている場合は、発生しているエスカレーションについて心配する必要はありません。多くの場合、ブロッキング テーブル ロックは、適切なカバー インデックスによって排除できます。
更新: クエリのカバリング インデックスは、クラスター化されたものへのルックアップを実行する必要がないことを意味し、これにより、テーブルへの挿入がブロックされる可能性が減少します。
「効率的」の定義は複雑です。多くのプロセスが衝突なしで実行できる場合は、並行性を最適化する方が効率的な場合があります。単一のプロセスをより高速に実行するには、一時的な同時実行ヒットを取得する方が効率的な場合があります。エスカレーションされたロックは他のプロセスを締め出し、このプロセスがその仕事を終わらせて邪魔にならないようにします。
ロックのオーバーヘッドは、1 つのテーブル ロックを管理する方が、多数の行ロックを管理するよりもパフォーマンスが優れていることを意味します。各ロックはいくらかのメモリを消費するため、多くの行ロックは 1 つのテーブル ロックよりも多くのメモリを消費する可能性があります。そのため、ロックのエスカレーションは、行 -> ページ -> テーブル ロックから行われます。
ロックの維持方法に関する具体的な情報については、Microsoft SQL Server 2005: The Storage Engine の第 8 章を参照してください (私は関係者ではありません。これは私が最初に見つけた内部情報です)。books24x7 アカウントをお持ちの場合は、そこにあります。16 GB を超えるメモリ マシンでは、ロック ハッシュ テーブルに 2^25 (33554432) スロットがあり、上限は 2^31 スロットです。
特定のアプリケーションでは、きめの細かいロックのみを使用することで、合計スループットが向上する可能性があります。おそらくご想像のとおり、すべては、ロック管理のオーバーヘッドと過剰なロックの可能性を比較する方法に依存します。