Pitanja i odgovori – Transakcije

1. Kakav je uticaj nivoa izolacije na konkurentnost?

Termin nivo izolacije se koristi za opis stepena ometanja koji transakcija moze da podnese pri konkurentnom
izvrsavanju. Ako su transakcije serijalizibilne stepen ometanja ne postoji, tj. nivo izolacije je maksimalan.
Realni sistemi zbog razlicitih razloga, npr. zbog performansi, dopustaju rad sa nivoom izolacije koji je manji
od maksimalnog. Sto je veci nivo izolacije manje su dopustene smetnje i obratno.

2. Karakteristike algoritma oporavka

Algoritmi za oporavak ponistavaju efekte transakcija koje su bile aktivne u vreme nastanka greske i
ponavljaju izvrsavanje transakcija koje su uspesno zavrsile svoj rad do tog trenutka, ali nisu stigle da efekat
izvrsavanja zapisu na fizicki disk. Jedan od algoritama je citanje log datoteke i izvrsavanje gorepomenutog
procesa, a drugi je algoritam ARIES, koji ovaj proces vrsi u obrnutom poretku. Prvo ponavlja izvrsavanje
transakcija, a onda ponistava efekte nezavrsenih.

3. Logovi i njihovo koriscenje u bazama

Sistem odrzava log ili zurnal u kome se nalaze informacije neophodne za oporavak. U log se upisuju sve
informacije, sve sto bilo koji korisnik radi sa bilo cime u bazi.
Postoje 2 vrste loga: aktivni i arhivski log. Informacije se upisuju u arhivski log kada se aktivni napuni.
Logovi mogu biti “cirkularni”, uvek ih ima vise, kada se poslednji log napuni, gazimo sadrzaj prvog.
U arhivski log se upisuju informacije kada se poslednji log napuni, kako buduce transakcije ne bi gazile
postojece logove. Sistem alocira odredjen broj primarnih logova odredjene velicine u aktivnom logu.
Arhivski log omogucava oporavak baze. i ROLLBACK se upisuje u log, pa mozemo da se vratimo na stanje
koje je bilo na pocetku transakcije u log datoteci. O velicini loga, nacinu cuvanja i ostalim specifikacijama
brine se administrator baze.
Ako nam je logtimeout = -1 ne proverava se da li je doslo do mrtve petlje ili stanja cekanja. Ako je umesto
-1 neki drugi broj, za toliko sekundi dobijamo informaciju da li smo upali u mrtvu petlju ili stanje cekanja.

4. Optimisticno zakljucavanje
Ne drze se kljucevi nad redovima izmedju dohvatanja, azuriranja ili brisanja redova. Aplikacija optimisticno
pretpostavlja da se nezakljucani redovi nece promeniti pre update ili delete operacije. Koristi se za
povecanje konkurentnosti. Ako je ipak doslo do promena, ponavlja se ceo postupak. Provera – RID_BIT ili
RID funkcija, mozemo da proverimo kada je poslednji put doslo do promene u redu.
RID funkcijaja vraca id reda u razlicitim formatima, a ROW CHANGE TIMESTAMP vraca poslednju
promenu u redu

5. Dvofazni COMMIT i dvofazni protokol zakljucavanja

Neophodan je dvofazni COMMIT u slucaj uda aplikacija radi sa nezavisnim upravljacima resursa (npr. IMS
i DB2) i u slucaju distribuiranih baza (jedna baza na vise racunara). Obezbedjuje korektno izvrsavanje u
slucaju pojave greske na bilo kojoj komponenti.
Teorema Dvofazni protokol zakljucavanja: Ako sve transakcije primenjuju dvofazni protokol zakljucavanja,
tada su svi moguci rasporedi transakcija serijalizabilni.
Nacin rada:
1. Faza zahteva katanca. Pre rada sa bilo kojim objektom, transkacija mora da zahteva katance nad tim
objektom
2. Faza ukidanja katanca. Po oslobodjenju katanca, transakcija vise ne sme da zahteva bilo koji katanac.

