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í :)

+1 A pokud ne na Rootu, tak kde? http://www.postgres.cz/ ?

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.

Počínaje 5.0 MySQL umí řadu věcí, které jste jmenoval - uložené procedury, které dokonce vrací multi record sets, triggery, check constrainty. Akorát málo kdo to používá :(.

http://www.root.cz/clanky/letmy-uvod-do-ulozenych-procedur-mysql-prvni-cast/
http://www.root.cz/clanky/ulozene-procedury-event-scheduler-a-informacni-schemata-mysql/

Má to určité mušky, ale je to použitelné.

Pracuji právě s verzí 5, ale má to opravdu hodně mušek :-(
Ty triggery mi trošku ujely a datasety ze stored procedur jsem nevěděl jak na ně (no muset vytvořit temporary tabulku pro vrácení datasetu ze stored procedury mi přijde jako drbání se levou rukou za pravým uchem a prostrčit si ji při tom ještě mezi nohama :-)).
Na mě působí MySQL asi tak, jak bylo řečeno v titulku Vašeho článku - rychlé, ale ne 100% spolehlivé, nepodporující některé nejzákladnější postupy. Co jsem zatím viděl, tak MySQL je DB, kterou využívají především lidé, kteří dělají weby pro ukládání takovýchto dat (mám na mysli data jednoduchá - nic extra komplexního). A z těch databází, které jsem od těchto lidí viděl, mi nebylo moc do zpěvu (absence základních návyků, postupů a pravidel při vytváření, nelogičnost, duplicity atd...).

P.S.: Patřím mezi lidi, kteří se bez transakcí neobejdou :-)
P.P.S.: Check constrainty v dokumentaci verze 5.1 prostě nevidím.

Omlouvam se za mystifikaci. InnoDB podporuje pouze foreign key constrainty - klasicke CHECK ignoruje. Spojil jsem si je dohromady.

Ohledně vracení datasetů MySQL věrně kopíruje MS SQL. Přijde na to. Někdy je výhodnější připravit generované množiny hromadnými operacemi (ala MS SQL nebo MySQL) někdy po řádcích (Firebird, PostgreSQL). Co se týče syntaxe, tak snad vyjma nové Sybase, žádná databáze nerespektuje standard. Věcně je způsob MS ale standardu relativně blízký.

MySQL AB to s 5.0 docela zazdila. Chtělo to ještě rok počkat a ty uložené procedury dotáhnout. Lidi se na 5ku docela těšili, a pak zjistili, že třeba ohledně uložených proc, předložená verze odpovídá zhruba prototypu. Přesto se našlo pár lidí, kteří proc používali a propagovali:

http://rpbouman.blogspot.com/
http://db4free.blogspot.com/2005/11/calculate-uniqueness-of-text-fields.html

MySQL AB se pak věnovala víc replikacím a pak bohužel utopila hodně energie ve Falconu. Což může být zajímavý engine. Zatím ovšem po třech letech je v hrubé betě.

Co mě mrzí, je to kopnutí si do MySQL na začátku. Technický článek s politickým začátkem docela znechutí.

Jinak já vím, co jsou to transakce dobře, dělal jsem s velkými dbms ještě před tím, než jsem potkal MySQL, a sice jsem chvíli nadával, ale všude je něco, s čím se zápasí. V PostgreSQL se zápasilo s chybovostí až vysokých verzí, teprve až poslední roky se dá na PostgreSQL spolehnout, že nelikviduje data. A to nemluvím, jak dlouho PostgreSQL trvalo, než byla schopná poskytnout Windows port, což také leccos říkalo o schopnostech jejích vývojářů a o tom, jak byla programovaná. Takový Firebird vzniknul na unixech, pak ho adoptoval Borland a bez problémů jel na Windows, a pak se zase roztáhnul v platformách – je to naprosto jiná ukázka toho, jak se programuje multiplatformní kód. U Firebirdu se zase zápasí s nejhorší dokumentací co u projektu znám, a u dbms to bolí desetinásobně. To jen na vyváženost.

Jinak u MySQL bych opravil – triggery jsou tam napůl nepoužitelné. Triggery nesmí měnit tabulku, nad kterou sedí, což je z hodně použití (neříkám že ze všech) diskvalifikuje.

V zásadě bych řekl, že triggery v MySQL mají největší použití právě jako náhrada constraintů, protože umějí odmítnout sql příkaz. Možná tak byly i míněny.

