středa 19. září 2007

Vyhodnocení soutěže s Oracle BI SE One

Vážení přátelé,

děkujeme vám všem, kteří jste se zúčastnili soutěže s Oracle Business Intelligence Standard Edition One - tzn. soutěže o nejlepší BI Dashboard / Manažerský kokpit.

Soutěže se zúčastnilo celkem 32 účastníků ze strany Oracle partnerů, zákazníků a konkurence. Z tohoto počtu naši obchodníci vybrali 10 nejlepších, kteří se utkají o hlavní ceny.

Hlasování o nejlepší BI Dashboard probíhá formou ankety, kterou najdete na pravé straně našeho blogu. Stačí když ze seznamu soutěžících dashboardů (nejdete je níže) vyberete ten nejlepší a klikem v anketě mu dáte svůj hlas.


A jaká je odezva zúčastněných na Oracle BI SE One? Zprůměrované odpovědi jsou k dispozici zde (hodnotilo se jako ve škole 1-nejlepší, 5-nejhorší):
  • 1,4 - Průběh instalace OBI SE One
  • 1,9 - Intuitivnost tvorby reportů/analýz
  • 1,6 - Intuitivnost tvorby BI kokpitu
  • 1,4 - Celkový dojem z OBI SE One
  • 1,1 - Líbila se Vám soutěž

S pozdravem

Oracle BI/DW team.


Seznam soutěžících dashboardů

#1 - BLU Dashboard



#2 - CEO Dashboard



#3 - Dashboard Produktového ředitele



#4 - TOP Management Dashboard



#5 - Dashboard Monitoring kampaní

#6 - Sales Dashboard



#7 - Profit Dashboard



#8 - Europe Monthly Operations Dashboard



#9 - CFO Dashboard



#10 - Sales Analysis Dashboard


úterý 11. září 2007

Datová komprese aneb jak ušetřit diskový prostor a zrychlit odezvu dotazů

Už jste přemýšleli o tom, co uděláte s historickými daty staršími než je povinná doba pro jejich uchování a které určitě zabírají více jak 50 procent diskové kapacity serveru?
Budete je archivovat? Ale jakým způsobem a kam? Budou pak snadno a rychle dostupná pro účely reportingu, analýz, auditu nebo jiných činností, které „business“ potřebuje?

Zkuste se zamyslet zda není jednodušší je nechat tam kde jsou a využít „Table Compression“ – vlastnost databáze Oracle, která je k dispozici již od verze 9i.


Co je a jak funguje Oracle Table Compression


Jde o bezztrátovou kompresi, která je prováděna mezi hodnotami řádků a sloupců na úrovni databázového bloku eliminací duplicitních hodnot. Struktura komprimovaného bloku oproti normálnímu je jiná v tom, že je zde navíc přidána takzvaná „Symbol Table“ (metadata o kompresi), která obsahuje nejčastěji se opakující hodnoty. To zda pro sloupce budou hodnoty do „Symbol Table“ přidány nebo ne, rozhoduje sama databáze a to na základě délky sloupce a počtu výskytů hodnot. Jakmile je hodnota do „Symbol Table“ vložena, je její normální výskyt v bloku nahrazen „pointerem“ ukazujícím do „Symbol Table“, viz. Obr.1.

Obr.1 – Struktura komprimovaného a normálního bloku

Table Compression významně snižuje požadavky na použitý diskový prostor a na paměť databáze Oracle (konkrétně na buffer cache), a přitom zvyšuje výkon SQL dotazů. Ptáte se jak je to možné?

Data komprimovaných tabulek zabírají méně datových bloků na disku (do jednoho bloku je nyní možné uložit mnohem více dat), čímž se snižují nároky na diskový prostor. Data z komprimovaných tabulek jsou čtena do paměti databáze (buffer cache) v komprimovaném stavu (jsou dekomprimovány až při přístupu do nich), z čehož vyplývá, že do stejně velké paměti lze načíst mnohem více dat. A protože díky kompresi se čte méně databázových bloků z disku, provádí se i méně I/O operací (fyzických i logických), což má za následek, že dotazy „trpící“ díky vysokému I/O jsou nyní znatelně rychlejší.


Jak se Table Compression zapíná

Table Compression můžete využít na tabulky, materializované pohledy nebo partition (všechny nebo pouze určité). Atribut komprese lze pak zapnout i pro celý tablespace tzn. všechny výše zmíněné objekty budou mít zapnutou kompresi.

CREATE TABLE [name] COMPRESS;


Kdy a jaké operace data komprimují


V Oracle Database 9i a 10g bylo možno komprimovat pouze ta data, která byla nahrávána pomocí „BULK“ operací
. Data, která byla nahrávána nebo modifikována pomocí DML (insert, update, delete) komprimována nebyla.
Tzn. využít Table Compression bylo nejvhodnější pro datové sklady a nebo pro archivaci historických dat (tedy tam, kde lze využít „BULK“ operace).

Mezi „BULK“ operace, které komprimují data patří:
  • CREATE TABLE [name] COMPRESS AS SELECT
  • ALTER TABLE [name] MOVE COMPRESS
  • ALTER TABLE [name] MOVE PARTITION [name] COMPRESS
  • INSERT /*+ APPEND */ nebo Parallel INSERT do tabulky, která má zapnutou kompresi
  • Direct Path SQL*Loader do tabulky, která má zapnutou kompresi

V Oracle Database 11g je k dispozici OLTP Table Compression, která podporuje kompresi dat i pro individuální DML operace, tedy INSERT, UPDATE, DELETE. V tomto případě komprese probíhá na pozadí (nulová režie při zápisu) a to jakmile zaplnění databázového bloku daty dosáhne hodnotu parametru PCTFREE, viz. Obr.2.

Syntaxe v 11g je následující:
  • ... COMPRESS [FOR {ALL | DIRECT_LOAD} OPERATIONS]
  • kde parametr DIRECT_LOAD – (default nastavení), je to samé co je v 9i a 10g
  • kde parametr ALL – DML i DIRECT_LOAD operace

Obr.2 – OLTP Table Compression v Oracle Database 11g


Testcase – co vlastně testovat?

Co udělat před vlastním nasazením? Nejlépe je otestovat Table Compression na kopii vašich skutečných dat a s vašimi konkrétními aplikacemi. Na co se vlastně zaměřit?

  1. Kolik místa kompresí dat vlastně ušetříte, tzn. zjistit kompresní poměr (nekomprimovaná / komprimovaná data). Ten standardně bývá okolo 2:1 až 4:1 a samozřejmě závisí na samotných datech. U hodně duplicitních dat, jako jsou například detailní výpisy hovorů u telekomunikačního operátora, je možné dosáhnout poměru až 12:1 (nekomprimovaná data jsou 12 krát větší než komprimovaná).

  2. Co to udělá s aplikací / reportingem, který data z tabulky využívá. Samozřejmostí je, že Table Compression je pro veškeré aplikace, reporty nebo uživatele plně transparentní, tedy pro nikoho se nic nezmění. Ale musíte si být jisti, že odezva aplikace/reportu je stejná jako dříve nebo lepší.

Osobně jsem Table Compression testoval ještě ve verzi 9i (Linux RedHat, Oracle9i EE – 9.2.0.2.0) nad daty, která byla uložena v partitionované tabulce. Z výsledků jsem byl mile překvapen. Dosáhl jsem kompresního poměru okolo 2:1, tzn. ušetřil 50 procent místa a navíc, což je podstatnější, veškerý reporting se nad těmito daty několikanásobně zrychlil, viz. Obr.3 a 4.

Obr.3 – Kompresní poměr


Obr.4 – Porovnání výkonnosti nekomprimovaná vs. komprimovaná data (zátěž CPU, doba zpracování, fyzické a logické I/O operace generované dotazy Q1, Q2 a Q3)


Co dodat závěrem

Oracle Table Compression patří mezi významné vlastnosti databáze Oracle
. Nejen že Vám ušetří diskovou kapacitu, ale v případě systémů s pomalým nebo hodně zatíženým I/O markantně urychlí odezvu dotazů.

Oracle Database 11g navíc přináší Advanced Compression Option, která kromě již zmíněné OLTP Table Compression obsahuje navíc: Data Guard Network Compression, Data Pump Compression, Fast RMAN Compression, SecureFiles Compression and Deduplication. Ale o tom až jindy.




Erik Eckhardt (eec).

pondělí 3. září 2007

Autentikace uživatelů oproti MS Active Directory a jiným LDAP serverům

V jednom z minulých příspěvků jsem psal o OBI EE / OBI SE One a jeho možnostech pro autentikaci uživatelů. Podrobně je zde popsána možnost autentikace oproti databázi v kombinaci s externí databázovou tabulkou určenou pro autorizaci. A protože mezi nejrozšířenější LDAP řešení u zákazníků patří MS Active Directory, přináším níže návod i pro toto spojení.


I. Připojení k MS AD (LDAP) serveru

Spusťte BI Administrator > Security Manager > New LDAP Server

1/ Záložka General

Zde vyplňte následující hodnoty:
  • Host name - jméno nebo IP adresa MS AD nebo (LDAP) serveru

  • Port number - číslo portu MS AD (LDAP), defaultní je 389

  • LDAP version - LDAP 2 nebo LDAP 3

  • Base DN - "base distinguished name" určuje startovní bod, od kterého se začne provádět autentikační vyhledávání v LDAP stromu

  • Bind DN a Bind Password - jméno uživatele a heslo pro svázání s LDAP. V případě, že LDAP umožňuje "anonymous binding", tak jméno a heslo není nutné vyplňovat. MS AD "anonymous binding" nepodporuje, proto je zde třeba vyplnit jméno a heslo na jeho uživatele.



2/ Záložka Advanced

V případě MS AD zde zaškrtněte checkbox ADSI a všimněte si změny názvu "user name" atributu z uid na sAMAccountName



Nyní se můžete vrátit na záložku General a otestovat připojení k LDAP serveru.



II. Autentikační blok

Jakmile máte založený LDAP server, musíte vytvořit inicializační blok, který se bude používat pro autentikaci uživatelů oproti LDAP serveru.

1/ Spusťte Variable Manager (Menu Manage > Variable Manager)

2/ Vytvořte "Session" Inicializační blok se jménem např. Authentication

3/ Přidejte Data Source typu LDAP a vyberte Váš LDAP (MS AD) server



4/ Přidejte Variable Target - založte novou proměnnou USER



5/ Jako LDAP proměnnou použijte
  • pro MS AD - sAMAccountName
  • pro jiný LDAP - uid



6/ Zaškrtněte, že tento blok je vyžadován pro autentikaci. Poté zvolte OK a uložte změny v repository.



7/ Opět otevřete autentikační blok a otestujte samotnou autentikaci oproti LDAP serveru!




Jestliže je Vaše proměnná naplněna zadaným "user ID", pak je autentikace oproti MS AD nebo jinému LDAP serveru funkční a tím pádem hotova.


eec.

Seznam článků od února do srpna 2007, seřazeno dle kategorie

BI Trendy

CPM

DWH

DWUG

Novinky

OBI EE

OBI EE - DEMO

OBI EE - FAQ

OBI SE

OBI SE - FAQ

OBI SE ONE

OBI SE ONE - FAQ

OWB

Anketa na měsíc červenec a srpen 07 - vyhodnocení