pondělí 31. května 2010

5. Oracle Czech BI/DW Experts Bootcamp

V pátek 28.05.2010 proběhl již 5. Oracle Czech BI/DW Experts Bootcamp, kterého se zúčastnilo 13 vybraných konzultantů a architektů od 10 Oracle partnerů + dva zástupci ze strany zákazníka:
  • Jiří Zamouřil (Oracle Consulting)
  • Jan Jůza (CCA)
  • Karel Hübl (GEMsystem)
  • Václav Bíba (Teura)
  • Michal Zima (Teura)
  • Petr Zeman (OKsystem)
  • Petr Kříž (OKsystem)
  • Jiří Doubravský (Pike Electronic)
  • Jakub Genža (CapGemini)
  • Jiří Bohuslav (CapGemini)
  • Vojtěch Šíp (DATACONS)
  • Petr Šimbera (Simora)
  • Petr Jurászek (ITsystems)

  • Radek Matyáš (Vodafone)
  • Lukáš Flek (Vodafone)

Agenda setkání:
  • Zahájení / představení
  • Novinky - Co se stalo od posledního 4. Bootcampu
  • Zákaznická půlhodinka (Případová studie)
  • 1. workshop
    - Tipy, triky a zkušenosti z BI/DW projektů
    - Co se vyřešit nepodařilo
  • Novinky – Co je nového v Oracle
  • Společný oběd a ubytování
  • 2. workshop
    - Vyjednávání a strategie při budování BI/DW řešení
  • Večeře, volná diskuse a zábava ...

Prezentace:

Hlavní prezentace z 5. Oracle Czech BI/DW Experts Bootcampu

Zákaznická půlhodinka (Případová studie)
Prezentace z 1. workshopu - Tipy, triky a zkušenosti z BI/DW projektů:

středa 26. května 2010

Přesun ODI Master repository pomocí prostředků relační databáze

Náš příklad nasazení ODI repository je následující: nejprve bylo instalováno vývojové prostředí (ODI Master+Work repository) a na něm probíhá vývoj. Produkční prostředí zatím není. Po ukončení vývoje je třeba přenést Master repository na produkční prostředí a zaregistrovat do něj novou produkční Work repository. Původní vývojová Work repository zůstává, původní Master repository je odstavena.

Jak přenést Master repository z jedné databáze do jiné?

Existují dvě možnosti:
  1. Využít ODI průvodce pro Export a Import jednotlivých repository
  2. Použít prostředky relačních databází
My jsme se rozhodli vyzkoušet bod číslo dva "Použít prostředky relačních databází" - ODI Master repository se skládá z obyčejných tabulek, neobsahuje žádné sekvence, view, packages nebo jiné, tj. lze jej tedy normálně exportovat.

Na vývojovém prostředí (server-dev):
exp ODI_MASTER/oldpass@TNS-DEV file=ODI_MASTER.dmp statistics=none
sqlplus / as sysdba

alter user ODI_MASTER account lock;


Přenos souboru ODI_MASTER.dmp na produkční prostředí (server-prod)

Na produkčním prostředí:
sqlplus / as sysdba
create user ODI_MASTER identified by newpass default tablespace xyz;

grant connect, resource to ODI_MASTER;

imp ODI_MASTER/newpass@TNS-PROD file=ODI_MASTER.dmp full=y


Přenastavení vývojového prostředí:
./agent.sh encode newpass
zkopírování enkodovaného hesla do schránky

editace souboru odiparams.sh:
ODI_SECU_DRIVER=oracle.jdbc.driver.OracleDriver
ODI_SECU_URL=jdbc:oracle:thin:@server-prod:1521:TNS-PROD

ODI_SECU_USER=ODI_MASTER

ODI_SECU_ENCODED_PASS=enkodované heslo

neměníme však parametry ODI_SECU_WORK_REP, ODI_ENCODED_PASS

změna přihlášení:
./topology.sh

v přihlašovacím okně – tlačítko Edit connection (název Connection může být libovolný, např. ODI na nasledujících obrázcích)



Změnu přihlášení je třeba udělat také na všech vývojářských PC.

Po přihlášení je vhodné projít topologii a zkontrolovat, zda jsou Master a vývojová Work repository správně připojené.

Přenastavení produkčního prostředí – v odiparams, stejně jako vývojové prostředí. Následně lze již vytvořit novou produkční Work repository.


Michal Tomek (Neit Consulting)

pondělí 24. května 2010

Oracle GoldenGate Trail vs. ASCII,SQL nebo XML soubory

  • Úvod do Oracle GoldenGate najdete zde.
  • Popis integrace mezi Oracle GoldenGate a Oracle Data Integrator najdete zde.
  • Popis instalace Oracle GoldenGate najde zde.
  • Konfiguraci prostředí, procesů a start replikace najdete zde.


GoldenGate Extract (Capture) proces zachytává transakce z databázových redo nebo archiv logů a poté je může zapisovat do:
  • Lokálního Trailu (parametr EXTTRAIL)
  • Vzdáleného Trailu (parametr RMTTRAIL)
  • Lokálního ASCII souboru (parametr EXTFILE)
  • Vzdáleného ASCII souboru (parametr RMTFILE)

Použití Trailů

Z důvodu zajištění bezproblémového přenosu a aplikování transakcí mezi různými platformami (DB, HW, OS, atd.), Extract proces konvertuje data do vlastního formátu a ukládá je do tzv. Trailu – soubor obsahuje potvrzené (commit) transakce ve stejném pořadí jako na zdrojovém systému.
V případě použití Trailu platí, že jeden Extract proces může zapisovat transakce do jednoho nebo více Trailů (vhodné pro distribuci do více lokalit najednou nebo zvýšení výkonu) a jeden Trail může být zpracován jedním nebo více Replicat procesy (vhodné pro zvýšení výkonu replikace). Z pohledu checkpointů platí, že Extract a Replicat procesy provádějí checkpointy pouze při zápisu do Trailu.


Obsah Trailu

  • Každý záznam obsahuje typ operace ze zdrojové databáze
  • Transakce jsou ve stejném pořadí jako na zdrojové databázi
  • Jednotlivé operace v transakcích jsou seskupeny pospolu
  • Standardně obsahuje pouze primární klíče a změněné záznamy
  • Skládá se z hlavičky a jednotlivých záznamů

Hlavička Trailu

Obecné informace:
  • Kompatibilita
  • Znaková sada
  • Datum a čas vytvoření
  • Sekvenční číslo
  • Velikost
Informace o prvním a posledním záznamu:
  • Timestamp
  • CSN
Informace o extraktu:
  • Verze GoldenGate
  • Jméno Extract skupiny
  • Hostname
  • HW
  • OS a verze
  • DB, verze a znaková sada

Záznamy v Trailu
  • Hlavička záznamu (název tabulky, typ operace, datum vzniku transakce, transakční skupina, délka dat, ...)
  • Datová oblast (ID sloupce, hodnota sloupce)

Utilita Logdump
V případě, že se chcete podívat na obsah Trailu můžete použít utilitu Logdump, která zobrazuje jeho hlavičku i jednotlivé záznamy (seznam příkazů viz. help).



Použití ASCII, SQL nebo XML souborů
V případech, kdy potřebujete získané transakce přímo nabídnout jiným procesům (např. ETL, ESB, DB Loaderům, ...) nebo aplikacím, použijte parametr FORMATxxx v konfiguračním souboru Extract procesu.

Parametr FORMATxxx zajistí, že výstup bude místo do Trailu uložen do soubor ve formátu: ASCII (FORMATASCII), SQL (FORMATSQL) nebo XML (FORMATXML).

V rámci jednoho Extrakt procesu se specifikuje jeden formát, tj. v případech kdy potřebujete najednou generovat více formát (např. Trail, ASCII a XML), pak vytvořte více Extract procesů. Poznámka: Při použití parametru FORMATxxx nelze již data aplikovat Replicat procesem.


FORMATASCII
Umožňuje generovat soubor s oddělovači nebo jej přímo formátovat pro databázové utility jako SQLLoader, BCP, SSIS, ...:

FORMATASCII, BCP
FORMATASCII, SQLLOADER


