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/

It is 100% free of Chicken Soup.
 

Great news about the new doc! Hope you get some good insight from them. Nice that the client was willing to let you work from home so you could be there, too.
 

Wonderful to hear. My twin brother went through something similar at a young age...now he's going to med school..best wishes.
 

HI Chet

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.

Just my 0.02

Mark
 

Mark,

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...) .

Anyway, thanks again for the comment. It is most helpful.

chet
 

@oraclenude

Thanks for the tip there...I went out and read some of his blog and his post on www.hopefulparents.com...sounds like someone I could talk to.

Kris has seen that book before, but for whatever reason, never got around to buying it. It's on the list now.
 

McG,

Med School? You mean I might have to pay for that? :)

That's awesome...we love to hear stories like that.
 

@JP

Kudos to the client. Very cool of them indeed.

Unfortunately, Kate transferred her Plague to me and I've been sick all week. I think she transferred her inability to handle illness to me as well. Better me than her though right?