Oracle gebruikt standaard rijniveau sloten.
Deze vergrendelingen blokkeren alleen voor schrijvers (bijwerken, verwijderen, invoegen enz.). Dat betekent dat select altijd werkt wanneer een tabel zwaar wordt bijgewerkt, verwijderd uit, enz.
Laat bijvoorbeeld tableA(col1 number, col2 number) zijn, met deze gegevens erin:
col1 | col2
1 | 10
2 | 20
3 | 30
Als gebruiker John problemen heeft op time1 :
update tableA set col2=11 where col1=1;
zal rij1 vergrendelen.
Om time2 gebruiker Markeer een
update tableA set col2=22 where col1=2;
de update werkt, omdat rij 2 niet is vergrendeld.
Nu ziet de tabel er in de database uit:
col1 | col2
1 | 11 --locked by john
2 | 22 --locked by mark
3 | 30
Voor Markeer tabel is(hij ziet de wijzigingen niet ongecommitteerd)
col1 | col2
1 | 10
2 | 22
3 | 30
Voor John is de tabel:(hij ziet de wijzigingen niet ongecommitteerd)
col1 | col2
1 | 11
2 | 20
3 | 30
Als Mark het probeert op time3 :
update tableA set col2=12 where col1=1;
zijn sessie blijft hangen tot time4 wanneer John een commit zal uitgeven .(Terugdraaien ontgrendelt ook de rijen, maar wijzigingen gaan verloren)
tabel is(in db, op tijd4):
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
Onmiddellijk, na John's commit, wordt rij1 ontgrendeld en de update van Marks zal het werk doen:
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
laten we een rollbak op tijd5 markeren:
col1 | col2
1 | 11
2 | 20
3 | 30
Het invoegen is eenvoudiger, omdat ingevoegde rijen zijn vergrendeld, maar ook niet worden gezien door andere gebruikers omdat ze niet zijn vastgelegd. Wanneer de gebruiker zich commit, geeft hij ook de vergrendelingen vrij, zodat andere gebruikers deze rijen kunnen bekijken, bijwerken of verwijderen.
BEWERKEN :Zoals Jeffrey Kemp heeft uitgelegd, als je PK hebt (het is geïmplementeerd in Oracle met een unieke index), als de gebruikers dezelfde waarde proberen in te voegen (dus we zouden een duplicaat hebben), zal de vergrendeling in de index . De tweede sessie wordt geblokkeerd totdat de eerste sessie eindigt omdat deze op dezelfde plaats probeert te schrijven. Als de eerste sessie zich commit, zal de tweede de primaire sleutel geschonden uitzondering genereren en de database niet wijzigen. Als de eerste sessie een rollback uitvoert, zal de tweede slagen (als er geen ander probleem optreedt).
(NB:In deze uitleg door gebruiker John bedoel ik een sessie gestart door gebruiker John.)