Tehnicko-teorijsko pitanje kada je u pitanju upisivanje u TRL

Pozdrav!

Jedno tehnicko-teorijsko pitanje kada je u pitanju upisivanje u TRL, i u bazu, i uopste nacina na koji radi sve ovo. Ako neko moze da dopuni moju pricu, ili da me ispravi tamo gde gresim.

Naime, imam transakciju. Nju prvo upisujem u TRL, pa u cache. Nakon neceg sto se zove "kontrolna tacka", sve se upisuje u bazu.

Kada kazem "sve se upisuje u bazu", mislim da se upisuje fizicki na disk, dakle u mdf ili u ndf fajl.

Da li sam u pravu za sada?


Dakle jos jednom, kada sam upisao u TRL, a jos nisam upisao u bazu, sve se upisuje u cache. Tek nakon toga, dolazi do upisivanja u bazu. Kada se upise u bazu, postavlja se checkpoint, koji oznacava da sve sto je do tada bilo u cache-u, konacno upisano i na disk.

Dalje...

Lako moze da se desi, da zadam upit, a da podaci jos nisu upisani u fajl (onaj gore koji sam spomenuo). Ako bih u tom slucaju zadao upit nad podacima, sve bi se korektno selektovalo, jer ako jos uvek nije zapisano na disku, imam ga u cache-u.


Da li mozete da mi kazete da li sam u pravu? Ne razumem u potpunosti deo koji se desava nakon upisivanja u TRL, a da jos nije postavljen check point. Da li se tada podaci ucitavaju i iz cache-a, ili su mozda nedostupni u tom periodu vremena?

Hvala unapred!

J.

Evo jednog jednostavnog primera:


create table tabela1
(polje1 int,
polje2 float)


begin tran

insert into tabela1
values (0, 0.1)

select * from tabela1 -- vraca 1 slog

rollback tran


select * from tabela1 -- ne vraca nista


Nadam se da je sada jasnije?

Potpis

http://www.montaznekuce.rs

Nije bas
:-)

Gde si commitovao transakciju?

Pa nije bas toliko jednosatvno, ali nije ni daleko. U principu entiteti u mdf file sistemu su podeljeni na stranice (page) i svaka od stranica je podlozna kesiranju u memoriji i svaka promena se radi ovim redosledom:

1. Upisuje u memorijski kes TRLa (vrh loga je uvek kesiran u memoriji)
2. Upisuje u kesiranoj stranici u memoriju (prvo je kesira ako nije tu) usput generisuci lockove na odredjenom nivou granulacije (to je druga prica)

Posto SQL koristi write-ahead log, kad se radi flushovanje kesa na disk (sto se ne podudara sa commit/rollbackom transakcija) redom se:

1. Flushuje TRL
2. Flushuju commited stranice
3. Udara checkpoint "pecat" u TRL i isti se trunc-uje ako je recovery model = simple.

U principu nista ne ulazi u data files a da se operacija pre toga ne zabelezi u TRLu bilo fizicki bilo u kesu. To sluzi za roll-forward popravku data fajlova ako server pukne u drugom koraku, kad se digne sledeci put krece se provera od poslednjeg checkpointa i odreadjuje korak 2 za sve transakcije (s tim sto se nezatvorene transakcije rollbackuju). Takodje obrati paznju da se uncommited stranice ne izbacuju iz cache-a (da se izbacuju bilo bi nemoguce spreciti dirty-read efekat jer stara kopija vise ne bi postojala) dok se TRL kes operacije koja je "isprljala" page svejedno mora da ode na disk TRL zbog sekvencijalnog poretka operacija.




Ne da lako moze nego se to stalno i desava . Tacan odgovor na to sta se desava i ciji select ce sta da vrati u ovakvim situacijama zavisi od stepena izolacije transakcije i trenutnih aktivnih lockova. Tebi, kao nosiocu transakcije, ce se uvek vratiti ono sto je u kesu (uncommited) ali drugima ne mora, ako je izolacija npr takva da je iskljucen dirty read, dobice staru verziju stranice sa diska.
Pogledaj ovaj link za vise detalja:
Isolation Levels in the Database Engine

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić