Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Dummies Guide - Enterprise Application Deployment Options | Main | OBIEE 11G Performance Optimization Strategies - Part II »

OBIEE 11G Performance Optimization Strategies - Part I

Any BI project is not only about implementation but is rather a complete lifecycle with activities required in the stages pre, during and post implementation. Coding the business requirements to achieve the desired results is just one part of the engagement. For a BI project to be successful it is not enough to deliver accurate information but it also has to be delivered in an optimal time frame.

The tuning, optimizing and performance monitoring is a very critical part to the implementation of an OBIEE solution yet is very commonly overlooked. In the following sections, we discuss Oracle BI performance and focus on the areas generally hit and the common optimization strategies.

Expectations Around OBIEE Performance

Before we go into the strategies that can be employed, we need to understand and identify what is good performance and what is bad before any action is taken on it. The reason behind any bad performance could be very basic in nature (connection pools not configured properly) or could be a result of disconnected development brought on by ignorant RPD building practices.

The common areas affected by performance degradation are listed below

  • Application availability and access
  • Retrieval and display of data on reports and dashboards within an optimal timeframe
  • Responsiveness of reporting application
  • Minimal impact of an increase in the number of concurrent users on the application responsiveness

Reporting Design Considerations

1. Extensive formatting of reports

Any formatting of reports (conditional or otherwise) has overhead on the system compared to simple tabular reports
Pivot Tables and Charts If a significant number of Charts or Pivot table views exist on a dashboard page, one should consider changing the existing reports to Table view to help performance

2. Defaulting Dashboard Prompts 

Using a default value for the prompts in dashboards ensures that the reports will return a smaller result set
Hidden sections and guided navigations Always check for any hidden sections and guided navigations on a dashboard page since these will always run

3. Push Complicated Calculations to BI RPD 

Complicated calculations should be coded in the BI repository rather to ensure the presentation services displaying the results in optimal time

The performance monitoring tool provided by Oracle provides key insights into the system performance and can be used to get details related to the cache usage, catalog access, the chart engine performance, presentation services sessions and connection pools amongst many other useful insights

In the next part we will dig a little deeper and discuss the RPD design considerations and DB Layer troubleshooting.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles