pondělí 31. března 2008

1. Oracle Czech BI/DW Expert Bootcamp

V pátek 28.3.2008 proběhl 1. Oracle Czech BI/DW Expert Bootcamp, kterého se zůčastnilo 12 vybraných BI/DW architektů a konzultantů od různých Oracle partnerů:
  • Aleš Jeník (Capgemini)
  • Bronislav Lukáš (BSC)
  • Jakub Genža (Sophia Solutions)
  • Jan Jůza (CCA)
  • Jiří Doubravský (PIKE Electronics)
  • Michal Zima (Oracle)
  • Miroslav Petr (Adastra)
  • Pavel Holý (Logos)
  • Peter Hora (Semanta)
  • Petr Jurášek (IT Systems)
  • Petr Šimbera (Simora)
  • Václav Hubka (HP)

Agenda setkání byla následující:

Prezentace 1. části - Úlohy, které jsem vyřešil a chci se o ně podělit s ostatními (ostatní bude publikováno formou článků na BI/DW Blogu):
  • Pavel Holý
    1. Vytvoření BI/DW PoC nad reálnými daty s reálnými reporty
    2. Zrychlení odezvy dotazů pomocí „inteligentního cachování“
    3. Napojení na MS OLAP přes XMLA
    4. Zobrazení dat v Azbuce / více-jazyčnost
  • Bronislav Lukáš
    1. Start OC4J bez přihlášení uživatele
    2. Nové „view“ ve fyzické vrstvě
  • Michal Zima
    1. Praktické zkušenosti s implementací Analytických aplikací
    (Oracle BI Applications / Siebel Business Analytics)
  • Miroslav Petr
    1. Kombinovaný dotaz + detail pages
    • Kombinovaný dotaz: jedna výzva + 2 různé atributy
    • Kombinovaný dotaz: nezadaná výzva + 2 různé atributy
    2. Vazba mezi atributy různých datových typ
    3. Nežádoucí formátování hodnot při exportu do Excelu
    4. Proměnné (suma poznatků o proměnných různých typů)
  • Jiří Doubravský
    Problem s PERF_PREFER_INTERVAL_STITCH_JOIN

čtvrtek 27. března 2008

Jak na nevyvážené (Value-based / Unbalanced / Ragged) hierarchie

Ve světě OLAPu existuje několik druhů hierarchií. Mezi nejznámější z nich patří:
  • Level-Based nebo také Balanced
  • Value-Based nebo také Unbalanced / Ragged
Level-based hierarchie (stejně dlouhé větve dimenze) se používají nejčastěji a můžeme je najít např. v dimenzi časové, produktové, geografické, atd.
Value-based hierarchie (nestejně dlouhé větve dimenze) se používají méně a můžeme je najít např. v dimenzích pro organizační strukturu.

Oracle Business Intelligence EE/SE-1 nativně podporuje Level-based hierarchie. V případě, že chcete vytvářet Value-based hierarchie, pak můžete buď:
  • Protáhnout nevyvážené větve "až dolů" (tzn. na chybějících úrovní hierarchie musíte buď zobrazit stejnou hodnotu jako je na vyšší úrovni, a nebo nic ("null").

  • Nebo použít řešení, které vytvořil Kurt Wolff a které naleznete zde.

Erik Eckhardt (eec).

úterý 25. března 2008

Jak zajistit, aby uživatelé viděli v reportech / dashboardech pouze ty informace, na které mají nárok (Row Level Security)

Mezi další požadavky na Analytický systém patří bezpečnost. Bezpečnost v rámci Oracle Business Intelligence můžeme rozdělit do několika oblastí:
  • Ověřování (Authentication) více zde

  • Oprávnění (Authorization)
    • Na objekty – tzn. na BI metadata (Cílové oblasti, dimenze, ukazatele, ...), na reporty, dashboardy, záložky atd.

    • Na systém – tzn. na BI nástroje (BI Answers, BI Delivers, ...) a na operace, které lze provádět v rámci jednotlivých nástrojů (např. tvorba reportu, prohlížení/úprava dashboardu, plánování distribuce sestav, zpětný zápis, ...)

    • „Na data - řádky“ (Row Level Security) – tzn. kontrola přístupu na obsah (řádky), který vidí uživatel v rámci Analytického systému (tj. v rámci reportu, dashboardu, sestavy, atd.)

Oprávnění „na data - řádky“ (Row Level Security)
To, čeho je třeba docílit je jednou vyvinout report nebo dashboard a pak v něm uživatelům (dle jejich role a oprávnění) zobrazovat pouze ty informace, na které mají nárok - tzn. je třeba nastavit Row Level Security.

Globální Dashboard "Prodeje" – Přístup uživatele s plným oprávněním
(vidí informace za celou firmu)



Globální Dashboard "Prodeje" – Přístup manažera pobočky ČR
(vidí informace pouze za danou pobočku)



„Row Level Security“ můžete nastavit globálně pro celou databázi – podmínkou je, že vybraná databázová technologie tuto bezpečnostní politiku podporuje. V případě, že zdrojová data jsou uložena v databázi Oracle, pak můžete využít funkcionalitu Virtual Private Database (VPD). Nespornou výhodou VPD je, že nezáleží z jakých nástrojů/aplikací budou uživatelé přistupovat na data (tj. Oracle BI, jiné BI, TOAD, SQL Navigator, SQL Plus .... aplikace) – vždy uvidí pouze ta data, na která mají nárok.

V případě, že zdrojová databáze neumožňuje použít „Row Level Security“, pak ji můžete nastavit v rámci Oracle Business Intelligence EE / SE-One. Postup viz. níže.


Postup
1/ Někde (v databázi, Excelu, LDAPu) je třeba udržovat informace o tom, kdo má na co práva (v mém případě mám v db tabulku REGION_MANAGER obsahující informace o loginu uživatele do BI a pobočce/regionu na kterou má oprávnění).



2/ Pomocí Variable Managera (menu Manage > Variables ...) založte Session Variable Inicialization Block, který vybere pro právě zalogovaného uživatele (proměnná :USER) data z Vaší security tabulky (u mne je to výše uvedená tabulka).
Výsledný řádek dotazu uložte do Vaší proměnné, na kterou se dále budete odkazovat (v mém případě je to proměnná PRODEJ_REGION). V případě, že uživatel má právo na více regionů (tzn. select bude vracet více jak jeden řádek), je třeba, aby cílová proměnná byla typu Row-wise (více o použití Row-wise proměnné najdete zde v bodu 8).



3/ Pomocí Security Managera (menu Manage > Security ...) založte skupinu (v mém případě skupina „Regionalni manager“), přes kterou nastavíte restrikce/práva vybraným uživatelům. Poté přidejte uživatele do skupiny (u mne je to uživatel czmgr a skmgr).



4/ Pro založenou skupinu vyberte volbu „Permissions...“



5/ Přejděte na záložku Filters a zde vyberte a nadefinujte požadované restrikce/filtry


  • Pro sloupec „Name“ vyberte z Prezentační vrstvy Cílovou oblast a složku (postupně všechny složky tj. všechny dimenze a fakta z Vašeho modelu), pro kterou chcete nastavit omezení

  • Pro sloupec „Status“ vyberte Enable
  • Pro sloupec „Business Model Filter“ zadejte podmínku, která omezuje data pouze na ta, na která má mít právě přihlášený uživatel právo, tj. hodnota sloupce = Vaše proměnná z kroku 2 (v mém případě sloupec STAT z dimenze GEOGRAFIE obsahuje názvy všech poboček a proměnná PRODEJ_REGION obsahuje pobočku právě přihlášeného uživatele – tzn. filtr zajišťuje restrikci na data o jeho pobočce).


Všimněte si, že filtr ("Prodejní analýzy".GEOGRAFIE.STAT = VALUEOF(NQ_SESSION."PRODEJ_REGION")) je zkopírován pro všechny složky (tj. všechny dimenze a fakta) z modelu. To je z důvodu, aby byla zajištěna stejná restrikce i pro jiné dimenze v cílové oblasti. Tzn. když si uživatel do reportu vloží pouze sloupce Výnos, Náklad a Prodejní kanál, tak stejně v reportu uvidí pouze informace o Výnosech a Nákladech přes Prodejní kanály za jeho pobočku (tzn. sloupec STAT v reportu nemusí být uveden).



Erik Eckhardt (eec).

čtvrtek 20. března 2008

Oracle Business Intelligence a škálovatelnost

V případě, že Vás zajímá škálovatelnost Oracle Business Intelligence, pak se podívejte na níže uvedené dokumenty, které popisují:

eec.

pondělí 17. března 2008

Jak zajistit překlady (více-jazyčnost) pro repoty a dashbordy

V článku „Jak zajistit více-jazyčná / více-pojmová metadata“ je popsán postup, který umožní řešit požadavek na více-jazyčnost metadat – tedy jak zobrazit různým skupinám uživatelů položky z BI Metadata repository (tj. Cílové oblasti, složky, dimenze a ukazatele) v jejich preferovaném jazyku (tj. česky, anglicky, německy, atd.).

Mezi další požadavek samozřejmě patří, jak to samé (tj. překlady) zajistit pro vytvořené dashboardy (názvy, záložky, popisy, atd.), reporty (názvy, nadpisy, texty, popisy) a ostatní objekty uložené v BI Web Catalogu. Postup, jak tento požadavek řešit v rámci Oracle BI EE/SE-1 naleznete níže.

Postup

1. Spusťte Oracle BI Catalog Manager a otevřete Váš BI Web Catalog v Offline módu



2. Z menu Tools spusťte utilitu „Export Captions“



3. Zadejte cestu, kam se mají vyexportovat popisky



4. Pro každou sdílenou složku uloženou v BI Web Catalogu se vytvoří jeden XML soubor obsahující popisky pro všechny objekty uložené v dané složce.



5. Struktura XML souboru je jednoduše čitelná a obsahuje popisy jednotlivých objektů uložených v BI Web Catalogu – tj. Složky, podsložky, názvy dashbordů, názvy stránek dashboardů, názvy objektů na dashbordu (případně obsahu), názvy a obsah filtrů, názvy a obsah reportů (nadpisy, podnadpisy, texty, ...) atd.

Vše vždy začíná tagem „WebMessageTable“, pod ním je tag „WebMessage name“ a pod ním je tag „Text“. Nyní přeložte / nechte přeložit obsah v tagu „Text“ do požadovaných jazyků – co jazyk to jeden XML soubor.



6. Poté je třeba založit správnou adresářovou strukturu v „home adresáři“ BI Presentation Serveru a do ní nakopírovat přeložené XML soubory.

V adresáři ...OracleBIData\web\ založte podadresář „res“, do něj adresáře l_[kód jazyka] a do nich adresář „Captions“. Do adresářů Captions nakopírujte přeložené XML soubory a restartujte službu BI Presentation Server.


Výsledek

Po přihlášení ...


v češtině vidí uživatelé dashboard, jeho obsah (reporty, filtry, ...) ...


... a položky katalogu (názvy složek, podsložek, reportů, filtrů, ...) v češtině.



Po přihlášení v angličtině vidí uživatelé vše v angličtině.




Erik Eckhardt (eec).

čtvrtek 13. března 2008

Kolektivní nezodpovědnost - část I.

Úvod

Níže uvedený příspěvek se Vás bude týkat ve dvou případech, pokud ve Vaší společnosti:

1) existuje BI/DWH řešení a vy pracujete s jeho výsledky

