čtvrtek 4. února 2010

Rychlost načítání závislého promptu

Na úvod – tento příspěvek neobsahuje žádný „how-to“ postup, který (zatím) neexistuje (?!). V rámci snahy dosáhnout komfortního prostředí pro uživatele reportů jsem se snažil zrychlit načítání obsahu závislého promptu.

Problém - spočívající v dlouhé době odezvy způsobený generováním seznamu hodnot pro závislý prompt - je tím palčivější, čím „větší“ jsou dimenze, které mají být promptovány. Problém budu ilustrovat na objektech defaultního schématu Oracle databáze – schématu oe.

Použitá metadata:



Report + prompt:


Popis problému:
V případě výběru konkrétního EMPLOYEE_ID (např. 153) se v CUST_LAST_NAME závislém (Constrain = yes) promptu zobrazí pouze příslušní zákazníci (Welles, Pacino, Martin, Landis, Fawcett). Nastavení závislostí mezi prompty je určitě dobrá věc, neb koncový uživatel není obtěžován nerelevantními možnostmi. Každé takovéto přegenerování závislého promptu však trvá. Snažil jsem se promtu pomoci v rychlosti použitím cache.

Ačkoliv se však následující dotaz uloží do cache:


Při změně promtu EMPLOYEE_ID (a vygenerování „podobného“ dotazu)se Cache nepoužije:


Druhý dotaz reprezentuje podmnožinu dotazu prvního. Podle aktuální dokumentace by jednoznačně měl nastat tzv. cache-hit. Obrátil jsem se tedy na Oracle support. Popisovat vývoj celé komunikace by zabralo mnoho řádek - alespoň zkratkovitě: Nejprve jsem dostal informaci , že se jedná o žádoucí chování. Při poukazu na rozpor s dokumentací nakonec připustili, že se jedná o chybu, ale pouze dokumentační - při „dimension-only“ requestech je pro cache hit nutný tzv. „exact-match“ (v projekční i restrikční části dotazů). Reakcí tedy měla být změněná dokumentace.
Dalším krokem bylo poukázaní na zajímavý fakt: použije-li se stejný scénář oproti XML datům, cache hit nastane podle očekávání – najednou „exact-match“ potřeba není. Nakonec byl tento request uznán jako Bug 8541767 a byl zařazen do vývoje release 11. Dokumentační Bug byl také vytvořen.

Pořád mám ale pochybnost. Že bych byl první (ve skutečnosti jeden podobný zapadlý request existoval a byl zamítnout … ale i tak – druhý a nikdo jiný?), kdo se s tímto problémem setkal? Takže třeba něco přehlížím, neznám nebo se v něčem velmi pletu?


Václav Bíba (konzultant společnosti NESS)

Žádné komentáře: