Hlavní navigace

Nástroje a utility

Jak vyčistit disk s Linuxem?

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

Abraxis
Abraxis (neregistrovaný)
13. 5. 2009 0:19 Nový

Offtopic

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!
Lael Ophir
Lael Ophir (neregistrovaný)
13. 5. 2009 13:59 Nový

Re: Offtopic

celé vlákno
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.
uživatel si přál zůstat v anonymitě
13. 5. 2009 21:45 Nový

Re: Offtopic

celé vlákno
MCSE - Minesweeper Consultant, Solitaire Expert ...
Ale kdyz se na to podivame vazne, tak jestli neni situace neni k smichu, je k placi...
Microsoftem certifikovani odbornici poslani systemovym integratorem migrovat (at uz wokna nebo exchange) se vetsinou ukazali jako agilni klikaci brilantni znalosti kam kliknout (jak by ne, kdyz pri certifikaci musi ty postupy popisovat z pameti ;-)), lec jakmile prvni dialog vratil "Chyba #$%$&#$ ......." (nebo jeste lepe "Chyba (Ok/Zrusit)" ;-) tak zvladli maximalne tupe cumet. V horsim pripade se sli topit rovnou do microsofti KB, nebo obvolavali vsechny svate. Ani je nenapadlo nacpat to do googlu, popremyslet o tom odkud to mohlo prijit, mrknout se na to nastrojem treti strany, nic. Takze to vetsinou dopadlo tak ze skutecne problemy vyresili nasi spravci, panove si tam odklikali co zvladli, podnik zaplatil desitky tisic za hodinu a bylo zmigrovano.

Pripady ichtylu co zkouseli (a pry i v nekolika nestrezenych okamzicich kdy jim naivni spravce nestal lidove receno "za prdeli") ze zhavarovaneho pole vytahnout zdravy disk a poslat ten raid 5 do kytek naveky uz radsi ani pitvat nebudu.

Nejsou ridke pripady kdy banda nedouku slibi ze doda dokonalou aplikaci .... a vysledek se zadani podoba asi tak jako kdyby ho nekdo peclive rozzvykal, spolkl, castecne natravil a pak teprve vyzvracel na disky serveru. O to smutnejsi je kdyz nahodou tyhle pripady sezenou sponzora, zacnou si hrat na spolecnost a ulovi statni zakazku ...

Po takovych zkusenostech je hlaska "A to se nejednalo o nějakého amatéra ..." smutnym dukazem naivity autora - ano, najdou se i cestne vyjimky ale obvykle se da spis spolehnout na to jak se ten clovek chova za konzoli nez na to kolik nesmyslu si nasype pred/za jmeno).

Dobry programator i admin proste potrebuje analyticky schopnosti, rozumet tomu co se deje za zavesy a ne mit nabiflovanou prirucku "Naucime se programovat v ___ / Spravujeme Microsoft ___ za ____ dni" a seznam scrennshotu okynek + znamy chyby. To jsou vsechno veci co se daji hledat za pochodu, u zkousek z matiky jsou taky povoleny tabulky ;-)))

Ale co, ten pan ma kvadro, patnact titulu, stoji za nim Servisni Partner, tak to to bude zrejme genius, nepujdem se pred nim rovnou plazit po kolenou ? ;-))))
Lael Ophir
Lael Ophir (neregistrovaný)
19. 5. 2009 18:44 Nový

Re: Offtopic

celé vlákno
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.
uživatel si přál zůstat v anonymitě
20. 5. 2009 10:18 Nový

Re: Offtopic

celé vlákno
Mame 3 spatne zkusenosti, dalsi mam od pratel kterym mohu verit. Samozrejme to byla posledni prace, kterou moulove provedli v nasi siti.
Lael Ophir
Lael Ophir (neregistrovaný)
21. 5. 2009 16:18 Nový

Re: Offtopic

celé vlákno
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.
kefa
kefa (neregistrovaný)
13. 5. 2009 8:36 Nový

Dobrý článek

Myslím, že dobrá tečka na rozloučenou. Povedený článek!
Libor
Libor (neregistrovaný)
13. 5. 2009 9:09 Nový

Super

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í :)
Martin Fiala
13. 5. 2009 9:24 Nový

Díky

celé vlákno
Pavle, díky za super článek. Doufám, že si od Tebe ještě nějaké články přečteme, i když třeba ne na rootovi.
kmarty aura:79

Re: Díky

celé vlákno
Tak k tomu se pridavam.

P.S.: Zrovna vcera jsme s kolegy meli debatu na tema takrka shodne s timto clankem, takze prisel velmi vhod.
j3nda aura:76

Re: Díky

celé vlákno
taky pripojuji sve diky. at uz za tento nebo jine pqsql clanky - v mem pripade me to vzdy mile smeruje k ziskavani dalsich informaci.
Franta Kučera aura:80
13. 5. 2009 22:14 Nový

Re: Díky

celé vlákno
+1 A pokud ne na Rootu, tak kde? http://www.postgres.cz/ ?
t42
t42 (neregistrovaný)
13. 5. 2009 22:17 Nový

Re: Díky

celé vlákno
take se velice rad pridavam s diky za velice prinosne clanky
melkor
melkor (neregistrovaný)
13. 5. 2009 12:39 Nový

Pekne

celé vlákno
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 ...
Lael Ophir
Lael Ophir (neregistrovaný)
13. 5. 2009 20:11 Nový

Re: Pekne

celé vlákno
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.
Franta Kučera aura:80
13. 5. 2009 22:16 Nový

Re: Pekne

celé vlákno
Tihle patlači jsou většinou Windowsáři, kteří k Linuxu přišli jen proto, že jim běží na serveru na webhostingu :-D
uživatel si přál zůstat v anonymitě
13. 5. 2009 22:20 Nový

Re: Pekne

celé vlákno
Laelku, a kdyz si vedle sebe postavis Linuxovyho patlala a Windowsiho patlala, kterej z nich na tom bude lip (ne ze bych jim neurazil ruce obema, kdyby chteli hrabnou na neco co ocividne nedavaj) ?

Sazim na linuxovy patlaly, ti se vetsinou aspon nauci si pod sebou nepodrezavat vetev nebo to nevydrzi a tahnou zpatky ;-)))

A navic, kdyz vidis co na woknech provadi radoby seriozni, v nekterych pripadech i multinarodni spolecnosti, tak bys brecel. A ne ze by windowsich patlalu nebylo vic, preci jen vstupni bariera je nizsi, o linuchu by se musel napred od nekoho/nekud dovedet, vschichni kamosi maji kradeny wokna a ve skole ho nauci profesionalni design stranek v nastroji MS Word. Dokumentace pro vyvojovy nastoje pro mainstream jsou plny kramy, skoda ze je to vzdycky to same, rozbredly popis algolove syntaxe, tahame zaznam z databaze, naklikame si gui v designeru a opravdu, za par dni uz umime "programovat".
Jo , jeste tridy, a u nekterejch jazyku zminit, ze je tu neco cemu se rika pointer a umozni na tom s prakticky nulovou namahou i pochopenim delat jeste lepsi bordel.

Jeste udelam stranky segre a jejimu kreckovi, a pri trose stesti az bude maminka nekde vypravet jak jsem sikovnej, tak se nekdo chyti.

Seznam featur: Formular pro select a insert, pri trose snahy i nejaky ten update a mozna i master/detail. Wow, jeste ze tady na to je ta komponenta. Moznost SQL injection zdarma v cene, pokud se tomu ovsem autori frameworku vsemi silami nesnazili tomu zabranit. Ale nevadi, urcite se mi podari tam nekam nacpat moje oblibene conn.execute("..." + var + "..."). Hesla samozrejme ukladame v plaintextu, abysme je mohli uzivatelum posilat zpatky, ted jen jeste nakopnout toho Commandera a uploadnout to na ftp, sifrovany kanal je zrejme neco sprostyho.

A zejtra zajdu za frantou, rikal ze se tedka naucil v tom flashi hejbat ctvereckem, zalozime spolecnost ...

Mam pokracovat ? ;-)
Lael Ophir
Lael Ophir (neregistrovaný)
19. 5. 2009 18:50 Nový

Re: Pekne

celé vlákno
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.
Substance242
Substance242 (neregistrovaný)
13. 5. 2009 12:52 Nový

ale

celé vlákno
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.
Milan Tomeš aura:43

Re: ale

