Monday, February 8, 2010

Random Things: Volume #13

A brief respite for me...I get to work remotely this week.

Admittedly I have gotten into the habit, finally, of traveling, so it's a little strange to be home (never thought I would say that). There is no shortage of respect from me for those who travel all the time. It's a hard life.

OBIEE PerformanceOur Usage Tracking reports are a tad slow and I've been looking into the logs trying to decipher them. Unlike the database which has a multitude of resources, OBIEE has hardly any. Christian did point me to this Mark Rittman article, which is good, but not great (not because the author is lacking...there just isn't that much to go on). rnm1978 suggested MOS, but I don't have access right now...besides, it seems to be having problems again anyway.

While I'm on the subject of performance and rnm1978, I should link up to this article which highlights 3 recent posts by Cary Millsap. All 3 are excellent reads and require your immediate attention.

KateThe reason I am home this week is so that I can go to a Doctor's visit with Kate. We finally found a place where they might be able to help diagnose her. Most of her doctors have been more concerned with keeping her alive (healthy) and haven't worried too much about her developmental delays (still not talking...but she can sign "daddy"). Anyway, the place is called The Tridas Center and we're excited/nervous. Excited about finding her better help and nervous about the possibilities (more specifically, what a diagnosis would mean).

8 comments:

Sweet Jesus, I don't want to be the guy that recommends Chicken Soup crap to anyone but this is a good book by a good writer about his family's journey to discover what was amiss with his daughter: http://www.schuylersmonsterblog.com/

Regarding the thoughts on OBIEE performance. Here's my thinking on the subject.

When I found out about concepts such as OBIEE "driving tables", level 5 logging and BI Server execution plans, my first reaction was to try and dissect them, try and understand them in the same way that I understand the various types of Oracle joins (hash/nested loop etc), Oracle trace files, 10035 traces etc. At the end of the day the BI Server is a virtual database engine and it makes sense to understand and tune it in the same way that we do with Oracle.

But then, the reality is, if you are spending time understanding level 5 log files, the various federated query optimization techniques, to be honest you'd be better off trying to optimize the underlying data so that the BI Server didn't then have to use these features.

For example - if you're trying to optimize a federated query, you should try and co-locate the data instead, either by copying both data sets to the same physical database, or better still, combine them into a data mart or warehouse. If you are having problems with aggregation and start thinking about the Aggregate Persistence Wizard - well you'd be better off putting the data into Essbase instead, and run OBIEE against that rather than your detail-level database.

And so on. So whilst it's interesting to see how the internals of the BI Server work, how it joins data, how you can optimize cross-database joins etc, in the end this is more from the intellectual angle, as you get far more "bang for your buck" by sorting out the data layer away from OBIEE and then bring a more optimized set of data into the BI Server. "Less is more" is my perspective with OBIEE, and the more that we can do at the (Oracle) database or (Essbase) OLAP server end, and keep the BI Server model simple, is the better in my book.

Thank you for saying that! I feel that way myself but don't yet have the authority to speak towards OBIEE as I would desire.

Understanding that no small amount of work has gone into building the engine that powers Oracle, it's hard for me to fathom that another tool could replicate that as easily without statistics or other knowledge of the data. My belief is that we are trying to use OBIEE like a database itself, when it shouldn't be (I did, (half) jokingly, suggest we put Oracle between the database and OBIEE...) .