PREDAVANJE 1

DB2 postoji na razlicitim platformama UNIX sistema/INTEL sistem/MAINFRAME.

U zavisnosti od platforme ide i odgovarajuca DB2 verzija. Db2 komponente:
DRDA Administration Client Run-time Client Application Developement Client

Communication Support

DB2
DB2_con
ne
DRDA Application Server

Communication Support mora da bude instaliran na serveru da bi omogucio klijentu remote login. Za nas je vazan
Application Developement Client koji je kolekcija grafickih i negrafickih alata i komponenti za razvoj tekstualno,
multimedijalno i objektno orjentisanih aplikacija.
Run-time-client omogucava funkcionalnost neophodnu da bi aplikacija pristupila DB2 Universal Database serverima i
DB2 Connect serverima. Funkcionalnost ukljucuje podrasku za communications support protokol i podrsku za
aplikacioni interfejs kao sto su JDBC, SQLJ, ODBC, CLI,...
Kako mozemo da pristupimo:
1. Preko komandnog interfejsa
2. Preko razlicitih stavki u SQL-u
3. Preko aplikativnih interfejsa kao sto je ugnjezdeni SQL (C, JAVA)

Moguce je da na istom sistemu postoji vise instanci(primeraka) od kojih svaki moze da ima svoju bazu(database
management environment). To sluzi da na jednom racunaru oni budu razdvojeni, odnosno jedna drugoj nemaju
pristup. Komanda za konekciju na bazu CONNECT TO ime_baze. Postoji protokol da se istovremeno prijavimo na vise
baza (to su oni connect type 1 i 2). Na mainframe-u imamo jednu bazu a sve ostalo ide preko prostora za cuvanje
tabela.
DSL(jezik podataka(data sublanguage))=DDL+DML

DB2 hijerarhija objekata:

-svaka baza moze da ima vise prostora za cuvanje tabela i vise prostora za cuvanje indeksa. Oni se koriste za
upravljanje smestanjem podataka na fizicki disk. Prostori tabela sadrze tabele, a prostori indeksa indekse i
RID.
-Relaciona baza podatke predstavlja kao kolekciju tabela gdje svaka tabela ima definisan broj kolona i
proizvoljan broj redova.
-Svaka tabela ,moze da ima vise indeksa koji pruzaju brzi pristup toj tabeli.
-Svaka tabela moze da ima vise pogleda koji mogu da sadrze vise osnovnih tabela

DDL-data definition language-jezik za definiciju podataka koji se koristi za definisanje ili deklarisanje objakata u
bazi(CREATE, ALTER, DROP)
DHL-data manipulation language-jezik za rad sa podacima koji se koristi pri radu i obradi objekata iz baze(SELECT,
UPDATE ,INSERT,DELETE)
DCL-data control language-REVOKE, GRANT, CONNECT, COMMIT, ROLLBACK
Alternativa u aplikacijama sa kojima mozemo da radimo:
-staticki SQL
-dinamicki SQL
-CALL LEVEL INTERFACE(ODBC)
-JAVA DEVELOPEMENT (JDBC i SQLJ)
-STORED procedure
-korisnicki definisane funkcije

Staticki SQL- sve naredbe su unaprijed poznate u DB2 UDB moze da odredi strategiju pristupa podacima za vreme
razvoja programa i sacuva strategiju za kasnije izvrsavanje
Dinamicki SQL-kada aplikacioni program prosledjuje naredbu DB2 UDB za vreme izvrsavanja. To znaci da DB2
odredjuje strategiju pristupa podacima tokom izvrsavanja programa.

Table/column descriptions
Server code with SQL
Autorizations

Statistic
PREPARE
ACCESS
Dinamicki staticki STRATEGY
EXECUTE

ACESS STRATEGY sadrzi SQL naredbe optimizovane prema statistici baze.

-CALL LEVEL INTERFACE-CLI je API(aplication program interface) za pristup bazi koji koristi nazive funkcija da
„prizove“ dinamicki SQL. To je alternativa ugradjenom dinamickomSQL-u. Razlika je u nacinu pozivanja mehanizma
za SQL. Aplikacija koja koristi ugradjeni SQL zahteva da prekompajler pretvori SQL naredbe u kod, koji se onda
kompajlira, vezuje za bazu i izvrsava. DB2 CLI aplikacija ne zahteva prekompilaciju ili vezivanje vec koristi standardni
set funkcija za izvrsavanje SQL naredbi i povezanih servisa za vreme izvrsavanja (run time).
ODBC-OPEN DATABASE CONNECTIVITY-standard za pristup bazi (razvio MICROSOFT).
-JAVA aplikacije: SQL APPLICATION
SQLJ RUN-TIME CLASSES

JAVA APPLICATION JDBC Remote database

DB2 client

-STORED procedure-omogucava aplikaciji koja radi na strani klijenta da pozove proceduru koja je smestena na server
baze. Ona se izvrsava lokalno i vraca informacije aplikaciji na strani klijenta. Prednosti:
-smanjuje internet saobracaj
-poboljsava performanse servera
-pristupa karakteristikama koje postoje samo na serveru baze
-Korisnicki definisane funkcije- mogu biti napisane za obavljanje operacija u okviru SQL-a koje vracaju jednu skalarnu
vrednost(npr konverzija, racun,..). Mogu da budu napisane na nekom visem programskom jeziku (C, C++,JAVA,...)
CLP-command line proccessor
Kako se izlazi iz komandne linije?
1.QUIT-ne prekida pozadinske procese i ne diskonektuje se sa baze
2.TERMINATE- prekida pozadinske procese i prekida konekciju sa bazom
3.CONNECT RESET-ne prekida pozadinske procese, a prekida konekciju sa bazom ako je CONNECT=1

Prostori tabela
Pre nego sto tabela moze da bude kreirana, mora da postoji baza podataka i prostor podataka. To ce vjerovatno biti
posao DB2 sistemskog administratora ili administratora baze podatakada naprave ove objekte. Sledi redosled
kreiranja: 1.baza
2. prostor tabela
3.tabele
CREATE TABLE naredba na kraju moze d aima IN prostor za cuvanje tabela. To IN stavlja tabelu u prostor za cuvanje
tabela koji se navede. Ako s eizostavi, stavlja se u podrazumjevani sistemski prostor za cuvanje tabela. Tipovi
podataka: CHAR(n), VARCHAR(n), LONG VARCHAR,GRAPHIC(n),VARGRAPHIC(n),LONG VARGRAPHIC, SMALLINT,
INTEGER, DECIMAL(p,s), FLOAT,REAL,DOUBLE),DATE, TIME, TIMESTAMP
Pogledi-rokovnik RBP
Privremene tabele-brisu se cim izadjemo iz programa(sa declare)
Referencijalni integritet
Trigeri
Tip int iz C-a nije dozvoljen jer je njegova interna reprezentacija masinski zavisna.
Ako je karakter od 20 onda je C-ovska promijenljiva char[21]

Kako izgleda struktura programa

U svakom programskom jeziku imamo dodatak koji kaze da se radi o SQL-u da bi prekompajler identifikovao SQL
naredbe i preveo ih.
COBOL EXEC SQL sql-statement END EXEC.
C, C++ EXEC SQL sql-statement;
JAVA #sql { sql-stratement};

Npr: EXEC SQL SELECT * FROM dosije;

Ugnjezdeni SQL se razlikuje kod HOST promijenljivih. One moraaju da budu smijestene na unaprijed predvidjeno
mjesto. Glavnaa karakteristika host promijenljive je da se u SQL naredbama pisu sa: ime_promijenljive
Npr: SQL: SELECT MAX(indeks)
FROM dosije
C:EXEC SQL SELECT MAX(indeks) INTO :indeks
FROM dosije;
Ako ne stavimo : onda to shvata kao atribut tabele i dolazi do greske. Da bi host promijenljiva primila vrijednost
koristimo INTO. On je kod SELECT-a obavezan.U programu kada kazemo SELECT mozemo da smestimo samo jedan
slog, tako da SELECT koristimo samo kada smo sigurni da rezultat nije vise od jednog sloga.
Deklaracija host promijenljivih se navodi izmedju:
EXEC SQL BEGIN DECLARE SECTION;
.
.
EXEC SQL END DECLARE SECTION;
Primeri:
Db2clgn –d ime_baze –t ime_tabele –l jezik
U zavisnosti od jezika(podrazumijevani je C) daje heder fajl u kome se .h nalazi struktura koja opisuje slogove u
tabeli. Podstrukturu sa .java duzinom i podatkom pravi kada imamo VARCHAR.
Atributi koji mogu da imaju vrijednost NULL koriste SHORTINT promijenljivu koja predstavlja indikator.
Npr: SELECT cola INTO :a:a_ind
Ako je NULL indikator je manji od nule.
Ako kod db2clgn stavimo –i moze da generise i indikatore i generise ih kao niz indikatora tipa SHORT . Indikatori
mogu da se koriste i za UPDATE. Stavimo -1u njega i u bazuse unese NULL.
SQLCA –SQL COMMUNICATION AREA.

Uspeh ili greska poslednje izvrsene SQL naredbe je opisan u strukturi SQLCA. SQLCA treba da provjerava posle svake
SQL naredbe. Prva SQL naredba u programu mora da bude EXEC SQL INCLUDE SQLCA, cime se ukljucuje struktura
SQLCA.
SQLCODE- detaljna, moguca zavisnost od platforme, numericka promijenljiva.
SQLSTATE-nije detaljan kao SQLCODE, ali je platformski nezavistan, string promijenljiva.
U SQLCA se upisuju odgovarajuci kodovi. Ako su <0 => greska, ako je +100=> not found, ako je 0=>uspeh, ako je >0 i
<>100=> warning.
WHENEVER naredba:
Koristi se u kodiranju za rukovanje izuzetcima. Sintaksa:
EXEC SQL WHENEVER CONDITION ACTION;
SQLERROR(SQLCODE<0) GO TO :X
SQLWARNING(0<SQLCODE<>100) CONTINUE
NOT FOUND(SQLCODE=+100)
Ako stavimo CONTINUE onda mi moramo da proveravamo greske, jer on „samo tera“.

Npr: EXEC SQL WHENEVER SQLERROR GO TO :test;

.
.
Test:........
/*on ubaci odgovarajuce pitanje iza svakog upita if(SQLCODE<0) go to test;*/

Na labelu moze samo go to. Alternativa WHENEVER komandi je niz if(...) else... pitalica.
Kad se radi sa vise slogova, definise se kursor.
Printf moze i poslije EXEC SQL CONNECT RESET; jer smo mi rezultat sacuvali u host promijenljivima(to je slucaj kad
imamo samo jedan slog kao rezultat).
Kada db2clgn radi on ne brise prethodni sadrzaj ve cdodaje na njega(pokrenuti dva puta istu tabelu).
DBRM-DATABASE REQUEST MODULE

Kad se napise program sa ugradjenim SQL-om prije nego sto se kompajlira odgovarajucim kompajlerom za taj jezik
(npr: gcc), EXEC SQL naredbe moraju da se zamene necim sto ce odgovarati kompajleru, da bi on to mogao da
procesira. Taj proces zamene radi DB2 proces koji se zove PREKOMPAJLER. Za staticke SQL programe. SQL naredbe
ce dodatno obradjene od strane DB2 bind procesa da bi se napravio paket

/*ima jos na slajdovima SQL.programiranje.pdf 125 str*/

/*DRUGO*/
Problem oporavka baze podataka je vracanje baze na korektno stanje posle gresaka koje su bazu dovele u
nekonzistentno stanje. Princip na kome je oporavak zasnovan je postojanje redundantnih podataka na fizickom
nivou.
Moguce greske:
-programske greske, npr: deljenje nulom
-hardverske greske, npr:pad glava na disku
-greske operatera, npr montiranje pogresne trake ili unos pogresnih podataka
-nestanak elektricne energije, pozar, poplava,...
Pomoc pri oporavku predstavlja uzimanje sigurnosnih kopija(backup-a). Osnovni pristup:
1.snimiti stanje baze u regularnim vremenskim intervalima
2.svaka promena se evidentira upisom u log datoteku
3.u slucaju da se desi greska:
-ako je baza ostacena, tekuce stanje se dobija uzimanjem arhivske kopije i primenom promena iz log
datoteke
-ako baza nije ostecena, ali je njen sadrzaj nekorektan, uraditi ponistavanje promena na osnovu sadrzaja log
datoteke

Transakcija je logicka jedinica posla. Moze da sadrzi niz operacija. Sa gledista korisnika izvrsavanje transakcije je
automatsko. Transakcija ostavlja bazu u konzistentnom stanju. Kontrolu nad trans u racunarskom sistemu ima
upravljac transakcijama(na starim sistemima koristen termin TP monitor).
Primer:
BEGIN TRANSACITON;
UPDATE AC 123 {BALANCE:=BALANCE- $100};
IF any error occured THEN GO TO UNDO; END IF;
COMMIT; /*successful transaction*/
GO TO FINISH;
UNDO:
ROLLBACK; /* UNsuccessful transaction */
FINISH;
RETURN;

Osobine transakcija:
1. BEGIN TRANSACTION, COMMIT ROLLBACK mogu biti pozvani i implicitno . Inicijalno svaka transakcija bi
trebalo da pocne sa BEGIN TRANSACTION. COMMIT potvrdjuje da je transakcija uspijesna i promijene su
trajno sacuvane. U DB2 ne postoji begin transaction. Prakticno kad program pocne , pocinje i transakcija.
Automatski cim se sa COMMIT ili ROLLBACK zavrsi transakcija, pocinje nova. COMMIT nije obavezan u DB2.
Navodimo ga ako hocemo eksplicitno da zavrsimo transakciju, tj, ako u programu imamo vise transakcija.
Navodjenjem ROLLBACK-a je obavezno ako zelimo da ponistimo efektte transakcije. To vracanje se radi
preko log datoteke. Tu se vrsi evidencija svega sto radimo sa bazom. Kad radimo ROLLBACK on se vraca
unazad po log datoteci i ponistava promijene. Postoje slucajevi kada sistem forsira ROLLBACK bez obzira na
nasu saglasnost.To su slucajevi kada se desi neka greska pa sistem sam vrsi oporavak.
Primjer:Kod 2 prodavnice rezervisu 1 preostalu kartu. Jedan ce dobiti, drugi nece. Tu ce sistem sam odraditi
ROLLBACK-to je sistemski ROLLBACK.
2. Vazno je obezbijediti odgovarajucu poruku na kraju izvrsavanja transakcije.
3. Postoji log za oporavak. Sistem odrzava log ili zurnal u kome se nalaze informacije neophodne za oporavak
-aktivni log
-arhivski log(kad se napuni aktivni)
 4. Sistem garantuje da je izvrsavanje naredbi nad bazom atomsko-naredbe se izvrsavaju nad skupovima torki i u
