pondělí 30. listopadu 2009

Instalace Oracle BI EE na Windows 7 pro testovací účely

Při pokusu instalovat Oracle BI EE v prostředí Windows 7 skončíte na této chybě:


To je sice pravda, ale je možné nainstalovat. Instalace sice není certifikovaná, ale pro potřeby pokusů a demonstrací je plně funkční. Postup instalace je následující:
  1. Uživatel ve Windows musí mít práva administrátora
  2. Zkopírujte instalační DVD na HDD počítače
  3. Najděte setup.exe, v properties mu nastavte "Spustit v režimu kompatability" Vista (nebo jiný podporovaný OS)
  4. Spustit setup.exe - Spustit jako správce (pravé tlačítko myši + vybrat z menu)
  5. Standardně instalovat

Další tipy
Vzhedem k tomu, že instalace neslouží k produkčnímu prostředí, ale k testování a demonstracím, je vhodné po startu počítače nespouštět zbytečně všechny služby, ale ponechat si možnost ručního spuštění. Je sice možné řešit startováním ( a zastavováním) jednotlivých sližeb, ale je šikovné si na to udělat startovací a zastavovací skripty (Pozor – oba se musí spouštět jako správce!):

Soubor BI_start.cmd
net start "Oracle BI Server"
net start "Oracle BI Java Host"
net start "Oracle BI Presentation Server"
C:\OracleBI\oc4j_bi\bin\oc4j.cmd -start

Soubor BI_stop.cmd
net stop "Oracle BI Java Host"
net stop "Oracle BI Presentation Server"
net stop "Oracle BI Server"

Připojení k databázi Oracle pomocí Oracle Instant Client
Při připojení pomocí Oracle Instant Client nešlo využít definice jednotlivých serverů v souboru TNSNAMES.ora, ale bylo potřeba zadat celou cestu přímo do definice Connection Pool (tedy v Data source Name je to, jak je definováno v tnsnames.ora):




Jan Jůza (CCA)

čtvrtek 26. listopadu 2009

Nové Oracle By Example pro OWB 11gR2

Nedávno do OBE (Oracle By Example) byly přidány nové příklady na Oracle Warehouse Builder verze 11gR2. První dva ukazují některé nové vlastnosti R2 verze (nové uživatelské prostředí, COBOL Copybook, ...), zbylé tři jsou do R2 verze předělány. Máte-li zájem, podívejte se na linky níže:
  1. Improved User Interface, Usability, and Productivity With OWB 11g R2
  2. Handling Flat File and COBOL Copybook Sources in Mappings
  3. Using Data Transformation Operators with Source and Target Operators
  4. Working with Pluggable Mappings
  5. Examining Source Data Using Data Profiling


eec.

pondělí 23. listopadu 2009

4. Oracle Czech BI/DW Experts Bootcamp

V pátek 20.11.2009 proběhl již 4. Oracle Czech BI/DW Experts Bootcamp, kterého se zúčastnilo 14 vybraných konzultantů a architektů od 12 Oracle partnerů:
  • Jaroslav Vlček (Adastra)
  • Jan Jůza (CCA)
  • Karel Hübl (GEM system)
  • Michal Tomek (Neit Consulting)
  • Lukáš Hrnčíř (Neit Consulting)
  • Václav Bíba (Ness Logos)
  • Petr Zeman (OKsystem)
  • Jiří Doubravský (Pike Electronic)
  • Jakub Genža (CapGemini)
  • Jiří Zamouřil (Oracle Consulting)
  • Martin Gerneš (Oracle Consulting)
  • Michal Zima (Teura)
  • Martin Cabák (Reporters)
  • Peter Hora (Sementa)

Agenda setkání:

Prezentace z 1. workshopu - Tipy, triky a zkušenosti z BI/DW projektů:

Erik Eckhardt (Oracle)
  • Zvýšení produktivity vývoje s ODI - Tvorba, úpravy a spouštění více jak +900 datových přenosů
Karel Hubl (GEM System)
  • Efektivní datové integrace s ODI
  • OBI 10.1.3.4.1 – Problém s filtry pro numerické datové typy
Michal Tomek (NEIT Consulting)
  • Essbase - trigger pro instalaci HSS
  • Posílání reportů z linuxového Publisheru na windowsový fileserver
  • 64bitová Essbase pro Linux
Jan Jůza (CCA)
  • Tipy, triky a zkušenosti z projektu „Převod analýz z Excelu do Oracle BI”
Jiří Doubravský (PIKE)
  • Použití kombinace funkcí Time Series (AGO a TODATE)
  • Doplnění legendy do reportu přes XML
  • Vliv nevhodného pojmenování časového údaje na použití v promptu
Michal Zima (Teura)
  • Zkušenosti s implementací OBIEE v clusteru
Jakub Genža (Capgemini Sophias)
  • Jak v OBI změnit defaultní menu pomocí currencies.xml (zkusenost z BIAPPS)
  • Jak v BIAPPS/ODI resetovat/vymazat jen jeden z modulů, ne celý warehouse (není zdokumentováno)
  • Jak odstranit v Answers při filtrování odkaz "Omezené volby", který může vygenerovat dost narocný dotaz
Jaroslav Vlček (Adastra)
  • BI Delivers versus autentifikace proti DB
Lukáš Hrnčíř (NEIT Consulting)
  • Transformace datových a report požadavků do designu metadat a designu reportů
Martin Gerneš (Oracle Consulting)
  • Integrace OBI EE, SSO, OAM, OID
  • Operátorská konzole pro OWB a ODI
Peter Hora (Semanta)
  • Komentáře a diskuze pro Oracle BI

pondělí 16. listopadu 2009

ODI a datový typ TIMESTAMP

Pokud v ODI datové pumpě přenášíte datový typ TIMESTAMP například z Oracle do Oracle, ale i z Oracle do jiné databáze, pak až do verze 10.1.3.5.3 ODI vždy „ořízlo“ počet desetinných míst u sekund na 3. Pokud jste tedy potřebovali využít přesnost například TIMESTAMP(6), pak o poslední 3 desetinná místa jste při přenosu dat přišli.

Na tuto chybu jsme narazili nedávno a byla na Oracle Metalinku zaevidována jako BUG 8917148. Odstraněna byla v patchi 9064641, který najdete tamtéž. Je označen jako Generic Cumulative Patch a upravuje číslo verze ODI na 10.1.3.5.4. Je možné jej aplikovat již od verze 10.1.3.5.0



Petr Zeman (konzultant společnosti OKsystem s.r.o.)

čtvrtek 12. listopadu 2009

Oracle 11gR2 - Hybrid columnar compression

Před několika týdny byla uvolněna nová verze databáze Oracle 11G R2 a ta, mimo jiná „vylepšení“, obsahuje jednu velmi zajímavou funkčnost, která se týká způsobu uložení dat. Na první pohled to vypadá jako převratná novinka ve světě uložení dat, ale Oracle není první, kdo se pustil do vertikálního konceptu. Na druhou stranu můžeme být jen rádi, že Oracle stále sleduje současné trendy vývoje v oblasti relačních databází pro systémy pro podporu rozhodování a v ničem nezůstává pozadu proti specializovaným produktům pro DWH/BI ostatních konkurentů. Prvním důkazem je nám všem dobře známá Exadata, která je pravou Datawarehouse Appliance, a samozřejmě její víc než zajímavé vylepšení, a to nejen technologické, tak zejména z hlediska poměru ceny za TB, v podobě Exadata 2. Druhým průlomovým krokem je funkcionalita, o které bych se rád zmínil v tomto článku, a to hybridní vertikální komprese.

Relační databáze, které jsou dnes dostupné na trhu, podporují vesměs jeden z následujících dvou konceptů uložení:
  • Řádkové uložení, neboli N-ary Storage Model (NSM)
  • Sloupcové uložení, neboli Decomposition Storage Model (DSM)
Řádkové uložení dat
Řádkové uložení je zřejmě nejvíce používaným způsobem uložení dat, tak jak jej známe ze všech verzí Oracle, MS SQL, PostgreSQL, MySQL a dalších. Data jsou ukládána po jednotlivých blocích a v rámci každého bloku jsou organizována po řádcích, stejně tak bloky jsou organizovány po řádcích. Každý řádek v rámci jednoho bloku obsahuje na začátku pointer, který označuje začátek řádku. To proto, protože řádky nemají fixní délku díky atributům s proměnnou délkou. Pokud je blok naplněn, další řádek se již zapisuje do dalšího volného bloku. Tento storage model je vhodný zejména pro OLTP systémy, kdy potřebujeme s vysokou selektivitou získat mnoho atributů z jednoho řádku. Pak se typicky provádí scan přes všechny řádky, případně indexy, filtruje se požadovaný záznam a vrací výsledek zpět. V případě OLAP/DSS systémů je výsledkem dotazu zpravidla restrikce (filtrování) dat, jejich následná agregace a projekce (vrácení pouze jednoho nebo několika atributů), jako např. aktuální počet zákazníků, nebo celkový objem transakcí za určité období. V tomto případě, i když potřebujeme z tabulky transakcí pouze datum a objem transakce, musíme projít všechny záznamy přes všechny atributy, což dotaz výrazně zpomaluje. Na druhou stranu čím více atributů z tabulky potřebujeme dostat, tím se řádkové uložení stává užitečnější.

