SAP BW _OLAP Cache _Transcript of SAP Know How Conference

SAP AMERICAHost: Margaret Anderson

August 7, 2003/10:00 a.m. CDT

SAP AMERICA

August 7, 200310:00 a.m. CDT

Moderator Ladies and gentlemen, thank you for standing by and welcome to BW

Know How Network conference call. At this time all participant lines are

in a listen-only mode. Later there will be an opportunity for questions and

instructions will be given at that time. As a reminder, the conference is

being recorded.

I would now like to turn the call over to Mr. Oliver Mayer. Please go

ahead.

O. Mayer Thank you, Rita. Good morning, everybody, or as the case may be if

you’re dialing in from Europe, good evening. I’d like to welcome

everybody to today’s call, which will cover the all-important BW OLAP

cache. So, again, thanks everybody for taking their time out of their busy

day to attend today’s call. I think we’ll have lots of good information.


August 7, 2003/10:00 a.m. CDT

So without further ado, I will turn it over to Klaus Werner, our speaker for

today.

K. Werner Hello, everybody. Let’s get started right away. Let’s have a look at slide

number two, which is a content slide. What we will cover today is an

overview on the OLAP cache. The entire call will be on the global OLAP

cache, so first of all, an overview, what do we mean by OLAP cache and

what is it about. Next thing is the usage during query execution. Then we

have a comparison between the OLAP cache and aggregates. We’ll talk

about the global OLAP cache maintenance, monitoring, and we also give

some recommendations at the end.

So we start with the overview on the OLAP cache. The OLAP cache

buffers query (result set) data in order to improve performance of

subsequent query executions. So if somebody runs a query, a result set is

retrieved by the OLAP processor and is delivered, first of all, to the front

end and is also buffered in the so-called OLAP cache.

It comes in two flavors – the old cache that has always existed, the local

cache, which is session dependent, and in which the current query data is

stored in memory. That is available since BW 1.2B. Now we have a new


August 7, 2003/10:00 a.m. CDT

thing, which is new with BW 3.x, which is a so-called global OLAP

cache. This one is session and user independent, and as I said, is new with

BW 3.x.

Since this is quite new, we have ongoing enhancements, and the

information in this presentation refers to at least support package 13,

support package 7, respectively, for BW 3.0B or 3.1C. The focus of this

presentation is clearly the global OLAP cache, so whenever we refer to

OLAP cache, we mean the global OLAP cache, which is new with BW

3.0.

Go to the next slide – location of the global OLAP cache. The global

OLAP cache is stored, first of all, in shared memory. There is a relatively

new SAP memory segment, the shared memory, whose size is defined

with this parameter given here, and the number of objects that can be

stored in there at the same time is the max objects parameter. This is, of

course, application server dependent, because the memory itself is

application server dependent. We’re talking about the location, so where

is data stored in case of an overflow of this cache.


August 7, 2003/10:00 a.m. CDT

There are three possibilities that, first of all, something is removed from

the cache, which is the least recently used. The next possibility is to swap

into a file, so move data from the memory to a file or to a cluster table,

and then load it back in case it is needed again. The next possibility is file

or cluster table, as we’ve just mentioned for swapping, and it is also

possible to immediately use the file or the cluster table instead of the

memory.

This is possible, again, in two flavors – application server dependent or

independent. You can see this below in this screenshot, where it is

possible to define these settings for each single query. So in the query

properties you can specify, first of all, that the cache is inactive, so

caching is not used at all. That will be a situation similar to what you have

in the BW 2.0 system, for example. Then the setting number 1 main

memory cache without swapping, so it will be stored in main memory, but

not swapped to a file or across the table.

The next entry is with swapping, so store in memory and swap out to a file

or cluster table in case the memory is full. The third option is to

immediately write to a cluster table or a flat file for each individual

application server or do the same thing across application servers, so


August 7, 2003/10:00 a.m. CDT

independent of the application server. In this case we have a central file or

have a central cluster table, and write the query result set to this cluster

table or file.

The next section is about usage during query execution. On the

slide “query execution order of data availability check” we can see how

and in which order the data availability is checked during a query

execution. The first thing that would happen if you run a query or a

navigational step is that it will be checked if the data is still available in

the local cache. That means, for example, if you have a very large query

and then you restrict to a fixed value within that query, it would use the

local cache because that data is already available, and it has just to restrict

from that data to give a sub-selection of that data in your new navigation

step. That will be taken out of the local OLAP cache.

The next step will be to check if this is not available, is it available maybe

in the global OLAP cache. Has this query already been run by some other

user or in some other session with those selection criteria? Is the data

available in the global OLAP cache? If yes, data is retrieved from there.

If no, in case of an InfoCube, say, as an InfoProvider, it will be checked


August 7, 2003/10:00 a.m. CDT

do I have aggregates available for this query. If no, I have to go through

the InfoProvider itself on the database, in this example a basic InfoCube.

On the next slide we see the tradeoff between different ways of accessing

data, getting data from up to an offline portal cache, pre-calculation and so

on. The important part here is where does the OLAP cache come in,

somewhere between pre-calculation and aggregates. Pre-calculation

means that you calculate query results and save them somewhere in the

cluster table and retrieve those pre-calculated data, which is static.

The OLAP cache, one level underneath is more flexible so it’s more an

online feature, not an offline pre-calculated feature located mainly in

memory or, again, in cluster tables or files. Underneath the OLAP cache

there are the aggregates. So OLAP cache is somewhere between the

aggregates and pre-calculation in terms of performance, as well as in terms

of reusability. Offline will usually give me the best performance.

Accessing the InfoCube will usually give me the worst performance.

Somewhere in between we have located the OLAP cache with major

performance benefits compared to aggregates or InfoCubes, but on the

other hand, less reusability compared to aggregates or InfoCubes. That’s


August 7, 2003/10:00 a.m. CDT

the idea of this slide, so you have a tradeoff between performance and

reusability.

Let’s go to the next slide. We have a comparison of the global OLAP

cache and aggregates. Why is that? Because, first of all, probably

everybody attending this call knows aggregates. The global OLAP cache

and aggregates have some similarities and some differences. For the

understanding, it’s better to really compare these two and see how do they

work together or how are they somehow competing. Global OLAP cache

and aggregates both store redundant data in order to improve query

performance.

One stores the data on the database. One stores the data mainly in

memory, but how do they work together? It’s not like they are in some

kind of competition. They are defined on different levels of the

architecture and complement one another. That’s important to understand.

As an example, the global OLAP cache is filled and the data is retrieved,

for example, from an aggregate.

On the other hand, when you can use the global OLAP cache, it takes load

off the aggregate because not everybody has to use those aggregates,


August 7, 2003/10:00 a.m. CDT

because of subsequent execution of the query will go to the OLAP cache.

So it will take load off your database. But it’s important to understand

there is no competition, and it’s mentioned here explicitly again this is not

a guideline to decide which one is better because there is no better or

worse. It’s just that you have to have both for best performance, both in

aligned coexistence.

We go the slide – “properties of global OLAP cache and aggregates”. The

physical location is as we’ve seen for the OLAP cache in the main

memory file or cluster table. For the aggregates it’s on the database. So

in regards to server dependency we have partially application server

dependent OLAP cache, and totally application server independent

aggregates. The query dependency is fully query dependent for the OLAP

cache and independent of a query for the aggregates.

InfoProviders: the aggregates, as you probably know, can only be defined

on basic InfoCubes. For the global OLAP cache all InfoProviders can be

used. In terms of performance, we have a rather stable, very good

performance for the global OLAP cache, and for the aggregate it really

depends on the size of the aggregates of your data model, how your


August 7, 2003/10:00 a.m. CDT

queries match the aggregates and so on, so there is more to take into

consideration when talking about performance of the aggregates.

Availability of data in the OLAP cache, of course, depends on previous

query executions because the OLAP cache only stores data if a query has

been executed, and the frequency of invalidations. We’ll talk about

invalidations in detail later on. The availability of data in the aggregates is

always given. You always have the data, the currently reportable data,

available in the aggregates.

Granularity of data, this is a very interesting aspect. The global OLAP

cache is pretty close to the query definition. It really stores the

summarized data according to the query, according to the query

navigations. Also, currency conversions are already performed. For the

aggregate you probably know you can filter or summarize by

characteristics, navigational attributes, hierarchy levels. This is

independent of the query.

Sub-queries or selections, like restricted key figures, put different

selections through the OLAP processor. Both have the same behavior.

Within one query you can use more than one aggregate, as you probably


August 7, 2003/10:00 a.m. CDT

know, and you can also use more than one global cache entry. If you have

several selections in your query, several query cache entries can be used.

Go to the next slide – global OLAP cache maintenance. First of all, let’s

talk about the global OLAP cache relevant parameters. As we’ve already

seen, there is a memory segment in the SAP basis, and there is a basis

profile parameter that determines the size of this memory segment and the

maximum number of objects that can be stored in that particular area. On

the BW side we have customizing of the size of the local OLAP cache and

of the global OLAP cache.

We can determine whether the global OLAP cache is globally active or

inactive in the system. We can specify a persistence mode, which means

here you can determine whether a file or a cluster table should be used in

case of swapping or in case of writing queries directly to a persistent data

store. And you can specify a flat file name, which is then used in case of

using a flat file as persistent mode. All of those parameters can be set by a

transaction RSRCACHE or RSRT.

Now let’s talk about invalidation of global OLAP cache, which is the next

slide. Those entries in the OLAP cache are a snapshot of query data, when


August 7, 2003/10:00 a.m. CDT

the query was run basically. Over time things will change. For example,

an InfoProvider will get new data, and then the cache must be invalidated

or those entries must be invalidated that no longer refer to the current

state. So invalidations will happen based on time stamps and time stamps

are given for InfoProviders.

When has the last data been loaded? When was the last deletion of data as

examples. The report itself, the query could be changed, so there is a

query generation time that comes in. There may be pre-calculated value

sets, so-called buckets. They may also change or changes of independent

InfoProviders may occur. Then there is the change run. Changes in

navigational attributes, changes in hierarchies will certainly influence

query results.

So also in case of a change run, you will have different query results and

invalidations take place. The same is true for currencies because currency

conversions are already pre-calculated in the OLAP cache. So if currency

conversion rates, for example, change, then the entries based on the old

currency conversion rates are no longer valid and must be invalidated. So

query results are, in general, invalidated if one component of this query

has changed.


August 7, 2003/10:00 a.m. CDT

The next item here is about a frequently asked question. How about

change of key dates? Just to clarify this: The key date is basically stored in

a variable. There will be a new cache entry if this key date changes, but

the old entry is not invalidated, because somebody else might still go back

to the old key date in the query and report on the old data so this is not a

case of invalidation. This is a case of a different variable value. That’s

important to understand. There’s also the possibility of manually

invalidating the cache, which basically means you delete all the cache

entries.

The next slide talks about switching off the global OLAP cache. The

global OLAP cache can be switched off, first of all, globally for the entire

system. It can also be switched off for an InfoProvider. If you do this, it

just means that this is the default for new queries. So whenever you

define a new query on that particular InfoProvider, for this query the cache

will not be used. It will not affect the old queries on this InfoProvider.

For old queries you would have to change the setting manually at the

query definition or the query properties. For a query, you can individually

set the OLAP cache on or off. For one query execution for testing, you


August 7, 2003/10:00 a.m. CDT

can do the same when you run transaction RSRT. RSRT is a transaction

where you can run queries within the normal SAP GUI and then debug.

There you can switch off the usage of the cache for testing purposes.

Reasons for switching off is, first of all, performance testing, but also

performance tuning. If you have a very fast query, you may not want to

have the cache overhead, because there is certainly some overhead for

checking if an entry is available in the cache or not, and if the query is fast

anyway, why would you want to use the cache. You may want to avoid

unnecessary swapping in the cache as well.

If you have a lot of queries that are, for example, fast and that

unnecessarily caused swapping in the cache, you may want to switch it off

for those. So queries to be switched off are first of all queries that have

large result sets, for example just used for batch printing. Why would you

ruin your OLAP cache and fill your memory unnecessarily with such a

query, so that would certainly be a candidate for switching off.

Queries with frequent invalidations: If you have an InfoProvider to which

you load data every five minutes, you would probably not want to have the

cache active for those queries, and an InfoProvider with a lot of ad hoc


August 7, 2003/10:00 a.m. CDT

queries maybe. If you create new queries, just for one time usage, you

wouldn’t want to have them cached either.

On this next slide we’ll talk about pre-calculation. Whenever a query is

executed, the global OLAP cache is filled. So whenever you use the

OLAP processor basically, independent of whether you use it through the

Bex Analyzer, a Web application, third-party front ends, the reporting

agent, or for example, RSRTRACE. Whenever you execute a query, this

OLAP cache is filled. You can make use of that fact by pre-calculating

query results and having them stored automatically in the global OLAP

cache.

This is, for example, possible with the reporting agent. It’s not what that

reporting agent has been designed for, but you can kind of abuse the

reporting agent to pre-calculate also the global OLAP cache. So you don’t

have to use any specific option for this cache filling. You can, for

example, use the pre-calculation of Web templates to fill this global OLAP

cache.

You can run those queries after, for example, data loading or change runs

are finished. You can kick off the reporting agent and pre-calculate your


August 7, 2003/10:00 a.m. CDT

queries. This could be used for very important and performance critical

queries. Again, it’s not a specific setting for the global OLAP cache. It’s

just a regular reporting agent that is used for also filling the OLAP cache.

That happens automatically when you specify settings in their reporting

agent, and you run those. So as you maybe know, you can specify that

you pre-calculate users specifically. You can choose roles or individual

users for pre-calculating their query results as they would see them,

depending on their authorization. Or you can also use the control query to

pre-calculate your query results, your navigation steps basically.

Running the queries with user authorization or specific selections with the

control query has advantages and disadvantages. A disadvantage may be

that you have more cache entries, more different ones. But on the other

hand, your cache entries are more specific. You have improved

performance because it’s more specific smaller result sets.

On the other hand, you may have more redundancy, especially if you have

similar authorizations for different users. That may mean also more

maintenance effort for you. If you run a query with kind of all

authorizations or general selections, then there are fewer cache entries,


August 7, 2003/10:00 a.m. CDT

less specific, worse performance, but on the other hand, also easier

maintenance.

We go to slide number 18 now, the content slide. “Monitoring”, and go to

19 immediately. First of all, let’s talk about the structure. That’s

important to understand in order to understand the monitor itself. As

already mentioned before, the global OLAP cache is query dependent. So

the first level parent of all entries is the query. Within this query you use

variables. You use presentation hierarchies. That’s the next level.

You may use different presentation hierarchies, for example. That would

result in different entries on this next level. Then we come to the

selections, currencies. Currency conversion is already pre-calculated in

the OLAP cache. The next level is the data itself. That’s the structure of

the global OLAP cache. The last two – global data selections, currency

and data – are summarized in one entry in the monitor of the global OLAP

cache.

On the next slide we see screenshots of what the monitor transaction looks

like now. I mean support package 13 or higher. You may still remember

an older screenshot. It looked different before. So we have those buttons


August 7, 2003/10:00 a.m. CDT

basically on the left upper side, and if you press those buttons you see

what happens. If you press the button cache parameters, you will see the

