Sadrzaj - Alas

Sadržaj
I Ugnježdeni SQL 1
1 Uvod 3
2 Osnove kodiranja SQL-a u aplikativnom programu 5
2.1 Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Deklarativne SQL naredbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Host promenljive i strukture . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Indikatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Osnovno o indikatorima . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2 Postavljanje NULL vrednosti . . . . . . . . . . . . . . . . . . . . . . 10
2.4.3 Promena kodirajućeg skupa karaktera za host promenljivu . . . . . . 10
3 Obrada grešaka pri SQL upitima 11
3.1 SQLCODE i SQLSTATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Konverzija koda greške u tekstualno objašnjenje . . . . . . . . . . . . . . . 12
3.3 WHENEVER naredba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Otkrivanje grešaka pri aritmetičkim operacijama i konverziji . . . . . . . . . 13
4 Kursori 15
4.1 Rad sa kursorima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1 Otvaranje kursora . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.2 Čitanje podataka kursorom . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3 Ažuriranje podataka kursorom . . . . . . . . . . . . . . . . . . . . . 18
4.1.4 Brisanje podataka kursorom . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.5 Zatvaranje kursora . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.6 Tipovi kursora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Pravila za kodiranje SQL naredbi u PL/I aplikacijama 23
5.1 Uključivanje SQLCODE i SQLSTATE . . . . . . . . . . . . . . . . . . . . . 23
5.2 Pravila kodiranja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Upotreba host promenljivih . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.1 Deklaracija host promenljivih . . . . . . . . . . . . . . . . . . . . . . 25
5.3.2 Konverzija SQL kodova u tekstualni zapis . . . . . . . . . . . . . . . 25
6 Pravila za kodiranje SQL naredbi u C aplikacijama 27
6.1 Osnovna pravila . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Strukture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Osnovni zahtevi za host promenljive u C-u . . . . . . . . . . . . . . . . . . . 29

ii
SADRŽAJ
6.4 Karakter host promenljive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
II Transakcije, restart i oporavak u programu 31
7 Uvod 33
8 Transakcije 35
8.1 Jedinica oporavka i otvoreni kursori . . . . . . . . . . . . . . . . . . . . . . 36
8.2 Opšti algoritam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3 Tačke čuvanja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
III Dodatne programske tehnike 43
9 Dinamički SQL 45
9.1 Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.2 Izbor izmedju dinamičkog i statičkog SQL-a . . . . . . . . . . . . . . . . . . 45
9.2.1 Šta može da uradi program koji koristi dinamički SQL . . . . . . . . 46
9.2.2 Performanse statičkog i dinamičkog SQL-a . . . . . . . . . . . . . . . 46
9.3 Keširanje naredbi sa dinamičkim SQL-om . . . . . . . . . . . . . . . . . . . 47
9.4 Čuvanje pripremljene naredbe posle COMMIT-a . . . . . . . . . . . . . . . 47
9.5 Izbor host jezika za aplikacije sa dinamičkim SQL-om . . . . . . . . . . . . 48
9.6 Dinamički SQL sa ne-SELECT naredbom . . . . . . . . . . . . . . . . . . . 48
9.6.1 Izvršavanje upotrebom EXECUTE IMMEDIATE . . . . . . . . . . . 48
9.6.2 Izvršavanje upotrebom PREPARE i EXECUTE . . . . . . . . . . . 48
9.7 Dinamički SQL sa fiksnom listom u SELECT naredbi . . . . . . . . . . . . 50
9.8 Dinamički SQL sa promenljivom listom u SELECT naredbi . . . . . . . . . 51
10 Podešavanje upita 53
10.1 Opšta pravila . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.2 Pisanje efikasnijih predikata . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.3 Efikasna upotreba podupita . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.3.1 Korelirani podupiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.3.2 Nekorelirani podupiti . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.3.3 Transformacija podupita u spajanje . . . . . . . . . . . . . . . . . . 56
10.4 Specijalne tehnike koje utiču na pristupni put . . . . . . . . . . . . . . . . . 56
10.4.1 Dobijanje informacija o pristupnim putevima . . . . . . . . . . . . . 56
10.4.2 Upotreba OPTIMIZE FOR n ROWS . . . . . . . . . . . . . . . . . . 56
10.4.3 Smanjenje broja uparenih kolona . . . . . . . . . . . . . . . . . . . . 57
10.4.4 Promena unutrašnjeg u spoljašnje spajanje . . . . . . . . . . . . . . 58
10.4.5 Ažuriranje statistike u katalogu . . . . . . . . . . . . . . . . . . . . . 58
10.5 Osnovno o uskladištenim (stored) procedurama . . . . . . . . . . . . . . . . 59
10.6 Osnovno o radu sa distribuiranim podacima . . . . . . . . . . . . . . . . . . 60
10.6.1 Vezivanje programa koji rade sa DRDA pristupom . . . . . . . . . . 62
10.7 EXPLAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
10.7.1 Neke informacije o EXPLAIN-u . . . . . . . . . . . . . . . . . . . . . 63
10.8 Pristupni putevi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.8.1 Tehnike za poboljšavanje pristupnog puta . . . . . . . . . . . . . . . 64

SADRŽAJ
iii
10.8.2 Pristupni putevi za jednu tabelu . . . . . . . . . . . . . . . . . . . . 65
10.8.3 Pristupni putevi za više tabela . . . . . . . . . . . . . . . . . . . . . 67
11 Literatura 71
11.1 DB2 za OS/390 V7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
11.2 QMF V7R2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.3 Dodatna literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A Značenja polja u SQLCA 73
B Izgled SQLCA strukture 79
C Klase SQLSTATE kodova 81

Deo I
Ugnježdeni SQL

Glava 1
Uvod
Pored interkativnog SQL-a, do podataka u DB2 može da se pristupi i korišćenjem aplikativnih
programa. Radi izvršavanja SQL naredbi program mora da komunicira sa DB2. Ta
komunikacija sa DB2 V7.1 za OS/390 i z/OS se može izvesti na različite načine:
• Pomoću statičkog SQL-a
• Pomoću ugneždenog dinamičkog SQL-a
• Pomoću ODBC (eng. Open DataBase Connectivity protokola
• Pomoću podrške za JDBC (eng. Java DataBase Connectivity
U daljem tekstu će biti razmatrani statički i dinamički SQL. ODBC dopušta pristup preko
poziva ODBC funkcija u programu. SQL naredbe se izvršava ju prenošenjem ka DB2
preko poziva ODBC funkcija. ODBC eliminiše potrebu za prekompilacijem i vezivanjem
aplikacija i povećava portabilnost aplikacija korišćenjem ODBC interfejsa.
U slučaju da se koristi Java potrebno je koristiti JDBC. JDBC je sličan ODBC-u ali je
dizajniran za korišćenje sa Java programima i stoga je bolji izbor od ODBC-a za korišćenje
u Java aplikacijama.
Za detaljnije informacije o krišćenju ODBC i JDBC videti DB2 V7.1 ODBC Guide and
Reference, SC26-9941-02

Glava 2
Osnove kodiranja SQL-a u
aplikativnom programu
2.1 Uvod
U prethodnom kursu je rečeno da se SQL u DB2 koristi i kao upitni jezik prilikom interaktivnog
postavljanja upita (SPUFI, QMF) i kao programski jezik za rad sa bazom podataka.
Termin ”Ugnježdeni SQL” označava SQL naredbe koje se nalaze uključene u programu
napisanom na nekom od viših programskih jezika ili asembleru. Takav programski jezik
se naziva ”host jezik”. DB2 podržava PL/I, C, C++, FORTAN, COBOL, APL2, BASIC,
Ada, Prolog/MVS & VM, REXX i assembler kao host jezike, odnosno jezike u kojima se
mogu pisati programi koji uključuju SQL naredbe.
SQL ugnježden u višem programskom jeziku nije novi jezik; štaviše, svaka SQL naredba
koja može da se koristi interaktivno, može da bude uključena u program kao ugnježdena
SQL naredba. Pri tome je potrebno eventualno samo dopuniti pojedine detalje koji se
odnose na specifičnosti konkretnog programskog jezika.
Pravila koja mora da zadovoljava ugnježdeni SQL su:
1. Ugnježdena SQL naredba obavezno poseduje prefiks EXEC SQL i završava se specijalnim
terminator simbolom (u PL/I ’;’)
2. SQL naredba se obavezno piše velikim slovima (sem literala i host promenljivih
(videti kasnije) koji se pišu onakvi kakvi su deklarisani). 1
3. Postoje dve vrste ugnježdenih SQL naredbi: izvršne i deklarativne. Izvršne naredbe
mogu da se nalaze na onim mestima gde mogu da se nalaze i izvršne naredbe odgovarajućeg
host jezika. Primer izvršne SQL naredbe predstavlja bilo koja od SQL
naredbi koja može da se izvrši interaktivno (naravno, uz dodavanje prefiksa EXEC
SQL). Za razliku od njih, deklarativne naredbe (videti u daljem tekstu) mogu da
se nalaze na mestima gde se u programima javljaju deklaracije. Deklarativne SQL
naredbe obradjuje DB2 prekompilator.
1 Za PL/I ovo pravilo ne važi, jer PL/I prevodilac ne pravi razliku izmedju malih i velikih slova.

6 Osnove kodiranja SQL-a u aplikativnom programu
2.2 Deklarativne SQL naredbe
Pre korišćenja SQL naredbi kojima se dobijaju, ažuriraju, brišu ili unose podaci poželjno
je opisati tabele i poglede kojima se pristupa u takvim naredbama. Opisivanje se vrši
uključivanjem EXEC SQL DECLARE naredbe u program.
Deklaracija tabela i pogleda nije obavezna; nepostojanje deklaracija ne utiče na ispravnost
programa. U slučaju da u programu deklaracije ne postoje, prekompilator će generisati
upozorenje o nepostojanju deklaracija. Medjutim, deklarisanje tabela i pogleda poseduje
odredjene prednosti:
• bolja dokumentovanost programa: u DECLARE naredbi se navodi struktura tabele
ili pogleda sa kojim se radi, kao i tip podataka svakog atributa tabele. Time je
olakšan posao programeru koji tu poseduje pregled imena kolona i tipova podataka
u tabeli.
• navodjenjem deklaracija olakšava se posao DB2 prekompilatoru koji deklaracije koristi
prilikom provere korektnosti naziva kolona i tipova podataka u SQL naredbama.
Deklaracija tabele (ili pogleda, bez razlike) se vrši navodjenjem naredbe
EXEC SQL DECLARE ime-tabele TABLE .... Na primer,
EXEC SQL DECLARE SNABDEVACI TABLE
(SNABDEVACI
SIME
STATUS
GRAD
CHAR(5) NOT NULL,
CHAR(20),
SMALLINT,
CHAR(15));
Programer može sam da unosi deklaraciju tabela (i/ili pogleda) ili može da koristi sistemski
generator deklaracija DCLGEN. DCLGEN je generator deklaracija koji formira
DECLARE naredbe za tabele i host strukture koje se mogu koristiti u C, COBOL ili
PL/I programima. DCLGEN se može koristiti pre prekompilacije programa. Deklaracije
formirane sa DCLGEN-om se uključuju u program bilo navodjenjem EXEC SQL INCLUDE
ime člana biblioteke; bilo uključivanjem (npr. editorom) člana biblioteke koji sadrži generisane
deklaracije u izvorni oblik programa.
DCLGEN se može pozvati na različite načine:
• Preko ISPF-a kroz DB2I, izborom DCLGEN opcije na DB2I primarnom panelu.
• Direktno iz TSO-a pozivnom TSO komande DSN i unošnejem podkomande
DCLGEN.
• Iz CLIST procedura (bilo interkativno ili u batch-u) pozivanjem DSN i DCLGEN, i
• Iz JCL-a navodjenjem potrebnih parametara.
Ako se u programu upotrebljavaju tzv. kursori tada deklarativna naredba za kursor
MORA da postoji. O radu sa kursorima i ostalim deklarativnim naredbama (kao WHENEVER)
biće reči kasnije.

Host promenljive i strukture 7
2.3 Host promenljive i strukture
Ugnježdene SQL naredbe mogu da uključe reference na promenljive i strukture višeg programskog
jezika. Takve promenljive (strukture) se nazivaju host promenljive (strukture). 2
Host promenljive mogu da sadrže samo pojedinačne vrednosti, ali ne i celu tabelu, kao
ni sve vrednosti u jednoj koloni. Host promenljive moraju da se deklarišu pre korišćenja
u SQL naredbama. Deklaracija se navodi prema pravilima host jezika, i, u zavisnosti od
opcija prekompilatora, može ali ne mora da se navede u bloku naredbi ograničenom sa
EXEC SQL BEGIN DECLARE SECTION
... deklaracije host promenljivih i indikatora
EXEC SQL END DECLARE SECTION
Pri tome tip host promenljive mora da odgovara tipu podatka koji se javlja u SQL upitu
na onoj poziciji gde se host promenljiva pojavljuje. Ispred host promenljive koja se pojavljuje
u SQL naredbama mora da se navede dvotačka kao prefiks. Dvotačka ne sme da
se pojavi kao prefiks kod host promenljivih koje se koriste van SQL upita.
Host promenljive predstavljaju mesto kod koga se interaktivni SQL razlikuje od ugnježdenih
SQL naredbi. Kod rada sa interaktivnim SQL-om rezultati upita kod kojih se traži dohvatanje
podataka iz baze se prikazuju na ekranu terminala, štampaču ili u unapred
odredjenoj datoteci. Kod aplikativnog programa to nije slučaj; SQL naredba se izvrši,
dohvati tražene podatke i preda kontrolu aplikativnom programu. Jasno je da u ovom
slučaju treba eksplicitno obezbediti prostor u memoriji u koji treba smestiti podatke jer
podaci ne mogu da budu ”tu negde”, odnosno da ”ostanu da vise u vazduhu”. Upravo
se host promenljive koriste kao prostor u kome se smeštaju dobijeni podaci. Koje će
host promenljive biti korišćene za smeštanje podataka odredjuje se navodjenjem INTO
klauzule kod SELECT ili FETCH SQL naredbe. Mogu se navesti prijemno polje (tj.
host struktura) ili lista host promenljivih. Ako je programer siguran da je rezultat upita
NAJVIŠE JEDAN RED tada se SQL naredbe mogu kodirati u programu na isti način kao
i u interaktivnom SQL-u, uz dodavanje INTO naredbe. Takodje se mogu koristiti SQL
skalarne i agregatne funkcije sve dok je ispunjen uslov da je rezultat upita najviše jedan
red (bez obzira na broj kolona ili izračunatih vrednosti).
Napomena 1
Ako SELECT naredba kao rezultat upita daje više od jednog reda tada se javlja greška i
podaci koji se dobiju su ili nedefinisani ili nepredvidivi.
Tipična mesta gde se koriste host promenljive su:
• kao prijemno polje pri čitanju podataka (u INTO ili FETCH klauzuli), npr.
EXEC SQL
SELECT SIME INTO :ime FROM SNABDEVACI WHERE SRBR=’S1’;
EXEC SQL
SELECT SIME, STATUS, GRAD INTO :ime, :status, :grad
FROM SNABDEVACI
WHERE SRBR=’S1’;
2 Nadalje se podrazumeva da sva pravila koja važe za promenljive važe i za strukture.

8 Osnove kodiranja SQL-a u aplikativnom programu
EXEC SQL
SELECT SIME, STATUS, GRAD INTO :polje
FROM SNABDEVACI
WHERE SRBR=’S1’;
gde je polje deklarisano kao
dcl 1 polje,
2 ime char(20),
2 status bin fixed(15),
2 grad char(15);
• u WHERE klauzuli, za navodjenje vrednosti u predikatu kojim se vrši restrikcija
uslova pretraživanja ili na mestu gde može da zameni literal. Npr.
EXEC SQL
SELECT SIME INTO :ime FROM SNABDEVACI WHERE SRBR=:rednibroj;
• kao vrednost u SELECT naredbi. Npr.
EXEC SQL
SELECT SIME, :broj, STATUS+:broj INTO :ime, :zalihe, :status,
FROM SNABDEVACI
WHERE SRBR=:rbr;
• kao vrednost u ostalim klauzulama u SQL naredbi:
– SET klauzuli u UPDATE naredbi
– VALUES klauzuli u INSERT naredbi
– HAVING klauzuli
– ...
Ilustracija upotrebe host promenljivih data je u programima primer1 i primer2 koji su
navedeni u dodatku ??. 3
2.4 Indikatori
2.4.1 Osnovno o indikatorima
Kako u aplikativnom programu otkriti da li je rezulat nekog upita NULL? Nije moguće
postaviti pitanje da li je sadržaj neke host promenljive jednak NULL, već se pri rešavanju
ovog problema koriste indikatori.
Indikator promenljiva je ceo broj od jedne polureči (dva bajta) koji se može koristiti za:
3 Izvorni kodovi programa se nalaze u datoteci HDB2000.T.PLI. Primeri programa dati od strane IBM-a
se nalaze u datoteci DSN710.SDSNSAMP.

Indikatori 9
• odredjivanje da li se host promenljiva koristi kao prijemno polje za kolonu koja
može da poseduje NULL vrednosti. Ako je vrednost u koloni koja se traži NULL,
DB2 upisuje negativnu vrednost u indikator promenljivu i ne menja vrednost host
promenljive. Ako je NULL zbog greške pri numeričkoj konverziji ili pri izračunavanju
aritmetičkog izraza, DB2 postavlja indikator promenljivu na -2.
Ako se ne koristi indikator promenljiva, a pojavi se NULL vrednost u nekoj koloni
rezultata, tada se u programu dobija kod koji označava grešku pri izvršavanju SQL
naredbe.
• proveru da li je došlo do skraćivanja karakter niske koja se dobija kao vrednost upita.
Ako indikator promenljiva sadrži pozitivnu vrednost tada ta vrednost predstavlja
pravu dužinu niske. Više o dijagnosticiranju ovakvih tipova grešaka videti u odeljku
3.
• unošenje NULL vrednosti u tabele (bilo preko INSERT ili UPDATE naredbe).
• Odredjivanje da li se vrednost karaktera može konvertovati pri dodeljivanju vrednosti
host promenljivoj.
• Odredjivanje drugog dela vremenske vrednosti koja je odsečena pri dodeljivanju
vrednosti host promenljivoj.
Indikator promenljiva se može kodirati u programu na dva načina:
1. navodjenjem imena indikator promenljive (kome prethodi dvotačka) neposredno iza
imena host promenljive, i
2. korišćenjem ključne reči INDICATOR izmedju host i indikator promenljive. Pri
tome reč INDICATOR nije rezervisana reč SQL-a.
Sledeća dva primera su ekvivalentna:
EXEC SQL SELECT GRAD INTO :dgrad:indik
FROM DELOVI
WHERE DRBR=’D6’;
EXEC SQL SELECT GRAD INTO :dgrad INDICATOR :indik
FROM DELOVI
WHERE DRBR=’D6’;
Tehnika rada sa indikatorima se ne menja kada se podaci dobijaju korišćenjem kursora.
Za host strukture koje se koriste u programima definišu se odgovarajuće indikator strukture
(kao niz BIN FIXED(15) elemenata). Broj elemenata u strukturi u u nizu moraju biti
isti. U SQL naredbama se kodira tako što se navede ime strukture za kojim sledi ime
indikator strukture. Ako vrednost bilo kot od atributa može biti NULL tada se mora
koristiti indikator struktura koja sadrži test za sve kolone (naravno, ukoliko se koristi host
struktura a ne više host promenljivih). Primer upotrebe indikator promenljivih je prikazan
u programu primer3.

10 Osnove kodiranja SQL-a u aplikativnom programu
2.4.2 Postavljanje NULL vrednosti
Indikator promenljive se mogu koristiti i za postavljanje NULL vrednosti u tabelama.
Kada se izvršava UPDATE ili INSERT naredba DB2 proverava sadržaj indikator
promenljive (ako postoji). Ako je sadržaj negativna vrednost, vrednosti u koloni odgovarajuće
tabele biće postavljene na NULL. Ako je vrednost indikator promenljive veća
od -1 tada vrednost odgovarajuće host promenljive sadrži vrednost koju treba postaviti u
kolonu.
Primer upotrebe indikator promenljivih za postavljanje NULL vrednosti u tabelama je
prikazan u programu primer4.
Za host strukture koje se koriste u programima definišu se odgovarajuće indikator strukture
(kao niz promenljivih tipa BIN FIXED(15)). Broj elemenata u strukturi u i nizu moraju
biti isti. U SQL naredbama ovakav slučaj se kodira tako što se navede ime strukture za
kojim sledi ime indikator strukture. Primer upotrebe indikator strukure (tj. niza indikator
promenljivih) je prikazan u programu primer3.
Ako bilo koja od rezultujućih kolona nekog upita može biti NULL, i ukoliko se koristi
host struktura a ne više host promenljivih, tada se mora koristiti indikator struktura koja
sadrži proveru za NULL vrednosti u svim kolonama (bez obzira što možda neka od kolona
nikada na može da sadrži NULL vrednost).
Napomena 2
Indikator promenljiva koja se koristi u WHERE naredbi ne sme da sadrži negativne vrednosti.
Za ispitivanje da li je nešto NULL koristi se isključivo IS NULL ili IS NOT NULL.
Za formiranje opisa tabela i konstrukciju host struktura koje odgovaraju tabeli može se
koristiti sistemski program DCLGEN.
2.4.3 Promena kodirajućeg skupa karaktera za host promenljivu
Sve DB2 niske različite od BLOB poseduju šemu enkodiranja i skup kodirajućih karaktera
(CCSID). NZa dodljivanje šeme enkodiranja i CCSID pojedinačnim host promenljivim se
može koristiti DECLARE VARIABLE naredba.
Na primer, sa
EXEC SQL DECLARE --prom-- VARIABLE CCSID 1208;
se deklariše karakter host promneljiva u Unicode CCSID 1208.

Glava 3
Obrada grešaka pri SQL upitima
Da bi program koji uključuje SQL naredbe komunicirao sa DB2 potrebno je da poseduje
prostor preko koga se obavlja ta komunikacija. To polje se naziva SQL polje za komunikaciju
(SQL communication area, SQLCA).
Kada DB2 izvršava SQL naredbe iz aplikativnog programa, povratni kod se upisuje u
polja SQLCODE i SQLSTATE u SQLCA. Na osnovu upisanog koda se odredjuje da li je
naredba uspešno izvršena ili ne.
SQLCA je struktura promenljivih koja se ažurira posle izvršavanja svake SQL naredbe.
Promenljive iz SQLCA se koriste kao alat pri dijagnosticiranju pojave eventualne greške.
Izgled SQLCA strukture i značenje promenljivih u SQLCA su prikazani u dodatku A.
Aplikativni program koji sadrži izvršne SQL naredbe (tj. bilo koje sem DECLARE, IN-
CLUDE, WHENEVER) obavezno mora da poseduje tačno jednu SQLCA. Izuzetak od
ovog pravila za PL/I programe je slučaj kada se program prekompilira sa opcijom STD-
SQL(YES) (videti deo o opcijama prekompilatora). U host jezicima SQL INCLUDE
naredba se može iskoristiti za deklarisanje SQLCA tako što se pre bilo koje SQL naredbe,
a najbolje na početku programa, navede:
EXEC SQL INCLUDE SQLCA;
Izgled strukture uključene ovom naredbom prikazan je u dodatku B.
3.1 SQLCODE i SQLSTATE
Korisnik koji radi sa relacionim sistemom mora da dobije informaciju o uspešnosti
izvršavanja njegovog zahteva. Željenu informaciju, u obliku povratnog koda, relacioni
sistem DB2 upisuje u polje nazvano SQLCODE. SQLCODE je celbrojna promenljiva.
DB2 vraća sledeće vrednosti SQLCODE-a:
• Ako je prilikom izvršavanja upita došlo do greške SQLCODE dobija negativnu vrednost;
• svi izuzeti (ali važeći) uslovi postavljaju pozitivnu vrednost; (npr. SQLCODE=100
predstavlja informaciju da nema podataka koji zadovoljavaju uslov upita)
• u slučaju da nema grešaka ili izuzetih uslova SQLCODE se postavlja na nulu.
Značenja SQLCODE-a koja su različita od 0 i 100 variraju u zavisnosti od različitih implementacija
SQL-a i RSUBP-a.

12 Obrada grešaka pri SQL upitima
SQL:1992 standard je definisao SQLSTATE kao promenljivu koja sadrži povratnu informaciju
o izvršavanju zahteva u bazi podataka. Funkcija SQLSTATE je slična funkciji
SQLCODE-a, sa tom razlikom što je SQLSTATE karakter promenljiva. Kodovi kod ovih
dveju promenljivih su različiti - tako npr. kod ’02000’ kod SQLSTATE-a ima isto značenje
kao i kod +100 kod SQLCODE-a. DB2 podržava i SQLCODE i SQLSTATE.
SQLSTATE kod poseduje odredjenu strukturu. Prva dva karaktera predstavlaju kod SQL-
STATE klase. Kod ’00’ označava uspešno izvršenje. Kod ’01’ označava kodove vezane za
upozorenje, a ’02’ uslov da nema više slogova (npr. SQLSTATE ’02000’ predstavlja informaciju
da nema podataka koji zadovoljavaju uslov upita). Sve ostale klase kodova
označavaju greške. Značenja SQLSTATE kodova po grupama su prikazana u dodatku C.
Vrednosti promenljivih SQLCODE i SQLSTATE se postavljaju posle izvršavanja svakog
SQL upita. Prednosti upotrebe SQLCODE-a u odnosu na SQLSTATE su veća količina
informacija koju SQLCODE nosi, zajedno sa pridruženim poljima u SQLCA. Radi zadovoljenja
SQL standarda, SQLCODE i SQLSTATE se mogu deklarisati kao samostalne
promenljive, bez navodjenja SQLCA strukture. Takva mogućnost se dobija navodjenjem
STDSQL(YES) opcije prekompilatora.
3.2 Konverzija koda greške u tekstualno objašnjenje
Provera kodova i otklanjanje eventualnih grešaka se mogu olakšati ako se izvrši prikaz odgovarajućeg
tekstualnog značenja dobijenog SQLCODE-a (SQLSTATE-a). Takav prikaz se
vrši pozivanjem asemblerskog potprograma DSNTIAR. Primeri poziva ovog programa su
prikazani u programu primer5. U programu primer5a je prikazan rad sa programskom
procedurom koja se može koristiti za proveru ispravnosti izvršenog SQL upita. Detaljan
opis kodova koje vraća DSNTIAR je dat u knjizi Application Programming and SQL
Guide.
3.3 WHENEVER naredba
WHENEVER naredba dopušta programeru da odluči na koji način će proveravati kod
dobijen posle izvršene SQL naredbe. WHENEVER naredba omogućava da DB2 proveri
SQLCA i nastavi izvršavanje programa ili da prenese izvršavanje na druge grane programa
u slučaju da se javila greška ili neko od izuzetih stanja. Tada program 1 može da proveri
odgovarajući kod i preduzme odgovarajuću akciju.
U jednom programu se može navesti više WHENEVER naredbi. Svaka WHENEVER
naredba se odnosi na sve naredne SQL naredbe do navodjenja nove WHENEVER naredbe
sa istim uslovom. Opšti oblik WHENEVER naredbe je:
EXEC SQL WHENEVER uslov akcija;
Postoje tri uslova:
1 REXX ne podržava WHENEVER naredbu.

Otkrivanje grešaka pri aritmetičkim operacijama i konverziji 13
SQLWARNING
SQLEEROR
NOT FOUND
i dve akcije:
CONTINUE
navodi se da bi se odredila akcija u slučaju SQLWARN0=W
ili SQLCODE 100
navodi se da bi se odredila akcija u slučaju da je SQLCODE

Glava 4
Kursori
DB2 koristi mehanizam koji se naziva kursor za dobijanje skupa slogova u aplikativnom
programu. Kursori se mogu koristiti za dobijanje pojedinačnih slogova rezultujućih tabela
ili iz skupa podataka vraćenih od strane stored procedure.
Opšti oblik deklaracije kursora je:
>>--DECLARE--cursor-name--+-----------------------------------+------>
+--+-INSENSITIVE----------+--SCROLL-+
+-SENSITIVE---STATIC---+
--CURSOR--+-----------------+------FOR--+-select-statement-+-------><
+-WITH HOLD---|
+-statement-name---+
+-WITH RETURN-+
1) The same clause must not be specified more than once
pri čemu navedeno ime kursora mora da bude jedinstveno u programu.
Ako je navedena SELECT naredba, tada ona ne sme da koristi parametar markere (koriste
se pri radu sa dinamičkim SQL-om), ali može da uključi host promenljive. Host
promenljive koje se javljaju u DECLARE CURSOR naredbi moraju prethodno da budu
deklarisane.
Slučaj kada je umesto SELECT naredbe naveden naziv promenljive koja sadrži upit, koristi
se pri radu sa dinamičkim SQL-om i biće obradjen u poglavlju o dinamičkom SQL-u.
Primeri korišćenja kursora su prikazani u programima primer7 i primer8.
Kursor se koristi za dobijanje podataka, ažuriranje slogova ili brisanje slogova. Ne može
da se koristi za unošenje novih slogova.
Ako se kursor koristi za ažuriranje podataka u kolonama tada na kraju upita treba navesti
klauzulu FOR UPDATE OF sa spiskom imena kolona koje želimo da ažuriramo.
Rezultujuća tabela ne može da se ažurira 1 ako SELECT naredba u deklaraciji kursora:
• ako FROM klauzula spoljašnje select naredbe sadrži
1 U daljem tekstu će se koristiti termin read only tabela.

16 Kursori
– read-only pogled
– tabelu ili pogled koji se javljaju u podupitu spoljašnje select naredbe
– spajanje (tj. ako sadrži više od jedne tabele ili pogleda)
– katalog tabelu koja ne sadrži kolone koje mogu da se ažuriraju
– tabličnu funkciju
• u svom prvom upitu sadrži ključnu reč DISTINCT ili agregatnu funkciju
• spoljašnji podupit sadrži klauzule GROUP BY ili HAVING
• podupit koji se referiše na istu osnovnu tabelu kao i spoljašnji upit.
• klauzule UNION, UNION ALL
• klauzulu ORDER BY (sem kada je kursor deklarisan kao SENSITIVE STATIC)
• sadrži FOR FETCH ONLY ili FOR READ ONLY klauzulu
• ne sadrži FOR UPDATE OF klauzulu, ali se pri izvršavanju naredbe koristi nivo
izolacije UR.
4.1 Rad sa kursorima
4.1.1 Otvaranje kursora
Pre čitanja podataka, kursor mora prethodno da se otvori. Ako deklaracija sadrži
host promenljive, vrednost host promenljive se uzima tek u trenutku otvaranja
kursora. Otvaranje kursora se vrši naredbom
EXEC SQL OPEN ime;
Pomoću otvorenog kursora podaci mogu da se čitaju, da se ažuriraju ili da se brišu.
Takodje, otvoreni kursor može i da se zatvori.
4.1.2 Čitanje podataka kursorom
Čitanje podataka kursorom se vrši naredbom
EXEC SQL FETCH ime INTO :host_promenljiva;
Umesto host promenljive može da se javi host struktura ili lista host promenljivih. Primetimo
da se u deklaraciji kursora nigde ne pojavljuje ključna reč INTO.
Izvršavanjem svake FETCH naredbe čita se red rezultujuće tabele. Ispitivanje da li ima još
podataka u tabeli vrži se testiranjem SQLCODE = 100 (odnosno SQLSTATE=’02000’)
Sem čitanja kursor se koristi i za pozicioniranje na odrejdneni podatak pre ažuriranja ili
brisanja podataka kursorom. Sintaksa FETCH naredbe je prikazana u narednoj tabeli.

Rad sa kursorima 17
+------------------------------------------------------------------------+
| |
| |
| +-NEXT---------------------------+ |
| >>--FETCH----------------------+--------------------------------+----> |
| | (1)| +-PRIOR--------------------------| |
| +-INSENSITIVE----| +-FIRST--------------------------| |
| | (2) | +-LAST---------------------------| |
| +-SENSITIVE------+ +-CURRENT------------------------| |
| | (3) | |
| +-BEFORE-------------------------| |
| | (3) | |
| +-AFTER--------------------------| |
| +-ABSOLUTE---host-variable-------| |
| | +-integer-constant-+ | |
| +-RELATIVE---host-variable-------+ |
| +-integer-constant-+ |
| |
| +-FROM-+ |
| >--------------cursor-name------------------------------------------>< |
| +-| single-fetch-clause +-+ |
| |
| single-fetch-clause: |
|

18 Kursori
Pokušaj otvaranja već otvorenog kursora pri konekciji programa u okviru jednog aplikativnog
servera daje grešku. Iako je oblast važenja kursora program u kome je kursor
deklarisan, svaki paket (ili DBRM plana) koji program formira uključuje posebnu instancu
kursora, pri čemu više instanci jednog istog kursora može biti korišćeno u istom
aplikativnom programu. Npr. neka je program prekompiliran sa opcijom CONNECT(2)
i neka se njegov DBRM koristi za formiranje paketa na lokacijama X i Y. Tada je sledeći
program ispravan
DECLARE C CURSOR FOR ...
CONNECT TO X
OPEN C
FETCH C INTO ...
CONNECT TO Y
OPEN C
FETCH C INTO ...
jer se druga naredba OPEN C referiše na drugu instancu kursora C. Sličan slučaj važi i
za jednu lokaciju ako se koriste paketi koji su u različitim skupovima, i za izbor paketa se
koristi SET CURRENT PACKAGESET naredba.
4.1.3 Ažuriranje podataka kursorom
Kursorom je moguće ažurirati samo slog tabele koji je trenutno pročitan. Zbog toga se
ovakav način ažuriranja tabele naziva poziciono ažuriranje. Takav kursor mora da bude
deklarisan sa FOR UPDATE OF klauzulom. U njoj se navode nazivi svih atributa čiji
sadržaj (u nekom od redova) treba ažurirati. 2 Za ažuriranje se koristi naredba
EXEC SQL UPDATE tabela SET kolona= vrednost, ...
WHERE CURRENT OF ime_kursora;
Posle ažuriranja, kursor i dalje pokazuje na tekući slog. Da bi se pročitao naredni slog
potrebno je izvršiti FETCH naredbu.
Naredba za poziciono ažuriranje tabele zadovoljava sledeće uslove:
• Ne može se ažurirati tabela ako se time narušava neko od ograničenja (jedinstvenost,
check ili referencijalno).
• UPDATE naredbom se ne mogu modifikovati redovi u privremenoj tabeli formiranoj
u istom programu, ali mogu iz deklarisanih privremenih tabela.
• Ako desna strana SET klauzule sadrži potpun SELECT izraz, tada on ne može da
uključuje korelirano ime za tabelu koja se ažurira.
4.1.4 Brisanje podataka kursorom
Kursorom je moguće brisati samo tekući slog tabele (tj. slog koji je pročitan pri poslednjem
izvršavanju FETCH naredbe). Zbog toga se ovakav način ažuriranja tabele naziva
poziciono brisanje. Brisanje se vrši naredbom
2 Sem u slučaju navodjenja opcije prekompilatora STDSQL(YES) odnosno NOFOR.

Rad sa kursorima 19
EXEC SQL DELETE FROM tabela
WHERE CURRENT OF ime_kursora;
Izvršavanjem ove naredbe se briše slog na koji pokazuje kursor. Pri tome važi
• jednim izvršavanjem DELETE naredbe sa opcijom WHERE CURRENT OF briše
se samo jedan red tabele,
• ime kursora u WHERE CURRENT OF odredjuje tabelu iz koje se brišu podaci,
• kursor se ne može koristiti za brisanje podataka iz privremene tabele formirane u
programu, ali može iz deklarisane privremene tabele.
• posle brisanja tekućeg reda kursor ostaje na istom mestu. Jedine naredbe koje mogu
da se izvrše nad tim kursorom su CLOSE i FETCH.
4.1.5 Zatvaranje kursora
Ako je završena obara slogova rezultujuće tabele i potrebno je da se kursor ponovo koristi
tada on mora da se zatvori, a zatim ponovo otvori. Zatvaranje kursora se vrši naredbom
EXEC SQL CLOSE ime; DB2 automatski zatvara sve otvorene kursore na kraju
izvršavanja programa.
4.1.6 Tipovi kursora
Navodjenjem različitih opcija u deklaraciji kursora se definišu kursori različitih tipova.
Deklarisane opcije imaju različite efekte na kursore, i to:
1. Opcija WITH HOLD sprečava zatvaranje kursora pri commit operaciji, sem u sledeća
tri slučaja:
• konekcija asocirana sa kursorom je u release pending stanju,
• važi bind opcija DISCONNECT(AUTOMATIC), ili
• okruženje ne prepoznaje WITH HOLD opciju.
Postojanje WITH HOLD ne sprečava zatvaranje kursora pri izvršavanju rollback
naredbe ili connect(1) operacije.
2. Opcija WITH RETURN opcija označava da kursor koji je deklarisan u stored proceduri
može da vrati rezultat u pozivajući program.
3. Izostanak opcije SCROLL označava da je kursor nepomerljiv u proizvoljnom smeru,
odnosno da njime mogu da se čitaju slogovi strogo sekvencijalno, samo redom, jedan
po jedan od početka ka kraju tabele.
Kursor koji nije pomerljiv se uvek pomera sekvencijalno počev od početka tabele. Po
otvaranju kursor se pozicionira na prvi red u rezultujućoj tabeli. Svako izvršavanje
FETCH naredbe pomera kursor za jedan red prema kraju tabele. Ako se za ovako
definisan kursor izvrše (pozicione) UPDATE ili DELETE naredbe, po njihovom
izvršavanju kursor ostaje na istom (tekućem) redu tabele.

20 Kursori
4. Opcija SCROLLoznačava da je kursor pomerljiv odnosno da se kursorom može vršiti
kretanje u slučajnom redosledu kroz rezultujuću tabelu. Pomerljiv kursor može biti
deklarisan sa atributom INSENSITIVE ili SENSITIVE STATIC.
Navodjenje atributa INSENSITIVE ima slede’ ce efekte:
(a) Veličina, redosled slogova i vrednosti u svakom redu rezultujuće tabele se ne
menjaju posle otvaranja kursora 3 .
(b) Rezultujuća tabela se može koristiti samo za čitanje. Posledica ovoga je da kursor
ne može istovremeno da sadrži klauzule i INSENSITIVE i FOR UPDATE
OF.
Navodjenje atributa SENSITIVE ima slede’ ce efekte:
(a) Rezultat izvršavanja pozicionih UPDATE ili DELETE naredbi je vidljiv u rezultujućoj
tabeli.
(b) Kada tekuća vrednost u redu dalje ne zadovoljava SELECT naredbu iz
deklaracije kursora, takav red prestaje da bude vidljiv u rezultujućoj tabeli.
(c) Kada je red rezultujuće tabele izbrisan iz tabele navedene u deklaraciji kursora
tada takav red prestaje da bude vidljiv u rezultujućoj tabeli.
(d) Promene u tabeli navedenoj u deklaraciji kursora napravljene drugim kursorima
ili od strane drugih aplikacija mogu da postanu vidljive u rezultujućoj tabeli u
zavisnosti od toga da li se koristi FETCH INSENSITIVE ili FETCH SENSIS-
TIVE naredba.
U DB2 V7 deklaracija SENSISTIVE povlači navodjenje klauzule STATIC. Kursori
deklarisani sa STATIC imaju sledeće osobine:
(a) Broj redova u rezultujućoj tabeli se ne menja po otvaranju kursora. Ako je
neki red dodat u tabelu korišćenu u deklaraciji kursora on neće postati vidljiv
u rezultujućoj tabeli.
(b) Uredjnje redova se ne menja po otvaranju kursora. Ako je kursor deklarisan sa
ORDER BY klauzulom, a vrednosti u kolonama navedenim u ORDER BY su
promenjene po otvaranju kursora redosled slogova u rezultujućoj tabeli se neće
promeniti.
Rad sa SENSITIVE kursorima
Posle otvaranja kursor je pozicioniran na prvi red u rezultujućoj tabeli. Pomerljiv kursor se
može pomerati na željeni red navodjenjem apsolutne ili relativne (u odnosu na tekući red)
pozicije u FETCH klauzuli. U narednoj tabeli su prikazane moguće pozicije pomerljivog
kursora.
+------------------------------------------------------------------------+
| Table 4. Positions for a scrollable cursor |
+------------------------------------------------------------------------|
| | Cursor position when the FETCH is |
| Keyword in FETCH statement | executed |
3 Tj. kursor je neosetljiv na promene, npr. od strane drugog aplikativnog programa.

Rad sa kursorima 21
+--------------------------------+---------------------------------------|
| BEFORE | Before the first row |
+--------------------------------+---------------------------------------|
| FIRST or ABSOLUTE +1 | At the first row |
+--------------------------------+---------------------------------------|
| LAST or ABSOLUTE -1 | At the last row |
+--------------------------------+---------------------------------------|
| AFTER | After the last row |
+--------------------------------+---------------------------------------|
| ABSOLUTE(1) | To an absolute row number, from |
| | before the first row forward or from |
| | after the last row backward |
+--------------------------------+---------------------------------------|
| RELATIVE(1) | Forward or backward a relative number |
| | of rows |
+--------------------------------+---------------------------------------|
| CURRENT | At the current row |
+--------------------------------+---------------------------------------|
| PRIOR or RELATIVE -1 | To the previous row |
+--------------------------------+---------------------------------------|
| NEXT or RELATIVE +1 | To the next row (default) |
+------------------------------------------------------------------------|
| Note: |
| |
| 1. ABSOLUTE and RELATIVE are described in greater detail in |
| the discussion of FETCH in Chapter 5 of DB2 SQL Reference. |
+------------------------------------------------------------------------+
Deklaracija kursora sa SENSITIVE klauzulom omogućuje da se promene napravljene od
strane druge aplikacije postanu vidljive u tekućem programu. Da li će se to desiti ili
ne zavisi od navedene klauzule u FETCH naredbi. U narednoj tabeli je prikazan odnos
SENSITIVE i INSENSITIVE klauzula navedenih u deklaraciji tabele i FETCH naredbi.
+------------------------------------------------------------------------+
| Table 5. How sensitivity affects the result table for a scrollable |
| cursor |
+------------------------------------------------------------------------|
| | FETCH sensitivity |
| +------------------------------------------------|
| DECLARE sensitivity | INSENSITIVE | SENSITIVE |
+-----------------------+------------------------+-----------------------|
| INSENSITIVE | No changes to the | Not valid. |
| | underlying table are | |
| | visible in the result | |
| | table. Positioned | |
| | UPDATE and DELETE | |
| | statements using the | |
| | cursor are not | |
| | allowed. | |

22 Kursori
+-----------------------+------------------------+-----------------------|
| SENSITIVE | Only changes that are | All changes are |
| | made by the cursor are | visible in the result |
| | visible in the result | table. |
| | table. | |
+------------------------------------------------------------------------+
Pri radu mogu da nastanu i tzv. rupe u rezultujućoj tabeli. Uzrok njihovog nastajanja je
moguća promena osnovnih tabela od strane istog ili drugog korsinika i rad sa kursoriam
sa odredjenom kombinacijom INSENSITIVE i SENSITIVE klauzula. Rupe se otkrivaju
pojavom ne-nula SQLCODE-a. Više o rupama, načinu njihovog pojavljivnaja i otklanjanja
se može naći u DB2 UDB for OS/390 and z/OS V7 Application Programming and SQL
Guide, SC26-9933-02 u poglavlju 2.2. Takodje, na istom mestu se mogu naći i informacije
kako može da se odredi tip kursora proverom SQLCA.

Glava 5
Pravila za kodiranje SQL naredbi
u PL/I aplikacijama
5.1 Uključivanje SQLCODE i SQLSTATE
PL/I program koji sadrži SQL naredbe mora da uključi:
1. Bar jednu od sledeće dve promenljive:
• SQLCODE deklarisanu kao BIN FIXED(31);
• SQLSTATE deklarisanu kao CHARACTER(5);
2. Ili SQLCA koja sadrži deklaracije promenljivih SQLCODE i SQLSTATE.
Da li će u programu biti deklarisani SQLCODE i SQLSTATE ili SQLCA zavisi od opcije
STDSQL prekompilatora:
YES U ovom slučaju ne treba definisati SQLCA. AKo se SQLCA navede tada se javlja
greška u prekompilaciji. Deklarisana promenljiva SQLSTATE ne sme biti deo strukture.
U ovom slučaju sve deklaracije host promenljivih se moraju javiti u bloku
BEGIN DECLARE SECTION
deklaracije ...
END DECLARE SECTION
U programu može postojati više BEGIN/END sekcija za deklaraciju.
NO U ovom slučaju treba eksplicitno uključiti SQLCA. Za uključivanje deklaracije
SQLCA najbolje je koristiti naredbu EXEC SQL INCLUDE SQLCA.
PL/I programi mogu, uključivanjem naredbe EXEC SQL INCLUDE SQLDA, da uključe
jedno ili više SQLDA polja i iskoriste ih u radu sa dinamičkim SQL-om.
5.2 Pravila kodiranja
Prva naredba u PL/I programima koji koriste SQL mora biti PROCEDURE sa OP-
TIONS(MAIN) osim u slučajevima stored procedura koje mogu biti potprogrami. SQL
naredbe u PL/I programima mogu da se koriste na svim mestima gde i izvršne PL/I

24 Pravila za kodiranje SQL naredbi u PL/I aplikacijama
naredbe. Svaka SQL naredba počinje ključnim rečima ’EXEC SQL’. Pri tome EXEC SQL
mora da se nalazi u jednom redu; ostatak SQL naredbe može ali ne mora da se nalazi
u istom redu gde i EXEC SQL. Kraj SQL naredbe se označava sa ’;’. Tačka-zarez kao
graničnik je neophodan na kraju svake SQL naredbe.
Svaka izvršna SQL naredba može da bude označena labelom na isti način kao i PL/I
naredbe. EXEC SQL INCLUDE naredbe ne mogu da budu ugnježdene. U SQL naredbama
ne treba koristiti direktive PL/I preprocesora.
Komentari mogu da budu uključeni u ugnježdene SQL naredbe na svim mestima gde može
da se nalazi blanko karakter, izuzimajući blankove izmedju EXEC i SQL. Pri tome se komentari
označavaju na isti način kao i u PL/I programima (sa /* i */), uz ograničenje da
komentari ne mogu biti ugnježdeni. Ako se koristi opcija prekompilatora STDSQL(YES)
tada se komentari mogu koristiti i unutar bilo koje statičke SQL naredbe.
Pravila za nastavljanje SQL naredbe su slična pravilima koja važe za naredbe PL/I jezika.
SQL naredba se može pisati u jednom ili više redova. Pri tome, svaka SQL naredba može
biti prekinuta na svakom mestu gde može da se javi blanko karakter (isključujući EXEC
SQL). Ako se programski red završava sa ne-blanko karakterom na desnoj margini, a
sledeći red počinje ne-blanko karakterom na levoj margini, tada se ova dva reda posmatraju
kao jedan (pri čemu se drugi red dopisuje u nastavku prvog). Veličine leve i desne
margine se postavljaju u MARGINS opciji prekompilatora. (inicijalno su 2 i 72).
Pravila koja se odnose na WHENEVER naredbe, i uključivanje deklaracija tabela u program
su prethodno navedena.
5.3 Upotreba host promenljivih
Za upotrebu host promenljivih u PL/I programima važe sledeća pravila:
1. Sve host promenljive se moraju eksplicitno deklarisati pre korišćenja u SQL naredbama,
sem u slučaju upotrebe TWOPASS opcije prekompilatora. Čak i sa
TWOPASS opcijom deklaracije host promenljivih koje se javljaju u naredbi DE-
CLARE CURSOR moraju da prethode samoj naredbi DECLARE CURSOR.
2. Sve host promenljive koje se javljaju u SQL naredbama moraju da imaju dvotačku
kao prefiks.
3. Nazivi host promenljivih treba da budu jedinstveni unutar programa, bez obzira da li
se host promenljive koriste samo u procedurama ili drugim programskim blokovima.
4. Host promenljive moraju biti skalarne promenljive ili strukture komponovane od
skalarnih promenljivih. Host promenljive ne mogu da budu deklarisane kao nizovi.
5. Da bi se izbegle moguće greške pri definisanju imena promenljivih u PL/I programima
treba se pridržavati pravila:
• za imena host promenljivih ne treba koristiti rezervisane reči SQL jezika niti
imena koja počinju sa SQL,
• ne treba koristiti imena eksternih promenljivih ni imena planova koja počinju
sa DSN (DSN je rezervisano za imena koja pripadaju DB2 podsistemu).

Upotreba host promenljivih 25
5.3.1 Deklaracija host promenljivih
Samo neke od mogućih PL/I deklaracija su moguće i za host promenljive. Prekompilator
koristi predefinisane tipove podataka navedene u PL/I default. Ako deklaracija host
promenljive nije korektna, to moze da dovede do poruke ’UNDECLARED HOST VARI-
ABLE’.
Prekompilator koristi jedino imena i atribute promenljivih igonorišući oblast važenja,
memorijske atribute i njihovo smeštanje u memoriji. Tako host promenljive mogu biti klase
STATIC, CONTROLLED, BASED ili AUTOMATIC. Medjutim, ukoliko je promenljiva
deklarisana sa EXTERNAL i STATIC atributima tada mora imati i INITIAL atribut.
U dodatku ?? su prikazani SQL tipovi podataka koje koristi prekompilator za PL/I
deklaracije, kao i preslikavanje izmedju tipova podataka u SQL-u i u PL/I.
5.3.2 Konverzija SQL kodova u tekstualni zapis
Za konverziju dobijenih SQL kodova u tekstualni zapis moze se koristiti asemblerski potprogram
DSNTIAR. Njegovo kodiranje je dato u obliku procedure, a upotreba je prikazana
npr. u programu primer5a.
/**************************************************************/
/* SQL ERROR CODE HANDLING */
/**************************************************************/
greska: proc(por);
dcl (pliretv,dim) builtin;
dcl dsntiar entry options(ASM,INTER,RETCODE);
dcl data_len fixed bin(31) init(120);
dcl data_dim fixed bin(31) init(10);
dcl 1 error_message automatic,
3 error_len fixed bin(15) unal init((data_len*data_dim)),
3 error_text(data_dim) char(data_len);
dcl por char(50) varying;
call dsntiar( sqlca , error_message , data_len );
put file(sysprint) edit(’Greska ’,por) (skip,a,a);
if pliretv = 0
then
do i=1 to dim(error_text,1);
put file (sysprint) edit ( error_text(i)) (skip,a) ;
end;
else
do;
put edit (’Greska pri pozivu DSNTIAR, RC=’, pliretv)
(skip,a,f(10));
stop;
end;
end greska;

Glava 6
Pravila za kodiranje SQL naredbi
u C aplikacijama
Pravila za kodiranje SQL naredbi u C i Java aplikacijama su vrlo sličan već navedenim
pravilma za PL/I.
6.1 Osnovna pravila
Osnovne pravila za kodiranje SQL-a u C programima su:
1. Sve SQL ključne reči (u C programima) moraju da se navode velikim slovima.
2. SQL naredba se može javiti na svim mestima gde i izvršna C naredba.
3. Jedna C naredba može da sadrži najviše jednu SQL naredbu.
4. Svaka SQL naredba koja se kodira u programu mora da počinje sa EXEC SQL. Pri
tome EXEC SQL mora da se nalazi u jednom redu; ostatak SQL naredbe može ali
ne mora da se nalazi u istom redu gde i EXEC SQL; pri tome ostatak naredbe može
da se nalazi u više narednih redova.
5. Kraj SQL naredbe se označava sa ”;”. Tačka-zarez kao graničnik je neophodan na
kraju svake SQL naredbe.
6. Svaka izvršna SQL naredba može da bude označena labelom na isti način kao i C
naredbe.
7. Komentari mogu da budu uključeni u SQL naredbe na svim mestima gde može da
se nalazi blanko karakter, izuzimajući blankove izmedju EXEC i SQL. Pri tome se
komentari označavaju na isti način kao i u C programima (sa /* i */), uz ograničenje
da komentari ne mogu biti ugnježdeni. Kao komentr se može koristiti i // u C
naredbama ali ne i u SQL-u. Ako se koristi opcija prekompilatora STDSQL(YES)
tada se komentari mogu koristiti i unutar bilo koje statičke SQL naredbe.
8. Nastavljanje SQL naredbe: Pravila za nastavljanje SQL naredbe su slična pravilima
koja važe za naredbe C jezika. SQL naredba se može pisati u jednom ili više redova.
Pri tome, svaka SQL naredba može biti prekinuta na svakom mestu gde može da se
javi blanko karakter (isključujući EXEC SQL). Ako se programski red završava sa

28 Pravila za kodiranje SQL naredbi u C aplikacijama
ne-blanko karakterom na desnoj margini, a sledeći red počinje ne-blanko karakterom
na levoj margini, tada se ova dva reda posmatraju kao jedan (pri čemu se drugi
red dopisuje u nastavku prvog). Pri tome ne treba navoditi obrnutu kosu crtu
(backslash) na kraju prvog programskog reda (kao u C-u).
9. Veličine leve i desne margine se postavljaju u MARGINS opciji prekompilatora.
Inicijalne vrednosti su 1 i 72.
10. DB2 prekompilator mora da se izvršava pre C preprocesora. Nijedna od direktiva C
preprocesora nije podržana od strane DB2 prekompilatora.
11. Uključivanje SQL naredbi ili deklaracija (iz ;lana biblioteke) se vrši naredbom
EXEC SQL INCLUDE ime-člana;
12. U slučaju da nekih C karaktera nema na tastaturi na njihovom mestu se mogu
koristiti trigrafi.
Da bi se izbegle moguće greške pri definisanju imena promenljivih u C programima treba
se pridržavati pravila:
• za imena host promenljvih ne treba koristiti rezervisane reči SQL jezika niti imena
koja počinju sa SQL.
• ne treba koristiti imena eksternih promenljvih ni imena planova koja počinju sa DSN
(DSN je rezervisano za imena koja pripadaju DB2 podsistemu).
• Pojam nulls-ova: i C i SQL koriste reč null ali sa različitim značenjem. C jezik
poseduje null karakter (NUL), null pokazivač (NULL) i null naredbu (koja sadrži
samo ;). C NUL je jedan karakter koji poredi jednakost sa 0. C NULL je specijalni
rezervisani pokazivač koji ne pokazuje niti na jedan od važećih objekata. Nasuprot
tome, SQL null vrednost (NULL) je specijalna vrednost koja se razlikuje od svih
ostalih vrednosti i označava odsustvo (nonnull) vrednosti.
6.2 Strukture
Host struktura označava grupno ime više komponenata koje su predstavljene elementarnim
tipovima podataka. Na primer,
struct {char c1[n];
char c2[n];
} polje;
• Polje je naziv host strukture koja se sastoji od elementarnih komponenti c1 i c2.
• n mora biti prethodno definisano kao celobrojna konstanta i mora da poseduje vrednost
¿0.
Host struktura koja je deo druge host strukture može da se referiše jedino u slučaju da se
nalazi na najdubljem nivou ugnježdenja.

Osnovni zahtevi za host promenljive u C-u 29
Strukture u C programima se koriste i za predstavljanje VARCHAR tipa podataka VAR-
CHAR(n) u DB2 predstavlja nisku karaktera čija dužina pripada intervalu [0,n]. VAR-
CHAR tip je podržan u C-u kao niska proizvoljnih (binarnih ili karakter) podataka. Pošto
binarni podaci mogu da sadrže bilo koju (heksadekadnu) kombinaciju VARCHAR tip koristi
dužinu polja i ne poseduje terminator karakter. Na primer,
struct short dužina; char podaci[maxduž] vark;
U prethodnom primeru vark je ime strukture. Promenljive dužina i podaci ne mogu da
budu korišćene pojedinačno, već je celokupna struktura vark prepoznata kao niska karektera
promenljive dužine, gde je maxduž pozitivan ceo broj.
Ova deklaracija je specijalno preslikavanje koje koristi pojedinačni format host strukture.
Ako je potrebna host struktura koja koristi taj format tada se mora definisti drugačije od
VARCHAR tipa podataka deklarisanjem lažnih (dummy) promenljivih unutar strukture.
Primedba: C funkcije za manipulaciju sa stringovima ne mogu da podrže ovaj tip podataka
jer niska može da sadrži NUL karaktere koji ne predstavljaju kraj niske. Praktično,
trenutna dužina niske je upisana u promenljivoj dužina, dok je maxduž maksimalna dužina
niske.
6.3 Osnovni zahtevi za host promenljive u C-u
Osnovni zahtevi za host promenljive u C-u su:
• Sve host promenljive koje se koriste u SQL naredbama moraju biti eksplicitno deklarisane.
Svaki eksplicitna deklaracija koja važi u C-u može se iskoristiti za deklaraciju
host promenljive. Pri tome tip promenljive mora biti kompatibilan sa odgovarajućim
SQL tipom podataka.
• Sve host promenljive koje se koriste u SQL naredbama moraju biti prethodno deklarisane
sem u slučaju da je navedena TWOPASS opcija kod DB2 prekompilatora. Čak
i sa TWOPASS opcijom deklaracije host promenljvih koje se javljaju u naredbi DE-
CLARE CURSOR moraju da prethode samoj naredbi DECLARE CURSOR.
• Deklaracija host promenljivih mora da se nalazi unutar sekcije za deklaraciju
promenljivih:
EXEC SQL BEGIN DECLARE SECTION;
... deklaracije host promenljivih ...
EXEC SQL END DECLARE SECTION;
• Host promenljive ne smeju da se inicijalizuju unutar sekcije za deklaraciju. U programu
se može navesti više sekcija za deklarisanje host promenljivih.
• Host promenljive moraju biti skalarne promenljive ili strukture komponovane od
skalarnih promenljivih; one ne mogu ulaziti u sastav vektora ili nizova osim za nizove
karaktera koje sadrže niske karaktera (stringove). Ako je niz asociran sa host
strukturom tada je dopušteno da on bude niz indikator promenljvih.
• Ako je host promenljiva korišćena u SQL naredbi tada ta SQL naredba mora da
bude unutar oblasti definisanosti te host promenljive.

30 Pravila za kodiranje SQL naredbi u C aplikacijama
6.4 Karakter host promenljive
Prilikom deklaracija karakter host promenljivih mora da se eksplicitno navede dužina
promenljive. Deklaracija ne sme da koristi izraz radi definiasanja dužine karakter
promenljive. U C-u char zauzima jedan bajt u memoriji i nema potrebe za navodjenjem
NUL (x’00’). char[n] predstavlja niz karaktera koji se završava sa NUL. Pošto je
navodjenje dužine u char[n] opciono u C-u, i pošto C kompilator dodaje NUL na kraj
niske sledi da u C-u relno ne postoji koncept karaktera fiksne dužine.

Deo II
Transakcije, restart i oporavak u
programu

Glava 7
Uvod
Sadržaj ovog dela i narednog koji se odnosi na konkurentnost su u velikoj meri isprepletani,
i predstavljaju deo jedne šire oblasti koja se naziva obrada transakcija. Iz čisto praktičnih
razloga izvršena je podela na dve celine. U ovom delu ćemo se posebno koncentrisati na
mogućnost oporavka od greške u programima.
Oporavak (eng. recovery) u bazi podataka označavaju na prvom mestu oporavak same
baze, tj. restauraciju stanja baze do trenutka kada je obezbedjena korektnost njenog
sadržaja. Restauracija se vrši posle svakog dogadjaja koji bazu dovodi u stanje nekonzistentnosti.
Osnovni princip na kome se zasniva oporavak baze je redundantnost.

Glava 8
Transakcije
Transakcija predstavlja logičku jedinicu posla. Razmotrimo sledeći primer: treba podići
novac za žiro računa u banci i uložiti ga na tekući račun. Obe operacije predstavljaju
jednu transakciju. Transakcija je nedeljiva - ne može se desiti da je jedna od njenih komponenti
uspešno završila a druga ne. U slučaju greške kod bilo koje komponente koja ulazi
u transakciju, vrši se poništavanje akcija bilo koje od komponenti te transakcije, koje su
izvršene u okviru te transakcije.
Sistemska komponenta koja obezbedjuje rad sa transakcijama se u RDBMS naziva nadzornik
transakcija (eng. transaction manager). Glavne operacije koje nadzornik izvodi su
potvrda i poništavanje transakcije.
Potvrda transakcije (eng. COMMIT) signalizira uspešan završetak transakcije, i ponovo
uspostavljanje konzistentnog stanja u bazi. Na osnovu toga, sve promene izvršene u
transakciji postaju stalne i dostupne i ostalim korisnicima.
Sintaksa COMMIT naredbe je:
+-WORK-+
>>--COMMIT------+-------+-----------------------------------><
Poništavanje transakcije (eng. ROLLBACK) signalizira neuspešan završetak transakcije.
Radi uspostavljanja (prethodnog) konzistentnog stanja u bazi, sve promene učinjene u ovoj
transkaciji se poništavaju.
Sintaksa ROLLBACK naredbe je:
+-WORK-+
>>--ROLLBACK--+------+--+-------------------------------+---------------><
+-TO SAVEPOINT--+-----------+---+
+-svpt-name-+
Više detalja o transakcijama i oporavku biće u kursu koji se odnosi na administraciju
baze podataka. U ovom trenutku za nas je interesantan oporavak programa u slučaju
neuspešnog završetka transakcije. Opšte pravilo koje treba primenjivati u ovakvim
slučajevima je da sve vrednosti koje su neophodne za restauraciju transakcije treba čuvati
u programskim promenljivima, a ne u bazi podataka. Tipičan primer ove situacije je odnos
transakcija i kursora, kao i postupak za oporavak kursora po završetku transakcije.

36 Transakcije
8.1 Jedinica oporavka i otvoreni kursori
Ako aplikativni program završava jedinicu oporavka (tj. ako je primenjen ili COMMIT
ili ROLLBACK) svi otvoreni kursori se automatski zatvaraju od strane DB2. Izuzetak
predstavlja jedino kursor deklarisan sa WITH HOLD opcijom koji može ostati otvoren
i posle izvršavanja COMMIT naredbe (ali ne i posle ROLLBACK naredbe). Korisnik
može ponovo da otvori kursor ali u tom slučaju obrada počinje od početka tabele. Da
bi se ponovo uspostavila pozicija kursora na sledećem redu od onog na kome se program
nalazio u trenutku COMMIT-a potrebno je koristiti posebnu tehniku.
Primer: Neka je potrebno ažurirati podatke za sve snabdevače koji se javljaju u tabeli snabdevača,
pri čemu je potrebno izvršiti COMMIT na svakih 100 promenjenih ili izbrisanih
redova.
Rešenje je moguće izvesti na sledeći način:
1. Odredi se donja granica vrednosti nekog atributa (koji ima jedinstvene vrednosti) u
tabeli . Neka je to uradjeno za npr. šifru snabdevaca
srbr_min =.... : srbr_min
ORDER BY SRBR;
2. Izvršiti otvaranje kursora i čitanje podataka iz tabele (red po red):
EXEC SQL OPEN IZDKURS;
.
.
.
EXEC SQL FETCH SKURS INTO :srbr, ...
Svaki put kada se izvrši čitanje podataka ažurira se vrednost u host promenljivoj
srbr. Kada program (uspešno) izvrši COMMIT ili ROLLBACK naredbu, potrebno
je vrednost iz srbr-a prepisati u srbr min. Pri sledećem otvaranju kursora, donja
granica uredjene tabele je vrednost sloga koji je već pročitan, tako da se čitaju samo
preostali redovi. U ovom slučaju je vrlo značajno što se vrednost donje granice čuva
u programskoj promenljivoj, a ne promenljivoj baze podataka.
3. Kada se menjaju ili brišu redovi treba koristiti pojedinačne UPDATE ili DELETE
naredbe. Npr za brisanje,
EXEC SQL DELETE FROM S WHERE SRBR = :sifsnabd
ne može se koristiti kursor (DELETE CURRENT) pošto definicija kursora uključuje
ORDER BY klauzulu.

Opšti algoritam 37
Primer ovakvog oporavka je prikazan u programu primer16.
Napomena 3
Ova tehnika ne obezbedjuje i oporavak za ne-DB2 resurse koji se eventualno koriste u
programu, kao npr. sekvencijalne izlazne datoteke, datoteke izveštaja, itd.
8.2 Opšti algoritam
Obično se za kolonu po kojoj se vrši uredjivanje kursora bira primarni ključ. Opšte pravilo,
koje se može primeniti i u slučaju da se primarni ključ sastoji od više komponenti može
se izložiti na sledeći način:
1. Opšti oblik definicije kursora za oporavak i repozicioniranje je
declare c1 cursor for
SELECT ...
FROM ...
WHERE ...nasi predikati...
AND ...predikati za repozicioniranje...
ORDER BY ...kljuc za repozicioniranje...
2. Program u najvećem broju slučajeva ima sledeću strukturu:
if restart then
restauracija promenljivih
do until kraj jedinice posla
open c1
do until sqlstate = ’02000’ or vreme-za-commit /* sqlcode = 100 */
......
end
close c1
commit
cuvanje promenljvih za restart
end
brisanje promenljivih za restart
end /* programa */
3. Zatvaranje i ponovo otvaranje kursora treba da eliminiše slogove koji su već
bili obradjeni. Zbog toga treba prilagoditi deklaraciju kursora na sledeći način
(poslednji ključ predstavlja oznaku za poslednju poznatu donju granicu preostale
uredjene tabele):
(a) Ako se primarni ključ sastoji od samo jedne kolone
declare scan cursor for select .... from ....
where primarni_kljuc > :poslednji_kljuc
order by primarni_kljuc
(b) Ako primarni ključ ima više od jedne kolone (označimo ih sa c1 i c2):
i. Rešenje sa OR (indeksni sken bez uparivanja)

38 Transakcije
declare scan cursor for select ... from ...
where ostali predikati
and (c1 = :poslednji_c1 and c2>:poslednji_c2)
or (c1 > :poslednji_c1)
order by c1, c2
Pristupni put je označen kao indeksni sken bez uparivanja. DB2 će čitati
sve indeksne stranice da bi se pronašli odgovarajući slogovi. Sort nije potreban
ako postoje indeksi na c1 i c2. Ovo rešenje je jako sporo za velike
tabele. Upotreba kursora sa WITH HOLD delimično rešava problem zbog
čuvanja pozicije. Ukoliko se to ne uradi, DB2 skenira kompletan indeks,
pri prvom fetchu, do nailaska na prvi odgovarajući upis u indeksu posle
svakog commit-a.
ii. Rešenje sa AND NOT (indeksni sken sa uparivanjem):
declare scan cursor for select ... from ...
where ostali predikati
and (c1 >= :poslednji_c1)
and not (c1 = :poslednji_c1 and c2=...)
and not (c1 = .... and c2 < ...)
and not (c1 = .... and c2 = ... and c3 < ....)
... .....................
and not (c1 = .... and c2 = ... and c3 = .... and cn =’. Dodatni predikati se dodaju upotrebom OR radi eliminisanja
slogova koji su već bili obradjeni. Broj uparenih kolona (za pretraživanje preko
indeksa) je i dalje ograničen na jedan.
declare scan cursor for select ... from ...
where ostali predikati
and (c1 >= :poslednji_c1)
and (c1 > :poslednji_c1
OR (c1 = :poslednji_c1 and c2 >:poslednji_c2))
order by c1, c2
(d) Rešenje sa više kursora:
declare scan1 cursor with hold
if restart
for select .... open scan2

Tačke čuvanja 39
from ..... do until sqlstate=’02000’
where ostali_predikati fetch scan2
and (c1>:poslednji_c1) ....
order by c1, c2 end
close scan2
declare scan2 cursor with hold
for select .... main:
from ..... do until end
where ostali_predikati open scan1
and (c1=:poslednji_c1 .....
and c2>:poslednji_c2)
end
order by c1, c2
Nedostatak AND NOT rešenja je što ono još uvek ne uparuje obe kolone. To nije
ozbiljan problem ukoliko je broj duplikata u prvoj koloni veliki. Ovaj problem
se može zaobići uvodjenjem više kursora. Na početku otvorimo kursor scan1
koji će vratiti odgovarajući broj redova. Kako koristimo WITH HOLD, ovaj
kursor ce moći da se koristi posle commit-a, jer mu se čuva pozicija. Kada dodje
do commit-a, ne možemo jednostavno da nastavimo da koristimo scan1 jer neće
biti obradjen slog sa vrednostima (C2>poslednji C2 and C1 = poslednji C1).
Stoga moramo da koristimo drugi kursor scan2. Kursor vraća ostale slogove za
C1=poslednji C1. Kada se stigne do kraja kursora (sqlstate=’02000’), nastavljamo
sa korišćenjem scan1. Od svih slučajeva, ovaj je najidelaniji za uparivanje.
8.3 Tačke čuvanja
Alternativan tehnika prethodno opisanim metodama je korišćenje tačaki čuvanja (savepoints).
Tačka čuvanja je mesto unutar logičke jedinice posla na koju se može izvršiti
oporavak relacione baze podatak aposle izvršenih promena. Tačka čuvanja se postavlja
naredbom SAVEPOINT.
Sintaksa naredbe SAVEPOINT je:
+------------------------------------------------------------------------+
| |
| |
| >>--SAVEPOINT--svpt-name---------------------------------------------> |
| +-UNIQUE-+ |
| |
| (1) |
| >--ON ROLLBACK RETAIN CURSORS----------------------------------------> |
| |
| (1) |
| +-ON ROLLBACK RETAIN LOCKS----+ |
| >------------------------------------------------------------------->< |
| |
| Note: |
| (1) These clauses can be specified in either order. |

40 Transakcije
| |
| |
+------------------------------------------------------------------------+
Značenja ključnih reči su:
• svpt-name predstavlja identifikator koji označava tačku čuvanja. Maksimalna dužina
identifikatora je 128 bajtova.
• UNIQUE označava da aplikativni program en može ponovo da koristi ime unutar
jedinice posla. U slučaju da se unutar iste jedinice posla nadju dve tačke čuvanja
sa istim imenom javlja se greška. Ako se ne navede UNIQUE tada navodjenje nove
tačke čuvanja sa istim imenom poništava već postojeću tačku i formira novu.
• ON ROLLBACK RETAIN CURSORS označava da se kursor otvoren posle ove tačke
prekida ne prati i zato ne zatvara pri rollback-u na tu tačku čuvanja. Iako ovakvi
kursori ostaju otvoreni oni mogu da budu i nekorisni (npr. ako je oporavak na tačku
prekida prouzrokovao da se poništi unošenje sloga na koji je kursor pozicioniran,
korišćenje kursora za ažurriranje ili brisanje sloga generiše grešku.
• ON ROLLBACK RETAIN LOCKS označava da se ključevi zahtevani posle tačke
prekida ne prate i zato ne oslobbadajaju pri oporavku na tu tačku prekida.
U okviru jedne aplikacije se može pstaviti proizvoljan broj tačaka čuvanja. Kada tačak v
cuvanja više nije potrebna u aplikaciji ona se briše korišćenjem RELEASE SAVEPOINT
naredbe. Sinataksa RELEASE SAVE POINT naredbe je
+-TO-+
>>--RELEASE---+----+-----SAVEPOINT--svpt-name---------><
Njenim izvršavanjem se briše tačak čuvanja svpt-name i sve tačke čuvanja definisane
posle nje u istoj jedinici posla.
Povratak na neku tačku prekida se vrši naredbom COMMIT TO SAVEPOINT. Ako se
ne navede ime tačke čuvanja vrši se oporavak na poslednju aktivnu tačku.
Korišćenje tačaka čuvanja za poništavanje promena unutar jedinice posla
Kada je aktivna tačka čuvanja nije moguće pristupiti udaljenoj lokaciji korišćenjem trodelnih
imena ili aliasa na ta imena. Medjutim, DRDA pristup može da se koristi uz eksplicitnu
CONNECT naredbu.
Primer: postavljanje tačke čuvanja pri distribuiranoj obradi.
sledeće naredbe:
1. Postavi tačku čuvanja C1
2. Izvršava neku obradu u lokalu
3. Izvrši CONNECT naredbu na udaljeni server
4. Postavi tačku čuvanja C2
Neka aplikacija izvršava
Pošto je tačak C1 postalvjena pre konekcije na udaljeni server, poznata je jedino na
lokalnom serveru. Tačka C2 je postavljena posle konekcije na udlajeni server i poznata je
jedino na tom udaljenom serveru, ali ne i u lokalu.
Tačke čuvanja se automatski oslobadjaju po završetku jedinice posla.

Tačke čuvanja 41
Ograničenja u korišćenju tačaka čuvanja
Tačke čuvanja se ne mogu koristiti u:
1. globalnim transakciama (u RRSAF-u)
2. trigerima
3. korisnički definisanim funkcijama
4. uskladištenim procedurama, korisnički definisanim funkcijama ili trigerima koji su
ugneždeni unutar drugih trigera ili korisnički definisanih funkcija
Detaljnije informacije o SAVEPOINT, ROLLBACK TO SAVEPOINT, i RELEASE
SAVEPOINT naredbama se mogu naći u DB2 SQL, Reference, deo 5.

Deo III
Dodatne programske tehnike

Glava 9
Dinamički SQL
9.1 Uvod
SQL naredbe ugnježdene u viši programski jezik se nazivaju statičke SQL naredbe ako
su u potpunosti odredjene u vreme pisanja programa, i vezane pre izvršavanja programa.
Statičke SQL naredbe se mogu koristiti kada je pre izvršavanja programa poznato koje
SQL naredbe treba izvršiti u aplikaciji.
SQL naredbe ugnježdene u viši programski jezik se nazivaju dinamičke SQL naredbe
ako nisu poznate u vreme pisanja programa. Naredbe dinamičkog SQL-a se pripremaju
za izvršavanje, vezuju i izvršavaju u vreme izvršavanja programa. Postoje četiri tipa
dinamičkog SQL-a:
1. Ugnježdeni dinamički SQL. Aplikacija korisnika upisuje SQL naredbe u host
promenljive i uključuje PREPARE i EXECUTE naredbe kojima zahteva od DB2
pripremu i izvršavanje sadržaja host promenljivih u vreme izvršenja. Programi koji
sadrže ugnježdeni dinamički SQL moraju da se prekompiliraju i vezuju.
2. Interaktivni SQL. U ovu vrstu dinamičkog SQL-a spadaju naredbe koje korisnik unosi
preko SPUFI opcije. Tako unete naredbe DB2 priprema i izvršava kao dinamičke
SQL naredbe.
3. Odloženi dinamički SQL. Naredbe koje pripadaju ovoj grupi nisu ni potpuno statičke
ni potpuno dinamičke. One su ugnježdene u program (kao i statičke naredbe), ali
se pripremaju u vreme izvršenja (kao dinamičke naredbe). DB2 obradjuje odložene
ugnježdene SQL naredbe sa pravilima za vreme vezivanja. Na primer, DB2 koristi
autorizovani ID i kvalifikator koji su odredjeni u vreme vezivanja. Naredbe ove grupe
se koriste za privatni protokol DB2 pri pristupu udaljenim podacima.
4. Dinamički SQL koji se izvršava preko CLI (Call Level Interface) funkcija. CLI pozivi
funkcija koji su sadržani u aplikaciji prenose dinamičke SQL naredbe kao argumente.
Programi koji sadrže CLI naredbe ne moraju da se prekompiliraju i vezuju. Programi
koji sadrže CLI se pišu na C jeziku.
9.2 Izbor izmedju dinamičkog i statičkog SQL-a
Upotreba host promenljivih u velikoj meri povećava fleksibilnost naredbi statičkog SQL-a.
Još veća fleksibilnost naredbi se dobija kada se koristi dinamički SQL. U tom slučaju SQL

46 Dinamički SQL
ista naredba može da radi sa različitim tipovima podataka. Ne može se svaka SQL naredba
izvršavati dinamički. U dodatku ?? su prikazane SQL naredbe i način njihove pripreme.
9.2.1 Šta može da uradi program koji koristi dinamički SQL
Program koji koristi dinamički SQL može da prihvati kao ulaz, ili da formira SQL naredbe
u obliku niske karaktera. U najopštijem slučaju, kada nije poznat tip SQL naredbe koju
treba izvršiti, uobičajeni redosled koraka u izvršavanju je sledeći:
1. Prevesti ulazne podatke, uključujući sve parametar markere u SQL naredbe.
2. Pripremiti SQL naredbe za izvršenje, i zahtevati opis rezultujuće tabele.
3. Rezervisati, u slučaju SELECT naredbe, dovoljno glavne memorije za smeštanje
dobijenih podataka.
4. Izvršiti naredbu ili pročitati redove sa podacima.
5. Obraditi vraćene informacije.
6. Obraditi vraćene SQL kodove.
Ovaj niz koraka se može pojednostaviti ako nije u pitanju SELECT naredba.
9.2.2 Performanse statičkog i dinamičkog SQL-a
SQL naredba zahteva pristupni put za pristup DB2 podacima. U slučaju statičkog SQL-a
koji ne sadrži ulazne host promenljive, DB2 odredjuje pristupni put pri vezivanju programa
ili paketa. Ova kombinacija daje najbolje performanse, jer je pristupni put već
odredjen pri izvršavanju programa.
Ako naredba sadrži statički SQL sa ulaznim host promenljivima, vreme kada DB2 odredjuje
pristupni put zavisi od opcije REOPT(VARS) / NOREOPT(VARS) pri vezivaju.
Ako se navede NOREOPT(VARS) pristupni put se odredjuje pri vezivanju, dok se za
REOPT(VARS) pristupni put odredjuje pri vezivaju, i ponovo pri izvršavanju uzimajući
u obzir konkretne vrednosti host promenljivih, parametar markera i specijalnih registara.
Ova opcija zahteva dodatno vreme za odredjivanje pristupnog puta pri izvršavanju, ali
može dovesti do poboljšanja performansi u slučaju da DB2 odredi značajno bolji pristupni
put.
Za naredbe koje sadrše dinamički SQL, DB2 odredjuje pristupni put u vreme izvršavanja,
odmah posle pripreme naredbe. Ovo je razlog lošijih performansi naredbi sa dinamičkim
SQL-om, ali u slučaju da se ista naredba izvršava veći broj puta može se koristiti keširanje
dinamičkih naredbi radi smanjenja vremena potrebnog za pripremu.
Preporuka je da se za naredbe sa dinamičkim SQL-om koristi REOPT(VARS). U tom
slučaju je potrebno kodirati PREPARE naredbu radi smanjenja overhead-vremena. Sa
REOPT(VARS) DB2 priprema SQL naredbu u isto vreme kada obradjuje OPEN ili
EXECUTE za tu naredbu. Izvršavanje DESCRIBE naredbe pre PREPARE naredbe
ili korišćenje PREPARE naredbe sa INTO parametrom uzrokuje dvostruko izvršavanje
pripreme naredbe (drugi put sa unetim vrednostima promenljivih). Da bi se izbeglo
trošenje vremena na dvostruku pripremu, u naredbama koje koriste kursor, u programu
treba kodirati DESCRIBE naredbu posle OPEN naredbe.

Keširanje naredbi sa dinamičkim SQL-om 47
9.3 Keširanje naredbi sa dinamičkim SQL-om
Cena pripreme naredbi sa dinamičkim SQL-om se može naglo povećati u slučaju učestale
primene COMMIT operacije. U tom slučaju se mora ponovo primeniti PREPARE naredba
da bi se SQL naredba uspešno izvršila. Za SELECT naredbe opcija WITH HOLD može
donekle da ublaži ovaj zahtev, ali zahteva da kursor bude otvoren u vreme COMMIT-a, a
pored toga zadržava i ključeve nad svim objektima od kojih zavisi pripremljena naredba.
DB2 može smanjiti cenu izvršavanja naredbi sa dinamičkim SQL-om ako se pripremljena
dinamička naredba sačuva u kešu. NA taj način se izbegava ponovljena priprema iste
naredbe. Keširane naredbe mogu biti deljene izmedju različitih thread-ova (DB2 niti),
planova ili paketa. Samo naredbe SELECT, UPDATE, INSERT i DELETE mogu da
se keširaju. Medjutim, ako se koristi REOPT(VARS) tada naredbe vezane u takvim
planovima i paketima ne mogu da se keširaju.
Keširanje se omogućuje pri instalaciji DB2. Da bi se naredbe keširale one moraju biti
identične. Pri tome moraju da vaše sledeći uslovi:
• Naredbe koje se keširaju moraju biti identične. Npr. naredbe ’UPDATE DELOVI SET
TEZINA = TEZINA + 10;’ i ’UPDATE DELOVI SET TEZINA = TEZINA + 10 ;’ nisu
identične i za drugu naredbu se ne može koristiti keširana verzija prve.
• Autorizovani ID koji je korišćen pri pripremi prve, mora biti korišćen i pri pripremi
druge naredbe.
• Vrednosti sledećih opcija moraju biti identične pri vezivanju dva paketa u kojima se
nalaze naredbe koje učestvuju u keširanju:
– CURRENTDATA
– DYNAMICRULES
– ISOLATION
– SQLRULES
– QUALIFIER
• Vrednosti specijalnih registara CURRENT DEGREE i CURRENT RULES pri
pripremi druge naredbe moraju biti isti kao i vrednosti pri pripremi prve naredbe.
9.4 Čuvanje pripremljene naredbe posle COMMIT-a
Opcija pri vezivanju KEEPDYNAMIC(YES) dozvoljava čuvanje dinamičkih naredbi posle
commita-a u nekom od procesa. Aplikacija koja je vezana sa ovom opcijom može jednom
da koristi PREPARE naredbu za tu SQL naredbu. Npr.
PREPARE NAREDBA1 FROM ....
EXECUTE NAREDBA1
COMMIT
.
.
.
EXECUTE NAREDBA1

48 Dinamički SQL
COMMIT
.
.
.
9.5 Izbor host jezika za aplikacije sa dinamičkim SQL-om
Programi koji koriste dinamički SQL obično se pišu u assembler-u, C jeziku, PL/I jeziku
i verzijama COBOL jezika koje su različite od OS/VS COBOL-a. Ne-SELECT naredbe i
SELECT naredbe sa fiksnom listom argumenata se mogu pisati u svim host jezicima koje
podržava DB2.
Primeri PL/I programa koji sadrži dinamički SQL se nalaze u
’DSN510.SDSNSAMP(DSNTEP2)’ i ’DBKURS0.T.PLI(DYNSQL)’.
9.6 Dinamički SQL sa ne-SELECT naredbom
Ovaj slučaj predstavlja najjednostavniji način korišćenja dinamičkog SQL-a. Program koji
izvršava ovakve naredbe sa dinamičkim SQL-om mora da uključi sledeće korake:
1. Da uključi SQLCA.
2. Da učita ulaznu SQL naredbu (npr. u nisku karaktera).
3. Da izvrši naredbu. Izvršavanje je moguće na dva načina:
(a) upotrebom EXECUTE IMMEDIATE naredbe, i
(b) upotrebom PREPARE i EXECUTE naredbi.
4. Da obradi SQL greške koje mogu da se jave.
9.6.1 Izvršavanje upotrebom EXECUTE IMMEDIATE
Neka treba učitati sa tastature SQL naredbu kojom se briše red iz tabele DELOVI, i zatim
je izvršiti. Segment PL/I programa koji izvršava ovaj zahtev ima sledeći izgled:
...
dcl niska char(100) var;
...
get(niska); /* npr. niska=’DELETE FROM DELOVI WHERE DRBR=’D9’ */
EXEC SQL EXECUTE IMMEDIATE :niska;
...
9.6.2 Izvršavanje upotrebom PREPARE i EXECUTE
Pretpostavimo da treba izvršiti DELETE naredbu više puta uz upotrebu spiska sa šiframa
delova. U slučaju da ovaj zahtev možemo da pišemo kao statički SQL, njegov izgled bi
bio sledeći:

Dinamički SQL sa ne-SELECT naredbom 49
--cita se vredost DRBR sa tastature u host promenljivu drbr--
DO UNTIL (DRBR = ’**’);
EXEC SQL DELETE FROM DELOVI WHERE DRBR = :drbr;
--cita se vredost DRBR sa tastature u host promenljivu drbr--
END;
Iz ciklusa se izlazi kada se unese ’**’ kao vrednost DRBR. Ukoliko znamo da će se ovakav
upit koristiti samo za tabelu DELOVI, tada možemo da koristimo mnogo efikasniji statički
SQL. Medjutim, ako je ovakav upit potrebno izvršiti i npr. za tabelu POSILJKE, tada
statički SQL ne može da se koristi. Iako host promenljive mogu da sadrže DRBR, one
ne mogu da sadrže ime tabele, tako da ova naredba mora da se izvršava dinamički. U
programu su pored toga nužne i sledeće izmene:
• Umesto host promenljivih koriste se parametar markeri.
• Za pripremu ovakve SQL naredbe koristi se PREPARE.
• Umesto EXECUTE IMMEDIATE koristi se EXECUTE.
Parametar markeri
Umesto host promenljivih u naredbama se zamenjuju parametar markeri, koji su označeni
sa znakom pitanja ?. Tako, umesto prethodne naredbe treba pripremiti naredbu
DELETE FROM DELOVI WHERE DRBR = ?. Svaka host promenljiva se asocira sa parametar
markerom.
PREPARE naredba
Da bi se shvatila suština PREPARE naredbe, može se smatrati da je EXECUTE IM-
MEDIATE razbijeno na dve naredbe: PREPARE i EXECUTE. Prepare naredba prevodi
karakter nisku u SQL naredbu, a EXECUTE je izvršava. Primer: Neka programska
promenljiva niska sadrži ’DELETE FROM DELOVI WHERE DRBR=?’. Da bi se izvršila
njena priprema i pripremljenom obliku dodelilo ime S1, potrebno je izvršiti
EXEC SQL PREPARE S1 FROM :NISKA;
Pripremljena naredba još uvek sadrži parametar marker umesto koga se mora zameniti
vrednost pri izvršavanju naredbe. U pripremljenoj naredbi naziv tabele je fiksan, ali
parametar marker dopušta izvršavanje iste naredbe više puta za različite vrednosti DRBR.
EXECUTE naredba
EXECUTE naredba izvršava prethodno pripremljenu SQL naredbu, pri čemu kao argumente
ima jednu ili više host promenljivih ili host strukturu koja sadrži vrednosti koje
zamenjuju parametar markere. Posle pripreme, ista naredba se može izvršavati više puta
u transakciji. U slučaju da COMMIT ili ROLLBACK unište pripremljenu verziju naredbe,
priprema se mora ponovo izvršiti.
Radi izvršavanja pripremljene naredbe S1, uz upotrebu vrednosti parametra koja je upisana
u promeljivoj SIFRADELA, u programu treba kodirati
EXEC SQL EXECUTE S1 USING :SIFRADELA;

50 Dinamički SQL
Kompletan primer, ekvivalentan prethodno navedenom statičkom, je
--cita se naredba koja sadrzi parametar marker u NISKU --
EXEC SQL PREPARE S1 FROM NISKA;
--cita se vrednost za SIFRADELA --
DO UNTIL (DRBR = ’**’);
EXEC SQL EXECUTE S1 USING :SIFRADELA;
--cita se vrednost za SIFRADELA --
END;
U slučaju da ima više od jednog parametar markera, njihove vrednosti se navode u USING
klauzuli EXECUTE naredbe.
9.7 Dinamički SQL sa fiksnom listom u SELECT naredbi
SELECT naredba sa fiksnom listom vraća red koji sadrži poznat broj vrednosti poznatog
tipa (nije neophodno da se unapred zna broj slogova koji će se dobiti upitom). Kada se
koristi SELECT naredba sa fiksnom listom, unapred je poznat broj i tip host promenljivih
koje treba deklarisati za čuvanje rezultata.
Aplikativni program mora da izvrši sledeće operacije:
1. Da uključi SQLCA
2. Da učita ulaznu SQL naredbu (npr. u nisku karaktera pod imenom NISKA).
Naredba može da sadrži parametar markere.
3. Da deklariše kursor za tu naredbu i dodeli mu ime (npr. C1).
EXEC SQL DECLARE C1 CURSOR FOR NISKA;
4. Da pripremi naredbu za izvršenje:
EXEC SQL PREPARE NAREDBA FROM :NISKA;
5. Da otvori kursor. Otvaranje kursora izračunava vrednost SELECT naredbe koja je
nazvana NAREDBA. Moguća su dva oblika naredbe za otvaranje kursora:
(a) Bez parametar markera
EXEC SQL OPEN C1;
(b) Sa parametar markerima (npr. sa 3 parametar markera):
EXEC SQL OPEN C1 USING :VRED1, :VRED2, :VRED3;
6. Da pročita slogove iz rezultujuće tabele:
EXEC SQL FETCH C1 INTO :TEZINA, GRAD;
Ključna stvar je što je unapred poznat broj i tip host promenljivih koje treba navesti
iza INTO klauzule.

Dinamički SQL sa promenljivom listom u SELECT naredbi 51
7. Da zatvori kursor:
EXEC SQL CLOSE C1;
8. Da obradi SQL greške koje mogu da se jave.
9.8 Dinamički SQL sa promenljivom listom u SELECT
naredbi
SELECT naredba sa promenljivom listom vraća red koji sadrži nepoznat broj vrednosti
nepoznatog tipa. Ovaj slučaj dinamičkog SQL-a se obradjuje uz upotrebu pokazivača.
Aplikativni program mora da izvrši sledeće operacije:
1. Da uključi SQLCA
2. Da učita ulaznu SQL naredbu (npr. u nisku karaktera pod imenom NISKA).
3. Da pripremi i izvrši naredbu. Ovaj korak je mnogo kompleksniji od sličnih koraka
u prethodnim slučajevima. U ovom priručniku će biti naveden samo redosled akcija
koje treba izvršiti. Primeri PL/I programa koji izvršava ovaj oblik SELECT naredbe
se nalaze u
’DBKURS0.T.PLI(DYNSQL)’ i ’DSN510.SDSNSAMP(DSNTEP2)’.
Redosled koraka je sledeći:
(a) Uključivanje SQLDA (SQL descriptor area).
(b) Deklaracija kursora i priprema promenljive naredbe.
(c) Dobijanje informacija o tipu svake kolone u rezultujućoj tabeli.
(d) Odredjivanje veličine memorije potrebne za čuvanje slogova pročitanih podataka.
(e) Otvaranje kursora.
(f)
Čitanje slogova.
(g) Eventualno zatvaranje kursora i oslobadjanje glavne memorije.
U slučaju upotrebe parametar markera, algoritam se dodatno komplikuje.
4. Obrada grešaka koje nastaju pri izvršavanju.
Opis kompletnog postupka za rad sa SELECT naredbom sa promenljivom listom se nalazi
u knjizi Application Programming and SQL Guide.

Glava 10
Podešavanje upita
10.1 Opšta pravila
Ako se upit koga ste napisali sporo izvršava, prvo proverite da li su zadovoljena sledeća
opšta pravila:
1. Da li je upit kodiran na najjednostavniji mogući način? Proverite da li se izdvajaju
nepotrebne kolone i da li postoje ORDER BY ili GROUP BY koji nisu potrebni.
2. Da li su svi predikati korektno kodirani?
• Proverite da li su svi predikati za koje smatrate da treba da budu indeksibilni
zaista i takvi. U knjizi Application Programming and SQL Guide, deo 6.3.3.2,
nalazi se tabela sa spiskom predikata koji mogu da budu indeksibilni.
• Pokušajte da uklonite bilo koji predikat koji je redundantan ili koji vam nije
potreban.
• Proverite da deklarisana dužina bilo koje host promenljive nije veća od dužine
atributa sa kojim se poredi. Ako je veća, tada je predikat u fazi 2 i za njega se
ne može koristiti indeksni sken.
3. Da li postoje podupiti u vasem upitu? Ne postoji apsolutno pravilo po kome bi
odlučivali da li da kodirate podupit ili ne. Opšta pravila su:
• Ako postoji efikasan indeks nad tabelom u podupitu tada je korelirani upit
verovatno najbolji način kodiranja podupita.
• Ako nema efikasnog indeksa nad tabelom u podupitu, tada je verovatno nekorelirani
upit efikasniji.
• Ako postoji više podupita u jednom upitu, poredjajte ih po redosledu efikasnosti.
Npr.
SELECT * FROM POSILJKE
WHERE SRBR IN (Upit 1)
AND DRBR IN (Upit 2)
DB2 izvršava podupite u onom redosledu u kome su navedeni u WHERE
klauzuli. Neka podupit 1 odbacuje 10% od ukupnog broja slogova, a podupit
2 80%. Ako se Predikat u podupitu 1 (označimo ga sa P1) izvršava 1000 puta,

54 Podešavanje upita
tada se predikat u podupitu 2 (označimo ga sa P2) izvršava 900 puta. U obrnutom
redosledu upita P2 bi se izvršavao 1000 puta, ali P1 samo 200 puta, što
u ukupnom zbiru znači 700 provera manje.
Pogledajte deo koji se odnosi na pisanje efikasnijih podupita u okviru ove.
Ako ima sumnje u efikasnost upita treba izvršiti EXPLAIN i kodirati redosled
podupita na osnovu dobijenih rezultata.
4. Da li vaš upit uključuje agregatne funkcije? U tom slučaju proverite da li su one
kodirane na najjednostavniji mogući način.
5. Da li imate ulazne promenljive u predikatu u statičkoj SQL naredbi? Da bi efikasnije
kodirali ovaj slučaj pogledajte u delu o dinamičkom SQL-u kodiranje RE-
OPT(VARS) opciju pri vezivanju.
6. Da li imate problema sa korelacijom kolona? Za dve kolone se kaže da su u korelaciji
ako se njihove vrednosti ne menjaju nezavisno jedna od druge. DB2 ne može da
odredi najbolji pristupni put kada upit sadrži korelirane kolone.
7. Da li upit koristi izraze sa nekolonskim funkcijama? Sledeći predikat kombinuje
kolonu sa vrednostima koje nisu iz kolone na jednoj strani operatora poredjenja:
WHERE KOL + (:hostp1 * KOL)>5000
Isti izraz može biti mnogo efikasnije izračunar ako se napiše na sledeći način:
WHERE KOL > 5000/(1 + :hostp1)
Izraz na desnoj strani se naziva nekolonski izraz. Takve izraze DB2 može da izračuna
mnogo ranije, u fazi 1 i zbog toga ovakvi izrazi traže mnogo manje vremena za
izvršavanje.
10.2 Pisanje efikasnijih predikata
Detaljan opis zavisnosti upita od predikata je dat u knjizi Application Programming and
SQL Guide, u delu 6.3.2. Ovde će biti navedeni samo definicija predikata faze 1 i faze 2.
Redovi koji se dobijaju upitom prolaze kroz dve faze u obradi. Predikatima faze 1 se
nazivaju oni koji se mogu primeniti u prvoj fazi, dok se Predikatima faze 2 nazivaju oni
koji se ne mogu primeniti pre faze 2.
Faza kojoj pripada predikat se može odrediti na osnovu njegove sintakse (već pominjana
tabela koja sadrži podatke i o indeksibilnim predikatima), kao i tipa i dužine konstanti
u predikatu. Svi indeksibilni predikati su predikati faze 1. Preporuka je da se koriste
predikati faze 1 kada god je to moguće.
10.3 Efikasna upotreba podupita
U ovom delu će biti opisana neka od uputstava za efikasnije kodiranje podupita.

Efikasna upotreba podupita 55
10.3.1 Korelirani podupiti
Koreliranim podupitom se naziva upit koji se referiše na najmanje jednu kolonu iz
spoljašnjeg upita. Svi predikati koji sadrže korelirane podupite su predikati faze 2.
Primer: Dobiti imena snabdevača koji isporučuju deo D2.
select sime
from snabdevaci
where exists
( select *
from posiljke
where srbr = snabdevaci.srbr
and drbr = ’D2’ );
Svaki korelirani podupit se izračunava za svaki kvalifikovani red spoljašnjeg upita na koji
se referiše. U prethodnom primeru:
1. DB2 čita red iz tabele snabdevača.
2. Traži vrednost SRBR iz tog reda, u tabeli koja se nalazi u memoriji. U tabeli u
memoriji se nalazi vrednost izvršavanja podupita.
3. Ako vrednost SRBR nije u memoriji, izvršava se podupit.
4. Upisuju se vrednost SRBR i rezultat upita u memoriju.
5. Vraća vrednost tekućeg sloga tabele snabdevaci natrag u aplikaciju.
Ovaj postupak se ponavlja za svaki slog iz tabele snabdevaci.
10.3.2 Nekorelirani podupiti
Nekorelirani upiti su oni koji nemaju reference na spoljašnje upite.
Primer: Dobiti imena snabdevača koji isporučuju deo D2.
select sime
from snabdevaci
where srbr in
( select srbr
from posiljke
where drbr = ’D2’ );
Nekorelirani podupit se izvršava jednom pri otvaranju kursora vezanog za ovaj upit. Akcija
DB2 zavisi od toga da li se kao rezultat vraća jedan ili više slogova.
Ako podupit vraća najviše jedan red, tada su pravila koja se primenjuju radi odredjivanja
u kojoj je fazi predikat koji sadrži unutrašnji upit identična pravilima za pojedinačne
promenljive. Ako pak podupit sadrži više od jednog reda, DB2 pokušava da ga svede na
prethodni slučaj (to je uspešno ako postoji interval poredjenja zajedno sa SOME, ANY
ili ALL). U tom slučaju se, za odredjivanje faze predikata, primenjuju ista pravila kao i
na podupit koji vraća najviše jedan red.

56 Podešavanje upita
10.3.3 Transformacija podupita u spajanje
Podupit može biti transformisan u spajanje izmedju rezultujuće tabele podupita i rezultujuće
tabele spoljašnjeg upita, uz uslov da transformacija ne uvodi redundantnost. DB2
primenjuje ovu transformaciju ako:
1. Podupit se nalazi u WHERE klauzuli.
2. Podupit ne sadrži GROUP BY, HAVING ili agregatne funkcije.
3. Podupit ima samo jednu tabelu u FROM klauzuli.
4. Select lista u podupitu sadrži samo jednu kolonu, za koju jedinstveni indeks garantuje
jedinstvene vrednosti.
5. Operator poredjenja predikata je IN, = ANY ili = SOME
6. Za nekorelirani upit, leva strana predikata je jedna kolona sa istim tipom podataka
i dužinom kao i u koloni podupita.
U izveštaju iz EXPLAIN se informacija da li je podupit transformisan u spajanje
nalazi u koloni QBLOCKNO.
Prethodni upiti sa podupitom mogu da se transformišu u sledeći upit sa spajanjem:
select distinct snabdevaci.sime
from snabdevaci, posiljke
where snabdevaci.srbr = posiljke.srbr
and posiljke.drbr = ’D2’;
10.4 Specijalne tehnike koje utiču na pristupni put
Primedba: naredne tehnike strogo zavise od trenutne verzije DB2. Pri prelasku na novu
verziju softvera, svaku od ovih tehnika treba ponovo proveriti.
10.4.1 Dobijanje informacija o pristupnim putevima
Informacije o pristupnim putevima se mogu dobiti na tri načina:
1. Upotrebom alata Visual Explain.
2. Upotrebom DB2 Performance Monitor-a.
3. Navodjenjem opcije EXPLAIN(YES) pri vezivanju.
10.4.2 Upotreba OPTIMIZE FOR n ROWS
Kada aplikacija izvršava SELECT naredbu, DB2 pretpostavlja da će aplikacija pročitati
sve slogove rezultujuće tabele. Ova pretpostavka je vrlo verovatna u on-line obradama
transakcija ili batch programima. MEdjutim, za interaktivni SQL uobičajeno je da se
definiše upit sa vrlo velikim opsegom slogova koji ga zadovoljavaju, ali se zaista čita samo
prvih nekoliko slogova. U slučaju takvih interaktivnih aplikacija pristupni put DB2 može

Specijalne tehnike koje utiču na pristupni put 57
da ne bude optimalan.
Klauzula OPTIMIZE FOR n ROWS:
• čita samo podskup rezultujućeg skupa,
• daje prioritet čitanju prvih nekoliko slogova.
DB2 koristi ovu klauzulu za izbor pristupnog puta kojim minimizuje vreme odziva za
čitanje prvih nekoliko slogova.
Ova klauzula NE SPREČAVA čitanje svih slogova rezultujuće tabele. Medjutim, ako se
koristi ova klauzula ukupno potrebno vreme može biti značajno veće od vremena koje je
potrebno u slučaju da se ona ne navede.
OPTIMIZE FOR n ROWS se primenjuje samo na upite koji mogu biti primenjeni u
koracima. Ako upit zahteva od DB2 čitanje kompletnog skupa rezultata pre prikazivanja
prvog sloga, ova klauzula se ne primenjuje. Neki od takvih slučajeva su:
• Upit koristi SELECT DISTINCT ili izračunava vredost funkcije samo za jedinstvene
vrednosti, kao u npr. COUNT(DISTINCT ...)
• Koristi se ili GROUP BY ili ORDER BY, pri čemu nema indeksa koji može da
obezbedi željeno uredjenje.
• Postoji agregatna funkcija bez GROUP BY klauzule.
• Upit koristi UNION ili UNION ALL.
10.4.3 Smanjenje broja uparenih kolona
Upotreba indeksa slabih performansi se generalno smanjuje redukovanjem predikata indeksa
koji su upareni sa vodećim kolonama. Smanjenje broja kolona koje su najbolje
uparene može dovesti do različitih efekata u zavisnosti od načina promene predikata.
Promena jednakosnog predikata u BETWEEN predikat
Neka je originalni upit na tabeli KURS
SELECT ....
FROM KURS
WHERE MESTO=’PROJEKTANT’ AND GRAD=’BEOGRAD’
AND NIJEURADIO=’ZAD2’ AND URADIO=’ZAD1’
Neka postoje indeksi indeks1(MESTO, GRAD) i indeks2(NIJEURADIO, URADIO). Posmatrajmo
modifikovani upit:
SELECT ....
FROM KURS
WHERE MESTO BETWEEN ’PROJEKTANT’ AND ’PROJEKTANT’
AND GRAD=’BEOGRAD’
AND NIJEURADIO=’ZAD2’ AND URADIO=’ZAD1’

58 Podešavanje upita
Originalni upit je imao MATCHCOLS 2 (videti kod EXPLAIN-a značenje koje je vezano za
broj ključeva u indeksu koji se koristi za indeksni sken) jer postoje upareni predikati na dve
vodeće kolone u indeksu. Novi upit poseduje MATCHCOLS vrednost 1 zbog BETWEEN
predikata na vodećoj koloni indeksa Indeks1. Indeks2, koji još uvek ima MATHCOLS =
2 će u ovom slučaju biti optimalni pristupni put.
DB2 ne mora da izabere Indeks 2 ako postoji statistika za tabelu KURS. Ako postoji
statistika, izbor pristupnog puta zavisi od filter faktora za predikate MESTO BETWEEN
’PROJEKTANT’ AND ’PROJEKTANT’ i NIJEURADIO=’ZAD2’ AND URADIO=’ZAD1’.
Na sličan način se može onemogućiti upotreba pojedinih indeksa (npr. dodavanjem neutralnog
aritmetičkog predikata, npr. sabiranjem sa 0).
10.4.4 Promena unutrašnjeg u spoljašnje spajanje
Treba eliminisati upotrebu hibridnih spajanja unošenjem unutrašnjeg spajanja u spoljašnje
spajanje, i zatim korišćenjem WHERE klauzule radi eliminacije nepotrebnih slogova.
Primer. Neka želimo da dobijemo rezultate unutrašnjeg spajanja tabela delovi i posiljke:
SELECT DIME, BOJA, DELOVI.DRBR, KOL
FROM DELOVI, POSILJKE
ON DELOVI.DRBR = POSILJKE.DRBR
DB2 će formirati mnogo efikasniji upit sa tabelom delova kao spoljašnjom tabelom u
operaciji spajanja. Da bi se tabela delovi napravila spoljašnjom, treba koristiti operaciju
levog spoljasnjeg spajanja.
SELECT DIME, BOJA, DELOVI.DRBR, KOL
FROM DELOVI LEFT OUTER JOIN POSILJKE
ON DELOVI.DRBR = POSILJKE.DRBR
WHERE DELOVI.DRBR IS NOT NULL;
10.4.5 Ažuriranje statistike u katalogu
Za odredjivanje pristupnih puteva važno je imati ažurnu statistiku u katalogu baze podataka.
Statistika se može ažurirati na dva načina:
1. Ručno. Ovaj način se ne preporučuje zbog mogućnosti eventualnih grešaka koje
mogu negativno da utiču na odredjivanje pristupnog puta.
2. Izvršavanjem RUNSTATS pomoćnog programa i zahtevanjem statistike od koreliranih
kolona W FROM i W NOW. Više reči o RUNSTATS programu biće u kursu
o administraciji baze podataka.

10.5 Osnovno o uskladištenim (stored) procedurama
Uskladištena procedura je prevedeni program, smešten na lokalnom ili udaljenom DB2
serveru, koji može da izvrši SQL naredbe. Tipična uskladištena procedura sadrži dve ili
više SQL naredbe u višem programskom jeziku koje se koriste za obradu. Aplikativni
klijent program koristi SQL naredbu CALL radi poziva uskladištene procedure.
Ove procedure u klijent/server aplikacijama mogu da
• izvrše veliki broj SQL naredbi uz smanjenje saobraća ja kroz mrežu na jednu operaciju
slanja i primanja poruka za niz SQL naredbi.
• pristupaju host promenljivima za koje želite da garantujete sigurnost i integritet.
Da bi uskladištena procedura mogla da se izvršava, mora biti definisana u tabeli
SYSIBM.SYSPROCEDURES. Ova vrsta procedura se može pisati na assembleru, C
jeziku, COBOL-u ili PL/I jeziku. Primeri kodiranja ovih vrsta procedura su dati u
’DSN510.SDSNSAMP’.
Za uskladištene procedure važe sledeća ograničenja:
• Uskladištene procedure mogu da se izvršavaju u DB2 okolini (preko CAF attachment
facilitu) ili u WLM okolini (preko RRSAF attachment facilitu (Recoverable Resuorce
Manager Services).
• U uskladištene procedure ne treba uključivati sledeće SQL naredbe:
– CALL
– COMMIT
– CONNECT
– RELEASE
– SET CONENCTION
– SET CURRENT SQLID
Kada DB2 otkrije ove naredbe menja stanje thread-a u must roll back stanje. Kada
se kontrola vrati pozivajućem programu, on mora da ili uradi ROLLBACK ili da
prekine sa radom, što će prouzrokovati automatski rollback tekuće jedinice posla.
Uskladištene procedure mogu koristiti ili DB2 privatni protokol ili DRDA protokol pri
radu. Ukoliko koristi DRDA protokol, za svaki skup podataka koji želi da se vrati u
pozivajući program procedura mora da deklariše kursor sa opcijom WITH RETURN,
otvori kursor i ostavi ga otvorenog. Procedura se priprema za izvršavanje pomoću sledećeg
niza koraka:
1. Procedura se prekompilira i kompilira.
2. Vrši se linkovanje, pri čemu se bira interfejs modul (CAF ili RRSAF) koji se linkuje
sa procedurom.
3. Svaka procedura se vezuje u paket. Procedura zahteva paket na serveru ali ne i plan.
4. Da bi bila uspešno locirana od srane pozivajućeg programa, procedura se definiše u
tabeli SYSPROCEDURES.

60 Podešavanje upita
5. Potrebno je dati GRANT EXECUTE on PACKAGE .... TO ....; da bi autorizovali
korisnika za izvršavanje paketa.
Procedura se poziva CALL naredbom čiji su argumenti host promenljive deklarisane u
aplikativnom programu. Npr.
EXEC SQL CALL A (:srbr, :status, :sime);
EXEC SQL CALL A (:srbr, :status, ’Jones’);
EXEC SQL CALL :procime (:srbr, :status:, :sime);
Moguće su dve različite konvencije pri linkovanju uskladištenih procedura:
1. SIMPLE: kada ne želimo da pozivajući program prenese NULL vrednosti kao
parametre (niti za slanje niti za primanje).
2. SIMPLE WITH NULLS: kada dopuštamo da pozivajući program prenese NULL
vrednosti kao parametre (bilo za slanje bilo za primanje).
Klijent program koji poziva uskladištene procedure mora biti prekompiliran, kompiliran i
linkovan na klijent sistemu. Uskladištena procedura može biti izvršavana bilo kao glavni
program bilo kao potprogram.
Detaljnije informacije o radu sa uskladištenim procedurama se mogu naći u knjizi Application
Programming and SQL Guide.
10.6 Osnovno o radu sa distribuiranim podacima
Distribuirani podaci su oni koji postoje na nekom sistemu za upravljanje bazama podataka
koji je različit od lokalnog sistema korisnika. Lokalni RSUBP je onaj na kome se vezuje
aplikativni plan. Svi ostali RDBMS-ovi su udaljeni. U daljem tekstu je pretpostavka da
se zahteva servis od udaljenog RSUBP-a. U takvoj situaciji taj RSUBP je server, dok je
lokalni sistem klijent. Aplikacija u jednom trenutku može biti povezana na više servera.
Onaj na kome se trenutno obavlja posao je tekući server.
RSUBP bilo lokalni ili udaljen je poznat DB2 na osnovu naziva svoje lokacije.
lokacija udaljenih RSUBP-a su upisani u komunikacionoj bazi podataka.
Primeri upita koji rade sa udaljenim podacima:
Nazivi
1. SELECT * FROM LOC.DSN8510.EMP; – čitanje udaljene tabele na lokaciji LOC.
2. EXEC SQL CONNECT TO NIŠ; – povezivanje sa serverom na lokaciji NIŠ. Sve
naredne naredbe bi se izvršavale na tom serveru.
3. EXEC SQL CONNECT TO NOVI SAD;
EXEC SQL CALL ime procedure (parametar lista); – poziv uskladištene procedure
na lokaciji NOVI SAD.
Postoje dve metode pristupa:
1. DB2 privatni protokol za pristup (prikazan u primeru 1). Ovaj protokol podržava
jedino DB2 za OS/390.

Osnovno o radu sa distribuiranim podacima 61
2. DRDA pristup (prikazan u primerima 2 i 3). Preporuka je da se koristi DRDA
protokol kada god je to moguće. DRDA protokol pored DB2 za OS/390 podržavaju
i ostali članovi DB2 familije i veliki broj produkata drugih firmi.
Primer. Neka je potrebno napisati program koji ažurira tabelu POSILJKE. Tabela pod
tim nazivom se nalazi na različitim lokacijama (recimo u mestima gde se nalaze skladišta
robe). Grubi izgled programa koji koristi DRDA protokol za pristup udaljenim podacima
je
procitati ulazne vrednosti
DO za sve lokacije
procitaj ime lokacije
EXEC SQL CONNECT TO :lokacija
EXEC SQL UPDATE DBKURS0.POSILJKE
SET KOL = :kol
WHERE SRBR = :srbr
AND DRBR = :drbr
AND PRBR = :prbr;
END;
COMMIT

62 Podešavanje upita
10.6.1 Vezivanje programa koji rade sa DRDA pristupom
• Relevantne opcije prekompilatora su
– CONNECT. Korisiti isključivo CONNECT(2).
– SQL. Koristiti SQL(ALL) eksplicitno ili po default-u ako server nije DB2 za
OS/390. Prekompilator tada prihvata naredbe koje su predvidjene DRDA pravilima.
Ako je server DB2 za OS/390 tada koristiti SQL(DB2).
• Relevantne BIND PACKAGE opcije su:
– naziv lokacije
– SQLERROR
– CURRENTDATA
– OPTIONS. Kada formirate udaljenu kopiju paketa upotrebom BIND PACK-
AGE sa COPY opcijom, upotrebljavajte ovu opciju za kontrolu default opcija
vezivanja koje koristi DB2.
∗ COMPOSITE znači da DB2 koristi opcije navedene u komandi BIND
PACKAGE. Za ostale opcije, koriste se opcije prepisanog paketa.
∗ COMMAND znači da DB2 koristi opcije navedene u komandi BIND PACK-
AGE. Za ostale opcije, koriste se default opcije na serveru na kome se vrši
vezivanje.
• Relevantne BIND PLAN opcije su:
– DISCONNECT. Radi najveće fleksibilnosti koristite DISCONNECT (EX-
PLICIT). To zahteva eksplicitnu upotrebu RELEASE naredbe u vašem programu.
DISCONNECT (AUTOMATIC) raskida sve udaljene veze za vreme COMMIT
operacije, bez potrebe za RELEASE naredbom u programu.
DISCONNECT (CONDITIONAL) raskida sve udaljene veze za vreme COM-
MIT operacije, sem onih sa kojima je asociran kursor otvoren sa WITH HOLD
opcijom.
– SQLRULES. Koristiti SQLRULES(DB2) eksplicitno ili kao default.
– SQLRULES. Koristiti SQLRULES(DB2) eksplicitno ili kao default. SQL-
RULES(STD) primenjuje pravila SQL standarda na CONENCT naredbu, tako
da CONNECT TO loc vraća grešku ako ste već povezani sa lokacijom loc.
– CURRENTDATA. Koristiti CURRENTDATA(NO) da bi forsirali čitanje podataka
u blokovima.
U distribuiranim okruženjima je vrlo vašno koordinirati ažuriranje u dva ili više RSUBPa.
U slučaju da svi sistemi koriste dvofazni commit, ažuriranje se može jednostavno
koordinirati.

EXPLAIN 63
10.7 EXPLAIN
EXPLAIN je alatka koja služi za nadzor i generiše informacije o planovima, paketima ili
vezanim SQL naredbama. Izlaz se upisuje u tabelu pod nazivom PLAN TABLE. Dobijene
informacije mogu da pomognu pri:
• Dizajnu baze, indeksa i aplikativnih programa
• Odredjivanja kada treba ponovo vezati aplikaciju
• Odredjivanju pristupnog puta izabranog za upit.
Primarna funkcija EXPLAIN-a je da prikaže pristupne puteve koji bi se koristili pri
izvršavanju upita. Za UPDATE, INSERT i DELETE WHERE CURRENT OF u tabelu
se upisuje znatno manje informacija.
Da bi se informacije uopšte dobile, potrebno je napraviti tabelu PLAN TABLE. SQL
kojim se formira tabela se nalazi u datoteci ’XDB2000.T.SQL(CRTABPL)’. U ovom
priručniku neće biti detaljno navodjenja značenja svih kolona u rezultatu koji se upisuje
u PLAN TABLE. Umesto toga biće prikazane osnovne vrste pristupnih puteva, dok će
primeri upotrebe EXPLAIN-a biti prikazani na praktičnim vežbama.
Kada se jednom formira tabela planova (plan table) postoje dva pristupa za dobijanje
izlaza iz EXPLAIN-a:
1. BIND/REBIND sa EXPLAIN(YES). DB2 će upisati pristupni put svake opisive
tabele u tabelu planova pri Bind/Rebind procesu plana ili paketa u kome je ukljucena
ova opcija. Rezultat će biti upisan u tabelu sa prefiksom imena koji je jednak
primarnom useridu vlasnika plana/paketa.
2. EXPLAIN FOR ALL SQL naredba. DB2 neće procesirati SQL naredbe kojima je
ovaj tekst, vec će upisati informacije o pristupnim putevima u tabelu. Sintaksa ove
naredbe je
>>--EXPLAIN--+-PLAN-+--+---------------------+----------------------->
+-ALL--+ +-SET QUERYNO=integer-+
>--FOR--explainable-sql-statement-----------------------------------><
10.7.1 Neke informacije o EXPLAIN-u
Postoje dve glavne grupe indikatora za sort, SORTN i SORTC. SORTN sadrži indikator
za nove tabele koji se uvodi u koraku opisivanja, dok je SORTC informacija o rezultatima
prethodnih koraka. Unutar svake grupe postoje četiri moguca razloga za izvršavanje sorta.
Svaki od njih se prikazuje odvojeno.
Agregatne funkcije se mogu obradjivati u različitim koracima izvršavanja SQL-a. Ono sto
želite da se uradi najbrže moguće, je dobijanje podataka. Ako to nije moguće, možda
treba izvršiti sortiranje da bi se podaci dobili u korektnom redosledu. Izračunavanja se
mogu uraditi posle svih ovih koraka.

64 Podešavanje upita
Opcija BIND-a REOPT(VARS) uvodi zahteve za označavanjem kada se informacije iz
opisa pišu, i da li su te informacije važeći pristupni putevi koji se koriste u vreme izvršenja.
WHEN OPTIMIZE označava tip pristupnog puta i da li je on važeći u doba izvršenja. Ako
se koristi REOPT(VARS) i optimizacija u vremenu povezivanja (pri BIND-u) ne uspe zbog
autorizacija ili zavisnosti objekata, u vreme izvršenja se umeće slog u opisu koji to označava
sa vrednošću R u koloni WHEN OPTIMIZE.
TSLOCKMODE daje informaciju o načinu upravljanja zaključavanjima od strane DB2.
Označeni način se dobija na nivou prostora za čuvanje tabela, i činjenica da taj ključ na
nižem nivou može biti tražen se može osmotriti kroz dodatne namere na tom nivou. Ne
može se zahtevati nivo na kome će ostali ključevi biti traženi.
BIND TIME i TIMESTAMP označavaju vreme poslednjeg izvršavanja BIND naredbe. Za
dinamički SQL ove dve vrednosti su jednake.
10.8 Pristupni putevi
10.8.1 Tehnike za poboljšavanje pristupnog puta
Sekvencijalno predčitanje (prefetch)
Izvršavanje skena prostora za čuvanje podataka se vrši po unapred definisanom načinu:
sve stranice podataka se čitaju u nizu u kome se pojavljuju. Ako DB2 startuje I/O za
novu stranicu posle obrade prethodne, program će provesti dosta vremena na čekanje
tako čitanih stranica. Za rešavanje ovog problema se uvodi asinhroni mehanizam: čitanje
velikog broja redova unapred. Dok se vrši obrada jedne stranice, sledeća se već nalazi
u memoriji. Ovaj mehanizam dovodi do velikog poboljšanja performansi, pri čemu se u
velikoj meri smanjuje i broj zahtevanih I/O operacija.
Ako je veličina bufferpool-a u kome se nalazi vaš objekat manja od 10.000 stranica, DB2 će
biti u mogućnosti da čita stranice u bufferpool-u koristeći efikasne I/O operacije i čitajući
32 stranice u jednoj I/O operaciji. Kako se čita 32 stranice za popunjavanje svih 1000
stranica trebaće najviše 31 I/O operacija, umesto ranijih 1000.
Postoje dve tačke u kojma DB2 može da odluči da koristi sekvencijalno predčitanje: u
vreme bind-ovanja i u vreme izvršenja. Prvo se naziva sekvencijalno predčitanje, dok se
drugo naziva sekvencijalna detekcija. U obe tehnike se primenjuje isti osnovni princip -
predpročitani podaci se mogu koristiti samo ako ste sigurni da će se obradjivati dovoljno
veliki broj stranica da opravda cenu predčitanja.
Predčitanje se može prevesti u veliki broj stranica za pristup indeksom, i clusterratio za
uzastopne pristupe podacima. Primetimo da postoji samo jedno polje za naznačavanje
predčitanja zbog čega se ne može napraviti razlika izmedju predčitanja indeksa i podataka.
Triger-in kod sekvencijalne detekcije se radi na osnovu naredbe koja se izvršava. DB2
vodi računa o pristupu na poslednjh 8 stranica. Ako je paterna dovoljno sekvencijalna,
DB2 počinje sa asinhronim I/O. Ova tehnika se takodje može primeniti na UPDATE i
DELETE.
EXPLAIN neće označiti ništa što zavisi od karakteristika u vreme izvršenja, bez obzira
da li je predčitanje trigerovano ili ne.

Pristupni putevi 65
List Prefetch
• dohvata sve pokazivače indeksa koji zadovoljavaju uparujući predikat.
• Sortira pokazivače u opadajući redosled.
• Pristupa stranicama podataka upotrebom liste pokazivača (korišćenjem Skip Sequential
Access Method-a).
• Ova tehnika je korisna kada je Clusterratio 80% samo kada je potreban mali broj stranica.
• Uvek se koristi za
– Multiple index access
– Inner table access of a hybrid Join
Kao što je prethodno napomenuto, moguće je da niz slogova u TS ne odgovara nizu indeksa,
što uzrokuje čitanje iste strane podataka više puta. Sortiranjem odgovarajućeg
RID-a u opadajući redosled problem se eliminiše.
Skip sequential access method moze da pročita ne-uzastopne stranice u jednoj I/O operaciji.
Mana ove tehnike je što mora da se čeka na prvi slog sve dok RID ne bude
pročitan i sortiran, što može da bude neprihvatljivo kod interaktivnih programa.
Thresholds (prag, granica) kod List Prefetch-a
DB2 ima granicu i u vreme povezivanja i u vreme izvršenja kada proverava da li je
predčitanje liste dobro rešenje. Najveća opasnost je da se završi sa RID listom koja
sadrži najveći deo slogova, sortira se a da pri tome bude pročitan najveći deo stranica u
TS-u. U tom slučaju efikasnije je primeniti jednostavni sken TS-a.
DB2 poseduje mogucńost da zaobidje particije u podeljenom TS, kada je očigledno da
particija ne sadrži tražene slogove. Ovo može da se primeni na pristupne puteve za indeks
i TS.
Particioni sken
Particioni sken obezbedjuje mogućnost za skeniranje odgovarajućih podataka bez upotrebe
indeksa particije. Na taj način se mogu eliminisati nepotrebna skeniranja TS-a i zameniti
sa pristupnim putem koji pristupa samo zahtevanim particijama.
Odluka koje su particije potrebne se donosi u vreme BIND-a. Da bi se naredbe sa host
promenljivim načinile odgovarajucim za particioni sken, REOPT(VARS) opcija mora biti
upotrebljena za odlaganje BIND-a u vreme izvršenja.
Particije mogu da barataju ne-neprekidnim particijama kada se koristi npr. IN lista.
Takodje, particioni sken uzima jedino prvu kolonu particionog ključa u razmatranje, čak
i ako je upareno više kolona tog indeksa.
10.8.2 Pristupni putevi za jednu tabelu
U narednim primerima će za ilustraciju različitih vrsta pristupnih puteva biti korišćene
tabele T adress i R postal code. U T adress indeks se javlja na R ADDRESS, (T STREET,
T NUMBER), T NAME, i R OWNER. U R postal code indeks se javlja na R POSTAL CODE.

66 Podešavanje upita
1. Upit
select * from t_address
where R_POSTAL_CODE=’1234’
za koji je sadržaj polja ACCESSTYPE u PLAN TABLE ’R’, se obradjuje na sledeći
način:
2. Upit
• pošto nema indeksa nad tom kolonom, mora da se primeni tablespace scan
• u segmentiranom TS DB2 će skenirati samo one segmente koji sadrže podatke,
a u prostom TS sa više od jedne tabele biće procitane sve stranice.
select * from t_address
where T_street = ’Vase Carapica’
za koji je sadržaj polja ACCESSTYPE u PLAN TABLE ’I’, se obradjuje tako što
indeksni sken sa uparivanjem koristi kolone u indeksu radi odredjivanja redova koji
zadovoljavaju uslov. Strane u TS će biti čitane jedino ako je u indeksu pronadjen
odgovarajući red. Ova metoda je vrlo korisna za velike tabele, dok za male tabele
prednosti nisu tako izražene.
3. Upit
select * from t_address
where T_number = 88
za koji je sadržaj polja ACCESSTYPE u PLAN TABLE ’I’ se obradjuje na sledeći
način:
Pretpostavimo da indeksni sken sa uparivanjem ne može da se koristi, ali je broj
stranica u indeksu znatno manji nego u TS, i tražena kolona se nalazi u indeksu. U
ovom slučaju se kao koristan moze pokazati indeksni sken bez uparivanja. DB2 će
čitati i obraditi sve stranice koji su listovi u indeksu. Da bi se ubrzao proces, DB2 ce
verovatno korisiti sekvencijalni prefetch (u daljem tekstu sekvencijalno predčitanje).
4. Upit
select t_street, t_number
from t_address
where t_street = ’Vase Carapica’
and t_number in (1,2)
se obradjuje preko IN-list indeks skena (polje ACCESSTYPE u
PLAN TABLE je ’N’).
Ova pristupna metoda je specijalni slučaj indeksnog skena sa uparivanjem. Za
svaku vrednost u in-listi, DB2 će koristiti indeksni sken sa uparivanjem za odredjivanje
redova koji zadovoljavaju uslov. DB2 poseduje mogućnost da konvertuje skup
predikata kombinovan kroz OR u ovaj tip pristupnog puta. Izlaz iz opisa ce naznačiti
šta se desilo.

Pristupni putevi 67
5. Upit
select *
from t_address
where (t_name = ’Pera’)
or (t_street = ’Vase Carapica’)
za koji je sadržaj polja ACCESSTYPE u PLAN TABLE ’M’ (sa kombinacijama MX,
MU, ...) se obradjuje preko višestrukog indeksnog pristupa (multiple-index access).
DB2 može da koristi više od jednog indeksa pri formiranju skupa odgovora. Mehanizam
je vrlo jednostavan. Izabira se RID (Row ID) kvalifikovanog sloga u svakom indeksu,
i kombinuju rezultati svakog indeksa korišćenjem i/ili za odredjivanje konačne
liste RIDova. Ova lista se koristi za pristup stranicama podataka.
6. Upit
select min(t_number)
from t_address
where t_street = ’Vase Carapica’
se obradjuje kao pristup sa jednim čitanjem. Ovo je verovatno najbrži mogući pristupni
put. DB2 čak ne mora da skenira ni indeks. Izdvaja se jedna stavka iz indeksa
i dobija rezultat upita.
7. Upit
select *
from t_address
where t_number = 88
se obradjuje primenom neuparenog predikata na indeks. Ova metoda se naziva
zaklanjanje (zaštita) indeksa. Ona je alternativa primeni predikata u vreme pristupa
podacima. Postoje izvesna ograničenja mogucnosti DB2 da tako uradi. Čak i ako
postoje predikati u polju koji su prisutni u indeksu, ali nisu upareni, DB2 će primeniti
ove uslove u vreme pristupa podacima. Takodje, DB2 ne može da koristi ovu tehniku
pri list-prefetching-u.
10.8.3 Pristupni putevi za više tabela
Za pristup do više tabela postoje tri kombinovane tehnike: Ugnježdena petlja (Nested
loop), Pomešani sken (Merge scan) i Hibridno spajanje (hybrid join).
Ako se kombinuju dve ili više tabela, DB2 može da koristi različite tehnike za kombinovanje
prve dve i treće od njih. DB2 takodje može da koristi bilo koji od metoda pristupa
pojedinačnim tabelama da bi ih obradio.

68 Podešavanje upita
Ugnježdena petlja
SELECT T_NAME, T_STREET, T_CITY
FROM T_ADDRESS A, R_POSTAL_CODE B
WHERE T_FAX_NR LIKE ’03%’
AND A.R_POSTAL_CODE = B.R_POSTAL_CODE
Unutrašnja tabela se skenira da bi se pronašli svi slogovi koji se mogu upariti sa slogovima
spoljašnje tabele. Rezultat ovoga je jedan sken spoljašnje tabele i n-skenova (n = broj
odgovarajućih slogova unutrašnje tabele) unutrašnje tabele. Efikasnost ove tehnologije
jako zavisi od efikasnosti skena unutrašnje tabele.
Spajanje sa pomešanim skenom
SELECT T_NAME, T_STREET, T_CITY
FROM T_ADDRESS A, R_POSTAL_CODE B
WHERE T_FAX_NR LIKE ’03%’
AND A.R_POSTAL_CODE = B.R_POSTAL_CODE
AND T_CITY LIKE ’A%’
- Sken T_ADDRESS - Skenira se R_POSTAL_CODE
- Dohvataju se slogovi - Dohvataju se slogovi koji
koji imaju T_FAX_NR like ...
imaju T_CITY like
- Uredjuje se rezultat po R_POSTAL_CODE - Uredjuje se rezultat po
R_POSTAL_CODE
spajaju se dve tabele
Obe tabele se uredjuju u redosled po kolonama koje se spajaju preko sortiranja indeksa.
DB2 zatim počinje balansirano čitanje obe tabele.
Hibridno spajanje
SELECT T_NAME, T_STREET, T_CITY
FROM T_ADDRESS A, R_POSTAL_CODE B
WHERE T_FAX_NR LIKE ’03%’
AND A.R_POSTAL_CODE = B.R_POSTAL_CODE
• skenira se spoljašnja tabela
• formira se medjutabela dodavanjem odgovarajućeg RID-a u spoljašnju rezultat
tabelu
• ako unutrašnja tabela nije visoko klasterovana, potreban je radni prostor za sortiranje
• lista predčitanja unutrašnje tabele
• dopisivanje rezultata

Pristupni putevi 69
Hibridno spajanje je na neki način različita tehnika koja pokušava da reši problem
ugnježdene petlje: skeniranje unutrašnje tabele je primenjeno za svaki slog spoljašnje
tabele koji zadovoljava uslov. DB2 ekstrahuje RID unutrašnje tabele jednom za svaku
različitu vrednost u unutrašnjoj tabeli. Zatim se medjurezultat uredjuje po RID-ovima
unutrašnje tabele, i predčitanje liste se koristi za pristup dodatnim informacijama. DB2
zahteva najmanje jedan indeks na kolonama unutrašnje tabele koje se spajaju da bi ova
tehnika mogla da se koristi.
Kada se primenjuje koja tehnika
Procena DB2 jako zavisi od tačnosti procene spajanja kolona. Vrlo je važno da DB2
poseduje korektnu statistiku za kolone koje se koriste pri spajanju tabela.
• Ugnježdena petlja. Sken unutrašnje tabele je jako skupa operacija. Ugnježdena
petlja će se primeniti ako mali broj slogova spoljašnje tabele zadovoljava uslov, ili
ako postoji vrlo efikasan indeks nad unutrašnjom tabelom. Vrlo mala spoljašnja
tabela će takodje poboljšati performanse.
• Pomešani sken. Ugnježdena petlja skenira unutrašnju tabelu, čak i za duplikate.
Veliki broj duplikata u obe tabele se bolje obradjuje sa tehnikom pomešanih skenova,
kao i velike tabele bez odgovarajućih indeksa.
• Hibridno spajanje. Najbolji efekti se dobijaju ako postoji indeks na atributima
unutrašnje tabele preko kojih se vrši spajanje, kao i ako spoljašnja tabela ima veliki
broj duplikata.
• Spoljašnje spajanje. DB2 interno prevodi desno spoljašnje spajanje na levo spoljašnje
spajanje. U oba slučaja JOIN TYPE je ’L’. Puno spoljašnje spajanje ima ’F’ u
JOIN TYPE koloni, i uvek se obradjuje primenom tehnike pomešanih skenova.

Glava 11
Literatura
11.1 DB2 za OS/390 V7
1. DB2 UDB for OS/390 and z/OS V7 Administration Guide, SC26-9931-02
2. DB2 UDB for OS/390 and z/OS V7 Application Programming and SQL Guide,
SC26-9933-02
3. DB2 UDB for OS/390 and z/OS V7 Application Programming Guide and Reference
for Java(TM), SC26-9932-02
4. DB2 UDB for OS/390 and z/OS V7 Command Reference, SC26-9934-02
5. DB2 UDB for OS/390 and z/OS V7 Data Sharing: Planning and Administration,
SC26-9935-02
6. DB2 UDB for OS/390 and z/OS V7 Image, Audio, and Video Extenders Administration
and Programming, SC26-9947-00
7. DB2 UDB for OS/390 and z/OS V7 Installation Guide, GC26-9936-02 DSNIGH12
8. DB2 UDB for OS/390 and z/OS V7 Messages and Codes, GC26-9940-02 DSN-
MCH12
9. DB2 UDB for OS/390 and z/OS V7 Net Search Extender Administration and Programming,
SC27-1171-00
10. DB2 UDB for OS/390 and z/OS V7 ODBC Guide and Reference, SC26-9941-02
11. DB2 UDB for OS/390 and z/OS V7 Reference for Remote DRDA Requesters and
Servers, SC26-9942-00
12. DB2 UDB for OS/390 and z/OS V7 Release Planning Guide, SC26-9943-02
13. DB2 UDB for OS/390 and z/OS V7 SQL Reference, SC26-9944-02
14. DB2 UDB for OS/390 and z/OS V7 Text Extender Administration and Programming,
SC26-9948-00
15. DB2 UDB for OS/390 and z/OS V7 Utility Guide and Reference, SC26-9945-03

16. DB2 UDB for OS/390 and z/OS V7 XML Extender Administration and Programming,
SC26-9949-00
17. DB2 UDB for z/OS and OS/390 V7 What’s New?, GC26-9946-02
11.2 QMF V7R2 for OS/390
1. QMF Developing QMF Applications Version 7 Release 2, SC27-0718-01
2. QMF Getting Started with QMF for Windows Version 7 Release 2, SC27-0723-01
3. QMF High Performance Option User’s Guide for z/OS and OS/390 Version 7 Rel 2,
SC27-0724-01
4. QMF Installing & Managing QMF for Windows Version 7 Release 2, GC27-0722-01
5. QMF Installing and Managing QMF Version 7 Release 2, GC27-0720-01
6. QMF Introducing QMF Version 7 Release 2, GC27-0714-02
7. QMF Messages and Codes Version 7 Release 2, GC27-0717-01
8. QMF Reference Version 7 Release 2, SC27-0715-01
9. QMF Using QMF Version 7 Release 2, SC27-0716-01
11.3 Dodatna literatura
1. N. Mitić, plikativno programiranje za DB2 V5 za OS/390, Beograd 1999.

Dodatak A
Značenja polja u SQLCA
Napomena 4
Imena koja se odnose na FORTRAN su isključena zbog preglednosti.
+----------------------------------------------------------------------+
| Table 31. Fields of SQLCA |
+----------------------------------------------------------------------|
| Assembler, | | | |
| COBOL, or | C | Data | |
| PL/I Name | Name | Type | Purpose |
+------------+--------------+-------------+----------------------------|
| SQLCAID | sqlcaid | CHAR(8) | An "eye catcher" for |
| | | | storage dumps, containing |
| | | | the text ’SQLCA’. |
+------------+--------------+-------------+----------------------------|
| SQLCABC | sqlcabc | INTEGER | Contains the length of the |
| | | | SQLCA: 136. |
+------------+--------------+-------------+----------------------------|
| SQLCODE | SQLCODE | INTEGER | Contains the SQL return |
| (See note | | | code. (See note 2) |
| 1) | | | Code Means |
| | | | 0 Successful |
| | | | execution |
| | | | (though there |
| | | | might have |
| | | | been warning |
| | | | messages). |
| | | | positive Successful |
| | | | execution, but |
| | | | with an |
| | | | exception |
| | | | condition. |
| | | | negative Error |
| | | | condition. |
+------------+--------------+-------------+----------------------------|

74 Značenja polja u SQLCA
+------------+--------------+-------------+----------------------------|
| SQLERRML | sqlerrml | SMALLINT | Length indicator for |
| (See note | (See note 3) | | SQLERRMC, in the range 0 |
| 3) | | | through 70. 0 means that |
| | | | the value of SQLERRMC is |
| | | | not pertinent. |
+------------+--------------+-------------+----------------------------|
| SQLERRMC | sqlerrmc | VARCHAR(70) | Contains one or more |
| (See note | (See note 3) | | tokens, separated by |
| 3) | | | X’FF’, that are |
| | | | substituted for variables |
| | | | in the descriptions of |
| | | | error conditions. |
+------------+--------------+-------------+----------------------------|
| SQLERRP | sqlerrp | CHAR(8) | Provides a product |
| | | | signature and, in the case |
| | | | of an error, diagnostic |
| | | | information such as the |
| | | | name of the module that |
| | | | detected the error. In |
| | | | all cases, the first three |
| | | | characters are ’DSN’ for |
| | | | DB2 for MVS/ESA. |
+------------+--------------+-------------+----------------------------|
| SQLERRD(1) | sqlerrd[0] | INTEGER | Contains an internal error |
| | | | code. |
+------------+--------------+-------------+----------------------------|
| SQLERRD(2) | sqlerrd[1] | INTEGER | Contains an internal error |
| | | | code. |
+------------+--------------+-------------+----------------------------|
| SQLERRD(3) | sqlerrd[2] | INTEGER | Contains the number of |
| | | | rows affected after |
| | | | INSERT, UPDATE, and DELETE |
| | | | (but not rows deleted as a |
| | | | result of CASCADE delete). |
| | | | Set to 0 if the SQL |
| | | | statement fails, |
| | | | indicating that all |
| | | | changes made in executing |
| | | | the statement were |
| | | | canceled. Set to -1 for a |
| | | | mass delete from a table |
| | | | in a segmented table |
| | | | space. |
+------------+--------------+-------------+----------------------------|

75
+------------+--------------+-------------+----------------------------|
| SQLERRD(4) | sqlerrd[3] | INTEGER | Contains timerons, a short |
| | | | floating-point value that |
| | | | indicates a rough relative |
| | | | estimate of resources |
| | | | required (See note 4). It |
| | | | does not reflect an |
| | | | estimate of the time |
| | | | required. When preparing |
| | | | a dynamically defined SQL |
| | | | statement, you can use |
| | | | this field as an indicator |
| | | | of the relative cost of |
| | | | the prepared SQL |
| | | | statement. For a |
| | | | particular statement, this |
| | | | number can vary with |
| | | | changes to the statistics |
| | | | in the catalog. It is |
| | | | also subject to change |
| | | | between releases of DB2 |
| | | | for MVS/ESA. |
+------------+--------------+-------------+----------------------------|
| SQLERRD(5) | sqlerrd[4] | INTEGER | Contains the position or |
| | | | column of a syntax error |
| | | | for a PREPARE, or EXECUTE |
| | | | IMMEDIATE statement. |
+------------+--------------+-------------+----------------------------|
| SQLERRD(6) | sqlerrd[5] | INTEGER | Contains an internal error |
| | | | code. |
+------------+--------------+-------------+----------------------------|
| SQLWARN0 | SQLWARN0 | CHAR(1) | Blank if all other |
| | | | indicators are blank; |
| | | | contains W if at least one |
| | | | other indicator also |
| | | | contains W. |
+------------+--------------+-------------+----------------------------|
| SQLWARN1 | SQLWARN1 | CHAR(1) | Contains W if the value of |
| | | | a string column was |
| | | | truncated when assigned to |
| | | | a host variable. |
+------------+--------------+-------------+----------------------------|
| SQLWARN2 | SQLWARN2 | CHAR(1) | Contains W if null values |
| | | | were eliminated from the |
| | | | argument of a column |
| | | | function; not necessarily |
| | | | set to W for the MIN |
+------------+--------------+-------------+----------------------------|

76 Značenja polja u SQLCA
+------------+--------------+-------------+----------------------------|
| | | | function because its |
| | | | results are not dependent |
| | | | on the elimination of null |
| | | | values. |
+------------+--------------+-------------+----------------------------|
| SQLWARN3 | SQLWARN3 | CHAR(1) | Contains W if the number |
| | | | of result columns is |
| | | | larger than the number of |
| | | | host variables. |
+------------+--------------+-------------+----------------------------|
| SQLWARN4 | SQLWARN4 | CHAR(1) | Contains W if a prepared |
| | | | UPDATE or DELETE statement |
| | | | does not include a WHERE |
| | | | clause. |
+------------+--------------+-------------+----------------------------|
| SQLWARN5 | SQLWARN5 | CHAR(1) | Contains W if the SQL |
| | | | statement was not executed |
| | | | because it is not a valid |
| | | | SQL statement in DB2 for |
| | | | MVS/ESA. |
+------------+--------------+-------------+----------------------------|
| SQLWARN6 | SQLWARN6 | CHAR(1) | Contains W if the addition |
| | | | of a month or year |
| | | | duration to a DATE or |
| | | | TIMESTAMP value results in |
| | | | an invalid day (for |
| | | | example, June 31). |
| | | | Indicates that the value |
| | | | of the day was changed to |
| | | | the last day of the month |
| | | | to make the result valid. |
+------------+--------------+-------------+----------------------------|
| SQLWARN7 | SQLWARN7 | CHAR(1) | Contains a W if one or |
| | | | more nonzero digits were |
| | | | eliminated from the |
| | | | fractional part of a |
| | | | number used as the operand |
| | | | of a decimal multiply or |
| | | | divide operation. |
+------------+--------------+-------------+----------------------------|
| SQLWARN8 | SQLWARN8 | CHAR(1) | Contains a W if a |
| | | | character that could not |
| | | | be converted was replaced |
| | | | with a substitute |
| | | | character. |
+------------+--------------+-------------+----------------------------|

77
+------------+--------------+-------------+----------------------------|
| SQLWARN9 | SQLWARN9 | CHAR(1) | Contains a W if arithmetic |
| | | | exceptions were ignored |
| | | | during COUNT DISTINCT |
| | | | processing. |
+------------+--------------+-------------+----------------------------|
| SQLWARNA | SQLWARNA | CHAR(1) | Contains a W if at least |
| | | | one character field of the |
| | | | SQLCA or the SQLDA names |
| | | | or labels is invalid due |
| | | | to a character conversion |
| | | | error. |
+------------+--------------+-------------+----------------------------|
| SQLSTATE | sqlstate | CHAR(5) | Contains a return code for |
| | | | the outcome of the most |
| | | | recent execution of an SQL |
| | | | statement (See note 5). |
+----------------------------------------------------------------------|
| Note: |
| |
| 1. With the precompiler option STDSQL(YES) in effect, SQLCODE is |
| replaced by SQLCADE in SQLCA. |
| |
| 2. For the specific meanings of SQL return codes, see Section 2 of |
| Messages and Codes. |
| |
| 3. In COBOL, SQLERRM includes SQLERRML and SQLERRMC. In PL/I and C, |
| the varying-length string SQLERRM is equivalent to SQLERRML |
| prefixed to SQLERRMC. In assembler, the storage area SQLERRM is |
| equivalent to SQLERRML and SQLERRMC. See the examples for the |
| various host languages in "The Included SQLCA" in topic C.1.2. |
| |
| 4. The use of timerons may require special handling because they |
| are floating-point values in an INTEGER array. In PL/I, for |
| example you could first copy the value into a BIN FIXED(31) |
| based variable that coincides with a BIN FLOAT(24) variable. |
| |
| 5. For a description of SQLSTATE values, see Appendix C of Messages |
| and Codes. |
+----------------------------------------------------------------------+

Dodatak B
Izgled SQLCA strukture
PL/I: | C:
|
|
DECLARE | #ifndef SQLCODE
1 SQLCA, | struct sqlca
2 SQLCAID CHAR(8), | {
2 SQLCABC FIXED(31) BINARY, | unsigned char sqlcaid[8];
2 SQLCODE FIXED(31) BINARY, | long sqlcabc;
2 SQLERRM CHAR(70) VAR, | long sqlcode;
2 SQLERRP CHAR(8), | short sqlerrml;
2 SQLERRD(6) FIXED(31) BINARY, | unsigned char sqlerrmc[70];
2 SQLWARN, | unsigned char sqlerrp[8];
3 SQLWARN0 CHAR(1), | long sqlerrd[6];
3 SQLWARN1 CHAR(1), | unsigned char sqlwarn[11];
3 SQLWARN2 CHAR(1), | unsigned char sqlstate[5];
3 SQLWARN3 CHAR(1), | };
3 SQLWARN4 CHAR(1), | #define SQLCODE sqlca.sqlcode
3 SQLWARN5 CHAR(1), | #define SQLWARN0 sqlca.sqlwarn[0]
3 SQLWARN6 CHAR(1), | #define SQLWARN1 sqlca.sqlwarn[1]
3 SQLWARN7 CHAR(1), | #define SQLWARN2 sqlca.sqlwarn[2]
2 SQLEXT, | #define SQLWARN3 sqlca.sqlwarn[3]
3 SQLWARN8 CHAR(1), | #define SQLWARN4 sqlca.sqlwarn[4]
3 SQLWARN9 CHAR(1), | #define SQLWARN5 sqlca.sqlwarn[5]
3 SQLWARNA CHAR(1), | #define SQLWARN6 sqlca.sqlwarn[6]
3 SQLSTATE CHAR(5); | #define SQLWARN7 sqlca.sqlwarn[7]
| #define SQLWARN8 sqlca.sqlwarn[8]
| #define SQLWARN9 sqlca.sqlwarn[9]
| #define SQLWARNA sqlca.sqlwarn[10]
| #define SQLSTATE sqlca.sqlstate
| #endif
| struct sqlca sqlca;

Dodatak C
Klase SQLSTATE kodova
SQLSTATE values are returned to the application in the last five bytes of
the SQLCA. Each five-character value is a return code that indicates the
outcome of the most recently executed SQL statement.
SQLSTATE values are designed so that application programs can test for
specific errors or classes of errors. The first character of an
SQLSTATE value indicates whether the SQL statement was executed successfully
or unsuccessfully (equal to or not equal to zero, respectively).
SQLSTATE values are comprised of a two-character class code value, followed
by a three-character subclass code value. Class code values represent classes
of successful and unsuccessful execution conditions. An application might
define classes beginning with the characters ’7’ through ’9’ or ’I’ through ’Z’
and subclasses for any class beginning with the characters ’I’ through ’Z’.
Table 5 identifies the SQLSTATE class codes.
+------------------------------------------------------------------------+
| Table 5. SQLSTATE Class Codes |
+------------------------------------------------------------------------|
| Class | | For subcodes, |
| Code | Meaning | refer to... |
+--------+------------------------------------+--------------------------|
| 00 | Unqualified Successful Completion | Table 6 |
+--------+------------------------------------+--------------------------|
| 01 | Warning | Table 7 |
+--------+------------------------------------+--------------------------|
| 02 | No Data | Table 8 |
+--------+------------------------------------+--------------------------|
| 07 | Dynamic SQL Error | Table 9 |
+--------+------------------------------------+--------------------------|
| 08 | Connection Exception | Table 10 |
+--------+------------------------------------+--------------------------|
| 09 | Triggered Action Exception | Table 11 |

82 Klase SQLSTATE kodova
+--------+------------------------------------+--------------------------|
| 0A | Feature Not Supported | Table 12 |
+--------+------------------------------------+--------------------------|
| 0F | Invalid Token | Table 13 |
+--------+------------------------------------+--------------------------|
| 21 | Cardinality Violation | Table 14 |
+--------+------------------------------------+--------------------------|
| 22 | Data Exception | Table 15 |
+--------+------------------------------------+--------------------------|
| 23 | Constraint Violation | Table 16 |
+--------+------------------------------------+--------------------------|
| 24 | Invalid Cursor State | Table 17 |
+--------+------------------------------------+--------------------------|
| 25 | Invalid Transaction State | Table 18 |
+--------+------------------------------------+--------------------------|
| 26 | Invalid SQL Statement Identifier | Table 19 |
+--------+------------------------------------+--------------------------|
| 2D | Invalid Transaction Termination | Table 20 |
+--------+------------------------------------+--------------------------|
| 34 | Invalid Cursor Name | Table 21 |
+--------+------------------------------------+--------------------------|
| 38 | External Function Exception | Table 22 |
+--------+------------------------------------+--------------------------|
| 39 | External Function Call Exception | Table 23 |
+--------+------------------------------------+--------------------------|
| 40 | Transaction Rollback | Table 24 |
+--------+------------------------------------+--------------------------|
| 42 | Syntax Error or Access Rule | Table 25 |
| | Violation | |
+--------+------------------------------------+--------------------------|
| 44 | WITH CHECK OPTION Violation | Table 26 |
+--------+------------------------------------+--------------------------|
| 51 | Invalid Application State | Table 27 |
+--------+------------------------------------+--------------------------|
| 53 | Invalid Operand or Inconsistent | Table 28 |
| | Specification | |
+--------+------------------------------------+--------------------------|
| 54 | SQL or Product Limit Exceeded | Table 29 |
+--------+------------------------------------+--------------------------|
| 55 | Object Not in Prerequisite State | Table 30 |
+--------+------------------------------------+--------------------------|
| 56 | Miscellaneous SQL or Product Error | Table 31 |
+--------+------------------------------------+--------------------------|
| 57 | Resource Not Available or Operator | Table 32 |
| | Intervention | |
+--------+------------------------------------+--------------------------|
| 58 | System Error | Table 33 |
+------------------------------------------------------------------------+

83
+------------------------------------------------------------------------+
| Table 6. Class Code 00: Unqualified Successful Completion |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 00000 | Execution of the SQL statement was successful and did not |
| | result in any type of warning or exception condition. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 7. Class Code 01: Warning |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 01003 | Null values were eliminated from the argument of a column |
| | function. |
+---------+--------------------------------------------------------------|
| 01004 | The value of a string was truncated when assigned to a host |
| | variable. |
+---------+--------------------------------------------------------------|
| 01005 | Insufficient number of entries in an SQLDA. |
+---------+--------------------------------------------------------------|
| 0100C | One or more ad hoc result sets were returned from the |
| | procedure. |
+---------+--------------------------------------------------------------|
| 0100E | The procedure returned too many result sets. |
+---------+--------------------------------------------------------------|
| 01503 | The number of result columns is larger than the number of |
| | host variables provided. |
+---------+--------------------------------------------------------------|
| 01504 | The UPDATE or DELETE statement does not include a WHERE |
| | clause. |
+---------+--------------------------------------------------------------|
| 01505 | The statement was not executed because it is unacceptable in |
| | this environment. |
+---------+--------------------------------------------------------------|
| 01506 | An adjustment was made to a DATE or TIMESTAMP value to |
| | correct an invalid date resulting from an arithmetic |
| | operation. |
+---------+--------------------------------------------------------------|
| 01507 | One or more non-zero digits were eliminated from the |
| | fractional part of a number used as the operand of a |

84 Klase SQLSTATE kodova
| | multiply or divide operation. |
+---------+--------------------------------------------------------------|
| 01514 | The tablespace has been placed in the check-pending state. |
+---------+--------------------------------------------------------------|
| 01515 | The null value has been assigned to a host variable, because |
| | the non-null value of the column is not within the range of |
| | the host variable. |
+---------+--------------------------------------------------------------|
| 01516 | An inapplicable WITH GRANT OPTION has been ignored. |
+---------+--------------------------------------------------------------|
| 01517 | A character that could not be converted was replaced with a |
| | substitute character. |
+---------+--------------------------------------------------------------|
| 01518 | The definition of the table has been changed to incomplete. |
+---------+--------------------------------------------------------------|
| 01519 | The null value has been assigned to a host variable, because |
| | a numeric value is out of range. |
+---------+--------------------------------------------------------------|
| 01520 | The null value has been assigned to a host variable, because |
| | the characters cannot be converted. |
+---------+--------------------------------------------------------------|
| 01521 | A specified server-name is undefined but is not needed until |
| | the statement is executed or the alias is used. |
+---------+--------------------------------------------------------------|
| 01522 | The local table or view name used in the CREATE ALIAS |
| | statement is undefined. |
+---------+--------------------------------------------------------------|
| 01523 | ALL was interpreted to exclude ALTER, INDEX, REFERENCES, and |
| | TRIGGER, because these privileges cannot be granted to a |
| | remote user. |
+---------+--------------------------------------------------------------|
| 01524 | The result of a column function does not include the null |
| | values that were caused by evaluating the arithmetic |
| | expression implied by the column of the view. |
+---------+--------------------------------------------------------------|
| 01525 | The number of INSERT values is not the same as the number of |
| | columns. |
+---------+--------------------------------------------------------------|
| 01527 | A SET statement references a special register that does not |
| | exist at the AS. |
+---------+--------------------------------------------------------------|
| 01528 | WHERE NOT NULL is ignored, because the index key cannot |
| | contain null values. |
+---------+--------------------------------------------------------------|
| 01529 | As a result of the DROP INDEX, the UNIQUE constraint is no |
| | longer enforced. |
+---------+--------------------------------------------------------------|
| 01530 | Definition change may require a corresponding change on the |

85
| | read-only systems. |
+---------+--------------------------------------------------------------|
| 01532 | An undefined object name was detected. |
+---------+--------------------------------------------------------------|
| 01533 | An undefined column name was detected. |
+---------+--------------------------------------------------------------|
| 01537 | An SQL statement cannot be EXPLAINed, because it references |
| | a remote object. |
+---------+--------------------------------------------------------------|
| 01538 | The table cannot be subsequently defined as a dependent, |
| | because it has the maximum number of columns. |
+---------+--------------------------------------------------------------|
| 01539 | Connection is successful but only SBCS characters should be |
| | used. |
+---------+--------------------------------------------------------------|
| 01540 | A limit key has been truncated to 40 bytes. |
+---------+--------------------------------------------------------------|
| 01542 | Authorization ID does not have the privilege to perform the |
| | operation as specified. |
+---------+--------------------------------------------------------------|
| 01543 | A duplicate constraint has been ignored. |
+---------+--------------------------------------------------------------|
| 01545 | An unqualified column name has been interpreted as a |
| | correlated reference. |
+---------+--------------------------------------------------------------|
| 01546 | A column of the explanation table is improperly defined. |
+---------+--------------------------------------------------------------|
| 01548 | The authorization ID does not have the privilege to perform |
| | the specified operation on the identified object. |
+---------+--------------------------------------------------------------|
| 01551 | A table in a partitioned tablespace is not available, |
| | because its partitioned index has not been created. |
+---------+--------------------------------------------------------------|
| 01552 | An ambiguous qualified column name was resolved to the first |
| | of the duplicate names in the FROM clause. |
+---------+--------------------------------------------------------------|
| 01553 | Isolation level RR conflicts with a tablespace locksize of |
| | page. |
+---------+--------------------------------------------------------------|
| 01554 | Decimal multiplication may cause overflow. |
+---------+--------------------------------------------------------------|
| 01558 | A distribution protocol has been violated. |
+---------+--------------------------------------------------------------|
| 01560 | A redundant GRANT has been ignored. |
+---------+--------------------------------------------------------------|
| 01561 | An update to a data capture table was not signaled to the |
| | originating subsystem. |
+---------+--------------------------------------------------------------|

86 Klase SQLSTATE kodova
| 01566 | The index has been placed in a recover-pending state. |
+---------+--------------------------------------------------------------|
| 01568 | The dynamic SQL statement ends with a semicolon. |
+---------+--------------------------------------------------------------|
| 01569 | The statement will be executed at a DB2 system that does not |
| | support character conversion. |
+---------+--------------------------------------------------------------|
| 01590 | Type 2 indexes do not have subpages. |
+---------+--------------------------------------------------------------|
| 01591 | The result of the positioned UPDATE or DELETE may depend on |
| | the order of the rows. |
+---------+--------------------------------------------------------------|
| 01594 | Insufficient number of entries in an SQLDA for ALL |
| | information (i.e. not enough descriptors to return the |
| | distinct name). |
+---------+--------------------------------------------------------------|
| 01596 | Comparison functions were not created for a distinct type |
| | based on a long string data type. |
+---------+--------------------------------------------------------------|
| 01597 | Specific and non-specific volume IDs are not allowed in a |
| | storage group. |
+---------+--------------------------------------------------------------|
| 01602 | The optimization level has been reduced. |
+---------+--------------------------------------------------------------|
| 01608 | An unsupported value has been replaced. |
+---------+--------------------------------------------------------------|
| 01612 | The part clause of a LOCK TABLE statement is not valid. |
+---------+--------------------------------------------------------------|
| 01614 | There are fewer locators than the number of result sets. |
+---------+--------------------------------------------------------------|
| 01616 | The estimated CPU cost exceeds the resource limit. |
+---------+--------------------------------------------------------------|
| 01624 | The GBPCACHE specification is ignored because the bufferpool |
| | does not allow caching. |
+---------+--------------------------------------------------------------|
| 01625 | The schema name appears more than once in the CURRENT PATH. |
+---------+--------------------------------------------------------------|
| 01628 | The user-specified access path hints are invalid. The access |
| | path hints are ignored. |
+---------+--------------------------------------------------------------|
| 01629 | User-specified access path hints were used during access |
| | path selection. |
+---------+--------------------------------------------------------------|
| 01635 | Statements in the same program have duplicate QUERYNOs. |
+---------+--------------------------------------------------------------|
| 01638 | SUBPAGES greater than one are not supported for Type 1 |
| | indexes in a data sharing environment. |
+---------+--------------------------------------------------------------|

87
| 01Hxx | Valid warning SQLSTATEs returned by a user-defined function |
| | or external procedure CALL. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 8. Class Code 02: No Data |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 02000 | One of the following exceptions occurred: |
| | |
| | @ The result of the SELECT INTO statement or the subselect |
| | of the INSERT statement was an empty table. |
| | @ The number of rows identified in the searched UPDATE or |
| | DELETE statement was zero. |
| | @ The position of the cursor referenced in the FETCH |
| | statement was after the last row of the result table. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 9. Class Code 07: Dynamic SQL Error |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 07001 | The number of host variables is not the same as the number |
| | of parameter markers. |
+---------+--------------------------------------------------------------|
| 07002 | The call parameter list or control block is invalid. |
+---------+--------------------------------------------------------------|
| 07003 | The statement identified in the EXECUTE statement is a |
| | select-statement, or is not in a prepared state. |
+---------+--------------------------------------------------------------|
| 07005 | The statement name of the cursor identifies a prepared |
| | statement that cannot be associated with a cursor. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 10. Class Code 08: Connection Exception |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 08001 | The application requester is unable to establish the |

88 Klase SQLSTATE kodova
| | connection. |
+---------+--------------------------------------------------------------|
| 08002 | The connection already exists. |
+---------+--------------------------------------------------------------|
| 08003 | The connection does not exist. |
+---------+--------------------------------------------------------------|
| 08004 | The application server rejected establishment of the |
| | connection. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 11. Class Code 09: Triggered Action Exception |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 09000 | A triggered SQL statement failed. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 12. Class Code 0A: Feature Not Supported |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 0A001 | The CONNECT statement is invalid, because the process is not |
| | in the connectable state. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 13. Class Code 0F: Invalid Token |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 0F001 | The locator value does not currently represent any value. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 14. Class Code 21: Cardinality Violation |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|

89
| 21000 | The result of a SELECT INTO is a result table of more than |
| | one row, or the result of the subquery of a basic predicate |
| | is more than one value. |
+---------+--------------------------------------------------------------|
| 21501 | A multiple-row INSERT into a self-referencing table is |
| | invalid. |
+---------+--------------------------------------------------------------|
| 21502 | A multiple-row UPDATE of a primary key is invalid. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 15. Class Code 22: Data Exception |
+------------------------------------------------------------------------|
| SQLSTATE| |
| Value | Meaning |
+---------+--------------------------------------------------------------|
| 22001 | Character data, right truncation occurred; for example, an |
| | update or insert value is a string that is too long for the |
| | column, or a datetime value cannot be assigned to a host |
| | variable, because it is too small. |
+---------+--------------------------------------------------------------|
| 22002 | A null value, or the absence of an indicator parameter was |
| | detected; for example, the null value cannot be assigned to |
| | a host variable, because no indicator variable is specified. |
+---------+--------------------------------------------------------------|
| 22003 | A numeric value is out of range. |
+---------+--------------------------------------------------------------|
| 22007 | An invalid datetime format was detected; that is, an invalid |
| | string representation or value was specified. |
+---------+--------------------------------------------------------------|
| 22008 | Datetime field overflow occurred; for example, an arithmetic |
| | operation on a date or timestamp has a result that is not |
| | within the valid range of dates. |
+---------+--------------------------------------------------------------|
| 22011 | A substring error occurred; for example, an argument of |
| | SUBSTR is out of range. |
+---------+--------------------------------------------------------------|
| 22012 | Division by zero is invalid. |
+---------+--------------------------------------------------------------|
| 22018 | The character value for the CAST, DECIMAL, FLOAT, or INTEGER |
| | scalar function is invalid. |
+---------+--------------------------------------------------------------|
| 22019 | The LIKE predicate has an invalid escape character. |
+---------+--------------------------------------------------------------|
| 22021 | A character is not in the coded character set. |
+---------+--------------------------------------------------------------|
| 22023 | A parameter or host variable value is invalid. |

90 Klase SQLSTATE kodova
+---------+--------------------------------------------------------------|
| 22024 | A NUL-terminated input host variable or parameter did not |
| | contain a NUL. |
+---------+--------------------------------------------------------------|
| 22025 | The LIKE predicate string pattern contains an invalid |
| | occurrence of an escape character. |
+---------+--------------------------------------------------------------|
| 22501 | The length control field of a variable length string is |
| | negative or greater than the maximum. |
+---------+--------------------------------------------------------------|
| 22503 | The string representation of a name is invalid. |
+---------+--------------------------------------------------------------|
| 22504 | A mixed data value is invalid. |
+---------+--------------------------------------------------------------|
| 22505 | The local date or time length has been increased, but the |
| | executing program relies on the old length. |
+---------+--------------------------------------------------------------|
| 22506 | A reference to a datetime special register is invalid, |
| | because the TOD clock is malfunctioning or the operating |
| | system timezone parameter is out of range. |
+---------+--------------------------------------------------------------|
| 22508 | CURRENT PACKAGESET is blank. |
+---------+--------------------------------------------------------------|
| 22511 | ADT length exceeds maximum column length. The value for a |
| | ROWID or reference column is not valid. |
+---------+--------------------------------------------------------------|
| 22512 | A host variable in a predicate is invalid, because its |
| | indicator variable is negative. |
+---------+--------------------------------------------------------------|
| 22522 | A CCSID value is not valid at all, not valid for the data |
| | type or subtype, or not valid for the encoding scheme. |
+---------+--------------------------------------------------------------|
| 22525 | Partitioning key value is not valid. |
+------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| Table 16. Class Code 23: Constraint Violation |
+------------------------------------------------------------------------|