SQL Serverは通常、Oracleとは異なるロック方法を使用します。 SQL Serverで使用されるデフォルトの戦略では、行を選択すると、それらに読み取りロック（行、ページ、またはテーブル全体）が設定されます*。したがって、NOLOCKは有用な句になることがあります。ただし、分離レベルのセマンティクスを変更し、クエリの出力に一貫性のない結果を引き起こす可能性があるため、これを使用しないことをお勧めします。
*（注：これがデフォルトです。SNAPSHOT分離が選択されている場合、動作は異なり、リーダーはライターをブロックしません。）
Oracleでは、読み取りプロセスが書き込みプロセスをブロックすることはありません。以下は、「Oracle Database Concepts 11g Release 2」からの抜粋です。これがOracleでどのように処理されるかに興味がある場合は、ぜひご覧になることをお勧めします。
ロック動作の概要
データベースは、ロックを取得した操作に応じて、いくつかの異なるタイプのロックを維持します。一般に、データベースは2種類のロックを使用します。排他ロックと共有ロックです。行やテーブルなどのリソースで取得できる排他ロックは1つだけですが、単一のリソースで多くの共有ロックを取得できます。
ロックは、リーダーとライターの相互作用に影響します。リーダーはリソースのクエリですが、ライターはリソースを変更するステートメントです。次のルールは、リーダーとライターに対するOracle Databaseのロック動作を要約しています。
•ライターが変更した場合にのみ、行がロックされます。
ステートメントが1つの行を更新すると、トランザクションはこの行のみのロックを取得します。データベースは、行レベルでテーブルデータをロックすることにより、同じデータの競合を最小限に抑えます。通常の状況1では、データベースは行ロックをブロックまたはテーブルレベルにエスカレートしません。
•行のライターは、同じ行の同時ライターをブロックします。
1つのトランザクションが行を変更している場合、行ロックは、別のトランザクションが同じ行を同時に変更することを防ぎます。
•リーダーがライターをブロックすることはありません。
行の読み取り側は行をロックしないため、書き込み側はこの行を変更できます。唯一の例外はSELECT ... FOR UPDATEステートメントです。これは、読み取っている行をロックする特別なタイプのSELECTステートメントです。
•ライターがリーダーをブロックすることはありません。
行がライターによって変更されている場合、データベースは取り消しデータを使用して、行の一貫したビューをリーダーに提供します。