DBMS felépítése

Lekérdezés megválaszolása

Lekérdezésfordító

Elemez és optimalizál

Végrehajtómotor

Kissebb adategységekre (jellemzően rekordokra) vonatkozó kérdések sorozatát adja át

Erőforrás-kezelő

Ismeri:

• a relációkat tartalmazó adatfájlokat
• a fájlok rekordjainak formátumát és méretét
• az indexfájlokat

Az adatkéréseket az erőforrás-kezelő lefordítja lapokra (blokkokra), amiket rovábbad

Pufferkezelő

Feladata a másodlagos adattárolón (általában lemezen) tárolt adatok megfelelő részét a központi memória puffereibe töltése

A pufferek és lemez közti adatátvitel egysége általában egy lap, vagy egy lemezblokk

A pufferkezelő információt cserél a tárkezelővel, hogy megkapja az adatokat a lemezről

Előfordulhat, hogy a tárkezelő OS rendszerhívásokat használ, de jellemzően a DBMS a parancsait közvetlenül a lemezvezérlőhöz intézi

Tranzakció feldolgozása

Feldolgozó két fő része:

• Ütemező - scheduler
  • Konkurenciavezérlés-kezelő
  • a tranzakciók elkülönítésének és atomosságának biztosítására
• Naplózás és helyreállítás-kezelő
  • tranzakciók atomosságáért és tartósságáért felelős

Feldolgozó 3 fő feladata:

• naplózás
• konkurenciavezérlés
• holtpont feloldás

Naplózás

• A tartósság fenntarthatóságáért minden változtatást naplózunk
• A naplókezelő (log manager) választ eljárásmódot, amit követni fog
• Az eljárásmódok biztosítják, hogy bármikor is történik a rendszerhiba vagy teljes összeomlás, a helyreállítás-kezelő vissza tudja állítani DB-t a legközelebbi konzisztens állapotra a napló alapján
• A naplókezelő először a pufferbe naplózik, és egyeztet a pufferkezelővel, hogy a pufferek alkalmas időpillanatban garantáltan íródjanak ki a lemezre, ahol az adatok már túlélik a rendszer összeomlását

Konkurenciavezérlés

• A tranzakcióknak elkülönítettnek, függetlennek kell látszódnia
• Az ütemező dolga meghatározni az összetett tranzakciós tevékenységek egy olyan sorrendjét:
  • Amely sorrend követésével az elemi tevékenységek összhatása a tranzakciók atomi futtatásának sorrendjével egyenértékű lesz

$$ \blue{T_1:~~u_1;~u_2;~\cdots~;~u_n} \ \green{T_2:~~v_1;~v_2;~\cdots~;~v_m} \

T:~~\blue{u_1};~\green{v_1};~\green{v_2};~\blue{u_2};~\blue{u_3};~\cdots~;~\green{v_m};~\blue{u_n} $$

A saját utasításainak sorrendje változatlan marad

Ekkor olyan állapot is létrejöhet, ami nem lett volna teljes atomiság esetén

• Az ütemező jellemzően zárakkal akadályozza meg a helytelen I/O értékek kialakulását
• Az ütemező tiltja meg a végrehajtómotornak, hogy a zártábla (lock-table) által lezárt részekhez hozzáférjen

Holtpont feloldás

• A zárak versenyhelyzetet alakítanak ki, esetleg teljes deadlock-ot
• A tranzakciókezelő feladat közbeavatkozni
  • Tehát addig abortál tranzakciókat, amíg a deadlock fel nem oldódik

Konzisztenci sérülés potenciális okai

• Skill Issue✨
  • A DBMS valamely komponense nem, vagy rosszul működik
• Tranzakcióhiba
  • Hibásan megírt, rosszul ütemezet, félbehagyott tranzakciók
• Hardverhiba
  • Adatvesztés, random memória korrupció

• Adatmegosztásból származó hiba
  • T1: 10% fizetésemelés mindenkinek
  • T2: minden Fejlesztő-t nevezzünk át Senior Programozó-ra

Helyreállítás

• Meghibásodási modell definiálása
• Események osztályozása
  • Szabályos
  • Kivételes
    • Előrelátható
    • Nem várt

Szabályos esemény

Az, ami "a felhasználói kézikönyv alapján kezelhető"

Előrelátható, kivételes esemény lehet

• Rendszerösszeomlás
  • Elszáll a memória
  • Leáll a CPU, újraindultunk

Hibás adatbevitel

• Tartalmi hiba
  • Gyakran nem észrevehető, mert a formaiságát még tartja az adat
  • Bro, did you just typo in MY DB?, how dare you??!
• Formai hiba
  • pl.: kevés számjegy egy telefonszámban
  • Jellemzően kulcsokkal és megszorításokkal kiküszöbölhető

További triggerek még segíthetnek a hibás adatbevitel elkerülésére

Készülékhibák

• Kis hiba
  • Lemezegység egy olyan hibája, hogy egy bit vált
    • Paritás-ellenőrzés megbízhatóan felismeri egy bizonyos fokig
• Nagy hiba
  • Lemezegység jelentős sérülése, paritással nem javítható
  • I/O fej katasztrófái, akár teljes olvashatatlanság

Nagy hibák csak fizikailak kerülhetőek el

RAID

• Redundant Array of Independent Disks
• Teljes lemezkatasztrófa is kijavítható
• Jobb RAID-el akár több lemez együttes elpusztulása sem okoz adatvesztést

Archiválás

• DB egy külső, off-line másolata
• Teljes, vagy inkrementális
• "A mentett anyagot az adatbázistól biztonságos távolságban kell tárolnunk"

Osztott másolat

• DB egy elosztott, on-line másolata
• Figyelni kell a másolatok konzisztenciájára

Katasztrófális hibák

• Azok a helyzetek, amikor a DB-t tartalmaző eszköz megsemmisül
  • Robbanás, Tűz, vandalizmus, vírus
• RAID nem segít, mert az lokális mirror (szóval az is kuka)
• Paritás ellenőrzéshes sok sikert lol
• A másik kettő megoldás még működni fog (remélhetőleg)

Rendszerhibák

• Minden tranzakciónak van egy állapota, ami megadja, hogy mi történt eddig a tranzakcióban
  • Tartalmazza
    • a végrehajtás pillanatnyi helyét a tranzakció kódjában
    • a végrehajtás minden lokális változójának értékét
  • A rendszerhibák ezen álapotok elvesztését okozzák
• Áramkimaradás és szorfverhibák tipikusak
  • Memóriakorrupciót okozhat
  • Nyilván nem tudhatjuk, hogy hagytuk abba, vagy hogy az állapotunk mely része érintetlen
  • A tranzakció újbóli lefuttatása nem biztos, hogy megoldja
    • Lásd ++

Megoldás: egy elkülönült, nem illékony naplófájl nyilvántartása

Ehhez hibavédett Naplózási mechanizmusra van szükség

Nem várt, kivételes esemény

MINDEN MÁS