celé vlákno
No je pravda, že MySQL nemám rád, protože neumí spoustu věcí, na které jsem z Firebirdu zvyklý (stored procedury, které umějí vracet datasety, triggery, check constrainty atd...) a také dělá věci, které bych nikdy nepředpokládal (např. vztah mezi not null constraintem a default hodnotou sloupce). Možná je to tím, že MySQL moc nepoužívám (1. jen krátce, 2. snažím se mu vyhnout a radši nasadit Firebird) a tudíž s ním nemám moc zkušeností. Ve FB jsem poměrně kovaný, takže jsem schopen řešit spoustu problémů tak nějak automaticky. A pro rýpavé podotýkám - MSSQL nemám rád také :-)
Pavel Stěhule aura:89
13. 5. 2009 15:55 Nový

Re: ale

celé vlákno
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é.
Milan Tomeš aura:43

Re: ale

celé vlákno
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.
Pavel Stěhule aura:89
13. 5. 2009 16:54 Nový

Re: ale

celé vlákno
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ě.
Miloslav Ponkrác aura:67
13. 5. 2009 19:31 Nový

No …

celé vlákno
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.
Pavel Stěhule aura:89
13. 5. 2009 20:04 Nový

Re: No …

celé vlákno
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.
Milan Tomeš aura:43

Re: No …

celé vlákno
Nevím přesně, kdy lidé za MySQL začali byť jen koketovat s myšlenkou na implementaci transakcí, ale je pravdou, že v dobách, kdy jsem vybíral nástupce BDE (cca. 2001-2002) jsem jejich podporu jednoznačně vyžadoval a tím jsem pochopitelně MySQL vyloučil z výběru.
Kamil Podlešák aura:100

Re: No …

celé vlákno
V té době již MySQL transakce měla.
Milan Tomeš aura:43

Re: No …

celé vlákno
V době, kdy jsem rozhodoval, tak ne.
Zdenek Kotala
Zdenek Kotala (neregistrovaný)
13. 5. 2009 20:34 Nový

Re: No …

celé vlákno

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.

Ksl
Ksl (neregistrovaný)
13. 5. 2009 20:38 Nový

Re: No …

celé vlákno
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é.
Miloslav Ponkrác aura:67
13. 5. 2009 23:40 Nový

Re: No …

celé vlákno
Já řeknu toto: Zdrojový kód MULTIPLATFORMNÍHO programu, který byl přes 20 let vyvíjen, prošel rukama několika vývojových týmů – od toho bych nečekal dokonale čistý kód. Mluvím o Firebirdu. Zřejmě nečekáte, že v těch letech se vyvíjelo nad configure, a ve Windows se takto také nevyvíjí. Navíc není příliš zvykem (a hlavně v minulosti nebývalo zvykem) psát extra dokumentaci pro relativně malý projekt uvnitř vývojového týmu – což byl případ Interbase.

Možná Vám to ušlo, ale pro jistotu bych Vám rád připomněl, že Interbase byl komerční projekt, který byl vyvíjen uzavřeně a interně. A když byl tuším někdy po roce 2000 darován Borlandem open source komunitě, dokumentace tomu odpovídala.

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

PostgreSQL je mladší projekt, než Firebird/Interbase, a také s multiplatformovostí měli dlouho velmi výrazné problémy. Že je kód přehlednější, když prostě natvrdo (tedy nemultiplatformně) volali UNIX api, to je celkem nabíledni spolu s mladším stářím projektu a otevřeným stylem vývoje.
Ksl
Ksl (neregistrovaný)
13. 5. 2009 23:58 Nový

Re: No …

celé vlákno
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. :-)
Zdenek Kotala
Zdenek Kotala (neregistrovaný)
14. 5. 2009 10:18 Nový

Re: No …

celé vlákno

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.

Ksl
Ksl (neregistrovaný)
14. 5. 2009 22:15 Nový

Re: No …

celé vlákno
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? :)
Milan
Milan (neregistrovaný)
13. 5. 2009 12:58 Nový

Lenin

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.
Lael Ophir
Lael Ophir (neregistrovaný)
13. 5. 2009 14:16 Nový

pěkné

celé vlákno
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ý.
Bu bu bák
Bu bu bák (neregistrovaný)
13. 5. 2009 14:32 Nový

Re: pěkné

celé vlákno
Tak šup sem s tím, když to víš. Tož se poděl.
Už se klepu :-)
Lael Ophir
Lael Ophir (neregistrovaný)
13. 5. 2009 18:23 Nový

