Snapshot isolation

Snapshot isolation je posebna vrsta kontrole konkurentnosti koja je naila na veliko

prihvatanje u komercijalnim i open-source sistemima kao to su Oracle, PostgreSQL i SQL
Server.
Snapshot isolation ukljuuje dostavljanje snapshota ili snimka baze podataka transakciji i to
za vrijeme kada poinje njeno izvrenje. Transakcija zatim vri operacije na osnovu tog
snapshota u potpunoj izolaciji od konkurentnih transakcija. Ova izolacija je idealna za readonly transakcije jer one nikada ne moraju da ekaju i nikada nee niti prekinute od strane
menadera. Transakcije auriranja baze podataka moraju da budu u interakciji s potencijalnim
konfliktnim konkurentnim transakcijama auriranja prije nego to se izvre auriranja u bazi
podataka. Auriranja se uvaju u radnom prostoru transakcija sve do trenutka kad se
transakcija uspjeno izvri nakon ega se auriranja upisuju u bazu podataka.
Koraci validacije za auriranje transkacija
Treba rei da mogu postojati dvije konkuretne transakcije tako da obje auriraju iste stavke
podataka. Budui da ove dvije transakcije rade u izolaciji koristei vlastite privatne snimke,
deava se da jedna transakcija ne vidi auriranje od strane druge transakcije. Tako se
auriranja mogu ponititi i izgubiti. To se mora sprijeiti.
Postoje dvije varijante snapshot isolation-a, oba postavljenja u cilju spreavanja gubitka
auriranja. To su:

first committer wins

first updater wins

Oba pristupa se temelje na testiranju transakcija protiv konkurentskih transakcija. Transkacija

A je konkurentna sa transakcijom T ako je akitvno ili djelimino poinjena u bilo kojem
trenutku od poetka T, ukljuujui i vrijeme kada se ovaj test izvodi.
First committer wins Kada je transakcija T djelimino ucinjena, mogu se izvriti sljedee
akcije:
o A test je napravljen da se vidi ima li ijedna transkacija, konkuretna sa T, ve upisana
auriranja baze podataka za neke stavke podataka koji T namjerava upisati
o ako se pronae takva transkacija, onda se T prekida
o ako se ne pronae takva transkacija, onda se T izvrsava i upisuje se azuriranje baze
podataka

Pristup se naziva first committer wins, jer kad se izvri testiranje, prva transakcija koja bude
slijedila pravila, upisuje se za auriranje baze, dok sve naknade transakcije bivaju prekinute.
First updater wins Sistem koristi mehanizme za zakljuavanje koji se primjenjuju samo za
auriranje. Kada transakcija Ti pokusava auirirati stavku podataka, ona trazu blokadu pisanja
za tu stavku podataka. Ako zakljuavanje nije odrano od konkuretnih transkcija, onda se
poduzimaju sljedei koraci nakon sto je klju steen:
o ako je stavka bila aurirana konkrentnom transkacijom, onda se Ti prekida
o inae, Ti moe nastaviti proces, ukljuujui i ono sto je eventualno poinila
Kljuevi se oslobaaju, nakon to se transakcija izvri ili prekine.
Pristup se naziva first updater wins zato to ako doe do sukoba transkacija, prvi koji dobavi
klju, doputeno mu je da poini auriranje. Sve transkacije koje kasnije pokuaju izvriti
auriranje prekidaju se, osim ako first updater ne izvri prekid iz nekih drugih razloga.
Serializability Issues
Snapshot isolation je atraktivna u praksi, jer su opi trokovi niski i nema prekida osim ako
dvije konkuretne transakcije auriraju iste podatkovne stavke. Meutim, postoji ipak jedan
problem sa Snapshot isolation. Naime, ova shema ne obezbjeuje serijalizibilnost. Ovo vrijedi
ak i za Oracle. Postoje mnogi primjeti koji pokazuju kako se nositi sa ovim problemom, te
izvriti uspjenu implementaciju.
Od tri sistema koja koriste snapshot isolation, SQl srever ipak nudi mogunost izbora nivoa
serijalizibilnosti, ime se uistinu prua serijalizibilnost i bolja izvedba snapshot izolacije.
Insert Operations and Delete Operations
Do sada smo ograniili nau panju na itanje i pisanje operacija. Ovo ogranienje limitira
transkacije za podakovne stavke koje se nalaze ve u bazi. Neke transkacije zahtjevaju ne
samo pristup postojeim stavkama podataka, ve mogunost za stvaranje novih stavki
podataka. Druge zahtjevaju vjetinu brisanja podataka. Kako bismo ispitali kako takve
transakcije utiu na kontrolu konkurencije, uvodimo dodatne operacije. Te dodatne operacije
su:

