LINUXSOFT.cz Přeskoč levou lištu

ARCHIV



   

> PostgreSQL (15) - Transakce

Transakce patří k základním mechanismům práce s daty na databázovém serveru, zejména pak při aktivních operacích (UPDATE, INSERT, DELETE).

30.8.2005 06:00 | MaReK Olšavský | Články autora | přečteno 20168×

K čemu slouží transakce

Při jakékoliv operaci může dojít k chybě při práci s daty, ať již pádem serverové služby, nebo špatně položeným dotazem. Teoreticky se při SELECTu tak mnoho neděje, jen aplikace nezíská všechna potřebná data, ale při zadávání nových záznamů, jejich změnách, či mazání by mohl nastat velmi závažný problém s integritou dat.

Modelový příklad může být změna změna cen v elektronickém obchodě, například z konkurenčních důvodů. Po zadání příkazu UPDATE products SET price = price / 1.01, což je zlevnění veškerého zboží o 1% může v chodu serveru nastat chyba, například při aktualizaci 1028 položky z 9000. Pokud nejsou použity transakce, bude aktualizováno právě těch prvních 1027 položek, ale další zůstanou neaktualizovány. Aplikace se dozví, že nastala chyba a pokusí se tuto aktualizaci spustit znovu, takže těch prvních 1027 položek bude 2x zlevněno o 1%. Dalo by se tomuto předejít použitím timestampu, kdy další pokus by aktualizoval data, která by měla starší (třeba o 1 hodinu) datum aktualizace, než je poslední timestamp.

Popisovaný příklad navíc nepočítá se změnami, které mohou probíhat na dalším připojení k databázi z aplikace spuštěné na jiném počítači. Například z jiného místa bude změněn popis zboží, čiže timestamp by mohl nasvědčovat tomu, že cena již byla aktualizována byla.

Tyto problémy se řeší jednodušeji, než se zdá, pomocí tzv. transakčního zpracování, které je sice o malinko pomalejší, ale odolná vůči těmto problémům. Transakce v podstatě zajišťují, že pokud není příkaz provedený do konce korektně a není tudíž potvrzen, nejsu změny přístupné v následujících příkladech. V příkladě, který byl napsán o několik řádků výše to znamená, že pokud nastane chyba, když bude mechanismus db serveru aktualizovat 1028 řádek, tak nebude uloženo ani těch prvních 1027 řádek se změněnou cenou.

Každý příkaz, který je odeslán na PostgreSQL server je "obalen" v samostatné transakci, a pracuje nad obrazem dat, který byl k dispozici v momentě zahájení transakce. Trochu problém by mohl nastat pokud by měnění dat bylo prováděno z vícero míst současně, protože by server nemusel být schopen sestavit správně všechny změny, které byly zadány, takže v tomto místě k transakcím ještě přistoupí zamykání tabulek, se kterými se seznámíme v příštím díle.

Transakční módy a módy čtení

PostgreSQL server nabízí několik módů, ve kterých může data zpracovávat v transakcích (pro ty jsou módy 4) a další 3 módy pro čtení.

Módy transakcí:

  • READ COMMITTED - Základní mód PgSQL, kdy dotaz čte pouze data z ukončených/potvrzených transakcí. Pokud během čtení je některá z transakcí ukládajících, či měnících, data potvrzena, tento SELECT je neuvidí.
  • READ UNCOMMITTED - Chová se stejně, jako READ COMMITED, je zde jen z důvodu kompatibility s SQL standardem. V původní verzi má číst i data, která ještě nemají potvrzené transakce (v případě nepotvrzeného DELETE jsou vynechány řádky, které mají být vymazány).
  • SERIALIZABLE - Nejčistší a nejbezpečnější forma transakčního zpracování. Server nepovolí paralelně přes sebe běžící transakce, ale řadí jednu za druhou. V tomto módu je nutné mít aplikaci připravenu na opakování transakce (bloku příkazů), když bude serverem změna zamítnuta.
  • REPEATABLE READ - V PgSQL má stejné chování, jako SERIALIZABLE, je opět pouze kvůli kompatibilitě s SQL std. V normované verzi příkaz SELECT zpracuje a vrátí aplikaci pouze data, která jsou potvrzená, přičemž, ale doběhne-li některá transakce měnící data, je tento blok znovu SELECTEM zpracován a zařazen do návratových dat.

Módy čtení:

  • DIRTY READ - Transakce čte data, která nejsou ještě potvrzená v jiné transakci.
  • NONREPEATABLE READ - Transakce znovu načte data, která byla načtena při prvním čtení z tabulky a najde data, která byla mezitím potvrzena z jiné transakce.
  • PHANTOM READ - Transakce znovu vykonná dotaz vracející množinu řádek odpovídající vyhledávací podmínce a najde řádky, které byly mezitím z jiné transakce potvrzeny, jako zpracované.