2) zatím BI/DWH řešení neexistuje ale v krátké době Vás čeká jeho příprava

Ostatním lze nabídnout informace k zamyšlení nad jejich stávajícími systémy, protože to, co je zde prezentováno se ve velké míře týká i klasických OLTP systémů a reportingových řešení.

Pro ty z Vás, kteří se potýkají s nízkým výkonem existujících BI/DHW řešení je primárně určena tato první část, v které jsou nastíněny potenciální příčiny problémů, které vedou ke stavu, kdy se znehodnocuje Vaše investice do BI/DWH řešení. V závěru je navrženo několik kroků kudy ven z tmavého lesa.

Druhá část je zaměřena na prevenci, protože ta je samozřejmě klíčová. Nejen proto, že je výrazně levnější než úprava existujícího řešení, ale má největší vliv na celkovou životnost a provozovatelnost řešení.

Část I: Existující BI/DWH řešení

Když Váš pracovní den začíná přibližně takto:

Chcete si otevřít přehledové reporty, které Vám jednoduše prozradí, jak je na tom Vaše firma, resp. Vaše oddělení….a reporty se včerejšími daty nejsou připravené.

Když pátrátr po příčině dostává se Vám odpovědi…."Reporty budete mít až zítra, když se zadaří, v noci jsme měli problém a teď to pracuje pomalu...Oracle databáze nestíhá...hodně dat….chce to pořádnou databázi…víc s tím udělat neumíme"

