This is my presentation from last week’s Rittman-Mead BI Forum in Atlanta. Incidentally it happens to be the same topic (similar slides) to the KPI Partners webinar from April and what I gave in Denver at Collaborate also in April. The webinar has been recorded, so you can hear my commentary and the QA session afterwards. If you get the chance, I’ll be doing the same preso at Kscope in New Orelans next month. Enjoy!
The BI Apps from Oracle present customers with a nice head start to getting their BI environment up and running. Financial Analytics, HR Analytics, Supply Chain Analytics, etc. all come pre built with much of the code and reports you’ll need to build to support your business. But for many customers they just are too slow for their user community while running dashboards, reports and ad-hoc queries. In an era where an internet search engine can give you what you want in one second, reports running for a minute or more are just not acceptable.
In this post I’ll discuss some of the inherent performance limitations in the BI Apps and what you should do about it. Note the vast majority of customers really don’t have a performance problem with their system, but you can always deliver reporting content faster. If you are running at 15 seconds per page, wouldn’t 5 seconds be that much better? The performance problem really lies with some large customers with larger data volumes. It is here where the BI Apps design can be enhanced with more performance in mind.
I’ve written about OBI performance a few times in the past, and I’m sure there will be more to come. As a refresher, here are a few other posts to take a look at:
- Achieving Good Performance with OBIEE
- OBI Performance Preso
- Performance Tuning Financial Analytics
- Stitch Joins
In the past I’ve written and presented on OBI performance from the ‘before perspective’: before you begin development, what are the things you should plan on and how should you implement them. This paper however is with the ‘after perspective’; what to do if you are stuck with a performance problem that you need to solve quickly. It will use the Financial Analytics (All versions) application from Oracle’s BI Applications (aka the BI Apps) to walk through a plan of attack and demonstrate specific changes using the Oracle Database 10x. Thus, this paper has two purposes:
- Specifically to document actual changes for Financial Analytics
- Generally to walk through a performance tuning effort that you yourself may undertake
Note: You do not need to be working on Financial Analytics or even the BI Apps for the concepts in this article to apply. It merely uses Financial Analytics as its example, and where appropriate I will explain the model.
I’m going to do something a bit different with this article in that I will tell the story of a recent performance tuning project for a client. A previous integrator had delivered Financial Analytics and it was up and running in a production environment, but the performance was terrible. Many queries were over 8 minutes. We were asked to tune the GL Transactions star, but the lessons learned here will work for all modules of Financial Analytics, regardless of version. In fact, implementing them for only one star actually boosted the performance of the other Financial Analytics Subject Areas. Read the rest of this entry