Názory k článku Transakce a izolace transakcí v databázích

Vyrok "A to se nejednalo o nějakého amatéra, ale o Microsoftem certifikovaného inženýra." mne vazne i v tuto nocni hodinu velmi pobavil. Moc diky!

Bohužel existuje i nemálo firem (nevím jestli s certifikovanými inženýry), které tímhle stylem napíší kompletní aplikace. A člověk může jen zvracet a nadávat.

Certifikace MCSE vyžaduje absolvování 6 různých zkoušek, a ty nejsou 2x jednoduché. Otázkou ale je, čemu u vás říkáte "Microsoftem certifikovani odbornici".

Google ve světě Windows není primárním ani jediným zdrojem informací. Na prvním místě se vyplatí zkusit autorizované zdroje. Například u STOP chyby (aka blue screen) můžete její popis hledat půl dne na Googlu, a dozvědět se spoustu nesmyslů, nebo najít dokumentaci za minutu na webu MS.

Pokud jste schopni si práci odvést sami v lepší kvalitě, tak mi není jasné, proč si někoho najímáte. Buď máte jedinou mizernou zkušenost se subkontraktory (a to není vypovídající), nebo obecně umíte provést práci lépe, ale přesto si na ní najímáte neschopná nemehla (což je vaše chyba).

Pokud za někoho platíte za každý den i více než jeden průměrný plat, tak se očekává nejen znalost věci, ale i to sako. Zkuste někdy přijít do banky jako subkontraktor v otahaném tričku se skvrnami, jetých džínách neurčitě barvy, a mastnými vlasy po pás. Samozřejmě jestli děláte ve státní správě nebo jste zamknutý někde v suterénu, tak *vám* taková věc může projít.

Je otázka, zda ti konkrétní byli měli opravdu certifikaci MCSE. Faktem je, že spousta formálně kvalifikovaných lidí nezvládá práci, kterou mají dělat. To můžete vidět u managerů, zedníků a pokrývačů, a samozřejmě i v IT. Důležité je umět vybrat dodavatele, a umět mu omlátit případnou nekvalitu o hlavu.

Myslím, že dobrá tečka na rozloučenou. Povedený článek!

Vždycky sem nad tímhle uvažoval trošku jinak (asi jako zamčení záznamu přes hodnotu 1/0 v nějakém sloupci...)...takhle mě to ještě nikdo nevysvětlil...díky...klidně bych si dal i nějaké pokračování :)

take se velice rad pridavam s diky za velice prinosne clanky

Hezky nastin do uvodu, pro uvodni seznameni s problematikou idealni. Diky!

BTW: Alespon je videt, co vsechno dokaze udelat zkousku na MSCE. Ono to tak trosku odrazi tradicni pristup MS k bezpecnosti ...

Myslíte MCSE? A udělení certifikátu na základě absolvování kurzu a následného testu fakt odráží přístup MS k bezpečnosti? To je naprostý nesmysl. Zkuste raději jiné téma. Můžete třeba promluvit o tom, proč spousta uživatelů Linuxu rádoby-profesionálně patlá webové taky-aplikace s příšernými vlastnostmi.

Patlal je patlal, bez ohledu na platformu. Na Windows bude patlal lépe dosahovat výsledků, ale patlalem zůstane.

"Vstupní bariéra" je blbost. Nechcete dnes sázat grafiku jen z olova, aby tam byla ta správná vstupní bariéra? Vždyť dnes každá lama může na svém počítači díky DTP programům spatlat 5 písem na jednom letáčku, a člověk by zvracel. Dokud se lilo olovo, neexistovaly stupidní časopisy pro ženy.
Jenže skutečnost je jiná. Jednoduše použitelné nástroje prostě zvyšují produktivitu profesionálů. Vyjma toho také zpřístupňují technologii neznalým. V některých případech je to dobré (účetní pracují produktivněji než s papírem), v jiných špatné (patlalové patlají).

Pokud jsem si všiml, tak náchylnost na SQL injection je běžná feature právě u těch PHP patlalů. Ve Windows se totiž s parametry pracuje snadno, a existuje velmi dobrá dokumentace, navíc s příklady a tutorialy.

