Administrace komentářů

Pokud vim tak exekucni plany sdili jedine Oracle. Cela myslenka sdileni exekucnich planu vychazi z predpokladu, ze autor aplikace neni idiot a ze pouziva rozumne mnozstvi SQL statementu. V Oracle se rozlisuje tzv. soft parse(plan se najde podle hashe SQL v SGA) a hard parse(cely exekucni plan se vymysli a ulozi do SGA). Proti sdileni exekucnich planu mam jeden priklad z praxe. V DB je tabulka T a ma sloupce (PK1, ANAME1, AVALUE1, ..., ANAME24, AVALUE24). Inserty do teto tabulky vklada nejaky JAVA sr*c, ktery dynamicky "vymysli" SQL statement podle toho ktere sloupce jsou insertu zrovna pouzity. Hadam ze programator ktery tohle vymyslel byl na sebe hodne pysny, kdyz to odladil. Tabulka T ma 24 "atributu" => existuje 2^24 (16,7 milionu) ruznych insertu. A  LRU cache Oracle se poctive snazi udrzet exekucni plany vsech insertu, bohuzel ma SGA omezenou velikost a proto se ji to nikdy nemuze podarit a z SGA "vypadavaji" i SQL statementy, ktere by tam mely zustat. Na RACu se navic sdili exekucni plany i mezi nody, takze kazde parsovani vyzaduje komunikaci po siti mezi nody clusteru.

Na druhou stranu treba Informix exekucni plany nesdili. Kazda session si drzni svoje exekucni plany. Proti tehle strategii mam zase jiny protipriklad z praxe. Nekdo rekl JAVA programatorovi ze je dobre pouzivat prepared SQL statementy, buhuzel uz mu nikdo nerekl ze pokud pouzitje Prepare, tak taky musi pouzit Release. Jinak si bude Informixova session pamatovat exekucni plan dotazu navzdy. JAVA programator predpokladal ze uvolneni prostredku za nej vyresi GC. Cim system bezi dele, tim vice pameti zabiraji exekucni plany jednotlivych SQL dotazu. Za tyden je to cca 8GB RAM. Ten system stal spoustu penez, vsechno je navrzeno aby to bylo vysoce dostupne a presto je to potreba kazdy tyden restartovat.

Prvni priklad by v pohode fungoval na Informixu a ten druhy zase na Oracle. Takze sdileni exekucnich planu neni zadna vyhra, casto to beh zrychli ale nekdy to muze spusobit spoustu problemu.