1
2
Trankzakció • Több lépésből álló adatmódosító műveletek • Párhuzamosan több ilyen művelet fut • Atomicity ▫ A tranzakciók vagy teljes egészében lefutnak, vagy egyáltalán nem okoznak változást (mindent vagy semmit)
• Consistency ▫ Az adatbázist a tranzakció konzisztens állapotból konzisztensbe viszi
• Isolation ▫ A párhuzamos tranzakciók csak kontrolláltan interferálhatnak
• Durability (tartósság) ▫ Ha egy tranzakció készre lett jelentve, akkor az többet nem vonható vissza
3
Példa tranzakcióra • Bankszámla terhelése egy másik javára • Először ellenőrizni kell, hogy van-e elég fedezet • Eközben valaki más terhelheti ugyanazt a számlát!
CREATE PROC CreditDebit @sourceID int, @destID int, @amount numberic AS DECLARE @balance numeric SELECT @balance = balance FROM Account WHERE ID = @sourceID IF (@balance < @amount) ROLLBACK ELSE BEGIN UPDATE Account SET balance = balance - @amount WHERE ID = @sourceID
• Végeredmény lehet: ▫ Commit (érvényesített) ▫ Rollback (érvénytelen) ▫ Abort (ütközés)
UPDATE Account SET balance = balance + @amount WHERE ID = @destID COMMIT END
4
Izolációs szint • Mennyire engedjük meg a tranzakciók interferenciáját ▫ Az adatbázis mikori állapota látszik a tranzakció során? A tranzakció indításának megfelelő állapot Változhat, ahogy a konkurens tranzakciók módosítják
▫ Olvasható-e más tranzakció által írt módosítás? Bármilyen módosítás olvasható Csak olyan módosítás, amit egy konkurens tranzakció már érvényesített
▫ Milyen típusú módosítások vannak hatással a többi konkurens tranzakcióra Meglevő sor értékének módosítása Sor beszúrása, törlése
5
Tranzakciók izolálása • Cél: konkurens műveletek párhuzamos futtatása úgy, hogy az adatok konzisztensek maradjanak • Két fő megvalósítási lehetőség: ▫ Adatok zárolása: LOCK Megosztott olvasási, exkluzív írási stb. Sorra, page-re, intervallumra, táblára, DB-re stb.
▫ Adatok ellátása verziószámmal Módosításkor új verziószámmal új sor jön létre Commitnál ellenőrizhető az ütközés
6
Fantom olvasás • A tranzakciók izolálása általában sor szinten történik ▫ ▫
Gyorsabb működése Kevesebb ütközés
• Mi van, ha egy query sok sort olvas a táblából… ▫ ▫ ▫
SELECT COUNT(*) FROM megrendelés SELECT SUM(egyenleg) FROM számlák Nem csak aggregált esetében fordulhat elő!
• … és közben egy másik tranzakció beszúr a táblába egy új sort vagy töröl egy meglevőt? • Ugyanaz a query kétszer egymás után nem ugyanazt az eredményt adja vissza • Ha el akarjuk kerülni, nem elég a sor szintű zárolás!
7
Tranzakciók izolációs szintjei •
READ UNCOMMITED ▫
•
READ COMMITED ▫
•
A SELECT által egyszer már olvasott sorokat a többi tranzakció nem módosíthatja. A SELECT kétszer egymás után futtatva ugyanazt az eredményt adja, viszont fantom olvasás előfordulhat.
SERIALIZABLE ▫
•
A SELECT által egyszer már olvasott sorokat más tranzakció módosíthatja. Olvasáskor csak befejezett tranzakciók által írt adat látszik. A SELECT kétszer egymás után futtatva adhat különböző eredményt. Fantom olvasás előfordulhat.
REPEATABLE READ ▫
•
Nem befejezett tranzakciók által írt adatot is olvashat (dirty read)
Az összes tranzakció úgy fut, mintha egy szálon, egymás után futnának. Nem lehet fantom olvasás.
SNAPSHOT ▫ ▫
Az előbbiekkel szemben ez LOCK helyett verziószámokat használ Jobb konkurens teljesítmény
8
Tranzakciós szintek összehasonlítása Szint
READ UNCOMMITED READ COMMITED REPEATABLE READ SERIALIZABLE
Piszkos olvasás
Nem megismételhető olvasás
Fantom sorok
X
X
X
X
X X
9
Objektumok zárolása - LOCK • Objektumok: ▫ Sor (ROW) SELECT adat FROM tábla WHERE ID = 12
▫ Lap (PAGE) ▫ Tartomány (RANGE) SELECT adat FROM tábla WHERE dátum BETWEEN régen AND most A lock az index egy vagy több során jelenik meg
▫ Tábla (TABLOCK) SELECT adat FROM tábla
10
Holtpont (dead-lock) • Az A és B folyamatnak egyaránt szüksége van az E1 és E2 erőforrásokra ▫ A az erőforrásokat E1-E2 sorrendben zárolja ▫ B az erőforrásokat E2-E1 sorrendben zárolja ▫ Kölcsönösen vár egymásra a két folyamat
• Feloldása: sorba kell rendezni az erőforrásigényeket ▫ SQL Server a legtöbb esetben megoldja
• Ha nem lehet feloldani a holtpontot, akkor valamelyik folyamat hibaüzenetet kap ▫ Holtponti áldozat = dead-lock victim
11
Tranzakció sikertelensége • • • •
Hardver hiba Rendszer hiba (hálózati hibák stb.) Adatbázis hiba (pl. nincsen elég hely) Alkalmazás hiba (rosszul írtuk meg a programot)
• Direkt ROLLBACK utasítás • Ütközés miatti Abort • Dead-lock áldozat
12
13
Biztonsági mentés (back-up) •
Adatbázis-szerverek alapvető biztonsági funkciója ▫ ▫ ▫
•
Hardver és szoftver meghibásodások kijavítására Meghibásodás esetén egy korábbi állapot visszaállítható On-line művelet, nem kell lekapcsolni hozzá az adatbázist
A teljes adatbázis mentése nagyon sok idő ▫ ▫
Teljes mentés ritkábban Inkrementális mentés sűrűbben
•
csak a legutóbbi mentés óta eltelt változások
Visszaállításhoz kell: ▫ ▫
Legutóbbi teljes mentés Összes azóta készült inkrementális mentés
•
Visszaállítás közben a DB elvileg működhet
•
Mi van azokkal a módosításokkal, amik a legeslegutolsó mentés óta történtek?
Tranzakciós napló
Utolsó biztonsági mentés
14
Tranzakciós napló t1 t2 (most)
15
Tranzakciós napló • Minden változást egy naplófájlban jegyzünk fel • Biztonsági mentéskor a napló üríthető • Visszaállításkor: ▫ biztonsági mentés visszaállítása ▫ tranzakciós napló futtatása adott időpontig
• Biztonsági mentés ▫ általában lassú, tömörítés, szalagra stb.
• Tranzakciós napló ▫ Gyors, diszkre ▫ A tranzakció csak akkor érvényesíthető, ha a naplóba már bekerült
16
Visszaállítási modellek • A tranzakciós napló írása erőforrást igényel • Mennyire kell szigorúan írni a tranzakciós naplót? • Különböző visszaállítási módok: ▫ FULL Teljes napló készül az adatmódosító műveletekről
▫ SIMPLE Nem készül tranzakciós napló a műveletekről Nekünk legtöbbször ez kell tudományos adatokhoz
▫ BULK-LOGGED Nagy mennyiségű adat betöltésekor minimális naplózás, egyébként részletes napló
17
Minimális naplózás • Az ACID D-je (durability) megköveteli, hogy bármilyen művelet sikertelensége esetén visszaállítható legyen az eredeti állapot • Adatbetöltéskor sok problémát okoz ▫ Minden sort kétszer kell beírni? ▫ Egyszer a táblába, egyszer a naplóba?
• Ha új lapokat kezd a szerver, akkor elég csak a lapok azonosítóját naplózni! • A minimális naplózásnak sok feltétele van, de hasznos, ld. később az adatbetöltéseknél
18
Replikáció • Az adatbázis egy részének (vagy egészének) lemásolása egy másik adatbázisba • Meghatározott időnként szinkronizálás • Nem biztonsági mentésre való • Pl. laptop-on el lehet vinni az ügynök számára fontos adatokat, másnap reggel tud szinkronizálni stb.
19
Adatbázis tükrözés • Csak full recovery model esetében ▫ Tudományos célra nem lesz jó
• Meghibásodás esetén a másik gép automatikusan átveszi a kiszolgálást • Azonnali szinkronizációt igényel a két gép között • Valójában csak a tranzakciós napló utazik a hálózaton, és a slave gépen az kerül lefuttatásra • Egyes adatbázisok külön-külön tükrözhetők • Szoftveres megoldás
20
Fail-over cluster • Hardveres megoldás • Speciális megosztott tárterületet igényel • Kettő vagy több gép használja a kettő vagy több közös, megosztott tárterületet • Kívülről az egész klaszter egy szerverként látszik