Aby vše nebylo úplně jednoduché, není možné kombinovat módy transakcí s módy čtení kombinovat zcela libovolně, ale PgSQL si tuto režii, který mód bude použit zařizuje sám, jen na základě nastaveného transakčního módo. Tabulka, z originální dokumentace, ukazuje, které módy transakcí a čtení nesmí být zkombinovány a z těch povolených je už jen na serveru, který použije.

Seskupení příkazů do transakce

PostgreSQL server pracuje v tzv. Autocommit  módu, kdy každý příkaz je "obalen" ve své vlastní transakci, čímž je předejíto možnosti chyb, která byla naznačena v modelovém příkladě. V řadě případů je nutné mít explicitně v jedné transakci několik SQL příkazů. K tomu slouží pár příkazů BEGIN a END, kterými se blok příkazů obalí.

Příkaz BEGIN má několik doplňkových parametrů, čiže jeho výsledný tvar má následující možnosti: BEGIN [WORK | TRANSACTION] [ISOLATION LEVEL transaction_mode [, ...]], kde klíčová slova WORK a TRANSACTION jsou volitelné parametry, které jsou bezvýznamové, ale v souladu s normou, pokud je transakce započata například, jako WORK, musí být takto i ukončena. Parametr transaction_mode má některou z hodnot READ COMMITTED, READ UNCOMMITTED, SERIALIZABLE a REPEATABLE READ, které byly vysvětleny v předchozí kapitolce, další volitelné prarametry, které jsou spjaty s ISOLATION LEVEL transaction_mode a jsou volitelné jsou READ ONLY a WRITE ONLY, které určují, pro kterou část práce s daty patří v danné transakci mód. Ekvivalentem tohoto příkazu, včetně stejných parametrů, jen neobsahující jedno z dvojice klíčových slov WORK a TREANSTACTION.

Pro ukončení transakce jsou k dispozici 2 příkazy, jeden pro potvrzení transakce, který se jmenuje COMMIT [WORK | TRANSACTION] a druhý je ROLLBACK [WORK | TRANSACTION], který slouží pro zrušení transakce, tudíž veškeré změny jsou zahozeny. Tyto příkazy jsou posílány z aplikace, takže není problém kdykoliv v průběhu práce s daty, nebo při chybě odchycené v aplikaci, transakci zrušit. Pro vysvětlení: při nastartování transakce z aplikace, a zadávání dalších příkazů z této, server standardně reaguje například na chybně zadaná data (řetězec do čísla, ...), takže chyba je oznámena standardním mechanismem aplikaci, tudíž je možné na ní zareagovat, například zrušením transakce.

Užitečnou vlastností při používání transakcí je možnost vytvořit si návratové body, tzv. SAVEPOINTs. Vytvářejí se klíčovým slovem SAVEPOINT jmeno, kde jméno savepointu je plně v rukou programátora a je povinným parametrem. Pro zrušení všech změn (rollback), které se udály mezi nastavením návratového bodu a se používá příkaz ROLLBACK TO SAVEPOINT jmeno, přičemž transakce zůstane běžící, jen jsou zrušeny změny k tomuto návratovému bodu. Pokud je v aplikaci návratový bod již nepotřebný, lze jej zrušit příkazem RELEASE SAVEPOINT jmeno.

Kromě výše uvedených příkazů lze pro všechny operace používat "centrální" nastavení vlastností transakcí příkazem SET TRANSACTION transaction_mode [, ...], kde transaction_mode je jeden z módů, uvedených v předchozí kapitolce a je možný přídavný parametr READ ONLY, nebo WRITE ONLY, jehož význam je stejný, jako u BEGIN/START TRANSACTION. Tímto příkazem se nastaví transakce pro jedno sezení, poté je stačí pouze startovat a ukončovat. Pokud je tento příkaz odeslán při již otevřené/spuštěné transakci, nemá žádný vliv na její průběh.

Dodatky k transakcím

Transakce, tak jak je nabízí PgSQL nejsou ekvivalentní k možnostem, které má MySQL, dokonce ta je nemá na svých MyISAM tabulkách, ale je třeba použít InnoDB tabulky. V MySQL znamená přechod na InnoDB tabulky dokonce zpomalení celé databáze, bohužel.

Byť je režie transakcí pro databázi zpomalující, může být soustředění několika příkazů do jedné transakce přínosné pro výkon databáze jako takové, vůči stavu bez jejich použití. Jak bylo napsáno, PgSQL pracuje v tzv. Autocommit módu, tj. je-li na server posláno několik nesouvisejících příkazů (čiže logicky by nebylo třeba je obalovat startem a ukončením transakcí), jsou tyto vykonávány jeden za druhým s tím, že pro každý extra je otevírána a potvrzována transakce, ale v případě že je explicitně nastartována transakce, jsou vykonány všechny změny, které jsou do ní promítnuty teprve po jejím potvrzení.

Transakce přináší také vyšší nároky na diskový prostor. V případě, že má databáze 800 MB a příkazy seskládanými v transakci bude ovlivněno 500MB, je třeba mít volných těchto 500MB v paměťovém/diskovém prostoru serveru.