6. Cursor stability nivo izolacije sa Currently Commited

CS (Cursor stability) je predefinisan nivo izolacije. Zakljucava bilo koji red koji se cita tokom transakcije
dok je kursor pozicioniran na taj red. Zakljucavanje se zadrzava sve dok se sledeci red ne dohvati ili se
transakcija ne zavrsi. Ako su bilo koji podaci u redu promenjeni, zakljucavanje se zadrzava dok se promena
ne potvrdi. Veca mogucnost konkurentnog rada.
CC (Currently Commited) je predefinisan za nove baze od verzije 9.7. Vracaju se samo trenutno potvrdjeni
podaci, a ako nisu trenutno potvrdjeni, onda se citaju prethodna stanja log bafera (radna memorija loga).
Transakcija koja cita podatke ne mora da ceka da promene budu potvrdjenje i da se katanci oslobode.
7. Eskalacija kljuceva
Ako memorija za cuvanje kljuceva dostize LOCKLIST (kolicina memorije koja se koristi za upravljanje
kljucevima) ili iskoriscenost te memorije od strane aplikacije prekoraci MAXLOCKS (maksimalan procenat
memorije koju jedna konekcija moze da iskoristi iz LOCKLIST memorije), treba uraditi eskalaciju. Moramo
da cuvamo informacije o tome koji slog ima koji kljuc. Kljucevi koji su prisutni u velikom broju podizu se
na nivo tabele. Tako oslobadjamo memoriju koja je koriscena za kljuceve na nizem nivou, a koji nam nisu
vise potrebni. Kada se desi eskalacija, aplikacija ide u stanje eskalacije dok se eskalacija ne izvrsi ili se
transakcija ne zavrsi. Mozda neki slogovi nisu pod kljucem, ali ih drzi druga aplikacija, pa tad ne moze da se
uradi eskalacija.

8. ACID osobine
1. Atomicnost – Transakcije su atomske, ili se izvrse u celosti ili se uopste ne izvrse.
2. Konzistentnost – Transakcije prevode jedno konzistentno stanje baze u drugo konzistentno stanje.
3. Izolovanost – Efekti izvrsenja jedne transakcije su nepoznati drugoj do njenog uspesnog zavrsetka.
4. Trajnost – Po potvrdjivanju transakcije, promene ostaju u bazi cak i u slucaju pada sistema.

Ako su ove osobine striktne, konkurentnost nije velika, pa se zato tezi oslabljivanju zahteva.

9. Konkurentnost
Termin konkurentnost oznacava cinjenicu da SUBP dopusta vecem broju transakcija pristup do istih
podataka istovremeno.
Prednosti: maksimalna propusnost, krace vreme odziva.
Mane: problem izgubljenih azuriranja, problem zavisnosti od nepotvrdjenih podataka, problem
nekonzistentne analize.

10. Transakcije – opsti pojmovi

Transakcija je logicka jedinica posla koja moze da sadrzi niz operacija. Upravljac transakcijama vrsi
upravljanje transakcijama u racunarskom sistemu. Transakciju pocinjemo naredbom begin transaction.
Naredba COMMIT je signalizacija uspesnog zavrsavanja, dok naredbama UNDO/ROLLBACK
signaliziramo da se transakcija nije uspesno zavrsila. ROLLBACK ponistava sve efekte i promene nacinjene
neuspesnom transakcijom.

11. Opisati efekat na nivou sloga / tabele svakog od nivoa izolacije kursora u DB2
1. RR (Repeatable Read) – najvisi nivo izolovanosti aplikacije i njenih transakcija. Zakljucava sve
redove na koje se aplikacija refereise prilikom rada, a ne samo one redove koji zadovoljavaju uslove
upita. Proces na RR nivou izolovanosti dobija bar deljive katance nad svim podacima kojima
pristupa, proces je u ptpunosti izolovan od strane drugih procesa. Rezultat izvrsenja jednog upita
transakcije T se ne moze promeniti od strane druge pre nego sto se transakcija T ne zavrsi.
Transakcija nema uvid u nepotvrdjene promene drugih transakcija. Nijedan podataka koji drzi
transakcija se ne moze menjati od strane drugih transakcija sve do zavrsetka obrade od strane te
transakcije, pa nista ne moze da utice na rezultatat.
2. RS (Read Stability) – ovaj nivo izolovanosti zakljucava samo one redove koji zadovoljavaju uslov
upita. Ne dopusta promenu od strane drugih transakcija, podataka koje cita transakcija, sve dok se
ona ne zavrsi. Ne izoluju transakciju u potpunosti, pa prilikom ponovljenih izvrsavanja istog upita od
strane transakcije mogu da se razlikuju rezultati, jer moze doci do dodavanja vrsta koje ce zadovoljiti
taj upit (fantomski redovi).
3. CS (Cursor Stability) - predefinisan nivo izolacije. Zakljucava bilo koji red koji se cita tokom
transakcije dok je kursor pozicioniran na taj red. Zakljucavanje se zadrzava sve dok se sledeci red ne
dohvati ili se transakcija ne zavrsi. Ako su bilo koji podaci u redu promenjeni, zakljucavanje se
zadrzava dok se promena ne potvrdi. Veca mogucnost konkurentnog rada.
 4. UR (Uncommited Read) – najnizi nivo izolacije. Dozvoljava se citanje nepotvrdjenih podataka kao i
promena reda koji se cita od strane drugih transakcija. Za ostale operacije vaze pravila CS nivoa.

12. Opisati vrste kljuceva koji mogu da se postave nad tabelama u sistemu DB2
1. IS (Intent Share) – T namerava da postavi deljivi katanac nad pojedinacnim torkama relvara R, radi
garantovanja stabilnosti tih torki koje namerava da obradjuje
2. IX (Intent Exclusive) – isto kao IS ,samo sto T sada moze da azurira pojedinacne torke i tada
postavlja privatni katanac na njih
3. S (Share) – T tolerise konkurentno citanje, ali ne i konkurentno azuriranje. T nema nameru da azurira
bilo koju torku iz R.
4. SIX (Shared Intent Exclusive) – kombinacjia S i IX, tj T moze da tolerise konkurentno citanje i
namerava da azurira pojedinacne torke u R u kom slucaju ce postaviti IX katance na te torke
5. X (Exclusive) – T ne moze da tolerise bilo kakav pristup do R. Samo T moze, ali ne mora da azurira
torke u R.
6. U (Update) – T moze da cita i da menja podatke ako moze da dobije katanac nad R. Ostale
transakcije mogu da citaju, ali ne i da azuriraju.
7. Z (Superexclusive) – Najjaci nacin zakljucavanja, niko ne moze da pristupi R. Koristi se kod
masivnog punjenja tabela, alter i drop naredbi, kao i kod utility programa koji rade na niskom nivou,
npr. kod REORG.
8. IN (Intent None) – T moze da cita podatke cak i nepotvrdjene, ali ne moze da azurira nista u R.
Ostale transakcije mogu i da citaju i da azuriraju R.

IS, IX, SIX – Na nivou tabele da bi bilo podrzano zakljucavanje redova.

S, U, X, Z – Na nivou tabele sa striktin zakljucavanjem, ne koristi se zakljucavanje redova.
IN – koristi se da dozvoli UR nivo izolacije
Nad prostorima za cuvanje tabela mogu da se postave: IN, IX, IS i Z

13. Razlika izmedju postojanja mrtve petlje i stanja cekanja, kako se te situacije
otkrivaju i prevazilaze?
Mrtva petlja (deadlock) je situacija kada 2 ili vise transakcija imaju postavljen katanac nad resursom koji je
potreban onoj drugoj, tako da nijedna ne moze da nastavi sa radom. Otkriva se grafom cekanja (ukoliko
postoji nekakav “krug”, tada postoji mrtva petlja). Razresava se tako sto se izabere zrtva (ne nuzno jedna,
moze biti vise transakcija koje se prekidaju) ciji se efekti poniste i tako se oslobode resursi. Koja se bira za
zrtvu zavisi od toga sta od resursa drzi, koliko dugo radi, itd…
SQLCODE = -911 – transakcija je prekinuta zbog mrtve petlje
SQLCODE = -913 ili SQLCODE = -918 – prekinuta zbog cekanja, kod zavisi od toga koji objekat je u
pitanju.
Stanje cekanja – ako aplikacija koja drzi kljuc ne uradi COMMIT ili ROLLBACK, druge aplikacije cekaju
dok se timeout ne prekoraci (SET CURRENT LOCK TIMEOUT – mozemo promeniti predefinisane
vrednosti), ili ako je zahtev za postavljanjem katanca od strane jedne transakcije odbijen jer je u konfliktu sa
vec postavljenim katancem od strane druge transakcije. Tada transakcija ide u stanje cekanja dok druga
transakcija ne oslobodi kljuc (sistem mora da garantuje da nece zauvek ostati u stanju cekanja).

Zadaci

1. Neka transakcije izvrsavaju sledece operacije:

T1: dodaje 1 na A
T2: duplira vrednost A
T3: Prikazuje A na ekran I posle toga postavlja A na 1, gde je A numericka vrednost
a) Ako se T1, T2, T3 izvrsavaju konkurentno I pocetna vrednost A je jednaka 0, navesti sve
moguce korektne rezultate koji mogu da se dobiju, kao I redosled izvrsavanja transakcija
koji te rezultate proizvodi

Resenje:

T1 T2 T3 A = 0, A = 1, A = 2, A = 1
T1 T3 T2 A = 0, A = 1, A = 1, A = 2
T2 T1 T3 A = 0, A = 0, A = 1, A = 1
T2 T3 T1 A = 0, A = 0, A = 1, A = 2
T3 T2 T1 A = 0, A = 1, A = 2, A = 3
T3 T1 T2 A = 0, A = 1, A = 2, A = 4

b) Neka je interna struktura transakcija T1, T2, T3 predstavljena narednim pseudokodom.

Ako se transakcije izvrsavaju bez ikakvog zakljucavanja, koliko ima razlicith rasporeda
izvrsavanja?

T1 T2 T3
R1: FETCH A INTO a1; R2: FETCH A INTO a2; R3: FETCH A INTO a3;
A1 := a1 + 1; a2 := a2 * 2; Prikazi a3;
U1: UPDATE A FROM a1; U2: UPDATE A FROM a2; U3: UPDATE A FROM 1

Resenje:

Ra Rb Rc Ux Uy Uz = 3 * 2 * 1 * 3 * 2 * 1 = 36
Ra Rb Ux Rc Uy Uz = 3 * 2 * 2 * 1 * 2 * 1 = 24
Ra Rb Ux Uy Rc Uz = 3 * 2 * 2 * 1 * 1 * 1 = 12
Ra Ua Rb Ub Rc Uc = 3 * 1 * 2 * 1 * 1 * 1 = 6 ← korektno
Ra Ua Rb Rc Uy Uz = 3 * 1 * 2 * 1 * 2 * 1 = 12
––––––––––––––––––––––––––––––––––––––––
Ukupno: 96

c) A= 0. Da li postoji neki isprepletani redosled izvrsavanja transakcija cija je struktura

prikazana u b) (ako postoji navesti ga) koji proizvodi korektan rezultat a da nije
serijalizabilan?

Resenje:

R1 R2 R3 U2 U1 U3

R1 R2 R3 ← S katanac
U2 U1 U3 ← promocija u X, ali ne moze

d) Da li postoji neki isprepletani redosled izvrsavanja transakcija cija je struktura prikazana

u b) (ako postoji navesti ga) koji je u sustini serijalizibilan, ali ne moze da se javi ako sve 3
transakcije primenjuju dvofazni protokol zakljucavanja?

Resenje:
R1 R2 R3 U1 U2 U3