Re: pěkné

celé vlákno
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.
backup
backup (neregistrovaný)
13. 5. 2009 18:53 Nový

Re: pěkné

celé vlákno
seda je teorie, zeleny je strom zivota ... co si z te Vasi teorie mame odnest do toho zivota ?
Lael Ophir
Lael Ophir (neregistrovaný)
13. 5. 2009 19:25 Nový

Re: pěkné

celé vlákno
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.
VM
VM (neregistrovaný)
14. 5. 2009 8:38 Nový

Re: pěkné

celé vlákno
Až napíše systém se spoustou paralelních operací bez transakcí, a záhadným neopakovatelným způsobem se tam začnou množit chyby, tak pochopí.
Makovec
Makovec (neregistrovaný)
14. 5. 2009 9:25 Nový

Re: pěkné

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

Tesat do kamene.
Michal Kára
Michal Kára (neregistrovaný)
14. 5. 2009 9:36 Nový

Re: pěkné

celé vlákno
Akorat je - podobne jako u ostatnich remesel - casto problem najit nekoho, kdo to kvalitni provedeni zaplati :-)
Makovec
Makovec (neregistrovaný)
14. 5. 2009 12:59 Nový

Re: pěkné

celé vlákno
Jiste, ale obecne si myslim ze zrovna programatori si na vysi platu moc stezovat nemuzou (chapu ze generalizuji).
Michal Kára
Michal Kára (neregistrovaný)
14. 5. 2009 18:30 Nový

Re: pěkné

celé vlákno
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" ;-)
Ksl
Ksl (neregistrovaný)
13. 5. 2009 20:18 Nový

Re: pěkné

celé vlákno
"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.
Lael Ophir
Lael Ophir (neregistrovaný)
19. 5. 2009 18:55 Nový

Re: pěkné

celé vlákno
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 ;)
backup
backup (neregistrovaný)
13. 5. 2009 14:41 Nový

autora si vazim, presto bych rad videl

celé vlákno
ten inzenyrsky pristup ohledne toho vyskytu tech kolizi pro viceuzivatelskem pristupu.

Obavam se, ze zadne statistiky nema.
Pavel Stěhule aura:89
13. 5. 2009 15:10 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
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.
P_V
P_V (neregistrovaný)
13. 5. 2009 15:15 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
Ono je to taky o tom, aby zákazník byl schopen ocenit tu větší pracnost, která za robustností stojí.
Lael Ophir
Lael Ophir (neregistrovaný)
13. 5. 2009 18:41 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
Ř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.
Pavel Stěhule aura:89
13. 5. 2009 19:37 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
Nebyl také Microsoft dlouho garážová firma? Co odlišuje garážovou firmu od profesionálů? I tak velká firma jako je Microsoft např. neručí za škody, které vzniknou chybnou funkcí jejich sw. Takže záruky to nejsou. Já osobně bych si určitě raději objednal sw od svého profesora, který mne učil programovat, než od leckteré profi firmy (jeho přístup ke kvalitě je nepochybně lepší než Leninův).

Osobně bych se na profesionalitu profesionálů až tak moc nespoléhal. Zvláště v IT - ty zásadní chyby jsou odstraněné cca až v druhé, třetí verzi (např. u ekonomických aplikací Oraclu se na některé chyby narazí dodnes). Problémy (výkonnostní) bývají také s docela starými aplikacemi, které mají vlastní systém zamykání záznamů, vlastní systém synchronizace, a moderní databázi používají jen jako nosič.

Určitě už je situace o dost lepší než třeba před deseti roky, kdy byla tristní, ale že by se psaly perfektní aplikace (na první pokus) - hmm, tak o tom nic nevím. I velké firmy zaměstnávají jenom lidi - a jen minimum firem má tak nastavený testovací proces, že třeba chyby souběhu dokáže včas zastavit. Nemluvě o bezpečnostních chybách.
Lael Ophir
Lael Ophir (neregistrovaný)
13. 5. 2009 20:14 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
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.
Pavel Stěhule aura:89
13. 5. 2009 20:35 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
Každý jsme absolvovali jinou školu a měli jiné učitele - já si nemůžu stěžovat.
Snapshot
Snapshot (neregistrovaný)
14. 5. 2009 19:59 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
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. ;_)
backup
backup (neregistrovaný)
13. 5. 2009 21:28 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
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.
Lael Ophir
Lael Ophir (neregistrovaný)
19. 5. 2009 19:03 Nový