slucaju greske u sredini naredbenije dozvoljeno da nad nekim torkama naredba bude izvrsena a nad nekim
ne
5. Program se izvrsava kao niz transakcija.
6. COMMIT ili ROLLBACK zavrsavaju transakciju alli ne prekidaju izvrsavanje programa
7. „Program <- 1st transaction ->
initiation“ BEGIN TRANSACTION COMMIT
<- 2nd transaction ->
BEGIN TRANSACTION ROLLBACK
<- 3rd transaction ->
BEGIN TRANSACTION COMMIT
„Program termination“

8. Nema ugnjezdenih transakcija

9. Transakcija ostavlja bazu u konzistentnom stanju. Unutar transakcije, pri izvrsavanju operacija koje cine
transakciju, konzistentnost moze da bude narusena. Konzistetno stanje ne znaci da je sadrzaj baze korektan.
Danasnji SUBP ne vrse provjeru korektnosti, vec podrazumijevaju da su transakcije korektne
10. Paralelno izvrsavanje operacija transakcija ukida potrebu za COMMIT, ROLLBACK iBEGIN TRANSACTION. U
teoriji je moguce ali nije do kraja podrzano od strane savremenih SUBP.

Upravljac transakcijama obezbedjuje da se trans ne izgube, da ne budu delimicno izvrsene ili da ne budu izvrsene
vise puta. Struktura trans je:
BEGIN TRANSACTION;
/*niz operacija transakcije*/
.
.
.
COMMIT; (ili ROLLBACK)
/*signal uspesnog ili neuspesnog zavrsetka*/

COMMIT
1 signalizira uspesan kraj transakcije
2 sve promene postaju stalne
3 do tada su promene smatrane samo kao namera koja je mogla da se ponisti u slucaju pojave greske

ROLLBACK
1 signalizira neuspesan kraj transakcije
2 baza može da bude u nekonzistentnom stanju
3 sve promene ucinjene u transakciji moraju da budu ponistene (na osnovu sadržaja log datoteke)

LOG (protokol pisanja unapred):

1 Upis promena u bazu i upis promena u log su dve razlicite operacije
2 Izmedju njih može da se desi greska
3 Pre pisanja sloga u fizicku bazu mora prvo da se upise slog u log datoteku
4 Pre potvrde transakcije svi log slogovi moraju da se upisu u fizicki log

Neki od ovih logova nisu uvek korektni, npr nestane struje i sistem krene da se dize.Prvo se cita iz loga i vraca
konzistentnost. Pokazalo se da ako tokom tog procesa nestane struja mogu da se izgube neki podaci.
TACKA SINHRONIZACIJE
1 Nalazi se izmedju dve transakcije. Baza je u konzistentnom stanju
2 U nju se dolazi ili inicijalizacijom programa ili izvrsavanjem COMMIT/ROLLBACK
3 Kada se uspostavi tacka sinhronizacije
-sve promene nastale od prethodne tacke sinhronizacije se potvrdjuju (COMMIT) ili ponistavaju (ROLLBACK)
-svi kursori otvoreni u programu se zatvaraju, sem ukoliko nisu deklarisani sa WITH HOLD opcijom
-kljucevi nad objektima baze se oslobadjaju (zavisi i od nacina vezivanja programa)

ACID OSOBINE
Transakcija poseduje osobine:
1 Atomicnost (eng. Atomicity). Transakcije su atomske
2 Konzistentnost (eng. Consistency). Transakcije cuvaju konzistentnost baze
3 Izolovanost (eng. Isolation). Transakcije su izolovane jedna od druge prilikom izvrsavanja.
4 Trajnost (eng. Durability). Po potvrdjivanju transakcije promene ostaju u bazi, cak i u slucaju pada sistema

Kritican resurs-sadrzaj bafera, odnosno glavne memorije koji je izgubljen(bafer u sistemu postoji samo na jednom
mjestu i ako se izgubi->problem).

OPORAVAK
-ponistiti efekte transakcija koje su bile aktivne u vreme nastanka greske
-ponoviti izvrsavanje transakcija koje su uspesno zavrsile do tog trenutka ali nisu stigle da efekat izvrsavanja zapisu
na fizicki disk

CHECKPOINT Presek stanja sistema (kao da uzmemo zamrznutu sliku i kad krene oporavak krenemo od te tacke)
Algoritmi za oporavak:
-citanje log datoteke i zatim ponistavanje efekta nezavrsenih transakcija i ponavljanje efekta zavrsenih
ARIES (Algorithms for Recovery and Isolation Exploiting Semantics). Zbog efikasnosti savremeni sistemi prvo vrse
onavljanje izvrsavanja transakcija a zatim ponistavanje efekata neizvrsenih transakcija. Ako bi radio obrnuto, opet
greska.

DVOFAZNI COMMIT
Neophodan u slucaju da aplikacija radi sa nezavisnim upravljacima resursa (npr. IMS i DB2)
Nepohodan u slucaju distribuiranih baza.
Obezbedjuje korektno izvrsavanje u slucaju pojave greske na bilo kojoj komponenti.
"Globalni"(odnosi se na sve sisteme) COMMIT ili ROLLBACK
Koordinator - sistemska komponenta koja koordinira rad upravljaca resursa

TACKE CUVANJA (savepoints)

mesta unutar transakcije na koje se dolazi ponistavanjem uradjenih aktivnosti koje slede posle njih.
vidljive su jedino unutar transakcije.
nisu isto sto i COMMIT; izvrsavanjem ROLLBACK-a se ponistavaju sve tacke cuvanja unutar transakcije.
Za jednu transakciju to bi bila neka vrsta checkpoint-a . To radimo da ne bi radili cijelu transakciju ponovo.
Primer: Imamo 4 mesta, ja hocu 2 mesta. Imamo 2 mesta u prednjem i 2 mesta u zadnjem delu aviona. Ja kazem da
hocu 2 napred, pa se predomislim i trazim nazad. Tacka cuvanja bi bio korak unazad, odnosno da su dva mesta
rezervisana, nebitno napred ili nazad, bitno je da su rezervisana.To se eksplicitno navodi u programu.
SQL-podrska -start transaction-kod vecine SUBP implicitno
-COMMIT [work] [AND [NO ] CHAIN ];
-ROLLBACK [work] [AND [NO ] CHAIN ];
-AND CHAIN – uzrokuje start nove transakcije
-AND NO CHAIN – je predefinisano
-SAVEPOINT
-WITH HOLD – u deklaraciji kursora
KONKURENTNOST

Termin konkuretnost oznacava cinjenicu da SUBP dopusta vecem broju transakcija pristup do istih podataka
istovremeno. Prednosti konkuretnog rada:
-krace vreme odziva
-maksimalna propusnost(broj programa koji mogu da rade sa istim podacima)
Problem: kako obezbediti da konkuretne transakcije ne smetaju jedna drugoj?

PROBLEMI u konkuretnom radu

1 Problem izgubljenih ažuriranja (eng. Lost update problem)
2 Problem zavisnosti od nepotvrdjenih podataka (eng. uncommited dependency problem)
3 Problem nekonzistentne analize (eng. inconsistent analysis problem)

Problem izgubljenih azuriranja:

Trans A vreme Trans B
--- - ---
Fetch R t1 ---
--- - ---
--- t2 fetch R
--- - ---
Update R t3 ---
--- - ---
--- t4 Update R

Problem zavisnosti od nepotvrdjenih podataka:

Prvi slucaj: Trans A vreme Trans B
--- t1 Update R
--- - ---
fetch R t2 ---
--- - ---
--- t3 ROLLBACK
Transakcija A u trenutku t2 zavisi od nepotvrdjenih promena
Drugi slucaj: Trans A vreme Trans B
--- t1 Update R
--- - ---
update R t2 ---
--- - ---
--- t3 ROLLBACK
Transakcija A u trenutku t2 azurira podatke cija promena nije potvrdjena, i u trenutku t3 se gube ucinjene promene.
Problem Nekonzistentne analize:
Tri racuna sa stanjem: rac1=40, rac2=50, rac3=30. Transakcija A sabira stanje na sva tri racuna, dok
transakcija B prenosi 10 sa rac3 na rac1. U jednom trenutku samo jedan moze fizicki da koristi CPU. Moze da
s edesi da ga operativni sistem prekine i dodeli drugom programu.Posledica je dobijanje pogresne vrednosti
za zbir.
Trans A vreme Trans B
Fetch rac1(40) t1 ---
Sum=40 - ---
--- - ---
Fetch rac2(50) t2 ---
Sum=90 - ---
--- - ---
--- t3 fetch rac3(30)
--- - ---
--- t4 update rac3(30->20)
--- - ---
--- t5 fetch rac1(40)
--- - ---
--- t6 update rac1(40->50)
--- - ---
--- t7 commit
--- - ---
Fetch rac3(20) t8 ---
Sum=110 - ---

ZAKLJUCAVANJE
Osnovna ideja:
-kada transakcija želi da radi sa nekim resursom ona zahteva zakljucavanje tog objekta (postavlja katanac nad tim
objektom).
-kada se transakcija zavrsi resurs se oslobadja.

PRETPOSTAVKE
Sistem podržava bar dve vrste katanaca: privatni (ekskluzivni, X) i deljivi (S)
1.Ako je transakcija A postavila X katanac nad torkom t tada zahtev bilo koje druge transakcije B za postavljanje bilo
kog katanca nad t biva odbijen
2.Ako je transakcija A postavila deljivi kljuc nad torkom t tada zahtev bilo koje druge transakcije B za postavljanje
-S katanca nad t može biti ispunjen
-X katanca nad t biva odbijen
Matrica kompatibilnosti:

Transakc A
X S -
X N N Y
Tran B

S N Y Y
- Y Y Y
KATANAC: X(privatni), S(deljiv),-(ne postoji)
N-konflikt, Y-kompatibilnost
DVOFAZNI PROTOKOL ZAKLJUCAVANJA
Striktni dvofazni protokol zakljuc avanja garantuje da se problemi konkurentnosti ne javljaju
1) Transakcija koja želi da procita torku mora prvo da nad njom postavi S katanac.
2) Transakcija koja želi da ažurira torku mora prvo da nad njom postavi X katanac. Alternativno, ako vec drži S
katanac nad tom torkom, transakcija mora da zahteva unapredjenje S katanca u X katanac.
3) Ako je zahtev za postavljanjem katanca od strane transakcije B odbijen jer je u konfliktu sa vec postavljenim
katancem od strane transakcije A, transakcija B ide u stanje cekanja. B ceka dok A ne oslobodi kljuc (sistem mora da
garantuje da B nece zauvek da ostane u stanju cekanja!).
4) X katanac se zadržava do kraja transakcije (COMMIT ili ROLLBACK). S katanac se, uobicajeno, takodje zadržava
(najduže) do kraja transakcije.

Problem izgubljenih azuriranja-resenje:

Trans A vreme Trans B
Fetch R t1 --- (zahteva S kljuc nad R)
--- - ---
--- t2 fetch R (zahteva S kljuc nad R)
--- - ---
Update R t3 --- (zahteva S kljuc nad R)
ceka - ---
ceka t4 Update R (zahteva X kljuc nad R)
ceka - ceka
Transakcija A gubi svoja azuriranja u trenutku t4
--u t1 transakcija A postavlja S katanac
--u t2 transakcija B postavlja S katanac
--u t3 transakcija A ne moze da postavi X katanac i ide u stanje cekanja
--u t4 transakcija B ne moze da postavi X katanac i ide u stanje cekanja
--ni jedna transakcija ne moze da nastavi rad, obe cekaju jedna na drugu-mrtva petlja(deadlock)

Problem zavisnosti od nepotvrdjenih podataka-resenje:

Prvi slucaj: Trans A vreme Trans B
--- t1 Update R (zahteva X katanac nad R)
--- - ---
fetch R t2 --- (zahteva S katanac nad R)
ceka - ---
ceka t3 ROLLBACK (tacka sinhronizacije, oslobadja se X katanac)
ceka - ---
fetch R t4 --- (ponovo se izvrsava i postavlja katanac S nad R)
Transakcija A je sprecena da procita nepotvrdjene promjene u trenutku t2.

Drugi slucaj: Trans A vreme Trans B

--- t1 Update R
--- - ---
update R t2 ---
--- - ---
--- t3 ROLLBACK

MRTVA PETLJA
Mrtva petlja (eng. deadlock) je situacija kada dve ili vise transakcija imaju postavljen katanac nad resursom koji je
potreban onoj drugoj tako da ni jedna ne može da nastavi sa radom.
Mrtva petlja može da ukljuci dve ili vise transakcija
Otkriva se grafom cekanja
Razresava se tako sto se izabere žrtva ciji se efekti poniste i tako oslobode resursi. Koja se bira za zrtvu zavisi od toga
sta od resursa drzi, koliko dugo radi,...
Sql code: =-911 transakcija je prekinuta i automatski je uradjen ROLLBACK
=-913 nije uradjen ROLLBACK ???????
SERIJALIZABILNOST
Kriterijum korektnosti izvrsavanja datog skupa transakcija. Izvrsavanje datog skupa transakcija je korektno ako je
serijalizabilno, tj. Ako proizvodi isti rezultat kao i serijsko izvrsavanje istog skupa transakcija.
Efekat zakljucavanja je da isforsira serijalizibilnost transakcije.

DVOFAZNI PROTOKOL ZAKLJUCAVANJA

TEOREMA:Ako sve transakcije primenjuju dvofazni protokol zakljucavanja tada su svi moguci rasporedi izvrsavanja
transakcija serijalizabilni.
Nacin rada:
1.Pre rada sa bilo kojim objektom transakcija mora da zahteva katanac nad tim objektom.
2.Po oslobadjanju katanca transakcija ne sme vise da zahteva bilo koji katanac.
Transakcije koje se ponasaju u skladu sa ovim protokolom imaju dve faze:
-faza zahteva za katancima
-faza ukidanja katanaca tj. Oslobadjanja resursa
Druga faza se cesto komprimuje u jednu operaciju (COMMIT ili ROLLBACK)

NIVO IZOLACIJE
Termin nivo izolacije se koristi za opis stepena ometanja koje tekuca transakcija može da podnese pri konkuretnom
radu.Ako su transakcije serijalizabilne stepen ometanja ne postoji, tj nivo izolacije je maksimalan. Realni sistemi zbog
razlicitih razloga (performansi) dopustaju rad sa nivoom izolacije koji je manji od maksimalnog. Sto je veci nivo
izolacije manje su dostupne smetnje i obrnuto.

NACINI ZAKLJUCAVANJA
Pod nacinom zakljucavanja podrazumeva se vrsta pristupa zakljucanom objektu koja je dostupna konkurentnoj
transakciji.
Protokol zakljucavanje sa namerom (eng. intent locking protocol) - transakciji nije dozvoljeno da zahteva katanac
nad torkom pre prvog zahteva za postavljanjem katanca uopste.
Konflikt izmedu zahteva se otkriva na nivou relvar-a a ne na nivou torki.
Ako transakcija T zahteva zakljucavanje relvara R katanci koje moze da postavi su:
IS (intent share) - T namerava da postavi S katanac nad pojedinacnim torkama R, radi garantovanja stabilnosti tih
torki koje namerava da obradjuje
IX (intent exclusive) - Isto kao i IS, plus sto T moze da ažurira pojedinacne torke i tada postavlja X katanac na njih
S (share) - T tolerise konkuretno citanje ali ne i konkuretno ažuriranje. T nema nameru da ažurira bilo koju torku iz R
SIX (shared intent exclusive) - Kombinacija S i IX, tj. T može da tolerise konkurentno citanje, i T namerava da ažurira
pojedinacne torke u R, u kom slucaju ce da postavi IX katanac na te torke
X (exclusive) - T ne može da tolerise bilo kakav konkuretan pristup do R.Samo T može ali ne mora da ažurira torke u
R.
Matrica kompatibilnosti:

Transakcija A
X SIX IX S IS -
X N N N N N Y
SIX N N N N Y Y
Transakcija B

IX N N Y N Y Y
S N N N Y Y Y
IS N Y Y Y Y Y
- Y Y Y Y Y Y
SQL standard:
-ne propisuje eksplicitno mogucnosti zakljucavanja
-zahteva od implementacija da obezbede mogucnost konkurentnog izvrsavanja transakcije
-zahteca da azuriranja jedne ne budu vidljiva drugim transakcijama sem u slucaju da prva zavrsi sa COMMIT-om.
SQL Standard definise sledece nivoe izolacije:
READ UNCOMMITED
READ COMMITED
REPEATABLE READ
SERIALIZABLE (predefinisan)

Standard definise tri nacina na koja serializabilnost može da bude narusena kada se ne radi sa najvecim nivoom
izolacije
-Prljavo citanje (eng. dirty read). Transakcija T1 ažurira neki slog, transakcija T2 cita taj slog a zatim T1 ponisti
promene. T2 je procitala slog koji ne postoji niti je formalno ikada postojao
-Neponovljeno citanje (eng. nonrepeatable read). T1 cita slog, T2 ažurira taj slog i T1 cita "istislog ponovo
-Fantomi (eng. phantom). Neka T1 cita skup slogova koji zadovoljavaju neki uslov. Neka T2 unese novi slog koji
zadovoljava isti uslov. Ako T1 sada ponovi zahtev videce slog koji ranije nije postojao - fantomski slog
Nivo izolacije Prljavo Neponovljeno Fantomi
READ UNCOMMITED Y Y Y
READ COMMITED N Y Y
REPEATABLE READ N N Y
SERIALIZABLE N N N

NIVOI IZOLACIJE KURSORA –DB@ REFERENCES VOL1

NIVOI IZOLACIJE u DB2 su
RR - Repeatable Read
RS - Read Stability
SC - Cursor Stability (predefinisan)
CC - currently committed (predefinisano za nove baze od V9.7)
UR - Uncommitted Read
NC - No Commit (samo na i seriji)

ZAKLJUCAVANJE I KONKURENTNOST
DIRTY WRITE-Transakcija menja nepotvrdjene podatke koji su modifikovani od strane neke druge transakcije koja
nije izvrsila COMMIT ili ROLLBACK.
DIRTY READ-Transakcija cita podatke koji su modifikovani od strane druge transakcije koja jos nije izvrsila COMMIT ili
ROLLBACK.
FUZZY READ, NON-REPEATABLE READ-Transakcija koja cita podatke, kad ponovi citanje ne vidi iste podatke.
PHANTOM READ-T1 cita skup slogova koji zadovoljavaju neki uslov. T2 unese novi slog koji zadovoljava isti uslov. Ako
T1sada ponovi zahtev, vidjece slog koji ranije nije postojao-fantomski slog.

Glavni razlozi zasto su ZAKLJUCAVANJA potrebna su:

-osiguranje integriteta podataka-sprecavanje promena dok jedna transakcija drzi resurs od strane druge transakcije
-pristup nepotvrdjenim podacima- A azurira podatke, B cita nepotvrdjene podatke,. Ako A uradi ROLLBACK, operacije
koje je B uradila su zasnovane na nepotvrdjenim(vjerovatno nevalidnim) podacima.

Database manager kontrolise pristup ovome da bi se sprecili nezeljeni efekti kao sto su:
-IZGUBLJENA azuriranja- A i B citaju isti slog. A azurira taj slog, a zatim to radi B. Kada B azurira taj slog A gubi
svoja azuriranja.
-NEPONOVLJENA citanja(non-repeatable read)-A cita slog i odlazi da obradi druge SQL zahtjeve. U
medjuvremenu B mijenja taj slog i salje COMMIT. Ako A sada pokusa da procita aj slog vidjece da je on
mijenjan ili obrisan.
-FANTOMI(phantom red phenomenom)-T1 cita skup slogova koji zadovoljavaju odredjeni uslov. T2 unosi
novi slog koji odgovara tom uslovu. Ako sada T1 ponovi zahtjev, vidjece da slog koji ranije nije postojao-
fantomski slog.
DB2 ce zahtevati kljuceve nad objektima baze u zavisnosti od tipa pristupai nivoa izolacije koji vazi za konekciju ili
naredbu za pristup podacima.Kljucevi nad prostorima tabela(objekti koji mogu biti zakljucani)se uglavnom koriste za
kontrolu konkurentnog izvrsavanja utility-ja kao sto su BACKUP,LOAD,REORG.
Primer-online backup nece raditi u isto vreme kada i utility obradjuje tabelu u istom prostoru tabela.
Za standardne DB2 tabele, DB2 ce zahtjevati kljuc na nivou tabele, zavisno od tipa pristupa. SELECT naredba ce
zahtevati kljuc koji dozvoljava citanje,... U vecini slucajeva DB2 ce zahtevati kljuceve za pisanje i citanje na nivou
redova tabele da bi dozvolio mnogim aplikacijama pristup tabeli. Kod multidimenzionih klasterovanih tabela (MDC)
podaci se cuvaju i indeksiraju na nivou bloka. DB2 moze da zahteva zakljucavanje na nivou blokova (range-
partitioned) tabele DB2 moze da zahteva zakljucavanje na nivou particija podataka.
Na vrhu svega su prostori tabela. Kad DB2 radi zakljucavanje, jedan par je tabelai neki njeni slogovi. Zakljucavanje
moze d abude na nivou blokova, klastera,...
Table lock Table lock
Table lock
Block lock Data lock
Row lock
Row lock Range lock

KATANCI NAD TABELAMA Row lock

IN-intent none-mozemo da citamo bilo koji podatak iz tabele, cak i one nepotvrdjene, ali ne mozezemo da azuriramo
nista. Konkurentnost transakcije mogu da citaju ili azuriraju tabelu. Kljucevi nad redovima nisu potrebni. I prostori
tabela i tabele mogu da budu zakljucani ovim kljucem.
IS-intention share-mozemo da citamo podatke ako mozemo da dobijemo kljuc S nad ciljani mredovima. Ne mozemo
da vrsimo azuriranja. Drugi mogu da citaju ili mijenjaju podatke, sve dok ne mijenjaju redove nad kojima drzimo S
kljuc. I prostori tabela i tabele mogu biti ovako zakljucani.
IX-intention exclusive-vlasnik moze da cita ili azurira ako dobije unapredjenje u X katanac za slogove koje zeli da
azurira, odnosno U ili S katanac za slogove koje hoce da cita. Ostali mogu da citaju ili azuriraju tabelu, sve dok to nije
nad slogovima nad kojima vlasnik ima X katanac. I prostori tabela i tabele mogu biti ovako zakljucani.
SIX-share with intention exclusive-vlasnik moze d acita bilo koje podatke i mijenja redove nad kojima moze d adobije
unapredjenje u X katanac. Ostali mogu da citaju tabelu. Zakljucavanje tabela sa SIX je poseban slucaj. Do njega dolazi
ako aplikacija drzi IX katanac nad tabelama i zahteva S katanac, ili obratno. Rezultat je SIX katanac.
S-shore-dijeljiv kljuc, vlasnik i svi ostali m ogu da citaju ali ne i da azuriraju podatke u tabel. Tabele mogu biti ovako
zakljucane.
U-update-vlasnik moze da cita sve podatke iz tabele i moze da mijenja podatke ukoliko moze d adobije X kljuc nad
tabelom. Ovo moze da se desi ukoliko imamo SELECT sa FOR UPDATE . ostali mogu da citaju ali ne i da azuriraju.
Tabele mogu biti zakljucane ovako.
X-exclusive-vlasnik moze da cita ili azurira podatak. Samo UR moze da pristupi zakljucanom objektu. Tabele mogu biti
ovako zakljucane.
Z-super exclusive-koristi se kod alter i drop naredbi nad tabelama ili kod nekih tipova reorganizacije tabela. Niko
drugi ne moze da cita ili azurira tabelu. Tabeli i prostori mogu da budu ovako zakljucani.

IS, IX, SIX se koriste na nivou tabele da bi bilo podrzano zakljucavanje redova(slogova). Oni dozvoljavaju zakljucavanje
na nivou slogova istovremeno sprecavajuci vise ekskl. Kljuceva nad tabelama koje postavljaju druge aplikacije.
S,U,X i Z se koriste na nivou tabele da isforsiraju striktnu strategiju zakljucavanja tebela. Ne koristi se zakljucavanje
nad redovima(slogovima)
IN se koristi nad tabelom da dozvoli koncept uncommited read-a. Nisu potrbna zakljucavanja na dslogovima.
KLJUCEVI NAD REDOVIMA(SLOGOVIMA)
S-share- slog je dostupan za citanje vlasniku, dok ostali mogu da citaju.
U-update-vlasnik cita slog, ali postoji mogucnost da ga mijenja. Ostali mogu samo da citaju. Glavna razlika u odnosu
na S je namjera da se izvrsi azuriranje. U katanac podrzava kursore koji imaju FOR UPDATE OF. Samo jedna aplikacija
moze da drzi U katanac nad slogom.
X-exclusive-slog moze da mijenja samo vlasnik. Za ostale nije dostupan, osim ako s ekoristi uncomitted read.
W-weak exclusive-zahtijeva se nad slogom kada se on unosiu ne katalosku tabelu i kada se naidje dupliran kljuc za
unique indeks. Vlasnik moze da mijenja zakljucan slog. Ovaj kljuc je slican X-u, samo je kompatibilan NW kljucu.
NS-next key share-vlasnik i konkurentne aplikacije mogu da citaju ali ne i da azuriraju red. Samo pojedinacni redovi
mogu da budu zakljucani sa NS. Ovaj kljuc se zahtjeva kad imamo dijeljiv kljuc(S) nad podacima koji se citaju sa RS ili
CS novoom izolacije.
NW-next key weak exclusive-ovaj kljuc se zahtjeva nad sledecim slogom kada se slog unosi u indeks nekataloske
tabele. Vlasnik moze da cita ali ne i da mijenja zakljucan slog. Ovo je slicno X i NX kljucevima, samo sto je ovo
kompatibilno sa W iNS kljucevima.
Kljucevi nad slogovima zahtijevaju samo aplikacije koje imaju podrzano zakljucavanje na nivou tabela. Ovi
podrzavajuci kljucevi sa namerom IS, IX i SIX.

TABLE LOCK ROW LOCK

B B
IN IS S IX SIX U X Z
S U X W NS NW
IN Y Y Y Y Y Y Y N
S Y Y N N Y N
IS Y Y Y Y Y Y N N
A U Y N N N Y N
S Y Y Y N N Y N N A X
IX Y Y N Y N N N N N N N N N N
SIX Y Y N N N N N N W N N N N N Y
U Y Y Y N N N N N NS Y Y N N Y Y
X Y N N N N N N N NW N N N Y Y N
Z N N N N N N N N

Osnovni koncept ROW LOCK-a je da slogove koje cita jedna aplikacija mogu da citaju i drugi, i slogove koje azurira
jedna aplikacija nisu dostupni drugima koji koriste zakljucavanje na nivou slogova.

NIVOI IZOLACIJE OBJEKTA:

Odredjuje nacin na koji su podaci zakljucani od strane jednog objekta za pristup drugima DB2 omogucava razlicite
nivoe izolacije:
-UNCOMMITED READ(UR)
-CURSOR STABILITY(CS)-ponasanje pri zakljucavanju zavisi od CUR_COMMIT u konfiguraciji baze:
-ON-read only pristup nece zahtijevati zakljucavanje na nivou slogova
-AVAILABLE-aplikacija moze da izbere commited mod da bi izbijegla zakljucavanje slogova
-DISABLE-read only pristup ce zahtijevati zakljucavanje na nivou slogova
-READ STABILITY (RS)
-REPEATABLE READ(RR)
Nivoi izolacije mogu da navedu za sesiju, korinsicku konekciju ili za aplikaciju prije konekcije na bazu, ili za
pojedinacne SQL naredbe:
-za ugradjeni SQL nivo izolacije se odredjuje u vreme vezivanja(bind time)
-za dinamicki SQL nivo izolacije se odredjuje u vreme izvrsavanja(run-time)
-SELECT ... WITH UR|CS|RS|RR
NIVO IZOLACIJE odredjuje:
-stepen u kome su slogovi koje citamo ili azuriramo dostupni drugima
-stepen u kome konkurentno azuriranje od strane drugih utice na nas
-nivo izolacije za staticki SQL se definise kao atribut paketa i odnosi se na aplikaciju koja koristi taj paket. Nivo
izolacije se definise u vrijeme pripreme programa postavljenjem ISOLATION bind ili prekompile option.
-za dinamicki SQL podrazumijevanji nivo izolacije je onaj koji je odredjen u paketu koji priprema naredbu. Pomocu
SET CURRENT ISOLATION naredbe definisemo nivoe izolacije za dinamicke SQL naredbe.
-ako u SELECT navedemonivo izolacije on vazi bez obzira na nivo izolacije koji je naveden u dinamickom ili statickom
SQL(u specijalnom registru ili kao bind vrijednost(kod statickog)).
-privremene tabele i njigovi slogovi ne mogu da budu zakljucani zato sto su oni dostupni samo iz aplikacije u kojoj su
generisani.

DB2 i ANSI NIVOI IZOLACIJE:

DB2 ANSI Dirty write Dirty read Fuzzy read Phantom read
Uncomitted read Read uncomitted N Y Y Y
(UR) (lvl 0)
Cursor stability Read committed N N Y Y
(CS) (lvl 1)
Read stability Repetable read N N N Y
(RS) (lvl 2)
Repeatable read Serializabel read N N N N
(RR) (lvl 3)

ZAKLJUCAVANJE ZA READ-ONLY PRISTUP

NIVO IZOLACIJE METODE ZAKLJUCAVANJA ZA READ-ONLY PRISTUP DOZVOLJEN
PRISTUP
NEPOTVRDJENIM
PROMENAMA
UNCOMMITED READ IN- nad tabelom, ne zakljucavamo slogove za read only pristup. DA
Nepotvrdjenim slogovima pristupamo iz bafera.
CS SA CURRENCY IS-nad tabelom, ne zaklj. Slogove za read only pristup. Staru verziju NE
COMMITED sloga sa nepotvrdjenim promenama citamo iz log-a.
CS BEZ CURRENCY IS-nad tabelom, NS nad trenutnim slogom. Drzi se kljuc zbog NE
COMMITED kasnjenja pri pristupu nepotvrdjenim promenama u baferu
READ STABILITY IS-nad tabelom, NS cuva rezultat do COMMIT-a. Drzi se kljuc zbog NE
kasnjenja pri pristupu nepotvrdjenim promenama u baferu
REPEATABLE READ IS-nad tabelom,S cuva rezultat do COMMIT-a u svim redovima. Drzi NE
se kljuc zbog kasnjenja pri pristupu nepotvrdjenim promenama u
baferu

Kako radi CURRENCY COMMITED sa nivoom izolacije CURSOR STABILITY:

A Azurira neke slogove. B cita neke slogove, medju kojima su one cije promena A nije potvrdila. Ako je CC ukljucen, B
te slogove (nepotvrdjene) cita iz log-a i ne ceka da A uradi commit ili rollback. Sustina je da konkurentnostmoze da se
obezbedi i na druge nacine, a ne samo zakljucavanjem. Nedostatak je to sto treba da obezbijedimo vise kopija, sto
moze da optereti log datoteku. Ako je log pun sa bazom ne moze nista da se radi, pa se gubi na performansama.
Postoji mogucnost implicitnog(sam uradi DB2, database manaager)i eksplicitnog (lock table naredba) zakljucavanja.
LOCK TABLE ime IN SHARE (EXCLUSIVE) MODE

LOCK TABLE naredba omogucava programeru da zakljucava tabelu u strozijem modu od onog sto zahtijeva database
manager. Mi sa LOCK TABLE smanjujemo nivo paralelnog izvrsavanja. Ovo radimo ako npr hocemo presjek stanja pa
ne zelimo da nas prekida jer nam je potrebno bas precizno stanje.
SHARE MODE-dozvoljava drugima SELECT nad tabelom ali ne i INSERT, UPDATE ili DELETE.
EXCLUSIVE MODE-zabranjuje ostalima da vrse bilo koje operacije nad tabelom, sa izuzetkom onih koji imaju nivo
izolacije UNCOMMITED READ

KONVERZIJA KATANACA:
Moguce je da se izvrsi konverzija nekih katanaca na katance na visem nivou-to bi bilo unapredjenje katanaca.
Unapredjenje ide samo u jednom smijeru i nijedna naredba ne moze da vrati katanac na nizi nivo dok se ne odradi
ROLLBACK ili COMMIT.SIX kljuc nad tabelom je poseban slucaj. Dobija se kada drzimo IX kljuc nad tabelom i
zahtevamoS kljuc, ili obrnuto. Rezultat konverzije kljuceva u ovom slucaju je ikatanac SIX.

ESKALACIJA KLJUCEVA:
Imamo tabelu i na njoj imamo neki kljuc. U njoj imamo mnogo slogova koji imaju neki drugi kljuc. Kada u jednom
trenutku bude previse takvih slogova, dolazi do ekskalacije kljuceva i taj kljuc podizemo na visi nivo-npr nivo tabele.
Dva parametra u konfiguraciji baze direktno uticu na proces ekskalacije kljuceva.
1. LOCKLIST-za memoriju za kljuceve se analizira 4KB u bazi. Ovaj parametar moze da se mijenja.
2. 2. MAXLOCK-procenat locklist-e dozvoljen jednoj aplikaciji. Ovaj parametar moze da se mijenja.
Eskalacija kljuceva moze da se javi u dvije razlicite situacije:
1. Aplikacija trazi kljuc koji ce nadmasiti procenat u locklistu definisan u maxlock. Database manager ce
pokusati da oslobodi memoriju postavljanjem kljuca nad tabelom i oslobadjanjem kljuceva nad slogovima.
2. Aplikacija trazi eskalaciju kljuceva ako je lock lista puna. Database manager ce pokusati da oslobodi
memoriju dobijanjem kljuca nad tabelom i oslobadjanjem kljuceva nad slogovima.
SQLCODE -912 ukoliko je askalacija kljuceva neuspesna.
LOCKLIST/MAXLOCK definisu ukupnu kolicinu memorije dostupnu za kljuceve i memorijski limit za kljuceve jedne
aplikacije.

LOCKLIST MAXLOCK
-kolicina memorije koja se koristi za kljuceve -max procenat memorije koji se dodjeljuje jednoj
-parametar u konfiguraciji baze konekciji iz locklist-e
-velicina stranice u memoriji 4K -parametar u konfiguraciji baze
-moze da se menja -velicina je u procentima
-automatsko odrzavanje -moze da se menja
-default -automatsko odrzavanje
-dozvoljava dinamicko upravljanje memorijom -default
sa najmanje jos jednim automatskim -zahteva da je LOCKLIST podesen na automatic
potrosacem memorije -raspon 1-100
-omogucava automatsko odrzavanje
MAXLOCK-a-
opseg 4 - 524288
TIMEOUT je kada jedna aplikacija drzi resurs, a svi ostali hoce da mu pristupe. Drugi ne drze nista. TIMEOUT je
vrijeme poslije koga se prekida ovo cekanje. Ovo vrijeme se konfigurise pomocu parametra locktimeout. Vrijednost
se definise u sekundama. Za transakciona okruzenja preporucena startna vrijednost za ovaj parametar je 30 sekundi.
Ukoliko za vrijednost stavimo -1, sto je podrazumjevana vrijednost timeout se iskljucuje i aplikacije koje cekaju nece
primiti timeout.
Aplikacija moze da koristi naredbu SET CURRENT LOCK TIMEOUT da promijeni podrazumijevanu vrijednost u bazi.
Ukoliko hocemo da iskljucimo promjene i koristimo podrazumjevanu vrijednost, onda : set current lock timeout null

DEADLOCK-uzroci i otkrivanje
Situacija kad advije ili vis eaplikacija imaju postavljen katanac nad resursom koji je potreban onoj drugoj, tako da ni
jedna ne moze da nastavi sa radom.
Uzroci deadlock-a:
-REPEATABLE READ i READ STABILITY
-ESKALACIJA KLJUCEVA
-CATALOG MODIFICATION
-REFERENTIAL CONSTRAINT ....
-LOSE PROGRAMIRANJE

Detektor DEADLOCK-a(DEADLOCK DETECTOR)-pozadinski proces koji upravlja mrtvim petljama. Kada se otkrije bira
se zrtva nad kojim se vrsi ROLLBACK i vraca SQLCODE -911 sa reason code 2. ROLLBACK nad zrtvom oslobadja
kljuceve i drugi procesi mogu da nastave.

DLCHKTIME- deadlock check interval-odredjuje vremenski interval u kome se provjerava da li je doslo do mrtve
petlje. Mjeri se u milisekundama. Podrazumjevana vrijednost je 10 sekundi( 10 000 ms).

OPTIMISTICKO ZAKLJUCAVANJE
Tehnika koja ne zahtjeva zakljucavanje na nivou slogova izmedju SELECT i UPDATE/DELETE nad ti mslogovima.
Pretpostavljamo da otkljucani slogovi nece biti mijenjani preije UPDATE ili DELETE. Ako se slogovi promijene UPDATE
i DELETE nece uspjeti i ovakve neuspjehe treba da obradimo u aplikaciji, npr tako sto ponovimo SELECT. Prednost
optimistickog zakljucavanja je poboljsana konkurentnost, zato sto drugi mogu da citaju (pisu) taj slog. DB2 koristi
odredjene funkcije koje olaksavaju implementaciju optimistickog zakljucavanja. To su:
-RID-BIT-vraca lokaciju sloga u tabeli
-ROW CHANGE TOKEN-daje vrijednost koja pokazuje trenutnu verziju sloga
Podaci koje vracaju ove funkcije se koriste za UPDATE i DELETE. Uz pomoc vrijednosti koju vraca RID-BIT DB2 brzo
pronalazi optimalni red. Uz pomoc vrijednosti iz ROW CHANGE TOKEN DB2 zna da li je bilo promijena u tom slogu
od prethodnog SELECT-a. Ove funkcije dozvoljavaju aplikaciji da osigura integritet podataka bez drzanja katanca duzi
period vremena, sto doprinosi boljim preformansama i smanju lock contation.
SERIJALIZACIJA
DB2 ima mehanizme serijalizacije koji:
-sprecavaju gubitak integriteta podataka
-maksimizuje konkurentnost
-minimizuje cijenu CPU, I/O i memorije
Ti mehanizmi su:
1. Transakciono zakljucavanje
2. Restricted states-STOP, START,UT,CHKP,UTUT,UTRO,UTRW,...
3. Claims and drains-omogucava DB2 utility-ma i naredbama da nezavisno od bilo kojih katanaca koje ima
transakcija preuzmu kontrolu nad objektima npr QUIESCE utility
4. Latching-struktura stranice moze da bude nekonzistentna dok se vrse promijene. Za ovo vrijeme page batch
se koristi da sprijeci pristup stranici
Konkurentnost se odnosi na dijeljenje resursa od strane vise korisnika ili programa u isto vrijeme. Ovo DB2 kontrolise
pomocu mehanizama serijalizacije.
Sta sve moze biti zakljucano?
Podaci koje oznacimo u SQL-u. Ovdje imamo najvecu kontrolu. Dodatno podaci u povezanim tabelama mogu biti
zakljucan, npr. U roditelj tabeli brisemo slog. DB2 moze da obrise slog i u zavisnoj tabeli. Ako se ovo desi DB2
zakljucava slog u roditelji u zavisnoj tabeli. Ukoliko se katalozi u directory azuriraju i oni moraju biti zakljucani. Indeksi
koji se koriste nad tabelama se ne zakljucavaju transakcionim katancima.

Glavne karakteristike transakcionog zakljucavanja:

-VELICINA
-NACIN
-TRAJANJE
Velicina -isti podaci mogu da se kontrolisu katancima razlicite velicine. Katanac nad prostorom tabele(najveci)
kontrolise najvise podatak, sve podatke u prostoru tabela. Katanci nad slogovimakontrolisu samo podatke u
pojedinacnim slogovima. Naredbe CREATE TABLESPACE i ALTER TABLESPACE imeju LOCKSIZE opciju. Izbor moze da
bude ANY(default(DB2 sam odluci sta je najbolje)), ROW, PAGE, TABLE ili TABLESPACE.
Jos jedna mogucnost je LOCK TABLE naredba sa SHARE i EKSKLUSIVE nacinom pristupa. Hijerarhija zakljucavanja-ako
hocemo da zakljucamo slog, moramo prvo da zakljucamo prostor tabela, pa tebelu, pa tek onda slog.

Izbor velicine katanca predstavlja odnos izmedju konkurentnosti i CPU OVERHEAD

Dvije strategije zakljucavanja:
1. DB2 zakljucava samo tabele-slogovi ce imati isti katanac
2. DB2 zakljucava tabele i stranice i slogove u njima
Katanci: S,U, X –nad slogovima (24 str). S je kada vlaxsnik i ostali mogu da citanju ali ne da update-ju, U je kada
vlasnik moze da cita ali ne da update-je, ostali mogu da imaju S, vlasnik moze da unapredi U u X, smanjuje se
deadlock. X samo vlasnik kljuca moze da cita ili update-uje, ostali mogu da citaju sa UR.
S U X
S Y Y N
U Y N N
X N N N

(intent lock mode)(IS, IX, SIX), (Gross lock mode)(S,U,X)-nad prostorima tabela i tabelama
IS (Intent share), IX (Intent exclusive), SIX (Share with intent exclusive), S (Share),U (Update), E (Exclusive)

IS: vlasnik moze da cita podatke u tabel, prostoru tabela ili particiji ali ne da menja. Ima S katanac na stranama i
redovima kojima pristupa. Istodobni procesi mogu čitati i mijenjati podatke.
 IX: vlasnik i istodobni procesi mogu citati i menjati podatke u tabeli, prostoru tabela ili particiji. Ima X katanac .
SIX: je zapravo hibrid stanje. Iz perspektive čitanje je gross lock i od pisanja je intent lock.
Vlasnik brava može čitati i mijenjati podatke u tablici, prostorima tabela ili particiji.
Istodobni procesi mogu čitati podatke u tablici, prostorima tabela ili particiju, ali ne ga promijeniti.
Tek kada je vlasnik lock-a mijenja podatke dobija X lock na stranici ili reda.
S: Vlasnik kljuca i istodobni procesimogu da citaju, ali ne da menjaju podatke u tabeli ili prostorima tabela. Nije
potreban S kljuc na strani ili redu.
U: Vlasnik kljuca moze da cita, ali ne d amenja zakljucane podatke. Ali moze da unapredi U u X i onda menja
podatke. Smanjuje sansu za deadlock kada vlasnik kljuca cita podatke da odluci da li da ih menja.
X: Vlasnik moze da cita i menja podatke u tabeli ili prostorima tabela. Samo istodobni procesi mogu da pristupe
tabeli ili prostorima tabela.

Nivoi izolacije:
CURSOR STABILITY(CS)
Nakon sto korisnik1 uradi FETCH, ako slog ili strana koju zeli vec ima X katanac, DB2 ceka dok ne dobije S
katanac. S katanac nad tim slogom ili stranom ce se otpustiti kod FETCH uzrokuja DB2 da predje na sledeci
slog ili stranu. Ako korisnik izda FETCH i slog ili stranica koje trazi nemaju X katanac, onda DB2 izbjegava
stavljanje S katanca. Ovo smanjuje uticaj korisnika na buduca azuriranja, ali ako on ponovi svoj zahtjev, moze
dobiti razlicit rezultat. Ukoliko u deklaraciji kursora stavimo FOR UPDATE OF, onda DB2 umijesto S uzima U
katanac. On se isto otpusta po prelasku u novi slog ili stranu.
PEPETABLE READ(RR)
Kjuc S nad slogovima ili stranama se drzi nad svim slogovima kojima smo pristupili do sledeceg COMMIT-a.
READ STABILITY(RS)
Kljuc nad slogom ili stranom se drzi samo za one slogove ili strane koji ispunjavaju uslov upita najkasnije do
sledeceg COMMIT-a. RS nudi vecu konkurentnost od RR jer iako drugi ne mogu da mijenjaju slogove koji
ispunjavaju uslove aplikacije, mogu da ubacuju nove i azuriraju slogove koji ne zadovoljavaju uslove
aplikacije. U RS mogu da se dese fantomi.
UNCOMMITED READ(UR)
Korisnik ne zahtjeva katance nad stranama ili slogovima. Prednosti-azuriranje ne zahtjeva od korisnika da
ceka da postavi katanac i korisnik ne usporava nikog drugog. Problemi-korisnik moze da cita nepotvrdjene
podatke, slog moze da se broji vise puta.

ZAKLJUCAVANJE STRANICA I SLOGOVA  OSLOBADJANJE KATANACA

-S-katanac-SELECT S i U katanci
-ako neuspe izbegavanje kljuceva -DB2 samo predje na sledeci slog(stranu samo
-ili ako nije UR CS)
-FETCH NO FOR UPDATE -zavrsi (CS samo)
-ako neuspe izbegavanje kljuceva -jedna SELECT naredba-sledeca instrukcija
-ili ako nije UR -operacija kursora (SQLCODE=100)
-zatvori kursor
-COMMIT

MOZE: ALLOCATE/DEALLOCATE
USE/DEALLOCATE
USE/COMMIT
NE MOZE: ALLOCATE/COMMIT
U katanac  FETCH ... FOR UPDATE
X katanac  INSERT, UPDATE i DELETE
Trajanje katanaca nad TABELOM, PROSTOROM TABELA I PARTICIJAMA:
Postoje parametri koji kazu koliko dugo traje neki kljuc.
-ACQUIRE -ALLOCATE-trazim da mi se svi potrebni kljucevi dodijele na pocetku aplikacije. Ako ih ne dobijem
odmah - GRESKA
-USE-taj kljuc mi se dodijeljuje kad naidjem na naredbu gdje mi on treba
-RELEASE -DEALLOCATE- kada se zavrsi program. Ako koristimo ALLOCATE moramo da oslobadjamo sa
DEALLOCATE. Svrha je da program kad krene dobije max svega sto mu treba i to drzi do kraja. Nista
ne moze da ga prekine. To je najmanji nivo konkurentnosti. Ovo je kao da smo sami na sistemu.
-COMMIT
USE/COMMIT je najveci nivo konkurentnosti.Ne smije da se koristi kombinacija ALLOCATE/ COMMIT.
LOCKMAX je opcija u CREATE/ALTER TABLE SPACE. Odredjuje max broj zakljucanih slogova i strana koje aplikacija
moze da drzi u prostoru tabele. Ako aplikacija zahtjeva vise od tog broja dolazi do ekskalacije kljuceva.

TIMEOUT-Proces je suspendovan kada trazi kljuc koji je vec zauzet od strane nekog drugog procesa i ne moze da
bude deljen. Suspendovani privremeno zaustavi izvrsavanje. Nastavi sa radom kada:
-Svi procesi koji su u konfliktu oslobode kljuc ili
-Proces koji zahteva istekne vreme i mora d ase nosi sa greskom. DB2 resava to sa dve poruke u konzoli i
vraca SQLCODE -911 ili -913 procesu.
DEADLOCK
1. User 1 updates table M, and acquires an exclusive lock for page A, which contains
record 000100.
2. User 2 updates table N, and acquires an exclusive lock for page B, which contains
record 000030.
3. User 1 then attempts to SELECT from page B of table N, while still holding the lock on
page A of table M. The job is suspended, because user 2 is holding an exclusive lock on
page B.
4. User 2 then attempts to SELECT from page A of table, M while still holding the lock on
page B of table N. The job is suspended, because user 1 is holding an exclusive lock on
page A.
Situacija je deadlock. Posle vremena, DB2 can roll back trenutnu jedinicu posla za jednu od procesa ili zahteva proces
da se zavrsi. To oslobadja kljuceve i dopusta preostalim procesima da nastave sa radom.
SMANJENJE DEADLOCK-a
Jedan od načina da se smanji vjerojatnost zastoja je pristup podacima na dosljedan cilju.
U gornjem primjeru, oba korisnika treba pristupiti tablice u istom redoslijedu, ako je moguće,
to jest, tabela M slijede tabelu N. Prvi korisniku pristup tabeli M moglo odgoditi drugi
Korisnik ali dvije korisnici ne mogu zastoja.

INDEKSI
Indeksi su struktura podataka za efikasno pronalazenje slogova na nekom kljucu.
Javili su se 60-tih i oni su u sustini pokazivaci. Takodje olaksavaju skeniranje cijelih relacija ako podaci nisu smesteni
na fizicki uzastopnim blokovima. Kako najjednostavnije odrediti gdje je slog? Jedan nacin je da krenemo slog po slog,
redom. Prvi problem je bespotrebno citanje, a drugi sto moramo da idemo do kraja tabele da vidimo da nema jos
takvih slogova.
Imamo sekvencijalnu datoteku koja sadrzi neke slogove. Pp da u jednom bloku u memoriji imamo 2 sloga. Sta ako
hocemo da procitamo 50? Krenemo redom. Nadjemo 50 i ako su uredjeni kljucevi, to je to.
Alternativa-imamo tabelu sa kljucevima i jos dodatno ona ima pokazivac na mesto gdje je taj kljuc u tabeli. Time
dobijamo manje za pretrazivanje. To su indeksi.
Gusti indeksi (dense)-svakom kljucu odgovara pokazivac:
Kluc u indeksu za svaku vrednost u fajlu.

Gusti indeksi sekvencijalna datoteka(blokovi)

10 10
20 20
30
40 30
50 40
60
70 50
80 60
90
100 70
110 80
120
90
100

Retki indeksi (sparse)-kljuc u indeksu za svaki blok u fajlu:

10
10 20
30
50 30
70 40

50
90
60
110
130
70
150
80

90
100
Primer: Trazimo 40, on nadje 50. Sad se vrati na 30 i krene odatle. Dobitak je manje prostora za indekse, ali mora da
bude sortirano po kljucu.

Retki indeksi-drugi nivo (SPARSE 2ND LEVEL INDEKS)

Mi tabelu indeksa pretrazujemo sekvencijalno, pa ako je mnogo velika, to moze da bude problem. Zato mozemo da
organizujemo indekse u dva nivoa. Sad imamo vise koraka ali brze dolazimo do resenja. Ako su tabele male pne
isplati se rad sa indeksima u dva nivoa.

10 10
10
30 20
90
170 50
70 30
250
40
330 90
110 50
410
130 60
490
570 150
70
170 80
190
210 90
230 100

GUSTI PROTIV RIJETKIH INDEKSA

RIJETKI-manje prostora za indekse=> mozemo da imamo vise indeksa u memorij
-bolji su za unos u tabelu
GUSTI-mozemo odmah, bez pristupa fajlu, da vidimo da li slog postoji
-potrebni su za sekundarne indekse

Pojmovi:
-SEARCH KEY(razlicit od PRIMARY KEY)
-PRIMARY INDEX -primarni indeks-definise se nad atributima koji su primarni kljucevi. Sadrzi informaciju gdje
se koji blok fizicki nalazi
SECONDARY INDEKS -sekundarni indeks-definisemo drugi indeks. Recimo da hocemo da pretrazujemo po imenu i
prezimenu. Nad njima pravimo sekundarni indeks i on nam kaze npr. Petar Petrovic u tabeli.
-DENSE INDEKS -gusti indeks
-SPARSE INDEKS -rijetki indeks
-MULTI LEVEL INDEKS
DUPLIRANI KLJUCEVI
Gusti indeksi- jedan nacin Gusti indeksi-drugi nacin
10 10
10 10 10
10
10 10
20 10
20
20
20 30
10
30 20 40
20
30 30
30
30 20
30 30

40 30
50 30
45

40
45
Prvi nacin (svako ima svoj pokazivac)
Drugi nacin (svi isti su uredjeni i imamo pokazivac samo na njihov pocetak)
DUPLIRANI KLJUCEVI

Gusti indeksi- jedan nacin Gusti indeksi-drugi nacin

10 10 10 10
10 10 20 nd 10
20 30 Nije
30 10
dobro
20 10
30?? nd
20
20
30
20
30 30
30
30
40 30
45
40
45

Prvi nacin (imamo pokazivac na pocetak svakog bloka. Sta ako nam treba 20 ili 30? Moramo da idemo i gore i dole.
NE VALJA ?)
Drugi nacin (U indeksu stavimo pokazivac na blok, ali u inddeksu kao kljuc stavljamo noovu vrednost u bloku)
Zakljucak-kod primarnog indeksa indeks pokazuje na prvu instancu svake vrednosti.

a a
a
a
:
:
b
OPERACIJE AZURIRANJA NAD INDEKSIMA
Retki indeksi-BRISANJE
10 10
30 20
50
70 30
40
90
110 50
130 60
150
70
80

Brisemo slog 40. Obrisemo i stavimo da su nevazeci podaci.

10 10
30 20
40
50 30
70 40

Sta ako brisemo slog 30 na koji pokazuje indeks? Trebalo bi da zamenimo pokazivac u indeksu.
10 10
30 20
40
50 30
70 40

Sta ako brisemo i 30 i 40?

10 10
30 20
50
50
70

50
60

70
80
Gusti indeksi-BRISANJE
10 10
20 20
30
40 30
40
50
60 50
70 60
80
70
80

Ako obrisemo slog 30.

10 10
20 20
30
40 30
40

Retki indeksi-UNOS
10 10
30 20
40
60 30

40
50

60

Unosimo 34. Imamo mesta tacno gdje nam treba, pa samo smestimo.
10 10
30 20
40
60 30
34

Sta ako unosimo 15? Menjamo indeks i pomeramo.

10 10
20 20
30 15
40
60 30
20
30

40
50
Ako unosimo 25...

10 10
30 20
40
60 30

40
50

25

Dodamo blok, reorganizujemo posle.

Sta ako nemamo prostora da pomerimo? Ako pokusamo momentalnu reorganizaciju to u praksi ne valja (velike
tabele). Bolje da ubacimo novi blok pa onda na kraju sa jednom komandom reorganizujemo tabelu.

Gusti indeksi-UNOS
Slicno kao kod retkih, samo su znatno skuplji za odrzavanje.

SEKUNDARNI INDEKSI
Preporuka je da se gusti indeksi koriste za sekundarne indekse jer svaki slog ima svoj pokazivac koji moze da
pokazuje bilo gdje, tj slog moze da bude bilo gdje. Ovdje se rijetki indeksi koriste na visem nivou
10 30
10
50 50
20
90
30
... 20
40
70
50
60 80
70 40
...
100
10

90
60

Kod sekundarnih indeksa na najnizem nivou su gusti indeksi, dok su na drugim nivoima retki indeksi. Takodje
pokazivaci pokazuju na slog a ne na blok.
DUPLIRANE VREDNOSTI I SEKUNDARNI INDEKSI:
10 20
10 10
10
20 20
40
20
30 10
40 40
40
10
40 40
40
... 30
40

Drugi nacin je da koristimo medjusloj (buckets (ako postings file ?))

10 20
20 10
30
40 20
40
50
60 10
... 40

10
40

30
40

Zasto je ideja sa medjuslojem korisna?

Primer:
Indeksi Slogovi

NAME: primary
EMP(NAME, DEPT, FLOOR,...)
DEPT: secondary
FLOOR: secondary
Upit: GET EMPLOYEES IN (TOY DEPT) AND (2nd FLOOR)
DEPT INDEKS EMP FLOOR INDEKS

TOY 2nd
Presek TOYBUCKET i 2nd FLOOR BUCKET da bi dobili odgovarajuciset EMP-a. Ova ideja se koristi u pretrazivanju
teksta-tekst information retrieval.
The cat is fat....
cat
...was raining cats and dogs...
dog
...Frido the dog...

-KONVENCIONALNI INDEKSI
-osnovne ideje-rijetki, gusti, uvise nivoa
-duple vrijednosti
-DELETE /INSERT
-sekundarni indeksi
-PREDNOSTI-jednostavni, indeks je sekvencionalna datoteka, dobar za pretrazivace
-MANE-skupo unosenje i moze da se izgubi sekvencijalnost balansiranost
 B drveta

B je od balansirano. B drveta su struktura preko koje se realizuju indeksi. Nisu sekvencijalna, balansirana su.(do
slogova se dolazi putevima iste duzine). Dobra osobina im je da se zbog dizajna struktura sami odrzavaju. B drveta su
zgodna za upis i brisanje podataka. Ovde se u cvorovima nalaze blokovi podataka koji mogu da imaju pokazivace.
Blok se sastoji od najvise n kljuceva, n+1 pokazivaca, a najmanje pola od ovoga.

Primer b drveta:
N=3 => u primeru blok ima najvise 3 kljuca i 4 pokazivaca.

100

30 120 150 180

3 5 11 30 35 100 101 110 120 130 150 156 179 180 200
Listovi

Cvor koji nije list list cvor

120 150 180 120 130 unused

Ka slogu sa kljucem 130

<120 ka slogu sa kljucem 120
120<=k<150 150<=k<180 >=180
k-vrednost u bliku

STRUKTURA-na pocetku je root, sve levo je manje od njega, sve desno je vece ili jednako od njega (kao u gornjem
primeru). Ovako izgleda globalna struktura. Moguci su dodatci. Mozemo da dodajemo pokazivace u levo( []-> ) i u
desno ( []-> ). Cvor koji je list sadrzi pokazivace na slogove i jednu „kucicu“ koja je pokazivac na sledeci list.
Nije dobro da napravimo cvorove koji su previse prazni. Broj pokazivaca u upotrebi je:
-za unutrasnje cvorove najmanje [(n+1)/2] ka deci cvorovima
-za listove najmanje [(n+1)/2] ka slogovima/blokovima

Node<=>cvor
Seanster.com/BplusTree/BplusTree.html

Levo su manji!
Desno su veci!
N=3 full node min node
Cvor 120 150 180 30

List 3 5 11 30 35
PRAVILA ZA B+ DRVETA
1. Svi listovi su na istom najnizem nivou (balansirajuce drvo)
2. Pokazivaci u listovima pokazuju na slogove, osim „seqence pointer“ (oni ulevo)
3. Broj pokazivaca na B+ i kljuceva za B+ drveta

Max pokazivaca Max kljuceva Min pokazivaca Min kljuceva

Cvorovi (ne root) N+1 n [(n+1)/2] [(n+1)/2]
Listovi(ne root) N+1 N [(n+1)/2] [(n+1)/2]
Root N+1 N 2(*) 1

(*)1, ako je samo jedan slog u fajlu

UNOS B+ DRVETA
a) najjednostavniji slucaj- list nije pun=> samo unesemo(kljuc, pokazivac na slog)
unosimo kljuc 32
n=3 100

