Arhiviranjem dnevnika se sustav dodatno štiti od pogreške medija – dnenik važan za obnovu u slucaju pogreske,

Omogucava se ponovno iskorištavanje oslobođenog prostora

Periodička izrada arhiva dnevnika – Neprekidno arhiviranje stabilne online memorije u offline, po mogućnosti
udaljenu stabilnu memoriju

Inkrementalno arhiviranje: Periodičko arhiviranje cijele ili dijela baze podataka naizmjenice. Rijeđe se arhivira cijela, a
češće manji djelovi baze podataka
Arhiva razine 0 – full backup – arhiviranje svih blokova podataka – DUGOTRAJNO
Arhiva razine 1 . samo oni blokovi koji su promijenjeni nakon razine 0
Arhiva razine 2 – samo ovi blokovi koji su promijenjeni nakon razine 1
Preporuča se ćuvati barem 3 posljedne arhive dnevnika

8. Kontrola istodobnog pristupa

Korektna transakcija – Transakcija koja bazu podataka prevodi iz jednog u drugo konzistentno stanje
Serijalizabilna transakcije – transakcije čiji je rezultat izvršavanja jednak serijskom izvršavanju

Nekonzistenta analiza – ako transakcija T1 čita nekoliko elemenata, neke elemente pročita prije, a neke nakon što ih
je promijenila transakcija T2

Izgubljena izmjena - ako transakcija T1 na temelju pročitane vrijednosti elementa x promijeni vrijednost elementa x,
pri tome ne uzevši u obzir izmjenu elementa x koju je u međuvremenu obavila transakcija T2

Prljavo čitanje - ako transakcija T1pročita element nakon što ga je promijenila transakcija T2, a prije nego je
T2potvrđena

Model transakcije – modelom transakcije je određen redosljed operacija unutar jedne transakcije

Povijest – opisujevremenski određen redoslijed obavljanja operacija jedne ili više transakcija

Svojstva povijesti:
1. Povijest sadrži točno one operacije koje su sadržane u transkacijama
2. Poredak kojeg transakcije imaju unutar Ti mora biti zadržan u H
3. Poredak je određen za SVE konfliktne operacije neovisno kojoj transakciji pripadaju

Konfliktne operacije su operacije čija bi zamjena redoslijeda izvršavanja mogla utjecati na konačni rezultat r-w, w-w
Dvije operacije su konfliktne ako dijeluju NA ISTI ELEMENT baze podataka i barem jedna je operacija pisanja

Serijska povijest – Povijest je serijska ako za svake dvije transakcije Ti i Tj iz povijesti vrijedni da sve operacije iz Ti
prethode svim operacijama iz Tj i obrnuto (jedna transakcija počinje nakon potvrđivanja druge)
Dvije serijske povijesti ne moraju dati isti rezultat izvršavanja (zbog mogucih konflikata)

Serijalizabilna povijest – Povijest je serijalizabilna (SR) ako je ekvivalentna nekoj serijskoj povijesti H=Hs

Ekvivalent povijesti – Povijest H1 je ekvivalentna povijesti H2 ako i samo ako je rezultat izvršavanja H1 jednak H2

Konflikt-ekvivalentna povijest – Stroži uvijet od serijalizabilne – Dvije povijesti su konflikt-evivalentne H1 =c H2 ako

sadrže isti skup operacija i svaki par konfliktnih operacija je poredan na jednak način u obe povijesti
- Rezultat obavljanja ovakve dvije povijesti je sigurno jednak jer redosljed svakog konflikta čiji bi redosljed mogao
utjecati je jednak u obe povijesti

Konflikt-serijalizabilna povijest – Povijest je konflikt-serijalizabilna (CSR) ako je serijalizabilna (CSR) ako je H konflikt-
ekvivalentna nekoj serijskoj povijesti HS
Serijalizacijski graf (SG) za povijest H, označen sa SG(H), je usmjereni graf čiji su čvorovi transakcije iz H, a lúkovi su
(Ti, Tj), i != j, ako postoji operacija pi iz Ti koja prethodi operaciji qj iz Tj i pri tome su pi i qj konfliktne operacije.

