I Would Now Like to Turn the Call Over to Mr. Oliver Mayer. Please Go Ahead

SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 1

SAP AMERICA

August 7, 2003 10: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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 2

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 3 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

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 4

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 5 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 6 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 7 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, SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 8 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 9 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 10 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 11 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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 12

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 13 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 14 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 15 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, SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 16 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 17 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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 18

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 19 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 20 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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 21

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 22

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 23 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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 24

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 25

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 26

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 27

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 28

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 29

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

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? SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 30

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? SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 31

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 32

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 33

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 34

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 35

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 36

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 37

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 38

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 39

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 40

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 41

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 42

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

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 43

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 SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 44

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. SAP AMERICA Host: Margaret Anderson August 7, 2003/10:00 a.m. CDT Page 45

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

participation. You may now disconnect.