Sloupcové uložení dat
Sloupcové, nebo také vertikální uložení dat, je koncept navržený výhradně pro DSS systémy. Místo toho, aby byly tabulky uloženy po jednotlivých řádcích, jsou uloženy po sloupcích. Hodnoty atributů jednotlivých řádků jsou tak uloženy vedle sebe, každá hodnota má navíc pointer, ukazující řádek, do kterého hodnota patří. Výhod tohoto způsobu uložení dat je hned několik – pokud použijeme v dotazu restrikci na určitý rozsah hodnot atributu (range restriction), pak se provádí nejprve scan jen jednoho atributu, po nalezení požadovaných hodnot se provádí tzv. rekonstrukce řádku, kdy se spojují nalezené hodnoty přes řádkový pointer na ostatní atributy a vrací se výsledek. V případě dotazů nad několika málo atributy je tento koncept vysoce efektivní proti řádkovému a přináší značné úspory v I/O operacích (čtení z disku). Problémy však nastanou, kdy je potřeba vrátit více atributů, pak se provádí nákladná rekonstrukce řádku přes více atributů a to zpracování velmi zpomaluje. Tento problém se však některé databáze snaží eliminovat pomocí tzv. „affinity graphs“, které seskupují atributy do skupin podle četnosti v dotazech. Další velkou výhodou vertikálního uložení dat je velmi rychlý update, pokud aktualizujeme jen jeden atribut přes všechny řádky. Poslední, ne nevýznamnou výhodou, je komprese, kdy pomocí vertikálního uložení dat můžeme dosáhnout mnohem vyššího kompresního poměru, proti řádkovému uložení. Důvodem je ukládání atributů po blocích a tím i možnost existence stejných hodnot v rámci jednoho bloku. Kompresí se také výrazně zrychluje čtení z disku, kdy se čte menší objem dat, tedy je menší náročnost na I/O a odpověď na dotaz je o to rychlejší. Tento koncept byl poprvé popsán již v roce 1979.

Příkladem relační databáze, používající vertikální koncept je Sybase IQ, která je na trhu už od 90 — tých let minulého století, dále pak novější a méně známé produkty, jako PARAccel, Infobright nebo Vertica.

PAX
Za tajemnou zkratkou PAX se skrývá název Partition Attributes Accross, což je koncept uložení dat, který byl poprvé popsán v roce 2001. Jedná se v podstatě o kombinaci dvou předchozích modelů, tedy řádkového a sloupcového s tím, že PAX eliminuje nevýhody obou a vytváří jakýsi hybrid, tedy „hybrid columnar storage“, na kterém je založena novinka v Oracle 11gR2.

Princip modelu spočívá v tom, že data jsou, podobně jako v případě řádkové uložení, ukládána po blocích, ale v rámci každého bloku jsou již organizována po sloupcích. V rámci bloku se vytváří tzv. minibloky, kde každý miniblok obsahuje hodnoty jednoho atributu pro řádky, které jsou součástí bloku. Tímto způsobem se eliminuje problém sloupcového uložení, kdy se musí provádět náročná rekonstrukce řádků při požadavku na větší počet atributů v dotazu, protože hodnoty atributu jsou uloženy spolu s ostatními atributy řádku v jednom bloku a tedy i rekonstrukce řádku je velmi jednoduchá. Při dotazu obsahujícím restrikci (filtr) na určitý sloupec jsou z disku čteny jen hodnoty tohoto sloupce, je provedena restrikce a následně rekonstrukce řádků. Neprovádí se tedy scan přes všechny atributy, jako v případě řádkového uložení, ale jen rychlý výběr hodnot jednoho sloupce. U tabulek s větším počtem atributů to může být velmi efektivní. Stejně tak zůstane zachována výhoda komprese u sloupcového uložení, kdy hodnoty atributu jsou uloženy vedle sebe. Teoreticky může být hodnota komprese zvýšena způsobem seřazení záznamů, kdy sloupec, podle kterého setřídíme data, bude mít nejspíše nejlepší kompresní poměr.