ako je povijest H konflikt-ekvivalentna, tada se za H pomoću SG(H) lako može odrediti konflikt-ekvivalentna serijska
povijest. budući da je serijalizacijski graf acikličan za konflikt ekvivalentne povijesti, za SG(H) je moguće odrediti
topološki poredak. Svaki topološki poredak elemenata SG(H) implicira po jednu konflikt ekvivalentnu serijsku povijest
za H

Povijesti H iH' su pogled-ekvivalentne (view-equivalent), H =v H', ako vrijedi da tTransakcije čitaju iste vrijednosti te
konačno i zapisuju iste vrijednosti.

moguće je dokazati da je svaka CSR povijest ujedno i VSR povijest, dok svaka VSR povijest nije ujedno i CSR povijest
Obnovljiva povijest RC - povijest H je obnovljiva (recoverable ili RC) ako za svaku potvrđenu transakciju Ti
koja čita iz Tj, vrijedi da je cj < ci. Tj. Transakcija smije biti potvrđena tek nakon što su potvrđene sve
transakcije iz kojih je čitala
ACA povijest - povijest H izbjegava kaskadno poništavanje(avoids cascading aborts ili ACA) ako za svaku
transakciju Ti koja operacijom ri[x] čita iz Tj, vrijedi da je cj < ri[x].
•drugim riječima, transakcija smije čitati samo one vrijednosti koje je zapisala već potvrđena transakcija
Striktna povijest (ST) - povijest H je striktna (strict ili ST) ako za svake dvije transakcije Ti i Tj vrijedi da ako
je wj[x] < oi[x], tada ili aj < oi[x] ili cj < oi[x]
drugim riječima, niti jedan element se ne smije niti pročitati niti izmijeniti dok sve transakcije koje su
prije toga pisale u taj element ne terminiraju (obave abortili commit)

svaka ST povijest jest ujedno i ACA povijest

svaka ACA povijest jest ujedno i RC povijest
9. Kontrola istodobnog pristupa
Osiguravanje serijalizabilno izvršavanja
Protokoli temeljeni na zaključavanju - zaključavanje je uobičajen način rješavanja problema sinkroniziranja
pristupa dijeljenim podacima. Prija obavljanja operacije LM ispituje je li x zaključan pa čeka ili postavlja ključ

2PL protokol - dvofazniprotokolzaključavanja (two-phaselockingprotocol): Temeljni, Striktni, Rigorozni

svaka povijest H koja je nastala obavljanjem operacija u skladu s 2PL protokolom je konflikt-
serijalizabilna

2PL protokol je "stroži" nego je nužno za osiguravanje konflikt-serijalizabilnosti: r1x,w2x,r1y,w2y,c1,c2 –

iako ta povijest je csr T1->T2 – 2PL protokol ce je izmjeniti
Menadzer transakcija koji ne primjenjuje 2PL bi dopustio neserijalizabilne povijest

2PL1 propisuje da transakcija Ti prije obavljanja operacije mora zatražiti (i dobiti) ključ odgovarajuće vrste,
te da ga nakon operacije mora otpustiti (ne nužno odmah)
2PL2 propisuje da element može biti zaključan ili jednim X-ključem ili jednim ili više S-ključeva
2PL3 propisuje da transakcija Ti mora zaključati sve potrebne elemente prije nego otključa bilo koji
element, odnosno transakcija koja je otpustila ključ (bilo koje vrste) ne može nakon toga postavljati nove
ključeve (bilo koje vrste) – Faza rasta, faza sažimanja ključeva

STRIKTNI 2PL protokol

X ključevi se smiju otpustiti tek poslije toče potvrđivanja, a S ključevi i ranije! – mogući zastoj

RIGOROZNI 2PL protokol

SVI kljućevi se otpuštaju tek nakon potvrđivanja transakcije
Izgladnjavanje transakcije – ako menadžer zaključavanja ne provodi first come- first serve pravilo tada
transakcija može biti stalno odgađana u korist drugi transakcija
Potpuni zastoj – Kad jedna čeka oslobađanje ključa elementa kojeg drži druga transakcija, a ta druga
također čeka oslobađanje ključa za drugi element i nijedna ne može nastaviti s radom
- Spriječavanje: 2PL se dopunjava zabranom čekanja, propisivanjem redosljeda zaključavanja, vremenske
oznake, konzervativni 2PL protokol
- Detecija: Praćenje vremena čekanja , korištenje grafa čekanja WFG