30

3 5 11
30 31 32

b) slucaj kada je list pun

unosimo kljuc 7, n=3
=> mora da uleti izmedju 5 i 7
=>pravimo novi list i dodajemo gore pokazivac

100

7 30

3 5 3 5 7 11 30 31

Gore smo nismo mogli samo da izbacimo 30 jer on kaze da je levo od njega sve manje=> 7 mora levo, a desno
sve vece.

Razlika izmedju B+ i B drveta: Sustina je da li imaju samo podatke u listovima ili u cvorovima. B+ nema podatke u
cvorovima’.
Svi donji blokovi treba da budu povezani.

c) Slucaj kada je cvor koji nije list pun

Unosima kljuc 160, n=3

100 160

120 150 180 180

150 156 179 160 179 180 200

 d) Slucaj kada imamo novi koren
Unosimo kljuc 45, n=3
Slika 42

Visina raste ka korenu i time se odrzava balansiranost.

BRISANJE IZ B+ DRVETA
a) Najjednostavniji slucaj-no underflow-izbrisemo iz bloka neki podatak tako da broj preostalih podataka u
bloku bude manji od minimalnog. Ovo je slucaj kada se to ne desava , pa samo brisemo bez bilo kakvih
dodatnih promena.
b) Slucaj kada imamo underflow a sused od koga pozajmljujemo nije previse prazan.
N=4 => imamo broj kljuceva u listu [(n+1)/2]=[(n+1)/2]=[5/2]=2
Brisemo 50:

Primer 42

=> zasto pozajmljujemo 35 od bas tog suseda? Pozajmljujemo zato sto je levo. Od desnog ne uzimamo jer ne
znamo sta se tamo nalazi. Vece je, moze da bude bilo sta. Zbog ove pozajmice moramo i gornji cvor da
menjamo

a) b) c) su slucajevi nad listovima

Prvi podatak odredjuje sta je u gornjem cvoru!

c) Kad imamo spajanje cvorova

Brisemo 50,n=4
Slika 43

d) Slucajevi a), b), c) kad ne listovima

N=4 => minimum kljuceva u cvoru koji nije list [(n+1)/2]-1=[5/2]-1=3-1=2
Brisemo 37:

Slika 43
BRISANJE B+ DRVETA U PRAKSI
Cesto spajanje cvorova u praksi nije implementirano. Razlog je sto je komplikovano i nije vredno toga. Takodje kasniji
unosi mogu da vrate cvor na njegovu minimalnu velicinu. Kompromis je da probamo da rasporedimo kljuceve medju
susedima, a ako to nije moguce, da ih ostavimo tu gdje su.

Zasto su B+ drveta dobra?

B drveta se dobro prilagodjavaju unosu i brisanju podataka, zadrzavajuci balansiranost.
-administrator baze podataka ne mora da brine o reorganizaciji
-SPLIT/MERGE operacije su retke
-...
Efikasnost B+ drveta
Primer: pretpostavimo da je velicina bloka 4kb, kljuca 4 byta i pokazivaca 8 bytes. Koliko kljuceva stane u cvor?
(4+n+8*(n+1))B<=4096B
=>2n=340 =>340 kljuceva i 341 pokazivac staje u cvor.
Pretpostavimo da prosecan cvor ima 255 pokazivaca.
-> B drvo na 3 nivoa ima 255^2=65025 listova sa otprilike 255^3 priblizno jednako 16,6 miliona pokazivaca na
slogove
-> ako se blok koji je root nalazi u glavnoj memoriji, svakom slogu se moze pristupiti sa 2+1 disk I/O.
Ako je svih 256 unutrasnjih cvorova u glavnoj memoriji, pristup slogu zahteva 1+1 disk I/O. (256*4kb=1MB)

Primer : dat je niz brojeva. Konstruisati B drvo nad njim. 1,10,4,35,7,3, n=3
Dve varijante:
-sortiramo pa tako radimo drvo
-jedan po jedan se unose
1. 1,10,4,35,7,3
1,3,4,7,10,35
N=3

Slika 44

2. Korak po korak sa sortiranim nizom.

1.
2.
3.

4.

5.
OPTIMIZACIJA
UVOD:
Imamo upit, mozemo da ga napisemo na vise nacina. Nije svaki nacin podjednako efikasan.
Problem—kako izabrati efikasnu strategiju izracunavanja postavljenog upita?
Optimizacija upita predstavlja i izazov i mogucnost u relacionim bazama podataka.
IZAZOV: jer je potrebna radi dostizanja prihvatljivih performansi sistema.
MOGUCNOST: jer ilustruje prednost relacionog pristupa (u odnosu na nerelacione). Za relacione izraze koji su na
dovoljno visokom semantickom nivouoptimizacija se izvodi na samom pocettku obrade(relacije su matematicki
zasnovane, pa mozemo da definisemo pravila na osnovu kojih mozemo da odredimo efikasnost).
Optimizacija se vrsi automatski, bez intervencije korisnika. Program za optimizaciju ce bolje uraditi optimizaciju od
korisnika rel. Sistema.

Razlozi vece efikasnosti automatske optimizacije:

-dobar optimizator ima na raspolaganju staticke informacije iz sistemskog kataloga, npr br vrednosti u svakom
domenu,broj torki u svakom osnovnom relvar-u, trenutni broj razlicitih vrednosti u svakom osnovnom relvar-u,koliko
puta se svaka vrednost javlja u svakom atributu, itd.
-ako se statistika promeni moguce je da je treba prilagoditi, tj izvrsiti reoptimizaciju. Reoptimizacija se vrsi ponovnom
obradomorginalnih zahteva od straneoptimizatora, sto bi bio vrlo redak slucaj rucne optimizacije od strane korisnika.
-optimizator je program i prema samoj definiciji je strpljiviji od coveka. On je, u odnosu na coveka, sposoban da
pregleda stotine razlicitih strategija pristupa za dati upit.
-optimizatoru su ukljucene vestine i znanje “najboljih “ ljudskih programera. Posledica je d asu te osobine svima na
raspolaganju.
Primer:
Prikazati imena studenata koji su polagali ispit PBP (id_predmeta=101)
((DOSIJE JOIN ISPIT)
WHERE id_predmeta(101)) {ime}
Neka baza sadrzi 100 studenata i podatke o 10000 ispita od kojih se 50 odnosi na predmet PBP. Neka se dosije i ispit
nalaze direktno na disku, svaki relvar u jednoj datoteci sa jednom torkom u jednom slogu. Za kriterijum efikasnosti
uzecemo borj citnaj i pisanja na disku, tj broj U/I operacija.

STRATEGIJE IZRACUNAVANJA:
1. DIREKTNA:
-izvrsiti spajanje DOSIJE i ISPIT(preko indeks)-cita se 10 000 ispita za svakog od 100 studenata. Medjurezultat
se sastoji od 10000 spojenih torki koje se pisu natrag na disk(jer memorija nije dovoljno velika da ih primi)
-vrsi se restauracija rezultata iz prethodnog koraka na torke koje sadrze 101-cita se ponovo 10 000 torki sa
diska. Rezultat je 50 torki koje mogu da ostanu u memoriji.
-projektuje se rezultat iz prethodnog koraka preko IME-najvise 50 torki koje ostaju u memoriji.
2. SA OPTIMIZACIJOM:
-izvrsiti restrikciju na torke koje sadrze 101-cita se 10 000 ispit. Medjurezultat se sastoji od 50 torki koje
ostaju u memoriji.
-spojiti rezultate sa prethodnog koraka sa DOSIJE (preko indeks)-cita se 100 studenata , dobijeni rezultat ima
50 torki koje ostaju u memoriji.
-projektuju se rezultati iz prethodnog koraka preko IME-najvise 50 torki koje ostaju u memoriji.

Prvi pristup ima ukupno 1 030 000 U/I torki, dok drugi ima samo 10 100. Razlika u duzini izvrsavanja je ocigledna-
drugi pristup daje oko 100 puta brze izracunavanje. Moguca se i dalja poboljsanja, npr, ako se atributi indeksiraju
(npr id_predmeta).
Staticki SQL je brzi od dinamickog jer samo jednom predje, a dinamicki mora svaki put ponovo.
FAZE OBRADE UPITA:
U obradi upita se mogu identifikovati 4 osnovne faze:
-Prevodjenje upita na interni zapis
-Konverzija upita u kanonickiu oblik
-Izbor kandidata za procedure niskog nivoa
-Formiranje planova upita i izbor najjeftinije

Source query

DHL Proccessor Parsing, view, processing, translating

CATALOG

Relational algebra expression

Compiled query

METADATA OPTIMIZER Expression transformation, cost estimation,..

Optimized plan
Query plan
DATABASE

Run-time manager execution

data

result

FAZA1-PREVODJENJE UPITA NA INTERNI ZAPIS:

Pocetni upit se prevodi u internu reprezentaciju koja je najpogodnija za obradu u racunaru. Obicno se koristi drvo
upita ili drvo apstrakten sintakse. Za nase potrebe biramo najpogodniji formalizam za predstavljanje upita, npr:
relacionu algebru ((DOSIJE JOIN ISPIT ) WHERE id_predmeta(101)){ime}
Drvo upita
REZULTAT
|
PROJEKCIJA (ime)
|
RESTRIKCIJA(id_predmeta=101)
|
SPAJANJE(ispit.indeks=dosije.indeks)
/\
ISPIT DOSIJE
FAZA2- KONVERZIJA UPITA U KANONSKI OBLIK
U ovoj fazi optimizator obavlja operacije za koje postoji garancija da su dobre, bez obzira kakvi su podaci i koja baza u
pitanju. Npr: SQL upit je moguce zapisati na vise nacina koj epre dalje obrade treba dovesti na ekvivalentan kanonski
oblik koji je mnogo efikasniji. Za konverziju upita u kanonski oblik optimizator koristi razlicita pravila za
transformaciju. Dva upita q1 i q2 su ekvivalentni akko se pri njihovom izvrsavanju, u svim slucajevima, dobijaju isti
rezultati.
Kanonski oblik(definicija): za podskup C datog skupa upita Q se kaze da je u kanonskoj formi za Q akko je svaki upit q
iz Q ekvivalentan nekom upitu iz C.Upit c predstavlja kanonicki oblik upita q.
Posledica-sve „korisne“ osobine koje mogu da se primjene na upit q vaze i za upit c. Zbog toga je dovoljno da se
razmatra manji skup upita C umijesto veceg Q da bi se dobili razliciti „korisni “ rezultati.

FAZA3- IZBOR KANDIDATA ZA PROCEDURE NISKOG NIVOA

Poslije konverzije i predstavljanja u kanonskom obliku optimizator mora sa odluci na koji nacin ce izvrsavati
transformisani upit. Osnovna strategija je posmatranje izraza koji predstavlja upit kao niz operacija niskog
nivoa(spajanje, projekcija, restrikcija,...) izmedju kojih postoje odredjene zavisnosti npr. Projekcija obicnih zahtjeva
da ulazne torke budu sortirane sto znaci da rezultat prethodne operacije treba da bude sortiran.
Optimizator razmatra postojanje indeksa, postojenje pristupnih puteva, fizicku distribuciju podataka,...
Za svaku od operacija niskog nivoa optimizatop ima na raspolaganju skup predefinisanih procedura za njihovu
implementaciju. Svaka procedura ima pridruzenu (parametrizovanu) formulu za odredjivanje cene kostanja, obicno u
zavisnosti od U/I operacija na disku, CPU vremena, velicine medjurezultata,...
Na osnovu informacija iz kataloga o tekucem stanju baze i medjusobnih zavisnosti operacija niskog nivoa optimiyator
bira jednu ili vise procedura za implementaciju svake od operacija niskog nivoa.

FAZA4-FORMIRANJE PLANOVA UPITA I IZBOR NAJJEFTINIJEG

Formira se skup kandidata na PLAN upita izmedju kojih se bira najbolji (najjeftiniji). Svaki plan ne kombinacija
kandidata za implementaciju procedura niskog nivoa.
Cena upita je jdenaka zbiru cijena pojedinacnih upita procedura. Problem je odredjivanje cijene upita jer formule
zavise od velicine relacija koje se obradjuju.
Svi sem najjednostavnijih upita ukljucuju formiranje medjurezultata pri izvrsavanju tako da najveci dio parametra
nije unaprijed poznat. Zbog toga optimizator pravi procjene cijene kostanja upita.Primjer procjene-VISUAL EXPLAIN U
DB2

TRANSFORMACIJA IZRAZA:
Restrikcija i projekcija
1. (A where restrikcija1 )where restrikcija2
Je ekvivalentno sa
A where restrikcija1 and restrikcija2
2. Kod niza projekcija nad istom relacijom ignorisu se sve sem poslednje
(A{atribu1t}) {atribut2} <=> A{atribut2}
3. Restrikcija projekcije se moze transformisati u projekciju restrikcija
(A{atribut}) where restrikcija <=> (A where restrikcija){atribut}
Primedba: U opstem slucaju je dobro primeniti restrikciju pre projekcije jer se time smanjuje velicina ulaza u
projekciju cime se smanjuje velicina podataka koje treba sortirati radi eliminisanja dupolikata.
Distribucija:
-za unarni operator f se kaze da je distributivan preko binarnog operatora o akko f(AoB)= f(A) o f(B)
-restrikcija je distributivna preko unije presjeka i razlike, preko spajanja akko se uslov restrikcije sastoji od
najvise dva odvojena uslova restrikcije koja su spojena konjukcijom (AND), jedan za svaki operand u spajanju.
-projekcija je distributivna
-preko unije i presjeka
(A UNION B){C}=A{C} UNION B{C}
(A INTERSECT B){C}= A{C} INTERSECT B{C}
-ne i preko razlike
-preko spajanja
(A JOIN B){C}=(A{AC} JOIN B{BC})
Akko
–AC je unija
a)atributa koji su zajednicki za A i B
b)onih atributa c koji se pojavljuju samo u A
-BC je unija
a)atributa koji su zajednicki za A i B
b)onih atributa c koji se pojavljuju samo u B

Komutativnost:
-binarni operator o je komutativan akko vazi AoB=BoA
-unija, presek i spajanje su komutativni. Razlika i deljenje nisu.
-posledica-ako upit ukljucuje spajanje dvije relacije A i B komutacija omogucuje da se „manja“ relacija uzima
za spoljasnju

Idempotencija:
-binarni operator o je idempotentan akko vazi AoA=A
-unija, presek i spajanje su idempotentni. Razlika i deljenje nisu.
-osobina idempotencije moze da bude korisna u transformaciji izraza

Skalarni izracunljivi izrazi:

-optimizator mora d avodi racuna i o transformacijama aritmetickih izraza npr komutacija, asocijacija,
distribucija, jer na ovaj tip izraza moze da se naidje u kontekstu operatora extend i summarize.

