Som standard använder Oracle radnivå lås.
Dessa lås blockerar endast för skribenter (uppdatera, radera, infoga etc). Det betyder att select kommer att fungera hela tiden när en tabell är tung uppdaterad, radera från, etc.
Låt till exempel vara tabellA(kol1 nummer, kol2 nummer), med dessa data inom sig:
col1 | col2
1 | 10
2 | 20
3 | 30
Om användaren John problem vid time1 :
update tableA set col2=11 where col1=1;
kommer att låsa rad1.
Vid time2 användare Markera utfärda en
update tableA set col2=22 where col1=2;
uppdateringen kommer att fungera, eftersom rad 2 inte är låst.
Nu ser tabellen i databasen:
col1 | col2
1 | 11 --locked by john
2 | 22 --locked by mark
3 | 30
För Mark tabellen är(han ser inte ändringarna oengagerad)
col1 | col2
1 | 10
2 | 22
3 | 30
För John är tabellen:(han ser inte ändringarna oengagerade)
col1 | col2
1 | 11
2 | 20
3 | 30
Om mark försöker vid time3 :
update tableA set col2=12 where col1=1;
hans session kommer att hänga på till time4 när John kommer att utfärda en commit .(Återställning låser också upp raderna, men ändringar kommer att gå förlorade)
tabellen är(i db, vid tidpunkt4):
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
Omedelbart, efter Johns commit, låses rad1 upp och Marks uppdatering kommer att göra jobbet:
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
låt oss markera utfärda en rollbak vid tidpunkt5:
col1 | col2
1 | 11
2 | 20
3 | 30
Insticksfodralet är enklare, eftersom infogade rader är låsta, men inte heller ses av andra användare eftersom de inte är commiterade. När användaren förbinder sig släpper han också låsen, så att andra användare kan se dessa rader, uppdatera dem eller ta bort dem.
REDIGERA :Som Jeffrey Kemp förklarade, när du har PK (det är implementerat i Oracle med ett unikt index), om användarna försöker infoga samma värde (så vi skulle ha en dubblett), kommer låsningen att ske i index . Den andra sessionen kommer att blockeras tills den första sessionen slutar eftersom den försöker skriva på samma ställe. Om den första sessionen commit, kommer den andra att ge Primary Key violated undantag och kommer att misslyckas med att ändra databasen. Om den första sessionen gör en återställning kommer den andra att lyckas (om inget annat problem uppstår).
(OBS:I denna förklaring av användaren John menar jag en session startad av användaren John.)