Jinak s tím, že MySQL 5 vyšla předčasně bych se ztotožnil.

Ohledně Falconu, oni neměli jinou možnost, než potápět InnoDb a rozvíjet Falcon. InnoDb totiž nebyl jejich engine, a firmu InnoDb software koupil před časem Oracle, který jim mohl kdykoli zavařit a odepřít pokračování v poskytování InnoDb. Právě proto začali horečně rozvíjet nový, svůj vlastní engine Falcon a moc doufali, že jim Oracle nepřidusí vzduch, než ho dokončí. Ironií osudu je dnes MySQL v rukách Oracle, takže možná se změní celá strategie MySQL, kdo ví, každopádně se dá čekat leccos – od dobrých až po špatné zprávy.

To není kopnutí - ale připomenutí. Určitě se na tu dobu pamatujeme oba. Diskuze zda transakce ano či ne se rozhořela právě ohledně MySQL. Do té doby se transakcím nikdo zvlášť nevěnoval. Podobné diskuze běžely paralelně třeba ohledně referenční integrity nebo použití uložených procedur (namátkou právě třeba triggerů). Jakási filozofie každého produktu pak samozřejmě ovlivňuje i jeho vlastnosti - díky tomu MySQL má stále třeba určité problémy s uloženými procedurami a například PostgreSQL dodnes nemá integrovanou replikaci. Prostě každá parta vývojářů měla a má jiné priority - proto třeba PostgreSQL dlouho nebyl pro Windows (nekomerční varianta PostgreSQL - komerční porty na Win - bylo jich několik - předcházely finálnímu portu možná i pět let).

Souhlasím, že koupě InnoDB Oraclem byla pro MySQL AB rána, která poslala MySQL do rukou Sunu a následně neplánovaně Oraclu. Vývoj Falconu sebral určitě hodně energie a zdrojů - nedávno jsem narazil na zprávičku o ohlášení Falconu starou tři roky - předpokládám, že to nečekali, když pro vývoj engine angažovali Jima, který do MySQL přišel s vlastním již existujícím enginem. Je jen otázkou, jak by MySQL vypadala dnes, kdyby se vývojáři nemuseli věnovat vývoji Falconu.

Takový Firebird vzniknul na unixech, pak ho adoptoval Borland a bez problémů jel na Windows, a pak se zase roztáhnul v platformách – je to naprosto jiná ukázka toho, jak se programuje multiplatformní kód.

Jednak Borlandu trvalo nekolik verzi, kdy kod na widows stabilizovali. Prvni pouzitelna verze defakto byla Interbase 6. A co se tyce kodu videl jste ho nekdy? Az posledni verze se daji jakztak prelozit a funguje ./configure. Ale prelozit takovy firebird 1.0 se v podstate nedalo. Zdrojovy kod neni vubec dokumentovany a zoreintovat se v nem je dost narocne. Naproti PostgreSQL je jeden z mala kodu, ktery jsem mel moznost videt, v kterem se da velice dobre orientovat a je dobre dokumentovany.

Myslím, že stav Interbase 6.0.x v době uvolnění mají na svědomí spíš lidé od Borlandu. :-) Ještě ze se toho pak chytli schopní lidé.

Mimochodem, právě dokumentace je dokonalým důkazem neshcopnosti open source vývoje Firebirdu. Jediná rozumná dokumentace, od které se můžete odpíchnout je manuál psaný Borlandem. Nějaká ucelená a rozumná dokumentace pak od open source vývoje neexistuje, takže celkem není divu, že Firebird postupně upadá do zapomnění. A možná, že celá 28-letá historie Firebirdu dopadne tak, že o jeho likvidaci se postará až open source komunita zanedbávající dokumentaci tak brutálně, jak se to jinde nevidí.

Čtete firebirdí Release Notes? Přijdou Vám nějak neúplné nebo nedostatečné? Já myslím, že jejich editorka odvádí výbornou práci. Aha. Já zapomněl. Vy si nechcete koupit její knížku, přestože ta kniha je tisíckrát lépe napsaná než celá ta slavná dokumentace k PHP a MySQL. :-)

No mne nic neuniklo. To vy jste tvrdil:

Takový Firebird vzniknul na unixech, pak ho adoptoval Borland a bez problémů jel na Windows, a pak se zase roztáhnul v platformách – je to naprosto jiná ukázka toho, jak se programuje multiplatformní kód.