Re: autora si vazim, presto bych rad videl

celé vlákno
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 ;)
LENIN POWER! aura:43
13. 5. 2009 21:15 Nový

isolation levels

celé vlákno
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.
Lael Ophir
Lael Ophir (neregistrovaný)
13. 5. 2009 22:55 Nový

Re: isolation levels

celé vlákno
Souhlas. Ovšem dlouho trvající transakce také zvyšují pravděpodobnost deadlocku, takže se jim stejně člověk snaží vyhnout.
Ksl
Ksl (neregistrovaný)
13. 5. 2009 23:22 Nový

Re: isolation levels

celé vlákno
No to spíš závisí na tom, co ty transakce dělají, než jak dlouho trvají... :}
Snapshot
Snapshot (neregistrovaný)
13. 5. 2009 23:19 Nový

Re: isolation levels

celé vlákno
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.
LENIN POWER!
LENIN POWER! (neregistrovaný)
14. 5. 2009 1:08 Nový

Re: isolation levels

celé vlákno
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.
Michal Kára
Michal Kára (neregistrovaný)
14. 5. 2009 8:07 Nový

Re: isolation levels

celé vlákno
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 :-/
Snapshot
Snapshot (neregistrovaný)
14. 5. 2009 11:26 Nový

Re: isolation levels

celé vlákno
S tim absolutne souhlasim. Veci ohledne provazani packages apod. nejsou reseny zrovna idealne. ;_)
DK
DK (neregistrovaný)
14. 5. 2009 17:09 Nový

Re: isolation levels

celé vlákno
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]
Snapshot
Snapshot (neregistrovaný)
14. 5. 2009 17:23 Nový

Re: isolation levels

celé vlákno
Mno. Jenze oni toho vzdy naslibujou. :-)
Michal Kára
Michal Kára (neregistrovaný)
14. 5. 2009 18:10 Nový

Re: isolation levels

celé vlákno
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 ;-)
LENIN POWER!
LENIN POWER! (neregistrovaný)
14. 5. 2009 18:42 Nový

oracle 11

celé vlákno
my taky 11ku v produkci prakticky nikde nemame, zakaznici ji nepozaduji.
Snapshot
Snapshot (neregistrovaný)
14. 5. 2009 11:11 Nový

Re: isolation levels

celé vlákno
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.
ivan
ivan (neregistrovaný)
14. 5. 2009 14:00 Nový

Re: isolation levels

celé vlákno
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".
LENIN POWER!
LENIN POWER! (neregistrovaný)
14. 5. 2009 14:49 Nový

Re: isolation levels

celé vlákno
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?
ivan
ivan (neregistrovaný)
14. 5. 2009 15:21 Nový

Re: isolation levels

celé vlákno
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 :)
LENIN POWER!
LENIN POWER! (neregistrovaný)
14. 5. 2009 19:30 Nový

Re: isolation levels

celé vlákno
tim myslite rceni: az na stara kolena zblbneme tak pouzijeme hibernate a nikdo nic nepozna?
Snapshot
Snapshot (neregistrovaný)
14. 5. 2009 19:34 Nový

Re: isolation levels

celé vlákno
Hezky receno. :-) O tomhle produktu nechci ani slyset. ;_)
Snapshot
Snapshot (neregistrovaný)
14. 5. 2009 15:48 Nový

Re: isolation levels

celé vlákno
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.
Lael Ophir
Lael Ophir (neregistrovaný)
19. 5. 2009 19:08 Nový

Re: isolation levels

celé vlákno
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.
Snapshot
Snapshot (neregistrovaný)
20. 5. 2009 20:48 Nový

Re: isolation levels

celé vlákno
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. :-)
Snapshot
Snapshot (neregistrovaný)
13. 5. 2009 23:32 Nový

race condition

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. :-)
Jiří Petřík

Kvalitní článek

Č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!"
Jiri Cincura
Jiri Cincura (neregistrovaný)
16. 5. 2009 21:36 Nový

Odstranovani verzi radku ve FB

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

JC
Zasílat nově přidané příspěvky e-mailem