Názory k článku Úvaha ohledně zneužívání LIKE v databázích

me se na techto prikladech nelibi, ze nejsou realne. Me se to jeste nikdy nestalo, aby se server restartoval prave v tu chvili, kdy se provadi nejaky velky update. To ja pak mohu jit, zabudovat do masiny vadny hw-raid controler, nechat oracle-db bezet a pote, kdy uzivatel zjisti, ze ma misto dat salat rici, ze Oracle je na prd.

Nahoda je blbec ale statistika je ocelova, transakce jsou monstrance dnesni IT doby a plni zejmena tu ulohu, aby mohl management klidne spat.

Pokud se něco podobného stane u velkého updatu, pak je to pořád ještě ten lepší případ. A ne, nestalo se mi. Horší je to u malého updatu, kde je poškozeno jen pár záznamů a kolikrát na to nepřijdete. A to se mi už stalo. Troufám si říci, že pokud máte rozumně vytíženou databázi, tak při každém násilném restartu (já onehdá zakopl o napájecí kabel) se vám poškodí nějaká data. A teď jak z toho ven? Jedna cesta je používat stabilní OS, stabilní verzi databázového SW, pravidelně aktualizovat, UPS atd. Druhá cesta je použít transakční databázi. V každém případě je to však "vlastnost", o které by měl správce vědět a nějak ji řešit. Strčit hlavu do písku a tvářit se, že problém neexistuje... no to není dobré :-)

Tak vzdy mozte rollbacknut z pravidelnej zalohy, dolezite je, aku mate infrastrukturu. Pokial sa vo firme setri na vsetkom vratane HW, tak nech sa potom nedivi.

Vy snad zalohujete kontinualne?
A zakon schvalnosti funguje spolehlive: Prevazna vetsina poruch je tesne pred denni zalohou. Je snad lepsi ztratit cely den prace nez pouzivat transakce?

Ale kdepak, převážná většina poruch je právě ve chvíli, kdy zálohujete (je to i logicky zdůvodnitelné: disky prostě dostanou zabrat), takže i záloha je poškozená :)

Firmy naštěstí nepoužívají MySQL. Mají serverový HW (ne shit postavený v garáži), UPS, používají transakční DB engine a transakce na úrovni aplikačních serverů, zálohují DB i transakční logy, a drží vždy více záloh. "Webové aplikace" běžící na garážovém HW, LAMP a bez zálohování jsou z trochu jiné kategorie.

...s výjimkou Googlu... :o)

To se ovšem typicky týká služeb typu Google. Když taková služba ztratí kus indexu, nic se neděje, za nějaký čas ho získá zpátky. Když ale firma ztratí faktury, tak se už samy neobjeví.

Pokud jste ale byl v serverově nějakého hostingu, tak tam v klecích ležely počítače různých garážových firem, co mají své projekty na inetu. A to je přesně ta kategorie "splácám to v garáži, ono to něco udělá, a jestli se ta data ztratí, je mi to jedno".

jedno jim to neni, ale jsou lini zalohovat. Kdyz ztrati data pokladaji to za nevyhnutelne zlo.

Firmy naštěstí nepoužívají MySQL

No jó, ani Google ani Seznam nejsou firmy, to jsou zájmová sdružení :)

Ta finanční stránka věci zaslouží upřesnit. Například alza.cz má roční obrat přes 2 miliardy korun. To je průměrný obrat asi 230k Kč za hodinu. To jen abychom měli představu, jak levná či drahá je pro takový podnik licence Windows a MS SQL Serveru či Oracle.

Řeč byla o MySQL, a tam myslím není co řešit. Firebird neznám, nebudu tedy vynášet soudy.

SQL Server nebo Oracle vám dají minimálně to, že můžete začíst s verzí zdarma (SQL Server Express Edition), a poté jen za cenu licence přejít na větší DB server (SQL Server Standard Edition). Nemusíte u toho přepisovat aplikaci. Naopak když začnete na MySQL a budete chtít víc, budete aplikaci přepisovat, což je velký problém.

