ロックエスカレーション＝悪ではない（ロックエスカレーションの真実） SQL Server

■ ロックエスカレーションとは
行単位のロック（行レベルロック）は、同時実行性は高まりますが、大量の行が更新される場合には、ロック数が膨大になってしまいます。したがって、SQL Server の場合は、行単位やページ単位など、小さい粒度のロックが大量に発生し、SQL Server 自身に負荷が高いと認識したときには、必要に応じてロックの粒度を拡大（エスカレート）します。この機能のことを「ロックエスカレーション」（Lock Escalation）と呼んでいます。
例えば、テーブルデータが 100万件あり、そのうちの 90万件へ行ロックがかかっているとします。このとき、これらのロックをテーブル単位のロックへエスカレートできるのであれば、ロックは１つで済むのです。なお、SQL Server の場合にロックがエスカレートされるかどうかは、同時実行されているトランザクションや、利用できるメモリ量に依存します。

■ ロックエスカレーション＝悪ではない
オラクル社の影響からか、「ロックエスカレーション＝悪」という風潮が世の中にはありますが、ロックエスカレーションは悪ではありません。確かにロックエスカレーションは、同時実行性が低下する可能性があるという悪い面がありますが、前述したような良い面もあるのです。したがって、処理によっては、ロックエスカレーションが起きてくれたほうが性能向上しますし、実際、過去の弊社の案件ではロックエスカレーションを活用して性能向上させたことがあります。
オラクル社は、「他社データベースはロックエスカレーションが悪さをする」と言ってさんざん不安を煽っていますが、逆に「Oracle Database にはロックエスカレーション機能がない」ので、これはマイナス要素です。Oracle Database ではロックエスカレーションによる性能メリットを享受することができないのです。
Oracle Database は、既定では「行レベルロック」なので、大量のデータを処理する場合に、大量の行レベルロックがかかるオーバーヘッドがあります。
これに対し、ロックエスカレーション機能が実装されているデータベース（SQL Server など）では、大量のデータを処理する場合には、自動的にロックをかける粒度を大きくしてくれます。もし、その粒度が大きすぎて同時実行性が落ちるなら、ヒントで粒度を小さく指定すれば良いのです。また、SQL Server でロックエスカレーション機能が不要な場合は、禁止することもできます。

いずれにしても、ロックエスカレーション機能を実装していようがいまいが、性能向上を実現するためには、Oracle であろうと SQL Server であろうと、既定の動作に頼ることは良くないということです。
これは、ロックエスカレーションに限った話しではなく、どんな技術でも同じです。どんな技術にも良い面と悪い面がありますし、他の技術とのトレードオフが発生する場合もあるでしょう。
例えば、トランザクションログ（REDO ログ）は、障害対策のためには重要なものですが、性能面ではオーバーヘッドがあります。性能を向上させたければ、データベースを利用しなければ良いのです（でも障害対策などが必要になる場合は、別の手段が必要になるので、開発コストなどを考慮すると結局データベースを利用するほうが良いという結論になることが多いと思います）。

■ オラクル社に物申す
オラクル社の人たちは、SQL Server はロックエスカレーションが発生してしまう、とよく叩いていることがありますが、それは間違っています。ロックエスカレーションは禁止することができますし、処理によってはロックエスカレーションが発生してくれた方が性能向上するからです。オラクル社の人たちは、不安を煽っているだけの、単なる（Oracke Database を売りたいだけの）セールストークをしているにすぎません（buzzword として使っているだけです）。営業さんによっては SQL Server にロックエスカレーションの禁止オプションがあることを知らないケースもあります（技術力不足）。

いずれにしても、セールストークの場合は、競合製品の技術的な悪い面だけを叩き、自社製品の良い面だけを持ち上げますので、持ち上げられた良い面だけを見るのではなく（セールストークを鵜呑みにするのではなく）、エンジニアとしては悪い面にも目を向けることが重要です。