How Different RAM Consumption OBIEE11g by Installation Type

As we all know OBIEE 11g has three install types: Simple Install, Enterprise Install, Software Install.

We had low end PC with 2GB RAM and RHEL6 and OBIEE Standard Editon One Licence 11.1.1.7.0 64bit linux.  So we had to make decision which install type to use to stay minimal.

Here are results for OBIEE + Publisher only installation. No EssBase or Real Time Decisions:

Enterprise Install consumes less RAM than Simple Install – by ~200 MB. Would be nice to prove with more tests. That’s a bit controversy as enterprise install has node manager running, extra managed server running. So it’s at least two more services running than Simple Install case.

Enterprise Install

=0.172+1.5+4.1+1.3+15+9.8+0.684=32.556 MB

=0.004+3.1+0.004+696.7+0.004+408.2=1108.012 MB

Total = 1140 MB

Simple Install

=0.008+1.7+0.852+8+23.4+1.7+6.7=42.36 MB

=0.044+0.044+1300=1300.088 MB

Total = 1343.14 MB

Labai svarbus OLAP komandai – įgūdis sugebėti suprojektuoti ir suprogramuoti pirmą release’ą duomenų sandėlio ir ataskaitų su netikrais duomenimis, kol dar nėra suprogramuota OLTP sistema.

Tačiau čia reikia būti labai profesionaliu, kad nesgautų darbas dėl darbo. Tai yra sugaištas laikas nėbūtų visiškai nenaudingas kuriant antrą versiją, kai jau yra OLAP sistema pakankamai nusistovėjusi.

Dažniausiai toks scenarijus būna kai startuoja projektas nuo nulio. Viena komanda projektuoja OLTP sistemą, kita – OLAP sistemą. Abi remiasi tais pačiais analizės dokumentais.

Tačiau vienaip ar kitaip, ko neįvertina projektų vadovai, kad OLAP (ataskaitų) sistema niekada nepradės veikti anksčiau nei OLTP sistema. Tai yra ataskaitų kūrimo komanda vis tiek yra priklausoma nuo OLAP kūrimo komandos.

Dažniausiai ta priklausomybė yra neigiama, nes jei vėluoja OLTP komanda, vėluose ir OLTP komanda. Atvirkštinė priklausomybė retai būna.

 

Repository Documentation Utility Do Not Export Unlinked Physical Tables

There is not very often used Repository Documentation utility.

clip_image001

Objects which are not added to business layer are not added to generated documentation CSV file. Objects table1, table2 exists in physical layer only. They are not mapped at business and presentation layer.

clip_image002

Therefore generated CSV file doesn’t contain those physical tables.

clip_image004

Oracle Fusion Tap

Ką tik peržiūrėjau video apie Oracle Fusion Tap programą, skirta Apple planšetėms (kodėl tik Apple?!). Gal todėl, kad USA vadovai naudoja tik Apple…

Įdomus filmukas, apie tai kaip panaudoti duomenų sandėlį ir specialią programinę įrangą veiklos analizei konkrečioje srityje. Šios programos esmė, kad leidžia darbuotojui dirbti bet kada ir bet kur panaudojant kiekvieną laisvą akimirką: autobuse, kavinėje, tualete..

Programa apima, kiek supratau HR, CRM ir pagrindinius verslo rodiklius.

Štai tas filmukas, o nuorodoje ir visas straipsnis.

[youtube=http://www.youtube.com/watch?v=ELNpasrRvgc&w=448&h=252&hd=1]

OBIEE11g ir Active Data Guard

Straipsnyje Configuring Oracle BI EE Server with Oracle Active Data Guard rašo kaip OBIEE11G sujungti su aktyviais atsarginiais serveriais panaudojant Oracle Active Data Guard technologiją.

Active Data Guard leidžia turėti vieną ar daugiau identiškų produkcinei duomenų bazių, kurios automatiškai atnaujinamos pagal paskutinius duomenų pakeitimus produkcinėje. Šias duomenų bazes pavadinsiu atsarginėmis. Dažniausiai jos būna “miegojimo režime” (stand-by).

Šios atsarginės duomenų bazės gali būti panaudojamos skaitymo režime (read-only). Kadangi duomenų sandėlys praktiškai visada yra tik skaitomas, tai straipsnyje siūlo panaudoti atsarginę duomenų bazę:

  1. Kaip atsarginį sandelio serverį nelaimės atveju (disaster recovery), nes duomenys identiški gamybinei
  2. Kaip testavimo aplinką, nes duomenys identiški gamybinei.
  3. Kaip sistemos išplėtimą, nuimant ataskaitų sukuriamą krūvį nuo pagrindinio DB serverio.

Norint tai padaryti reikia dviejų dalykų:

  1. OBIEE turi būti sukonfigūruotas taip, kad rašymo operacijos eitų į pagrindinę duomenų bazę.
  2. Skaitymo operacijos naudotų atsarginę duomenų bazę skaitymo režimu.

Tai yra padaroma Saugykloje (Repository) sukuriant du Connection’us. Pirmą – į atsarginę duomenų bazę ataskaitų užklausoms. Antrą – į pagrindinę duomenų bazę duomenų koregavimui.

Dar parodyta kaip teisingai sukonfigūruoti naudojimo sekimą (Usage tracking), kešavimą (Event pooling).

#1 Terminai

Pivot – pivot reiškia, stulpelio reikšmes perkelti į atskirus stulpelius, kiekvienai reikšmei po vieną stulpelį. 

Pvz, jei pirmas stuleplis buvo su pavadinimu Metai ir trys reikšmės: 2010, 2011, 2012.

Tada po pivot operacijos, lentelėje dingsta stulpelis Metai ir atsiranda trys stulpeliai: 2010, 2011, 2012.

 

OWB patarimai #1

  1. Nenaudoti dimensijos atributo, kuris yra išorinis raktas agregavimo funkcijoje ar duomenų išvedimui. Tokiu atveju geriau sukurti dubliuotą atributą.
  2. Iš duomenų šaltinio į OWB įkelti visas lenteles ir visus jų stulpelius (jeigu jų nėra tūkstančiai). Dažniausiai tai apima vienos duomenų bazės ar schemos kontekstą.
  3. Mapping’uose naudoti tik tuos atributus, kurių reikia. Dėl greitumo nepermetinėti visų atributų iš vieno objekto į kitą, o paskui tik sujungti rodyklėmis, kuriuos reikia.