no treba kdyz mate oracle data guard nebo db2 hadr tak pri havarii neztratite ani jednu transakci a failover na backup server je za nekolik sekund. To je dost dobra vec pro online e=shop, nemyslite?

Dalsi vec je mit db ktera je odzkousena a ne kterou dela par zoufalcu po vecerech.

Dalsi hezka vec je ze profi databaze umi workload manager - nektere dotazy umi vyrizovat prednostne. Takze pak reporty nebrzdi OLTP a nemusite delat reporty nad historickymi daty, ale nad aktualnimy. Aktualni informace maji cenu zlata. Kdyz treba zakaznik zavola nasi reklamce a chce prave aktualni stav protoze pred nekolika hodinama spustil dulezitou a drahou kampan tak muze operatorka vyrobit a poslat sestavy, ktery se nevytvari zrovna rychle tak je dulezity aby to tu databazi nebrzdilo pro normalni provoz.

Krom toho dneska se databaze daji zalohovat velmi rychle ty 2 TB co tu mame se zalohuji na pasky bez disk spoolingu neco malo pres hodinu.

Takze jak tu mistni expert tvrdil 'databaze co muze mit i nekolik GB a to je pak problem' asi nikdy nevidel poradny HW.

ODG stalo $30k na procesor, ale nekdo mi tu psal ze ho uz v 11 EE davaji zadara.

To neni zadny hrdinstvi nacpat hodne dat do db, zalezi na tom jak to je pak rychly. mysql pri 10GB db uz zacne prohravat s cloudscape.

PGSQL ne pri vice datech taky strasnej opruz protoze vacuum. I na 30 GB trva vacuum full hodne dlouho (po 8 hodinach jsem to killnul) pokud je ta db rozfragmentovana treba 3 rocnim provozem.

A všechny ty tunitelný věci na z/OSDB2 nejsou pravěk? :-)

db2 9.7 ma taky mvcc a nemusi delat ani stupidni vacuum (pg, firebird) ani pouzivat rollback segmenty (oracle). Nacita starsi verze radek z transakcniho logu. Oracle kopiruje kazdou zmenenou stranku do rollback segmentu, to generuje znacne mnozstvi IO operaci i kdyz ji nikdo nebude cist. DB2 se s tim zacne zabyvat az v pripade ze nekdo chce stary snapshot dat cist.

No něco na upřesnění: Firebird většinu starých řádků odstraňuje průběžně na pozadí společně s běžným přístupem ke stránkám. Jakmile je zapotřebí provést "sweep", je to příznak, že se něco "podělalo". Pro starší verze řádku nemusí sahat do protokolu - nejenže transakční protokol nemá, ale proč sahat pro nejnovější verzi řádku do jedné (datové) stránky a pro dvě starší verze do dvou různých dalších stránek (protokolu), když je jednodušší a rychlejší všechno shrábnout z jediné diskové stránky? Opravdu "stupidní" řešení. :-)

Obvolaval jsem lidi at jim napisou ze chceme preportovat schema evolution z Z/OS do unix verze.

Schema evolution? To jako tohle?

DB2 UDB for z/OS now provides the ability to change the definitions of tables and indexes without dropping and re-creating the object. This capability significantly enhances both the availability of your database and the performance of data access.

Přidat sloupec do existující tabulky je "pokročílá fíčura"? Nejen že tohle Firebird umí, ale umí to už dvacet let, za plného chodu, je to transakčně opouzdřené a provádí se to lazy updatem dat (verzovaná metadata), takže se databáze nezasekne na půl hodiny, když přidám sloupec do desetigigabajtové tabulky.