Ale ja som na Radkovom najčítanejšom blogu na svete čítal, že MySQL je strašne zastaralé a dobré akurát tak na nejaký malý CMS a tak... hmm? :-) Napríklad že nemá triggery, aj keď priznám sa že neviem čo to je.

PS: Článok som si vytlačil a prečítam si to v pokoji neskôr... ale vyzerá dobre.

Já myslím, že kdyby něco napsal Lenin, tak by se dalo o databázích pokračovat. Zvlášť oblast Oracle PL/SQL a Microsoft Trasact-SQL, DB2 apod. by mohlo být velmi zajímavé.
Pěkně od začátečníků po pokročilé :-). Jako problém vidím, že ty články byly jenom o open source databázích a byly málo edukativní, takže to sloužilo jenom omezenějšímu počtu čtenářů.
Hodně úspěchů a štěstí autorovi.

Pěkně napsané, i když tohle by měl znát každý absolvent. Jen z hlediska konzistence výkladu bych doporučil použít příklad s aktivy a pasivy i pro vysvětlení rozdílu mezi READ UNCOMMITED a READ COMMITED. Také bych více rozvedl vysvětlení, proč je v konkrétním případě výsledek výběru neočekávaný.

Tak šup sem s tím, když to víš. Tož se poděl.
Už se klepu :-)

Nepochopil jste článek? Zkusme to znovu, třeba to půjde.

Provádíme následující dotaz:

BEGIN
SELECT sum(castka) FROM aktiva;
SELECT sum(castka) FROM pasiva;
COMMIT

Zároveň na serveru probíhá vkládání dat tímto způsobem (předpokládáme vždy shodu částek jdoucích na aktiva a pasiva):

BEGIN
INSERT INTO aktiva (castka) VALUES (1234)
INSERT INTO pasiva (castka) VALUES (1234)
COMMIT

Při úrovni izolace READ UNCOMMITED "vidí" SELECT i data z neuzavřených transakcí. Proto se může stát, že uvidíte vloženo těch 1234 v tabulce aktiva, ale ještě nebude totéž vloženo do tabulky pasiva. Pozmínka: také se může stát, že transakce měnící obsah tabulky neskončí potvrzením (COMMIT) ale zrušením (ROLLBACK), a vy jste data přesto uviděl a načetl. To bývá také nežádoucí.

Při úrovni izolace READ COMMITED vidíte jen data z potvrzených (commited) transakcí. Proto bude součet aktiv a pasiv vždy stejný. Problém je vyřešen. Jenže... Naše transakce se SELECTy provádí čtení dvěma dotazy. Může to dost dobře dopadnout to takhle:
1. prvním SELECTem vypočtete sumu z tabulky aktiva (a suma z tabulky pasiva bude v tu chvíli stejná)
2. pak někdo jinou transakcí aktualizuje tabulky aktiva i pasiva
3. Vypočtete sumu z tabulky pasiva, ale už tam budete mít započtené změny učiněné v kroku 2. Aktiva v tuhle chvíli budou opět sedět s pasivy, ovšem hodnoty už budou dávno odlišné. Oops, pořád máme problém.

Co s tím? Naštěstí tu máme úroveň izolace SERIALIZABLE. Na téhle úrovni izolace se DB tváří, jako kdyby byla vždy vykonána celá transakce, a teprve poté začala další transakce (což řeší náš problém popsaný v u READ COMMITED).
Typická implementace úrovně SERIALIZABLE vypadá tak, že (navíc proti nižším úrovním izolace) transakce provádíte najednou, ale při čtení si zamknete záznamy v DB. Když se je pak někdo snaží změnit, jeho transakce musí čekat, dokud není zámek odstraněn. Pokud transakce na zámek nenarazí, může být uskutečněna. Asi není třeba říkat, že práce se zámky je pro dospělou DB s hromadami transakcí probíhajících v jednom čase klíčovou záležitostí.

Mohli bychom si povídat ještě o snapshotech (verzování polí DB a řešení konfliktů až při commitu), příčinách a řešeních deadlocků (třeba wait-for graph), třífázovém commitu (používá se v heterogenních a distribuovaných systémech), a spoustě dalších krásných věcí. Jenže na to nemám čas, a navíc je sdílení vědomostí obtížné a nevděčné.

