PA152: Efektivní využívání DB 11. Zotavení z chyb Vlastislav Dohnal PA152, Vlastislav Dohnal, FI MUNI, 2014 2 Integrita nebo správnost dat  Chtěli bychom, aby data byla stále „bezesporná“ a „správná“. Jméno Novák Starý Svoboda Věk 52 3421 1 Zaměstnanci PA152, Vlastislav Dohnal, FI MUNI, 2014 3 Integrita nebo správnost dat  Integritní omezení Hlavní nástroj integrity DB Predikáty, které musí data splňovat  Příklady: x je primární klíč relace R Funkční závislost: x  y Doména(x) = {červená, modrá, zelená} a je platná hodnota atributu x v R (cizí klíč) Žádný zaměstnanec by neměl mít záporný plat. PA152, Vlastislav Dohnal, FI MUNI, 2014 4 Integrita nebo správnost dat  Konzistentní stav splňuje všechna omezení  Konzistentní DB DB v konzistentním stavu PA152, Vlastislav Dohnal, FI MUNI, 2014 5 Limity integritních omezeních  Nemusí zajistit „plnou správnost“  Příklady: (Transakční omezení) Žádný zaměstnanec by neměl mít více než dvojnásobek průměrného platu. Pokud měníme plat, nový plat > původní plat Pro smazání bankovního účtu musí platit balance = 0 PA152, Vlastislav Dohnal, FI MUNI, 2014 6 Limity integritních omezeních  Některé z nich mohou být „emulovány“ pomocí standardních omezení Smazání účtu nahradit příznakem smazání č.ú. … zůstatek smazanýúčet PA152, Vlastislav Dohnal, FI MUNI, 2014 7 Limity integritních omezeních  Databáze by měla odpovídat skutečnému světu.  Prováděj kontrolu existujících podmínek  přestože některé prvky „reality“ nelze definovat podmínkou omezení nebo DB není identická realitě  Pozorování  DB nemůže být konzistentní stále. DB Realita PA152, Vlastislav Dohnal, FI MUNI, 2014 8 Příklad nekonzistentního stavu  Příklad omezení a1 + a2 +…. an = TOT  Aplikace provádí vložení 100 Kč na účet a2 a2  a2 + 100 TOT  TOT + 100 . . 50 . . 1000 . . 150 . . 1000 . . 150 . . 1100 a2 TOT PA152, Vlastislav Dohnal, FI MUNI, 2014 9 Řešení průběžných nekonzistencí  Transakce Soubor akcí udržujících konzistenci Konzistentní DB Konzistentní DB’ T PA152, Vlastislav Dohnal, FI MUNI, 2014 10 Transakční zpracování  Předpoklad Pokud T začíná v konzistentním stavu a T běží samostatně  T končí také v konzistentním stavu  Správnost Pokud přerušíme běžící transakci, DB zůstane konzistentní Každá transakce vidí konzistentní DB PA152, Vlastislav Dohnal, FI MUNI, 2014 11 Porušení konzistence  Příčiny Chyba transakce Chyba DB systému Výpadek hardwaru  Např. výpadek úložiště poruší stav účtu na disku Sdílení dat  Např. T1: přidej 10% platu programátorům T2: změň programátor  systémový analytik PA152, Vlastislav Dohnal, FI MUNI, 2014 12 Zajištění konzistence  Model výpadků Shromáždění možných rizik Řešíme výpadky jednotlivých komponent CPU M Dpaměť procesor disk sběrnice PA152, Vlastislav Dohnal, FI MUNI, 2014 13 Zajištění konzistence  Model výpadků Kategorizace událostí (rizik) události žádoucí nežádoucí předpokládané nepředpokládané PA152, Vlastislav Dohnal, FI MUNI, 2014 14 Zajištění konzistence  Události Očekávané  Viz manuál DB systému  Nežádoucí očekávané  Ztráta obsahu paměti  Zastavení procesoru, reset procesoru  Násilné vypnutí počítače Nežádoucí neočekávané (vše ostatní)  Ztráta dat na disku  Chyba paměti bez zastavení procesoru  Živelné pohromy, … PA152, Vlastislav Dohnal, FI MUNI, 2014 15 Model výpadků  Přístup k omezení rizik Přidání kontrol na nejnižší úrovni Redundance zvýší pravděpodobnost zachování podmínek  Např. Stabilní uložení dat (replikace disku, RAID) Lepší paměť (kontrola paritní, ECC) Kontrola CPU PA152, Vlastislav Dohnal, FI MUNI, 2014 16 Model výpadků  Soustřeďujeme se na organizaci paměti  Klíčový problém Nedokončené transakce Příklad Paměť x x Disk Omezení: A=B Transakce T1: A  A  2 B  B  2 PA152, Vlastislav Dohnal, FI MUNI, 2014 17 Transakce  Základní operace Input (x): blok obsahující x  paměť Output (x): blok obsahující x  disk Read (x,t): a. Input(x), pokud je potřeba b. t  hodnota x v bloku Write (x,t): a. Input(x), pokud je potřeba b. hodnota x v bloku  t PA152, Vlastislav Dohnal, FI MUNI, 2014 18 Příklad transakce T1 T1: Read (A,t); t  t  2; Write (A,t); Read (B,t); t  t  2; Write (B,t); Output (A); Output (B); A: 8 B: 8 paměť disk 16 A: 8 B: 8 16 výpadek! 16 PA152, Vlastislav Dohnal, FI MUNI, 2014 19 Transakce  Atomičnost Řešení problému nedokončených transakcí Provedení všech akcí transakce nebo vůbec žádné  Jak implementovat? Logování provedených změn  Tj. vytvoření žurnálu (souboru se záznamy o změnách) PA152, Vlastislav Dohnal, FI MUNI, 2014 20 Žurnálování  Běh transakce produkuje záznamy o změnách do žurnálu Začátek, konec, uložení, aktualizace, …  Využití Výpadek systému  znovu provedení/zrušení změn podle žurnálu Obnova dat z archivu  znovu provedení změn podle žurnálu PA152, Vlastislav Dohnal, FI MUNI, 2014 21 Žurnálování  Při obnově Některé transakce se provedou znovu  REDO Některé transakce se zruší  UNDO PA152, Vlastislav Dohnal, FI MUNI, 2014 22 Undo logging  „Zrušení podle žurnálu“  Pokud není 100% jistota uložení změn dokončené transakce Pak se změny podle žurnálu odstraní  Tj. obnovení předchozího stavu DB  Transakce nikdy nebyla spuštěna  Vlastnost Změny prováděné transakcí jsou ihned ukládány na disk PA152, Vlastislav Dohnal, FI MUNI, 2014 23 Undo logging: Transakce T1 Read (A,t); t  t  2; Write (A,t); Read (B,t); t  t  2; Write (B,t); Output (A); Output (B); A: 8 B: 8 paměť disk A: 8 B: 8 16 žurnál 16 16 16 T1: Pozn: vyžadujeme platnost A=B PA152, Vlastislav Dohnal, FI MUNI, 2014 24 Undo logging  Komplikace Žurnálování používá správce vyrovnávací paměti  tvořen v paměti, později uložen. A: 8 16 B: 8 16 Log: A: 8 B: 8 16 CHYBA # 1 paměť disk žurnál PA152, Vlastislav Dohnal, FI MUNI, 2014 25 Undo logging  Komplikace Žurnálování používá správce vyrovnávací paměti  tvořen v paměti, později uložen. A: 8 16 B: 8 16 Log: A: 8 B: 8 16 CHYBA # 2 paměť disk žurnál ... PA152, Vlastislav Dohnal, FI MUNI, 2014 26 Undo logging  Pravidla 1. Pro každou akci vytvoř v žurnálu záznam obsahující starou hodnotu 2. Před změnou x na disku musí být na disku záznamy žurnálu týkající se x  Tzv. write ahead logging (WAL) 3. Před vytvořením záznamu v žurnálu musí být všechny zápisy transakce uloženy na disku. PA152, Vlastislav Dohnal, FI MUNI, 2014 27 Undo logging – obnova po výpadku  Pro každé Ti , které má v žurnálu: Pokud existuje nebo , nedělej nic Jinak pro každé v žurnálu:  write(X, v)  output(X)  zapiš do žurnálu Je to správně? PA152, Vlastislav Dohnal, FI MUNI, 2014 28 Undo logging – obnova po výpadku 1. S = množina transakcí  Které mají v žurnálu,  ale nemají ani 2. Pro každé v žurnálu  Proveď v obráceném pořadí (nejnovější  nejstarší)  Pokud Ti  S, pak write(X, v) a output (X) 3. Pro každé Ti  S  zapiš do žurnálu PA152, Vlastislav Dohnal, FI MUNI, 2014 29 Undo logging – obnova po výpadku  Výpadek během obnovy Nevadí  UNDO lze provést i opakovaně (je idempotentní)  Provádí se pouze pro nedokončené transakce PA152, Vlastislav Dohnal, FI MUNI, 2014 30 Redo logging  „Znovu provedení podle žurnálu“  Vlastnost Změny provedené transakcí jsou ukládány později  Tj. při potvrzení (commit)  Ušetření zápisů na disk Při obnově jsou ignorovány nedokončené transakce Vyžaduje uložení žurnálu před uložením změn v DB.  Žurnálují se nové hodnoty PA152, Vlastislav Dohnal, FI MUNI, 2014 31 Redo logging: Transakce T1 Read (A,t); t  t  2; Write (A,t); Read (B,t); t  t  2; Write (B,t); Output (A); Output (B); A: 8 B: 8 paměť disk A: 8 B: 8 16 žurnál 16 16 16 T1: PA152, Vlastislav Dohnal, FI MUNI, 2014 32 Redo logging  Pravidla 1. Pro každou akci vytvoř v žurnálu záznam obsahující novou hodnotu 2. Před změnou x na disku (v DB) musí být na disku všechny záznamy žurnálu (včetně commit) pro transakci měnící x 1. Ulož záznamy žurnálu na disk 2. Ulož změněná data na disk 3. Zapiš end do žurnálu PA152, Vlastislav Dohnal, FI MUNI, 2014 33 Redo logging – obnova po výpadku  Pro každé Ti , které má v žurnálu, proveď: Pro každé v žurnálu proveď:  write(X, v)  output(X) Je to správně? PA152, Vlastislav Dohnal, FI MUNI, 2014 34 Redo logging – obnova po výpadku 1. S = množina transakcí  Které mají v žurnálu,  ale nemají 2. Pro každé v žurnálu  Proveď v dopředném pořadí (nejstarší  nejnovější)  Pokud Ti  S, pak write(X, v) a output (X) 3. Pro každé Ti  S  zapiš do žurnálu Combining Records  Want to delay DB flushes for hot objects PA152, Vlastislav Dohnal, FI MUNI, 2014 35 Say X is branch balance: T1: ... update X... T2: ... update X... T3: ... update X... T4: ... update X... Actions: write X output X write X output X write X output X write X output X combined (checkpoint) PA152, Vlastislav Dohnal, FI MUNI, 2014 36 Redo logging – obnova po výpadku  Ukládání změn output(X) Pokud je více transakcí měnících X, pak stačí provést output(X) pouze pro poslední záznam v žurnálu Také záznam end lze zkombinovat pro více transakcí PA152, Vlastislav Dohnal, FI MUNI, 2014 37 Redo logging – obnova po výpadku  Obnova je velice pomalá ... ... ... Výpadek První záznam (1 rok starý) T1 zapíše A,B Potvrzeno před rokem  STÁLE potřebujeme pro obnovu! Poslední záznam PA152, Vlastislav Dohnal, FI MUNI, 2014 38 Žurnálování – obnova po výpadku  Řešení pomalosti  kontrolní body (checkpoints)  Implementace: 1. Přestaň přijímat nové transakce 2. Počkej na ukončení všech transakcí 3. Ulož všechny záznamy žurnálu na disk 4. Ulož všechny bloky na disk (DB) 5. Zapiš záznam „checkpoint“ na disk do žurnálu 6. Pokračuj ve zpracování transakcí PA152, Vlastislav Dohnal, FI MUNI, 2014 39 Žurnálování – obnova po výpadku  Postup při obnově Vyhledej poslední kontrolní bod Od něj proveď obnovu  Příklad redo log: Checkpoint ... ... ... ... ... ... PA152, Vlastislav Dohnal, FI MUNI, 2014 40 Žurnálování  Hlavní nevýhody Undo logging  Ze zálohy DB nelze vytvořit aktuální stav DB Redo logging  Všechny modifikované bloky musíme držet v paměti až do potvrzení (commit) transakce Zápisy na disk jsou vynuceny pravidly žurnálu a ne přístupem k datům  Řešení: Undo/Redo logging Záznam v žurnálu obsahuje starou i novou hodnotu: PA152, Vlastislav Dohnal, FI MUNI, 2014 41 Undo/Redo logging  Pravidla  Hodnota X může být uložena před i po potvrzení Ti  Před zapsáním hodnoty X na disk, musí být na disk zapsán odpovídající záznam žurnálu (WAL)  Ulož žurnál při potvrzení transakce  Obnova  Ukončené transakce zopakujeme (redo) od začátku  Nedokončené transakce vrátíme (undo) od konce PA152, Vlastislav Dohnal, FI MUNI, 2014 42 Undo/Redo logging – obnovení  Příklad undo/redo log: ... ... ... ... ... ... PA152, Vlastislav Dohnal, FI MUNI, 2014 43 Kontrolní body  Jednoduchý checkpoint Během vytváření nesmí žádné transakce běžet Významné snížení průchodnosti DB  Řešení Průběžné kontrolní body (Non-quiescent Checkpoint)  Evidence nedokončených transakcí  UNDO/REDO logging:  všechny změněné záznamy (bloky) jsou uloženy na disk PA152, Vlastislav Dohnal, FI MUNI, 2014 44 Průběžné kontrolní body  Uloží se počátek a konec kontrolního bodu Start-ckpt active TR: T1,T2,... End ckpt .........Žurnál Zápisy bloků s nezapsanými změnami (všech, tj. i neukončených transakcí) odkazy na začátky transakcí PA152, Vlastislav Dohnal, FI MUNI, 2014 45 Průběžné kontrolní body  Obnova 1  T1 nemá commit  Undo T1 (undo a,b) T1 a ... Start-ckpt T1 ... End ckpt ... T1 b ...  Obnova 2  T1 má commit  Redo T1 (redo b,c) PA152, Vlastislav Dohnal, FI MUNI, 2014 46 ... T1 a ... ... T1 b ... ... T1 c ... T1 cmt ... ckpt- end ckpt-s T1 Průběžné kontrolní body PA152, Vlastislav Dohnal, FI MUNI, 2014 47 ... ckpt start ... ... T1 b ... ... T1 c ... ckpt- start ckpt end Průběžné kontrolní body  Obnova 3  Není dokončený kontrolní bod  najdi poslední úspěšný kontrolní bod Proveď undo/redo transakcí PA152, Vlastislav Dohnal, FI MUNI, 2014 48 Proces obnovy z výpadku  Zpětný průchod (konec žurnálu  začátek posledního ukončeného kontrolního bodu) 1. Vytvoř množinu S potvrzených transakcí 2. Vrať (undo) akce transakcí, které nejsou v S  Ad 1) Vrácení nedokončených transakcí  Včetně nedokončených transakcí v kontrolním bodu  Ad 2) Dopředný průchod (začátek posledního kontrolního bodu  konec žurnálu)  Opakuj akce transakcí v množině S (bez end) Zpětný průchod Dopředný průchod start check- point PA152, Vlastislav Dohnal, FI MUNI, 2014 49 Reálný příklad transakce  Vybírání hotovosti z bankomatu Informace o účtech v DB banky HW zařízení bankomatu  Implementace Transakce v databázi Fyzický výdej peněz  Postup Proveď transakci, výdej peněz až po commit. Výdej peněz by měla být idempotentní operace. PA152, Vlastislav Dohnal, FI MUNI, 2014 50 Reálný příklad transakce  Po provedení transakce v DB je poslán „signál“ pro výdej $ vydej(částka) lastTid: čas:VydejObnos(částka, Tid, čas) PA152, Vlastislav Dohnal, FI MUNI, 2014 52 Výpadek úložného média  RAID  Kopie dat na nižší úrovni Např.  3 identické kopie  Output(X)  ulož do 3 úložišť  Input(X)  načti ze 3 úložišť a zvol správný výsledek (voting) X1 X2 X3 PA152, Vlastislav Dohnal, FI MUNI, 2014 53 Výpadek úložného média  Kopie dat na nižší úrovni Jiný příklad  3 identické kopie  Output(X)  ulož do 3 úložišť  Input(X)  načti z prvního (pokud je ok, pokračuj)  načti z druhého, …  Podmínka  Chybná data lze detekovat X1 X2 X3 PA152, Vlastislav Dohnal, FI MUNI, 2014 54 Výpadek úložného média  Záloha DB Obnovení ze zálohy (archivu) Zpracování žurnálu  Zopakuj redo záznamy pro každou transakci nedokončenou v době provedení zálohy záložní DB aktivní DB žurnál PA152, Vlastislav Dohnal, FI MUNI, 2014 55 Mazání žurnálu  Kdy lze žurnál zkrátit? V případě UNDO/REDO logging check- point záloha db poslední potřebný undo nepotřebné při výpadku média nepotřebné pro undo obnovu po výpadku nepotřebné pro redo obnovu po výpadku žurnál čas PA152, Vlastislav Dohnal, FI MUNI, 2014 56 LOG DATADATADATA STABLE STORAGE UNSTABLE STORAGE WRITE log records before commit WRITE modified pages after commit RECOVERY Pi Pj DATABASE BUFFER LOG BUFFER lri lrj PA152, Vlastislav Dohnal, FI MUNI, 2014 57 Žurnálování v SQLServer 2000 Free Log caches Flush Log caches Current Log caches Flush Log caches db writer Flush queue Waiting processes LOG DATA free Pi free Pj Log entries: - LSN - before and after images or logical log Lazy- writer Synchronous I/O Asynchronous I/O DATABASE BUFFER DB2 v7 používá podobné schéma PA152, Vlastislav Dohnal, FI MUNI, 2014 58 Žurnálování v Oracle 8i Rollback segments (fixed size) After images (redo entries) Log buffer (default 32 Kb) Pi Pj Free list DATABASE BUFFER LOG DATA Rollback Segments Log File #1 Log File #2 Log Writer Database Writer Before images PA152, Vlastislav Dohnal, FI MUNI, 2014 59 Ukládání žurnálu  Na samostatný disk  Záznamy žurnálu jsou ukládány sekvenčně  Sekvenční zápis je násobně rychlejší než náhodný Na disku žurnálu by neměla být žádná další data + sekvenční V/V + výpadek žurnálu není závislý na výpadku DB PA152, Vlastislav Dohnal, FI MUNI, 2014 60 Ukládání žurnálu 0 50 100 150 200 250 300 350 controller cache no controller cache Throughput(tuples/sec) Log on same disk Log on separate disk 300 000 transakcí Každá transakce = 1x INSERT DB2 v7.1 server 5% zlepšení při žurnálu ukládaném samostatně Cache řadiče snižuje negativní důsledek při nededikovaném ukládání HW: střední server, Adaptec RAID controller (80Mb RAM), 2x18Gb disk. PA152, Vlastislav Dohnal, FI MUNI, 2014 61 Ukládání vyrovnávacích pamětí  Ukládání čekajících dat (dirty data) Při překročení parametru v počtu stránek (Oracle 8) Při překročení procenta volných stránek (méně než 3% - SQLServer 7) Při provedení kontrolního bodu V pravidelných intervalech PA152, Vlastislav Dohnal, FI MUNI, 2014 62 Vytváření kontrolních bodů 0 0.2 0.4 0.6 0.8 1 1.2 0 checkpoint 4 checkpoints ThroughputRatio Vliv na výkonnost (snížení propustnosti) Redukuje velikost žurnálu Zkracuje čas obnovy po výpadku 300 000 transakcí Každá transakce = jeden INSERT Oracle 8i na Windows 2000 PA152, Vlastislav Dohnal, FI MUNI, 2014 63 Shrnutí  Konzistence dat Jeden zdroj problémů: výpadky  Řešení:  žurnálování  redundance Další zdroj problémů: sdílení dat  Řešení:  Zamykání dat při zpracování transakcí  Nebudeme v přednáškách řešit