Oracle a PAX
V současné době existují pouze dohady, jakým způsobem je přesně implementován hybridní sloupcový model uložení v Oracle, pravděpodobně však inspirací je právě koncept PAX. Kompresí nad takto uloženými daty je pak možno dosáhnout 10x -40x kompresní poměr, podle charakteru dat (čím více opakujících se hodnot, tím vyšší kompresní poměr). Hovoří se také o možnosti vybrat si jen část dat, která bude uložena tímto způsobem a zbytek zůstane v klasickém řádkovém uložení. Zůstává otázkou, zda tento hybrid přinese i nějaký benefit v podobě zrychlení odezvy na některé typy dotazů. Z titulu komprese a tím menšího počtu I/O to pravděpodobné bude, z hlediska sloupcového uložení to záleží na skutečnosti, zda implementace je více sloupcová nebo více řádková. Více se snad dozvíme z dalších materiálů, které budou publikovány Oraclem k tomuto tématu.

V úvodu článku jsem se zmínil, že Oracle není jedinou databází, která přichází na trh s hybridní sloupcovou organizací dat. Dalším produktem, který se již brzy objeví na trhu je nová verze Vertica 3.5 a její koncept nazvaný Flex Store, který řeší něco podobného. Ovšem Vertica začala úplně z jiné strany než Oracle, jde od sloupcového uložení směrem k hybridnímu, Oracle od řádkového k hybridnímu. Budou tedy všechny databázové systémy pro podporu rozhodování v budoucnosti jen „hybridy“ ?


Radan Návrat (DWH architect v T-Systems)

pondělí 9. listopadu 2009

Dokumentační nepřesnost, týkající se „Security groups“ v metadatech BI Serveru

Jistě je všem, kteří s OBIEE již nějakou dobu pracují znám koncept Security Groups, které jsou definovány v metadatech BI serveru a které slouží k definovaní restrikcí v metadatech (objektové omezení pro objekty prezentační vrtsvy a „data level“ omezení definovaním tzv. security filtrů).

Standardní dokumentace OBIEE, konkrétně dokument „Server Administration Guide“ upřesňuje (v kapitole 15 „Security in Oracle BI“, odstavec Working with Groups , část „Group Inheritance“ uplatnění tzv. „least restrictive“ pravidla v případě, že uživatel je přirazen k více skupinám s „konfliktně“ nadefinovanými přístupovými privilegii:

„If there are multiple groups acting on a user or group at the same level with conflicting security attributes, the user or group is granted the least restrictive security attribute. Any explicit permissions acting on a user take precedence over any privileges on the same objects granted to that user through groups.“

Zjednodušeně řečeno, je-li definována security skupina GROUPA, která má např. právo „Read“ na subjektovou oblast SA1 prezentační vrstvy metadat a security skupina GROUPB, která má „Read“ privilegium na subjektovou oblast SA1 explicitně odebránu, pak je-li uživateli USER1 přidělena jak skupina GROUPA, tak GROUPB, pak tento uživatel má (díky „least restrictive“ pravidlu) „Read“ právo na subjektovou oblast SA1.

Toto pravidlo ovšem neplatí v případě definic tzv. „data level security“ pomocí „security filtrů“ :


Zde naopak platí „most restrictive „ pravidlo – tj. např. mám-li definovánu na úrovni business modelu logickou faktovou tabulku Fact1, a 2 security skupiny GROUPA a GROUPB, přičemž pro GROUPA nadefinuji pro tuto logickou faktovou tabulku „security filter“ a pro skupinu GROUPB tento filtr definován nebude. Pokud se uživatel USER1, kterému je přiřazena jak skupina GROUPA, tak skupina GROUPB dotazuje (v nástroji Answers) na metriky faktové tabulky, jsou mu data této faktové tabulky vždy omezena filtrem, definovaným pro skupinu GROUPA (i když zároveň patří i do skupiny GROUPB, která nad touto faktovou tabulkou žádný filtr nadefinován nemá).


Takže se v případě security filtrů nenechte zmást popisem ve standardní OBIEE dokumentací, chování BI serveru tomu neodpovídá.



Michal Zima (Teura s.r.o.)

čtvrtek 5. listopadu 2009

Instalace Hyperion Shared Services (HSS) na Oracle databázi s českou lokalizací

V dokumentaci Oracle Hyperion Enterprise Performance Management System Installation Start Here Release 11.1.1 jsou uvedeny následující požadavky na konfiguraci Oracle databáze pro instalaci HSS:
  • Database character set = AL32UTF8 nebo UTF8 nebo UTFE
  • grant CREATE SESSION, CREATE VIEW, RESOURCE
  • nls_length_semantics = ’CHAR’
  • nls_language = ‘AMERICAN‘
  • nls_territory = ‘AMERICA‘

Potíže s tím spojené jsou tyto:
  1. Bez těchto parametrů (s výjimkou prvního) nelze HSS rozběhnout. Typický příznak: během instalace a zejména při spuštění HSS služby se opakovaně (na konzoli, v logu) objevuje chyba ORA-01722: invalid number.
  2. Řada instancí Oracle v českých zemích nemá tyto parametry.
  3. Změnit parametry nls_* na databázi (alter system) není obvykle dost dobře možné.
  4. Změnit parametry nls_* na klientovi (tj. stroj, kde běží HSS), podle mých dosavadních pokusů nestačí. HSS se totiž připojují přes driver JDBC Merant 5.2, který je vůči nastavení environmentu i javovským locale typu -Duser.language=en -Duser.region=US zcela imunní.
Workaround:

create or replace trigger hyperion.nls_bugfix_trigger
after logon on database
declare u VARCHAR2(30);
begin
select user into u from dual;
if u = 'HYPERION' then
execute immediate 'alter session set nls_territory = ''AMERICA'' ' ;
execute immediate 'alter session set nls_language = ''AMERICAN'' ' ;
execute immediate 'alter session set nls_length_semantics = ''CHAR'' ' ;
end if;
end;
/

Testováno na verzi 11.1.1.2. Netestováno, zda problém přetrvává i na 11.1.1.3 (původní myšlenka viz. zde).



Michal Tomek (konzultant společnosti Neit Consulting)


pondělí 2. listopadu 2009

Oracle BI – GO URL a české znaky

Jako součást jednoho projektu jsme implementovali GO URL API pro volání PDF a XLS reportů s parametry. V takovém případě se nevyhnete použití češtiny. České znaky jsou součástí řetězců, které jsou předávané jako hodnoty jednotlivých parametrů a zde byla čeština použita i v názvech samotných sestav v katalogu. V URL samozřejmě češtinu použít nelze.
Řešením je použít tzv. URL encoding. Při instalaci Oracle BI na platformě MS Windows a použití klienta na téže platformě (MS Internet Explorer 8) je třeba použít variantu UTF-8. Následující tabulka ukazuje, který znak nahradit jakou sekvencí:

Český znak UTF-8 sekvence
ě %C4%9B
š %C5%A1
č %C4%8D
ř %C5%99
ž %C5%BE
ý %C3%BD
á %C3%A1
í %C3%AD
é %C3%A9
ď %C4%8F
ť %C5%A5
ň %C5%88
ú %C3%BA
ů %C5%AF
Š %C5%A0
Č %C4%8C
Ř %C5%98
Ž %C5%BD
Á %C3%81
Ú %C3%9A

Na závěr malý příklad:
PŮVODNÍ URL:
http://biserver/analytics/saw.dll?Go&Path=/Shared/Kontrola/Reporty/Pokuty+Osob&NQUser=Administrator&Action=Navigate&Format=PDF&P0=2&P1=eq&P2="D01%20Datum".Datum&P3=13.9.2009&P4=like&P5="D15%20Důvod%20pokuty".Text&P6=%25500%25

UPRAVENÉ URL:
http://biserver/analytics/saw.dll?Go&Path=/Shared/Kontrola/Reporty/Pokuty+Osob&NQUser=Administrator&Action=Navigate&Format=PDF&P0=2&P1=eq&P2="D01%20Datum".Datum&P3=13.9.2009&P4=like&P5="D15%20D%c5%afvod%20pokuty".Text&P6=%25500%25



Petr Zeman (softwarový konzultant, OKsystem s.r.o.)