Pro vaši informaci teoretické základy pro vznik RDBMS byly položeny Edgarem Coddem někdy v sedmdesátých letech, a implementace se začaly šířit v letech osmdesátých. Na začátku Coddova práce mohla působit jako neškodná akademická hříčka. Dnes na ní stojí veliký kus IT světa.

Pokud chcete více informací, sežeňte si dokumentaci k MS SQL Serveru. Koncepty jsou tam vysvětlené tak, že to musí být jasné i slepému. Alternativou jsou skripta, wikipedia nebo učebnice.

seda je teorie, zeleny je strom zivota ... co si z te Vasi teorie mame odnest do toho zivota ?

Pokud je to pro vás obsah článku nebo mého příspěvku novinka, tak se zkuste naučit nejdůležitější teoretické základy, než se pustíte do praktických realizací. Vzdělání pomůže, ale není nutné; informace jsou k dispozici všude po webu, a mozek máte vlastní.

IT je svým způsobem řemeslo, a jako ostatní řemesla zaslouží kvalitní provedení. Co byste si myslel o instalatérovi, který nezná základy svého řemesla? A co si myslíte o člověku, který bez znalosti základů svého řemesla špatně navrhne DB (porušení normálních forem), a/nebo špatně navrhne aplikaci (s race conditions), a/nebo aplikaci napíše nebezpečně (umožní SQL injection)? Takový člověk dělá ostudu sobě i celému odvětví, a ještě často způsobí škody.

"Na začátku Coddova práce mohla působit jako neškodná akademická hříčka. Dnes na ní stojí veliký kus IT světa."

Spíš bych řekl, že veliký kus světa stojí nad zpotvořeninou Coddovy práce. Přečtěte si Třetí manifest od Datea a Darwena a pochopíte.

Codd položil základ DB, a jeho teorie byla do praxe převedena celkem dobře. Tedy na úrovni DB. Integrace mezi DB a objektovým prostředím je věc jiná. Tady je třeba přiznat, že to tak úplně nevyšlo. Ale znáte to - I consider my glass half full ;)

ten inzenyrsky pristup ohledne toho vyskytu tech kolizi pro viceuzivatelskem pristupu.

Obavam se, ze zadne statistiky nema.

Ono je to taky o tom, aby zákazník byl schopen ocenit tu větší pracnost, která za robustností stojí.

Řada jednoduchých aplikací může šťastně existovat s úrovní izolace READ UNCOMMITED, a nevyžadují ani ostatní ACID vlastnosti. Příkladem může být diskuze tady na rootu, nebo většina triviálních webových udělátek. Ovšem jakmile se začneme bavit o trochu vážnějším použití DB, je situace úplně jiná. Představte si třeba databázi zákazníků na call centru, a do té buší dvacet (nebo také dvě stě) operátorek. Velmi lehko se stane, že jich bude více editovat ten stejný záznam. Co se stane u jednoduché aplikace? Přijdete o změny. Je to akceptovatelné? V žádném případě, to byste z toho udělal ca-ll-sino.

Problém je v tom, že aplikace (a zvláště ty webové) píší často lidé bez základních znalostí a schopností. Doma jim ten eshop fungoval, zákazník si to také zkusil, tak co. Jenže jak uváděl kolega Stěhule, až přijde vánoční špička, může majitel mít shopu vrásky na telefonu rozzlobené zákazníky, a na čele hluboké vrásky. Proto je pro zákazníka lepší pracovat s profesionály, a ne s garážovými firmami.

MS samozřejmě byla garážová firma, jako velké procento dnešních velkých firem. Ovšem zakladatelé měli slušné znalosti.

Garážová firma nemusí nutně dělat věci špatně. Ovšem dobrá garážová firma se z té garáže dostane (byť asi neskončí tak vysoko, jako MS), kdežto patlalové v garáži typicky zůstanou (i z toho existují výjimky). U garážové firmy má nezkušený zákazník veliké riziko, že se spálí.

