STANDARDNO PODEŠAVANJE DEFAULT RAZMIŠLJANJE

UVOD

Sa bazama podataka radim oko 10 godina isključivo kao DB developer, od tih 10 godina, 7 godina sam proveo u razvoju aplikacija pod Oracle bazom podataka, a zadnje 3 godine radim sa MSSQL bazom podataka.

Ono što upada u oko svakom ko se priključi nekom novom/starom projektu, je činjica da se ti projekti u velikom broju slučaja razvijaju na standardnim podešavanjima baze podataka. Upravo ova standardna podešavanja uveliko definišu i način razmišljanja developera koji počinju da rade na tim projektima. Ovde dolazimo do suštinskih razlika između developera koji rade sa MSSQL-om i Oracle-om.

MALO O IZOLACIONIM NIVOIMA ORACLE I MSSQL BAZE

Standardna podešavanja izolacionog nivoa obje baze je read committed. Posljedice ovog podešavanja su iskazane u tabeli.

Međutim, pristup ovom izolacionom nivou je drugačiji. MSSQL koristi pesimistični pristuop dok Oracle koristi optimistični pristup. 

U prevodu ovo znači:

MSSQL 

onaj koji piše blokira onog koji piše
onaj koji piše blokira onog koji čita 
onaj koji čita ne blokira onog koji čita

Oracle 

onaj koji piše blokira onog koji piše
onaj koji piše ne blokira onog koji čita 
onaj koji čita ne blokira onog koji čita

MALO O PRAKSI

U praksi ovo znači:

MSSQL

• prekomjerno korišćenje NOLOCK-a u select iskazima zbog "poboljšanja" performansi, tj. izbjegavanje mehanizma locking-a, što dobrim dijelom bazu podataka dovodi u izolacioni nivo read uncommitted
• dizajn i logika sistema su podređeni činjenici da baza lebdi iznad dva izolaciona nivoa, read committed i read uncommitted
• opasnost od: dirty read, non-repeatable read, phantom read

Oracle

• optimistični pristup Oracle baze garantuje da će podaci biti onakvi kakvi su bili u momentu izvršenja sql iskaza(statement -level read consistency)
• veća odgovornost DB developera u implementaciji poslovne logike na nivou baze podataka
• opasnost od: non-repeatable read, phantom read

Sa stanovištva razvoja (DB development) baze podataka u vidu kreiranja procedura, pogleda i neke poslovne logike skladištene u bazi, daleko je lakše voditi računa o non-repeatable reads i phantom reads, nego raditi u okruženju koje dodatno dodaje mogućnost dirty read-a ili locking-a prilikom select iskaza. 

Ukoliko pogledamo pravila koje je legendarni Tom Kyte napisao:

• You should do it in a single SQL statement if at all possible.
• If you cannot do it in a single SQL Statement, then do it in PL/SQL.
• If you cannot do it in PL/SQL, try a Java Stored Procedure.
• If you cannot do it in Java, do it in a C external procedure.
• If you cannot do it in a C external routine, you might want to seriously think about why it is you need to do it....; 

vidimo da u prvom pravilu(do it in a single SQL statement) izbjegavmo non-repeatable reads i phantom reads u slučaju optimističnog read committed izolacionog nivoa. Sa svim bazama sa kojima sam se susreo, većina logike je zapravo skladištena ili može biti skladištena u pojedinačnim SQL iskazima ukoliko se sva moće i potencijal SQL jezika iskoristi.

STATEMENT-LEVEL READ CONSISTENCY

Statement-level read consistency sigurno nije neki magični štapić RDBMS, ali iz ličnog iskustva mogu slobodno reći da je pola magičnog štapića, dok je druga polovina u samom programeru (hint: select for update ili updlock). 

U Oracle RDBMS ovaj mehanizam je riješen preko UNDO segmenta. Činjenica je da Oracle DB administratori moraju biti svjesni ovoga segmenta i ako je to neophodno izvršiti određena podešavanja, jer tome i služe administratori.

Ali da se vratimo MSSQL-u. Ni MSSQL-u statement-level read consistency nije stran. Ali da bi baza bila podešena da radi u optimističnom read committed izolacionom nivou neophodno je izvršiti komandu: 

ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON;

Po izvršenju komande, MSSQL počinje da koristi tempdb za čuvanje predhodnih verzija redova (podataka iz tabele) koji omogućuju konzistentnost čitanja u sql iskazu.

Sigurno je da ovo utiče na performanse sistema, ali mišljenja sam da je cijena mala u poređenju sa mogućim locking-om pesimističkog read committed i read uncommitted izolacionih nivoa.

Sa druge strane, vrlo teško je postojeće sisteme prilagoditi novoj logici, te tako jednom razvijen sistem sa pesimističnim pristupom bi zahtjevao reviziju kompletnog koda ispisanog u bazi, što me dovodi do naslova ovog bloga: STANDARDNO PODEŠAVANJE DEFAULT RAZMIŠLJANJE na koji bih dodao HARD ROLLBACK.

PITANJA

Kako nisam DB administrator guru sa anormnim tehničkim znanjem (under the hood) baza, ne mogu ulaziti detaljno u tehnička pitanja i realizacije nekih stvari sa ove dvije baze, ali smatram da kao DB developer mogu postaviti par hipotetičkih pitanja koliko god ona bila ili izgledala naivna:

Zašto Microsfot ne isporučuje SQL Server gdje je standardno podešavanje baze optimistični pristup read committed izolacionom nivou?

Ako je briga tempdb, zašto Microsoft ne napravi novu sistemsku bazu sa posebnim database fajlovima zaduženim za verzionisanje podataka, gdje će se DB administraotrima omogućiti održavanje tih fajova/baze (size, grow, retention period itd....) po uzoru na Oracle UNDO segment?

ZAKLJUČAK

Za zaključak mogu reći par stvari... 
Volio bih da čujem više o iskustvima ljudi koji rade sa MSSQL čije baze rade u režimu optimističnog read committed...
Možda suštineske razlike između ova dva pristupa počivaju na mogućnostima i nemogućnostima jezika T-SQL i PL/SQL...
Možda suštineske razlike počivaju negdje dublje na nivou bloka...
Možda je neko samo postavio pogrešno default podešavanje...