Tak si to nejdrive ujasnete vy co je Firebird a Interbase, kdyz mne to pak omlacujete o hlavu. Co ja tvrdim je to, ze neni pravda, ze to bylo jednoduche, jak si myslite a trvalo to nekolik verzi(let) nez se to zadarilo.

Dale bych Vas rad upozornil, ze neexistuje nic jako UNIX api. Existuje neco cemu se rika ANSI C a POSIX. Obe tyto normy slouzi k tomu, aby bylo mozno psat prenositelne aplikace. To ze na windows POSIX api je rozbite to je proste fakt a pak je nutne si ho tam dopsat.

Dale bych Vas rad upozornil, ze Postgres tak Interbase vznikali obe v 80. letech takze tvrzeni, ktera databaze je mladsi je irelevantni.

Trošku offtopic: Necítíte se teď trošku schizofrenně, když Váš zaměstnavatel vyvíjí a prodává MySQL *a* Oracle (a ještě InnoDB a Berkeley DB enginy), zatímco Vy děláte reklamu jedné z posledních databází, které ještě nekoupili? :)

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ý.

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.

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.

"IT je svým způsobem řemeslo, a jako ostatní řemesla zaslouží kvalitní provedení."

Tesat do kamene.

Akorat je - podobne jako u ostatnich remesel - casto problem najit nekoho, kdo to kvalitni provedeni zaplati :-)

Jiste, ale obecne si myslim ze zrovna programatori si na vysi platu moc stezovat nemuzou (chapu ze generalizuji).

No, ono je to spis o tom, ze pokud reknete zakaznikovi "bude to za 100 dni prace "nejak" nebo za 150 dni "remeslne krasne"", tak si vybere tech 100 dni. Takze bud budete delat zadarmo, nebo to udelate "nejak" ;-)

"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.

Kolize se v článku vyskytují několikrát - co máte konkrétně na mysli?

Žádné statistiky ohledně kolizí nemám - podkladem je prezentace Toma Lanea.

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. ;_)

q1p7Mk cogfvqumjagx, [url=http://qhs­npvtqwgju.com/]qhsnpv­tqwgju[/url], [link=http://iw­bznmxhnair.com/]iw­bznmxhnair[/lin­k], http://awrsvbkyhbmz.com/

q1p7Mk cogfvqumjagx, [url=http://qhs­npvtqwgju.com/]qhsnpv­tqwgju[/url], [link=http://iw­bznmxhnair.com/]iw­bznmxhnair[/lin­k], http://awrsvbkyhbmz.com/

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 ;)

Oracle nema uplny MVCC jako maji pgsql a firebird. Oracle pouziva before statement block level snapshoty a sdili stejny block ve snapshotu vice transakcemi misto aby mel pro kazdou svuj jako maji MVCC databaze. Oracle implementace ma pak problem s garbabe collection snapshot bloku (znama chyba snapshot too old) u dlouhotrvajicich transakci, coz je docela opruz a proto se doporucuje oracle neprovokovat dlouhymi transakcemi.

DB2 umi v 9.7 Oracle 'statement snapshot' read commited isolation level. Stejne jako Oracle tak i DB2 emuluje MVCC, ale nepouziva block level snapshot ale ARIES.

Clanek by chtelo rozdelit na vic dilu:jeden o races, druhy o transakcich a isolation levelech, treti o zamykani s probranim lock avoidance strategii. Skoda ze s tim autor seknul, ale chapu ho.

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. ;_)

No a stačilo to prostě říct :-).... ehm. a nainstalovat Oracle Database 11g
Pohled do New Features Guide říká:
[url]http://download.oracle.com/docs/cd/B28359_01/server.111/b28279/chapter1.htm#FEATURENO07519[/url]
[b]1.2.9.3 Finer Grained Dependencies[/b]
In previous releases, metadata recorded mutual dependencies between objects with the granularity of the whole object. For example, PL/SQL unit P depends on PL/SQL unit Q or that view V depends on table T. This means that dependent objects were sometimes invalidated when there was no logical requirement to do so. For example, if view V depends only on columns C1, C2, and C3 in table T and a new column, C99, is added, the validity of view V is not logically affected. Nevertheless, in earlier releases, V was invalidated by the addition of column C99.

Oracle Database 11g records dependency metatdata at a finer level of granularity so that the addition of C99 does not invalidate view V. Similarly, if procedure P depends only on elements E1 and E2 in package PKG, then if element E99 is added to PKG, procedure P is not invalidated. (In Oracle Database 10g, this change to PKG would invalidate procedure P.)