Zabrana čekanja – SET LOCK MODE TO NOT WAIT – ako dođe do čekanja aborta se
Konzervativni 2PL protokol – transakcija na početku postavlja SVE ključeve koje će koristiti. Ako ne uspije
postaviti sve onda ne zadržava nijedan i aborta se
Propisivanje redosljeda zaključavanja – Utvrđuje se poredak među elementima. Ako Ti zaključa xi tada ne
može xj za kojeg vrijedi xj < xi

Metoda vremenskih oznaka – Transition timestamp (starija-mlađa)

- sustav svakoj transakciji dodijeljuje vremensku oznaku TS(Ti) u trenutku kad se POČNE izvršavati
Metoda wait-die
Ako je Ti starija ( TS(Ti) < TS(Tj) ), Ti čeka ; Ako je Ti mlađa ona se prekida
- starija čeka da mlađa otpusti ključeve, mlađoj nije dopušteno čekanje
Metoda wound-wait
Ako je Ti starija ona prekida mlađu te se mlađa poništava i PONOVNO pokreće sa svojom
STAROM vremenskom oznakom Tj. Ako je mlađa onda čeka
Timeout-base metoda
Ako Ti čeka na postavljanje ključa duže od LOCK_TIMEOUT parametra tada se pretpostavlja
da je uključena u potpuni zastoj te se prekida i poništava

GRAF ČEKANJA, wait-for-graph WFG

WFG je usmjereni graf, WFG = (N, E), u kojem čvorovi N predstavljaju transakcije, a lúkovi E predstavljaju
ovisnosti među transakcijama: lûk Ti -> Tj znači da transakcija Ti čeka zbog ključa kojeg je postavila
transakcija Tj
U sustavu postoji potpuni zastoj ako i samo ako u WFG postoji petlja

ključ za izmjenu,U-ključ, update-lock – Ako Ti čita element, a kasnije pisati u njega stavlja U ključ
- U ključ se može promovirati u X ključ
- U ključ se može postaviti na element zaključan S ključevima drugih transakcija!
- Ako je element zaključan U ključem druge transakcije ne mogu postaviti U ili X ključ, mogu S ključ
- S ključ se ne smije promovirati u U ili X ključ – ako namjerava pisati treba odma postaviti U umjesto S
10. Predavanje – Kontrola pristupa 3/3 – granulacija
Zaključavanje može biti na razini: n-torke, fizičke stranice, relacije i baze podataka
Warning lock – kljuc upozorenja
Intention lock – kljuc namjere
Intention exlusive lock – IX
- Jedna ili više relacija nižih razina ima eXclusive kljuc postavljen
Kad se postavlja X kljuc na neku N-torku prvo se treba provjeriti i postaviti IX na roditelja
Intention shared lock – IS
Na nižim razinama postoje elementi zaključani S ključem
Shared and intention-exlusive lock SIX
- Kombinacija S i iX kljuca
- Na korijen se postavlja S ključ, a na neka podstabla će biti ili već je postavljen X kljuc

MGL – Multiple granularity locking protocol – warning protocol

MGL1 – Ti može zaključati x ako je traženi ključ kompatibilan sa vec postojecim kljucevima drugih
transakcija
MGL2 – Zakljucavanje pocinje od korjena -> Baze podataka pa nadolje
MGL3 – Ti element x može zaključati sa S ili iS samo ako je roditelja zakljucala sa IS ili IX
MGL4 – Ti element x može zaključati sa X,IX ili SIX, jedino ako je roditelja sa IX ili SIX
MGL5 – Ti može zaključati element x jedino ako prije tog nije otključaka nijedan drugi elem. 2PL3
MGL6 – Ti može otkljucati element x jedino ako nijedan potomak nije zakljucan (Otkljucava se od niže
prema visim)

Operacija brisanja Del[x] – prije nje element zaključati X ključem

Operacija Unosa ins[x] – Upravo upisani element zaključati X ključem
Sablasna N-torka
- N torka koja ne postoji u trenutku kad neka transakcija postavlja ključeve na N-torke koje zadovoljavaju
predikat, a neka druga transakcija unese/izmjeni tu N-torku prije nego je prva transakcija završila tj dok je
još trajala
- Rješenje zaključavanje čitave relacije (jer ne mozemo skup Ntorki) – ali to smanjuje konkurentnost
- Pravo rješenje korištenje INDEXA

Indeks-Locking protocol – Protokol zaključavanja indexa

- sprječava sablasne Ntorke; PRIMJENJIV SAMO AKO POSTOJI ODGOVARAJUĆ INDEX
Transakcija koja čita skup N-torki zaključava S ključem te zapise u B-stablu (ne cijeli list)
Transakcija koja unosi ili briše Ntorke treba postaviti X ključ na zapise u B stablu u kojem će se nalaziti nova
Ntorka

AKO TRANSAKCIJA RADI SAMO UPDATE – DOVOLJNO JE S-ključ na index jer ne mijenja kardinalnost
skupa!

PRLJAVO ČITANJE
Transakcija T1 obavi čitanje x prije nego je T2 koja je pisala bila završena(commit/abort)
Povijest koja nije ST niti ACA niti RC – zbog prljavog čitanja

NEPONOVLJIVO ČITANJE
T1 pročita element X, T2 primijeni X. Ako t1 ponovno čita pročitat će drugačiju vrijednost
Zbog nekonzistente analize i izgubljene izmjene

SABLASNE N-TORKE
Transakcija T1 pročita elemente na temelju predikata P, a zatim T2 unese, izmjeni ili obriše elemente koji
zadovoljavaju taj predikat P prije nego što je T1 završila
SQL RAZINE IZOLACIJE:

Read uncommited – Operacija Rx ne postavlja S kljuc na X niti provjerava je li zaključana X-kljucem

Read commited – Rx postavlja kratkotrajni S-kljuc samo u trenutku obavljanja operacije te ga otpušta
Repeatable read – Rx postavlja uobivajeni dugotrajni S-kljuc u skladu sa 2PL protokolom, ali ne koristi
protokol zaključavanja indeksa niti relacije ako nema indexa (sablasne Ntroke)
Serializable – provodi se striktni 2pl protokol i zaključavanje indexa ili čitave relacije

READ UNCOMMITTED - ne postavlja S i IS ključeve, postavlja X ključeve.

READ COMMITTED - postavlja kratkotrajne S i IS ključeve, postavlja X ključeve.
REPEATABLE READ - postavlja S ključeve kao SERIALIZABLE - osim S ključa na indeks; postavlja X ključeve.
PRIMJER U KODU:
START TRANSACTION;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Multiverzijski protokoli MV
- Svako potvrđeno pisanje stvara novu verziju X-a
- Dvije vrste: Multiversion timestamp ordering i Multiversion two-phase ordering
- U nekim sustavima koriste snapshot izolaciju – transakcija uzme svoju kopiju baze u tom trenutku –
na taj način spriječene ANSI anomalie (prljavo čitanje, neponovljivo čitanje, sablasne ntorke) -> NE
GARANTIRANI serijabilnost baš svake povijesti jer postoji anomalija Write Skew
Protokol vremenskih oznaka – Timestamp-ordering protocol
- U distribuiranim sustavima – osigurava serijazibilnu povijest
- Koristi se vremenska oznaka početka transakcije TS(Ti)
- Manji TS znači da je transakcija starija – ranije počela
- WTS(x) – najveća vrijednost vremenske oznake transakcije koja je obavila W[x]
- RTS(x) – najveća vrijednost vremenske oznake transakcije koja je obavila R[x]
SNAPSHOT ISOLATION
- Transakcija T vidi samo one podatke koji su bili POTVRĐENI u trenutku kad je ZAPOČELA i samo svoje
pormjene.
PRAVILA PROTOKOLA VREMENSKIH OZNAKA:
11. Distribuirane baze podataka
Homogeni sustav – svi čvorovi koriste jednake modele podataka, upitne jezike, OS …
Heterogeni sustav – različiti OS, različiti modeli, različiti protokoli …
Shema fragmentacija – podjela baze u disjunkti skup fragmenata – Moze biti Vertikalno i horizontalno
Shema alokacije – shema koja opisuje koji fragment je pridružen kojem čvoru
Fragmentacija je korektna ako ima svojstva: obnovljivosti i disjunktnosti

Obnovljivost: ako se R dekomponira onda mora postojati funkcija koja će rekonstruirati

Disjunktnost:
Horizontalno fragmentiranje – vrijedi da presjeka nema
Vertikalno fragmentiranje – u presjeku je samo primarni ključ
STUPANJ REPLIKACIJE FRAGMENATA – br čvorova u kojima je fragment alociran
Particionirana ili nereplicirana baza – svaki fragment u samo jednom čvoru – stupanj =1
Potpuno replicirana – Svaki fragment alociran u svim čvorovima – Stupanj = n
Parcijalno replicirana - svaki fragment u jednom,više ili svim čvorovima

Transparentnost fragmentacije – korisnici ne trebaju voditi računa kako je relacija fragmentirana

Transparentnost lokacije – ne trbaju znati kojem je cvoru alociran koji fragment
Transparentnost replikacije – ne trebaju voditi računa o postojanju kopija/replika
TRANSAKCIJE U DISTRIBUIRANIM SUSTAVIMA – očuvanje ACID-a

TM – manadzer transakcija – zadaće: obnova, izolacija … - obavlja i subtransakcije

TC – koordinator transakcija

Atomarnost globalne transakcije znači da TM-ovi u svim čvorovima u kojima se izvršavaju pripadne
subtransakcije moraju donijeti i provesti jednaku odluku o ishodu obavljanja transakcije: ili su
svesubtransakcije globalne transakcije potvrđene, ili su sveponištene

2PC – two phase commit

TC distribuira transakcije TM-ovima i tek nakoj obavljanja svih subtransakcija započinje 2PC
1. Faza – TC pita TM-ove „jesi li spreman potvrditi subtransakciju“
2. Faza – Ako su SVI spremni tada TC svim TM-voima šalje nalog POTVRDI subtransakciju
2PC je blokirajući protokol jer neki TM neće moći zavrsiti transakciju (poslao TC-u poruku spreman i čeka
odgovor) sve dok od TC-a ne dobije poruku golobalnoPotvrdi ili globalnoPoništi – slučaj kad je TC u
kvaru. Zbog tog TM treba čekati dok se TC ne obnovi i dok se ne uspostavi veza

Protokol je NEZAVISAN S OBZIROM NA MOGUĆNOST OBNOVE ako svaki čvor TC ili TM nakon što se
njemu dogodio kvar može samostalno, bez komuniklacije s ostalim čvorovima donijeti odluku o
poništavanju ili ponovnom obavljanju svih subtransakcija koje su se odvijale u trenutku kvara
 2PC nije nezavisan s obzirom na mogućnost obnove (P4)
Ako je TM u dnevniku zapisao spreman i prema TC poslao tu poruku – ako se tada TM pokvari on
ne moze odluciti treba li potvrditi ili poništiti bez TC-a
12 Distribuirane baze podataka

globalna serijalizabilnost u particioniranimbazama podataka postiže se kombiniranom uporabom

rigoroznog 2PL protokola i 2PC protokola

ako se koristi striktni 2PL protokol (S-ključeve smijese otpustiti i prije kraja subtransakcije), sustav bi
mogao producirati povijest koja nije serijalizabilna:
ako se koristi rigorozni 2PL protokol (sviključevi se otpuštaju tek po završetku 2PC), sustav će osigurati
serijalizabilnost globalne transakcije:

Replicirane BP
fragment je repliciran ako je alociran u dva ili više čvorova
za jedan logički element x (n-torku, fragment, relaciju) postoji više fizičkih elemenata (kopija, replika), x1,
x2, ..., u čvorovima S1, S2, ...
Nedostaci repliciranih BP - problem konzistentnosti kopija logičkog elementa

Izolacija u repliciranim bazama podataka

Zaključavanje uz pomoć primarne kopije (Primary-copy locking)
- Za svaki element postoji samo jedna primarna kopija Xp na primarnoj lokaciji p
Kad transakcija treba zaključati X ona treba tražiti ključ na primarnoj lokaciji – time implicitno
dobiva ključ nad svim replikama
Većinski protokol (Majority Protocol)
Moraju se zaključati kopije elementa X u više od polovice čvorva u kojima je x alociran

Pristrani protokol (Biased Protocol)

Sličan većinskom protokolu
- Za obavljanje S operacije dovoljno je postaviti S ključ nad samo jednom kopijom
- Za obavljanje X operacije treba postaviti ključ nad SVIM kopijama ReadOne-WriteAll
Protokol usuglašavanja kvorumom (Quorum Consensus Protocol)
Svaki čvor dobiva težinski faktor wi te se izračunava njihova suma
Za svaki element X odabiru se dvije vrijednosti: read-quorum Qr i write-quorum Qw