すべてのクエリで（nolock）ヒントを使用しないことを正当化する
クエリヒントを使用しないことを正当化する必要がありましたか？
非常にビジーなサーバーにヒットするすべてのクエリにWITH (NOLOCK)が表示されます。開発者は、何千回もコードでそれを見るのを嫌うので、デフォルトでオンにすべきであると考えるのは、まさしくそれです。
私はそれがダーティリードを許可しており、最終的には悪いデータで終わるだろうと説明しようとしましたが、彼らはパフォーマンスのトレードオフはそれだけの価値があると信じています。 （これらのデータベースは混乱しています。パフォーマンスの問題があるのも不思議ではありません。）
このNOLOCKヒントの乱用に対して訴訟を提起する方法の明確な例があれば、喜ばれます。
あなたはあなたの戦いを選び、このような戦いは簡単に勝つことはできません。私たちは、すべてのDMLがROWLOCKヒントでヒント付けされているシステムを持っています（1行または数千行の変更に関係なく）。実際にパフォーマンスが低下する理由をいくつか示しましたが、システムはすでに機能しているため、変更に対する抵抗があります。ただし、これを今後使用しないように十分に確信していることに注意してください。
NOLOCKはその場所にありますが、それを使用する際の問題点を示すいくつかの優れたリファレンスをお勧めします。
- Microsoft SQL Server開発カスタマーアドバイザリーチームのブログ– NOLOCKヒントを使用すると、以前にコミットされた行が失われる可能性があります
- SQL MagazineのItzik Ben Gan – クラスター化インデックススキャンパートIII
- Sqlpass.orgのItkiz Ben Gan – NOLOCKヒントに注意
これはSOで以前に議論されました：
- https://stackoverflow.com/questions/2141104/using-nolock-hint-in-ef4/2141802#2141802
- https://stackoverflow.com/questions/1682240/what-can-happen-as-a-result-of-using-nolock-on-every-select-in-sql-sever
非常に忙しいと定義します。大量（1秒あたり5万の新しい行、大きな集計など）があり、危険なデータを取得する必要もない
分離レベルを理解することの重要性を同僚に説明する必要があります。例を示します。リトルケンドラの 分離レベルのポスター で見つけた最も素晴らしく簡単な説明。彼らにnolockヒントが必要だと思う理由を尋ねます。 「トランザクション分離レベルの設定...」ステートメントを使用しないのはなぜですか？彼らが修正したい状況を正確に尋ねます。おそらくデッドロックやブロッキングなどがあります。ロックを保持したくないだけの場合は、スナップショット分離レベルを検討できます。
それらを尋ねることによってのみ、あなたは明確な画像を持つことができます。