precetl jsem si dokumentaci a firebird uklada vice verzi radek do stejneho bloku. kdyz zjisti ze je tam nejaka stara co se uz nepotrebuje (nevim zda i pri cteni bloku nebo jen pri zapisu) tak ji vygumuje. Nektere stare radky to ale nemusi timpadem vygumovat kdyz pak delsi cas k nim nikdo nepristupuje. pokud je takhle cisti i pri cteni bloku tak generuje zbytecne zapisove operace, ktere jsou pomale.

bez transakcniho logu nemuzete delat rollforward recovery, umi tohle firebird?

Pokud mate v logu starou i novou verzi radku jako mela db2 vzdycky tak se za delat i rollbackward recovery coz je velmi zajimava vec. Do logu se musi stara verze zapsat u db2 vzdy takze mvcc neni zadne io navic jako u oraclu a vetsinou se stara verze potrebovat nacist nebude, v pripade ze ano je tu jeste pravdepodobnost ze bude v log bufferu. Mne to nepripada jako nestastne reseni, je to asi to nejlepsi co se da zaridit. Vacuum i rollback segment free a navic setri misto na disku i v bufferpoolu.

no schema evolution umi i zajimavejsi veci: zmenit index podle ktereho se tablice clusteruje, pridat sloupecek do indexu. zbytek uz je docela nuda: pridavani sloupecku, prejmenovani sloupecku, zruseni sloupecku, zmena poradi sloupcu a zmena data typu. Nejzajimavejsi je ze je to provedeno okamzite bez cekani, fyzicky se ta tabulka presoupe casem. Pro data warehousing k nezaplaceni. podporovano je soucasne max. 255 verzi tabulky a 16 versi indexu.

adminovat db2 na zOS je narocnejsi nez Oracle, ma to hodne ruznych prepinacu. naopak db2 na unixu je velmi jednoducha a kazda dalsi verze je snadnejsi. Na zOS panuje opacny trend.

no kolik mela nejrychlejsi masina co jste kdy videl? Mame tu treba db server co dela 1.1M TPC-C. Konzolidujeme na nem databaze a stal necely $3 mega.

mysql nema rollforward recovery, umi jen prehravat SQL prikazy (to je znacne pomale) a jeste v tom ma zname races, takze je mozne dostat po prehrani SQL logu jina data.

S bastlem mysql se vubec nema cenu zabyvat.

express edice se daji pouzit na netrivialni produkcni aplikace bez problemu. Jsou to totiz plnohodnotne databaze, ktera maji nejaka technicka nebo jen licencni omezeni. Je to stejne vyspely kod, ktery pohani velke databaze. Neni to nejaky zmetek zbastleny v garazi. Navic mate k dispozici vsechny vyvojove nastroje a knowhow z velkych systemu.

Pokud trvate na tom ze chcete databazi s nulovymi pocatecnimy naklady tak jsou to prave. Zejmena mssql express je velmi dobra vec pro zacatecniky. Mrknete co vsechno ta databaze umi http://www.microsoft.com/express/sql/default.aspx a jake hezke tooly k tomu muzete mit. Vy to nevidite ze se vam v tom bude delat snadneji a rychleji? Lidska prace totiz stoji nemale prostredky.

My treba mame pgsql nasazeny v jedne aplikaci kterou jsme koupili i ze serverem. Ma to pro nas nevyhody:

* opruz s vacuum
* nutnosti porad nastavovat free space map velikost protoze db porad roste. uz se to asi zvetsovalo 3x. Vrchol demence nastavovat cosi podle velikosti db, jak to mame vedet jak rychle poroste?
* replikace slony1 se opravdu velmi spatne adminuje a je nespolehliva, krome toho ze je jeste dost pomala a ma overhead i na strane master db.
* aplikace v 8.3+ nechodi. Zpetna kompatibilita pgsql zjevne neni nic moc. Jak dlouho bude jeste podporovana 8.2, kdo vi.
* pri upgradu na vyssi verzi se musi udelat import/export dat coz je dost opruz pac se jedna o 24/7 aplikaci. Pgsql navic importuje data pomalu jako lemra.
* knowhow o administraci pgsql se spatne shani.
* administrativni nastroje nejsou - vse se dela z command lajny
* monitorovaci nastroje taky nejsou
a to jeste nemluvime o takovych vlastnostech jako HA a recovery

Takze databaze sice stala toho kdo tu aplikaci psal $0, ale TCO co nas to stoji je mnohem vyssi nez kdyby to bezelo na komercni databazi. Kdyby ji napsal pro express edici velke db, tak si normalne misto srani s pgsql koupime standardni edici a mame klid. Ted budete muset jeste nechat nekoho to aplikaci prepsat do jine db, coz jsou zase nemale naklady.

Kde jsme podle vas usetrili pouzitim pgsql? Ja tu inzerovanou usporu nikde nevidim.

INFO: vacuuming "alexa.resultcache"
INFO: scanned index "resultcache1" to remove 91 row versions
DETAIL: CPU 3.66s/6.46u sec elapsed 131.09 sec.
INFO: "resultcache": removed 91 row versions in 7 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.12 sec.
INFO: index "resultcache1" now contains 143751986 row versions in 497612 pages
DETAIL: 91 index row versions were removed.
74 index pages have been deleted, 74 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO: "resultcache": found 91 removable, 143751986 nonremovable row versions in 1647055 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 7503 unused item pointers.
73 pages contain useful free space.
0 pages are entirely empty.
CPU 14.72s/11.47u sec elapsed 361.19 sec.

autovacuum | on
autovacuum_analyze_scale_factor | 0.1
autovacuum_analyze_threshold | 250
autovacuum_freeze_max_age | 200000000
autovacuum_naptime | 60
autovacuum_vacuum_cost_delay | -1
autovacuum_vacuum_cost_limit | -1
autovacuum_vacuum_scale_factor | 0.2
autovacuum_vacuum_threshold | 500

na 8.3 migrovat nebudeme, k nicemu by nam to nebylo. db roste asi o 1 GB denne. Mame autovacuum + 1x denne vacuum. REINDEX ani VACUUM FULL delat nemuzeme, to by trvalo desitky hodin.

Ten /postmaster.pid to je taky opruz, mame tu napsano v poznamkach ze kdyz server spadne tak pgsql kvuli nemu nenastartuje. musi se rucne smazat. Boze to je spolehlivost. Ta pitoma databaze neumi ani spolehlive zjistit zda bezi?

pokud hroz´ı pˇreteˇcen´ı ˇc´ıtaˇce transakc´ı (varov´an´ı v logu) VACUUM FREEZE (1x za nˇekolik let). Neda se to zjistit nejakym selectem? ja nemam zajem se hrabat ve /var/log/messages - zaukoloval jsem admina.

Kdyby ta aplikace nebyla zbastlena v pythonu, nemela 6mb zdrojaku a nepouzivala modul import pg ktery je db neprenositelny tak uz by davno sel pg i se svym vacuum do haje. delat mvcc pres disk je pitomost.

Ne ze by se ten pgsql nejak vyrazne predrel pokud jde o odmazavani dat z velkych tablic. Pravda je tam DELETE CASCADE v relaci tak 1:80 ale stejne je to pomaly jak prase.
crawler=# DELETE FROM alexa.querycache where cached < '2009-03-17';
DELETE 67155
Time: 228892.404 ms

ted mne bezi DELETE + aktivni autovacuum cisti tabulky a dulezita query od klientu co bezi normalne tak 0.3sec normalne ted jede tak 7 sekund. To je radosti na starym belidle s db co nemaj workload manager a neumi poustet dulezite dotazy prioritne. Doufam ze neprijdou stiznosti.

Kdyz bezi autovacuum tak je to tedy znatelne pomalejsi:
crawler=# DELETE FROM alexa.querycache where cached < '2009-03-19';
DELETE 147471
Time: 1331750.621 ms

To vacuum je fakt za trest. Nerikal jsem vam ze je dulezite umet garantovat worst case? Takhle to moc nejde, napere se tam jedno automaticke vacuum a vykon jde do kytek.

taky by mne zajimalo proc se to vacuum chova takto, delam to na jedne tabulce a porad to cisteni restartuje. Proc tu tabulku a index musel cistit 3x? To to nezvladl v jednom pruchodu? To ale generuje strasnyho i/o.

crawler=# VACUUM verbose alexa.resultcache ;
INFO: vacuuming "alexa.resultcache"
INFO: scanned index "resultcache1" to remove 5592194 row versions
DETAIL: CPU 4.69s/18.03u sec elapsed 227.78 sec.
INFO: "resultcache": removed 5592194 row versions in 67423 pages
DETAIL: CPU 2.13s/0.45u sec elapsed 141.74 sec.
INFO: scanned index "resultcache1" to remove 5592205 row versions
DETAIL: CPU 4.69s/17.31u sec elapsed 170.26 sec.
INFO: "resultcache": removed 5592205 row versions in 63695 pages
DETAIL: CPU 1.85s/0.50u sec elapsed 80.27 sec.
INFO: scanned index "resultcache1" to remove 5005436 row versions
DETAIL: CPU 4.39s/32.36u sec elapsed 225.78 sec.
INFO: "resultcache": removed 5005436 row versions in 57313 pages
DETAIL: CPU 1.70s/0.46u sec elapsed 91.58 sec.
INFO: index "resultcache1" now contains 118633367 row versions in 498388 pages
DETAIL: 16189835 index row versions were removed.
87911 index pages have been deleted, 31703 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "resultcache": found 16189835 removable, 118633367 nonremovable row versions in 1649104 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9117033 unused item pointers.
289416 pages contain useful free space.
0 pages are entirely empty.
CPU 31.78s/74.51u sec elapsed 1226.20 sec.

Teda zajimalo by mne ciste teoreticky zda firebird s tim vacuum taky takhle blbne. jo recovery.conf to je od autoru pgsql opravdu kanadsky zertik. Pripadam si jak roce 1987.

A to se tu bavime o pididatabazi 30GB. Co budeme delat az db naroste na 200GB? To uz abychom to zacali prepisovat pro ten Oraakl. Tady vidite ze pgsql ma pri nasazeni v realne netrivialni aplikaci dost vazne problemy. A to nechavam stranou jeho narocnou administraci na lidskou praci.

Vy si porad myslite ze se nam to vyplati? Kdyby jsme tam meli neco z trojky db2, mssql, oracle tak tyhle db zadne z vyse uvedenych problemu (vacuum normal/full/freeze migrace verzi) nemaji. Administrace pomoci klikacich nastroju, zalohovani do TSM bez problemu, rollforward recovery se dela 1 - slovy jednim prikazem. Ten pgsql ma strasne velky TCO.

ad 8.4 migrace:
* aplikace nefunguje ani s 8.3 - musela by se upravit, asi nejak moc vyrazne ale:
* dump z 8.2 se do 8.3 nenacte kvuli fulltext indexum

ad myisam/memcache:
potrebuju persistentni data, vyroba tech sestav trva znacne dlouho. Tak si nemuzu dovolit po pripadnem restartu stroje dropnout cache. To je pak ta aplikace nepouzitelne pomala.

table partitioning nemam moc rad, driv se to muselo pouzivat ponevadz db2 umela na unixu/windows max. velikost tablespace 64GB coz byl ale desnej opruz. Osobne ho pouzivam jako nutne zlo jen kdyz se tablice nevejdou do tablespace. Nastesti s db2 9 uz tento opruz konci pac minimalni maximalni velikost tablespace je 2TB.

Ale uznavam ze to bude asi nejlepsi navrzene reseni. Musim rict ze je to tedy znacny administrativni opruz v pgsql:
http://www.postgresql.org/docs/8.2/static/ddl-partitioning.html
to se mi delat nechce, na to si nekoho najmeme, napsal jsem tehletem http://www.varlena.com/contactus.php
srovnejte to s db2
http://www.ibm.com/developerworks/data/library/techarticle/dm-0605ahuja2/index.html

jak vam crashla ta db2 a ktera verze to byla?

Obvykle neni duvod delat restore cele databaze, staci udelat restore jen toho tablespace ktere zarvalo. Vy nezalohujete po tablespaces? Pokud mate soft `db2 recovery expert` tak dokonce staci jen dropnout tu poskozenou tablici a udelat na ni rollforward.

Uznavam ze oracle je v tomto lepsi nez db2, ten umi delat restore na urovni db bloku (obnovi jen ty pozkozene bloky ze zalohy); je to jen ponekud administrativne narocnejsi na muj vkus. ja recovery databazi nedelam, mozna ze na to budou mit nejaky tooly.

Na ten EMS manager jsem se dival, vyzkousel jsem db2 verzi, ta mela vazny bugy (neukladala konfiguraci pripojeni k db, a taky pouzivala V8 syntax oproti V9 db) tak jsem ji smazal. Kdyz se holt setri na QA testingu tak pak nejsou sales. Na tu pgsql verzi EMS se podivam casem.

Takhle to dopadne kdyz se clovek necha premluvit na OSS databazovy soft. Je s tim jeden problem za druhym:
NOTICE: number of page slots needed (1950384) exceeds max_fsm_pages (1000000)
asi mi tim chce naznacit ze 30GB databaze potrebuje 2 mega? no dobre nastavil jsem mu je na 5 mega.

tato "nebezpecnost" je u mysql dan za rychlost a nie stastny navrh. Ale uprimne, stalo sa nikomu v realnom nasadeni, ze by sa server restartoval(spadol) pocas vykonavania updatu? Ja si myslim, ze pri spravnej udrzbe systemu to skoro ani nieje mozne.

Stalo. Poprvé to byl idiot, který vytáhl kabel. Podruhé to byl ten samý idiot kdy pro změnu vypl natvrdo diskové pole u špatného serveru. Ale uznávám, že to není obvyklé a že to byla naše chyba, protože jsme ho neměli do servrovny pouštět. Bohužel to byl správce druhého serveru a tak jsme ho tam pustit asi museli. Pazoury bych mu tehdy nejraději urazil.

Já jednou viděl server v kanclu, kde uklízečka brzo ráno přišla, vrazila vysavač do UPS, a začala kancelář luxovat. Po půl minutě overloadu UPSky provedl server automaticky shutdown. Dali červenou nálepku s upozorněním na zásuvku co byla na UPSce, a situace se opakovala. Dali dětské zámky na zásuvky, ale uklízečka je vyndala ze zásuvky. Takové osobě urazit obě ruce.

Která firma je tak blbá, že dá uklizečce (nebo jakémukoliv jinému neškolenému zaměstnanci) bez dozoru přístup k serveru?

Spíš dali serveru bez dozoru přístup k uklízečce. :]

To byla malá firmička, a server ležel kdesi v rohu v jedné kanceláři. Samostatná serverovna pro umístění dvou třech serverů je pro malé firmy drahá a zbytečná.

Spousta malých firem má malý box pod stropem (nebo jinde, ale pod stropem to bývá často, protože to nepřekáží) se servery a UPSkou a pod zámkem. Uklizečka prostě nemá mít přístup k serveru stejně jako nemá mít přístup do trezoru.

Jistě takové firmy jsou. Také je ale hromada firem, které nemají ani tu UPS, natož server v racku. Pokladna je ve formě kasičky zamknuté v šuplíku stolu, a HR materiály zamknuté ve skříni. Prostě jim to tak stačí, protože jsou malí. Doma svůj počítač asi nezamykáte do racku, i když jsou na něm citlivá data, a své papírové dokumenty nemáte v trezoru. Občas se podobně chovají i firmy o desítkách lidí, protože rády šetří a nemají ještě špatnou zkušenost.

