This article has been superseded by a newer version: Instrumenting OBIEE Database Connections For Improved Performance Diagnostics (Previously on this blog: 1, 2, 3…) Summary Instrument your code. Stop guessing. Make your DBA happy. Make your life as a BI Admin easier. The Problem OBIEE will typically connect to the database using a generic application account. (Hopefully, you’ll have isolated it to an account used only for this purpose - if you haven’t, you should.

Here’s a quotation that I’ve just read and wanted to share. It is all part of a BAAG approach to troubleshooting problems, performance in particular. From Greg Rahn (web|twitter) on oracle-l: There are always exceptions, but exceptions can be justified and supported with data. Just beware of the the silver bullet syndrome… The unfortunate part […] is that rarely anyone goes back and does the root cause analysis. It tends to fall into the bucket of “problem…solved”.

Here’s a scenario that’ll be depressingly familiar to most reading this: after ages of running fine, and no changes to the code, a query suddenly starts running for magnitudes longer than it used to. In this instance it was an ETL step which used to take c.1 hour, and was now at 5 hours and counting. Since it still hadn’t finished, and the gods had conspired to bring down Grid too (unrelated), I generated a SQL Monitor report to see what was happening: [sourcecode language=“sql”] select DBMS_SQLTUNE.

Just because something produces the correct numbers on the report, it doesn’t mean you can stop there. How you are producing those numbers matters, and matters a lot if you have an interest in the long-term health of your system and its ability to scale. OBIEE is the case in point here, but the principle applies to any architecture with >1 tiers or components. Let me start with a rhetorical question.

This post expands on one I made last year here about sampling frequency (of I/O throughput, but it’s a generic concept). The background to this is my analysis of the performance and capacity of our data warehouse on Oracle 11g. Before I get too boring, here’s the fun bit: Pork Pies per Hour (PP/h) Jim wants to enter a championship pork-pie eating competition. He’s timed himself practising and over the course of an hour he eats four pork pies.

Cary Millsap recently published a paper “Mastering Performance with Extended SQL Trace” describing how to use Oracle trace to assist with troubleshooting the performance of database queries. As with all of Cary Millsap’s papers it is superbly written, presenting very detailed information in a clear and understandable way. (and yes I do have a DBA crush ;-)) It discusses how you can automate the tracing of specific sessions on the database, and requiring the application to be appropriately instrumented.

I’ve been involved with some performance work around an ODI DWH load batch. The batch comprises well over 1000 tasks in ODI, and whilst the Operator console is not a bad interface, it’s not very easy to spot the areas consuming the most runtime. Here’s a set of SQL statements to run against the ODI work repository tables to help you methodically find the steps of most interest for tuning efforts.

Jeff McQuigg has posted two presentations that he gave at Openworld 2010 on his website here: http://greatobi.wordpress.com/2010/10/26/oow-presos/ They’re full of real content and well worth a read. There’s excellent levels of detail and plenty to think about if you’re involved in OBI or DW development projects.

Introduction We’re in the process of implemention Resource Manager (RM) on our Oracle 11gR1 Data Warehouse. We’ve currently got one DW application live, but have several more imminent. We identified RM as a suitable way of - as the name would suggest - managing the resources on the server. In the first instance we’re looking at simply protecting CPU for, and from, future applications. At some point it would be interesting to use some of the more granular and precise functions to demote long-running queries, have nighttime/daytime plans, etc.

@alexgorbachev tweeted me recently after picking up my presentation on Performance Testing and OBIEE. His question got me thinking, and as ever the answer “It Depends” is appropriate here :-) Why is the measurement being done? Without knowing the context of the work Alex is doing, how to measure depends on whether the measurement needs to be of: - The actual response times that the users are getting, or The response times that the system is currently capable of delivering This may sound like splitting hairs or beard-scratching irrelevance, but it’s not.