Lokin ylläpito ja puskurinhallinta C. Mohan, D. Haderle, B. Lindsay, H. Pirahesh & P. Schwartz: ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging. ACM Transactions on Database Systems 17:1 (1992), 94 162; kohdat 1.1 (logging, failures, and recovery methods), 1.2 (latches and locks), 1.4 (buffer management), 2 (goals), 3 (overview of ARIES), 4 (data structures), 5.1 (updates) ja 9 (nested top actions). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Fifth Edition. McGraw-Hill, 2006, sivut 461 464, luvun 11 (storage and file structure) kohdat 11.5.1 (buffer manager) ja 11.5.2 (buffer-replacement policies); sivut 684 697, luvun 17 (recovery system) kohdat 17.2 (storage structure), 17.3 (recovery and atomicity) ja 17.4 (log-based recovery); sivut 699 702, kohta 17.6 (buffer management); sivut 704 705, kohta 17.8.1 (logical undo logging); sivut 708 709, kohdan 17.8.6 (ARIES) alakohta 17.8.6.1 (data structures). 77
Tietokannan loki, s. 79. Fyysinen ja looginen lokikäytäntö, s. 83. Fysiologinen lokikäytäntö, s. 87. Aktiivisten transaktioiden taulu, s. 91. Avainvälimallin operaatioiden lokikirjaukset, s. 94. Rakennemuutosten lokikirjaukset, s. 101. Tietosivun päivittäminen, s. 104. WAL-käytäntö, s. 107. Puskurinhallintakäytännöt, s. 110. Levyhakujen vähentäminen, s. 116. 78
Tietokannan loki Normaalin transaktionkäsittelyn aikana pidetään yllä lokia (log) seuraavia tarkoituksia varten: (1) Transaktioiden peruutus tai osittaisperuutus: etenemisvaiheen päivitysten käänteisoperaatioiden tuottaminen. (2) Häiriöistä elvytys: tietokannan levyversiosta puuttuvien päivitysten toisto ja transaktioiden peruutus. Lokiin kirjataan transaktioiden tietokantaan tekemät päivitykset, so. avainvälimallissa I-, D-, I 1 - ja D 1 -operaatiot, transaktioiden ohjausoperaatiot B, C, A, S[P], A[P] ja C[P], fyysisen tietokannan rakennemuutokset sekä elvytystä nopeuttavaa tietoa tarkistuspisteistä. 79
Jokainen lokikirjaus saa yksikäsitteisen lokijärjestysnumeron (log sequence number, LSN). Keskitetyssä tietokannassa lokijärjestysnumeroiden jono on nouseva: jos transaktion T operaatio o on suoritettu transaktion T operaation o jälkeen, on LSN(o) < LSN(o ). Yhteislevy- tai sivupalvelinjärjestelmässä, jossa pisteet (asiakkaat) tuottavat yhteiseen tietokantaan kohdistamistaan operaatioista lokikirjauksia toisistaan riippumattomasti, ei lokijärjestysnumeroiden jono voi olla globaalisti nouseva. Samalle sivulle kohdistuvien päivitysten LSN-arvojen pitää kuitenkin aina muodostaa ajan suhteen nouseva jono. 80
Lokijärjestysnumerot pyritään tuottamaan siten, että ne toimivat myös suorina (tai lähes suorina) osoitteina lokikirjauksiin. Usein käytetään lokitiedoston numeron ja tavusiirtymän muodostamaa paria. Tavusiirtymä ilmoittaa lokikirjauksen ensimmäisen tavun numeron tiedoston alusta lukien; siitä saadaan tietueen sijaintisivu operaatiolla sivunumero = tavusiirtymä div sivun koko. Tavusiirtymän sijasta voitaisiin käyttää myös tietuetunnistetta (p, i), missä p on sivunumero (1,2,3,...) ja i tietueen järjestysnumero sivulla (sivun sisäisen tietuehakemiston indeksi). Silloin (p 1,i 1 ) < (p 2,i 2 ), jos joko p 1 < p 2 tai p 1 = p 2 ja i 1 < i 2. Transaktion T tuottama lokikirjaus varustetaan aina T :n tunnisteella ja T :lle kuuluvat lokikirjaukset linkitetään LSN:ien avulla toisiinsa. 81
Transaktion T lokikirjauksen yleinen muoto on n: T,o[ x],n, missä o[ x] esittää kirjattavaa operaatiota ja sen argumentteja, n on kirjauksen LSN ja n on joko T :n edellisen lokikirjauksen LSN (etenemisoperaation kirjauksessa) tai T :n seuraavaksi peruutettavan operaation lokikirjauksen LSN (käänteisoperaation kirjauksessa). Transaktion T etenemisoperaatio o[ x] kirjataan lokitietueeseen siten, että operaatio voidaan tarvittaessa toistaa tai perua. Transaktion T peruutusvaiheessaan tai osittaisperuutuksessa suorittama käänteisoperaatio o 1 [ x] on tarpeen kirjata ainoastaan toistokelpoisesti: operaatio o 1 [ x] on lokikirjauksen perusteella voitava toistaa; peruutuskelpoisuus ei sitä vastoin ole tarpeen, koska käänteisoperaatioita ei koskaan peruta. Lokikirjauskäytännöt voidaan luokitella fyysisiin, loogisiin ja fysiologisiin lokikäytäntöihin. 82
Fyysinen ja looginen lokikäytäntö Arvoperustaisessa eli fyysisessä lokikäytännössä (value logging, physical logging) lokitietueeseen kirjataan päivityksen kohteena olevan sivun numero, päivitysoperaation vaikutuksesta muuttuneiden tavujen sijainti sivulla sekä päivityksen alkukuva ja jälkikuva. Alkukuva (before image) ilmoittaa tavujen sisällön ennen päivitystä ja jälkikuva (after image) tavujen sisällön päivityksen jälkeen. Esim. monikon (x,v) lisäyksestä sivulle p tietuepaikkaan i kirjattaisiin tietuepaikan i muuttuneet tavut sivun p tietuealueella sekä myös muuttuneet tavut sivun p tietuehakemistossa (indeksin i kohdalla) ja p:n otsikkotietueessa (tietuehakemiston alkioiden lukumäärän osoittavassa kentässä). 83
Muuttuneet tavujonot osoitteineen (tavusiirtymä sivun alusta) ja alku- ja jälkikuvineen voidaan kirjata kaikki yhteen lokikirjaukseen, mikäli tämä mahtuu yhdelle sivulle. Voidaan myös käyttää useampaa lokitietuetta; esim. alkukuva voidaan kirjata yhteen ja jälkikuva toiseen. Lokiin fyysisesti kirjattu päivitysoperaatio voidaan toistaa naulitsemalla ja kirjoitussalpaamalla asianomainen sivu ja kirjoittamalla siihen jälkikuva, ja operaatio voidaan perua kirjoittamalla alkukuva. 84
Loogisessa lokikäytännössä (logical logging) lokitietueeseen kirjataan loogisia operaatioita, so. avainvälimallissamme operaatioita I[x,v], D[x,v], I 1 [x,v] ja D 1 [x,v]. Esim. transaktion T etenemisoperaatio I[x,v] kirjattaisiin n: T,I,x,v,n, missä n on T :n edellisen lokikirjauksen LSN. Looginen operaatio toistetaan suorittamalla operaatio uudestaan (loogisesti) ja perutaan suorittamalla operaation käänteisoperaatio (loogisesti). Esim. I[x,v] perutaan suorittamalla D[x,v]. 85
Loogisesti kirjatun operaation toisto ja peruutus ovat tehottomia. Esim. toistetaan D[x,v]. Jos tietokannan rakenteena on kasa (järjestämätön peräkkäistiedosto), on siitä etsittävä avainarvolla x varustettu monikko konttaamalla kasan sivut läpi kirjoitussalpoja varaten, kunnes päästään monikon (x,v) sisältävälle sivulle. Jos tietokannan rakenteena on B-puu, on siitä etsittävä avainarvolla x varustettu monikko konttaamalla hakupolku B-puun juurisivulta avainarvon x peittävälle lehtisivulle. 86
Fysiologinen lokikäytäntö Nykyisissä tkhj:ssä sovelletaan yleensä fyysis-loogista eli fysiologista lokikäytäntöä (physiological logging), jossa lokikirjaukset ovat sivun osalta fyysisiä ja tietueen osalta loogisia. Esim. transaktion T harvan B-puun lehtisivulle p tietuepaikkaan i suorittama operaatio I[x,v] kirjataan n: T,I, p,i,x,v,n. Esitettävässä elvytysmenetelmässä (ARIES-algoritmissa) operaatioiden toistot suoritetaan aina täsmälleen lokikirjausjärjestyksessä eli operaatioiden alkuperäisessä suoritusjärjestyksessä. Fysiologisesti kirjatun operaation toisto voidaan niin muodoin aina toteuttaa fyysisesti, so. samalle sivulle p ja samaan tietuepaikkaan i, johon se alkujaan tehtiin ja jonka paikan osoite, (p,i), on kirjattu lokitietueeseen. 87
Fyysinen toisto on hyvin tehokasta, sillä operaation kohdetta ei tarvitse etsiä, vaan kohteen sijaintisivulle päästään suoraan riippumatta siitä, mikä fyysinen tietokantarakenne on kysymyksessä. Lokiin tietueella T,I, p,i,x,v,n kirjatun operaation I[x,v] toistossa sivu p naulitaan ja kirjoitussalvataan, lisätään monikko (x,v) sivulle p paikkaan i ja vapautetaan p:n salpaus ja naulinta. Lokiin tietueella T,D, p,i,x,v,n kirjatun operaation D[x,v] toistossa sivu p naulitaan ja kirjoitussalvataan, poistetaan sivulta p tietuepaikassa i oleva monikko (joka on (x,v)) ja vapautetaan p:n salpaus ja naulinta. 88
Operaation peruutus fyysisesti ei sitä vastoin aina ole mahdollista. Transaktioita tuottavat prosessit vapauttavat päivittämiinsä sivuihin varaamansa kirjoitussalvat heti päivitysoperaation suorituksen jälkeen, siis ennen transaktion sitoutumista, ja voivat peruuttaa operaatioitaan toisista transaktioista riippumatta. Transaktio T suorittaa B-puun lehtisivulle p paikkaan i operaation D[x,v]. Operaatio kirjataan lokiin tietueella n: T,D, p,i,x,v,n. T vapauttaa sivun p kirjoitussalvan ja jatkaa etenemistään suorittaen muita operaatioita. Muiden transaktioiden operaatiot sillä välin täyttävät sivua p niin, ettei sinne enää jää tilaa yhdellekään tietueelle, tai sitten sivu p ylivuotaa ja halkaistaan niin, että varattu uusi sivu p peittää avainarvon x. 89
T on vielä aktiivinen ja haluaa nyt peruuttaa operaation D[x,v]. Käänteisoperaation D 1 [x,v] suoritus fyysisesti sivulle p ei onnistu. Kun operaatiota ei voida peruuttaa fyysisesti, turvaudutaan loogiseen peruutukseen. Operaation D[x, v] peruutusta yritetään ensin entiselle sivulle p: sivu p naulitaan ja kirjoitussalvataan ja jos se vielä peittää avainarvon x ja jos sivulla p on tilaa monikolle (x,v), niin lisätään (x,v) sivulle p johonkin paikkaan j. Muutoin operaatio perutaan suorittamalla käänteisoperaatio D 1 [x,v] loogisesti: kuljetaan hakupolku puun juuresta x:n peittävälle lehtisivulle p ja lisätään (x,v) sinne. 90
Aktiivisten transaktioiden taulu Transaktionhallinnan ja elvytyksen tarpeisiin pidetään kirjaa transaktioista, jotka parhaillaan ovat aktiivisina. Kustakin aktiivisesta transaktiosta T säilytetään aktiivisten transaktioiden taulussa (activetransaction table) eli lyhyesti transaktiotaulussa (transaction table) seuraavia tietoja: (1) T :n tunniste. (2) T :n tila (state), so. forward-rolling (etenevä) tai backwardrolling (peruuntuva). (3) T :n tuottaman viimeisimmän vielä peruuttamatonta etenemisvaiheen operaatiota esittävän lokikirjauksen järjestysnumero Undo- Next-LSN. Käytännössä myös (4) T :n viimeisimmän lokikirjauksen järjestysnumero Prev-LSN (ei tarvita kurssilla esittävissä algoritmeissa). Transaktiotaulu perustetaan ja alustetaan tyhjäksi järjestelmää käynnistettäessä. 91
Kun järjestelmään tulee suoritettavaksi uusi transaktio, sille määrätään tunniste, T, kirjataan lokiin aloituskirjaus T,B ja viedään transaktiotauluun tietue (T, forward-rolling, Undo-Next-LSN = n), missä n on T :n aloituskirjauksen LSN. Kun transaktio sitoutuu tai päättää peruutuksensa, sen tiedot poistetaan transaktiotaulusta. Transaktiotaulu toteutetaan tehokkaana keskusmuistitietorakenteena (hajautus transaktion tunnisteella). 92
Transaktioiden peruutuksen ja häiriöistä elvytyksen tarpeisiin olisi transaktiotauluun tarpeen tallentaa tieto ainoastaan niistä aktiivisista transaktioista, jotka ovat suorittaneet vähintään yhden päivitysoperaation. Transaktioiden samanaikaisuuden hallintaa varten on transaktioilla tarpeen olla tunniste siinä vaiheessa, kun transaktio varaa ensimmäisen lukkonsa (joko lukua tai päivitystä varten). Kun sovellusohjelmointikielessä ei ole erityistä transaktionaloituslausetta (begin transaction), tehdäänkin transaktion aloituskirjaus vasta sitten, kun transaktio on suorittamassa ensimmäistä tietokantaoperaatiotaan (lukua tai päivitystä). 93
Avainvälimallin operaatioiden lokikirjaukset Fysiologisessa lokikäytännössä kirjattavat operaatiokohtaiset lokitietueet ovat avainvälimallimme tapauksessa seuraavat (n on lokikirjauksen saama LSN): (1) Transaktion T aloitusoperaatio B kirjataan n: T,B. (2) Transaktion T sitoutuminen tai peruutuksen päättyminen C kirjataan n: T,C. (3) Transaktion T keskeytyminen A kirjataan n: T,A. Transaktion T etenemisoperaation (I tai D) lokikirjaus sisältää operaation nimen ja argumentit sekä T :n Undo-Next-LSN-arvon n. (4) Transaktion T sivulle p tietuepaikkaan i toteutettu etenemisoperaatio I[x,v] kirjataan n: T,I, p,i,x,v,n. (5) Transaktion T sivulle p tietuepaikkaan i toteutettu etenemisoperaatio D[x,v] kirjataan n: T,D, p,i,x,v,n. 94
(6) Transaktion T peruutuspisteen asetus S[P] kirjataan n: T,S[P],n, missä n on T :n edellisen lokikirjauksen LSN. (7) Transaktion T osittaisperuutuksen aloitus A[P] kirjataan n: T,A[P]. (8) Transaktion T osittaisperuutuksen päättäminen C[P] kirjataan n: T,C[P]. Etenemisoperaatioiden lokikirjaukset 4 ja 5 ovat toisto- ja peruutuskelpoisia kirjauksia (redo-undo log record); niiden avulla operaatio voidaan sekä toistaa (fyysisesti) että perua (fyysisesti, tai jos se ei ole mahdollista, niin loogisesti). 95
Peruuntuvan transaktion peruutusvaiheessa tai etenevän transaktion osittaisperuutuksessa suoritetun käänteisoperaation lokikirjaus sisältää operaation nimen ja argumentit (tarvittavin osin) sekä T :n Undo-Next- LSN-arvon, so. T :n seuraavaksi peruutettavan operaation lokikirjauksen LSN:n n. (9) Transaktion T sivulle p tietuepaikkaan i toteutettu käänteisoperaatio I 1 [x,v] kirjataan n: T,I 1, p,i,n, kun T :n vastaavan etenemisoperaation I[x, v] lokikirjaus on T,I, p,i,x,v,n. Huomaa, ettei monikon lisäyksen peruutuksen eli monikon poiston toistoa varten ole tarpeen kirjata itse monikkoa. 96
(10) Transaktion T sivulle p tietuepaikkaan i toteutettu käänteisoperaatio D 1 [x,v] kirjataan n: T,D 1, p,i,x,v,n, kun T :n vastaavan etenemisoperaation D[x, v] lokikirjaus on T,D, p,i,x,v,n. Käänteisoperaatioiden lokikirjaukset ovat ainoastaan toistokelpoisia kirjauksia (redo-only log record); niiden avulla lokikirjauksen ilmaisema käänteisoperaatio voidaan toistaa (fyysisesti), mutta käänteisoperaatioita ei koskaan peruta. Käytetään myös nimitystä korvaava lokikirjaus (compensation log record, CLR). 97
Esim. sitoutunut transaktio T 1 : BR[x,u]R[y,v]D[z,w]I[z,w ]C tuottaa lokikirjaukset n 1 : T 1,B. n 2 : T 1,D, p,i,z,w,n 1. n 3 : T 1,I, p,i,z,w,n 2. n 4 : T 1,C. Tässä monikko (z, w) on poistettu sivulta p tietuepaikasta i ja monikko (z,w ) lisätty sivulle p paikkaan i. Lokijärjestysnumerot n 1,n 2,n 3,n 4 muodostavat nousevan jonon. Kun suorituksessa on muita samanaikaisia transaktioita, kirjautuu näiden tuottamia lokikirjauksia T 1 :n lokikirjausten väliin. 98
Peruuntunut transaktio T 2 : BR[x,u]R[y,v]D[z,w]I[z,w ]AI 1 [z,w ]D 1 [z,w]c tuottaa lokikirjaukset n 1 : T 2,B. n 2 : T 2,D, p 1,i 1,z,w,n 1. n 3 : T 2,I, p 2,i 2,z,w,n 2. n 4 : T 2,A. n 5 : T 2,I 1, p 3,i 3,n 2. n 6 : T 2,D 1, p 4,i 4,z,w,n 1. n 7 : T 2,C. Monikon (z,w ) lisäys sivulle p 2 paikkaan i 2 on peruttu poistamalla monikko sen nykyisestä sijaintipaikasta sivulta p 3 paikasta i 3. Monikon (z,w) poisto sivulta p 1 paikasta i 1 on peruttu lisäämällä monikko (z,w) sivulle p 4 paikkaan i 4. 99
Edellä olemme olettaneet, että looginen tietokantamme koostuu yhdestä ainoasta relaatiosta. Mikäli looginen tietokanta koostuu useammasta relaatiosta, on asianomaisen relaation tunniste r sijoitettava lokikirjaukseen: Etenemisoperaatioiden kirjaukset: (4) T,I, p,i,r(x,v),n. (5) T,D, p,i,r(x,v),n. Käänteisoperaatioiden kirjaukset: (9) T,I 1, p,i,n. (10) T,D 1, p,i,r(x,v),n. Kirjauksessa 10 on r tarpeellinen vain jos se kuuluu monikon sisäiseen esitykseen. Mikäli looginen tietokanta jakaantuu useampiin osatietokantoihin, joissa voi olla samannimisiä relaatioita, pitää lokikirjauksiin sijoittaa myös osatietokannan tunniste. 100
Rakennemuutosten lokikirjaukset Kuten edellä on jo todettu, fyysisen tietokannan rakennemuutos on oma atominen kokonaisuutensa, joka sitoutuu rakennemuutoksen aiheuttaneesta transaktiosta riippumattomasti. Jotta tietokannan levyversiosta puuttuvat rakennemuutokset olisi mahdollista toistaa häiriöstä elvyttäessä, on nekin kirjattava lokiin. Uuden sivun q varaus kasarakenteeseen voitaisiin kirjata lokiin esimerkiksi seuraavasti: n 1 : S,B. n 2 : S, allocate-page-for-heap, s, f, p,q. n 3 : S,C. Tässä S on järjestelmän generoima uusi transaktiotunniste. Kun rakennemuutos on kirjattu sitoutuneeksi, on se peruuttamaton, kuten mikä tahansa sitoutunut transaktio. 101
Tehokkuussyistä emme kuitenkaan vaadi rakennemuutoksilta aivan täyttä transaktion semantiikkaa. Transaktion täydellinen sitoutumiskäytäntö edellyttäisi lokin pakotusta levylle, mitä haluamme välttää. Kun rakennemuutoksen kaikki varsinaiset fyysisen tietokannan rakenteeseen vaikuttavat operaatiot voidaan kirjata yhteen lokitietueeseen, ei ole tarpeen tuottaa erityistä transaktiotunnistetta eikä myöskään kirjata erikseen rakennemuutoksen alkamista ja päättymistä. Rakennemuutoksesta, joka varaa uuden sivun kasarakenteeseen, kirjataan siis lokiin ainoastaan tietue allocate-page-for-heap, s, f, p,q. 102
Oletetaan, että transaktioiden T 1 = BI[x,v]AI 1 [x,v]c ja T 2 = BI[y,w]C operaatiot suoritetaan järjestyksessä B 1 I 1 [x,v]b 2 I 2 [y,w]c 2 A 1 I 1 1 [x,v]c 1 ja että operaatio I 1 [x,v] aiheuttaa uuden sivun varauksen. Lokiin kirjautuu: n 1 : T 1,B. n 2 : allocate-page-for-heap, s, f, p,q. n 3 : T 1,I,q,i,x,v,n 1. n 4 : T 2,B. n 5 : T 2,I,q, j,y,w,n 4. n 6 : T 2,C. n 7 : T 1,A. n 8 : T 1,I 1,q,i,n 1. n 9 : T 1,C. Kirjaus n 2 ei kuulu millekään transaktiolle. T 1 :n kirjauksen n 3 Undo- Next-LSN-arvo osoittaa n 2 :n yli T 1 :n edelliseen kirjaukseen n 1. 103
Tietosivun päivittäminen Oletetaan, että lokikirjaus... viedään lokiin kutsulla log(n,... ). Kutsu kirjoitussalpaa lokitiedoston viimeisen sivun, määrää LSNn n, vie lokikirjauksen lokitiedoston viimeiselle sivulle, vapauttaa sivun salpauksen ja palauttaa n:n. Tarkastellaan seuraavassa lyhyesti transaktion T etenemisoperaatioiden I[x,v] ja D[x,v] toteutusta. Tarkastelun ulkopuolelle jätetään vielä transaktioiden samanaikaisuuden hallinta (lukitus). Operaation I[x, v] toteutuksessa paikannetaan ja kirjoitussalvataan ensin tietokantarakenteesta se tietosivu p, jolle monikko (x, v) kuuluu lisätä. Esim. harvan B-puun tapauksessa on paikannettava se lehtisivu p, joka peittää avaimen x. 104
Oletetaan vielä, että sivun p paikantaminen sisältää myös ne rakennemuutokset (sivujen halkaisut), jotka on tehtävä riittävän tilan järjestämiseksi lisättävälle monikolle. Kun transaktiota T tuottava palvelinprosessin säie on paikantanut, naulinnut ja kirjoitussalvannut tietosivun p, monikko (x,v) lisätään sivulle p seuraavalla kutsulla: Insert-into-page(T, p, x, v) { lisää (x,v) sivulle p vapaaseen tietuepaikkaan i; log(n, T,I, p,i,x,v,n ), missä n = Undo-Next-LSN(T ); Undo-Next-LSN(T ) := n; Page-LSN(p) := n; }. Kutsun päätteeksi sivun p salpaus ja naulinta vapautetaan: ul(p). 105
Operaation D[x, v] toteutuksessa paikannetaan ja kirjoitussalvataan ensin tietokantarakenteesta se tietosivu p, joka sisältää avaimella x varustetun monikon. Oletetaan vielä, että sivun p paikantaminen sisältää myös ne rakennemuutokset, jotka on tehtävä, jottei sivu p jäisi monikon (x, v) poiston takia liian vajaaksi. Kun transaktiota T tuottava palvelinprosessin säie on paikantanut, naulinnut ja kirjoitussalvannut tietosivun p, monikko (x, v) poistetaan sivulta p seuraavalla kutsulla: Delete-from-page(T, p, x) { olkoon (x,v) sivun p tietuepaikassa i; poista (x,v) sivun p tietuepaikasta i; log(n, T,D, p,i,x,v,n ), missä n = Undo-Next-LSN(T ); Undo-Next-LSN(T ) := n; Page-LSN(p) := n; }. Kutsun päätteeksi sivun p salpaus ja naulinta vapautetaan: ul(p). 106
WAL-käytäntö Lokia säilytetään vakaassa muistissa (stable storage), so. mahdollisimman varmassa pysyvässä muistissa. Käytännössä vakaata muistia joudutaan approksimoimaan eri levyasemille sijoitetuilla kahdennetuilla levytiedostoilla. Lokikirjauksia pakataan puskurisivuille, joita tarvittaessa viedään levylle. Jotta loki osoittaisi mahdollisimman tarkasti transaktioiden ja tietokannan tilan, tulisi lokitiedoston sivu periaatteessa viedä puskurista levylle heti, kun siihen on lisätty uusi lokikirjaus. Tämä aiheuttaisi levyhaun jokaista päivitystä kohti, mikä on hyvin tehotonta. Todellisuudessa loki pakotetaan levylle vasta, kun transaktio sitoutuu tai päättää peruutuksensa tai kun puskurointikäytäntö sitä vaatii. Transaktion sitoutumiskäytäntöön (commit protocol), so. operaation C suoritukseen, sisältyy lokin vienti levylle (force-log-at-commit). 107
Aina kun transaktio päivittää (I, D, I 1 tai D 1 ) puskurissa olevaa tietokantasivua p, leimataan tästä päivityksestä tuotetun lokikirjauksen LSN sivun p otsikkotietueen Page-LSN-kenttään. Samoin leimataan rakennemuutoksen lokikirjauksen LSN kaikkien niiden sivujen Page-LSN-kenttään, joiden sisältöä rakennemuutos muuttaa. Esim. lokikirjauksen n 2 : allocate-page-for-heap, s, f, p,q LSN n 2 leimataan sivujen s, f, p ja q Page-LSN-kenttään. Kun sivu p on tarkoitus viedä puskurista levylle, on lokin hallitsimen ensin vietävä levylle kaikki lokitietueet, joiden LSN on p:n Page- LSN:ää pienempi tai yhtäsuuri. Tätä käytäntöä kutsutaan nimellä WAL-käytäntö (write-ahead logging protocol). 108
Häiriötilanteessa keskusmuistin sisältö katoaa, jolloin siis menetetään päivitettyjen tietokantasivujen puskuriversiot samoin kuin lokipuskurissa vielä olevat, levylle viemättömät lokikirjaukset. WAL-käytäntöä noudatettaessa levylle kertyy lokikirjauksia aina vähintään yhtä pitkälle kuin tietokantasivujen levyversioihin vastaavia päivityksiä. Häiriöstä elvyttäessä on lokin perusteella siis mahdollista toistaa ne päivitykset, jotka eivät olleet ehtineet levylle asti, ja peruuttaa levylle ehtineet aktiivisten transaktioiden päivitykset. Aktiiviseksi katsotaan transaktio, jolle ei löydy lokista C-tietuetta. 109
Puskurinhallintakäytännöt Palvelimen puskurinhallitsimen (buffer manager) tehtävänä on palvella tietokantaa käsittelevien prosessien naulinta- ja salpauspyyntöjä (rl, wl, ul) sekä yleisesti huolehtia siitä, että tietokantasivut ovat mahdollisimman hyvin saatavilla. Puskurissa on kerrallaan tilaa vain pienelle määrälle tietokantasivuja; puskurin kokoa voidaan varioida, mutta se on harvoin muutamaa tuhatta sivua suurempi. Sivujen naulinta puskuriin sekä lokitietueiden kirjoitussäännöt rajoittavat puskurinhallitsimen vapautta poistaa sivuja puskurista puskuritilan loputtua. 110
Sivua, joka on parhaillaan naulittuna jollekin prosessille tai säikeelle, ei puskurinhallitsimen ole lupa poistaa puskurista. WAL-käytännön mukaisesti päivitetyn tietokantasivun saa viedä puskurista levylle vasta, kun sivun päivitysten lokikirjaukset on viety levylle. Transaktion sitoutumiskäytäntö (samoin kuin peruutuksen päättämiskäytäntö) taas sisältää lokin pakotuksen levylle. Näiden lisäksi järjestelmä ei yleensä aseta puskurinhallinnalle muita rajoituksia. Joissakin järjestelmissä puskurinhallitsin saattaa soveltaa rajoitetumpaa käytäntöä. 111
Loogisen tietokannan tietoalkio (monikko tai relaatio) on likainen (dirty), jos sitä viimeksi päivittänyt transaktio on vielä aktiivinen, ja puhdas (clean), jos sitä viimeksi päivittänyt transaktio on sitoutunut tai peruuntunut. Päivitetty tietokantasivu on likainen, jos se sisältää likaisia tietoalkioita, ja puhdas muutoin. Puskurista levylle vietävää naulitsematonta sivua valitessaan puskurinhallitsin voi tehdä eron likaisten ja puhtaiden sivujen välillä tai sitten jättää sivun päivitystilan huomiotta. Jälkimmäisessä tapauksessa puskurinhallitsin soveltaa varastakäytäntöä (steal policy): sivu on lupa varastaa puskurista ja viedä levylle, vaikka sivun monikoita päivittäneistä transaktioista jotkin ovat vielä aktiivisia. 112
Toinen vaihtoehto on älä varasta -käytäntö (no-steal policy), jonka mukaan kaikki likaiset sivut pidetään puskurissa siihen asti, kun sivuja päivittäneet transaktiot ovat kaikki sitoutuneet tai peruuntuneet. Älä varasta -käytännöllä saavutetaan etua eräiden sellaisten elvytyskäytäntöjen yhteydessä, joissa häiriön vuoksi keskeytyneiden transaktioiden päivityksiä ei toisteta (vaan ne unohdetaan ). Tällä kurssilla esitettävän ARIES-elvytysalgoritmin tapauksessa älä varasta -käytännöstä ei sitä vastoin ole mitään etua (vaan pelkästään haittaa). Älä varasta -käytäntöä sovellettaessa puskurialtaan täytyy sitä paitsi olla niin iso, että sinne mahtuvat kaikkien aktiivisten transaktioiden päivittämät sivut samalla kertaa. Jo tästä syystä useimmissa järjestelmissä sovelletaankin varastakäytäntöä. 113
Entä milloin sitoutuvan transaktion päivittämät sivut pitäisi kirjoittaa levylle? On kaksi eri käytäntöä: Pakota-käytäntö (force policy). Transaktion pyytäessä sitoutumista tai päästyä peruutusvaiheensa loppuun (operaatio commit tai rollbackcompleted) puskurinhallitsin paikantaa kaikki transaktion päivittämät sivut, joita ei vielä ole viety levylle, ja vie ne levylle (WAL-käytäntöä noudattaen). Vasta tämän jälkeen transaktio sitoutuu tai päättää peruutuksensa, ts. transaktion päättyminen kirjataan lokiin ja loki pakotetaan levylle. Älä pakota -käytäntö (no-force policy). Sekä likaiset että puhtaat tietokantasivut saavat olla puskurissa niin kauan kuin sivujen viemää puskuritilaa ei tarvita muuhun käyttöön. 114
Pakota-käytäntö nopeuttaa häiriöstä elvytyksen toistovaihetta. Pakota-käytäntö hidastaa kuitenkin transaktion sitoutumista: päivitetyt sivut viedään levylle osana transaktion sitoutumiskäytäntöä. Vielä merkittävämpi haitta on, että sivu, jota useat transaktiot päivittävät peräjälkeen, tulee tarpeettomasti kirjoitetuksi levylle erikseen kunkin transaktion sitoutumisen yhteydessä. Älä pakota -käytännössä tällainen usein käytetty sivu ( hotspot - sivu) varmaankin pysyisi puskurissa transaktioiden välillä eikä sitä tarvitsisi kirjoittaa levylle kertaakaan. Useimmissa järjestelmissä sovelletaan älä pakota -käytäntöä. Tällä kurssilla esitettävissä menetelmissä oletetaan aina sovellettavan varasta ja älä pakota -käytäntöjä ( steal-and-no-force ), so. mahdollisimman vapaata puskurointikäytäntöä. 115
Levyhakujen vähentäminen Puskurinhallitsimen tulisi osaltaan yrittää minimoida tarvittavien levyhakujen määrää. Puskurin täyttyessä puskurista poistettava sivu tulisi valita järkevästi. Näennäismuistin (virtuaalimuistin) hallinnassa sovelletaan yleensä ns. LRU (least recently used) -strategiaa: kun kaikki kehykset ovat varattuja, viedään levylle se sivu, joka on pisimpään ollut käyttämättä (so. viittaamatta). LRU on riittävä strategia näennäismuistin hallintaan: kaikenlaisten ohjelmien käyttäytymistä on vaikea ennustaa. Tietokantasivujen hallintaan strategiaa voidaan parantaa. Tietokannan hallintajärjestelmä pystyy usein kyselyn muodosta ennustamaan, mitä sivuja tullaan tarvitsemaan kyselyn toteuttamisessa. Käyttöjärjestelmä sitä vastoin joutuu nojautumaan menneisyyteen tulevaisuuden ennustamisessa, kun taas tkhj:llä voi olla tietoa ainakin lähitulevaisuudesta. 116
Relaatioiden r(ab) ja s(bc) luonnollisen liitoksen r s laskenta, kun liitosattribuutti B ei ole kummankaan relaation avain, relaatiot ovat eri tiedostoissa ja hakemistoja ei ole (lukitusoperaatiot puuttuvat algoritmista): for (jokainen r:n sivu p) { rl(p); for (jokainen s:n sivu q) { rl(q); for (jokainen p:n r-monikko t ja jokainen q:n s-monikko u) if (t(b) = u(b)) tulosta liitosmonikko tu; ul(q) }; ul(p) }. 117
Kun r:n sivu p on käsitelty, sitä ei enää tarvita uudelleen. Sopiva puskurointistrategia r:n sivuille on: poista heti puskurista (toss immediate). Jokaista r:n sivua p kohti täytyy käsitellä kaikki s:n sivut q. Kun q on käsitelty, sitä tarvitaan uudelleen vasta kun kaikki muut s:n sivut on käsitelty. Sopiva puskurointistrategia s:n sivuille on MRU (most recently used), siis LRU-strategian vastakohta. Käsittelyvuorossa oleva r:n sivu naulitaan s:n käsittelyn ajaksi, minkä jälkeen siitä tehdään MRU-sivu. Siis MRU on optimaalinen strategia sekä r:n että s:n sivuille. 118