OBIEE Caching Best Practices

One of my recent discussions with a colleague on the caching strategy for OBIEE resulted in the following Best practices; Oracle BI Server is an Intelligent Query Engine that stores database hits in a cache file, this cache file is stored on the BI server.

OBIEE Architectural Best Practice feature is to implement the caching mechanism by using the following methodology where in the configuration tags can be set in optimal fashion as follows:

Enable: turns caching on/off Data_Storage_Paths: defines location to store result files Metadata_File: defines location for cache metadata file Replace_Algorithm: for discarding entries if cache full Buffer_Pool_Size: buffer for caching metadata file Max_Rows_Per_Cache_Entry: upper limit on rows in result Max_Cache_Entry_Size: upper limit on size (#rows*#bytes/row) Max_Cache_Entries: upper limit on #of cached queries

The Following is an in detail Architectural configuration changes that can be implemented for OBIEE Caching

Parameter: Enable Turns caching on/off

Best Practice: Set to YES if you want caching

Parameter: Data_Storage_Paths Defines the directory or directories to store cached result files Provide location and capacity DATA_STORAGE_PATHS = d:\OracleBIData\nQSCache 500 MB Least-recently-used cache is purged if full capacity

Best practice

o o o

use dedicated drive(s): performance and reliability use local disk (not a file share). (Not enforced) capacity should be significantly larger than value of Max_Cache_Entry_Size

Caveats to be kept in mind

o o
1.

Disk space must exist (or bad things will happen) Capacity of each location must not exceed 4 GB (2 GB before 7.7)

Parameter: Replace_Algorithm

Algorithm used to purge cache entries when the cache is full

Full is either: 1. 1. 2. Max_Cache_Entries have been created Less than Max_Cache_Entry_Size space is available

Removes cache entry that has not been accessed for longest time not necessarily the oldest created cache item Only choice is LRU (least-recently-used) 1. Parameter: Buffer_Pool_Size Defines the amount of memory for caching the cache metadata file. Parameter does not affect correctness/behavior of cache purely a performance setting

Best practice

1.

Dont change the default value. No/limited performance gains possible. Parameter: Max_Rows_Per_Cache_Entry Defines upper bound on number of rows in a cached result set Prevent large or runaway queries from consuming too much cache Query will run to completion, but if limit exceeded result will not be added to cache event is not logged Set value to 0 if no limit is desired Very large cache files are inefficient o stored in single file on disk o No indexes full sequential scan to access

Best practice

o o
1.

Define a non-zero value (less than 1,000,000 if possible) Max_Cache_Entry_Size is best place to define space limit

Parameter: Max_Cache_Entry_Size Defines limit on size (#of bytes) of a cache entry Used to prevent large cache entries from being created. Query will not be cached if exceeds this limit. No logging of exceeding limit. Size: #of rows times #of bytes/row #of bytes per row calculation: o Unicode expansion (2x or 4x multiplier for char and varchar columns) o Column alignment overheads o Null value representation overhead Cache is purged until Max_Cache_Entry_Size bytes are available

Best practice

o o

Set value to at most 10% of cache capacity (of smallest cache directory) More effective limit than Max_Rows_Per_Cache_Entry or Max_Cache_Entries

Caveats

Default value (1 MB) is fairly small. Many queries will hit this limit.