OLAP Cache

Optimization


AN SPE PICTURE
Why Cache?
In a SAP BW context, the OLAP cache buffers query results sets
retrieved from the database (disk) by storing them in resident
memory as highly compressed cluster data.
Why bother storing query results in memory? The answer is simple
this is a speed contest between disk accesses vs. memory access,
with memory being the much faster winner.
The desire to improve performance by avoiding disk access is the
fundamental rationale for database management system (DBMS)
caching and other file system caching methods. SAP BW is no
different and contains caching at the application layer to improve
OLAP reporting performance.

How Does Cache Work?
Users progressively fill the OLAP cache as they access queries. When
a user accesses a query result set for the first time, a database read
from disk takes place and the result set is then written to cache
memory.
A cache read action takes place when the same result set (or
subset) is subsequently accessed. Hence, the result set is retrieved
from memory, instead of being retrieved from disk.
An important feature of the OLAP cache is that read/write access
to the cache is available to all users on the application server. All
users get the benefits of faster data retrieval from the cache if
another process or user has previously written the data to it.

Accessing the OLAP Processor



When searching for requested data, a BI query accesses performance optimized
sources in the order shown. The important take-away is that the OLAP cache is read
first, in preference to all other performance optimization techniques, even the BI
Accelerator.
However, this isnt to say that these techniques dont have their place.
Cache Modes and Persistence
Modes
These are two terms that will be used frequently in the slides ahead.
Cache Mode:
The cache mode defines how the query results and navigational
states calculated by the OLAP processor should be saved in BW.
Persistence Mode:
The Persistence Mode parameter determines what happens to the
data in the cache if the memory reaches its maximum size. A
proportion of the data must either be removed or swapped.
As you must have guessed the concepts of Cache Mode and
Persistence mode go hand in hand.

Cache Modes
1. Cache is Inactive (0)
Yes Indeed this is the first Cache Mode available.

Where Can this be used in the SPE landscape:
Since we have BIA on our landscape, we can use on queries built on
all Infocubes that are small and also roll up to BIA.


Cache Modes
2. Main Memory Cache Without Swapping (1)
The cache data is stored in the main memory. When the cache
memory has been exhausted, excess data is removed according to
the LRU algorithm, i.e. deleted from the memory. When a query is
subsequently requested, the result is read from the InfoProvider once
again.
Where Can this be used in the SPE landscape:
Not Recommended because it has a severe size limitation.

Cache Modes
3. Main Memory Cache with Swapping (2)
The cache data is stored in the main memory. When the caching
memory is used up, the excess data is written to a background and
can be loaded back into the cache memory when making another
request.
The main memory cache is particularly fast but restricted by its size.
Swapping cached data does cancel out limitations on the main
memory but simultaneously affects performance.
Usage in SPE: Can be used in simple queries in terms of their
structure. For Complex queries we should definitely avoid this option.
Cache Modes
4. Persistent Cache per Application Server (3)
The cache data is stored persistently as a database table or as a file
in a directory attainable from the application server.
It is recommended that you choose a directory that is proximate to
the application server. Even If you happen to use a database table
to store Cached Data it would still be much faster than querying a
multidimensional structure of an Infocube.