Nemusíte psát, jak je fyzická bezpečnost důležitá. Dobře to vím.

Na linuxu s jeho demetni spravou pameti tam kdyz dojde pamet tak kernel odstreli ten oracle, pac ji ma nejvic

Tak hloupý zase OOM killer není. Nejdřív střílí procesy, které už dlouho nepožadovaly CPU čas. Krom toho mu lze celkem snadno říct (přes /proc/$PID/oom_adj), aby Oracle nechával až na později anebo vůbec nestřílel.

To bohužel nic nemění na faktu, že taková správa paměti je dementní. Ale to je na jinou diskusi.

To je skoda, ze je to na jinou diskusi, protoze me by treba celkem zajimalo, jake lepsi reseni byste navrhoval.

Ja myslim, ze prave o to se vyvojari jadra snazi. ;-)

Zkuste na rootu vyhledat OOM Killer v diskuzích ke článkům a zprávičkám. V krátkosti:
- nepoužívat fork/exec, ale nějakou obdobu CreateProces
- používat thready místo worker procesů
- při alokaci paměti jí opravdu vyhradit (tedy nelhat o paměti)
- když paměť není, tak se chovat dle normy jazyka C (alokace vrátí null),
- aplikace by měly být schopné správně reagovat na nedostatek paměti

Zkuste si to s Oraclem nebo MS SQL Serverem. Když selže alokace, tak zmenší nějaké buffery, nebo selže pouze provádění statementu, který paměť potřeboval. Slíbit procesům paměť, a pak je různě losovat a střílet, to je linuxové zvěrstvo.

Memory overcommit jde vypnout, ale pak brzo dojde paměť. Důvodem je nadužívání konstrukcí, které mohou spotřebovat spoustu paměti, ale většinou jí nepoužijí. Příkladem je fork a fork/exec.

Reakce na nedostatek paměti NENÍ v rukou programátora. Na Linuxi díky overcommittingu projde prakticky jakákoliv alokace, i když paměť není (malloc vrátí pointer). Když potom aplikace zkusí paměť použít, kernel zjistí, že aplikaci slíbil paměť, a teď jí nemá. Pak je čas na OOM Killer. Autor aplikace s tím moc nenadělá. Minimálně na Windows a Solarisu je situace řešená daleko lépe. O paměti se nelže, threading je dlouhá léta funkční, a příšernost fork/exec není třeba používat.

http://www.root.cz/zpravicky/steve-ballmer-linux-je-vetsi-hrozba-nez-apple/257669/

misto aby vylepsovali oom killer by mohli prestat lhat o pameti. Navic ta sama aplikace na windows kdyz se srovna s linux verzi tak linux verze zerou mnohem vic pameti.

Solaris taky neni zadny zazrak, 32 bit verze ma swap max. 2GB. 32bit solac je kupodivu vyrazne rychlejsi.

POSIX.2 z roku 1996 nezná vfork. Možná právě proto už 30 let aplikace vesele používají fork/exec. Navíc vfork má své vlastní problémy:
http://linux.die.net/man/2/vfork

Které konkrétní možnosti máte na mysli u CreateProcess?

dokavad nedefinujete 'netrivialni', tak se jedna bohuzel o kecy

jenomze mysql/isam neumi provest atomicky ani jeden (cely) prikaz.

Jak jsem říkal, v praxi mnou popsaný efekt nemá velký význam.

Používat LIKE jako náhradu fulltextu je samozřejmě hrubě špatně.

Takhle udělaný stavový automat přes tail cally ti bude konzumovat množství zásobníku lineárně závislé na množství projitých stavů. Gcc sice ty tail cally umí optimalizovat na skoky, ale nedělá to vždy (tato optimalizace nejde dělat, pokud se ve funkci vyskytuje pointer na proměnnou zásobníku a není možné dokázat, že ten pointer "neutekl" mimo tu funkci) a navíc to uživatel nemusí kompilovat pomocí gcc nebo nemusí zapnout optimalizace.

Tady není otázka, zda to je nebo není lépe čitelné, tady je problém, že takhle napsaný stavový automat nebude při dostatečně dlouhém vstupu fungovat.

Taky jsem si to myslel, ale nebyl jsem si jisty. Diky.

Taky poslouchám Leonardo, je to príma rádio!
:)

Presne tak. Moje zkusenosti to dokazuji taky. Ony byt dobrym IT zakaznikem se taky musite naucit. Normalni predstava: dam vam par desitek mega a za 2 roky si prijdu pro aplikaci je dost najivni.

> Nemůže ovšem vyhovět takovým přáním, které si protiřečí.
proto musi u zadavatele existovat osoba ktera ma konecne slovo nad tim co se bude ci nebude delat.

Souhlas s vámi i předřečníkem.

Asi pracujete s jinými zákazníky, nežli já. Business logika je vše, jen ne logická. Změny v ní se udělat nedají, protože jsou již podepsané smlouvy a v nich jsou ty protimluvy vytesané do kamene; a smlouvy se změnit nedají protože druhá strana, zákazníkův klient, by se mohla vyzout ze svého závazku.

Kromě toho, projekt na zelené louce dnes už snad nikdo nedělá, ať už bohužel nebo bohudík. V každém současném projektu se navazuje na stávající systémy se všemy jejich chybami (které je nutno považovat za vlastnosti, neboť instalace jejich opravy stejně bude trvat přes rok) a téměř jistě se nějaký systém nahrazuje, tj. musí se data z něj zmigrovat a musíme nějakou dobu umět běžet side-by-side. Už jsem viděl hodně architektur, které musely být z těchto důvodu zprzněny.

A pořád se pohybujete v idealizovaném kruhu "předpokládejme, že se aspoň ten náš projekt od začátku udělal správně".

No to jsou takove rekl bych trochu akademicke uvahy. V tabulce mam hodne sloupcu, pokud tam hodne sloupcu patri - kdyz udelam normalni formu a vyjde mi do tabulky 20 sloupcu (nebo co vlastne znamena hodne?), tak to budu jen proto nejak delit?. Samozrejme ze dotaz na vice sloupcu muze trvat dele, ale pokud opravdu chci vsechny sloupce, tak to je irelevantni. select * ma v produkcnim kodu omezene vyuziti a byva casto pouzit chybne (coz byva tim ze programuje kazdy kdo ma ruce), ale ma ho.

Hm to je casty problem - skodlive zevseobecnovani nejakeho pozorovani. Taky jsem videl desive pouziti "select * into a, b, c", ale chybne lze pouzit cokoliv, kdyz se to neumi.

Napriklad tato funkce k vyzvednuti radku z tabulky pro dalsi zpracovani v PLSQL je zcela spravna, robustni, elegantni...

function fetch_account(account_id in account.id%type) return account%rowtype is
  acc_row account%rowtype;
begin
  select * into acc_row 
    from account 
    where id = acc_id;
  return acc_row;
end fetch_account;

Kdyby toto nekdo prepsal na jednotlive sloupce (i kdyby jich bylo treba jen 5), tak mu urazim pracky :-) Takto funkce dela presne to co chci a bude to delat i kdyz z tabulky sloupce uberu, pridam nebo prejmenuju, cehoz s vyjmenovanim sloupcu nemohu dosahnout. Proste select * neni spatny, spatni mohou byt pouze programatori, kteri ho neumi pouzivat.

Samozrejme zalezi na tom, jak to udelam (viz muj prispevek o kousekl vyse). Proste kazda konstrukce ma nejake vlastnosti, ktere je treba znat a brat je v uvahu. Moudra typu "select * je spatny" a podobna jsou spatna, protoze zjednodusujici.