av Zsolt Vajda för 7 årar sedan
351
Mer av detta
A gondolattérkép elkészítéséhez forrásként használtam fel az előadás diáit, illetve az előadáson elhangzottakat.
"A párhuzamos feldolgozás koordinálásának a lényege az, hogy a tranzakciók egymástól függetlenül fussanak, ne dolgozhassanak ugyanazokkal a rekordokkal, ha az nem egyértelmű állapothoz vezetne. Ha valamilyen okból mégis konfliktus alakulna ki közöttük, akkor az úgy oldódjon meg, hogy az adatbázis utána is konzisztens, egyértelműen definiálható állapotban maradjon."
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
A párhuzamos feldolgozás legfontosabb eleme a tranzakció. A felhasználók az adatokat olvassák és módosítják egy tranzakció belsejében. Ez olyan egymást követő adatbázis-műveletek sorozata, melyek vagy teljes egészükben mind megvalósulnak, vagy egy elemük sem hajtódik végre, illetve nem véglegesítődik. Ezeket a módosításokat bármikor jóváhagyhatják (COMMIT utasítás), vagy visszavonhatják (ROLLBACK utasítás). Az adatbáziskezelő rendszer nem tudhatja előre, hogy a felhasználó melyik utasítást fogja kiadni (és akkor még nem is beszéltünk arról, hogy meghibásodás is felléphet).
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
A tranzakció többféle lehetséges kimenetele miatt az új (úgynevezett After Image) és a régi ("Before Image") értéket egyaránt meg kell őrizni. Az új érték csak a jóváhagyás (COMMIT utasítás kiadása) után válik láthatóvá mások (másik munkamenetek) számára (ezt úgy kell érteni, hogy az adatokat módosító felhasználó egy másik bejelentkezésből szintén csak a jóváhagyás után látja az új értéket).
Hol tároljuk az értékeket?
A tranzakciók 99%-a jóváhagyással (COMMIT-tal) ér véget, ezért logikus, hogy az új értéket az eredeti helyen, míg a régi értéket egy másik helyen tároljuk. Így a jóváhagyás után az új érték van a megfelelő helyen, a régit pedig elfelejthetjük (bár ez nem teljesen igaz, később fogjuk látni, hogy miért).
Régi értékek tárolása
Az adatbázison belül történik, az UNDO szegmensben.
UNDO szegmens
A régi értékek tárolására egy speciális szegmenst, úgynevezett UNDO szegmenst hozott létre az Oracle. Ezt úgy kell elképzelni, mint egy speciális táblát, amibe a régi érték automatikusan átkerül, amikor azt felülírom. Azonban az UNDO szegmens egy idő után megtelik, így nem tárolhatjuk itt végtelen ideig a régi adatokat. Szükség esetén a régi adatokat egy jel (pointer) segítségével tudjuk megtalálni, és visszavonáskor (ROLLBACK) innen másolja vissza az értéket az eredeti helyre. Amikor módosítottam a tábla adatait, akkor jó eséllyel az index adatai is módosultak, ebből kifolyólag például egy INSERT során akár több helyen is történhet módosítás, ezeknek mind meg kell jelenniük az UNDO szegmensben.
Ábra: http://slideplayer.hu/slide/2084841/8/images/32/A+visszag%C3%B6rget%C5%91+(Rollback)+szegmens.jpg
Az UNDO szegmens feladatai
Olvasási konzisztencia
Ha valaki olvasni szeretné a táblát (nevezzük Istvánnak a példa kedvéért), és az előtt adta ki a SELECT utasítást, hogy a módosító (őt hívjuk Lászlónak) jóváhagyta volna COMMIT-tal a módosítást, akkor István még a régi értéket fogja látni. Ez ugyan lassabb lesz, hiszen kell tenni egy "kitérőt", azonban elkerülhető vele az úgynevezett dirty read, ami téves adat olvasását jelenti. Istvánnak mindig a SELECT kiadásának pillanatában fennálló állapotot kell látnia, így ha ez a SELECT annyira hosszan tart, hogy közben László kiadja a COMMIT utasítást, és törlődik az UNDO szegmensből a "before image", akkor István SELECT-je hibaüzenetet kap eredményül.
Tranzakció helyreállítása
Az UNDO szegmensnek a valamilyen hibás működést követő helyreállításban is fontos szerepe van, erről a naplózás című részben írtam részletesebben.
Tranzakció "rollback"
Amikor a felhasználó kiadja a ROLLBACK utasítást, akkor az UNDO szegmensben az adott tranzakcióhoz tartozó bejegyzések visszakerülnek az eredeti helyre.
A párhuzamos feldolgozásból adódó hibák kiküszöbölésére az adatbázis-kezelő rendszerek zárakat használnak.
A módosításkor az adott sorok (nem feltétlenül sor szintű lockolást használnak, de ez a leginkább jellemző) zárolódnak, ennek fő célja meggátolni, hogy egyszerre többen módosítsák ugyanazt, és így inkonzisztens végeredmény keletkezzen, viszont nem akadályozza meg ezeknek a soroknak az olvasását.
Zárak jellemzői
Zárak időtartama
A zár általában az utasítás kiadásakor lép életbe, és a COMMIT/ROLLBACK
végrehajtásakor szűnik meg.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Zárak erőssége
A zár erőssége határozza meg, hogy más tranzakciók milyen módon használhatják a zárolt elemeket.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Módosítási zár
Update vagy U zár: A rekordot valamikor később esetleg meg akarjuk változtatni. A módosítás pillanatában az U zár átvált X zárba.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Kizárólagos zár
Exclusive vagy X zár: Más tranzakciók nem férhetnek hozzá az így zárolt elemekhez.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Osztott zár
Share vagy S zár: Bárki más olvashatja az így zárolt elemeket, de senki nem változtathatja meg őket.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Zárak mérete
"Minél nagyobb az elzárt terület, annál kevesebb zárra van szükségünk, annál kisebb rendszer adminisztrációt jelent a zárak nyilvántartása, de annál jobban csökken a párhuzamos feldolgozás lehetősége. Ezért a legtöbb rendszer észszerű kompromisszumként alapértelmezésben a feldolgozandó adatokat tartalmazó lapokat zárja el. Ez azonban
módosítható. A zár aktuális méretét az adatbázis-felügyelő
vagy a felhasználó esetenként maga is meghatározhatja. Ezt a zárat az adatbázis-kezelő rendszer automatikusan ráteszi az adatbázisnak a használatba vett (vagy használatba venni kívánt) részére,
illetve ha valamilyen okból nem tudja feltenni, akkor előjegyzésbe veszi a zárolási szándékot. Kivételt ez alól csak a táblázat szintű elzárás képez."
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Row lock
Az adatbázis kezelő rendszer elzárja a feldolgozandó adatokat tartalmazó sort (rekordot).
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Page lock
Az adatbázis kezelő rendszer elzárja a feldolgozandó adatokat tartalmazó lapot.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Table lock
Az adatbázis kezelő rendszer elzárja a feldolgozandó adatokat tartalmazó táblázatot.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Tablespace lock
Az adatbázis kezelő rendszer elzárja a feldolgozandó adatokat tartalmazó adathordozó logikailag összetartozó részét . Ezt általában
a szolgáltató programok használják, amikor nagy adatmennyiségek újraszervezésének, betöltésének zavartalanságát, megszakítás mentes végrehajtását kívánják biztosítani.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Database lock
Az adatbázis kezelő rendszer elzárja a teljes adatbázist. Ezt nemigen alkalmazzák, mert ez a párhuzamos feldolgozást lehetetlenné teszi.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Lock-ra várakozás
Ha a lock megakadályoz valakit a módosításban, akkor ő várakozni fog ("lock-ra fog várni"). A felhasználó ilyenkor tulajdonképpen egymásra várnak, kialakul egy sorrend, ezt "sorban állásnak" is nevezik. Addig kell várakoznunk amíg a sorban előttünk lévő tranzakció be nem fejeződik. Érdekesség, hogy egyes adatbázis kezelőkben paraméterezhető, hogy mennyi ideig várakozzak, és ha nem kerülök sorra, akkor egy hibaüzenetet kapok vissza.
Működési módok
Read committed
Az olvasó csak a jóváhagyott értékeket látja. Ez az Oracle alapvető működési módja, ettől szinte sosem térnek el, hiszen a Repeatable read működésnek túl nagy ára van.
Dirty read
Az olvasó jóváhagyott és nem jóváhagyott értékeket egyaránt láthat. Az Oracle-nél ez nem fordulhat elő.
Repeteable read
Egy olyan működési forma, amelyben újra és újra megismétlem a SELECT-et és garantáltan ugyanazt az eredményt fogom kapni. Így is tud működni az Oracle, de ennek az az ára, hogy a SELECT is zárolni akarja a táblát abból a célból, hogy garantáltan ugyanazt az eredményt kapja, ne tudják két SELECT között módosítani a táblát.
A patthelyzetek jelentik a legnagyobb veszélyt a párhuzamos feldolgozásban.Ezek akkor alakulhatnak ki,ha egyidejűleg futó tranzakciók kizárólagosan is lefoglalhatnak erőforrásokat, általában adatbázis lapokat vagy rekordokat. Ilyenkor két vagy több tranzakció vár olyan erőforrásokra, amelyeket egyikük kizárólagos módon zárolt, de nem tud
felszabadítani, mert ő maga is vár olyan erőforrásra, melyet egy másik tart zárva.
Példa: István 7 óra 30 perckor módosítja az 1111-es számú rekordot, X zárat tesz rá (X zár: kizárólagos zár, más tranzakciók nem férhetnek hozzá az így zárolt elemekhez). László 7 óra 32 perckor módosítja a 2222-es számú rekordot, X zárat tesz rá. 7 óra 35 perckor Istvánnak szüksége lenne a 2222-es rekordra, azonban nem fér hozzá László X zára miatt. Ezért István
vár egészen addig, amíg László nem véglegesíti a változtatásokat 2222-ben. Ez általában időben bekövetkezik. István némi várakozás után folytathatja munkáját. Balszerencsés esetben azonban Lászlónak 7 óra 36 perckor pont az 1111 kulcsú rekordra lenne szüksége. De ehhez nem férhet hozzá István X zárja miatt. Ezt István nem tudja felszabadítani, mivel vár a 2222
rekordra, amit viszont László nem tud szabaddá tenni.
A patthelyzetet teljesen kiküszöbölhetjük,
ha az adatbázisnak azokat a részeit,
melyeket a tranzakciók folyamán kizárólagosan
is akarunk használni, rögtön a feldolgozás
kezdetekor X zárral elzárjuk.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
István beolvassa 7 óra 30 perckor a krumpli adatait és azt látja, hogy az ára 100 forint és a 3-as kategóriában van. Ezután különböző számításokat végez a beolvasott adatokkal. Közben 7 óra 32 perckor László átsorolja a krumplit a 3-as kategóriából az 5-ös kategóriába. 7 óra 35 perckor István tovább dolgozik a krumpli általa 7 óra 30 perckor beolvasott rekordján, és azt látja, hogy a krumpli még mindig a 3-as kategóriában van, pedig László azt már átsorolta az 5-ös kategóriába. Ilyenkor az sem segítene István helyzetén, ha újra beolvasná a rekordot, hiszen nem tudná eldönteni, hogy az általa kapott eredmények a 3-as kategória feltételezésével érvényesek-e, vagy újra el kell végeznie a számításait az 5-ös kategória feltételezésével. Csak akkor folytathatná biztonsággal a munkáját, ha az újraolvasásnál meggyőződne arról, hogy senki nem változtatta meg a krumpli adatait a két beolvasás között.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
Ez akkor fordulhatna elő, ha például István módosítaná 7 óra 30 perckor a krumpli árát 100 forintról 80 forintra, azonban nem hagyná jóvá, hanem várna, László pedig 7 óra 32 perckor az új, de még nem jóváhagyott adattal dolgozna (tehát a 80 forintos árral), majd 7 óra 35 perckor István meggondolná magát, és ROLLBACK-kel visszavonná a módosítást, tehát a krumpli ára 100 forint maradna. Azonban László 7 óra 32 perckor a 80 forintos adattal dolgozott, ez mindenképpen gondot okozna, ezért az ilyen hiba előfordulását meg kell akadályozni.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
István 7 óra 30 perckor, László 7 óra 32 perckor beolvassa a krumpli adatait, és mindketten azt látják, hogy 100 forint és a 3-as kategóriába tartozik. Ezután István 7 óra 35 perckor módosítja a krumpli árát 80 forintra, és meghagyja a 3-as kategóriában, azonban eközben László is módosítja a krumpli adatait, ő a 100 forintos árat változatlanul hagyja, azonban átsorolja az 5-ös kategóriába. Ilyenkor az egyikük változtatása elveszik attól függően, hogy melyik következett be előbb.
Forrás: Quittner Pál és Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerek. Debrecen: Debreceni Egyetem Agrártudományi Centrum
A SELECT FOR UPDATE a SELECT-nek egy variánsa, amelyben nem csak elolvasni akarjuk az adatokat, hanem ezeket le is akarjuk zárni, mert a repeatable read érdekében azt szeretnénk, hogy ha megismételjük a SELECT-et, akkor ugyanazt az eredményt kapjuk. A SELECT FOR UPDATE utasítással tehát le is zárom a sorokat, ám elképzelhető, hogy ezek már le vannak lock-olva valaki más által, ilyenkor a SELECT FOR UPDATE várakozni fog arra, hogy a másik végezzen.
Van WAIT klauzula is, ami adott ideig várakozik, majd ha nem végez a másik addig az ideig, akkor kapok vissza hibaüzenetet.
Az ORACLE esetében a SELECT FOR UPDATE-nek van egy NOWAIT klauzulája, ezzel azt érhetjük el, hogy az utasításunk ne várakozzon lock-ra, hanem rögtön kapjunk vissza hibaüzenetet.
A SELECT-nek vagy a végeredmény nagyon nagy, vagy lehet esetleg a végeredmény normál méretű, de a részeredmények menet közben hatalmasak, ez utóbbi főleg adattárházak esetében gyakori. Az adatbázis kezelő ezeket a részeredményeket a memóriában próbálja tárolni, azonban a memória mérete véges. Ha a rendszer nem tud magának elég memóriát találni, akkor ezeket a részeredményeket visszaírja a disk-re, de a disk-en is véges mennyiségű terület van, és ha a felhasználó olyan SELECT-et írt, aminek ennyi hely sem elég, akkor az hibaüzenettel ér véget.
Az UNDO szegmenshez hasonlóan ez is ideiglenes adatokat tárol, csak nem a tranzakciók before image-ét, hanem a SELECT utasítások részeredményit, és ezt egy úgynevezett temporális táblatérbe írja az Oracle, ha a memóriába nem fér be. A temporális táblatérnek is van egy véges mérete.
Az olvasási konzisztencia miatt jelentkezhet, az István által kiadott SELECT olyan sokáig eltarthat, hogy közben László jóváhagyta a módosítást, azonban Istvánnak még ebben az esetben is a SELECT kiadásának pillanatában lévő állapotot kellene látnia, de elképzelhető, hogy az olvasási folyamat olyan sok időt vesz igénybe, hogy addigra már felülíródott az UNDO szegmensben lévő érték (before image), ebben az esetben a SELECT, amit István kiadott, hibaüzenettel végződik. Ez a leggyakoribb forgatókönyve egy sikertelen SELECT-nek.
Egyes adatbázis kezelő rendszerek nemcsak előre, hanem időben visszafelé is képesek görgetni az eseményeket, az Oracle-nél ezt „Flashback Database”-nek hívják, ezt úgy tudjuk elképzelni, mint egy időutazást, az adatbázist gyakorlatilag előre és hátra lehet navigálni az időben, jó néhány ügyfél így próbálja a hibás működést meg nem történtté tenni. A Flashback Database luxus lehetőség és további beállítást igényel. Ezt nem szabad összekeverni a Flashback Query-vel, ami nem luxus lehetőség, ugyanis mindig működik, amíg rendelkezésre állnak az UNDO adatok. A Flashback Query az UNDO adatokat használja,ez a SELECT-nek egy furcsa szintaxisa, lehetővé teszi, hogy ne a SELECT pillanatában fennálló állapotot lássam, hanem egy korábbi időpont adatait tudjam olvasni (például 8 órakor láthassam a 7:30-as állapotot). Túl régi adatokat azonban ezzel nem tudok olvasni, hiszen minél távolabbra szeretnék visszamenni az időben, annál valószínűbb, hogy az akkori UNDO adatok már felülíródtak.
A cache-elés során a naplózás garantálja azt, hogy nem veszítünk adatot. A cache-elés a memóriában zajlik, amikor egy értéket módosítok és kiadom a COMMIT utasítást, még akkor sem garantált, hogy azonnal visszaíródik a data file-ba, hanem csak egy idő után írja vissza a database writer a módosított blokkokat a data file-okba. Ennek ellenére garantált, hogy a COMMIT-ált módosítás jóvá lesz hagyva, a naplózásnak (az Oracle-ben ezt redo logging-nak nevezik) köszönhetően, ugyanis a Log Writer a napló pufferből az összes időközben összegyűlt módosítást kiírja a Redo Log File-okba, illetve a COMMIT rekordot is kiteszi a Redo Log File-ba, amint a Redo Log File-ba, a disk-re került a napló, onnantól garantáltan nem veszik el az adat. A naplóbejegyzés legkésőbb a COMMIT utasítás kiadásakor kikerül a lemezre.
A naplóállomány nem őrzi korlátlan időre visszamenőleg az adatokat, jellemzően az utolsó 10-20-30 perc adatai találhatóak meg benne, hiszen a Redo Log File-ok kapacitása is véges. Ez áramszünet elleni védettségben azonban így is elegendő a helyreállításhoz, hiszen a data file-ok általában 1-2 perc késéssel megkapják az adatot a database buffer cache-től, tehát valójában a naplóból is csak az utolsó néhány perc adataira van feltétlenül szükség egy áramszünet utáni helyreállításhoz.
A naplóadatok azonban önmagukban nem védenek meg minket az adatfájlok vesztésétől. Amennyiben úgynevezett "disk crash" történik, akkor elvesznek a data file-ok is, ez megengedhetetlen, hiszen itt vannak a legfontosabb adatok.
Helyreállítás
Rendelkezésre áll egy régebbi mentés, illetve be van kapcsolva az archiváló üzemmód, ennek köszönhetően rendelkezünk az archív redo log file-ok egy szériájávál a legutóbbi mentéstől egészen mostanáig.
Helyreállítás lépései
Mentett adatok visszamásolása
Visszamásoljuk a mentett fájlt a megfelelő helyre, azonban ez önmagában nem elegendő, hiszen a mentés pillanatában fennálló állapotnak megfelelő értékeket tartalmazza.
Rollforward recovery
Ezután következik az úgynevezett „Rollforward recovery”, vagyis időrendi sorrendben rájátsszuk a mentés óta az összes naplóbejegyzést az archivált redo log file-okból, majd az online redo log file-okból, így megnyitható az ily módon helyreállított adatfájl, és így már az aktuális adatokat láthatjuk.
Rollback recovery
A naplóbejegyzésekbe bekerültek olyan UPDATE-ek is, melyeknek a végén nincs COMMIT, így az adatbázis ebben a pillanatban a nem COMMIT-ált adatot is tartalmazza, azonban ez nem jelent gondot, mert az előregörgetés (Rollforward recovery) során az adatbázis kezelő nemcsak a táblákat, hanem az UNDO szegmenst is felépítette, így az UNDO adatokat is görgetjük előre, melyekre a helyreállítás kiadja a ROLLBACK parancsot, így az adatbázisban csak a jóváhagyott adatok lesznek.
Lemezhiba elleni védelem
Archiválás
Mivel a mentés önmagában nem elegendő, ezen kívül még meg kell akadályozni az online naplóállományok tartalmának elveszítését, Oracle esetén ezt archiválásnak nevezzük. Ehhez be kell iktatni egy archiváló processzt.
Mentések
Időnként le kell menteni az adatbázis fájljait. Azonban a mentés önmagában nem elegendő, hiszen ez csak arra jó, hogy egy lemezhiba esetén vissza tudjam állítani a mentés pillanatában fennálló állapotot.
Ha például egy áramszünet, vagy egyéb ok miatt a rendszer összeomlik, a naplózás akkor is védelmet nyújt, ugyanis az újraindításkor a rendszert újraindító processzek észreveszik, hogy a naplóállományban több tartalom van, mint az adatállományban, az elinduláskor naplóban lévő többlet adatot az adatbáziskezelő automatikusan végigolvassa és rájátssza az adat file-okra. Tehát mire a felhasználó bejelentkezik, a megfelelő értékek a helyükön vannak. A cache-elésnek tehát nem kell figyelnie a tranzakció kezelésre, ami így egy teljesen független folyamat lehet.
A naplózás kezdetben a memóriába íródik egy ciklikus pufferbe (Oracle-nél ez Redo Log Buffer-nek nevezik), de később a COMMIT ezt kiírja a lemezre, és innentől kezdve vagyunk védettek. Az Oracle adatbázis esetén ez egy külön fájltípus a lemezen: Redo Log File, egészen pontosan Online Redo Log File.
Bináris adatok íródnak be a naplókba.
A Log Writer nevű háttérprocessz időnként (ezt úgy kell érteni, hogy elég gyakran) a Redo Log Buffer-ben lévő bejegyzéseket kiírja a Redo Log File-ba. Redo Log File-ból több is van, ezek is ciklikusan íródnak, azonban ez a ciklus nagyobb, mint a Redo Log Buffer-é.
Amikor a felhasználó módosít valamit, arról bináris bejegyzés (úgynevezett naplóbejegyzés) készül, ami a Redo Log Buffer-be íródik. Ez egy ciklikus memóriaszerkezet, amit a különböző felhasználók töltenek fel különböző módosításokkal.
A cache-elés és a tranzakciókezelés (ide tartozik az UNDO kezelése is) egymásra ortogonális jelenségek, vagyis egy időben zajlik a két tevékenység, de függetlenek egymástól.
A tábla és az UNDO szegmens egyaránt az adatbázis kezelő rendszerben vannak a disc-en, és ezek cache-elődnek. Az adatbázis kezelő szoftvernek van egy gyorsítótára, amelyben a gyakran használt adatokat memóriákon kezeljük. Az UNDO szegmenst felfoghatjuk egy speciális táblaként, ami ugyanúgy cache-elődik, mint az igazi tábla. Az adatbázisban lévő data file-okban vannak a hasznos adataink, ilyen hasznos adat a tábla, illetve az UNDO szegmens is. Az adatblokk gyorsító (database buffer cache) a data file-ok tartalmának a cache-elésére szolgál (ez az előadáson elhangzott példa alapján azt jelenti, hogy a data file-okban 1 terabyte van, a cache-ben pedig 10 gigabyte, ilyenkor minden századik adatot, a gyakran használtakat, a memóriában tároljuk). A database buffer cache-ben találhatóak tábla, illetve UNDO blokkok is. Amikor a felhasználó módosítanak akkor valójában nem a data file-ban módosítanak, hanem a cache-ben, és a database writer nevű háttérprocessz írja vissza a módosított tartalmakat a data file-ba.