local cache size, the global cache size, whether the cache is active and also

the persistence mode.

If you press the main memory button, then you will see, again, the

maximum cache size, which is the sizing of specified as a parameter, the

current cache size, the current swap size, and what is used of the current

cache of the maximum the cache could grow to. In this example we

would have 250 megabytes customized, but only 414 kilobytes used, so

that’s close to zero percent and that’s why it gives you zero percent here.

The overall number of cache entries, 634, is also given here. We have 634

cache entries.

The next section is interesting. The buffer poll time will just tell you how

old this information is that is currently displayed. It’s by default updated

once in five minutes. The next number, the 32% refer to the maximum

usage of the cache, taking into account the size, as well as the number of

objects. So here at the moment the limiting factor is the number of

objects. We see that we have 634 current cache entries, out of 2,000 we

have specified in the parameter.


August 7, 2003/10:00 a.m. CDT

You cannot see the 2,000 here in this slide, but that’s what you can see in

the next slide. So 32% of the cache is used. Not the cache size in this

case, but the maximum number of objects. The next “buffer setting

cache” gives you the information that at the moment in this system 100%

of this basis memory area is currently used by the OLAP cache, so nobody

else is at the moment using this segment, this SAP shared memory

segment. That’s this information. There may be other components also

using it and then you would see a low number here.

The next thing you see, if you press on the button, for example,

application server, then you see the current cache size there. You see the

current swap size, which doesn’t make any sense because it’s already

swapping this is talking about. So it’s basically the current swap size itself

that is displayed here in the first row, and in the second row it would say

swapping of the swapping, but there is no swapping of the swapping.

So in the next support package you will no longer see this line. It doesn’t

make any sense. You will see the current cache entries, which means

basically the currently swapped entries on an application server level. The

same information you get for cross-application servers if you press the


August 7, 2003/10:00 a.m. CDT

second to last button. Whenever you press buffer objects, underneath one

of those buttons you will get a view of the current buffered objects.

In this example we pressed not this last button, it’s just for display in this

slide. We pressed the button on the main memory because the others are

empty anyway. There you see the query name first. You remember the

structure of the global OLAP cache. The first level is the query. The next

level is hierarchies and variables, and then summarized the selections,

currency conversions, and the data. If you double-click on this hierarchies

and variables, you can also see which hierarchies and variables are taken

into account here.

On the next slide, “cache monitor basis” you see a basis view, a basis

transaction that some of you may know, the ST02, which is a view on the

memory that SAP allocates. This is not BW specific, but basically Web

Application Server specific.

Here we have the last line, export/import shared memory, and that’s where

you get the basis view on this memory segment that is used for the global

OLAP cache. You see a hit ratio here. You get a size, and the last figure

you see here in this screenshot is the number of entries that you can have


August 7, 2003/10:00 a.m. CDT

in this cache, so this is the 2,000 I have referred to in this slide before.

That’s the 2,000, out of which currently 634 entries were used and that’s

why it gives you the usage of 32% in this previous slide.

On the next slide, the query properties, you see a screenshot of transaction

RSRT. You specify a query, and press the button “technical information”,

and within the technical information you have a lot of data about the query

– performance relevant data and also data like generation time, internal

technical names, and things like that. One section of that is the cache-

relevant data. It specifies whether the query can use the cache.

It usually says yes; it rarely says no. If it says no, it tells you why it

cannot use that cache. You see the query generation time and you see the

last data change of the underlying InfoProvider. If you press this

properties button, then you will see, first of all, the read mode. You all

probably know the read mode, and on the same level where you can

specify query specifically read mode, you can now specify also the cache

mode. That’s exactly that little screenshot we had in our of the first slides

where you can specify for one individual query whether the cache is active

or not, and whether you use main memory with, without swapping, or

cluster table or flat file application server dependent or independent.


August 7, 2003/10:00 a.m. CDT

On the next slide we have given some exceptions, in which case

the OLAP cache will or can at the moment not be used. It’s currently not

used for queries containing variables with replacement path, sometimes

also referred to as pre-query. It’s at the moment not yet used for most

recent reporting, but that has been implemented with support package 15

so this is the latest information.

Another restriction is that large objects are not buffered in memory, so if

you chose memory buffering and you have a very large query result set

that exceeds about something between a fourth and a fifth of the export/

import buffer, then the result will not be written through the global OLAP

cache.

On this next slide or second slide, we give some recommendations for

setting the parameters. We will investigate that more and we will give you

more detailed information that will be published in the SAP Service

Marketplace, but this is for now what we usually recommend. 80%

recommendation: Say for 80% of the systems it should be fine, that you

use 200 megabytes for the global OLAP cache, and for the export/import

buffer set memory 100 megabytes.


August 7, 2003/10:00 a.m. CDT

This last value is not the default setting. That’s a thing you’d have to

change because the default is only four megabyte and you could run out of

these four megabyte easily. So you should check in your system the usage

of this segment in transaction ST02 and increase the size if it is too small.

Different aspects need to be considered when setting up those parameters,

and we will elaborate on this a little more in the next slide. Bear in mind

that you can decide for each query to set the cache to active or inactive,

and to use the memory or use flat file or the cluster table.

So we’ll go to this next slide. There is a matrix giving you some aspects

you may take into consideration when deciding for a single query or your

entire system which kind of caching option to use. What is important is

certainly the frequency of changes of data. Like if you, for example, load

every five minutes to an InfoProvider, the caching will not be that efficient

because invalidations will take place frequently. Also, certainly the

amount of active users and of query navigations that are performed in your

system, the amount of different queries.

Remember that the OLAP cache is dependent on queries, so it’s certainly

interesting whether you have many queries or you only have a few queries

to determine how efficient the cache can be. Also, the number of ad hoc


August 7, 2003/10:00 a.m. CDT

queries is important. If you create a new query, this new query will

certainly not be cached at first execution because you have just created it.

If you usually do ad hoc querying, the cache is also not that good.

The size of the result set may influence your decision on whether you use

the memory or not for caching those query result sets. If you have very

large result sets, it may make sense to immediately write them to a file or a

cluster table. Also, the load on InfoProviders on database tables is

interesting. If you have a high load on the database on the InfoProvider

tables, it certainly makes sense to use one of those caching options.

Low query performance is, of course, another indicator. That’s what it’s

all about: increasing the performance of queries. So if you have a low

query performance you would certainly want to use this global OLAP

cache. User groups assigned to application servers, that’s interesting to

decide whether you want to use a cache across application servers or

application server specific. If you assign your user groups to different

application servers, user groups doing similar kind of reporting, it

certainly makes sense to have the cache application server dependent. The

speed of your I/O is certainly also interesting. Cache will, of course, have


August 7, 2003/10:00 a.m. CDT

less I/O impact than retrieving the data from an InfoCube or from

aggregate.

We’ll go to the next slide. There we have some links. More information

can be found in the online documentation. There will be a documentation

enhancement soon available in SAP Service Marketplace, especially about

the OLAP cache. There will be some conferences, BI conferences in

Berlin, and Tech Ed in Las Vegas and in Basel, and also the ASUG BITI

forum in Dallas.

That’s the end of the presentation. You now have time to ask questions.

Moderator Our first question is from Radu Drasta with Colgate-Palmolive. Please go

ahead.

R. Drasta Is there a method to keep a certain report in the cache or how would you

ensure to keep a given report, and perhaps some of it’s navigation steps

over a longer period of time? I’m thinking for the use of certain executive

reports that do not refresh that often, perhaps year-to-date summaries,

things like that.


August 7, 2003/10:00 a.m. CDT

K. Werner If I get your question right, it’s about keeping query results for a long

time. You can keep them kind of forever if you use the swapping options

or if you use the cluster table and the flat file. They will never be removed

unless they’re invalidated, and they will certainly be invalidated if you

load new data. So if you have a management report, a very important one,

it will usually also have some current data in there and you will load new

data maybe daily or say at least monthly. Then the cache entry will

always be invalidated. But if it’s not invalidated, it will stay in the cluster

table or flat file if you use swapping or you immediately write it there.

R. Drasta Granted, let’s say that they only change monthly. Let’s say that the cache

is filling up and this report, since it hasn’t been refreshed, so perhaps it

isn’t run that often as the other ones, may be getting at the end of queue

and the algorithm would throw it out of the cache. In that situation should

we set up the reporting agent that runs this all the time, or would there be

some other way of making sure say we run this report, don’t ever take it

out of the cache until the data changes behind it? Is there such a way of

doing it?

K. Werner No, it’s not necessary. This swapping or this removing of the cache out of

the cache will only happen if you choose this first option, main memory


August 7, 2003/10:00 a.m. CDT

without swapping. With all other options for this particular query, all

other options will guarantee that it will never be removed from the OLAP

cache. Never.

R. Drasta I see. So unless the results change, it will never be swapped The answer

is there should be a select few queries like that in the set with that

parameter going to the OLAP cache?

K. Werner Yes. You can use several queries. You can use all queries like that. It

will not be removed. Only the cache size will, of course, maybe increase

unnecessarily. But for the important queries, you should make sure that

you use one of those options, two to four, and not the first one.

Moderator Ravi Lakkaraju with Joann Stores.

R. Lakkaraju Does the OLAP cache get invalidated with a cycling of the system, too?

K. Werner With a …?

R. Lakkaraju Say you cycled the system, shut it down, and bring it up for daily

maintenance.


August 7, 2003/10:00 a.m. CDT

K. Werner If you shut it down and bring it back up again, the memory cache will be

certainly removed and the swapping is removed, but the file on the cluster

table will remain available.

R. Lakkaraju So is there a way for it to read through the file and bring it back into

cache? Is there a way to do that?

K. Werner No. There is no such option at the moment.

Moderator Andreas Peters, UBS.

A. Peters I have a question concerning the filling using the reporting agent. Is there

a difference if I fill this cache using web templates or if we did it the last

test using the print agent, which does not print any lines?

K. Werner It’s the same whatever you use. Only I think for the Web templates you’ll

have some more options like doing it by authorizations or control query.

I’m not sure about this, but there is no difference whatsoever. It only

depends on what kind of query you use, what kind of navigation step you


August 7, 2003/10:00 a.m. CDT

perform there, and the only important thing is that it is performed no

matter what you do with the data afterwards.

Whether you use it in batch printing or not use it in batch printing, or put it

into a Web template, put the data somewhere or put the HTML

somewhere. Independent of that, it’s only important that the query gets

executed in the way you would like to have it executed.

A. Peters The next question is if I create a drilldown, which has a lot of lines, let’s

say 64,000 lines, which is indicated in the RSRT, the query result is

incomplete due to the large number of lines. If I now create a reporting

agent job, which creates such a large number of lines, does that mean that

the cache is not completely filled will all the lines or is it there all in there

even if it’s not all printed?

K. Werner First of all, you should not have queries with 64,000 lines. Second, the

restriction comes from Microsoft Excel, not from SAP. If you don’t use

Excel, for example, batch printing, then there is no such restriction.

A. Peters The last question would be, if I have one query which runs and which

makes drilldown into characteristic one, and have a second drilldown into


August 7, 2003/10:00 a.m. CDT

characteristic two, now the second user comes. He first drills down into

characteristic one and immediately into characteristic two. Is the cache

used or not or do I have to create a set with both characteristics drilled

down?

K. Werner Let me introduce and hand over to Stefan Miller, who is the developer in

that area, who has just joined. Let me hand over to him for the answer.

S. Miller The cache would be used. There is only one problem. If they do it at the

same time, really at the same time, then it could be that the cache data has

to be calculated by each user. But if they do it with a time difference, it

will be used. Is that okay?

A. Peters Yes.

Moderator Steve Rudolph, Monsanto.

S. Rudolph Thank you for the conference call. My question is whether there is any

correlation between OLAP cache and BW statistics. Does it require or

make use of BW statistics to make decisions on use of the OLAP cache?


August 7, 2003/10:00 a.m. CDT

K. Werner At the moment, unfortunately, there is no direct relation indicating that the

OLAP cache has been used in the BW statistics. That’s still something

that we have to develop, that we have to do. There is an indication for it if

no data records are selected from the database and transferred to the

application server. You may know those fields QDBSEL and

QDBTRANS in the table RSDDSTAT or the corresponding InfoObjects

in the BW statistics indicating how many records have been read from the

database and how many records have been transferred to the application

server.

This will always be zero if the OLAP cache was used, but it may be zero if

the OLAP cache was not used, just because there was no data available,

but that should be an exceptional case. So usually if you look for those

entries with no records selected from the database, you will have those

entries that refer to usage of an OLAP cache.

S. Rudolph Conversely, it sounds like from what you said, there is no direct

requirement to have statistics active in order to use OLAP cache. Is that

correct?


August 7, 2003/10:00 a.m. CDT

K. Werner Yes. That’s certainly correct. There is no dependency of using BW

statistics on the OLAP cache. Maybe I misunderstood your question.

They are two totally different things. So statistics are always collected

independent of what kind of settings you have with your query, but the

thing at the moment is that you cannot see directly into statistics whether

the OLAP cache was used or not. Only by this guessing from QDBSEL

and QDBTRANS is equal to zero.

S. Rudolph I understand. Thank you.

Moderator Eloy Meira with Rich’s Foods.

E. Meira I have two questions. Is there a possibility to swap the cache into the

cluster table? I also have a second question. Is the cluster table faster for

caching or swapping that cache than the file?

K. Werner Your first question maybe refers to the existing cache and memory of

somehow getting it into the cluster table. Then the answer is no. But for

swapping you can choose the persistence mode cluster table or you can

choose in the query properties to immediately write to that cluster table all

the data that that query delivers. Maybe you can put your question in

another way so I understand what your question really is, the first one.


August 7, 2003/10:00 a.m. CDT

E. Meira It’s just to ensure that if we decided, for example, to use buffing or

swapping technique for attaching the cache, the OLAP memory, that the

cluster table is going to be an efficient way of doing it. I will assume that

also that’s related to my second question, that the cluster will be faster on

the file, but that was my second question.

K. Werner I understand. So you can use the cluster table for swapping. That’s for

sure. You choose the persistent cluster table and you specify for your

queries the option main memory with swapping. That’s the first thing.

Performance really depends on many factors, like how fast is the

communication between your application servers or application servers

and server you have the file on. May be cluster table may be faster or it

may be slower. I think both are possible. Unfortunately, we have not

done any detailed measurements on that, but we will do so probably by the

end of the year, but I cannot give you a reliable answer right now. But it

will be published some time this year in the SAP Service Marketplace.

Moderator Troy Mosser, Molex.


August 7, 2003/10:00 a.m. CDT

T. Mosser We are using this … the data-mining tool for populating an object from a

query. Will that use the cache …?

K. Werner Could you repeat what you are using? I didn’t get that part.

T. Mosser Yes. The transaction code is RSBNWB. It’s data mining. Basically, the

data-mining tool is calling the transaction for CRM analytics.

K. Werner This is a very good question. Unfortunately, I do not have the answer

because I’m not a CRM expert. So I don’t know what kind of interface

they’re using. If they use the APO interface, the answer is no. If they use

the normal OLAP processor, the answer is yes.

T. Mosser I’m not sure because sometimes you have both the options. Sometimes

you can do it … transaction or sometimes it uses the OLAP, because you

