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 20399×
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
|
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 ...
|