Sivupalvelin- ja yhteislevyjärjestelmät C. Mohan & I. Narang 1994: ARIES/CSA: a method for database recovery in client-server architectures. Proc. of the 1994 ACM SIG- MOD Internat. Conf. on Management of Data, 55 66. C. Mohan & I. Narang: Recovery and coherency-control protocols for fast intersystem page transfer and fine-granularity locking in a shared disks transaction environment. VLDB 1991, Proc. of the 17th Internat. Conf. on Very Large Data Bases, 1991, 193 207. A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Sixth Edition. McGraw-Hill, 2010; sivut 775 777 ja 783, luvun 17 (database-system architectures) kohdat 17.2.2 (data servers) ja 17.3.3.2 (shared disk). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Fifth Edition. McGraw-Hill, 2006; sivut 789 790 ja 796, luvun 20 (database-system architectures) kohdat 20.2.2 (data servers) ja 20.3.3.2 (shared disk). 225
Tietopalvelin, s. 227. Sivupalvelinjärjestelmän rakenne, s. 232. Tiedon puskurointi asiakkailla, s. 237. Sivupalvelinjärjestelmän tila, s. 240. Päivitysten levittämiskäytännöt, s. 242. Puskurieheys ja takaisinkutsut, s. 247. Lokin hallinta, s. 251. Asiakkaan häiriöistä elvytys, s. 258. Palvelimen häiriöistä elvytys, s. 266. Lukkojen hallinta, s. 274. Yhteislevyjärjestelmä, s. 277. 226
Tietopalvelin Tavanomainen tietokantapalvelin on ns. kyselypalvelin (query server) eli funktiopalvelin (function server) eli transaktiopalvelin (transaction server), joka palvelee asiakkailta (sovellusprosesseilta) tulevia SQL-operaatiopyyntöjä. Sovelluksen SQL-operaatiot suoritetaan palvelimen puskuriin noudettuihin tietokantasivuihin. Kyselypalvelimen toimintaperiaatetta kutsutaan kyselynkuljetukseksi (query shipping) eli funktionkuljetukseksi (function shipping) eli transaktionkuljetukseksi (transaction shipping): siinä SQL-operaatio (kysely, funktio, transaktio) kuljetetaan sovelluksesta palvelimeen suoritettavaksi siellä (tiedon luona). Tietopalvelin (data server) taas on tietokantapalvelin, joka palvelee asiakkailta tulevia tietokannan yksittäisten (loogisten tai fyysisten) tietoalkioiden noutopyyntöjä. Tietopalvelimen toimintaperiaatetta kutsutaan tiedonkuljetukseksi (data shipping): tieto kuljetetaan palvelimelta asiakkaalle operoitavaksi siellä (ja asiakkaan päivittämä tieto palautetaan palvelimelle). Asiakas puskuroi tietoalkioita omassa asiakaspuskurissaan (client buffer, client cache) ja suorittaa niihin SQL-operaatioita. 227
Asiakkaan pyyntöjen kohteena olevien tietoalkioiden rakenteen mukaan tietopalvelin voidaan luokitella oliopalvelimeksi, sivupalvelimeksi tai tiedostopalvelimeksi. Oliopalvelin (object server) palvelee loogisen tietokannan tietoalkioihin kuten relaatiotietokannan monikoihin tai oliotietokannan olioihin kohdistuvia noutopyyntöjä: Nouda tietokannasta oliotunnisteella x varustettu olio asiakaspuskuriin. Sivupalvelin (page server) palvelee fyysisen tietokannan sivuihin kohdistuvia noutopyyntöjä: Nouda tietokannasta sivutunnisteella p varustettu sivu asiakaspuskuriin. Tiedostopalvelin (file server) palvelee fyysisen tietokannan tiedostoihin (tai levyalueisiin) kohdistuvia noutopyyntöjä: Nouda tietokannasta tiedostotunnisteella f varustettu tiedosto asiakaspuskuriin. 228
Tietopalvelimessa tietoalkioiden varsinainen käsittely tapahtuu asiakkailla. Itse asiassa kyselynkäsittely (SQL-kyselyn jäsennys, optimointi ja suoritus) tapahtuu kokonaan asiakkailla. Miten muuten asiakas osaisi pyytää palvelimelta jotain tiettyä oliota, sivua tai tiedostoa? Jokainen transaktio käynnistetään jollakin asiakkaalla ja suoritetaan alusta loppuun samalla asiakkaalla. Eri asiakkaiden transaktiot operoivat puskureittensa välityksellä palvelimella sijaitsevaan yhteiseen tietokantaan. Myös pääosa transaktioiden hallinnasta tapahtuu asiakkailla: asiakas aloittaa transaktion (tuottaa uuden transaktiotunnisteen), tuottaa transaktion lokikirjaukset sekä päättää (sitouttaa tai keskeyttää) transaktion. 229
Esimerkiksi asiakkaan c sovellusohjelman osasta begin transaction(); exec sql update r set V = V + 1; commit() syntyvän transaktion suoritus sivupalvelimessa sisältää seuraavaa: 1. Asiakas c tuottaa uuden transaktiotunnisteen T sekä T :n aloituskirjauksen. 2. Asiakas c pyytää palvelimelta puskuriinsa tietohakemiston sivuja, kunnes löytää relaatiota r koskevat tiedot. 3. Asiakkaan c kyselynoptimoija määrää update-operaation laskentastrategiaksi relaation r tietosivujen p 1,..., p n selauksen. 4. Asiakas c pyytää palvelimelta yksitellen puskuriinsa jokaisen tietosivun p i, päivittää sen monikoiden V -attribuutin arvon ja tuottaa päivityksistä lokikirjaukset. 5. Lopuksi asiakas c kirjaa T :n sitoutuneeksi ja pyytää palvelinta viemään lokikirjaukset levylle. Asiakaspuskurista päivitetyt sivut toimitetaan aikanaan palvelimen puskuriin. 230
Transaktiopalvelimessa lähes kaikki tietokannan hallintajärjestelmän funktionaliteetista on palvelimessa, kun taas tietopalvelimessa suurempi osa järjestelmän funktionaliteetista sisältyy asiakkaalla toimivaan paikalliseen hallintajärjestelmään. Sivupalvelimessa ja erityisesti tiedostopalvelimessa tietokantapalvelimen funktionaliteetti voi olla riisuttu äärimmilleen: Tietokanta on sivupalvelimen kannalta vain joukko sivuja, ja tiedostopalvelimen kannalta vain joukko tiedostoja, joiden yhteiskäytöstä ja pysyvyydestä palvelin huolehtii (tietokanta, loki, lukot). Asiakkaalla toimiva paikallinen hallintajärjestelmä tuntee sivuilla sijaitsevat oliot, oliokokoelmien hakemistorakenteet jne. Työasemaympäristössä toimivat, suunnittelusovelluksiin (CAD, CAM) tarkoitetut oliotietokannan hallintajärjestelmät ovat usein tietopalvelinjärjestelmiä. Tietopalvelinjärjestelmässä työasemien resursseja voidaan hyödyntää paremmin kuin transaktiopalvelinjärjestelmässä. Joissakin oliotietokannan hallintajärjestelmissä nämä kaksi periaatetta (tiedonkuljetus ja transaktionkuljetus) on yhdistetty: metodeja voidaan suorittaa sekä asiakkaalla että palvelimessa. 231
Sivupalvelinjärjestelmän rakenne Tarkastellaan sivupalvelinjärjestelmää, jossa tietokantapalvelimeen s on verkon välityksellä kytketty n asiakastyöasemaa c 1,...,c n. Palvelimeen s on kytketty levyasema tai -asemat, joilla tietokannan levyversio sijaitsee, sekä levyasema tai -asemat, joilla tietokannan lokia säilytetään. Asiakkailla c i ei ole tietokannan tai lokin pysyvään säilytykseen käytettävää levyä. Palvelimessa s on palvelimen puskuri (server buffer), jota käytetään tietokantasivujen puskurointiin siten kuin aiemmin on esitetty tavanomaisen kyselypalvelimen puskurinhallinnan yhteydessä. Jokaisella asiakkaalla c i on sen yksityiskäytössä oleva asiakkaan puskuri (client buffer, client cache), joka sisältää c i :ssä toimivien sovellusten operoimien tietokantasivujen kopioita. 232
s levyasemat palvelimen puskuri c 1 c 2 c 3 asiakkaan puskuri asiakkaan puskuri asiakkaan puskuri 233
Tarkastelemme sivupalvelinjärjestelmää, jonka prosessirakenne sisältää seuraavanlaisia prosesseja: Palvelimessa s toimii monisäikeinen tietokannan palvelinprosessi (database server) S, joka käsittelee asiakkailta tulevat palvelupyynnöt. Jokaisella asiakkaalla c i toimii monisäikeinen asiakkaan tietokantaprosessi (client database process) C i, jolle asiakkaalla c i toimivat sovellukset kohdistavat tietokannan käsittelypyyntönsä. Jokaisella asiakkaalla c i toimii yksi tai useampi asiakassovellusprosessi (client application process) A i j, joka suorittaa tietokantasovellusohjelmaa ja lähettää palvelupyyntöjä paikalliselle tietokantaprosessille C i transaktionkuljetus- eli kyselynkuljetusperiaatteella. 234
s S tiedonkuljetus (sivuja) kyselynkuljetus c 1 C 1 C 2 c 2 c 3 C 3 A 11 A 12 A 21 A 22 A 31 Asiakkaan c i sovelluksen A i j näkökulmasta sivupalvelinjärjestelmä on kyselynkuljetusperiaatteella toimiva paikallinen palvelu. 235
Transaktion suoritus tapahtuu kokonaan yhdellä asiakkaalla. Yksinkertaisuuden vuoksi voisimme hyvin olettaa, ettei palvelimessa suoriteta lainkaan transaktioita. Mikäli palvelimessakin halutaan suorittaa transaktioita, voidaan sitä varten näet käynnistää palvelimessa toimiva asiakkaan tietokantaprosessi, jonka alaisuudessa palvelimessa käynnistetyt sovellukset toimivat. Asiakkaan c i tietokantaprosessi C i jäsentää ja optimoi paikalliselta asiakassovellukseltaan A i j saamansa SQL-kyselyn ja suorittaa sen tuottaman tietokantaoperaatiosarjan sovelluksen transaktion nimissä. C i suorittaa tietokantaoperaatiot paikallisessa puskurissaan puskuroimilleen tietokantasivuille, pyytäen sivuja tarvittaessa palvelimelta. Puskurissaan olevat päivitetyt sivut ja päivitysten lokikirjaukset C i toimittaa aikanaan palvelimelle, joka asentaa sivut omaan puskuriinsa ja vie lokikirjaukset lokipuskuriin. Palvelimen puskurista päivitetyt sivut viedään aikanaan levylle normaaliin tapaan. 236
Tiedon puskurointi asiakkailla Eri asiakkailla puskuroitujen sivujen hallintaa varten palvelin ylläpitää keskusmuistissa puskuroitujen sivujen taulua, joka sisältää jokaisesta jonkin asiakkaan c i paikallisessa puskurissa olevasta sivusta p sivun tunnisteen, asiakkaan c i tunnisteen sekä puskurointioikeuden. Sivun p puskurointioikeus asiakkaalla c i voi olla lukuoikeus (read privilege, read token), joka oikeuttaa c i :n vain lukemaan sivua, tai päivitysoikeus (update privilege, write token), joka oikeuttaa c i :n sekä lukemaan että päivittämään p:tä. Usealla asiakkaalla voi olla samanaikaisesti sivuun p lukuoikeus, ts. p voi olla samanaikaisesti puskuroituna usean asiakkaan paikallisessa puskurissa lukemista varten. Sitä vastoin sivuun p voi kerrallaan olla vain yhdellä asiakkaalla päivitysoikeus, ts. p voi olla kerrallaan vain yhdellä asiakkaalla puskuroituna päivitystä varten. Tarkastelemassamme menetelmässä asiakkaan c i sivuun p omistama päivitysoikeus sulkee samalla pois muilta asiakkailta kaikki oikeudet p:hen. 237
Sivun p naulinta asiakkaan c i prosessille sisältää p:n hakemisen palvelimelta, mikäli p:tä ei ennestään ole c i :n puskurissa. Tällöin asiakasta c i palveleva palvelinprosessin S säie naulitsee ja lukusalpaa p:n, toimittaa p:stä kopion c i :hin ja vapauttaa p:n salpauksen ja naulinnan. Sivun p naulinnan vapautus asiakkaalla c i ei koskaan aiheuta mitään kommunikointia asiakkaan ja palvelimen välillä: sivu p jää asiakkaan puskuriin ja palvelimen puskuroitujen sivujen taulussa säilyy tieto p:n puskuroinnista c i :ssä entisellä oikeudella. Myöskään asiakkaan transaktion sitoutuminen ei tarkastelemassamme puskurointikäytännössä aiheuta mitään muutoksia transaktion lukemien tai päivittämien sivujen puskurointiin asiakkaalla. Sovellamme siis transaktiorajat ylittävää eli transaktioiden välistä puskurointia (inter-transaction caching): sivu voi olla salpaamatta ja naulitsematta asiakkaan puskurissa vaikkei asiakkaalla olisi suorituksessa yhtään transaktiota. 238
Transaktioiden välinen puskurointi on järkevää, koska samalla asiakkaalla aloitettu uusi transaktio usein operoi ainakin osittain samoihin sivuihin kuin vastikään päättynyt transaktio. Näin varsinkin silloin, kun tietokannan monikot on ryvästetty tietosivuille niiden luonnollista käsittelyjärjestystä noudattaen. Pitkän CAD-dokumentin editointi-istunnon katkaisee välillä operaatio save document, joka päättää transaktion. Istunnon jatko (seuraava transaktio) operoi lähes samoihin monikoihin kuin äsken päätetty transaktio. 239
Sivupalvelinjärjestelmän tila Keskitetylle tietokannalle määritellään käsitteet sivun levyversio, puskuriversio ja nykyversio sekä näiden avulla edelleen käsitteet tietokannan levyversio ja tietokannan nykyversio eli tietokannan tila. Sivupalvelinjärjestelmässä tiedon puskurointi asiakkaiden paikallisissa puskureissa tuo näihin määritelmiin yhden tason lisää. Sivun p levyversio (disk version) on p:n se versio, joka on palvelimen levyllä. Sivun p palvelinversio (server version) on palvelimen puskurissa oleva p:n versio, mikäli p on palvelimen puskurissa, ja p:n levyversio muutoin. Sivupalvelinjärjestelmän fyysisen tietokannan palvelinversio on sen sivujen palvelinversioiden joukko; loogisen tietokannan palvelinversio on fyysisen tietokannan tietosivujen palvelinversioiden sisältämien loogisten tietoalkioiden (monikoiden) joukko. 240
Sivun p nykyversio (current version) on se p:n versio, joka on puskuroituna jonkin asiakkaan c i paikallisessa puskurissa, mikäli p on puskuroituna jollakin asiakkaalla, ja p:n palvelinversio muutoin. Nykyversion määritelmä on mielekäs, koska puskurointimenetelmässämme sivu p voi olla samanaikaisesti puskuroituna usean asiakkaan puskurissa vain jos p:hen on näillä asiakkailla ainoastaan lukuoikeus (jolloin p on kaikilla asiakkailla samansisältöisenä). Sivupalvelinjärjestelmän fyysisen tietokannan nykyversio eli tila on sen sivujen nykyversioiden joukko; loogisen tietokannan nykyversio eli tila on fyysisen tietokannan tietosivujen nykyversioiden sisältämien loogisten tietoalkioiden (monikoiden) joukko. 241
Päivitysten levittämiskäytännöt Oletamme, että palvelin noudattaa sivujen puskuroinnissa tavanomaisia varasta- ja älä-pakota-käytäntöjä (steal-and-no-force policy): (1) Palvelin voi viedä puskuristaan levylle sivun, jolla on sitoutumattoman transaktion päivitys. (2) Palvelimen ei ole pakko viedä levylle transaktion päivittämiä sivuja transaktion sitoutumisen yhteydessä (eikä fyysisen tietokannan rakennemuutoksen koskettamia sivuja rakennemuutoksen valmistumisen yhteydessä). Asiakkaan c i puskurissa oleva sivu p on päivitetty (modified), jos se eroaa p:n palvelinversiosta, ja päivittämätön (unmodified) muutoin. Vrt. että palvelimen puskurissa olevaa sivua sanotaan päivitetyksi, jos se eroaa sivun levyversiosta. 242
Päivitetyn sivun toimittamisessa asiakkaalta palvelimeen voidaan soveltaa tietokannan hallintamenetelmästä riippuen erilaisia päivitysten levityskäytäntöjä (update-propagation policy). Kaikkien levityskäytäntöjen yhteydessä sovelletaan aina asiakkaan WAL-käytäntöä: Aina kun asiakkaalta c i toimitetaan palvelimeen päivitetty sivu p, toimitetaan palvelimeen samalla myös kaikki c i :ssä tuotetut, sivun p päivityksiä esittävät lokikirjaukset (mikäli näitä ei ole toimitettu palvelimeen jo aiemmin). Palvelin noudattaa luonnollisesti päivitettyjen sivujen ja lokikirjausten levylle viennissä tavanomaista WAL-käytäntöä: päivitetty sivu voidaan viedä palvelimen puskurista levylle vasta kun kaikki sivun päivitysten lokikirjaukset on viety levylle. 243
Päivitysten välittömässä levittämisessä (immediate update propagation) päivitetty sivu toimitetaan palvelimeen ja asennetaan sen puskuriin välittömästi jokaisen sivulle suoritetun päivityksen jälkeen. Näin esimerkiksi asiakkaalla c i päivitystä varten puskuroitu tietosivu p, jolle on suoritettu kirjoitusoperaatio W[x], toimitetaan (lokikirjauksineen) asiakkaalta c i palvelimeen heti, kun p:n salpaus c i :ssä on vapautettu. Samoin toimitetaan B-puun rakennemuutokseen (esim. sivun halkaisuun) osallistuneet sivut (lokikirjauksineen) c i :stä palvelimeen heti, kun niiden salpaus on rakennemuutoksen valmistuttua vapautettu. Päivitettyjä sivuja ei kuitenkaan poisteta asiakkaan puskurista, vaan asiakkaalle jää niiden päivitysoikeus. Päivitysten välittömässä levittämisessä tietokannan nykyversio yhtyy tietokannan palvelinversioon aina päivitysoperaatioiden välillä. Haittana on tiuhaan päivitetyn sivun jatkuva siirtäminen asiakkaalta palvelimeen. 244
Sitoutuneiden päivitysten levityksessä (committed-update propagation, force-to-server-at-commit) asiakas toimittaa transaktion päivittämät sivut palvelimeen transaktion sitoutumisen yhteydessä: Asiakkaan transaktio sitoutuu vasta, kun sen päivittämät sivut on asennettu palvelimen puskuriin (ja päivitysten lokikirjaukset viety palvelimen levylle). Asiakkaalla suoritettu fyysisen tietokannan rakennemuutos sitoutuu vasta, kun sen muuttamat sivut on asennettu palvelimen puskuriin (ja muutoksen lokikirjaus viety palvelimen levylle). Sitoutuneiden päivitysten levittämisessä tietokannan nykyversio yhtyy tietokannan palvelinversioon aina päivitystransaktioiden välillä, ts. aina silloin kun millään asiakkaalla ei ole päivittävää transaktiota tai rakennemuutosta käynnissä. Päivitettyjä sivuja ei poisteta asiakkaan puskurista sitoutumisen yhteydessä, vaan asiakkaalle jää niiden päivitysoikeus. 245
Laiskassa eli tarvehakuisessa päivitysten levityksessä (lazy update propagation, demand-driven update propagation) asiakkaalla päivitetty sivu toimitetaan palvelimeen vasta, kun sitä tarvitaan jollakin toisella asiakkaalla (sikäläisen transaktion luku- tai päivitysoperaatiota varten) tai palvelimessa (esim. täydellisen tarkistuspisteen ottoa varten) tai kun asiakkaan puskuritila loppuu. Tällöin asiakas luopuu samalla sivuun omistamastaan päivitysoikeudesta. Tätä levityskäytäntöä oletamme sovellettavaksi seuraavassa. 246
Puskurieheys ja takaisinkutsut Tiedon puskuroinnissa asiakkailla on ongelmana puskurieheyden (cache consistency) takaaminen: kun sivu p salvataan asiakkaalla c i transaktion luku- tai päivitysoperaatiota tai rakennemuutosta varten, c i :n puskurissa olevan p:n version täytyy olla p:n nykyversio. Tarvitaan mekanismi, jolla palvelin voi ottaa asiakkaalta c i pois naulitsemattoman sivun puskurointioikeuden, kun sivua pyydetään puskuroitavaksi toiselle asiakkaalle c j päivittämistä varten. Samoin asiakkaan c i puskuroimaansa kirjoitussalpaamattomaan sivuun omistama päivitysoikeus täytyy voida alentaa lukuoikeudeksi, kun sivua pyydetään puskuroitavaksi toiselle asiakkaalle c j lukemista varten. Asiakkaan c i sivuun p omistaman puskurointioikeuden pois ottamista tai alentamista sanotaan sivun p takaisinkutsuksi (callback) asiakkaalta c i. 247
Oletetaan, että asiakas c j pyytää palvelimelta oikeutta puskuroida sivu p lukemista varten. Sivua p ei siis ole ennestään c j :n puskurissa. Palvelin tutkii puskuroitujen sivujen taulusta, onko p puskuroituna jollakin toisella asiakkaalla päivittämistä varten. Jos p ei ole puskuroituna päivittämistä varten, palvelin naulitsee ja lukusalpaa p:n, kirjaa puskuroitujen sivujen tauluun c j :lle lukuoikeuden p:hen, toimittaa p:stä kopion c j :lle ja vapauttaa p:n salpauksen ja naulinnan. Asiakas c j asentaa p:n paikalliseen puskuriinsa. Jos taas p on puskuroituna asiakkaalla c i päivittämistä varten, palvelin lähettää c i :lle takaisinkutsun, jolla pyytää c i :tä alentamaan p:n puskurointioikeuden lukuoikeudeksi. 248
Takaisinkutsun saatuaan asiakas c i tutkii, onko sivu p parhaillaan päivitettävänä, so. kirjoitussalvattuna. Kun p ei ole enää kirjoitusalvattuna c i :ssä, c i toimittaa p:n ja sen päivitysten lokikirjaukset palvelimeen (mikäli p:tä oli päivitetty ja sitä ja lokikirjauksia ei jo ollut toimitettu palvelimelle aiemmin). Sen lisäksi c i viestittää palvelimelle alentavansa p:n puskurointioikeuden lukupuskuroinniksi. p:tä ei siis poisteta c i :n puskurista. Palvelin vie lokikirjaukset lokipuskuriin ja asentaa p:n puskuriinsa (korvaten siellä mahdollisesti olevan p:n palvelinversion). Palvelin kirjaa puskuroitujen sivujen taulussa p:n puskuroiduksi lukemista varten asiakkailla c i ja c j ja toimittaa kopion p:stä asiakkaalle c j, joka asentaa sivun puskuriinsa. 249
Oletetaan sitten, että c j pyytää palvelimelta lukuoikeudella puskuroimansa sivun q puskurointioikeuden korotusta päivitysoikeudeksi. Palvelin tutkii puskuroitujen sivujen taulusta, millä muilla asiakkailla q on puskuroituna. Mikäli q on puskuroituna c j :n lisäksi asiakkailla c i, i = m 1,...,m k, palvelin kutsuu q:n takaisin kaikilta asiakkailta c i, i = m 1,...,m k. Takaisinkutsu sisältää nyt vaatimuksen poistaa sivu puskurista. Takaisinkutsun saatuaan asiakas c i tutkii, onko sivu q parhaillaan luettavana, so. lukusalvattuna. Kun q ei enää ole salvattuna, c i poistaa q:n puskuristaan ja viestittää palvelimelle luopuneensa q:n puskurointioikeudesta. Palvelin poistaa puskuroitujen sivujen taulusta tiedon q:n puskuroinnista c i :ssä. Kun palvelin on saanut takaisinkutsuihinsa kaikilta sivua q puskuroivilta asiakkailta c i vastauksen, palvelin kirjaa q:n puskuroiduksi päivittämistä varten asiakkaalle c j ja viestittää tästä c j :lle. 250
Lokin hallinta Lokitiedosto sijaitsee sille varatulla levyllä palvelimessa. Kyselynkuljetusjärjestelmässä kaikki lokikirjaukset syntyvät palvelimessa, koska varsinaiset tietokantaoperaatiot suoritetaan siellä. Tiedonkuljetusjärjestelmässä enimmät lokikirjaukset syntyvät asiakkailla, joista ne täytyy toimittaa palvelimeen. Kullakin asiakkaalla on oma paikallinen lokinhallitsin muttei lokilevyä. Asiakas voi puskuroida lokikirjauksia omassa virtuaalimuistissaan ennen niiden lähettämistä palvelimeen. Kun palvelin saa lokikirjauksia asiakkaalta, se vie ne lokipuskuriin, lokitiedoston perään liitettäviksi. Palvelimen häiriön varalta asiakkaan tulee säilyttää tuottamansa lokikirjaus niin kauan kuin on saatu varmistus siitä, että palvelin on pakottanut lokikirjauksen levylle. 251
Miten taataan, että päivitettyä tietokantasivua vastaavat lokikirjaukset menevät palvelimen levylle ennen tietokantasivua, kun lokikirjauksia ja sivuja saapuu palvelimeen toisistaan riippumatta? WAL-käytännön noudattaminen edellyttää, että lokikirjausten järjestysnumeroiden (LSN) tulisi muodostaa päivitysten todellisen järjestyksen (so. lokikirjausten syntyjärjestyksen) suhteen monotonisesti nouseva jono. Miten tämä on mahdollista, jos asiakkaiden sallitaan tuottaa lokikirjauksia toisistaan riippumatta? On tehotonta tiedustella palvelimelta joka kerta erikseen vapaana olevaa LSN:ää. Asiakkaiden pitää antaa tuottaa LSN:nsä paikallisesti. 252
Paikallisesti tuotettu LSN ei silloin voi enää olla suora osoite lokitietueeseen palvelimen lokilevyllä. Sivua päivitettäessä sivun otsikkotietueen Page-LSN-kenttään leimattava arvo ilmoittaa edelleen sivulle tulleiden päivitysten kronologisen järjestyksen. Puskurointikäytäntömme mukaisesti sivun sallitaan olevan kerrallaan vain yhden asiakkaan puskurissa päivitettävänä. Koska LSN ei nyt enää ole lokikirjauksen suora osoite, se täytyy eksplisiittisesti sijoittaa lokikirjaukseen omaan kenttäänsä. Asiakkaan tuottamaan lokikirjaukseen sisältyy sekä asiakkaan tunniste että lokikirjauksen LSN. 253
Asiakkaan c i paikallinen lokinhallitsin ylläpitää laskuria Local-Max-LSN(c i ), joka sisältää c i :ssä viimeksi tuotetun lokikirjauksen LSN:n. Olkoon o sivuille p 1,..., p n kohdistuva päivitysoperaatio (joko tietosivulle p 1 suoritettava operaatio I, D tai W tai useampaa sivua p 1,..., p n koskettava rakennemuutos), joka suoritetaan asiakkaalla c i. Operaation o lokikirjauksen LSN:ksi tulee arvo n = 1+max{Page-LSN(p 1 ),...,Page-LSN(p n ),Local-Max-LSN(c i )}. Uusi LSN-arvo n sijoitetaan itse lokikirjaukseen, leimataan sivujen p 1,..., p n Page-LSN-kenttään ja asetetaan laskurin Local-Max- LSN(c i ) uudeksi arvoksi. Tällä tavalla taataan, että (1) samalle sivulle eri asiakkailla tehdyt päivitykset saavat päivitysten todellista kronologista järjestystä noudattavan LSN:n ja että (2) samalla asiakkaalla tuotettujen lokikirjausten LSN:ien jono on nouseva. 254
Transaktion peruutusta ja järjestelmän häiriöistä elvytystä varten täytyy saada selville se kohta lokista, josta selaus pitää aloittaa. Tämä ei käykään enää selville LSN:istä, jotka ovat vain lokikirjausten loogisia osoitteita eivätkä fyysisiä. Palvelimessa ylläpidetään eri asiakkaiden c i tuottamien LSNarvojen ja niitä vastaavien lokikirjausten fyysisten osoitteiden välistä kuvausta niiden LSN:ien osalta, joita elvytysalgoritmi tarvitsee. Kuvaus esitetään kolmikoista (c i, LSN, osoite) koostuvassa hajautustaulussa. Palvelimen päivitettyjen sivujen taulussa ylläpidetään jokaista palvelimen puskurissa olevaa päivitettyä sivua p kohti arvoa Rec- Addr(p), joka on fyysinen lokiosoite. Rec-Addr(p) ilmoittaa sen kohdan lokissa, josta lähtien sivulla p voi olla eri asiakkaiden tai palvelimen itsensä tekemiä päivityksiä, jotka eivät vielä näy sivun levyversiossa. Elvytysalgoritmissa Rec-Addr-arvoja käytetään Rec-LSN-arvojen sijasta. 255
Kunkin asiakkaan c i paikallisessa päivitettyjen sivujen taulussa ylläpidetään jokaista c i :n puskuroimaa päivitettyä sivua p kohti arvoa Rec-LSN(p). Rec-LSN(p) on asiakaskohtainen looginen lokiosoite, LSN-arvo, joka ilmoittaa asiakkaan puskuroiman sivun p päivitysten alkukohdan suhteessa sivun palvelinversioon. Rec-LSN(p) on se LSN, josta lähtien sivulla p voi olla c i :ssä tehtyjä päivityksiä, jotka eivät vielä näy p:n palvelinversiossa. 256
Kun asiakas c i lähettää päivitetyn sivun p palvelimeen, lähetetään samalla myös Rec-LSN(p). Mikäli sivun p palvelinversio on vielä päivittämätön, so. joko p:tä ei ole palvelimen puskurissa tai palvelimen puskurissa oleva p:n versio yhtyy p:n levyversioon, viedään p nyt palvelimen päivitettyjen sivujen tauluun ja asetetaan siellä arvoksi Rec-Addr(p) arvoa Rec-LSN(p) vastaava fyysinen lokiosoite (tai konservatiivisesti jokin sitä alempi, helposti määrättävissä oleva lokiosoite). Muussa tapauksessa p on jo kirjattu päivitettyjen sivujen tauluun, ja Rec-Addr(p) jätetään entiselleen. Kummassakin tapauksessa asiakkaan c i lähettämä sivu asennetaan palvelimen puskuriin, jossa se korvaa siellä mahdollisesti vielä olevan entisen version. 257
Asiakkaan häiriöistä elvytys Jos asiakas c i romahtaa, palvelin suorittaa sen puolesta ARIESelvytysalgoritmin analyysi-, toisto- ja peruutusvaiheet. Peruutusvaiheessa suoritettavista asiakkaan c i transaktion T käänteisoperaatioista palvelin tuottaa lokikirjaukset T :n nimissä. Asiakkaan häiriöiden käsittely tehostuu, jos myös asiakkaat ottavat aika ajoin tarkistuspisteitä. Asiakkaan c i tarkistuspisteessä kirjataan lokiin c i :n päivitettyjen sivujen taulu ja c i :n aktiivisten transaktioiden taulu. Kuten edellä määrittelimme, päivitetyksi sivuksi katsotaan c i :n puskurissa oleva sivu p, jonka sisältö eroaa p:n palvelinversiosta. 258
Asiakkaan c i päivitettyjen sivujen taulu sisältää jokaisesta c i :n puskurissa olevasta päivitetystä sivusta p sivun tunnisteen ja arvon Rec- LSN(p). Kun palvelin saa asiakkaan c i ottaman tarkistuspisteen päättävän lokikirjauksen c i,end-checkpoint, palvelin muuntaa tarkistuspisteen päivitettyjen sivujen taulun loogiset Rec-LSN-osoitteet fyysisiksi lokiosoitteiksi: Jokaiselle päivitettyjen sivujen taulun Rec-LSN(p)-arvolle määrätään sitä vastaava (tai konservatiivisesti alempi) fyysinen lokiosoite Rec-Addr(p). Näin saatu, pareista (p, Rec-Addr(p)) koostuva taulu sijoitetaan lokikirjaukseen c i,end-checkpoint, minkä jälkeen tietue viedään lokipuskuriin. 259
Esimerkki. Asiakkaalla c 1 aloitetaan uusi transaktio. Määrätään transaktiotunniste T 1 ja uusi LSN-arvo n 1. Tuotetaan lokikirjaus c 1,n 1,T 1,B. Transaktio T 1 haluaa sitten suorittaa operaation W[x 1,u 1,v 1 ] sivulle p, johon ei ole vielä operoitu sitten järjestelmän käynnistyksen. Asiakas c 1 pyytää sivua p palvelimelta päivitettäväksi c 1 :ssä. Palvelin naulitsee ja kirjoitussalpaa p:n. Palvelin kirjaa puskuroitujen sivujen tauluun p:n puskuroiduksi päivittämistä varten c 1 :ssä, lähettää kopion p:stä c 1 :lle ja vapauttaa lopuksi p:n salpauksen ja naulinnan. Asiakas c 1 asentaa p:n paikalliseen puskuriinsa ja kirjoitussalpaa sen. Asiakkaalla c 1 muutetaan sivulla p tietuepaikassa i sijaitseva monikko (x 1,u 1 ) monikoksi (x 1,v 1 ), määrätään uusi LSN-arvo n 2, tuotetaan lokikirjaus c 1,n 2,T 1,W, p,i,x 1,u 1,v 1,n 1, asetetaan Page-LSN(p) = n 2 ja Undo-Next-LSN(T 1 ) = n 2 ja vapautetaan sivun p salpaus. 260
Asiakkaan c 2 transaktio T 2 haluaa nyt suorittaa sivulle p operaation W[x 2,u 2,v 2 ], missä x 2 x 1. Asiakas c 2 pyytää sivua p palvelimelta päivitettäväksi c 2 :ssa. Palvelin lähettää sivun p takaisinkutsun c 1 :een. Asiakas c 1 lähettää lokikirjaukset n 1 ja n 2 sekä päivitetyn sivun p palvelimeen. Samalla c 1 viestittää palvelimelle, ettei enää puskuroi p:tä, ja poistaa sivun puskuristaan. Palvelin vie lokikirjaukset lokipuskuriin, naulitsee ja kirjoitussalpaa p:n, sijoittaa asiakkaalta c 1 saamansa p:n version p:lle varattuun puskurikehykseen, määrää LSN-arvoa n 2 vastaavan Rec-Addr-arvon, vie p:n päivitettyjen sivujen tauluun ja poistaa puskuroitujen sivujen taulusta tiedon p:n puskuroinnista c 1 :ssä. 261
Palvelin kirjaa puskuroitujen sivujen tauluun p:n puskuroiduksi päivittämistä varten c 2 :ssä, lähettää kopion p:stä c 2 :lle ja vapauttaa lopuksi p:n salpauksen ja naulinnan. Asiakas c 2 asentaa p:n paikalliseen puskuriinsa ja kirjoitussalpaa sen. Asiakkaalla c 2 muutetaan sivulla p tietuepaikassa j sijaitseva monikko (x 2,u 2 ) monikoksi (x 2,v 2 ), määrätään uusi LSN-arvo n 3 (> n 2 ), tuotetaan lokikirjaus c 2,n 3,T 2,W, p, j,x 2,u 2,v 2,m, missä m = Undo-Next-LSN(T 2 ), asetetaan Page-LSN(p) = n 3 Undo-Next-LSN(T 2 ) = n 3 ja vapautetaan sivun p salpaus. Sitten asiakas c 1 romahtaa transaktion T 1 ollessa vielä aktiivinen. ja 262
Palvelin ryhtyy suorittamaan ARIES-algoritmia romahtaneen asiakkaan c 1 puolesta. Analyysivaiheessa selataan palvelimen lokia ja rekonstruoidaan c 1 :n transaktiotaulu ja c 1 :n päivitettyjen sivujen taulu. Transaktiotaulussa on T 1. Päivitettyjen sivujen taulussa on pari (p,rec-lsn(p)), missä Rec-LSN(p) = n 2. Lokin selaus aloitetaan Rec-LSN(p):tä vastaavasta lokiosoitteesta Rec-Addr(p). Toistovaiheessa sivu p on haettava esiin ja sen Page-LSN tutkittava, koska Rec-LSN(p) n 2. 263
Puskuroitujen sivujen taulusta havaitaan, että p on puskuroituna päivitystä varten asiakkaalla c 2. Kutsutaan p takaisin c 2 :sta. Asiakas c 2 lähettää lokikirjauksen n 3 ja päivitetyn sivun p palvelimeen. Samalla c 2 viestittää palvelimelle, ettei enää puskuroi p:tä, ja poistaa sivun puskuristaan. Palvelin vie lokikirjauksen n 3 lokipuskuriin, naulitsee ja kirjoitussalpaa p:n, sijoittaa asiakkaalta c 2 saamansa p:n version p:lle varattuun puskurikehykseen ja poistaa puskuroitujen sivujen taulusta tiedon p:n puskuroinnista c 2 :ssa. Elvytyksen toistovaihe voi nyt jatkua. Havaitaan, että Page-LSN(p) = n 3 > n 2. Vapautetaan p:n salpaus ja naulinta. Toistovaihe päätyy. 264
Peruutusvaiheessa keskeytetään T 1 kirjaamalla lokiin c 1,n 4,T 1,A, missä n 4 > n 3. Peruutetaan T 1, so. naulitaan ja kirjoitussalvataan p, toteutetaan operaation W[x 1,u 1,v 1 ] käänteisoperaatio W 1 [x 1,u 1,v 1 ] sivulle p ja kirjataan lokiin c 1,n 5,T 1,W 1, p,i,x 1,u 1,v 1,n 1, missä n 5 > n 4, asetetaan Page-LSN(p) = n 5 ja Undo-Next-LSN(T 1 ) = n 1 ja vapautetaan sivun p salpaus ja naulinta. Päätetään T 1 :n peruutus kirjaamalla lokiin c 1,n 6,T 1,C, missä n 6 > n 5, ja pakottamalla loki levylle. Entä mitä c 1 :n pitää tehdä, kun se käynnistyy uudestaan? Elvytyksen eteen ei c 1 :n ole enää tarpeen tehdä mitään, vaan se voi ryhtyä heti ottamaan vastaan uusia transaktioita. 265
Palvelimen häiriöistä elvytys Omista häiriöistään elpymiseksi palvelin ottaa määräajoin omia tarkistuspisteitä. Palvelimen tarkistuspisteessä lokiin kirjataan palvelimen aktiivisten transaktioiden taulu ja päivitettyjen sivujen taulu. Transaktiotaulussa on tiedot palvelimen omista transaktioista, so. niistä transaktioista, joita suoritetaan palvelimessa. Päivitettyjen sivujen taulussa on tieto jokaisesta palvelimen puskurissa olevasta päivitetystä sivusta, so. sivusta, jonka puskuriversio eroaa sivun levyversiosta. Päivittämättömästä sivusta p tulee merkintä palvelimen päivitettyjen sivujen tauluun, kun (1) p:n päivitetty versio saapuu p:tä ensimmäisenä päivittäneeltä asiakkaalta tai (2) palvelimen oma transaktio päivittää p:tä ensimmäisenä. Samalla määrätään Rec-Addr(p). 266
Palvelimen häiriöstä elvytys perustuu ARIES-algoritmin mukaisesti palvelimen viimeksi ottamaan tarkistuspisteeseen, joka on kokonaisuudessaan kirjattu lokiin ja ehtinyt levylle asti ennen häiriötä. Elvytyksen toistovaiheessa toistetaan kaikki eri asiakkaiden transaktioiden lokiin kirjatut päivitykset (samoin kuin palvelimen omien transaktioiden lokiin kirjatut päivitykset), jotka eivät olleet ehtineet palvelimen puskurista levylle ennen häiriötä. Elvytyksen peruutusvaiheessa peruutetaan palvelimen omat aktiiviset transaktiot. Analyysivaiheessa rekonstruoidaan päivitettyjen sivujen taulu alustaen se palvelimen ottamasta tarkistuspisteestä ja lisäämällä siihen vasta tarkistuspisteen jälkeen päivitetyt sivut. 267
Asiakkaan päivittämä sivu p, joka on saapunut palvelimeen ja kirjattu päivitetyksi ennen tarkistuspistettä, löytyy rekonstruoidusta päivitettyjen sivujen taulusta, koska siitä on merkintä lokiin vedostetussa päivitettyjen sivujen taulussa. Samoin löytyy sellainen sivu p, joka muuttui päivitetyksi vasta tarkistuspisteen jälkeen ja jonka lokikirjauksia on saapunut palvelimeen ja ehtinyt levylle ennen häiriötä, sillä analyysivaiheessa lokista poimitaan kaikki tarkistuspisteen aloituksen jälkeen päivitetyt sivut ja viedään ne rekonstruoituun päivitettyjen sivujen tauluun. Sitä vastoin taulusta ei välttämättä löydy sivua p, joka on ennen tarkistuspistettä päivittämättömänä lähetetty jollekin asiakkaalle c ensi kertaa päivitettäväksi. Tällaisen sivun p päivitysten ainoat lokikirjaukset ovat voineet saapua palvelimeen ja ehtiä levylle asti ennen tarkistuspistettä. 268
... Sivu p noudetaan levyltä ja toimitetaan asiakkaalle c. Asiakkaan c transaktio T sitoutuu; T :n lokikirjaukset palvelimeen. c,n 2,T,W, p,i,x,u,v,n 1. c,n 3,T,C. Palvelin ottaa tarkistuspisteen: s,n 4,begin-checkpoint. s,n 5,transaction-table{...}. s,n 6,page-table{...} ei sisällä p:tä. s,n 7,end-checkpoint. Päivitetty p toimitetaan c:stä palvelimeen (esim. takaisinkutsusta). Palvelin vie p:n tiedot päivitettyjen sivujen tauluun. Asiakas c poistaa p:n puskuristaan. Palvelin romahtaa häiriöön. 269
Saatuaan palvelimelta varmistuksen lokikirjausten levylle viennistä asiakas c on poistanut lokikirjaukset paikallisesta puskuristaan. Tarkistuspisteen jälkeen asiakas c on lähettänyt päivitetyn sivun p palvelimeen ja poistanut sen paikallisesta puskuristaan. Asiakkaalla ei nyt enää ole tallessa p:n päivityksiä missään muodossa. Palvelin on asettanut p:n puskuriin, kirjannut p:stä tiedot päivitettyjen sivujen tauluunsa, pakottanut lokin levylle ja tiedottanut siitä asiakkaalle. Tarkistuspisteen ottamisen jälkeen ei palvelimeen ole tullut minkään transaktion päivitysten lokikirjauksia sivulle p eikä sivua p ole viety levylle. Palvelimen häiriön vuoksi puskurissa oleva päivitetty sivu p menetetään. 270
Analyysivaiheen tuloksena saatava, toistovaiheen aloituskohdan ilmoittama Redo-Addr-arvo voi olla suurempi kuin p:n päivitysten lokikirjausten osoitteet, jolloin asiakkaan c sitoutuneen transaktion sivulle p tekemiä päivityksiä ei toisteta, vaan ne menetetään. Yksinkertainen ratkaisu olisi viedä päivittämätön sivu p palvelimen päivitettyjen sivujen tauluun heti, kun sitä pyydetään puskuroitavaksi päivittämistä varten jollekin asiakkaalle. Rec-Addr(p)-arvo jää silloin kylläkin tarpeettoman varhaiseksi. 271
Parempi ratkaisu on sisällyttää palvelimen ottamaan tarkistuspisteeseen kaikkien asiakkaiden paikalliset päivitettyjen sivujen taulut. Palvelin aloittaa tarkistuspisteen kirjaamalla lokiin s,n, begin-checkpoint. Sitten palvelin pyytää kaikkia asiakkaita lähettämään palvelimeen vedoksen päivitettyjen sivujen tauluistaan. Kun kaikki asiakkaat ovat lähettäneet omansa, palvelin yhdistää oman taulunsa ja asiakkailta saamansa päivitystiedot ja vedostaa tiedot lokiin. Päivitettyjen sivujen Rec-LSN-arvot muutetaan Rec-Addr-osoitteiksi, kuten edellä on selostettu. Kirjataan lokiin palvelimen omien aktiivisten transaktioiden taulu. Kirjataan lokiin s,n,end-checkpoint{(p,rec-addr(p))-parit}. 272
Nyt analyysivaihe osaa määrätä tarpeeksi aikaisen Redo-Addrarvon, ja toistovaihe tuo kaikki lokiin kirjatut päivitykset palvelimen puskuriin. Kun palvelin on elpynyt häiriöstään, sen täytyy vielä suorittaa elvytys niiden asiakkaiden puolesta, jotka mahdollisesti sillä välin olivat romahtaneet, sekä hankkia käynnissä olevilta asiakkailtaan ne tiedot transaktioiden hallussa olevista lukoista ja puskuroiduista sivuista, joista on tarpeen olla tieto palvelimessa. Asiakkaiden täytyy lähettää uudestaan palvelimeen ne lokikirjaukset, joiden levylle viennistä ei ollut saatu varmistusta palvelimelta häiriön vuoksi. 273
Lukkojen hallinta Keskitettyihin tietokantoihin kehitettyjä lukitusmenetelmiä voidaan soveltaa myös sivupalvelinjärjestelmän transaktioiden samanaikaisuuden hallinnassa. Lukot voivat olla loogisia (avaimiin tai relaatioihin varattuja) tai fyysisiä (monikkotunnisteisiin tai sivuihin varattuja). Lukituskäytäntö täytyy sovittaa yhteen puskurointikäytännön kanssa. Koska puskurointi on fyysistä, on fyysisen lukituksen sovittaminen puskuroinnin kanssa suoraviivaisempaa kuin loogisen lukituksen. Sivun rakeisuudella toimiva ankara kaksivaihelukitus voidaan kytkeä suoraan puskurointiin siten, että sivun puskurointioikeus asiakkaalla säilytetään asiakkaan transaktion kestoajan. 274
Tietoalkioihin varattujen lukkojen ylläpitoa varten jokaisella asiakkaalla c on oma paikallinen lukkotaulu, johon kirjataan c:n transaktioiden hallussa olevat lukot. Asiakkaan c paikallisen lukkotaulun alkiot ovat normaaliin tapaan nelikkoja (T,x,m,d), missä x on lukon nimi, m lukon tyyppi, d kestoaika ja T asiakkaan c transaktion tunniste. Asiakkaiden transaktioiden varaamista lukoista pidetään kirjaa myös palvelimen globaalissa lukkotaulussa, johon lukot kirjataan asiakkaiden nimiin. Globaalin lukkotaulun alkiot ovat siis nelikkoja (c, x, m, d), missä x on lukon nimi, m lukon tyyppi, d kestoaika ja c asiakkaan tunniste. 275
Esimerkki. Asiakkaan c transaktio T alkaa ja pyytää S-lukkoa avainarvoon x. Asiakas c tarkistaa paikallisesta lukkotaulustaan, onko siinä S-lukon kanssa yhteensopimatonta lukkoa. Jos on, T jää odottamaan. Muutoin jos c:n paikallisessa lukkotaulussa on x:ään jollakin toisella c:n transaktiolla S-lukko, myöntää c S- lukon T :lle omalla päätöksellään, keskustelematta palvelimen kanssa. Jos c:n paikallisessa lukkotaulussa ei ole x:ää, c pyytää palvelimelta S-lukkoa x:ään omissa nimissään. Palvelin tarkistaa globaalista lukkotaulusta, onko siinä pyydetyn lukon kanssa yhteensopimatonta lukkoa. Jos on, asiakkaan pyyntö jää odottamaan. Jos ei ole, palvelin kirjaa globaaliin lukkotauluun pyydetyn lukon c:n nimiin ja palauttaa tiedon c:lle, joka kirjaa lukon paikalliseen lukkotauluunsa T :n nimiin. 276
Yhteislevyjärjestelmä Monet sivupalvelinjärjestelmän hallinnassa tarvittavat menetelmät soveltuvat sellaisinaan tai vähän muutettuina myös yhteislevyjärjestelmän (shared-disks system) hallintaan. Eroja syntyy siitä, että yhteislevyjärjestelmässä erillistä palvelinsolmua ei ole, vaan järjestelmän solmut ovat keskenään vertaisia: kussakin solmussa toimii täsmälleen saman tietokannan hallintajärjestelmän ilmentymä (instance), so. solmun yksityisessä keskusmuistissa toimiva prosessijoukko. Jokaisella solmulla on suora pääsy yhteiseen tietokantaan oman puskurinsa välityksellä: solmu voi tuoda sivun levyltä suoraan omaan puskuriinsa ja viedä päivitetyn sivun puskurista suoraan levylle. Sivu voidaan myös siirtää yhden solmun puskurista yhteenkytkentäverkon välityksellä toisen solmun puskuriin. Tämä onkin yleensä huomattavasti nopeampaa kuin sivun siirto levyn välityksellä. 277
Samoin kuin sivupalvelinjärjestelmässä, yhteislevyjärjestelmässä jokainen transaktio aloitetaan jossakin solmussa ja suoritetaan alusta loppuun samassa solmussa. Tällainen transaktio voi luonnollisesti olla jonkin hajautetun transaktion alitransaktio hajautetussa tietokantajärjestelmässä, jonka yhtenä pisteenä yhteislevyjärjestelmä toimii. Järjestelmän jokainen solmu ylläpitää omaa lokiaan, johon solmun transaktioiden lokikirjaukset ensin viedään. Solmu tuottaa transaktioidensa päivityskirjausten lokijärjestysnumerot samalla tavalla kuin sivupalvelinjärjestelmän asiakas. Järjestelmän solmuista yhdellä on pääsy kaikkien muiden solmujen lokitiedostoihin, ja tuossa solmussa toimiva prosessi tuottaa lokitiedostoista lomitettua versiota. 278
Sivun puskurointia solmujen puskureissa valvotaan samanlaisin puskurointioikeuksin kuin sivupalvelinjärjestelmässäkin: sivu voi olla puskuroituna samanaikaisesti useammassa solmussa lukemista varten, mutta puskurointi päivitystä varten yhden solmun puskurissa sulkee muilta solmuilta pois puskurointioikeuden. Solmun s 1 päivittämän sivun p päivitysoikeuden siirto solmulta s 1 solmulle s 2 voidaan toteuttaa eri tavoin. Yksinkertaisimmassa (ja hitaimmassa) tavassa p siirretään levyn kautta: s 1 vie p:n puskuristaan levylle WAL-käytäntöä noudattaen ja luopuu sitten päivitysoikeudestaan p:hen, minkä jälkeen s 2 saa päivitysoikeuden p:hen ja tuo p:n levyltä omaan puskuriinsa. Hieman nopeammassa tavassa s 1 vie p:n levylle ja samanaikaisesti siirtää p:n myös yhteyslinkin välityksellä suoraan s 2 :lle, jolta siten säästyy levyhaku. 279
Nopeimmissa tavoissa sivun p päivitysoikeuden nykyinen haltija s 1 ei vie sivua levylle, vaan s 1 ainoastaan pakottaa lokikirjaukset levylle Page-LSN(p):hen asti ja siirtää tämän jälkeen p:n sen päivitysoikeutta pyytäneeseen solmuun s 2 yhteyslinkin välityksellä. Päivitetty sivu voi nyt sisältää useammassa solmussa tehtyjä päivityksiä ennen kuin se aikanaan viedään levylle. Tämä vaikeuttaa häiriöstä elvytystä. Sivua p viimeksi päivittäneen solmun romahdettua menetetään p:n nykyversio. Sivun p saattaminen ajan tasalle p:n levyversiosta, josta puuttuu useamman eri solmun transaktioiden päivityksiä, vaatii eri solmujen lokeista lomitetun lokin läpikäyntiä tietystä LSN-arvosta alkaen. Kaikkein nopeimmassa siirtotavassa s 1 ei edes pakota lokikirjauksia levylle ennen p:n siirtoa s 2 :lle. WAL-käytäntöä täytyy nyt muuttaa niin, että päivitetty sivu voidaan viedä sitä viimeksi päivittäneen solmun puskurista levylle vasta kun kaikki sivua päivittäneet solmut ovat pakottaneet lokinsa levylle. 280