Profesor nemusí být automaticky vhodná osoba. Když budu potřebovat něco svařit na stavbě, profesor ze stavební fakulty může být tím nejhorším kandidátem. Podobně teoretický informatik může být pro tvorbu eshopu ztracený případ. A když vidím některé profesory, jak zápasí se zasunutím klíčenky a spuštěním PPT prezentace... Třikrát se nestrefí do USB konektoru, minutu hledá soubor v Exploreru, pak na něj klikne, zamyslí se, jde do menu File, a vybere položku Open. Přednášet problematiku ze sedmdesátých let zvládne v podstatě stejně úspěšně, jako udržet vlastní moč, ale rozhodně bych si ho nenajmul. Uživatele Lenin POWER! osobně neznám, ale pokud by měl kvalifikaci a reference (což asi má), tak bych mu vývoj dost možná svěřil.

Svět IT má svá specifika, díky kterým perfektní aplikace na první pokus dost možná nebudeme psát nikdy. Ovšem to nijak neospravedlňuje patlání bez znalosti základů řemesla.

Myslim si to stejne. Kdyz v praxi vidim co dodavaji za silenosti velke "profesionalni" firmy. Kolikrat nemaji o DB zadnou paru. Vedi ze tam jsou nejake tabulky kam se ukladaji data a nejake indexy aby to rychle vyhledavalo. To je bohuzel nekdy vse. :-( Pak staci v nejakem super nastroji naklikat objektovy datovy model a ejhle. Super profesionalni aplikace je na svete. :-) Jen od ni nikdo nesmi chtit aby bezela v zatezi. ;_)

ja vidim ten nejvetsi problem v IT v takovych lidech, jako jste vy. Takovi, kteri melou neustale ty IT-pravdy, ktere se naucili v nejakem kurzu nebo co pochytili na skole od nejakeho profesora, ktery v zivote nemusel projit ruznorodym softwarovm prostredim.

Ale mozna, ze jste chlap s gulema, a mozna treba i inzenyr a ne nejaka IT-slecinka, tak se nestydte a hodte sem ty statistiky tech kolizi v beznych softwarovych systemech rozdelene podle velikosti systemu, poctu uzivatelu, branze apod. Vypravejte nam o tech call centrech, kde delaji telefonistky na tech samejch zaznamech. (ano, takovy nesmysl je mozno zakaznikovi prodat, ale musi to navrhnout asi nekdo jako vy - samozrejme, ze budou dodrzeny normalni formy :-) )

Ale jestli ty statistiky nemate, tak vam rikam, ze kseftujete s citronama.

Aha. Takže vy při návrhu aplikace vůbec neuvažujete o tom, že operace bez transakcí nejsou atomické. Díky tomu zřejmě může dojít ke ztrátě dat, když se věci "vhodně" sejdou. Ale ten špatný je člověk, který si je problému vědom, a umí mu předejít. Naopak ten, kdo zprasí aplikaci tak, že může díky vadnému designu bez varování ztrácet data, je vlastně ten hodný a pracovitý hoch. Potom samozřejmě gratuluji, protože "jste ten hodný a pracovitý".

Hlavně se snažte vyvíjet někde hodně daleko od mě, a nedělejte nic, na čem opravdu záleží. Ti lepší patlalové se časem doučí (ti nejlepší se učí celý život). Ti horší patlají, dokud je nedostihne dost velký průšvih.

Ještě na okraj. Jeden takový patlal zabil 5 lidí, když si nevšiml race conditions u SW pro ozařovač Therac-25. Možná také čekal na statistiku počtu mrtvých pacientů podle jejich velikost, počtu ozařování a lokace nemocnice ;)

Souhlas. Ovšem dlouho trvající transakce také zvyšují pravděpodobnost deadlocku, takže se jim stejně člověk snaží vyhnout.

No to spíš závisí na tom, co ty transakce dělají, než jak dlouho trvají... :}

Imho Snapshot too old je trosku neco jineho. Asi bych to nedefinoval jako problem s garbage collection snapshot bloku :-) Takova vec neni potreba. :-)
Vse je to zavisle na UNDO. Tzn. modifikovane bloky se ziskavaji z UNDO a u jiz commitnutych transakci se muze stat, ze se pubvodni bloky prepisou a nepodari se je v UNDO dohledat (snapshot too old). Zalezi tedy na nastaveni velikosti UNDO a undo retention time.
Obecne se jedna spis o problem dlouho bezicich query nad modifikovanymi daty.
Klasicky pripad je napr. commit v cyklu namisto po cele transakci.

Jde proste o to, ze po commitu jsou UNDO bloky uvolneny pro dalsi pouziti, pak uz je to jen o te velikosti UNDO a jeho nastaveni. Proste dokud neprovedu commit, tak jsou bloky v undo v bezpeci. :-)

Pri dostatecne sizovanem undo je mozne klidne vytahnout obraz tabulky nekolik dnu zpetne.

U rozsahlych modifikaci se muze stat naopak to, ze se modifikovane bloky jiz do UNDO nevejdou a cela transakce spadne na unable to extend undo segment.

Jenomze to je prave ten spatny design. Po comitu sice uvolni bloky pro dalsi pouziti ale soucasne si je v tablespace necha, kdyz by je jeste nejaka bezici transakce potrebovala. Cisti je podle timestamp ale nikoliv podle toho zda nad nimy jeste nejaka transakce operuje ci ne. Meli by mit alespon inuse counter pro kazdy blok aby se nestavalo ze zahodi nespravny blok i kdyz je v undo tablespace misto. Kdyz je ten cas zbytecne velky tak se tam zase flakaji bloky ktere by mohli byt uz davno smazane.

mssql ani db2 tyhle problemy nemaji, je to zasadni oracle missdesign ktery ma snad od nepameti. Meli by to u oraclu uz konecne predelat takhle je to zbytecnej opruz.

Je fakt, ze problemy s UNDO segmentem jsem uz take zazil. Ale pokud bych mohl ovlivnit, co ma Oracle opravit, tak jsou to rozhodne veci spojene s retezovou invalidaci kodu. Zmenite hlacivku package a lup ho - vse co package pouziva je nevalidni a musi se rucne prekompilovat (krom triggeru). A nejlepsi je, ze obcas ani zkompilovani nepomuze a je nutne zavrit a znovu otevrit spojeni do DB, aby se novy kod zacal pouzivat. Bleeee :-/

S tim absolutne souhlasim. Veci ohledne provazani packages apod. nejsou reseny zrovna idealne. ;_)

To si nemyslim, ze se jedna o spatny design. Pri spravnem sizingu a nastaveni DB (UNDO) a samozrejme spravnem designu aplikace to nepredstavuje zadny problem. Udrzovani historie bloku je jen o diskovem prostoru.
Krome toho. Pokud uvazujeme dlouho bezici dotaz. Databaze preci nemuze dopredu vedet, ze ten konkretni blok v undo bude potrebovat. Ted konkretni blok se muze zmenit tisickrat. Pokud dotaz pobezi nekolik hodin tak databaze nema sanci podchytit, ktere bloky potrebovat bude a ktere se zmeni a bude je muset dotahnout z UNDO. To uz je vlastni resultset. ;-)
Snapshot too old je obecne problem v nastaveni DB(UNDO) nebo v navrhu aplikace.

JJ. Jak uz kdysi rekl jiny Lenin: "Vsechno souvisi se vsim". Tenhle missdesign je jen dusledek jinych zajimavych vlastni databaze. inuse counter je blbost, protoze byste pak musel obetovat prikaz "alter system kill session".

imho (asi to tak bylo i mysleno) se s jedna spis o chybu v designu cele aplikace.
Pri spravnem povedomi jak DB pracuje musi vyvojar takovou situaci predpokladat.

Tzn. jak bylo zmineno (Oracle, Postgres) pouzit for update

Jinak vlastni simulace je vcelku jednoducha rekl bych.
Pokud tim "obtížně se simuluje" nebyla myslena uz vysledna aplikace. :-)

Články tohoto autora jsou kvalitní, praktické a čtivé. Škoda, že ne všichni autoři z redakce root.cz píšou články podobného typu. Tedy nezbývá než říci "Díky!"

Krome odstranovani verzi radku pri pristupu, jeste ma FB background thread, ktery toto smeti take odstranuje. Oboji je vsak konfigurovatelne.

JC