can use encryption aggregation and calculator … and so on. In that case it

has to go through the OLAP processor.

K. Werner Yes. In that case it would be cached. In the case where it directly access

the database, it will certainly not be cached.


August 7, 2003/10:00 a.m. CDT

T. Mosser If a query has a very high OLAP time like in … caching will have,

because it will install data after calculation. Is that correct?

K. Werner That’s correct.

Moderator There is a question from Robby Lakkaraju with JoAnn Stores. Go ahead.

R. Lakkaraju When we run a query from …, you go into say ST02 or ST04 and start

monitoring that query, you’ll see it a lot of different SQLs being

performed at the database level. Now each one could be, let’s say, if the

main query was on a multi-cube, then each one of the sub-queries, so to

speak, would be at the InfoProvider level. So does the cache store the

results at the main query level or does it store it at the sub-query level?

K. Werner It has different levels so, first of all, it is totally dependent on the query

and the query, again, is totally dependent on the InfoProvider because the

query is always defined exactly on one InfoProvider. It may be a

MultiProvider, but it certainly is related to exactly one InfoProvider. The

cache entry is thus also directly related to an InfoProvider via the query

because the cache entry is dependent on the query.


August 7, 2003/10:00 a.m. CDT

Within the query, there are different selections maybe, like restricted key

figures for different selections to the OLAP processors to the database.

These different selections are stored as separate entries on the lower level.

If you remember that slide, we have the queries. Then we have

hierarchies and variables, and then we have the selections, currency

conversions, and so on. So always exactly related to the InfoProvider the

query is defined on, but different selections on a lower level of that

InfoProvider.

R. Lakkaraju Let’s say my query contains a non-cumulative key figure as one of the key

figures. I’m reporting for a certain week, but when I actually run that

query and I look at the SQL statements that are being generated with, let’s

say, ST05 traces or something, I will see that it’s actually going back and

calculating the non-cumulative based on its corresponding cumulative

delta values.

So even though my query contains only the non-cumulative key figure in

the results set, the sub-queries behind the scenes has actually gone ahead

and calculated the non-cumulative values based on its corresponding

deltas from the cumulatives, and then posted in the result sets. Does the


August 7, 2003/10:00 a.m. CDT

cache contain the non-cumulative calculated value or does the cache

contain the delta sets from the cumulatives?

K. Werner It contains calculated non-cumulative value.

Moderator Richard Oxley, Kenakore.

R. Oxley My question concerns the shared memory segment, and ST02 shows what

is using in that shared segment. What other functionality uses that shared

memory segment, other than the OLAP cache?

K. Werner At the moment in the BW system, I think nothing. No other component is

currently using it, but there will probably be in the future, so that’s why

we have prepared already this number, how many percent of the segment

is used by the OLAP cache. That will usually be 100% now, but in the

future it will be lower than 100%. So there will be other components

coming in.

Moderator Walter Froehlicher with IBM.

W. Froehlicher I have a question regarding free characteristics. … we have about a

couple free characteristics in there and we want to give the user, the


August 7, 2003/10:00 a.m. CDT

community, give the community the rate that it was obviously cache

independent major characteristic it drills into. Could we achieve it by

running the reporting agent by having or expanding all the characteristics

it runs, and would then the cache be used independent of which

combination of those characteristics they would select?

K. Werner Yes. The developer looks a little suspicious here, so I may wait. Just a

moment and let me just clarify it. The answer is yes.

W. Froehlicher I have a second question; it’s the second to last one actually. It’s

regarding this play … noticed it today. We actually run a pre-calculate

query, which could drilldown in a characteristic, which has to be …

attached. Now the user reperforms or re-executes the same query, the

same read on the cache actually is considered, but now if the user then

inactivates the display hierarchy, the community … database and it’s from

the cache.

K. Werner That’s correct. You remember this second level? The first level of the

global cache structure was a query. The next level was hierarchy and was

referred to presentation hierarchies or display hierarchies and variables. If


August 7, 2003/10:00 a.m. CDT

this key is wrong, the presentation hierarchy is no longer available; the

cache entry will not be used. That’s correct.

W. Froehlicher … data would be somewhere in the cache memory of it?

K. Werner No. It’s summarized up to the presentation hierarchy level basically, and

that’s why this is a key of this structure.

Moderator Lonnie Luehmann with Nike.

L. Luehmann I have two brief questions. The first one was a clarification on the

information on slide 25 about the recommendations. You mentioned 80%.

How should I apply that to determining the size of the global cache that

we would use here. We have a CIDB and three application servers in our

production environment. How do I apply that to arrive at the efficient

definition for the global cache size?

K. Werner I would start out with this values given here for every application server

basically, and then also maybe take into consideration what is told on the

next slide, where they have a special situation with maybe a lot of ad hoc

querying or whatever. Then watch the size of the cache. If the size is


August 7, 2003/10:00 a.m. CDT

much smaller than what you really need, then you can decrease those

parameters. If it is bigger, if there is a lot of swapping going on, you may

want to increase it. Start with the current recommendations given on that

slide and watch those numbers, like percentage of usage and ST02 and all

this kind of stuff.

L. Luehmann One other quick question. Is it possible to cache data from a remote cube?

K. Werner Yes, it is. There is a validity period you can specify here for the queries.

You can specify this in transaction SPRO, where you can also set

InfoProvider defaults like the read mode, you may know, and others, also

the cache mode. Additionally, for remote cube there will be a validity

period, I think in seconds, where you can specify how long they should be

valid because, of course, you can never know when the underlying data

structure changes in the remote system. So it’s just a value you have to

specify yourself, and you have to be aware of the fact that the data may be

a little outdated say, for example, by five minutes if you specify 300

seconds.

Moderator Next, Radu Drasta, Colgate-Palmolive.


August 7, 2003/10:00 a.m. CDT

R. Drasta I have another question regarding the parameters of the basis level. There

is a buffer size, I understand, that’s in your recommendation. That’s the

100-megabyte?

K. Werner Correct.

R. Drasta The number of objects, is that number of queries or number of all those

different objects?

K. Werner It’s a number of all entries. Not the number of queries, but the number of

all entries of all selections, of everything what you can see as the lowest

level item in the query monitor. So you may also want to increase this

size; that’s correct. That’s one thing I forgot to mention, so you may also

want to increase from the 2,000 default to some higher level because that

may be the limiting factor.

R. Drasta There are all by application servers as I understand?

K. Werner Yes.


August 7, 2003/10:00 a.m. CDT

R. Drasta The last one is the estimated size of the largest object. Again, that could

be like a result set, could be like a data package. Right?

K. Werner Yes. But at the moment this parameter is not really used for our purposes,

so you can ignore this parameter at the moment in our discussion here

about the global OLAP cache.

R. Drasta I’m sorry. I don’t understand.

K. Werner This parameter’s not used at the moment.

R. Drasta The large object size?

K. Werner Yes. Has no meaning for our OLAP cache here.

Moderator Walter Froehlicher, IBM.

W. Froehlicher Let’s assume we build a query with a structure containing various

selections, for instance, with restricted key figures and we perform

drilldowns after a filter, so filter and drilldown. What we observe now is

that every time everything is selected for the entire query. Is that correct

or is that not the case? If that is the case, then we can just do one filter and


August 7, 2003/10:00 a.m. CDT

drilldown, and store the data for all structure elements in the cache with

that.

K. Werner We have some problems understanding this question. Is what you’re

saying is if you filter?

W. Froehlicher Filter and drilldown.

K. Werner But then you say the filter is kind of ignored in the cache.

W. Froehlicher Yes. I would say from what we have observed from the measurements on

how long it takes to select it, that it doesn’t matter on which row I filter

and drilldown. It always takes the same amount of time to execute the

query, and so also to fill the cache. So I assume that in the background we

do not filter on a specific selection, but we do a drilldown for all the

members of the structure, and just display at the very end the one element

of the structure, which is filtered on which we have put … the filter.

K. Werner But what you say is about filling the cache. Filling the

cache is not really a factor in the overall query performance if you don’t

use the cache, but you read from some underlying data structure. So


August 7, 2003/10:00 a.m. CDT

filling of the cache you wouldn’t see much difference there, depending on

the results that are written to the OLAP cache. Otherwise, we would

really be in trouble and the OLAP cache would ruin our query

performance.

So filling the cache is not a performance issue here and it will only buffer

the data that is really retrieved. So if you have a filter in that query, it will

not retrieve any additional data and write it to the OLAP cache. That will

be very unusual. Did I misunderstand your question?

W. Froehlicher … happening for let’s just say if you do a navigation on a query or right

now … say filter and drilldown to. It seems that in a structure it does in

the background the selection, the retrieving of the data out of whatever for

all the elements of the structure. It’s that drilldown and not just for a

specific selection, as you would assume since you were doing a filter and

drilldown. It should be much faster to do a filter and drilldown on a

specific row of the structure than it is to do it on all elements.

K. Werner I absolutely agree, but this is not a problem of the OLAP cache. This

would be a problem of the query execution. And if that is the case, if that

is really true and if you can certainly have a look at the database statement


August 7, 2003/10:00 a.m. CDT

that is handed down to the database, if the OLAP cache is not used, then

please open an OSS message and we have a severe problem there. That

would be important to know, but that’s not a problem whatsoever of the

OLAP cache. That would be a problem of a query execution and query

performance.

W. Froehlicher In relation to the OLAP cache, if we want to … opportunity to do it, we

just have to do one of those and not for every specific filter drilled onto it.

So that’s why I asked the question there.

K. Werner I should hope no. I should hope you’re wrong about that. If you’re right,

please do open an OSS message.

Moderator We have no further questions at this time.

O. Mayer Since we have no further questions, I’d like to thank everybody for dialing

in today and taking the time out to attend the call. Of course, many thanks

go to Klaus for putting this presentation together and for Stefan for

dropping in and helping with the question and answer session. So, again,

I’d like to thank everybody for attending today’s call. Then we’ll wrap

this call up until two weeks from now.


August 7, 2003/10:00 a.m. CDT

Moderator This does conclude your teleconference for today. Thank you for your

participation. You may now disconnect.

SAP BW _OLAP Cache _Transcript of SAP Know How Conference

Documents

Transcript of SAP BW _OLAP Cache _Transcript of SAP Know How Conference