Transaktiopalvelimen rakenne, s. 43. Levyjaksot, sivut ja tiedostot, s. 46. Tietokantasivujen puskurointi, s. 53. Tietokannan tila, s. 57.

Transkriptio

1 Fyysinen tietokanta A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Fifth Edition. McGraw-Hill, 2006, sivut 24 26, luvun 1 (introduction) kohta 1.11 (database architecture); sivut , luvun 11 (storage and file structure) kohdat 11.5 (storage access), 11.6 (file organization), 11.7 (organization of records in files) ja 11.8 (data dictionary storage); sivut , luvun 17 (recovery system) kohta 17.6 (buffer management); sivut , luvun 20 (database-system architectures) kohta (transaction-server process structure). 41

2 Transaktiopalvelimen rakenne, s. 43. Levyjaksot, sivut ja tiedostot, s. 46. Tietokantasivujen puskurointi, s. 53. Tietokannan tila, s. 57. Tiedoston vapaan tilan hallinta, s. 61. Fyysisen tietokannan eheys, s. 65. Salpauskäytäntö, s. 67. Fyysisen tietokannan rakennemuutokset, s. 73. Uuden sivun varaus tietokantarakenteeseen, s

3 Transaktiopalvelimen rakenne Transaktiopalvelimella ylläpidetään kahta pysyvää tietokokoelmaa: (1) Tietokannan relaatiot, hakemistot ja tietohakemistorelaatiot sisältävät tietolevyt (data disk). (2) Tietokannan päivityksien lokikirjauksista koostuvat lokilevyt (log disk). Järjestelmän ollessa toiminnassa ylläpidetään mm. seuraavia katoavia rakenteita palvelimen eri prosessien yhteisessä keskusmuistissa (virtuaalimuistissa): (3) Puskuriallas (buffer pool) eli tietokantapuskuri (database buffer) tietokantasivujen käsittelyä varten. (4) Lokipuskuri (log buffer) lokitiedoston käsittelyä varten. (5) Lukkotaulu (lock table) transaktioiden samanaikaisuuden hallintaa varten. (6) Kyselysuunnitelmavälimuisti (query-plan cache), jossa säilytetään valmiiksi käännettyjä kyselysuunnitelmia. 43

4 Yhteisessä muistissa säilytettävään tietoon operoi useita prosesseja: (1) Jo aiemmin mainittuja palvelinprosesseja (server process) ja niiden säikeitä, jotka tuottavat sovellusprosessien lähettämien pyyntöjen perusteella transaktioita. (2) Tietokannankirjoitusprosessi (database-writer process), joka vie päivitettyjä tietokantasivuja puskurialtaasta takaisin levylle. (3) Lokinkirjoitusprosessi (log-writer process), joka vie lokikirjauksia lokipuskurista lokilevylle silloin, kun lokipuskuri täyttyy tai kun palvelinprosessi (transaktion sitoutumisen yhteydessä) pyytää lokin pakotusta levylle. (4) Tarkistuspisteprosessi (checkpoint process) ottaa aika-ajoin ns. tarkistuspisteen, jossa eräitä katoavia tietoja viedään levylle. (5) Prosessien valvontaprosessi (process-monitor process), joka valvoo järjestelmän muita prosesseja ja suorittaa romahtaneen prosessin vaatimat elvytystoimenpiteet, kuten keskeyttää ja peruuttaa suoritusvirheeseen päättyneen palvelinprosessin säikeen tuottaman transaktion. 44

5 (6) Lukkojenhallintaprosessi (lock-manager process), joka palvelee lukon varaus- ja vapautuspyyntöjä sekä huolehtii lukkiumien havaitsemisesta. Prosessien välisten viestien vähentämiseksi useissa järjestelmissä palvelinprosessit toteuttavat lukituksen päivittämällä lukkotaulua suoraan eikä lähettämällä pyyntöjä lukkojenhallintaprosessille. Lukkotaulu täytyy silloin suojata keskinäisen poissulkemisen mekanismilla (semaforilla) kuten muutkin usean prosessin yhteiskäytössä olevat muistirakenteet. 45

6 Levyjaksot, sivut ja tiedostot Fyysinen tietokanta (physical database) on levymuistiin sijoitettu kokoelma sivuja, jotka sisältävät tietueita. Sivu (page) on vakiokokoinen (joko 2, 4, 8, 16 tai 32 kilotavun) alue, joka on sijoitettu levymuistin yhteen jaksoon (tai useampaan peräkkäiseen jaksoon, mikäli sivu on jaksoa pitempi). Tietue (record) jakaantuu yhteen tai useampaan kenttään (field), joka voi sisältää atomisen arvon (luvun tai merkkijonon) tai osoittimen. Levyjakso eli -lohko (disk block) on yhdestä tai useammasta peräkkäisestä sektorista koostuva alue levypinnan uralla. Esim. jos jakson koko on 8 KB ja sektorin koko on 512 B, käsittää jakso 16 peräkkäistä sektoria. Levyllä yksittäinen sektori on pienin osoitettavissa oleva yksikkö. Sivun tuonti levyltä keskusmuistiin ja sivun vienti keskusmuistista levylle toteutetaan yhdellä levyoperaatiolla (yksi hakuvarren asetus ja sivuun kuuluvien peräkkäisten sektorien luku tai kirjoitus). 46

7 Looginen tietokanta toteutetaan fyysisen tietokannan avulla sijoittamalla tietokannan relaatioiden monikot sivuille. Monikoita sisältävää sivua kutsutaan tietosivuksi (data page). Tietosivujen lisäksi tarvitaan mm. tiedostorakenteesta riippuva joukko hakemisto- eli indeksisivuja (index page), joiden kautta tietosivuihin päästään tehokkaasti käsiksi. Tietokannan hallinnan tarpeisiin on vielä erinäisiä muita sivutyyppejä. Monikko toteutetaan tietosivulla yleensä yhtenä tietueena. Sivua pitempi monikko joudutaan jakamaan useaksi tietueeksi, jotka ketjutetaan toisiinsa. Sivulla on otsikkotietue, tietuealue ja tietuehakemisto. 47

8 Sivun alun otsikkotietue (header) sisältää ainakin seuraavat tiedot: (1) Sivun tyyppi, esim. relaatiotietosivu (relation data page, rivejä yhdestä relaatiosta), rypään tietosivu (cluster data page, rivejä useammasta relaatiosta), hakemistosivu (index page, relaation hakemistoon eli indeksiin kuuluva sivu), vapaata tilaa (free space, unallocated page), tietohakemistosivu (data-dictionary page), varauskuvaajasivu (storage-map page) jne. (2) Relaation, hakemiston, tms. sisäinen tunniste. (3) Sivun tietuehakemiston alkioiden lukumäärä. (4) Sivun sisäisen vapaan tilan hallitsemiseksi tarvittavaa tietoa: sivun tietuealueen pisimmän yhtenäisen vapaan alueen pituus ja sivun yhteenlaskettu vapaan tilan määrä. (5) Sivun viimeisimmän päivityksen lokikirjauksen järjestysnumero (page log-sequence number, Page-LSN). Puskuroidun sivun Page- LSN-kenttää päivitetään aina sivun päivityksen yhteydessä; kenttään sijoitetaan päivitystä kuvaavan lokikirjauksen LSN. 48

9 Sivun tietuealue sisältää sivun varsinaisen tiedon, tietosivun tapauksessa sivulle sijoitetut loogisen tietokannan monikot. Tietuealuetta täytetään sivun alusta lukien (otsikkotietueen jäljestä). Sivun tietuehakemisto on sivun lopussa sijaitseva taulukko m, jonka alkio m[i] sisältää tietuealueen i:nnen tietueen tavusiirtymän sivun alusta lukien. Tietuehakemisto kasvaa sivun lopusta alkuun päin. Esim. sivulla 924 paikassa m[3] oleva monikko: (924, 3) monikko 49

10 Jokaisella sivulla on yksikäsitteinen sivutunniste (page identifier, page-id, PID), joka yksilöi sivun fyysisessä tietokannassa: sivutunniste sisältää tiedoston numeron ja sivun järjestysnumeron tiedostossa. Hajautetussa tietokannassa täydellinen sivutunniste sisältää lisäksi järjestelmän asianomaisen pisteen (site, node) tunnisteen. Sivun tunnisteesta voidaan tiedostokuvaajan avulla määrätä sivun sisältävän levyjakson osoite. Tiedostokuvaaja (file descriptor) osoittaa tiedostolle varattujen alueiden sijainnin levyllä. Sivun p tietuealueen i:nnen tietueen tietuetunniste (record identifier, redord-id, RID) on pari (p,i), missä p on sivutunniste. Tietosivun p tietueeseen i sijoitetun monikon tietuetunnistetta (p,i) kutsutaan myös monikkotunnisteeksi (tuple identifier, tuple-id, TID). 50

11 Monikkotunnisteeseen perustuva haku on nopein tapa hakea monikko esille: 1. Eristä monikkotunnisteesta (p,i) sivutunniste p ja naulitse sivu p puskuriin; olkoon p:n puskurikehyksen osoite b. 2. Hae monikko osoitteesta b + m[i]. Tietuehakemiston m kautta käyvän epäsuoran osoituksen ansiosta tietueen tunniste voidaan säilyttää samana, vaikka tietuetta siirreltäisiin sivun sisällä. 51

12 Tietokannan sivut ryhmitellään yleensä tiedostoihin (file) tai segmentteihin (segment). Ryhmittely perustuu usein tietueiden tyyppiin. Relaatiotietokannan yksittäinen relaatio sijoitetaan usein omaan tiedostoonsa. Joissakin järjestelmissä kahden tai useamman toisiinsa liittyvän relaation monikot voidaan kaikki sijoittaa samaan tiedostoon, ns. ryvästiedostoon (cluster file), niin että samalla liitosattribuutin arvolla varustetut monikot ovat fyysisesti lähekkäin. Hyvin suuri relaatio on pakko osittaa useampaan tiedostoon. Osittaminen usein myös helpottaa tietokannan hallintatoimenpiteitä sekä lisää käsittelyn tehokkuutta (rinnakkaisuus). Tiedosto tai segmentti koostuu yhdestä tai useammasta fyysisesti peräkkäisten sivujen levyalueesta (extent). Tiedostolle varataan tilaa tarvittaessa alue (tai muutama alue) kerrallaan. Useissa järjestelmissä loogisen tietokannan tietokokoelmat ryhmitellään ylimmällä tasolla tauluavaruuksiksi (tablespace) kutsutuiksi loogisiksi tallennusyksiköiksi. Tauluavaruus jakaantuu tiedostoihin eli segmentteihin. 52

13 Tietokantasivujen puskurointi Tietokantapalvelimen ollessa käynnissä on keskusmuistista varattuna tietokantasivujen käsittelyä varten yksi tai useampi puskuri. Puskuri (buffer) eli puskuriallas (buffer pool) on sivun kokoisista puskurikehyksistä (buffer frame) koostuva taulukko B[1, 2,..., N]. Mikäli tietokannassa esiintyy erikokoisia sivuja, on jokaista eri sivukokoa varten oltava eri puskuri. Jotta tietokannan sivun p sisältöä voitaisiin lukea tai kirjoittaa, on sivu tuotava levyltä johonkin vapaaseen puskurikehykseen B[i]. Puskurin koko N on yleensä kertaluokkaa pienempi kuin tietokannan sivujen lukumäärä, joten yleensä vain pieni osa tietokannan sivuista mahtuu kerrallaan puskuriin. Puskurin kokoa voidaan säädellä, mutta se voi harvoin olla enempää kuin joitakin tuhansia sivuja, kun taas tietokanta sisältää miljoonia, iso tietokanta jopa miljardeja sivuja. 53

14 Sivun p käsittelyn ajaksi tietokantaa käsittelevä prosessi tai säie naulitsee (fix, pin) sivun puskuriin. Mikäli sivu p ei ole ennestään puskurissa, naulintakutsu fix(p) tuo p:n ensin levyltä puskuriin johonkin vapaaseen puskurikehykseen. Naulittua sivua ei puskurinhallitsimen ole lupa poistaa puskurista eikä siirtää toiseen kehykseen. Kutsuneelle prosessille välitetty sivun puskurikehyksen osoite säilyy siis voimassa naulinnan ajan. Sivun käsittelyn päätyttyä prosessi tai säie vapauttaa naulinnan (unfix, unpin). Sivu voidaan poistaa puskurista vasta, kun se ei ole enää naulittuna millekään prosessille. Sivuja poistetaan puskurista yleensä vasta silloin, kun puskuri on täynnä ja levyltä tuotavalle sivulle p täytyy (fix(p)-kutsussa) osoittaa puskurikehys. Tällöin puskurista poistetaan LRU-periaatteen mukaisesti sivu q, joka on pisimpään ollut käyttämättä (so. lukematta tai päivittämättä); mikäli sivua q on päivitetty, se on ensin vietävä levylle. 54

15 SQL-kyselyn toteutus sisältää sarjan sivujen fix- ja unfix-kutsupareja, jotka mahdollistavat operoinnin kyselyn viittaamiin sivuihin. Esimerkiksi SQL-kysely select sum(salary) from employee laskentaan sisältyy relaation employee tietosivujen läpikäynti niiden fyysisessä tallennusjärjestyksessä; kunkin tietosivun p kohdalla suoritetaan mm. seuraavat toimenpiteet: fix(p); hae p:n puskurikehyksestä kaikkien employee-monikoiden salaryattribuutin arvot ja lisää ne summaan; unfix(p). Puskuroidun sivun puskurinohjauslohko (buffer control block) on puskurinhallitsimen ylläpitämä pieni keskusmuistirakenne, joka sisältää mm. sivun tunnisteen, sivun sijainnin puskurissa (kehyksen osoitteen), naulintalaskurin, päivitysbitin (sivu päivitetty/päivittämätön), viimeisimpään päivitykseen liittyneen lokikirjauksen LSN:n sekä osoittimen kehykseen viittauksia valvovaan semaforiin. 55

16 fix(p)-kutsun suoritus (yksinkertaistettuna) sisältää seuraavat vaiheet: 1. Puskurinhallitsin etsii hajautustaulusta sivun p tunnistetta. Jos löytyy, mennään askeleeseen Etsitään puskurista kehys B[i], johon ei ole osoitettu sivua. Jos vapaata kehystä ei ole, poistetaan puskurista jokin naulitsematon sivu q. Jos q:ta on päivitetty (ts. q:n tuoretta sisältöä ei ole levyllä), viedään q ensin levylle q:n sivutunnisteen osoittamaan levyosoitteeseen. 3. Määrätään sivun p tunnisteesta levyjakson osoite. 4. Tuodaan sivu p levyltä, sijoitetaan se kehykseen B[i] ja tehdään p:lle puskurinohjauslohko, jossa päivitysbitti on nolla ja naulintalaskuri on nolla. 5. Lisätään p:n puskurinohjauslohkon naulintalaskuria yhdellä ja palautetaan kehyksen osoite kutsuneelle prosessille. Entä jos askeleessa 2 kaikki kehykset ovat varattuja ja naulittuja? 56

17 Tietokannan tila Sivun p levyversio (disk version) on levyllä p:n levyosoitteessa olevan sivun sisältö. Fyysisen tietokannan levyversio on sen sivujen levyversioiden joukko. Loogisen tietokannan levyversio on vastaavan fyysisen tietokannan levyversion tietosivujen sisältämien monikoiden joukko. Puskuroidun sivun p puskuriversio (buffer version) on puskurissa oleva p:n sisältö. Sivun p nykyversio (current version) on p:n puskuriversion sisältö, jos p on puskuroituna, ja p:n levyversion sisältö muutoin. Fyysisen tietokannan tila (state) eli nykyversio tietyllä hetkellä on sen sivujen nykyversioiden sisältö kyseisellä hetkellä. Loogisen tietokannan tila eli nykyversio tietyllä hetkellä on sen relaatioiden sisältämien monikoiden joukko kyseisellä hetkellä, ts. vastaavan fyysisen tietokannan tietosivujen nykyversioiden sisältämien monikoiden joukko. 57

18 Päivitetyn sivun puskuriversio eroaa sivun levyversiosta siihen asti, kun sivu viedään puskurista levylle. Levylleviennissä sivun levyversion päälle kirjoittuu sivun puskuriversio. Tehokkuussyistä päivitettyä sivua ei viedä levylle välittömästi päivitysoperaation suorituksen jälkeen, eikä edes sivua päivittäneen transaktion sitouduttua. Usein käytettyä sivua pyritään pitämään puskurissa mahdollisimman pitkään (LRU-periaate). Sivun puskuriversioon voi näin ollen kertyä useita päivityksiä, ja sivun levyversio voi jäädä paljon jälkeen nykyversiosta. Esimerkiksi tuhat peräkkäistä transaktiota päivittää kukin vuorollaan jotakin tietosivulla p olevaa monikkoa ja sitoutuu. Sivua p ei viedä välillä kertaakaan levylle, joten sen levyversio on ainakin tuhat päivitystä jäljessä nykyversiosta. 58

19 Miten käy, jos järjestelmä nyt romahtaa? Keskusmuistin sisältö, mukaan lukien puskurit, menetetään. Sitoutuneiden transaktioiden tekemien päivitysten lokikirjaukset on kuitenkin sitoutumisen yhteydessä viety lokilevylle. Tietokannan elvytyksessä (restart recovery) tietokannan romahdusta edeltävä tila rekonstruoidaan lokikirjausten avulla tietokannan levyversiosta: lokikirjausten esittämät päivitykset suoritetaan levyltä puskuriin tuoduille sivuille. 59

20 Elvytyksen nopeuttamiseksi päivitettyjä sivuja viedään levylle aika ajoin (tyypillisesti 5 10 minuutin välein) otettavan tarkistuspisteen (checkpoint) yhteydessä. Juuri levylle viennin jälkeen sivun levyversio on samansisältöinen kuin sivun nykyversio (eli puskuriversio). Täydellisessä tarkistuspisteessä viedään levylle kaikki päivitetyt sivut puskurista. Täydellisen tarkistuspisteen ottamisen jälkeen tietokannan sivujen levyversiot ovat samansisältöisiä kuin tietokannan tilassa (mikäli tarkistuspisteen ottamisen aikana tietokannan päivitys on estetty). Täydellisen tarkistuspisteen ottaminen yleensä hidastaa transaktionkäsittelyä huomattavasti. Täydellistä tarkistuspistettä kevyempi menettely tehostaa elvytystä on epäsuora tarkistuspiste (indirect checkpoint) eli sumea tarkistuspiste (fuzzy checkpoint), jossa vain osa päivitetyistä sivuista viedään levylle. 60

21 Tiedoston vapaan tilan hallinta Edellä esitetty sivun sisäinen tietorakenne sisältää sivun sisäisen vapaan tilan hallinnan. Seuraavassa tarkastellaan, miten hallitaan koko tiedoston vapaata tilaa. Mille sivulle sijoitetaan relaatioon r lisättävä uusi monikko t? Joissakin tietokantarakenteissa, kuten ns. harvassa B-puussa, jonka lehtisivut sisältävät perustietueita, lisättävän monikon t sijoitussivu p määräytyy suoraan indeksointiattribuutin arvon mukaan. Mikäli t ei sovi indeksointiattribuutin arvon peittävälle sivulle p, sivu halkaistaan, so. sivun p monikot jaetaan p:n ja sille varattavan uuden tyhjän sisarussivun p kesken. 61

22 B-puun lehtisivun tultua monikoiden poistojen seurauksena liian vajaaksi sivun monikot siirretään sisarussivulle ja tyhjentynyt sivu vapautetaan. Ns. tiheitä hakemistorakenteita käytettäessä perustietueet pidetään järjestämättömässä tiedostossa eli kasassa, ja hakemiston lehtisivuilla on tietueita, jotka sisältävät perustietueen indeksointiattribuutin arvon ja perustietueen tunnisteen. Edellisessä tapauksessa on monikon t lisäämistä varten löydettävä täysin tyhjä sivu p, joka linkitetään B-puun osaksi. Jälkimmäisessä tapauksessa on löydettävä sellainen kasan sivu p, jossa on tilaa monikolle t. 62

23 B-puun sivujen varausta ja vapauttamista varten voidaan pitää yllä tyhjien sivujen ketjua, johon B-puusta irrotetut, tyhjentyneet hakemisto- tai tietosivut sijoitetaan. Varattava uusi sivu otetaan tyhjien sivujen ketjusta, mikäli ketju on epätyhjä; muutoin B-puulle varattua tiedostoaluetta kasvatetaan varaamalla uusi yhtenäinen alue levyltä ja ottamalla sieltä käyttöön peräkkäisjärjestyksessä ensimmäinen sivu. Toinen tapa on ylläpitää varauskuvaajassa (space map) tietoa siitä, mikä tiedoston sivuista on vapaa ja mikä varattu. Tiedoston ensimmäisen sivun (sivun 0) täyttää e-alkioinen bittitaulukko, joka sisältää tiedoston e:n seuraavan sivun, so. sivujen 1,2,...,e muodostaman alueen varauskuvaajan. Varauskuvaajan i:nnen alkion arvo 1 osoittaa, että sivu i on varattu, ja arvo 0, että sivu i on vapaa. 63

24 Neljän kilotavun sivulle mahtuu noin alkioinen varauskuvaaja. Yli sivuisen tiedoston vapaan tilan hallitsemiseksi tarvitaan useampia varauskuvaajia: sivun e+1 täyttää varauskuvaaja, joka osoittaa seuraavien e:n sivun vapaan tilan, jne. Tiedostolle voidaan varata sivuja rypäissä, joissa on e sivua (tai sitä vähemmän). 64

25 Fyysisen tietokannan eheys Fyysinen tietokanta (tai oikeammin sen tila) on eheä, jos sen kaikkien sivujen sisäinen tietorakenne on eheä ja sivujen joukko muodostaa asianomaisen tiedostorakenteen mukaisen verkkorakenteen. Esim. tiedoston B-puurakenne määrittää tarkoin, millaisen verkkorakenteen sivut muodostavat, millaista tietoa rakenteen milläkin sivulla pitää olla, millaisten tasapainoehtojen tulee olla täytetty ja millaisella algoritmilla B-puun lehtisivuille tallennetut tietueet löydetään. Eheysvaatimukset koskevat ainoastaan tietokannan nykyversiota (kun rakennemuutoksia ei ole käynnissä). Tietokannan levyversion ei tarvitse olla eheä. 65

26 Mikäli jokainen yksittäisen sivun levylle vienti tai levyltä tuonti sujuu aina virheettömästi, fyysisen tietokannan jokaisen sivun levyversio on kyllä sisäiseltä tietorakenteeltaan eheä. Sivujen levyversioiden joukko ei kuitenkaan välttämättä muodosta eheätä tietokantarakennetta. Esim. kun B-puun rakenne muuttuu täyttynyttä sivua p halkaistaessa, osa rakennemuutokseen osallistuneista sivuista (esim. p) on voitu viedä levylle, mutta osa sivuista (esim. p:n isä ja uusi sisarus) on viemättä levylle. Samoin loogisen tietokannan levyversio voi olla jatkuvasti epäeheä. Kun minkään aktiivisen transaktion tietokantaoperaatiota ei ole parhaillaan suoritettavana, on fyysisen tietokannan nykyversio eheä. Kun yhtään transaktiota ei ole aktiivisena, on myös loogisen tietokannan nykyversio eheä, edellyttäen, että kaikki transaktiot ovat oikeellisia ja ne on ajettu täysin eristyneesti. 66

27 Salpauskäytäntö Tietokannan tulee säilyä eheänä samanaikaisten prosessien siihen kohdistamissa operaatioissa. Fyysisen tietokannan eheyden säilyttämiseksi tietokantasivua käsittelevän prosessin on aina asianmukaisesti salvattava (latch) naulitsemansa sivu sen käsittelyn ajaksi. Lukusalpa (read latch) oikeuttaa prosessin lukemaan sivua ja estää kaikkia prosesseja samanaikaisesti päivittämästä sivua. Usealla prosessilla voi olla sivuun yhtä aikaa lukusalpa. Kirjoitussalpa (write latch) oikeuttaa prosessin sekä lukemaan että päivittämään sivua ja estää muita prosesseja samanaikaisesti lukemasta ja päivittämästä sivua. Salvan haltijan on vapautettava (unlatch) salpa sivun käytön jälkeen. 67

28 Salpa toteutetaan puskuroituun sivuun liittyvän semaforin avulla. Järjestelmä tuottaa automaattisesti jokaisen SQL-kyselyn aiheuttaman sivun p viittauksen edelle kutsun rl(p) fix(p) & read-latch(p), mikäli p:tä ainoastaan luetaan tällä naulintakerralla, ja kutsun wl(p) fix(p) & write-latch(p), mikäli p:tä päivitetään tällä naulintakerralla. Salpaus ja naulinta vapautetaan tuottamalla kutsu ul(p) unlatch(p) & unfix(p). 68

29 Kun prosessi pyytää lukusalpaa sivuun, joka parhaillaan on kirjoitussalvattuna toiselle prosessille, tai kirjoitussalpaa sivuun, joka on parhaillaan luku- tai kirjoitussalvattuna toiselle prosessille, salpaa pyytänyt prosessi pannaan odottamaan, kunnes toiset prosessit ovat vapauttaneet salpansa. Periaatteena on, ettei mikään prosessi saa pitää salpaa kovin pitkää aikaa, ja ettei prosessilla saa olla kuin pieni vakiomäärä salpoja samanaikaisesti. Salpojen odotuksista ei näet ylläpidetä mitään odotusverkkoa mahdollisten lukkiumien havaitsemiseksi, joten prosessien salpauskäytännön tulee olla lukkiumat estävä. 69

30 Useimmiten prosessilla on kerrallaan hallussaan vain yksi salpa suojaamassa tietokantaoperaatiota. Kun prosessi haluaa lukea tietosivulla p sijaitsevan monikon, prosessi suorittaa kutsun rl(p), kopioi monikon sivun p puskurikehyksestä ja suorittaa sitten kutsun ul(p). Kun prosessi haluaa päivittää tietosivulla p sijaitsevaa monikkoa, prosessi suorittaa kutsun wl(p), päivittää monikkoa sivun p puskurikehyksessä, tuottaa päivityksestä lokikirjauksen, leimaa sen LSN:n sivun p Page-LSN-kenttään ja suorittaa sitten kutsun ul(p). 70

31 Ketjutettujen tietokantarakenteiden läpikäynnissä prosessin on tarpeen pitää kaksi sivua yhtä aikaa salvattuina. Oletetaan, että sivut p 1,..., p n muodostavat yksisuuntaisen ketjun niin, että sivun p i otsikkotietueessa on aina sivun p i+1 tunniste, 1 i < n, ja sivun p n otsikkotietueessa on ketjun päättävä tyhjä linkki. Prosessilla on hallussaan sivun p 1 tunniste ja se haluaa lukea sivut ketjun mukaisessa järjestyksessä. Jotta prosessi voisi varmistua siitä, että sivulta p i sivulle p i+1 johtava linkki todella pysyy voimassa linkin käytön ajan, on salpauskäytännön oltava seuraava: rl(p 1 ); lue sivua p 1 ja ota p 1 :stä seuraavan sivun tunniste p 2 ; rl(p 2 ); ul(p 1 ); lue sivua p 2 ja ota p 2 :stä seuraavan sivun tunniste p 3 ; 71

32 rl(p 3 ); ul(p 2 ); lue sivua p 3 ja ota p 3 :sta seuraavan sivun tunniste p 4 ;... rl(p n ); ul(p n 1 ); lue sivua p n ja ota p n :stä seuraavan sivun tunniste (tyhjä); ul(p n ). Tätä salpauskäytäntöä kutsutaan konttauskäytännöksi (latchcoupling). Konttauskäytäntöä sovelletaan mm. haettaessa tietuetta B-puusta. Tietueen hakupolulla B-puun juurisivulta tietueen sisältävälle lehtisivulle pidetään aina isäsivua salvattuna niin kauan kuin on saatu lapsisivu salvatuksi. 72

33 Fyysisen tietokannan rakennemuutokset Lisättäessä tietoa tietokantaan joudutaan toisinaan varaamaan uusia sivuja ja kytkemään ne osaksi tietokantarakennetta. B-puun täyttyneen sivun halkaisu sisältää uuden sivun varauksen ja sivun linkittämisen osaksi B-puun rakennetta. Tiedon poisto voi vastaavasti supistaa tietokantarakennetta, ja tyhjentyneitä sivuja irrotetaan rakenteesta. Kutsumme näitä fyysisen tietokannan rakennetta muuttavia operaatioita rakennemuutoksiksi (structure modification). Koko rakenteen täytyy säilyä eheänä, vaikka samanaikaisesti on suorituksessa useita transaktioita ja niiden aiheuttamia rakennemuutoksia. Rakennemuutokselta täytyy vaatia atomisuus. 73

34 Normaalin transaktionkäsittelyn aikana fyysisen tietokannan eheys taataan pitämällä fyysisen tietokantarakenteen rakennemuutokseen osallistuvat sivut kirjoitussalvattuina rakennemuutoksen ajan. Esim. kun B-puun sivun p täyttynyt lapsisivu q halkaistaan varaamalla uusi tyhjä sivu q, niin kaikki nämä kolme sivua pidetään kirjoitussalvattuina halkaisun ajan, so. kunnes sivu q on saatu linkitetyksi sivun p lapseksi ja sivulta q on saatu siirretyksi puolet tietueista sivulle q. Häiriötilanteessa fyysisen tietokannan levyversio voi olla enemmän tai vähemmän epäajantasainen sekä tietosivujen päivitysten että rakennemuutosten osalta. Tietokannan levyversiossa ei välttämättä näy rakennemuutosta, joka on ehditty suorittaa valmiiksi ennen häiriötä, tai rakennemuutos näkyy vain osittain, so. osasta rakennemuutokseen osallistuvia sivuja levylle on ehtinyt sivun uusi versio ja osasta jäljellä on vanha versio. 74

35 Uuden sivun varaus tietokantarakenteeseen Oletetaan, että looginen tietokanta (tai sen relaatio) toteutetaan kasana (heap), so. järjestämättömänä peräkkäistiedostona, jolle varataan uusia sivuja sitä mukaa kuin tietokantaan lisätään uusia monikoita. Kasaan kuuluvat sivut linkitetään niin, että sivun otsikkotietueessa on kasan seuraavan sivun tunniste. Kasan ensimmäisen sivun f otsikkotietueessa on myös kasan viimeisen sivun tunniste. Oletetaan, että transaktion T 1 operaatio I[x,v] saa aikaan uuden sivun q varauksen ja linkittämisen kasan loppuun, sen viimeisen sivun p seuraajaksi. Jotta rakenne säilyisi eheänä normaalin transaktionkäsittelyn kuluessa, täytyy varauskuvaajan sisältävä sivu s, kasan viimeinen sivu p, kasaan linkitettävä sivu q ja kasan ensimmäinen sivu f pitää kirjoitussalvattuina koko varausoperaation ajan. Sivu q, jolle monikko (x, v) lisätään, pidetään kirjoitussalvattuna, kunnes operaatio I[x,v] on loppuun suoritettu. 75

36 Oletetaan, että seuraavaksi toinen transaktio T 2 suorittaa operaation I[y,w], missä y > x. Kasarakenteessa tämäkin lisäysoperaatio suoritetaan sivulle q. Kun edellisen lisäyksen tehnyt transaktio T 1 on vapauttanut kirjoitussalpansa, pääsee T 2 kirjoitussalpaamaan sivun q ja lisäämään monikon (y,w) sinne. Sitten T 2 sitoutuu. T 1 on vielä aktiivinen ja haluaa nyt keskeytyä. T 1 :n peruuntumisvaiheessa suoritetaan käänteisoperaatio I 1 [x,v], joka poistaa monikon (x,v) sivulta q. Sitä vastoin ei sovi peruuttaa sivun q varausta. T 2 on näet ehtinyt jo tehdä oman päivityksensä sivulle q ja sitoutuakin. Siis rakennemuutoksen on annettava sitoutua siitä riippumatta, miten käy sen transaktion, joka rakennemuutoksen aiheutti. 76