Transactional Consistency i Point-in-time Recovery
Microsoft SQL Server i Oracle imaju ugradjen mehanizam za zaštitu korisničkih transakcija. Ideja koja se nalazi iza “transactional consistency” je da se promjene koje se izvrše nad podacima ne upisuju odmah u fajlove na disku operativnog sistema. Umjesto toga, izmjene se upisuju u operativnu memoriju servera u dio koji se naziva buffer cache. Iz buffer cache-a se podaci periodično prenose u fajl na disku u kojem su konkretni podaci za konkretne tabele baze podataka. Pored buffer cache-a, u memoriji servera postoji još jedan buffer. To je log buffer i on je vezan za čuvanje promjena nad podacima koje urade korisnici. Log buffer se koristi za kontinualno i sekvencijalno zapisivanje svih izmjena koje su izvršene nad podacima u bazi podataka. Sadržaj ovog buffera se upisuje u odvojeni – nezavisni fajl baze podataka na disku. Pošto imamo dva nezavisna bafera sa podacima (buffer keš i log buffer keš) postoje i 2 odvojena pozadinska procesa koji upisuju sadržaje ovih bufera u fizičke fajlove na disku. Log buffer keš se mnogo češće upisuje na disk nego buffer keš. To je zato što je operacija koja izvršava prenos log buffera mnogo brža – log file je obični sekvencijalni fajl kod koga se na njegov kraj dodaju novi slogovi sa podacima o promjenama na tabelama u redosljedu u kojem su se promjene dešavale (uočiti da je prepis iz buffer keša u fajl sa stvarnim podacima mnogo sporiji jer se za taj prepis uvjek mora prvo naći tačna pozicija u fajlu, tačna tabela i slog na koji se upisivanje odnosi i zbog toga se ovaj upis mnogo ređe izvršava)
Ukoliko korisnik uspješno komituje transakciju, promjene će postojati u buffer cache-u ali promjene iz buffer cache-a neće biti odmah upisane u data fajlove na diskovima. Promjene će se snimiti i u sekvencijalni log buffer. Sadržaj log buffer-a će biti prenešen na log file na disku prije nego što korisnik dobije signal od RDBMS-a da je uspješno uradjen commit njegove operacije.
SQL Server ovaj log fajl naziva Transaction Log. Kod Oracle-a se ovaj log naziva Redo Log. U SQL Server terminologiji, prostor u memoriji koji sadrži izmjene nad podacima je poznat pod imenom Log Buffer. Oracle za tu namjenu koristi termin Redo Buffer. Bez obzira na razliku u imenovanju, funkcije log fajlova su identične: ukoliko server “neočekivano padne”, database server će pretražiti sadržaj log fajla poslije restarta baze podataka. Ukoliko server u log fajlu pronadje komitovane transakcije koje nisu prenešene u fajl sa podacima, on će izvršiti izmjene na podacima u data fajlu na disku tako da će se izmjene jednom učinjene od strane korisnika prije pada sistema reflektovati u bazi podataka poslije njenog restarta. Ukoliko server prilikom restarta u log fajlu pronadje transakcije koje su nekompletne ili transakcije nad kojima je uradjen roll back, server će uraditi roll back i na podacima u data fajlovima. Prva faza obrade se naziva redo faza a druga je poznata pod nazivom undo.
SQL Server održava po jedan transaction log za svaku od svojih baza na hostu. Database transaction log može imati jedan ili više transakcionih log fajlova koji su mu dodjeljeni. Transactioni log fajlovi se kreiraju u vrijeme kreiranja baze podataka a dodatni fajlovi se mogu kreirati kasnije. Kod Oracle-a, koncept baze podataka obuhvata sve fizičke data fajlove i logičke tablespace-ove kojima on upravlja. Oracle-ovi redo logovi se kreiraju kao set fajlova koji prihvataju promjene koje se načine u svim tablespace-ovima. Svaka Oracle baza podataka mora da ima najmanje 2 redo log file-a za svoje operacije. Može postojati više od 2 redo log file-a, ali su 2 minimum.
Jedna očigledna razlika izmedju SQL Server transaction logova i Oracle redo logova je da SQL Server transaction log fajlovi nisu grupisani ninakoji logičan način. Redo log fajlovi kod Oracle-a su dodjeljeni dvema ili većem broju redo log grupa. Svaka Oracle baza podataka mora imati najmanje 2 redo log grupe a svaka grupa mora imati jedan ili više redo logova. Log fajlovi u svakoj grupi se nazivaju članovima (members) grupe.
Oracle upisuje redo ulaze iz svog log buffer-a u jednom trenutku u jednu redo grupu. Kada se redo ulaz upiše u redo log grupu, svaki member fajl groupe se update-uje u isto vrijeme. Postojanje više od jednog fajla u redo log fajl grupi obezbjedjuje zaštitu od eventualnog oštećenja fajla u grupi i naziva se multiplexing. Kada se log grupa napuni sa redo slogovima, Oracle će startovati upis logova u narednu redo grupu. Ovaj postupak se naziva log switching. Jednom, kada se grupa napuni, upis će se prosljediti na sljedeću grupu i tako redom. Ako je baza u NoArchiveLog modu, kada se napune sve redo grupe (bez obzira da li ih ima 2 ili više), Oracle će isprazniti prvu redo log grupu u lancu i početi ponovo upis u nju. Ukoliko Oracle baza radi u tzv Archive log modu i ukoliko su napunjeni svi ulazi u redo log bufferima, a pri tom iz redo log buffera koji je naredni za upis izmjenjenih podataka na disk podaci nisu preneseni na redo log fajl na disku, korisnička(e) transakcija(e) će biti zaustavljene dok se redolog buffer ne isprazni. Pražnjenje podataka iz Redo log buffer-a se najčešće vrši automatski (mada se može insistirati i na ručnom prenosu). Konfiguracionim parametrima na nivou baze se može promjeniti način izvršenja ove operacije.
SQL Server transakcioni log baze podataka se takodje puni u sekvenciajlnom redu. Log se ne briše automatski osim ako baza podataka ne radi u tzv simple recovery modu ili ukoliko se ne uradi backup transaction loga. Ukoliko logički transaction log za bazu podataka postane pun i ukoliko se log fajl za koji je logički transakcioni log vezan toliko velik da se više ne može povećavati, baza podataka postaje neraspoloživa za bilo kakvu korisničku aktivnost. Ako se izvrši backup transakcijskih logova, SQL Server će dozvoliti da se preko backup-ovanih ulaza u log fajl uradi novi upis novih transakcija.
Sljedeći detalj koji treba da primjetimo jeste da se SQL Serverov transaction log fajl može konfigurisati na način da se povećava automatski kada postoji potreba za većim prostorom u njemu. Oracleov redo log fajl se kreira sa predefinisanom veličinom i ona se ne povećava automatski osim ako se ta veličina kasnije ručno ne promjeni..
Sa stanovišta raspoloživosti podataka, obadvije platforme omogućuju point-in-time recovery. Ukoliko se želi, ova osobina može biti isključena. Kada je SQL Server baza podataka konfigurisana da radi u point-in-time recovery modu, kaže se da je ona u full recovery mode-u. Svaka modifikacija podataka u bazi podataka se evidentira u tranasction log-u nezavisno od toga koji se recovery moda primjenjuje za bazu podataka. Ovi log slogovi ostaju u fajlu dok se ne uradi transaction log backup. Baza podataka može biti i u simple recovery mode u kom slučaju slogovi u transaction logu ostaju dok se ne izvrši checkpoint. Checkpoint snima modifikovane podatke iz buffer keša i log keša u data fajlove i log fajlove na disku. Ukoliko baza podataka radi u tzv. simple recovery modu, svi slogovi u transaction logu prije najstarije otvorene transakcije se brišu poslije izvršenog checkpoint-a. Ovo se radi zato što SQL Server zna da su sve komitovane transakcije prije najstarije otvorene transakcije već bile upisane u fajl sa podacima.
Ukoliko se desi greška (fizička ili logička) u bazi podataka, prvo se treba restaurirati njen poslednji full backup a zatim se trebaju primjeniti svi backup-ovani tranasakcioni logovi koji su uradjeni poslije poslednjeg full backupa baze podataka. Ovo svojstvo nam omogućava da vratimo stanje baze podataka u bilo koji momenat vremena u prošlosti. Treba imati u vidu da ova funkcionalnost radi samo ako je baza podataka u full recovery mode.
Oracle ima sličan koncept. Oracle baza podataka može biti u ARCHIVELOG ili NOARCHIVELOG modu. Kada radi u NOARCHIVELOG modu, sadržaj prve redo log grupe se ponovo koristi za upis čim se poslednja log grupa u lancu napuni. Poštoo se sadržaj redo log grupa ne arhivira u ovom režimu rada, sistem se neće moći vratiti na stanje u nekoj vremenskoj tački u prošlosti koja je izbrisana u redolog-u. Funkcionalno, ovo je ekvivalentno SQL Serveru koji je u simple recovery modu.
Ako Oracle baza podataka radi u ARCHIVELOG modu, jedan ili više archive procesa će raditi u pozadini. Arhiv procesi vrše backup sadržaja redo log grupa kada one postanu pune i pohranjuju ih u odvojene fajlove na disk podsistemu. Ove sačuvane kopije redo log grupa su poznate pod imenom archived log. Jednom kada se log grupa arhivira, može se ponovo koristiti za upis podataka. Ako pokušamo naći paralelu, arhiving kod Oracle redo log grupa je funkcionalno ekvivalentno SQL Server transaction log backup-u a ARCHIVELOG mod je ekvivalentan full recovery modu.
Za Oracle, kao i za SQL Server, archivirani logovi se mogu primjeniti na bazu podataka tek pošto se uradi restore nekog full backup-a. Razlika izmedju ova dva sistema za upravljanje bazama podataka je da kod SQL Servera, transaction log backup task treba biti postavljen manuelno – ručno kao scheduled job, dok kod Oracle-a archiver proces automatski vodi računa o backup-u kada se baza podataka jednom konfiguriše za tu namjenu.
Konačno, ekvivalencija izmedju ovih platformi može biti uočena takodje i u terminologiji recovery time. Kao što je napomenuto ranije, kada se startuje DB engine, cjeli proces će ići kroz redo i undo fazu. Ukupno vrijeme provedeno u uvim dvijema fazama je poznato kao recovery interval. Očigledno je da će DBA želiti da recovery interval bude što je moguće manji. Kod SQL Servera, DBA može konfigurisati ovaj interval izvršavajući komande date u nastavku:
sp_configure ‘show advanced option’, 1
reconfigure
sp_configure ‘recovery interval’, <time-in-minutes>
reconfigure
Ova komanda modifikuje sistemske konfiguracione parametre. Kada se postavi recovery interval, SQL Server će upodobiti frekvenciju svog checkpoint procesa na svakoj od baza podataka tako da vrijeme provedeno tokom recovering-a svake od baza podataka ne premašuje ovaj interval. Recovery interval se specificira u minutama.
Oracle-ov ekvivalenat za recovery interval je Mean Time To Recover (MTTR). Ovaj parametar se može setovati mjenjajući Oracleov inicijalni parametar FAST_START_MTTR_TARGET. Ovaj parametar može biti postavljen za tzv fine-tune checkpoint frequency. Njegova vrijednost odredjuje koliko mnogo sekundi će Oracle provesti u database recovery poslije pada servera. Parameter može biti postavljen koristeći komandu poput sljedeće:
ALTER SYSTEM SET FAST_START_MTTR_TARGET=<number_of_seconds> SCOPE=spfile;
Blog by Sasa Tadic - Podgorica 