●SQL Server のロックエスカレーション機能
ＤＢシステム側での資源節約機能
ロックエスカレーション機能の解説では、「PassJ」の次のものが一番わかりやすかったです。《PassJ》「第４回 SQL Server 転ばぬ先の杖！」【引用】
Oracleは行単位のロックが確保されています。どれだけロックが増えても行単位でロックが確保される分、ロックが多いときにはリソースを消費します。SQL Serverも基本は行ロックですが、システムのリソースが少なくなると、複数の行ロックを1つのテーブルロックに切り替えることで、メモリを開放しようとします。これは、「ロックエスカレーション機能」と呼ばれています。
非接続型の ADODB.Recordset
ロックエスカレーション機能の背景を詳細に述べた、次のサイトも参考になりました。「第五章 ロックの真実」
ロックエスカレーションに関する問題回避方法は、私が思いつくものでは次のものがあります。
(1) ロックエスカレーションを発生させるような処理 (大量の一括更新) は、オンライン処理サービス時間帯には行わない。
(2) ロックエスカレーションのしきい値を引き上げる。
(3) インデックスが使用できない検索条件を指定しない。インデックスが付加されているカラムに関するダミーの検索条件を付加する。
(4) カーソルなどを使用して 1 レコードずつ処理を行うようにする。
先日、PassJのメーリングリストで、すぐにでも使えるコードを、Mitsugi OGAWA氏から教えていただきました。ありがとうございました＞OGAWA氏。(1) ロックエスカレーションを発生させるような処理 (大量の一括更新) は、オンライン処理サービス時間帯には行わない。
(2) ロックエスカレーションのしきい値を引き上げる。
(3) インデックスが使用できない検索条件を指定しない。インデックスが付加されているカラムに関するダミーの検索条件を付加する。
(4) カーソルなどを使用して 1 レコードずつ処理を行うようにする。
《PassJ》「【pml-dev 1213】Re: e_fail1状態について」2007/07/22【引用】
ざっと想定できるのはロックエスカレーションですかね。
ADP で直接テーブルを開かないとか、ページング（1 回で取得するデータの絞り込み）の実装とかしないと回避できないと思われます。
クエリを記述するときに NOLOCK 指定とかもありですが。
ADODB の Recordset を取得するときは、非接続型の Recordset を使うことも手です。
VBScript ですが、2001 年に記述したサンプルが見つかりました。
実際の VBScript のコードは、PassJでご覧になって下さい＞皆様。ADP で直接テーブルを開かないとか、ページング（1 回で取得するデータの絞り込み）の実装とかしないと回避できないと思われます。
クエリを記述するときに NOLOCK 指定とかもありですが。
ADODB の Recordset を取得するときは、非接続型の Recordset を使うことも手です。
VBScript ですが、2001 年に記述したサンプルが見つかりました。
