OBIEE Cache management

OBIEE is binnen de Oracle stack aangewezen als de rapportage front-end tool. De cache management mogelijkheden worden door Oracle naar voren gebracht als een krachtige feature.

Waarom zou je cache management van een rapportage tool moeten doen?

In een ideale wereld hoeft het namelijk helemaal niet. Je hebt een prachtig datawarehouse waar alle data in een grote kubus zit, welke razendsnel te raadplegen is via alle denkbare dwarsdoorsneden.

In de echte wereld zitten niet alle tabellen in het DWH, duurt het samenstellen van sommige aggregaten uren en komt de Excel sheet van Planning en Control altijd twee dagen na de start van de maandelijkse load binnen.

Een mogelijke (deel)oplossing voor deze problemen zou een stukje cache management kunnen zijn. Een cache wordt in dit artikel gedefinieerd als "een opslag plaats voor al bewerkte / geaggregeerde data".

In het hele OBIEE rapportage traject zijn er een viertal punten waar een cache bijgehouden kan worden:

• De Database:
  • Eigenlijk de beste plek voor een cache. De meeste databases hebben een behoorlijk grote "Shared Pool" constructie en kunnen deze hoeveelheid data "in memory" cachen, wat altijd sneller is dan de data te moeten lezen van schijf.
• De BI-Server:
  • Hoewel het zich lijkt te gedragen als een database is dat beslist niet het geval! De cache wordt als een "Flat File" opgeslagen op schijf. Het kent bijvoorbeeld geen indexen.
• De PresentationServer / Webserver:
  • OBIEE zal eerst controleren of het rapport al een keer gelopen heeft binnen de huidige sessie. Er wordt alleen gecontroleerd of de fi lter parameters niet gewijzigd zijn. Er vindt hier geen check plaats of de data in de bron gewijzigd is.
• De Cliënt Browser cache:
  • Hier wordt vooral gekeken of plaatjes al lokaal aanwezig zijn. Omdat sommige grafi eken als GIF of JPG weergegeven worden kan de browser hier de verkeerde versie oppikken. Indien mogelijk dient deze cache te worden uitgezet. In dit artikel wil ik vooral aandacht geven aan de BI-Server cache in het OBIEE rapportage traject.

Cache kandidaten

Binnen OBIEE is per tabel/view aan te geven of en hoe lang data in een cache mag blijven staan. Standaard staat deze altijd op "never expire" / "blijft eeuwig geldig". Dit is in de meeste gevallen prima als er extern cache onderhoud plaatsvindt. Indien dit onderhoud niet gepland is mag de cache levensduur natuurlijk niet langer zijn dan de verversinterval van het DWH.

Let op, dit kan bij een verversinterval van 24 uur ook leiden tot een theoretische "cache vertraging" van 24 uur. Beter is in dit geval om de cache duur te beperken tot 5 a 10% van de DWH verversinterval.

Bij tabellen die rechtstreeks van een OLTP systeem afkomen en waar de query de laatste stand opvraagt die nog niet in het DWH zit, moet de cache voor deze bron uiteraard uitgezet worden. Als niet altijd de allerlaatste stand nodig is, kan een cache periode van bijvoorbeeld een uur zorgen voor de nodige rust op het OLTP systeem

Hoe raadpleegt OBIEE de cache?

Eerst wordt gecontroleerd of alle tabellen van de query "cacheable" zijn. Als een of meerdere tabellen niet gecached mogen worden wordt het verzoek compleet doorgestuurd naar de database. Vervolgens wordt het verzoek gecontroleerd op complexiteit van de berekening. Deze mogen niet "dieper" gaan dan het ingestelde maximum (bv: COUNT(SIN(COS(TAN(RND* SUM(column)))))).

Er volgt een check of er gebruik gemaakt mag worden van de "algemene" cache of dat er als gevolg van de gebruikersrechten (VPD) slechts een bepaald deel van de cache gebruik mag worden. Uiteindelijk gaat OBIEE kijken of hij op basis van de reeds aanwezige cache delen het verzoek kan oplossen. Indien dit niet het geval is zal hij een verzoek op de database(s) uitvoeren en indien toegestaan aan de cache toevoegen.

Hardware

OBIEE houdt zijn cache bij op de harde schijf. Dit betekent dat u vooral moet investeren in snel toegankelijke schijven. Investeren in hele grote schijven heeft niet heel veel zin omdat OBIEE maximaal vier Gb per directory kan wegschrijven. Beter is om te investeren in een aantal kleinere snelle schijven. Als u de cache verdeeld over meerdere schijven is het te overwegen om iedere schijf zijn eigen controller te geven. Onder de meest ideale omstandigheden maakt u één of meerdere RAM - schijven aan. Dit heeft wel als nadeel bij een powerdown de cache weg is, maar dat is weer met een stukje cache scripting op te vangen.

Beheer

De OBI cache dient met als iedere andere cache beheerd te worden.In het bijzonder als het DWH ververst is dient natuurlijk (een gedeelte van) de cache vervangen te worden. Dat kan op verschillende manieren:

• De hele cache verwijderen.
• De cache per query verwijderen.
• De cache per tabel verwijderen.
• De cache per gebruiker verwijderen.

Na het leegmaken van de cache kan deze weer gevuld worden. Het meest logische is om dit te doen door de query(s) die het vaakst gebruikt worden alvast een keer af ter vuren. Hoewel het technisch mogelijk is leid het vullen van de cache met een gehele (aggregaten) tabel meestal niet tot performance verbetering, tenzij deze tabel slecht/tijdsgebonden op de bron database toegankelijk is. Het vullen van de cache op gebruikersnivo is van toepassing als er een vorm van datasecurity is ingericht waarbij de zichtbare data afhankelijk is van de toegangsrechten van de gebruiker. Als men gebruik maakt van een Virtual Private Database model dient men dit ook op de BI-server in te regelen om te voorkomen dat de ene gebruiker via de cache van een andere gebruiker de "verkeerde" data ziet.

Pas op

Het gebruik van cache mechanismes kan erg handig zijn, maar het gevaar is dat de BI-server wordt "misbruikt" als datastorage. OBIEE is beslist geen database! Een overmatig cache gebruik kan de echte problemen in het ontwerp van het DWH verbloemen.

John Minkjan is principal BI consultant en OBIEE Product Expert bij Ciber (www.ciber.nl). Hij is eigenaar van een van de grootste blogs rond OBIEE: http://obiee101.blogspot.com en genomineerd voor de BI-Dutch (www.BI-dutch.nl) consultant van het jaar 2008.