Lucka Žoltá

Řízení souběhu transakcí, zamykání

Jelikož nad jednou databázi většinou pracuje mnoho uživatelů, musí být databáze schopna řešit velké množství požadavků a transakcí. Zde může docházet k různým problémům vlivem špatné koordinace jednotlivých transakcí. Je třeba se zabývat řízením souběhu požadavků.

Hlavním problémem ke kterému dochází je, že si dvě transakce probíhající zároveň nad stejnými daty budou přepisovat data. Nejjednodušším řešením problému souběhu transakcí je spouštět transakce seriově, tedy jednu po druhé. Jenže to by bylo zdlouhavé a zbytečně by se během dlouhých přenosů dat nevyužíval procesor, který by mohl zpracovávat další transakce. Proto se transakce provádějí paralelně, ale tak aby byl splněn požadavek na sériovost transakcí, který říká aby výsledek paralelního zpracování byl stejný jako při zpracování sériovém.

Požadavek sériovosti transakcí můžeme zajistit:

• Precedenčním grafem - graf transakcí kde uzly reprezentují transakce a orientované hrany mezi nimi se pak objeví, pokud pracují nad stejnými daty. Pokud graf obsahuje cykly, pak testované schéma paralelního zpracování nesplňuje požadavek seriovosti.
• Zamykáním části databazí proti přepisu, když s ní zrovna transakce pracuje.

Zamykání

Transakce si při práci s daty může pozamykat části databáze proti přepisu. Většinou si zamkne záznamy které zpracovává, ale lze zamknout celou tabulku či dokonce databázi například při zálohování databáze. Rozlišujeme dva typy zámků:

• Zámek pro sdílený přístup - zamkne prvek pouze proti přepisu a ostatní transakce z něj můžou číst. V transakční analýze označujeme tento typ zámku LS(A)
• Exkluzivní zámek - zamkne prvek jak pro přepis, tak pro čtení. V trans. analýze označujeme LX(A).

Problém uváznutí

Ukázka uváznutí

Zámky sice řeší problém vzájemného přepisu, ale způsobují další problém a tím je problém uváznutí.  K tomu dochází když si transakce vzájemně zamknou záznamy s kterými potřebují a pak čekají až jim ta druhá ten jejich záznam odemkne.

Tento problém uváznutí se dá řešít několika způsoby:

• v transakční analýze tak že na začátku transakce vše potřebné pozamykáme a na konci to odemkneme. Zbytečně však během celé transakce blokujeme záznamy které nepotřebujeme a pak před zahájením dlouho čekáme na odemknutí všech potřebných záznamů.
• v transakční analýze při zamykání respektujeme nějakou lineární posloupnost. Například zamykáme postupně podle ID.
• SŘBD umí detekci uváznutí a ukončí jednu z transakcí
• SŘBD obsahuje plánovač který vykonává transakce tak aby k uváznutí nedocházelo. Například plánovač pomocí časových razítek. Jednotlivým transakcím přidělí časové razítko a podle toho pak řadí přístupy 

PROBLÉMY SOUBĚHU

Při souběhu mohou nastat tyto 3 problémy:

1.  Ztráta aktualizace

Transakce A načte entici t, transakce B načte taky entici t. Transakce A entici změní, pak ji změní i Transakce B a tím pádem je ztracena aktualizace, kterou provedla Transakce A.  

transakce A      transakce B

   read t                 -

     -                   read t

  write t                 -

     -                   write t

Tento problém se také označuje jako RW konflik neboli špinavý zápis.

2.  Nepotvrzená závislost 

Transakce A načte entici t a provede její aktualizaci, Transakce B načte už aktualizovanou entici t, ale Transakce A provede Rollback a tak Transakce B pracuje s neplatnými daty. Problém nepotvrzené závislosti nastane v případě kdy jedna transakce načte nebo v horším případě aktualizuje entici, která byla aktualizována dosud nepotvrzenou transakcí. Jelikož tato transakce nebyla potvrzena, existuje možnost, že potvrzena nebude a naopak transakce bude zrušena operací ROLLBACK. V tomto případě ale první transakce pracuje s hodnotami které nejsou platné.

transkace B      transakce A

     -                   write t

   read t                -

     -                  rollback

Tento problém je taky označovaný jako WR konflikt neboli špinavé čtení.

3. Nekonzistentní analýza - Jedna Transakce mění data pod rukama té druhé Transakce.

Rozdíl, mezi nepotvrzenou závislostí a nekonzistentní analýzou je, že u nepotvrzené závislosti pracuje transakce s daty, které už neexistujou (byl proveden Rollback) a u nekonzistentní analýzy s daty, které existujou (byl proveden Commit) ale jsou jiné než na začátku transakce.

transakce A           transakce B

   read t                     -

     -                      write t

   read t                     -

Úroveň izolace

READ UNCOMMITED - špinavé čtení - čte nepotvrzená data

READ COMMITED - čisté čtení - čte potvrzená data (opakovatelné čtení)

REPETABLE READ - čisté neopakovatelné čtení - mohou se zde vyskytovat fantomy

SERIALIZABLE - čisté neopakovatelné čtení bez fantomů