Více viz: [url]http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/dependencies.htm#CHDJIIFC[/url]

Mno. Jenze oni toho vzdy naslibujou. :-)

No vida. Sice to neresi tu nutnost obcas zavrit/otevrit spojeni na DB a nez se Oracle 11 dostane do produkce tak asi budu v duchodu (nedavno se slavou upgradovali na 10), ale lepsi nez dratem do oka ;-)

my taky 11ku v produkci prakticky nikde nemame, zakaznici ji nepozaduji.

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".

porovnejte oracle 10 s db2 9.7
- oba dva umi statement snapshot MVCC emulaci

- db2 nepotrebuje UNDO segmenty
- db2 umi libovolne dlouhe transakce (od v8)
- db2 navic diky ARIES ani nepotrebuje hard checkpointy (flush datapages)

Takze tohleto je dukazem ze se to MVCC-like prostredi poradne naprogramovat da aniz by se musely heuristicky nastavovat parametry u UNDO segmentu (ktery ani db2 nema). Nizsi administrativni zatez databaze je pochopitelne vyhoda, stejne tak je vyhoda ze se o toto nemusi starat aplikace a muze si delat transakce dlouhe jak je libo (ackoliv delsi mohou potencialne vice lehnout na deadlock pri kolizi s ostatnimy transakcemi). O jakou dulezitou vlastnost oraclu je implementace v db2 ochuzena? kill session db2 umi (rika se tomu v db2 terminologii force application).

Ja nevim lidi mne pripada ze snad vubec neumite pracovat s informacemi, co vam na tom jeste neni jasne?

Oracle napriklad umoznuje mit neomezene mnozstvi radkovych zamku - nema lock escalation. Na druhou stranu ovsem v Oracle neexistuje pametova struktura ktera by vam rekla ktere radky byly zmeneny/zamceny a kym.
Diky tomu, ze oracle nezamyka bloky ani tabulky vam nemuze nastat deadlock kdyz db zacnou dochazet zamky. Proste neni to ani lepsi ani horsi je to proste jinak. Jedine co s tim muzete delat je dekovat Bohu ze vymyslel JDBC, diky kteremu se tyhle rozdily mezi databazemi zastiraji a programatori v JAVE na takovehle veci vubec nemusi myslet :)

tim myslite rceni: az na stara kolena zblbneme tak pouzijeme hibernate a nikdo nic nepozna?

Hezky receno. :-) O tomhle produktu nechci ani slyset. ;_)

Jasne je jedine. O DB Oracle toho zas tak moc nevite. Myslim, ze jsem vse vysvetlil docela nazorne. Nevim jaka je u vas presne definice "dlouhe transakce". Tyden dva? :-) Transakci na Oracle muzu mit rozjetou aniz by to narazelo na deadlock nebo neco podobneho. :-) V podani oracle je deadlock vzdy problem v navrhu aplikace.
Myslim, ze je zbytecne to rozebirat. Vase argumenty vypovidaji jen o neznalosti DB Oracle. :-) S prominutim.

Jeho argumenty by mohly vypodívat leda o neznalosti omezení DB Oracle. Jenže on právě ta omezení popisuje. Vy je pokládáte za know how, on za nectnost dané DB. Obecně admini unixů a Oracle rádi vydávají znalost chyb a omezení za know how. Kdo chyby a omezení nezná, ten podle nich "neumí produkt". Nepřiznají si, že chyba není v lidech, ale v produktu.

Mno. Oracle ma chyb spoustu, ale popsane chovani k nim nastesti nepatri. :-) Admin nejsem. :-)
Nicmene mozna jde opravdu o uhel pohledu. Puvodne byla ma reakce na snapshot too old a jeho vysvetleni.

Vyzkousejte mi nejak vysvetlit v cem ono omezeni/chyba spociva?

Btw: Ktery produkt nema nejake omezeni. Urcite je lepsi o tech omezenich vedet aby clovek
mohl produkt efektivneji pouzivat a vyhnout se zbytecnym prekvapenim. Nebo to tak neni? :-)
Obvykle ma kazde omezeni nejaky duvod. V jednom smeru to neco prinese a z jine strany zese naopak.
Imho znalost omezeni produktu (at uz je to treba databaze) je soucasti znalosti produktu jako celku.

Nebranim se tomu, ze Oracle ma necnosti.. to urcite ma. Ale nesouhlasim s tim tak jak je popisovano chovani UNDO, protoze tak to nefunguje. :-)

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. :-)

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

JC