Logicki izrazi:
-npr. Izraz A> B AND B>A se moze, po osnovu tranzitivnosti operatora>, transformisati u izraz A>B AND B>3
AND A>3. Transformacija je korisna jer omogucuje dodatnu restrikciju na A prije izvodjenja spajanja(sa >).
Ideja izvodjenja ranije restrikcije je pogodna i primjenjuje je vise komercijalnih produkata.
Izraz A>B OR (C=D AND E<F) se moze transformisati u
(A>B OR C=D) AND (A>B OR E<F)
-Svaki log izraz se moze transformisati u ekvivalentan izraz u konjuktivno normalnoj formi(KNF)
KNF je oblika c1 AND c2 AND...AND cn, pri cemu ni jedan od izraza ci ne sadrzi konjukciju(and).
Prednost KNF-a je sto je izraz tacan ako su svi konjukti tacni, a netacan ako je bar jedan od njh netacan. Kako
je konjukcija komutativnaoptimizacija moze da bira redoslijed izvrsavanja konjukta od jednostavnijih ka
slozenim. Knf je pogodan kod sistema sa paralelnom obradom.
Semanticke transformacije:
-u izrazu (SP JOIN S){PRBR} spajanje se vrsi uparivanjem spoljasnjeg kljuca(sa jedne strane) i kandidata za
kljuc sa druge strane.odatle slijedi da se svaka torka iz SP spaja sa nekom torkom iz S i da zbog toga svaka
torka iz SP daje neko PRBR u krajnjem rezultatu. Odavde se vidi da nema potrebe za spajanjem i da izraz
moze biti uproscen u SP{PRBR}.
-ova transformacija, iako je zancajna, rijetko se srece kod komercijalnih sistema zbog slozenosti.

Statistika u bazi podataka:

Faze 3 i 4 procesa optimizacije koriste statistiku baze podataka koja se cuva u katalogu
-statistika o osnovnim tabelama
-statistika o svakoj koloni u osnovnoj tabeli
-statistika o indeksima
Statistika se ne skuplja automatski, vec na zahtjev korisnika-RUNSTATS (naredba u DB2)

Implementacija operatora spajanja: OVO SU ONI JOINI

U najvecem broju slucajeva sistem ima potrebu da vrsi grupisanje torka prema zajednickim vrijednostima u
odredjenim atributima. Za grupisanje se koriste razlicite tehnike.
Npr: za spajanje:
-gruba sila(brute force) u kojoj se prave sve moguce kombinacije torki u spajanju
-pomocu indeksa koji se koristi za direktan pristup uparenim torkama unutrasnje relacije spajanja
-pomocu hesa koji se kristi umijesto indeksa za direktan pristup uparenim torkama unutrasnje relacije
spajanja
-mijesanjem relacija koje su fizicki sacuvane u redoslijedu atributa po kome se spajaju
-hes tehnika koja omogucuje jedan prolaz kroz obje relacije koje se spajaju
-kombinacija ovih tehnika
OPTIMIZACIJA U DB2:
SQL upit u DB2 je skup „SELECT – FROM-WHERE“ blokova. Bira se redoslijed blokova, pri cemu se u slucaju
ugnjezdenih blokova prvo optimizuje onaj koji je na najvecoj dubini(naj unutrasnji blok). Statisticke informacije se
koriste iz kataloga.
EXPLAIN-alat za procijenu cijen upita
U DB2 postoji 7 nivoa optimizacije:
-0 -najmanji nivo optimizacije
-1 -koristi nivo optimizacije kao DB2(6000 vresion1 i jos neke dodatne stvari sa niskom cijenom kojih nema kod
version1)
-2 -koristi isto sto i nivo 5, ali ima jednostavniji JOIN algoritam
-3 -izvidi moderate kolicinu optimizacije, slicno osobinama optimizacije upita kod DB2 za Z/OS
-5 -koristi znacajnu kolicinu optimizacije sa heuristic rules podrazumijevan nivo optimizacije
-7 -koristi znacajnu kolicinu optimizacije bez heuristic rules
-9 -koristi sve dostupne tehnike optimizacije

Korisnik DB2 UDB na raspolaganju ima Visual Explain-alat za procjenu sa grafickim interfejsom. Procedura koriscenja
je:
-u DB2 CLP uci u direktorijum ..\DB2\SQLLIB\MISC
-DB2 CONNECT TO ime_baze_za_koju_zelite_procenu
-DB2 –t –f EXPLAIN.DDL
-u DB2 control center-u odabrati bazu, desni klik i opcija EXPLAIN SQL
-unijeti upit za koji se zeli procijena

Alternativa-odraditi Explain query iz control center-a.

TABLE SCAN je citanje red po red – tu se trazi sansa za optimizaciju (kod dijagama kod upita).

NOVO
U data studiju idemo desni klik na upit pa FORMAT SQL-da formatira(lijepo napise) upit.

START TUNING-postoji program koji provjerava nas upit i pravi semu koja se nalazi u ovim paketima. To upisuje u
posebne tabele u bazi. Dobijamo poruku da prvi put to ne postoji u bazi. Treba da izvrsimo EXPLAIN.DDL, pa
ponovimo komandu START TUNING.

Sad nam otvara QUERY TUNER WORKFLOW ASSISTANT

Ideja je kako mozemo da dobijemo neka uputstva da napisemo optimalne upite.

EXPLAIN opcije
-nivo izolacije kursora
-ko odrzava baze
-nivo optimizacije
-tekuci put
-CURRENT DEGREE-trenutni nivo paralelizacije
-statistika-da li da skuplja ili ne

Sad idemo na SELECT WHAT TO ROW pa SELECT ALL pa OK-izbaci nam izvjestaj.
Moze da se desi da tabele nemaju statistiku pa na RUNSTATS pa ponovimo TUNING
INVOKE/SINGLE QUERY/SET ADVISOR OPTIONS -?
Kako da napisemo upite da bi bili efikasniji:
-SELECT * ne stavljati ako nam ne trebaju sve kolone(mogu biti jako velike)
-voditi racuna o velicini podatak(short u short)
-ne ostavljati sistemu da radi implicitnu konverziju
-ako imamo nesto sto se rijesava podupitom, efikasnije je da to uradimo preko spajanja(biramo spajanje)
-UNION ALL ne zahtjeva sortiranje da eliminise duple slogove. Ako ti duplikati ne uticu na rezultat treba koristiti
UNION ALL(UNION radi i sortiranje)
-Koristi najmanji moguci nivo izolacije
-naglasi FOR READ ONLY pristup
-navedi for UPDATE OF- vezano za kursore. Ukoliko prilikom prevodjenja navedemo opciju da ide po DB2 onda
mozemo da azuriramo samo one kolone koje su navedene u for update of, a ukoliko stavimo da bude po standardu-
sve kolone
-izbjegavati DISTINCT ili ORDER BY ako nisu neophodni
-za gledanje da li slogovi postoje izbjegavati SELECT COUNT(*) FROM
-kad spajamo tabele provjeriti po cemu spajamo(treba po kljucevima)
-koristiti FETCH FIRST kROWS ONLY(ako zelimo da vidimo kako nesto izgleda, a ne SELECT *)
-koristiti WITH sa nivoom izolacije

Reoptimizacija SQL-a: REOPT BIND OPCIJA;

OPORAVAK
Oporavak baze znaci vracanej baze u korektno stanje poslije gresku ili pada sistema. Princip na kome je oporavak
zasnovan je postojanje redundantnih podataka na fizickom nivou.
Najznacajnije greske:
-GRESKA prilikom unosa-neke greske u podacima je nemoguce detektovati. Npr. Ako prilikom unosa broja telefona
pogrijesimo jednu cifru, to je i dalje broj telefona. Sa druge strane ako se unese cifra manje, to onda vise nije broj
telefona. Ovo se rijesava pisanjem ogranicenja i trigera.
-MEDIA FAILURES-nastaju uslijed fizickog ostecenja medija(diskova) na kojima se nalazi baza. Zovu se jod i hard
crash-es.ovdje je rijesenje da cuvamo arhivsku kopiju baze ili da imamo vise kopija baze na razlicitim mijestima.
-SYSTEM FAILURES-svaka transakcija ima stanje koje predstavlja sta se u njoj do sada desilo. Stanje ukljucuje koji se
kod u transakciji trnutno izvrsava i vrijednosti lokalnih promijenljivih koje ce biti kasnije potrebne. SYSTEM FAILURES
su problemi koji dovode do gubitka stanja transakcije. To su obicno nestanak struje i softverske greske. Ovi problemi
uzrokuju da se izgubi sadrzaj glavne memorije, pa samim tim i rezultati trensakcije, tj. Stanje transakcije. Ovo se
rijesava odrzavanjem logova.

TRANSAKCIJE-uopsteno , COMMIT, ROLLBACK ACID,...

Kako transakcija komunicira sa bazom – postoje tri adresna prostora koja su bitna:
1. Prostor blokova na disku u kome se nalaze elementi baze
2. Adresni prostor virtuelne ili glavne memorije kojim upravlja buffer manager
3. Lokalni adresni prostor transakcije

Da bi transakciija procitala element baze, taj element mora da bude u baferu glavne memorije. Kada je u baferu,
onda transakcija moze da ga procita i smijesti svoj adresni prostor. Kada transakcija pise vrijednost u bazu redoslijed
je obrnut. Notacija koja ovo opisuje:
1. INPUT (X)-kopira blok sa diska u bafer
2. READ(X,t)- kopira element baze X u lokalnu promijenljivu t transakcije. Ako blok u kome se nalazi X nije u
baferu prvo se izvrsava INPUT(X)
3. WRITE(X, t)-kopira vrijednost lok. Promijenljive t u element baze X u baferu. Ako X nije u baferu onda se prvo
izvrsava INPUT(X)
4. OUTPUT(X)-kopira blok koji sadrzi X iz bafera na disk. Da bi logovanje radilo pisanje X-a mora da bude
atomsko.

UNDO LOGGING:
Log je fajl koji govori sta je neka transakcija uradila.

UNDO LOGGING vrsi oporavak baze tako sto ponistava efekte transakcije koje se nisu zavrsile prije pada(greske).
Dok se transakcija izvrsava log manager je zaduzen da u log smjesti svaki vazan dogadjaj. U log se upisuje sledece:
1. <START T> oznacava da je transakcija pocela
2. <COMMIT T> transakcije t se zavrsila uspijesno i nece vise mijenjati elemente baze. Sve promjene koje je
napravila t treba da se pojave na disku. Medjutim, posto ne mozemo da kontrolisemo kada ce buffer
manager odluciti da kopira blok iz memorije na disk, ne mozemo biti sigurni da su promijene zaista na disku
kada vidimo <COMMIT T>. Ako insistiramo da promjene budu na disku to mora.... (str 852)
3. <ABORT T> transakcija T nije zavrsena uspjesno. Njene promjene ne smiju da budu na disku. Posao je
transaction manager-a da te promijenje nikad ne budu na disku.
<T,X,v> -znacenje ovog zapisa je transakcija T je promijenila element baze X i njegova stara vrijednost je v.
Undo log ne cuva novu vrijednost elementa baze vec staru.
UNDO LOGGING PRAVILA:
U1. Ako transakcija T mijenja element baze X onda log zapis <T,X,v> mora biti napisan na disk prije nego sto se nova
vrijednost X-a zapise na disk.
U2. Ako transakcija posalje COMMIT, onda njen zapis COMMIT-a u logu mora da bude napisan na disku nakom sto se
na disk zapisu svi elementi baze koje je mijenjala ta transkacija.

Kada sumiramo ova pravila dobijamo da se podaci vezani sa transakcijom zapisuju na disk u sledecem redoslijedu:
1. Lof zapisi o mijenjanim elementima
2. Mijenjani elemeti baze
3. Zapis COMMIT-a u log
Da bi poslao log zapise na disk log manager koristi FLUSH –LOG komandu koja kaze buffer manager-u da na disk
kopira sve log blokove kaji nisu do tada kopirani na disk, ili mijenjani od kad su poslednji put kreirani.

OPORAVAK KORISTENJEM LOGGING-a

Prvi zadatak jrecovery manager-a je da podijeli transakcije na one koje jesu i one koje nisu uspijesno zavrsile . ako u
log-u imamo <COMMIT T> onda je po pravilu U2 T ima zapisane sve promijene na disku, tako da T nije mogla da
dovede bazu u nekonzistentno stanje koje je dovelo do greske.
Ukoliko naidjemo na <START T> ali ne i na <COMMIT T> u logu, to znaci da neke promijene koje je T napravila mogu
biti na disku, a druge ne. U ovom slucaju promijene koje je T napravila moraju biti ponistene. Zbog pravila U1 mi na
disku imamo <T,X, v> u logu, tako da tokom oporavka pisemo vrijednost v u element baze X.
Recovery manager skenira log od kraja(od najskorije do najranijeg zapisa) i pamti sve transakcije. T za koje je video
<COMMIT T> ili <ABORT T>. Dok prolazi kroz log, kada vidi <T,X,v>
-ako je za T video COMMIT ne radi nista. T je uspijesno zavrsila i njene promijne se ne ponistavaju
-inace T je nezavrsena transakcija ili prekinuta transakcija. Tada recovery manager mora da promijeni
vrijednost X-a u bazi na vrijednost v.
Nakon ovih promjena recovery manager mora da u log upise <ABORT T> za svaku nezavrsenu transakciju T koja nije
prethodno stonirana i odradi flush log. Sada moze da se nastavi normalan rad sa bazom.

CHECKPOINTING
Oporavak zahtijeva da se ispita cijeli log. Kod UNDO LOGGINGA tada transakcija ima zapisano COMMIT u logu na
disku njeni unosi u log nam vise nisu potrebni tokom oporavka. Ako smanjimo log posto se jedna transakcija
uspijesno zavrsila unosi u log drugih transakcija mogu biri izgubljeni. Najjednostavnije rijesenje je periodicno
postavljanje checkpoint-a u log. Kod jednostavnog checkpoint-a:
1. Ne prihvatamo nove transakcije
2. Cekamo da sve aktivne transakcije posalju COMMIT ili ABORT i to upisemo u log
3. Snimimo log na disk
4. U log upisemo <CKPT> i ponovo snimimo log na disk
5. Nastavimo da prihvatamo nove transakcije
NONQUIESCENT CHECKPOINTING
Problem kod prethodne tehnike za checkpoint je sto sistem prestaje sa radom dok se pravi checkpoint. Zato se
koristi tehnika nonquiescent checkpointing koja dozvoljava novim transakcijama da udju u sistem dok se radi
checkpoint. Koraci:
1. U log upisi <START CKPT(T1,....Tk)> i snimi log na disk. T1,...Tk su sve jos uvijek aktivne transakcije.
2. Sacekaj dok sve T1,...Tk ne posalju COMMIT ili ABORT, ali nemoj da zabranjujes ostalim transakcijama da
pocnu.
3. Kada su sve T1,...Tk zavrsene upisi u log<END SKPT> i snimi log na disk

Ovdje je oporavak sledeci. Pretrazujemo log od kraja i trazimo sve nezavrsene transakcije i vracamo stare vrijednosti
u bazi elemenata koje su mijenjane. Imamo 2 slucaja:
1. Ako u logu prvo naidjemo na <END CKPT> tada zanmo da su sve nezavrsene transakcije pocele poslije
prethodnog <START CKPT(T1,...,Tk)>. Zato idemo do sledeceg <START CKPT> i stajemo. Prethodni log moze
sada biti obrisan.
2. Ako prvo naidjemo na <START CKPT(T1,...,Tk)> onda se greska desila za vrijeme checkpointa. Medjutim
jedine nezavrsene transakcije su one na koje smo naisli prije START CKPT i onr od T1,...,Tk koje se nisu
zavrsile. Sada nema potrebe da pretrazujemo dalje od pocetka najranije nezavrsene transakcije.

REDO LOGGING
UNDO LOGGING ima potencijalni problem da ne mozemo da commitujemo transakciju baz da prvo zapisemo sve
njene promjene na disk. Ponekad mozemo da smanjimo broj U/I operacija ako dozvolimo promjenama baze da
ostanu u glavnoj memoriji neko vrijeme. Dok god imamo log za oporavak u slucjau greske, ovaj pristup je bezbjedan.
Glavne razlike izmedju UNDO i REDO logginga su:
1. undo logging ponistava efekte nezavrsenih transakcija i ignorise one uspijesno zavrsene tokom oporavka;
redo logging ignorise nezavrsene i ponavlja promijene koje su uradile COMMIT ovane transakcije.
2. Undo logging zahtjeva da zapisemo promjene u bazi na disku prije nego sto COMMIT iz njega zapisemo na
disk; redo logging zahtjeva da prvo zapisemo COMMIT iz loga na disk prije nego sto ostale promjene u bazi
dospiju na disk.
3. Kod undo logginga cuvamo stare vrijednosti iz baze; kod redo cuvamo neke vrijednosti

REDO LOGGING PRAVILA

<T,X ,v> transakcija T je napisala novu vrijednost v za element baze X. Svaki put kada T modifikuje element X u bazi,
u log mora da se upise <T, X, v>
Redo pravilo= WAL – write ahead logging pravilo
R1: prije promjene elementa X u bazi, neophodno je da se u log upisu sve informacije koje imaju veze sa tom
promjenom i da se to nadje na disku, ukljucujuci i <T,X,v> i <COMMIT T>

Kada se koristi redo logging redoslijed zapisa podataka vezanih za transakciju na disk je;
1. Log zapisi koji govore o promjenama elemenata baze
2. Zapis COMMIT-a u logu
3. Sami promjenjeni elementi baze
OPORAVAK KORISTENJEM REDO LOGGING-a
Vazna posledica redo pravila je R1-ukoliko u logu nije uklonjen <COMMIT T> znamo da promjene nad bazom od
strane T nisu zapisane na disku, tako da T mozemo da posmatramo kao da se nikad nije ni dogodila. Problem su one
koje imaju COMMIT jer ne znamo koja je stigla da zapise promjene na disk. Zbog toga ovdje cuvamo nove vrijednosti.
Postupak oporavka kod redo logginga je:
1. Identifikuj transakcije koje imaju COMMIT
2. Pretrazi log unaprijed krenuvsi od pocetka. Za svaki zapis <T,X,v>
-ako T nije zavrsena transakcija, ne radi nista
-ako je T COMMIT-ovana, zapisi vrijednost v za element baze X
3. Za svaku nezavrsenu transakciju T u log zapisi <ABORT T> i uradi flush log.

CHECKPOINTING A REDO LOG

S obzirom da promjene u bazi koje je nacinila transakcija koja se zavrsila COMMIT-om mogu da budu kopiranje na
disk dosta kasnije u odnosu na to kad je odradjen COMMIT, ne mozemo samo da se ogranicimo na one transakcije
koje su bile aktivne kada je napravljen CHECKPOINT. Izmedju starta i kraja checkpointamoramo na disk da upisemo
sve promjene baze na disk. Da bi to uradili bafer manager mora da vodi racuna o baferima koji su mijenjani ali nisu
zapisani nadisk. Takodje bi trebalo da znamo koja transakcija je mijenjala koji bafer. S druge strane ili mozemo da
zavrsimo checkpoint bez cekanja da se aktivne transakcije zavrse jer nemaju dozvolu da tada pisu svoje promjene na
disk. Koraci:
1. U log zapisi <START CKPT (T1,...,Tk)> gdje su T1,...,Tk sve aktivne transakcije i snimi log na disk.
2. Zapisi na disk sve elemente baze koji su u baferui koje su mijenjane transakij. Koje su uspijesno zavrsile prije
upisa START CKPT u log
3. U log zapisi < END CKPT > i snimi log na disk

OPORAVAK KORISCENJEM CHECKPOINTED REDO LOG-a

Imamo dva slucaja:
1. Ako je poslednji checkpoint unos u log < END CKPT >. Znamo da su sve promjene transak. Koje su uspjesno
zavrsene prije < START CKPT (T1,...Tk)> zapisale svoje promjene na disk i o njima ne moramo da brinemo.
Medjutim sve one koje su medju Ti ili su jos aktivne od ranije jos uvijek imaju promjene koje nisu napisali na
disk iako su zavrsili sa COMMIT-om. Zato vrsimo oporavak kao sa 76 ali nasu paznju usmjeravamo na
transakciju. Te ili one koje su pocele prije START CKP i pojavile se kao zavrsene poslije. Kad pretrazujemo log
ne idemo ranije od najranijeg unosa <START T2>.
2. Ako je poslednji checkpoint unos u log < START CKPT (T1,...Tk)>. Ne mozemo biti sigurni da su transakcije
vezane za ovaj checkpoint zapisane promjene na disk. Zato trazimo unazad do prethodnog <END CHECKPT>,
zatim nadjemo njemu odgovarajuci < START CKPT (S1,...Sk)> i ponovimo sve COMMIT-ovane transakcije koje
su pocele poslije tog START CKPT ili su medju Si.

Posto transakcije mogu da budu aktivne kroz vise checkpoint-a zgodno je da u < START CKPT (T1,...Tk)> ne cuvamo
samo njihova imena, vec i pokazivace na mijesto u log-u gdje su startovale sa izvrsavanjem. Time znamo da je ranije
dijelove loga bezbijedno da obrisemo.

UNDO/REDO LOGGING
Undo logging zahtjeva da podaci budu zapisani na disk odmah po zavrsetku transakcije, sto moze dovesti do
povecanja broja U/I operacija.
Redo logging zahtjeva da drzimo sve modifikovane blokove u baferu dok transakcija ne zavrsi i log se ne zapise na
disk, sto mozwe dovesti do povecanja broja bafera potrebnih za transakciju.
I undo i redo logovi mogu da stave kontradiktorne zahtjeve na upravljanje baferima za vrijeme checkpoint-a, ukoliko
elementi baze nisu cijeli blokovi. Na primjer:ako bafer sadrzi jedan element baze A koja je promijenila transakciju
koja jos nije odradila COMMIT. Sada zbog A moramo da kopiramo blok na disk, ali zbog B i pravila R!1, to ne
smijemo.
UNDO/REDO PRAVILA
<T,X,v,w> transakcija T mijenja vrijednost elementa baze X, njegova stara vrijednost je v, a nova vrijednost je w
Pravilo:
UR1: prije mijenjanja elementa beze X na disku, zbog promijena koje je napravila transakcija T neophodno je da se
u log upise <T,X,v,w> i to snimi na disk.

OPORAVAK KORISTENJEM UNDO/REDO LOGGINGA

U logu imamo informaciju da li cemo da napisemo transakciju T vracajuci staru vrijednost elementima baze, ili da
ponovimo T ponavljajuci promjene koje je napravila.

UNDO/REDO OPORAVAK
1. Ponovi (REDO)- sve transakcije koje su zavrsile COMMIT –om u redoslijedu najranija-poslednja
2. Ponisti (UNDO)-sve nezavrsene transakcije u redoslijedu poslednja-prva

CHECKPOINTING UNDO/REDO LOG

1. U log upisi < START CKPT (T1,...Tk)>, gdje su T1,...Tk sve aktivne transakcije i snimi log na disk
2. Na disk zapisi sve „prljave “ bafere(sadrze promijenjene elemente baza). Za razliku od redo logginga na disk
snimamo sve „prljave “ bafere, ne samo one u koje su pisale COMMIT-ovane transakcije
3. U log upisi <END CKPT> i snimi log na disk
Jedini zahtjev je da transakcija ne smije da pise nista(cak ni u bafer) dok nije sigurna da nece biti prekinuta(abort).

ZASTITA PROTIV MEDIA FAILURES

Log nas stiti od sistem failures, gde nista sa diska nije izgubljeno, vec su iz memorije izgubljeni privremani podaci. Za
oporavak baze od fizickih ostecenja disak potreban je sistem arhiviranja.

ARHIVA
ARIVIRANJE-odrzavanja kopije baze koja je razdvojena od same baze. Ukoliko je moguce da ugasimo bazu na neko
vrijeme mogli bismo da napravimo kopiju za backup na nekom drugom mjestu. Da bismo vratili bazu tokom
oporavka mozemo da koristimo log, a da bismo sprijecili da se izgubi mi njega mozemo da presnimimo cim se kreira
na neko udaljeno mjesto.posto je pisanje veliki proces pokusavamo da izbjegnemo kopiranje cijele baze, u svakom
arhivskom koraku tako da ima dva nivoa arhiviranja:
1. FUL DUMP- gdje se kopira cijela baza
2. UNCREMENTAL DUMP- gdje se kopiraju samo oni dijelovi baze koji su promijenjeni poslije prethodnog
uzimanja kopije baze

NONQUIESCENT ARCHIVING
Problem sa jednostavnim nacinom arhiviranja je da vecina baza ne moze da bude iskljucena period vremena koji je
potreban da se napravi njihova kopija , ovo omogucava da pokusa da napravi kopiju baze koja je postojana kada je
dump zapoceo, ali nesto u medjuvremenu mogu da se promijene mnogi elementi baze, neophodno je da prilikom
oporavka baze koristimo log gdje su zapisane promjene nastale nad bazom za vrijeme uzimanja kopije.
NONQUIESCENT DUMP kopira elemente baze u fiksiranom redoslijedu i moguce je da se ti elementi promjene od
strane transakcije. Kao rezultat vrijednost elementa koji se kreira moze da bude promjenjen u odnosu na onu koja je
bila kad je dump poceo. Dokle god imamo log dok traje dump ovo nije problem jer se neslaganje vrijednosti
elemenata baze mogu ispraviti koristenjem loga
1. Uzeti bazu iz arhive
-pronaci poslednji full dump i iz njegaa rekonstruisati bazu
-ako je bilo kasnijih incremental dumps, azuriraj bazu sa njima pocevsi od najranijeg
2. Azuriraj bazu koristeci log. Koristi istog oporavka koji odgovara log metodu koji se koristi.
B DRVETA (neki zadatak)
Blok se sastoji od najvise n kljuceva , n+1 pokazivaca, a najmanje pola od ovoga.
Broj pokazivaca u upotrebi je:
-za unutrasnje cvorove najmanje[(n+1)/2] ka dijeci cvorovima
-za listove najmanje [(n+1)/2] ka slogovima/blokovima

Razlika izmedju B+ i B drveta-sustina je da imaju samo podatke u listovima ili u cvorovima. B+ nema podatke u
cvorovima.

B DRVETA primjer:
Pretpostavimo da je velicina bloka 4 kb, kljuca 4 byta i pokazivaca 8 bytes. Koliko pokazivaca i kljuceva staje u cvor?
(4+n+8*(n+1))B<=4096B
=>
N=340 => 340kljuceva i 341 pokazivac staje u cvor

Pretpostavimo da prosjecan cvor ima 255 pokazivaca

-B drvo na 3 nivoa ima 255^2=65025 listova sa otprilike 255^3=16,6 miliona pokazivaca na slogove
-ako se blok koji je root nalazi u glavnoj mem, svakom slogu se moze pristupiti sa 2+1 disk I/O. Ako je svih 256
unutrasnjih cvorova u glavnoj mem, pristup slogu zahtjeva 1+1 disk I/O
(256*4KB=1MB)

ARIES ALGORITAM

In computer science, Algorithms for Recovery and Isolation Exploiting Semantics, or ARIES is a
recovery algorithm designed to work with a no-force, steal database approach; it is used by IBM DB2, Microsoft SQL
Server and many other database systems.

Three main principles lie behind ARIES

 Write ahead logging: Any change to an object is first recorded in the log, and the log must be written to stable storage
before changes to the object are written to disk.

 Repeating history during Redo: On restart after a crash, ARIES retraces the actions of a database before the crash and
brings the system back to the exact state that it was in before the crash. Then it undoes the transactions still active at
crash time.

 Logging changes during Undo: Changes made to the database while undoing transactions are logged to ensure such
an action isn't repeated in the event of repeated restarts.

Arhivski vs cirkularni log

DB2 UDB has two types of logging available - circular and archive logging.
Circular logging
Circular logging is the default logging strategy used for a database. In this strategy, once the last primary log file is
filled in the log directory, new transactions will be written to the first log file thereby overwriting existing log data.
These new transactions will continue to overwrite each old log file in sequence. This method of logging ensures data
consistency for all committed transactions so that crash recovery is possible.
Circular logging is typically used in data warehouse environments where the need to recover a database is just a
matter of restoring a database image. This strategy should not be a choice in an on-line transaction processing
(OLTP) environment since roll-forward recovery is not possible. Figure 1 below illustrates circular logging:
Figure 1. Circular logging
Circular logging
Archival logging
In contrast to circular logging, the archival logging process creates a new log file when the last log file is filled so that
future transactions will not overwrite existing log files. When the database is initialized, the system allocates a
certain number of primary log files of a specified size in the active log directory. This number is controlled by a
database configuration parameter (discussed in the next section). When the primary log files are all full, secondary
log files are created on an "as-needed" basis until the maximum number of secondary log files has been created.
Once this number is reached, if additional log space is needed, an error is issued indicating no more log files are
available and all database activity is stopped.
With archival logging, it is possible to take an online database backup during which database activity continues to be
logged. In the event of a database crash or failure, the database may be restored using a full backup image followed
by a roll-forward operation using the archived logs to bring the database to a point-in-time state or to the most
recent consistent state by rolling forward to the end of the logs.