delete (brisanje) - (Q) brie podatke Q iz baze podataka

insert (umetanje) - ubacuje novi podatak Q u bazu podataka, i zadaje Q incijalnu
vrijednost

Weak Levels of Consistency in Practice

Konzistencija drugog stepena (Degree-Two Consistency)
Svrha konzizstencije drugog stepena je da se izbjegnu kaskadni prekidi bez nuno osigurane
serijalizibilnosti. Protokol zakljuavanja za konziztenciju drugog stepena koristi ista dva tipa
zakljuavanja kao kod dvofaznog protokola zakljuavanja: zajedniki (S) i ekslukizvni (X).
Transakcija mora odrati odgovarajui nain zakljuavanja kada pristupa podacima, ali
dvofazno ponaanje nije potrebno. Za razliku od dvofaznog zakljuavanja, S-klju moe biti
osloboen bilo kada, te se moe ponovo stei. Ovim protkolom nije osigurana
serijalizibilnost. Transkacija moe proitati dva puta iste podatke i dobiti razliite vrijednosti.
To je prikazano na sljedeoj slici:

Cursor Stability
To je oblik konzistencije drugog stepena koji umjesto da zakljua cijelu relaciju, osigurava
sljedee:

n-torka koja se trenutno obrauje u iteraciji je zakljuana u zajednikom nainu rada

sve izmjenjene n-torke su zakljuane u ekluzivnom nainu rada sve dok se transkacija
izvrava

Ova pravila obezbjeuju da konzistencija drugog stepena bude u upotrebi. Dvofazno

zakljuavanje nije neophodno, te serijalizibilnost nije garantovana. Cursor Stability se koristi
u praksi na relacijama kako bi se osigurala kontrola konkurencije i poboljale performanse.
Aplikacije koje koriste Cursor Stability moraju biti kodirane na nain da obezbjeuju

konzistenciju baze podataka bez obzira na neserijalizibilnost. Stoga, koritenje ovog naina je
ogranieno na specijalne situacije sa jednostavnim ogranienjima konzistencije.
Kontrola konkurencije preko interakcije korisnika
Protokoli za kontrolu konkurencije obino se odnose na transakcije koje ne ukljuuju
interakciju korisnika. Kao primjer emo uzeti rezervaciju sjedita u zrakoplovu. Naime,
putem web-stranice korisnici mogu online rezervirati avio kartu i pri tome odabrati redni broj
sjedita u zrakoplovu. Postavlja se pitanje: ta ako vie korisnika istovremeno odabere isto
sjedite. Vidimo da ovaj primjer ukljuuje interakciju korisnika.
Ako za rjeavanje problema primjenimo dvofazno zakljuavanje, cijeli set sjedita e biti
zakljuan u zajednikom nainu rada, sve dok korisnik ne bude izvrio odabir sjedita i ni
jedna druga transakcija ne bude u mogunosti aurirati informacije o sjeditu u tom periodu.
Jasno je da zakljuavanje nije dobar izbor, jer korisnik dugo moe ekati da odabere neko
sjedite, ili jednostavno odustati od transakcije bez izriitog otkazivanja.
Timestamp protokoli i validacija se mogu koristiti da se izbjegne ovaj problem, ali oba ova
rjeenja e zaustaviti transakciju korisnika A, ako je ijedan drugi korisnik B aurirao
informacije o sjeditu, ak i pod uslovom da izabrano sjedite od strane korisnika B nije u
sukobu sa sjeditem koje je odabrao korisnik A.
Snapshot isolation se ovdje ini kao dobro rjeenje, jer to ne bi prekinulo transkaciju korisnika
A dok B ne izabere isto sjedite kao korisnik A. Meutim, ovaj pristup zahtjeva od baze
podataka da zapamti podatke o auriranjima koje obavlja transakcija, i nakon to je zavrena,
sve dok su ostale konkurente transakcije jo uvijek aktivne. to je problematino za dugo
trajanje transakcija.
Druga mogunost je podijeliti transakciju koja ukljuuje korisniku interakciju u dvije ili vie
transakcije, tako da ni jedna ne ukljuuje interkaciju sa korisnikom. U naem primjeru bi
jedna transakcija itala dostupna sjedita, a druga e vriti dodjelu odabranih sjedita.
Ideja je generalizovati alternativnu shemu konkurencije, koja koristi verzije brojeva
pohranjene u n-torkama kako bi se izbjegao gubitak auriranja. Shema svake relacije je
promijenjena dodavanjem dodatne verzije broja atributa, koji je incijaliziran na 0 kad je ntorka stvorena.