Na Vaši připomínku, že stejnou odpověd Vám dávají poslední dva měsíce dostáváte odpověď:

"Data v datovém skladu rostou rychle, stávající řešení nezvládá nárůst dat, datový sklad začíná pravidelně dobíhat až odpoledne..."

Na Váš oprávněný dotaz, jestli s tím zkoušeli něco dělat odpovídá IT „mantrou“:

"Aplikační administrátoři hledali příčinu, ale vše se tváří že běží, bude to v nízké rychlosti databáze. Databázoví administrátoři koukali na databázi, a ta jede, parametry jsou stále stejné, žádná změna nebyla, čeká se na I/O. Systémáci koukali na server, ten má zatížení CPU jen 30% v serveru to není. Administrátor diskového pole hlásí průměrné zatížení diskového pole, při poslední kontrole ze strany automatických ladících mechanismů pole nebyly žádné návrhy na zlepšení. Dodavatel řešení navrhuje upgrade řešení s rozpočtem jednotek milionů.Howgh“

Když se obrátíte na dodavatele HW (servery, disková pole) a poskytovatele SW, rádi Vám nabídnou upgrade na lepší HW (pár GB paměti navíc, výkonnější CPU, případně dodavatel SW pár dalších licencí a další featurky databáze....ovšem s detailem, že vy na to musíte sehnat rozpočet....

V tomto případě pokračujte ve čtení, protože se pravděpodobně stáváte obětí „kolektivní nezodpovědnosti“.

Kolektivní nezodpovědnost

Kolektivní nezodpovědností je nazýván stav, kdy nelze jednoduše ukázat prstem na jednu příčinu „pomalosti“ řešení resp. na jednoho člověka, který je odpovědný za aktuální problémy provozovaného IT řešení (a kterého lze po právu ztrestat), která když je vyřešena, tak je zase vše v pořádku. Je to souhra několika faktorů a částečné odpovědnosti více pracovníků v době přípravy řešení a jeho následného provozu, což v důsledku znamená právě kolektivní nezodpovědnost.

Pro čtenáře, které trápí problémy stávajícího BI/DWH řešení zde uvádíme tabulku potenciálních příčin problémů týkající se provozu řešení:


Tab 2: Klíčové faktory v období provozu řešení

Faktor

Popis

Odpovědnost

P.1

Struktura a nastavení odpovědnosti jednotlivých oddělení IT provozu

IT manager

P.2

Motivace IT provozu ke komplexní péči o řešení

Board/IT manager

P.3

Podpora IT oddělení při zavádění komplexní péče

Business vlastník
/ Board

Faktor P1: Struktura IT Operations

Schéma č.1 znázorňuje standardní architekturu informačních systémů a její mapování na klasickou organizační strukturu IT.

Objasněme si velmi stručně, jaké jsou odpovědnosti jednotlivých rolí ve vazbě na řešení:

Role

Náplň role

Správce reportingové platformy

- Správa uživatelských účtů a profilů

- Přístup k reportům

- Deployment nových reportů

- Správa distribučních kanálu pro reporty

Správce datového skladu

- Zajištění chodu datového skladu a aktualizace jeho dat

- Monitoring procesů aktualizace DWH, detekce chyby, opravné spuštění

- Reakce na nestandardní stavy (výpadky zdrojových systémů, opravné dávky, atd)

-

Databázový administrátor

- Správa databází (databázových instancí)

- Správa uživatelských účtů v DB

- Správa prostředků databáze (role, systémová práva, tablespaces, využití prostoru atd.)

- Konfigurace a provádění zálohování databází ve spolupráci se systémovými administrátory

- Zajištění obnovy databáze po poruše HW

Systémový administrátor, (Správce serveru)

- Správa operačního systému

- Správa uživatelů na úrovni OS

- Monitoring zatížení serveru

- Zálohování serveru

- Aplikace patchů operačního systému

Administrátor SAN infrastruktury

- Konfigurace a přidělení úložné kapacity v rámci SAN podle požadavků IT

- Monitoring diskových polí

- Monitoring požadavků na úložnou kapacitu v rámci SAN

Pozn. SAN – Storage Area Network


Kde je potenciální problém ?

  1. Každý tým si obhospodařuje pouze svěřenou část infrastruktury
  2. Úzké zaměření týmů – systémový administrátor toho ví velmi málo o databázích a naopak. Stejně tak aplikační administrátor ví málo o fungování technologií.
  3. Náplň práce představuje rutinní udržování systémů v chodu, které je dost často díky divokým kombinacím použitého software časově náročná
  4. Odpovědnost resp. hodnocení IT je zaměřené na udržení systémů v chodu, případně na výkonnostní ukazatele jednotlivých součástí infrastruktury


Závěr:

  1. Chybí komplexní pohled na řešení skrze jednotlivé prvky infrastruktury – jak nastavit diskové pole, servery, operační systém a databázi tak, aby byla infrastruktura nastavena na optimální výkon nejen pro řešení typu BI/DWH
  2. Neinvestuje se do průběžného ladění a drobných vylepšení, které mohou mít zásadní vliv na nárůst výkonu řešení
  3. Chybí investice do know-how pracovníků IT (školení, užší spolupráce s dodavatelem řešení za účelem pochopení potřeb řešení, proškolení IT pracovníků z pohledu funkcionality BI/DWH řešení a nároků kladených na infrastrukturu)
  4. Velmi často není využíváno možností infrastruktury nakoupené za vysoké finanční částky (typicky disková pole, využití paměti serveru atd)

Faktor P2: Motivace IT provozu ke komplexní péči o řešení


Pokud je dodavatelem řešení solidní firma se zkušenostmi v dané oblasti je v rámci projektu definována role Technical Solution Architect (TSA), někdy také pojmenovaná Technology Solution Architect. Tato role představuje párovou dvojku k roli Business Solution Architekta.

Business solution architekt zodpovídá za obsahovou správnost řešení tj. aby bylo v souladu s business požadavky. Technology solution architect zodpovídá za technickou úroveň řešení, zajištění požadovaného výkonu a začlenění řešení do IT infrastruktury zákazníka dle požadavků.
Do doby předání řešení do provozu zodpovídá za architekturu řešení dodavatel.Po akceptaci je řešení převzato do provozu.

A od té doby představuje toto řešení víceméně sirotka, který roste „jako kůl v plotě“. V typické BI/DWH řešení objem dat roste, provádí se dílčí změny funkcionality na základě změnových řízení, zkrátka se jedná o mnohem dynamičtější systém než standardní transakční aplikace.

Protože toto řešení nemá po předání do provozu rodiče, který by se o něj s péčí starali, stává se z něj často divoký nevychovaný výrostek, který vám v důsledku může provádět hodně nepříjemné věci (nekontrolovatelný nárůst objemů dat, výkonnostní degradace, zahlcování infrastruktury, vynucení upgrade HW atd).

IT provoz je zodpovědné pouze za zajištění provozu, ne za komplexní péči o řešení. Stávající úroveň péče se s ohledem na možnosti a znalosti oddělení redukuje na základní kontroly běhu a v případě závažných chyb pak na snahu o opravu této chyby a opětovné zprovoznění.

Komplexní péčí rozumíme:

- Revize návrhu architektury a sizingu v době definice řešení a vyjasnění si sporných otázek s dodavatelem řešení

- Pravidelná výkonnostní profylaxe ve formě sledování trendů a jejich predikce

- Průběžný výkonnostní monitoring a ladění

- Používání možností infrastruktury k dosažení nutného výkonu

- Vyhodnocení navrhovaných funkčních změn na celkový výkon řešení

- Vytvoření budgetu na komplexní páčí v rámci výpočtu TCO nákladů na řešení


Z výše uvedeného seznamu je zřejmé, že je to činnost náročná na znalosti i na čas, a to nejen technologické. A typické IT oddělení na tyto činnosti nemá kapacitu a bohužel ani budget.

Dopad:
Business vlastník investuje vysoké částky do pořízení infrastruktury a řešení. Pokud řešení typu BI/DWH nemá po přechodu do produkce zajištěnu komplexní péči, dochází k postupnému znehodnocení této investice. V některých případech se jedná o velmi rychlé znehodnocení do 1 roku provozu. V horším případě na business vlastníka čeká jednání o úpravách systému a případný upgrade infrastruktury, aby alespoň v minimální míře byl schopen toto řešení používat.

Faktor P3: Podpora IT oddělení při zavádění komplexní péče

Nemysleme si, že IT oddělení je skupina sabotující Váš business. Tito lidé velmi často ví, kde systém pálí pata, ale nemají možnost s tím něco udělat. Proto se budou dál snažit udržet zahlcující se systém, vždyť jde i o jejich profesionální čest.

Je třeba si ale uvědomit už na počátku návrhu řešení, že právě tito lidé se budou muset o Váš systém starat a je třeba s nimi o připravovaném řešení mluvit a diskutovat, aby bylo navržené řešení akceptovatelné pro obě strany.

Co je vhodné komunikovat:

Od business vlastníka k IT

Od IT k business vlastníkovi

Varianty technického řešení, hledání shody

Nové technologie znamenají potřebu školení, když začleníme do nákladů projektu, jsme schopni akceptovat danou technologii

Jaké jsou odhadované náklady na zajištění komplexní péče, které máme zahrnout do rozpočtu (náklady na práci IT, zaškolení IT pracovníků atd)

Komunikovat rozumné odhady a nestažit se tlačit za každou cenu na pilu.

Jakou formu a rozsah dokumentace potřebujete pro zajištění komplexní péče

Jako business vlastník řešení by jste měli být připraveni na náklady spojené s komplexní péči o řešení.

Potřebujeme provést změny v běžícím systému, podpořte náš požadavek na budget.


Bohužel pravidlem je, že místo aby business a IT táhlo za jeden provaz, tak v převážné většině velkých společností je to právě naopak. Velmi často pracuji v roli, kdy plním roli posla a vyjednavače mezi business vlastníkem a IT oddělením. Setkávám se s názorem businessu, že IT brzdí jejich business, protože ten a ten systém nestíhají zavést a přitom je to tak jednoduché, jak říkal jeho distributor resp. prodejce. Z druhé strany zase zaznívá nelichotivé vyjádření o technických schopnostech business oddělení.

Nevím, zda je to dáno historickým vývojem, ale vím jistě, že je třeba to změnit, protože dobře a kooperativně fungující IT v dněšní době představuje přímou konkurenční výhodu a možnou výraznou úsporu v celkových nákladech na IT.

Závěr

Na závěr této části uvádím pár rad, jak se vyhnout problémům se zajištěním provozu systému:

1. Věnovat čas a úsilí v době návrhu řešení tomu, aby byla vybrána kombinace technologií, které bude plnit potřebné cíle dané business zadáním, ale nebude znamenat „vykradení“ budgetu na projekt.

2. Trvat důsledně na zavedení a dodržování procesů komplexní péče při provozování BI/DWH řešení včetně vyčlenění budgetu na tuto činnost.

3. Definovat v rámci projektu výkonnostní ukazatele, které budou klíčové pro provoz řešení

4. Realisticky pohlížet na možnosti technologií, obchodník s nimi není ten nejvhodnější člověk, který vám popíše reálné možnosti a omezení daných technologií.

5. Využít možnosti nezávislého auditu řešení již ve fázi návrhu řešení, což v důsledku může ušetřit vysoké náklady na jeho případnou změnu v provozu.

6. Vyjednávání typu Win-Win při tvorbě technické architektury řešení mezi dodavatelem, business vlastníkem a IT oddělením.


Praxe:

Na základě zkušenosti s laděním a audity BI/DWH řešení v ČR bych zde rád uvedl TOP 5 příčin problémů s výkonem BI/DWH řešení realizovaných s využitím databáze Oracle. V tabulce je uvedena definice problémové oblasti, typický projev problémů, četnost počet jejich výskytu (celkový počet auditů 6). Četnost výskytu je ovlivněna tím, že se téměř vždy jednalo o řešení vykazující nějaký problém, takže byl vyžádán audit řešení:

Oblast

Projev

Bližší popis projevu

Četnost výskytu

Nevhodně připravené reporty resp. datový model

Dlouho trvající reporty resp. odezva datového skladu

Nutnost redefinice reportů pro problematickou část řešení (zdrojový dotaz), případně redefinice datamartů a agregátů, optimalizace datového modelu

6

Konfigurace infrastruktury (servery a diskové pole)

Neadekvátně dlouhá doba odezvy na vyladěné dotazy, výskyt vysokého počtu čekání databáze na prostředky operačního systému resp. přístupu k datům, nízká I/O propustnost databáze

Nevhodná konfigurace parametrů operačního systému pro potřeby databáze, nutnost redefinice úložišť na diskovém poli, nejčastěji spojeno s oblastí nevyladěné databáze.

5

Nevyladěná databáze Oracle

Dlouhá doba odezvy na vyladěné dotazy

Optimalizace parametrů databáze, redesign databázových úložišť (tablespaces, mountpointy), optimalizace ETL procesů s využitím vlastností databáze

5

Sizing řešení

I přes veškerou optimalizaci a ladění není zajištěn požadovaný výkon

Podcenění nárůstu objemu dat v DWH

2

Nevhodná architektura řešení (nevhodná kombinace technologií)

Dlouho trvající aktualizace dat, dlouho trvající reporty, celkové zahlcování řešení, nepomáhá ani vyladění infrastruktury a databáze

Špatně nadefinované vrstvy datového skladu, nevhodně udělané historizace v normalizované vrstvě, nevyužívání možností databáze, redesign ETL procesů

Pozn. Datový sklad realizován několika obecnými tabulkami s parametrizací obsahu dle parametrů

1

Několik perliček z praxe, aneb vybrané výsledky z auditních zpráv:

- Zákazník používá enterprise server s 24GB RAM. Operační systém a databáze májí ale nastaveny parametry, které i při špičkovém zatížení neumožňují alokovat více jak 8GB paměti pro potřeby databáze (cena 1GB paměti v takové třídě serveru představuje tisíce EUR)

- Zákazník používá enterprise diskové pole – pro databázi je ale vytvořen jeden mountpoint, kde jsou všechna data, logy a řídící souboru databáze. Celková I/O propustnost je max. 10MB/s (typicky lze dosáhnout zhruba 10 násobné průchodnosti. Na užaslý dotaz proč je to takto, odpovídá IT tím, že je to enterprise pole, které to zvládne a dobře se to tak zálohuje. Krásný příklad plýtvání investicemi, když i váš disk v notebooku má průchodnost 30MB/s

- Zákazník používá Oracle a hlásí, že už bude muset přejít na jinou platformu pro DWH, že to Oracle nezvládá s objemem dat. Výsledek ? Nevhodně nastavené parametry databáze, konfigurace diskového pole obdobná jako v předchozím případě, ale osobně bych rád dostal do ruky člověka, který psal nad tímto skladem dotazy v reportech :o)

- Zákazník chce provozovat datový sklad o objemu řádově 1TB s dynamickým růstem na 4xdualcore 64bit serveru s 12 GB RAM, kde jsou instalovány 32-bitové windows a 32-bitový oracle….tomu se v branži říká nezřízený optimismus

- Zákazník používá databázi Oracle DB a ETL Informatica powermart. Deklaruje nízký výkon databáze resp. dlouhou dobu loadu…výsledky ukázaly, že naráží na limit ETL platformy (snaží se v krátkém čase vyhodnocovat změny pomocí plného porovnání dvou snímků zdrojové tabulky se 100miliony záznamů). Vyřešeno pomocí diferenčních view na úrovni databáze a vyladění databáze.


Bohužel praxe ukazuje stav, který je známý i z jiných oblastí techniky. Zákazník resp. IT si velmi často pořizuje infrastrukturu a software s vysokou investiční náročností, kterou pak ale nevyužívá vhodným způsobem, takž dochází k plýtvání investičními prostředky. Jako když si koupíte mobilní telefon typu Smart, který má operační systém a desítky dalších vlastností, ale vy s ním jen telefonujete a píšete textové zprávy. Když se Vás pak ale někdo zeptá, jaký máte telefon, s hrdostí ukazujete a odpovídáte. To že z jeho možností využíváte 10% není v tu chvíli důležité. Bohužel ale v tomto případě nejde o telefon, ale investice v řádu milionů, které musel zaplatit business vlastník řešení.


Příspěvek vytvořil a zaslal Petr Šimbera - nezávislý BI/DW Solution Architect. Díky!

pondělí 10. března 2008

BI Answers – Tipy/triky s kontingenční tabulkou

Pohled kontingenční tabulka v rámci BI Answers slouží primárně pro účely analýz dat. Níže najdete pár tipů jak lze kontingenční tabulku využívat.

Základní pojmy


Filtrování / řezy
V případě, že do sekce „Stránek“ dáte více dimenzí, pak standardní chování tabulky je takové, že v rámci „select boxu pro filtrování“ se vytvoří všechny kombinace hodnot z použitých dimenzí.



Jetliže Vám toto chování nevyhovuje, pak z možností vyberte volbu „Rozevírací seznam začátku nové stránky“ - výsledkem bude, že každá dimenze bude mít svůj vlastní "select box".


Položka „vše“ pro filtrování / řezy
Standardně jsou v rámci „select boxu pro filtrování“ pouze prvky dané dimenze.



V případě, že zde chcete mít i položku „vše“ tzn. součet za všechny roky, musíte v návrhu stránek zapnout součty.



Jakmile ve stránkách máte více jak jednu dimenzi a chcete mít položky „vše“ i za jejich kombinace, pak musíte zapnout součty na první dimenzi ve stránkách.


Stránky vs. oddíly
Hlavním rozdílem mezi stránkou a oddílem je to, že „Stránky“ umožňují dynamicky filtrovat hodnoty ...



... zatímco „Oddíly“ zobrazí všechny hodnoty pod sebe do samostatných tabulek.


Ukazatelé nad / pod dimenzí
Záleží co s čím chcete porovnávat:
  • v případě, že Vás zajímá porovnání jednotlivých ukazatelů v rámci prvků dimenze, pak dáte dimenzi nad ukazatele
  • v případě, že Vás zajímá porovnání jednotlivých prvků dimenze v rámci ukazatele, pak dáte dimenzi pod ukazatele

Součty a mezisoučty
Pro stránky, oddíly, řádky, sloupce, ukazatele a dimenze můžete zapnout součty a mezisoučty. Součet se pak může objevit buď před nebo za samotnými výpočty, případně úplně na začátku nebo na konci.


Počítané položky (Custom / Calculated Members)
Na základě dimenzí umístěných v rámci řádků, sloupců, stránek a oddílů můžete vytvářet vlastní počítané položky (z MOLAPu známé jako Custom / Calculated Members) – více viz. článek Uživatelem definované skupiny v rámci dimenze.


Průběžný součet (Running Sum)
Chcete-li zobrazit ukazatele jako průběžný součet, pak klikněte na jeho možnosti a z nabídky vyberte „Zobrazit jako průběžnou sumu“. V případě, že vedle sebe chcete mít pro stejný ukazatel sumu normální i průběžnou, pak nejprve z možností vyberte „Duplicitní vrstva“ (vybraný ukazatel se z duplikuje – můžete jej přejmenovat) ...


... a poté pro z duplikovaný ukazatel nastavte „Zobrazit jako průběžnou sumu“.


Procento / index z „něčeho“
Podobně jako jde vytvořit průběžný součet, můžete vytvořit ukazatel zobrazující procentuální hodnotu nebo index ze sloupce, řádku, oddílu, stránky, nadřazených objektů nebo určité dimenze. Stačí když vyberete ukazatel, kliknete na jeho možnosti a z nabídky vyberte „Zobrazit data jako“ > „Procento nebo Index“ > „z něčeho“.


Maximální počet řádků, buněk, oddílů, stránek ...
Po instalaci Oracle BI jsou standardně nastaveny určité parametry, které ovlivňují chování kontingenční tabulky. Mezi tyto parametry patří:
  • Maximální počet řádků, které mohou být zpracovány (parametr CubeMaxRecords – jeho defaultní hodnota je 20000)

  • Maximální počet buněk, které mohou být využity (parametr CubeMaxPopulatedCells – jeho defaultní hodnota je 150000)

  • Maximální počet oddílů, které mohou být zobrazeny (parametr MaxVisibleSections – jeho defaultní hodnota je 1000)

  • Maximální počet stránek, které mohou být zobrazeny (parametr MaxVisiblePages – jeho defaultní hodnota je 1000)

  • Maximální počet sloupců, které mohou být zobrazeny (parametr MaxVisibleColumns – jeho defaultní hodnota je 1000)

  • Maximální počet řádků, které mohou být zobrazeny (parametr MaxVisibleRows – jeho defaultní hodnota je 100000)
Defaultní hodnoty parametrů lze změnit v konfiguračním souboru instanceconfig.xml (konfigurační soubor ovlivňující chování BI Presentation Serveru). Parametry jsou vloženy mezi tagy PivotView.

Příklad:

Erik Eckhardt (eec).