デフォルトでは、Oracleは行レベルを使用します ロック。
これらのロックは、ライター（更新、削除、挿入など）に対してのみブロックされます。つまり、テーブルが大幅に更新されたり、削除されたりした場合でも、selectは常に機能します。
たとえば、次のデータを含むtableA（col1 number、col2 number）とします。
col1 | col2
1 | 10
2 | 20
3 | 30
ユーザーJohnがtime1で発行した場合 ：
update tableA set col2=11 where col1=1;
row1をロックします。
time2で ユーザーマークが
update tableA set col2=22 where col1=2;
行2がロックされていないため、更新は機能します。
これで、テーブルがデータベースに表示されます。
col1 | col2
1 | 11 --locked by john
2 | 22 --locked by mark
3 | 30
マークテーブルの場合（コミットされていない変更は表示されません）
col1 | col2
1 | 10
2 | 22
3 | 30
ジョンのテーブルは次のとおりです:(コミットされていない変更は表示されません）
col1 | col2
1 | 11
2 | 20
3 | 30
マークがtime3で試行した場合 ：
update tableA set col2=12 where col1=1;
彼のセッションはtime4までハングします ジョンがcommitを発行する時期 。（ロールバックも行のロックを解除しますが、変更は失われます）
テーブルは（db、time4）：
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
すぐに、ジョンのコミット後、row1のロックが解除され、マークの更新が機能します：
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
time5でロールバックの発行をマークしましょう：
col1 | col2
1 | 11
2 | 20
3 | 30
挿入された行はロックされているため、挿入ケースは単純ですが、コミットされていないため、他のユーザーには表示されません。ユーザーがコミットすると、ロックも解除されるため、他のユーザーはこれらの行を表示、更新、または削除できます。
編集 ：Jeffrey Kempが説明したように、PK（Oracleに一意のインデックスを使用して実装されている）がある場合、ユーザーが同じ値を挿入しようとすると（つまり、重複することになります）、ロックはで発生します。インデックス 。 2番目のセッションは、同じ場所に書き込もうとするため、最初のセッションが終了するまでブロックされます。最初のセッションがコミットすると、2番目のセッションは主キー違反の例外をスローし、データベースの変更に失敗します。最初のセッションがロールバックを実行する場合、2番目のセッションは成功します（他の問題が発生しない場合）。
（注：ユーザーJohnによるこの説明では、ユーザーJohnによって開始されたセッションを意味します。）