По подразбиране 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;
ще заключи ред1.
В 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
Ако mark се опита в time3
:
update tableA set col2=12 where col1=1;
неговата сесия ще продължи до time4
когато Джон ще издаде commit
.(Връщането също ще отключи редовете, но промените ще бъдат загубени)
таблицата е (в db, във време 4):
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
Веднага, след ангажимента на John, ред1 се отключва и актуализацията на marks ще свърши работата:
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
нека отбележим издаване на rollbak в time5:
col1 | col2
1 | 11
2 | 20
3 | 30
Случаят на вмъкване е по-прост, тъй като вмъкнатите редове са заключени, но също така не се виждат от други потребители, защото не са ангажирани. Когато потребителят се ангажира, той освобождава и ключалките, така че други потребители могат да преглеждат тези редове, да ги актуализират или изтриват.
РЕДАКТИРАНЕ :Както Джефри Кемп обясни, когато имате PK (имплементиран е в Oracle с уникален индекс), ако потребителите се опитат да вмъкнат същата стойност (така че ще имаме дубликат), заключването ще се случи в индекс . Втората сесия ще бъде блокирана до края на първата, защото се опитва да пише на същото място. Ако първата сесия се ангажира, втората ще хвърли изключение за нарушение на първичния ключ и няма да успее да промени базата данни. Ако първата сесия извърши връщане назад, втората ще успее (ако не се появи друг проблем).
(Забележка:В това обяснение от потребител John имам предвид сесия, стартирана от потребител John.)