Parametr FORMATASCII má různá nastavení ovlivňující výsledný výstup, jako např. COLHDRS, DATE | TIME | TS, DELIMITER, EXTRACOLS, NAMES, NONAMES, NOHDRFIELDS, NOQUOTE, NOTRANSSTMTS, NULLISPACE, PLACEHOLDERS, ...

Příklad použití:

Parametrický soubor

Start Extract procesu
add extract e_txt, tranlog, begin now
start extract e_txt


DML nad databází

Výsledek


FORMATSQL
Umožňuje generovat soubor obsahující DML příkazy. Možná nastavení NONAMES, NOPKUPDATES, ORACLE.

Příklad použití:

Parametrický soubor

Start Extract procesu
add extract e_sql, tranlog, begin now
start extract e_sql


DML nad databází

Výsledek
Poznámka: Tabulka nemá Primární klíč, proto jsou v klausuli WHERE vyjmenovány všechny sloupce, jinak jen PK.


FORMATXML
Umožňuje generovat soubor obsahující data ve formátu XML. Možná nastavení INLINEPROPERTIES | NOINLINEPROPERTIES, TRANS | NOTRANS.

Příklad použití:

Parametrický soubor

Start Extract procesu
add extract e_xml, tranlog, begin now
start extract e_xml


DML nad databází

Výsledek
Poznámka: změna lokace z PRAGUE na TABOR, je operace DELETE a INSERT.



Erik Eckhardt

čtvrtek 20. května 2010

Neočekávané chování v seskupování agregovaných ukazatelů při použití sort by funkce

Mějme dimenzi nazvanou OBDOBI a k ní hierarchii H_OBDOBI. Tato hierarchie má kromě grand total úrovně ještě následující: ROK, MESIC a TYDEN.


Data ve fyzické tabulce obsahují týden jako nejjemnější údaj. Dimenze má klíč nazvaný CAS_ID a je nastavená jako časová, což ovšem, jak jsem zjistil, nehraje žádnou roli.

Sloupec Měsíc je typu VARCHAR, což způsobuje potíže se tříděním na prezentační vrstvě.
Znáte to: 1, 10, 11, 12, 2, 3,…
Z toho důvodu jsem nastavil sloupci Měsíc třídění podle klíče dimenze, u kterého vím, že je s časem rostoucí (podmínka pro časovou dimenzi). Více o alternativním třídění dat najdete zde.


Tím jsem zajistil správné třídění sloupce Měsíc.
Potíž nastala jinde, a to zcela nečekaně. Pokud jsem totiž v dotazu zobrazil sloupec měsíc a některý agregovaný ukazatel, výsledky se v jednotlivých měsících ještě seskupily (group by) podle jednotlivých týdnů:


Po chvilce bádání jsem přišel na to, že to způsobuje ono třídící pravidlo. Přidal jsem si tedy další sloupec do fyzické tabulky (PORADI_M), do kterého jsem naplnil stejné číslo pro každý záznam náležející do stejného měsíce. Tím jsem problém obešel a pro mě vyřešil.

Abych byl důsledný, nakonec jsem si celé chování odladil v NQQuery logu. Věc se má tak, že onen třídící sloupec je skutečně v každém případě posílaný do databáze v group by klauzuli. Níže je vidět část logu s sql dotazem před změnou na třídění přes M_PORADI :

select T37."ROK" as c1,
T37."MESIC" as c2,
sum(T55."PRIJEM") as c3,
T37."CAS_ID" as c4
from
"DIM_CAS$" T37,
"F_PRODEJE$" T55
where ( T37."CAS_ID" = T55."CAS_ID" )
group by T37."CAS_ID", T37."ROK", T37."MESIC"


následně podobný dotaz po změně:

select T37."ROK" as c1,
T37."MESIC" as c2,
sum(T55."VYDEJ") as c3,
T37."PORADI_M" as c4
from
"DIM_CAS$" T37,
"F_PRODEJE$" T55
where ( T37."CAS_ID" = T55."CAS_ID" )
group by T37."ROK", T37."MESIC", T37."PORADI_M"




Petr Zeman (OKsystem)

pondělí 17. května 2010

Oracle GoldenGate – Konfigurace prostředí, procesů a start replikace

  • Úvod do Oracle GoldenGate najdete zde.
  • Popis integrace mezi Oracle GoldenGate a Oracle Data Integrator najdete zde.
  • Popis instalace Oracle GoldenGate najde zde.

Začít replikovat data pomocí Oracle GoldenGate lze v následujících čtyřech krocích:
  • I. Příprava OGG prostředí
  • II. Konfigurace a start Extract (Capture) a Data Pump procesů
  • III. Provedení inicializačního nahrání dat (synchronizace) ze zdroje do cíle
  • IV. Konfigurace a start Replicat (Delivery) procesu

I. Příprava OGG prostředí
Nejprve je potřeba nastavit OGG prostředí: Manager proces, DB přístup a Supplemental logging jsou potřeba nastavit v homogenním i v heterogenním prostředí. Navíc v heterogenním prostředí se musí ještě vytvořit Source definition soubor.

1. Manager proces
  • zajišťuje administrativní úkony jako je startování, monitorování a restartování procesů
  • musí běžet na zdrojové i cílové lokaci po celou dobu synchronizace dat (v mém případě zdroj i cíl je stejný, tj. jeden Manager proces)
  • konfigurační soubor pro Manager proces se jmenuje ...dirprm/mgr.prm (když existuje a je prázdný, Manager proces použije default hodnoty, např. port 7809)
  • logovací soubor je uložen v .../ggserr.log
  • startuje se pomocí programu ggsci a příkazu START MGR nebo Windows Services (více viz. zde)
2. „Source definition“ soubor
V případě, že přenosy probíhají v heterogenním prostředí, pak je potřeba pomocí utility defgen vytvořit „source definition“ soubor, podle kterého Replicat proces provádí transformaci zdrojové struktury (např. datové typy) do cílové (v mém případě jde o homogenní prostředí, tj. soubor není třeba vytvářet).

3. DB přístup a Supplemental logging pro tabulky
OGG procesy potřebují přístup do databáze, potřená oprávnění viz. instalace OGG.

Pro testovaní mám v databázi uživatele OGG:
create user ogg identified by ogg
default tablespace users

temporary tablespace temp
quota unlimited on users;

grant dba to ogg;


Dále pro správnou rekonstrukci UPDATE operací je potřeba do transakčních logů přidat dodatečné informace, tj. supplemental logging pro before & after image UPDATE operace. Minimální Supplemental logging byl přidán již v kroku instalace, zde.
Nyní se musí označit tabulky k replikaci pomocí OGG příkazu ADD TRANDATA. Pro Oracle 9.x a dále ADD TRANDATA zapne supplemental logging na úrovni databázových tabulek – příkaz vykoná ALTER TABLE ... ADD SUPPLEMENTAL LOG ...

Pro testovaní mám v databázi dva uživatele OGG_SRC a OGG_TRG:
create user ogg_src identified by ogg_src
default tablespace users

temporary tablespace temp

quota unlimited on users;

create user ogg_trg identified by ogg_trg
default tablespace users
temporary tablespace temp
quota unlimited on users;

grant connect to ogg_src, ogg_trg;


Oba dva vlastní kopie tabulek uživatele SCOTT, ale pouze tabulky uživatele OGG_SCR obsahují data:
create table ogg_src.emp as select * from scott.emp;
create table ogg_src.dept as select * from scott.dept;

create table ogg_trg.emp as select * from scott.emp where 1=2;

create table ogg_trg.dept as select * from scott.dept where 1=2;


Zapněte Supplemental logging pro db tabulky:
ggsci
dblogin userid ogg, password ogg
add trandata OGG_SRC.*



Ověřte Supplemental logging pomocí:
info trandata OGG_SRC.*



II. konfigurace a start Extract (Capture) a Data Pump procesů
Extract (Capture) proces zachytává transakce z redo logů a ukládá je do lokálního Trail souboru. Data Pump proces přenáší transakce z Trailu do cílové lokace.

A/ Extract proces
Proces bude zachytávat transakce z redologů a zapisovat je do lokálního trail souboru. Extract proces se konfiguruje na zdrojovém systému.

1. Vytvoření parametrického souboru
Konfigurace procesů se provádí pomocí ASCII souboru, který bude uložen v adresáři .../dirprm/

ggsci
edit params EOGGSRC1


Vložte do souboru:
-- Parametr file pro Extract proces
-- zachytava zmeny nad tabulkama schematu OGG_SRC.*
--
EXTRACT EOGGSRC1
USERID ogg, password ogg
EXTTRAIL ./dirdat/ee
TABLE OGG_SRC.*;


Uložte soubor

Poznámka: hesla ve všech konfiguračních souborech lze zašifrovat, jméno procesu je volitelné, exttrail určuje jméno lokálního trail file - dva znaky + OGG automatická sekvence (6 čísel)

2. Přidání do Extract skupiny
add extract EOGGSRC1, tranlog, begin now

Poznámka: tranlog znamená, že data budou čtena z redo logů

Ověřte pomocí:
info extract EOGGSRC1

3. Založení lokálního Trail souboru
add exttrail ./dirdat/ee, extract EOGGSRC1, megabytes 5


B/ Data Pump proces
Proces bude přenášet data z lokálního trail souboru do cíle. Data Pump proces se konfiguruje na zdrojovém systému.

1. Vytvoření parametrického souboru
Konfigurace procesů se provádí pomocí ASCII souboru, který bude uložen v adresáři .../dirprm/

ggsci
edit params PSRCTRG1


Vložte do souboru:
-- Parametr file pro Pump proces
-- cte lokalni trail soubor pro tabulky OGG_SRC.* a prenasi do cile
--
EXTRACT PSRCTRG1
PASSTHRU
RMTHOST localhost, MGRPORT 7809
RMTTRAIL ./dirdat/rr
TABLE OGG_SRC.*;


Uložte soubor

Poznámka: passthru se používá u Data Pump procesu když není požadována transformace nebo filtrování dat, RMTxxxx jsou parametry vzdáleného OGG

2. Přidání do Data Pump skupiny
add extract PSRCTRG1, exttrailsource ./dirdat/ee

Ověřte pomocí:
info extract PSRCTRG1

3. Založení vzdáleného Trail souboru
add rmttrail ./dirdat/rr, extract PSRCTRG1, megabytes 5



C/ Start Extract a Data Pump procesů
start extract EOGGSRC1
info extract EOGGSRC1


start extract PSRCTRG1

info extract PSRCTRG1




III. Provedení inicializačního nahrání dat ze zdroje do cíle
Inicializační nahrání dat ze zdroje do cíle zajistí prvotní synchronizaci obou systémů. Existuje několik metod jak prvotní inicializaci provést:

1. Prostředky GoldenGate
GoldenGate umožňuje provést inicializační nahrání vlastními prostředky v heterogenním prostředí. Pro zajištění vysokého výkonu lze kontrolovat FETCHSIZE, paralelní zpracování a volní Bulk utility pro zápis do cíle. Proces zpracování může vypadat následovně:

Extract proces čte zdrojová data přímo z databázových tabulek (ne z transakčních logů) a posílá je do cíle:
  • přímo na Replicat proces, který je zapisuje do cílových tabulek pomocí volání nativního SQL
  • přímo na Replicat proces, který volá externí Bulk Loader (např. Oracle SQL*Loader API)
  • přímo na Server Collector, který data ukládá do Trail file a Replicat je pomocí SQL zapisuje
  • přímo na Server Collector, který data ukládá do souboru připraveného pro externí Bulk Loader

2. Prostředky databází
Inicializační nahrání lze provést prostředky jednotlivých databází, jako je:
  • Záloha zdrojové (primární) databáze a její obnova jako cílové (záložní)
  • Export (exp, expdp) dat ze zdrojové databáze a import (imp, impdp) do cílové
  • Přenos dat přes DB link
  • Transportable tablespace
  • ...

Níže je uveden příklad provedení inicializačního nahrání prostředky GoldenGate, kdy Extract proces čte zdrojová data přímo z databázových tabulek a posílá je do cíle na Replicat proces, který je zapisuje do cílových tabulek pomocí volání nativního SQL:

A/ Na zdrojovém systému

1. Vytvoření parametrického souboru pro Initial Load Extract
ggsci
edit params EINILD1


Vložte do souboru:
-- Parametr file pro Initial Load Extract
-- cte data z tabulek OGG_SRC.* a prenasi do cile na Replicat proces
--
extract EINILD1
userid ogg, password ogg
rmthost localhost, mgrport 7809
rmttask replicat, group RINILD1
table OGG_SRC.*;


Uložte soubor

2. Přidání do Initial Extract skupiny
add extract EINILD1, sourceistable

Poznámka: sourceistable znamená, že Extract proces čte data přímo z db tabulek a ne z redo logů

Ověřte pomocí:
info extract *, tasks



B/ Na cílovém systému (v mém případě je stejný jako zdroj)

1. Vytvoření parametrického souboru pro Initial Load Replicat
ggsci
edit params RINILD1


Vložte do souboru:
-- Parametr file pro Initial Load Replicat (Delivery)
-- zapisuje data do tabulek OGG_TRG.*
--
replicat RINILD1
assumetargetdefs
userid ogg, password ogg
discardfile ./dirrpt/RINILD1.dsc, purge
MAP OGG_SRC.*, TARGET OGG_TRG.*;


Uložte soubor

Poznámka: assumetargetdefs znamená, že struktura zdrojových tabulek je shodná se strukturou cílových tabulek, discardfile určuje soubor do kterého budou uloženy chybné záznamy, map mapuje zdrojové tabulky na cílové

2. Přidání do Initial Replicat skupiny
add replicat RINILD1, specialrun

Poznámka: specialrun znamená, že jde o jednorázové zpracování dat bez udržování Chekpointů

Ověřte pomocí:
info replicat *, tasks



C/ Start a kontrola Inicializačního nahrání dat
Start provede dávkovou synchronizaci zdrojových tabulek uživatele OGG_SRC.* a cílových tabulek uživatele OGG_TRG.*

na zdrojovém systému:

start extract EINILD1
view report EINILD1




na cílovém systému (v mém případě shodný se zdrojem):

view report RINILD1



IV. Konfigurace a start Replicat (Delivery) procesu
Replicat proces čte cílový Trail soubor a aplikuje změny na cílové databázi. Replicat proces se konfiguruje na cílovém systému.

A/ Checkpoint tabulka
Oracle GoldenGate pro případ obnovy přenosu po chybě systému využívá mechanismu Checkpointů. Checkpoints jsou použity pro uchování současné čtecí a zapisovací pozice jednotlivých GoldenGate procesů (Extract, Pump a Replicat) během přenosu transakcí. Checkpoints pro Extract a Pump jsou uloženy v Trailu.

1. Založení / úprava GLOBALS parametru
ggsci
edit params ./GLOBALS


Vložte do souboru
CHECKPOINTTABLE OGG_TRG.GGSCHKPT

Uložte soubor a ukončete ggsci pomocí příkazu exit

Poznámka: soubor GLOBALS (globální parametry systému) se musí jmenovat velkými písmeny, být bez přípony a musí být uložen v root adresáři OGG na cílovém serveru.


2. Založení checkpoint tabulky
ggsci
dblogin userid ogg, password ogg

add checkpointtable





B/ Replicat proces

1. Vytvoření parametrického souboru
ggsci edit params ROGGTRG1

Vložte do souboru:
-- Parametr file pro Replicat (Delivery) proces
-- zapisuje data do tabulek OGG_TRG.*
--
replicat ROGGTRG1
userid ogg, password ogg
assumetargetdefs
discardfile ./dirrpt/ROGGTRG1.dsc, purge
map OGG_SRC.*, target OGG_TRG.*;


Uložte soubor

Poznámka: pro zabránění kolizi s inicializačním nahráním dat, lze použít parametr HANDLECOLLISIONS, který při INSERTu již existujícího záznamu (detekce duplicate-record) jej přepíše a při UPDATE nebo DELETE chybějícího záznamu (missing-record) zaznamená záznam do discardfile souboru.


2. Přidání do Replicat skupiny
add replicat ROGGTRG1, exttrail ./dirdat/rr


3. Spuštění Replicat procesu
start replicat ROGGTRG1

Ověření
info replicat ROGGTRG1

Poznámka: pro zabránění kolizi s inicializačním nahráním dat, lze Replicat proces nastartovat od určitého SCN pomocí parametru ATSCN nebo AFTERSCN



Testování replikace dat mezi zdrojem a cílem
V SQL nástroji spusťte DML operace nad tabulkou uživatele OGG_SRC, výsledek si následně ověřte nad tabulkou uživatele OGG_TRG.

1. Insert
Na zdrojové db:
...
...
insert into ogg_src.dept values (51,'APPS1','BRNO1');

insert into ogg_src.dept values (52,'APPS2','BRNO2');

insert into ogg_src.dept values (53,'APPS3','BRNO3');

insert into ogg_src.dept values (54,'APPS4','BRNO4');
insert into ogg_src.dept values (55,'APPS5','BRNO5');
commit;


Na cílové db:
select * from ogg_trg.dept;



2. Update
Na zdrojové db:
update ogg_src.dept set LOC = 'TABOR';
commit;


Na cílové db:
select * from ogg_trg.dept;



3. Delete
Na zdrojové db:
delete from ogg_src.dept; commit;

Na cílové db:
select * from ogg_trg.dept;



OGG statistiky pro Extract a Replicat procesy
Na zdrojovém systému (Extract proces):
ggsci
send extract EOGGSRC1 report

view report EOGGSRC1




Na cílovém systému (Replicat proces):
ggsci
send replicat ROGGTRG1 report
view report ROGGTRG1




Zastavení OGG procesů (Extract, Data Pump a Replicat)
ggsci
stop *

info *




Zastavení OGG Managera
ggsci
stop mgr

info mgr




Erik Eckhardt

čtvrtek 13. května 2010

Filtrování dat bez použití výzvy panelu, výzvy reportu nebo stránek kontingenční tabulky

Použití uživatelského výběru filtrů záznamů v sestavě se standardně provádí pomocí výzvy panelu. Často však chce uživatel vybrat hlavní kritéria pomocí VP, ale pak ještě v rámci výběru z VP chce provádět výběry přímo v sestavě aniž by musel ve výzvě panelu „mačkat“ tlačítko Start. Níže popsaný způsob dovoluje provádět dodatečné výběry záznamů přímo v sestavě. Jedná se však pouze o výběry pouze malého počtu výskytů.
Většinou se jedná pouze o výběr podle určitého typu nebo druhu.
Uvedený příklad prezentuje tento způsob.

Ukázka hotového „filtru“ v sestavě – možnost výběru druhu projektu:


Rozbalíme nabídku a vybereme „Interní“:


Výběr v tabulce se omezí na interní druhy projektů:


Jak toho dosáhneme?
Celý vtip je v přípravě zdrojů v business vrstvě BI modelu, které jsou filtrovány podle kritérií, jež chceme použít pro výběr v sestavě.

Ve fyzické vrstvě BI modelu vytvoříme pro každé omezení alias původní tabulky (např. FHODLINE_EXT a FHODLINE_INT jsou aliasy tabulky FHODLINE). Do faktové tabulky v business vrstvě přidáme jako další zdroje tyto alias tabulky. U každé alias tabulky nastavíme příslušnou podmínku, která provede omezení záznamů.



Pro každé omezení vytvoříme logický sloupec (např. INT a EXT) a nastavíme mapování. Např. sloupec INT mapujeme na sloupec PROJDRUH_CODE tabulky FHODLINE_INT.


Logické sloupce přesuneme do Prezentační vrstvy (INT – Interní a EXT – Externí).

V Answers přidáme do Složeného rozložení Výběr sloupce. Označíme, že sloupec obsahuje výběr a přidáme volby (logické sloupce Interní a Externí).


Toto řešení můžeme např. použít i pro omezení zobrazovaných v grafu:



Petr Jurászek, Věra Hubačová (IT Systems)

pondělí 10. května 2010

Oracle GoldenGate – Instalace

Instalaci a konfiguraci popisuji pro Oracle GoldenGate 10.4.0.x na MS Windows s Oracle Database 10g jako zdrojem i cílem (přesný postup instalace i pro ostatní verze, db platformy a OS viz. dodávaná dokumentace).

Úplný úvod do Oracle GoldenGate najdete v předchozím článku.


Download

Oracle GoldenGate pro Oracle Database 10g na Linuxu, Windows a Solarisu lze získat z OTN, pro ostatní verze, db platformy a OS z Oracle eDelivery.



Nastavení prostředí a splnění nutných požadavků

Přesný popis požadavků najdete v dokumentaci Oracle® GoldenGate Oracle Installation and Setup Guide Version 10.4.

DB klient
OGG vyžaduje, aby na Serveru existovala plná verze Oracle klienta nebo databáze (OGG potřebuje přístup k Oracle XDK a proto nelze použít Oracle Instant Client).

DB uživatelé a práva
OGG vyžaduje, aby ve zdrojové a cílové databázi existoval uživatel s následujícím oprávněním:


Zapnutí Supplemental Logging pro zdrojovou Oracle DB
Pro správné zachytávání aktualizací na primárních klíčích a „chained rows“ je potřeba na zdrojové databázi zapnout Supplemental Logging.

Spusťte SQL*Plus jako uživatel s ALTER SYSTEM oprávněním a napište:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER SYSTEM SWITCH LOGFILE;


Pro ověření napište (dotaz by měl vrátit YES nebo IMPLICIT):
SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;

Nastavení proměnných Windows
Ve Windows nastavte proměnné prostředí ORACLE_HOME a ORACLE_SID, které ukazují na Vaši Oracle databázi a instanci. OGG proces je používá při připojování k databázi.


Microsoft Visual C++ 2005 SP1 Redistributable Package
Ověřte, že máte nainstalován Microsoft Visual C ++ 2005 SP1 Redistributable Package, lze stáhnout zde.


Instalace
Oracle GoldenGate podobně jako Oracle Data Integrator není potřeba instalovat. Stačí stáhnout SW (Oracle GoldenGate V10.4.0.x for Oracle 10g on Windows 2000, XP, and 2003.zip ) a rozbalit jej do adresáře (po rozbalení bude mít cca 20 MB), který nesmí obsahovat MEZERY! (např. D:\Oracle\product\OGG).

Poznámka: Oracle GoldenGate (OGG) je potřeba nasadit na všechny zdrojové i cílové servery (v případě, že stejně jako já budete OGG pouze testovat, tak Vám stačí jedna DB, která bude zdrojem i cílem, tzn. OGG rozbalíte pouze jedenkrát).


Založení potřebných adresářových struktur pro OGG
Veškeré parametry, logy, skripty, přenášená data a další pomocné soubory jsou umístěny v adresářové struktuře root adresáře OGG.

Z OGG adresáře spusťte program ggsci.exe (Oracle GoldenGate Command Interpreter – příkazová řádka, ve které se s OGG provádí skoro vše, příkaz HELP Vám zobrazí dostupné příkazy) a v něm napište:
create subdirs
exit



Výsledkem je založení adresářové struktury v rootu OGG adresáře:



OGG Manager
OGG Manager lze startovat pomocí programu ggsci.exe a příkazu START MGR.


Před samotným startem je potřeba vytvořit parametrický soubor (mgr.prm) pro OGG Manager pomocí příkazu EDIT PARAM MGR (nebo ručně prostředky OS – všechny OGG procesy se konfigurují pomocí ASCII souborů).


Pro začátek soubor mgr.prm může být prázdný, OGG Manager při startu použije defaultní hodnoty, např. číslo portu bude 7809. OGG Manager loguje do souboru ggserr.log.


OGG Manager jako Windows Service
Na MS Windows je potřeba OGG Manager nainstalovat jako Windows Service, který poběží na pozadí a bude generovat události do Windows Event Logu.

Z OGG adresáře spusťte:
install addservice addevents

Výsledkem bude založení služby GGSMGR ve Windows:



Příště konfigurace OGG prostředí, procesů a start replikace.



Erik Eckhardt