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