--Jednoduse nastartovana a potvrzena transakce
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
UPDATE products SET unitprice = unitprice / 1.01;
DELETE FROM products WHERE unitprice<5.00;
COMMIT TRANSACTION

--Nastartovana a zamitnuta transakce
START TRANSACTION ISOLATION LEVEL READ COMMITTED;
UPDATE products SET unitprice = unitprice / 1.01;
DELETE FROM products WHERE unitprice>1000.00;
ROLLBACK TRANSACTION

--Pouziti savepointu
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SAVEPOINT muj_navrat;
UPDATE products SET unitprice = unitprice * 2;
ROLLBACK TO SAVEPOINT muj_navrat;
SAVEPOINT muj_navrat;
UPDATE products SET unitprice = unitprice * 1.02;
RELEASE SAVEPOINT muj_navrat;
DELETE FROM products WHERE unitprice>1000.00;
ROLLBACK TRANSACTION;

Tyto příklady jsou jen na to, jak mohou být příkazy za sebou seskládány, ale většinou budou tyto posílány z aplikace, čiže bude možná interakce s chybami, které vrátí PgSQL server do aplikace, případně reakce na chyby uživatele aplikace při změnách dat.

Závěrem

Cílem tohoto dílu bylo seznámit se s transakcemi a jejich použitím. V příštím díle bude probráno zamykání tabulek, čímž lze dopomoci k vyšší úrovni integrity dat.

Verze pro tisk

pridej.cz

 

DISKUZE

Doplnění - zpomalování 19.5.2006 23:38 Lukáš Zapletal
Dotaz na funkci transakci 18.9.2006 13:24 Tomk
  |- Re: Dotaz na funkci transakci 18.9.2006 15:27 Aleš Hakl
  L Re: Dotaz na funkci transakci 18.9.2006 17:35 Petr Zajíc
    L Re: Dotaz na funkci transakci 18.9.2006 17:41 Aleš Hakl
      L Re: Dotaz na funkci transakci 18.9.2006 22:57 Petr Zajíc
        L Re: Dotaz na funkci transakci 19.9.2006 08:57 Tomk
          L Re: Dotaz na funkci transakci 19.9.2006 21:59 Petr Zajíc
            L Re: Dotaz na funkci transakci 19.9.2006 23:49 Aleš Hakl




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

28.11.2018 23:56 /František Kučera
Prosincový sraz spolku OpenAlt se koná ve středu 5.12.2018 od 16:00 na adrese Zikova 1903/4, Praha 6. Tentokrát navštívíme organizaci CESNET. Na programu jsou dvě přednášky: Distribuované úložiště Ceph (Michal Strnad) a Plně šifrovaný disk na moderním systému (Ondřej Caletka). Následně se přesuneme do některé z nedalekých restaurací, kde budeme pokračovat v diskusi.
Komentářů: 1

12.11.2018 21:28 /Redakce Linuxsoft.cz
22. listopadu 2018 se koná v Praze na Karlově náměstí již pátý ročník konference s tématem Datová centra pro business, která nabídne odpovědi na aktuální a často řešené otázky: Jaké jsou aktuální trendy v oblasti datových center a jak je optimálně využít pro vlastní prospěch? Jak si zajistit odpovídající služby datových center? Podle jakých kritérií vybírat dodavatele služeb? Jak volit vhodné součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně datové centrum spravovat? Jak co nejlépe eliminovat možná rizika? apod. Příznivci LinuxSoftu mohou při registraci uplatnit kód LIN350, který jim přinese zvýhodněné vstupné s 50% slevou.
Přidat komentář

6.11.2018 2:04 /František Kučera
Říjnový pražský sraz spolku OpenAlt se koná v listopadu – již tento čtvrtek – 8. 11. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma umění a technologie, IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

4.10.2018 21:30 /Ondřej Čečák
LinuxDays 2018 již tento víkend, registrace je otevřená.
Přidat komentář

18.9.2018 23:30 /František Kučera
Zářijový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 20. 9. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

9.9.2018 14:15 /Redakce Linuxsoft.cz
20.9.2018 proběhne v pražském Kongresovém centru Vavruška konference Mobilní řešení pro business. Návštěvníci si vyslechnou mimo jiné přednášky na témata: Nejdůležitější aktuální trendy v oblasti mobilních technologií, správa a zabezpečení mobilních zařízení ve firmách, jak mobilně přistupovat k informačnímu systému firmy, kdy se vyplatí používat odolná mobilní zařízení nebo jak zabezpečit mobilní komunikaci.
Přidat komentář

12.8.2018 16:58 /František Kučera
Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek – 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.
Přidat komentář

16.7.2018 1:05 /František Kučera
Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

31.7.2023 14:13 / Linda Graham
iPhone Services

30.11.2022 9:32 / Kyle McDermott
Hosting download unavailable

13.12.2018 10:57 / Jan Mareš
Re: zavináč

2.12.2018 23:56 / František Kučera
Sraz

5.10.2018 17:12 / Jakub Kuljovsky
Re: Jaký kurz a software by jste doporučili pro začínajcího kodéra?

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2024) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze