http://blogs.wankuma.com/sakamoto/archive/2007/09/14/96238.aspx
SQL Server 2005ではロック周りに手が入ったからか動きが怪しいという話があるようですね。
実際怪しい動作に出会えるほど大量データをSQL Server 2005で扱ってはいないのでなんともいえないのですが、そんな噂に絡みそうなのが、SQL Server 2005でロックというとREAD_COMMITTED_SNAPSHOTでしょうか。
これ、いわゆるOracleでいうところの読み取り一貫性で、更新中排他がかかっていてもロックがかからずにデータが読み取れる（もちろん、更新前のね）やつですね。
問題があるとしたら次の２点でしょうか。
- SQL Server利用者が読み取り一貫性になれていないためにアプリ側ロジックで問題が発生する
- tempdbをより多く使うので、tempdb領域が少ないとその辺りで問題が発生する
- tempdbへの格納は行単位なので正規化していないようなちゃんとしていないテーブル構造だと更にtempdbが消費される
うーん、怪しいのは設定ノウハウ（Oracle構築する時には常に検討する事をSQL Server構築時も検討しないといけなくなった）使い方のような気もしますね。
とすれば、やはり本命はロックエスカレーションでしょうか。
ロックエスカレーションは、SQL Serverでもデフォルトになった行ロックを行っていたら、なんだかメモリが足りなくなってきたときに行ロックでなくテーブルロックに移行する機能です。
どのようなときに発生するかといえば、デフォルトのしきい値でロック管理情報がメモリの40%以上を使う始めるか、または5000行以上を一括更新しようとすると発生します。これ、前者は良いですが後者の5000行以上という条件がすぐに効いてしまいそうですね。
行ロック前提でアプリが組まれていて、気が付いたらロックエスカレーションしていて大変な事に！とかいう状況だったらロック周りが怪しいといわれてしまうかもしれないですね。よくRDBMSの特性を理解して使っていく事が重要だと思います。
# ロックエスカレーションなんて自動機能は必要ないのにーなどと思ってしまいます。