You are on page 1of 9

OBIEE Performance Tuning

February 22, 2015 Leave a comment

This post describes a few tips and things to keep in mind for OBIEE Performance Tuning.

Be Proactive when possible


The need to performance tune can be proactive (tune before a major issue arises) or reactive
(tune after a problem is reported by users for example). It is best to be proactive so
performance tuning should be built into your OBIEE maintenance schedule. For example,
OBIEEs Usage Tracking functionality should be used regularly to identify reports whose
performance can be improved and then performance steps should be carried out on the worst
performers.

Iterative Process change one thing or set of things at a time


One of the first things to keep in mind is that performance tuning is an iterative process. And
there is typically no one silver bullet that will resolve all your performance problems. You
may need to analyze and make changes to multiple parts of the system, but you want to make
the changes methodically. It is best to change one parameter or setting at the same time (or
one related set of parameters). Adjust and test the settings for that one parameter/setting (or
set of parameters) before moving on to another. If you change too much at one time, you
may have a difficulty determining what is helping from what is hurting your efforts.

Fix user complaints first, worst performers next, and then the next bad performers
down the list
Another thing to keep in mind, tune what users are reporting first, then tune the worst
problems second, then move on to the next.

Team Effort problem could be anywhere along the technology stack


Performance problems could be anywhere along the technology stack:
OBIEE
Database
Server
Network
Due to that span of technology, performance tuning is a team effort. OBIEE Admins and
Developers, DBAs, and ETL Developers can all be key to solving performance issues.
Logs from all components may need to be reviewed depending on the scenario.

Try to isolate or narrow-down the source of the problem


For example, run the report SQL directly on the database and see if you have the same
problem. If there is no issue when run directly on that the database, then you have eliminated
the database as the problem.
Determine if other applications have been also been experiencing slowness which could
indicate the possibility of a network problem.

If your users have reported an issue, then you need to get as much details as possible about
the performance problems they are experiencing. When did this start happening? Is it just
one report or many? Is it localized to one business area or multiple? Is it all the time or
sometimes? Knowing this will help you to know where to focus.

Other questions to ask as you try to identify the source of the problem include but not limited
to:
Has anything changed? If reports were running fine, but are now slow, the first thing to ask is

When the issue start? Determining exactly when it started might be helpful when correlating
with other system or company activity)
What has changed recently? Has there been any system changes, data changes, database
updates, network changes, etc. (even if they seem unrelated)? For example, rolling into a
new calendar year will cause new Year value(s) to be included in the data and can impact
performance if statistics are not gathered.
Is there a possibility that an index was dropped and not recreated as expected?

Use OBIEEs Usage Tracking information to analyze specific reports, analyze long running
reports, or frequently run reports. You will want to capture and analyze the SQL from these
reports to determine what can be done to improve their performance.

Database
DBAs can monitor the system in real-time, use various tools, or review logs for information
that can be helpful in the tuning effort. Tools such as Oracle Enterprise Manager (EM) or
SQL Tuning Advisor can be used to identify, analyze and tune high-load SQL.
OBIEE Usage Tracking can also be used to identify high-load SQL.
Without getting into much detail, these are some database features that could be used to help
improve performance:
Gather Statistics
Results Cache database feature
Partitioning

Servers
The System Admins can monitor the server resources to determine if there is an issue there.
Use fast disk for the OBIEE cache and/or temporary files.

OBIEE-specific performance tuning tips

OBIEE Caching
Are the tables being used set to cacheable?
Is caching turned on at the application level?
You may consider seeding the cache daily.
CACHE Settings:
o MAX_ROWS_PER_CACHE_ENTRY
o MAX_CACHE_ENTRY_SIZE
o MAX_CACHE_ENTRIES
o -
o USE_ADVANCED_HIT_DETECTION
Use Aggregation: Aggregate data when applicable
o You can use Aggregate tables or materialized views to realize this benefit.
o Aggregate Fact tables and corresponding Aggregate Dimensions.
o Make sure aggregation rules are applied to Fact table measures.
o Dont necessarily merge all measures into a single fact.

Joins and Indexes


o Do not create unnecessary joins.
o Verify that the joins on the tables being investigated are appropriate.
o Performance Indexing could be helpful. Again, this is an iterative process.

Prompts and Filters


o Use LOV tables to drive prompt values when possible, instead of building prompts from
large transactional data tables.
o Force filter selection / entry by making prompt values required. Do not allow open ended
run of reports.

Filter out unneeded data. If there is a significant amount of data that is not being used in
one or more tables (especially if they are frequently used), then that data should be filtered
out by the ETL before it gets joined in SQL, and then has to be filtered out in the RPD or at
the report level.

Enter the Number of Elements at this level value in the logical level in hierarchies.
Also ensure that all logical level keys are unique.

Avoid function in the where clause when possible.

Be careful of sub-queries.

Check out the features of the OBIEE Performance Monitor


http://server:port/analytics/saw.dll?Perfmon (enter your OBI server and port)

When possible, do comparison analysis to determine for example, why is this report running
fine, but this other seemingly similar report is not.

Use fast disk for the OBIEE cache and/or temporary files.

Sometimes a complete overhaul might be required


Review the users workflow and determine if new and improved queries can be written or if
the number of queries can be reduced.
Present information from a summary level first, and then provide increasing levels of details
as requested by users through drill down or navigation. Basically, present detailed
information only when necessary, and minimize the amount of detail provided at a time by
filtering on user selections.

Oracles OBIEE Performance Tuning Guide


Apply recommendations from the Best Practices Guide for Infrastructure Tuning Oracle
Business Intelligence Enterprise Edition 11g Release. I would recommend applying 1 3
changes or set of changes at a time; dont apply everything at the same time because if there
is a problem, it will be more difficult to determine which change caused it.
https://blogs.oracle.com/proactivesupportEPM/entry/wp_obiee_tuning_guide

Filed under Business Intelligence, Data Warehousing, OBIA, OBIEE, OBIEE 11g, OBIEE
Administration, OBIEE Best Practices, Performance Tuning Tagged with OBIEE
Performance Tuning, Performance, performance problems, performance tuning

New OBIEE Tuning Guide (Version 4) released Jan 2014


March 5, 2014 Leave a comment

A new version of the OBIEE Tuning Guide (Version 4) was released in January, 2014. It is
suitable for OBIEE 11.1.1.6 and 11.1.1.7 versions.

It can be found on Oracle Support under Document ID 1333049.1. Or here is a direct link to
the document (PDF).

New highlights from the previous document include:

Optimized JVM switches for JRockit / Sun JVM / IBM JVM

New tuning parameters settings / values for JavaHost / OPIS / OBIS components.

Improved performance monitoring techniques.

IBM WebSphere tuning parameters.

More WebLogic Server tuning parameters.

Windows Server 2012 tuning parameter.

New optimized Linux / AIX tuning parameters.

Additional Essbase ASO tuning parameters.

libOVD authenticator search tuning

As always, this document provides us with recommended baselines or starting points, but the
appropriate settings for each environment will vary.

Filed under Business Intelligence, Enterprise Manager Fusion Middleware Control, OBIEE
10g to 11g Upgrade, OBIEE 11g, OBIEE Administration, OBIEE Best Practices,
Performance Tuning, WebLogic Administration Console Tagged with OBIEE 11g
Performance Tuning Guide, OBIEE Performance Tuning
How to clear the BI Server cache using command line
script or via the Issue SQL page
October 11, 2013 1 Comment

This post will explain how to clear the BI Server cache using either (1) a script, or (2) the
user interface.
You may need to clear your cache to allow the data in the cache to get refreshed.

(1) Clearing the cache using Command Line script

This example is for Linux/Unix, but can be easily adjusted for Windows.

Create a file called purgecache.txt and place it at


[FMW_HOME]/instances/instance1/bifoundation/OracleBIApplication/coreapplication/
setup

In the file, enter the code call SAPurgeAllCache() (without the quotes) which is a
special BI Server command for clearing the entire cache.

Then create a shell script called purgecache.sh, located in a directory where you store your
custom scripts which includes the following 2 commands

(Note: there is a space after the dot in the below command)


./
[FMW_HOME]/instances/instance1/bifoundation/OracleBIApplication/coreapplication/
setup/bi-init.sh

(Note: the below is ONE long command; not 2 commands)


[FMW_HOME]/Oracle_BI1/bifoundation/server/bin/nqcmd -d AnalyticsWeb -u
administrator -p pswd s
[FMW_HOME]/instances/instance1/bifoundation/OracleBIApplication/coreapplication/
setup/purgecache.txt

Then you may execute the shell script just as you would any other script (for example
./purgecache.sh ) -or- you may add this new script to your crontab if desired for example,
to run each night before your cache seeding reports run.

(2) Clearing the cache using the Issue SQL page

Log into OBIEE Analytics using an ID that has the Administration link privilege.
http://server:9704/analytics

Click on the Administration link located at the top right of the page.
Click on the Issue SQL link at the bottom left of the page.

In the Issue SQL window, enter the command: call SAPurgeAllCache() (without the
quotes)
Click the Issue SQL button to execute the command.

You should see a message indicating that the command was executed successfully (assuming
you have caching turned on).

Your cache directory located at


[FMW_HOME]/instances/instance1/bifoundation/OracleBIServerComponent/
coreapplication_obis1/cache
should now be empty.

Filed under OBIEE 11g, OBIEE Administration, Performance Tuning

Informatica Unconnected Transformations


September 30, 2013 Leave a comment
There are 3 Informatica transformations (External Procedure, Lookup, and Stored Procedure)
that can be unconnected in a valid mapping. An unconnected transformation is one that is not
connected to the pipeline that is, it is not connected to any other transformation via a link.
Unconnected transformations, especially unconnected lookup transformations, are widely in
OBIA mappings.

Unconnected transformations are defined in a mapping and are called / invoked from another
transformation in the mapping. They can be called from any transformation that supports the
transformation expression language.

Below is a list of the 3 Informatica Unconnected Transformations and how they are called or
invoked from another transformation:

Transformation How its called / invoked


External :EXT.external_procedure_transformation(argument1, argument2, )
Procedure
Lookup :LKP.lookup_transformation(argument1, argument2, )
Stored Procedure :SP.stored_procedure_transformation( argument1, argument2, [,
PROC_RESULT])

Any mapping with an unconnected transformation must also include another transformation
that calls the unconnected transformation.

All of the 3 Unconnected Transformations can also be used in connected mode. However,
when you want to execute the transformation logic for a subset of the rows passing through
the mapping (especially when its a small percentage of the rows), you will want to consider
using the transformations in unconnected mode and with conditional logic. The conditional
logic will cause the unconnected transformation to execute only when necessary, and
therefore, may improve perfiormance.

The example below shows a call to an unconnected lookup transformation (lkp_item_id) that
is invoked only when the desired item_id value is NULL. In a case where only a small
percentage of the rows have an item_id that is NULL, then the lookup would only be invoked
for a small number of rows, as opposed to all rows if the transformation was connected.

IIF ( ISNULL(item_id), :LKP.lkp_item_id ( item_name ), item_id )

As a side note, the Sequence Generator transformation can also be invoked from a function
call, but it is a connected transformation.

Transformation How its called / invoked


Sequence Generator :SEQ.sequence_generator_transformation.CURRVAL

Filed under Data Integration, Informatica, Oracle Business Intelligence Applications,


Performance Tuning Tagged with Informatica, OBIA, unconnected lookup, unconnected
transformations, unconnected transformations invocation syntax
OBIEE Tuning Whitepaper from Oracle (has
been updated)
March 7, 2013 Leave a comment

Oracle has released an updated version of their OBIEE Tuning Whitepaper.

You can find the document here

https://blogs.oracle.com/pa/entry/test

or here

https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?
_afrLoop=212370301476321&id=1333049.1&_afrWindowMode=0&_adf.ctrl-
state=w65avp7pa_30

You will need to have an Oracle ID to access it (which is a free sign up).

In addition to all the great information that was in the original document, the updates to the
document include:

New improved HTTP Server Caching algorithm

Oracle iPlanet Web Server tuning parameters

New tuning parameters settings / values for OPIS/OBIS components

The topics included in the document are:

1.0 Performance Overview

1.1 Introduction to Oracle Business Intelligence EE Performance


1.2 Performance Terminology
1.3 Understanding Key Performance Drivers

2.0 Top Tuning Recommendations for OBIEE

2.1 Tune Operating Systems parameters.


2.2 Tune Oracle WebLogic Server (WLS) Parameters
2.3 Tune 64bit Java Virtual Machines (JVM)
2.4 Tune 32bit Java Virtual Machines (JVM)
2.5 Tune HTTP Server Parameters
2.6 Tune HTTP Server Compression / Caching
2.7 Tune Oracle Database Parameters

3.0 Performance Monitoring OBIEE


3.1 Built-in BI Metrics for Performance Monitoring
3.2 Performance Monitoring In Windows Environment
3.3. Performance Monitoring In Unix Environment

4.0 Tuning OBIEE Components

4.1 Oracle BI Presentation Services Component


4.2 Oracle BI Server Component

5.0 Tuning Essbase

5.1 Essbase ASO Tuning

You might also like