Query OLAP Cache Optimization in SAP BW

Query OLAP Cache Optimization in SAP BW Applies to: SAP NetWeaver 2004s BW 7.0 Summary This article explains how to improve performance of long running queries using OLAP Cache. Author: Sheetal Maharshi Company: Infosys Limited Created on: 13 th Aug 2011 Author Bio Sheetal Maharshi is working as an SAP BW consultant and has experience in many implementations of an Enterprise Date Warehouse, BW upgrade, BW Support, BWA and Reporting.. 2010 SAP AG 1

Table of Contents INTRODUCTION... 3 Pre- Requisite... 3 Query Design Tips... 4 Filling OLAP Cache... 5 BEx Broadcasting Approaches... 9 Query Monitor... 11 Read Mode:... 12 Cache Mode:... 13 Optimization Mode:... 14 Cache Maintenance... 16 Related Content... 19 Disclaimer and Liability Notice... 20 2010 SAP AG 2

INTRODUCTION The goal of performance tuning is to minimize the response time of BW queries and to make the best use of the server's resources.basic rules for Performance Optimization are : Eliminate all unnecessary processes. Reduce data Volume to be processed. Deploy parallelism at all available levels. The best way to avoid performance problems is to ensure that performance considerations are part of the ongoing development activities. Most significant performance improvements are realized through careful design at the beginning of the development cycle. Even after careful designing and development, we can still face issues in query performances that can take longer time in execution. There can be many techniques to improve these long running queries.some of these techniques are: By filling OLAP Cache By Creating Aggregates Using BWA Pre Calculated Web Templates This article explains how we can improve these long running queries using one of these techniques - OLAP cache. Pre- Requisite BW in SAP NetWeaver 7.0 2010 SAP AG 3

Query Design Tips Query Design can have a significant impact on the performance. Sometimes long running queries are the result of poor designing and not because of the amount of data it s fetching. Below are some handy query design tips: In most cases, Characteristics should be placed in the rows and Key Figures in columns. As characteristics may have potentially many values, it must not be added in the columns without a filter or a variable. Alternately, it can be integrated into Query free characteristics enabling it to be used in navigation. When a query is run on the Multiprovider, all the underlying Infoproviders are read. This can be restricted by using Characteristic 0INFOPROVIDER to only read the required Infoproviders. Keep the number of Characteristics in the query as small as possible to help reduce the number of cells sent to the front end. If Possible, define calculated and restricted Key Figures at the Infoprovider level instead of locally in the query. For better performance, try to avoid EXCLUSION option if possible, as characteristics in the INCLUSION can use database Indexes, Characteristics in the EXCLUSION cannot use Indexes. Therefore, it takes more time to read data for EXCLUSION as compared to INCLUSION. Avoid using cell definitions as far as possible as cell calculation by means of cell editor generates separate queries at query runtime. Hence, it should be used cautiously per the business requirement. Do not use Total Rows if not needed. Graphics like Charts, Graphs etc. can impact query performance. In case a query is being designed on Data Store objects and Infosets, use of variables and dropdown boxes makes data access more specific, as these are not aggregated like Infocubes. Check codes for variables processed by customer exits. Check if aggregates are defined correctly and are suitable. 2010 SAP AG 4

Filling OLAP Cache Filling OLAP cache allows pre-calculation of the queries and the cache is filled with the data. When the users runs WADs (Web Application Templates), queries, reports or workbooks which have OLAP cache setting enabled, the execution time is considerably reduced as the pre-calculated data is already stored in cache and there is no need to hit the database. This option is available in BEx Broadcaster using option Fill OLAP Cache. As mentioned above, filling of OLAP Cache reduces query execution time considerably as it reduces the Database read time. The global OLAP cache buffers query result data, in order to provide them for further accesses, thereby improving the performance. Below are the steps for creating BEx Broadcaster Settings for Filling OLAP Cache: 1. Go to BEx Query Designer and open the query for which the OLAP Cache needs to be filled.- Fig1 Fig 1 Or we can open from SAP Portal as well (Fig-2): Fig-2 2010 SAP AG 5

2. Create new setting for the query (Fig-3). Fig-3 3. Give the name of the new setting and select the Fill OLAP Cache from the dropdown of Distribution type (Fig-4): Fig-4 2010 SAP AG 6

4. Give the variable values and click on the save button : (Fig-5 & Fig-6) Fig-5 Fig-6 2010 SAP AG 7

5. Enter the description for the variable values and save the setting.(fig-7) Fig-7 6. After saving, OLAP cache setting can be directly execute or schedule.(fig-8) Fig-8 2010 SAP AG 8

BEx Broadcasting Approaches 1. Schedule broadcast on date/data change Scheduling can be done either with an event trigger or on daily, weekly or monthly basis. The option Direct Scheduling can be used to schedule this job daily, monthly or weekly basis. Firstly in the BEx Broadcaster schedule the broadcaster to run on a data change event. (Fig-9) Fig-9 Add a data change event to the end of each datamart load process chain. This event triggers the broadcasts which pre-fill the OLAP cache. In the data change event you specify which InfoProvider has had it s data changed (so that the OLAP cache has been erased for it) and broadcasts scheduled on the event for the InfoProvider are triggered. Fig-10 2010 SAP AG 9

2. Web Templates Web templates can contain multiple data providers and hence multiple queries. Instead of creating individual broadcast settings for each query in the template, a single global setting can be created for the template. When scheduled and broadcasted, this web template setting will run, and hence cache, all of the underlying queries in the template as they would appear in the dashboard. SAP doesn t provide standard broadcast distribution type of filling OLAP cache for web templates. Instead if we want to fill the OLAP cache for Web Templates, another setting such as Broadcast to the Portal will need to be used. Fig-11 shows the settings for this: Fig-11 These settings can be saved and scheduling can be done either with an event trigger or on daily, weekly or monthly basis 2010 SAP AG 10

3. Queries Queries can be individually broadcasted. Unlike with broadcasting a web template, more settings are available, such as broadcasting by multiple selection screen variants and by filter navigation on the query result set, i.e. by a characteristic. Query Monitor In the Properties tab of the Query Monitor different configuration settings for the Read Mode, Cache Mode, and Optimization Mode of the query are given. This can be checked in tcode - RSRT - > Properties The query definition tells the OLAP processor which data it must select. The query definition is determined by the InfoObjects of the query, with a distinction between the InfoObjects in rows (key figures + characteristics), the InfoObjects in columns (key figures + characteristics), the free characteristics, and the filter characteristics. As early as the first navigation step of the query, the InfoObject data in the rows, columns, and filter is read from the database. The data of the free characteristics, however, doesn't need to be read until the dicing of the free characteristics in the query occurs. Fig-12 2010 SAP AG 11

Read Mode: The read mode of a query determines how often the OLAP processor retrieves data from the database during query navigation. The read mode distinguishes between three types of read processes: (Fig -12) Read all data (setting A: Query to Read All Data At Once) Re read the data (setting X: Query to Read Data during Navigation) Re read the data when expanding a hierarchy (setting H: Query to Read When You Navigate or Expand Hierarchies) The Read all Data read mode includes only one read procedure. All the data needed by the query is read from the database in the first step and loaded into the main memory of the OLAP processor. For all additional navigation steps, including the navigation through the free characteristics, the data is aggregated and calculated from the main memory. Another read access to the database is not required. In the Reread the Data read mode, the OLAP processor requires only the necessary data for each navigation step. The data of the free characteristics is read only when it is needed for a dice. Data is read from the OLAP cache when the navigation results have already been selected once. Unlike the Reread the Data when Expanding a Hierarchy read mode, this read mode always reads external hierarchies completely at the leaf level, even if a query selects a higher level. The Reread the Data When Expanding a Hierarchy read mode selects the smallest amount of data. This is why this mode requires the most reads on the database. Where the Reread the Data read mode reads the expanded hierarchy completely in the first step, the Reread the Data When Expanding a Hierarchy read mode reads only the data up to the selected hierarchy level in the first step. If a deeper level of the hierarchy is required in another navigation step, the database must be accessed again. Read Mode Advantages Disadvantages Recommedations Read all Data Fast query navigation after first call, as all the data is present in the OLAP Cache. - First call is slow - Requires more memory in OLAP Cache - Use this read mode only with small Infocubes. - Queries having few free chararteristics. ReRead the data First call is very fast because only required data is selected User have to wait for additional calls if the selection differs from the first call Use this read mode with large quantities of results. ReRead data when expanding hierarchy First call is very fast because only required data is selected It selects smallest amount of data in the first call, so that changes to navigation require read access to database. Use this read mode for large hierarchies. Note: The default setting for a new query is Read Mode H: Query to Read When You Navigate or Expand Hierarchies. 2010 SAP AG 12

Cache Mode: The Cache mode determines whether and in what way the query results are to be saved in the OLAP cache. (Fig-13). Following are the different modes: Cache is Inactive (0) Fig-13 The cross transactional caching is deactivated which means that no result data will be held in Cache. Main Memory without Swapping (1) The cached data is stored in the main memory. In case that memory is exhausted, excess data will be deleted from the memory. Main Memory Cache with Swapping (2) The cached data is stored in the main Memory as well. If the main memory is used up the excess data will be written background store (file, BLOB table) and could be loaded back into the OLAP cache memory when executing another request Persistent Cache per Application server (3) The Cache data is stored persistently as cluster table or BLOB in a database or as a file. It s generally recommended to choose a directory that is proximate to the application server. Persistent Cache Across each Application server (4) The Cache data is stored persistently as cross application server cluster table or BLOB in a database or as a file in a network, accessible from all application servers. In this case only one cluster /BLOB table exists, but can be accessed and written by all application servers. Note: The default setting for a new query is - Main Memory without Swapping (1) 2010 SAP AG 13

Optimization Mode: You can set the optimization mode of the query in the dialog (Fig-14): Option 0 Query Will Be Optimized after generation i.e. the size of the memory structure in which data is stored will be determined by the OLAP processor. This is done after first execution and again after certain period, since the last operation. Option 1 Query Optimization with Individual Periods in Days. This mode is identical to option 0, but we can also select the period of optimization in days. Option 9 Query Optimization Inactive. In this mode, the memory structure of the table is not optimized after generation of the query. Fig-14 Note: The default setting for a new query is 0 Query Will Be Optimized after Generation. 2010 SAP AG 14

We can also change the query properties for all or selected queries of an InfoProvider, we can use the Query Mass Maintenance feature from Query Monitor. For this, use the menu path RSRT Environment Query Mass Maintenance When all the required setting changes are done, click on Generate report to regenerate the queries for the new settings to take effect. We will get following message on the Status bar of RSRT t-code: Queries Adjusted Successfully 2010 SAP AG 15

Cache Maintenance We need to maintain the OLAP cache. The t-code used for this purpose is - RSRCACHE. (Fig-14) Technically, the OLAP cache consists of two caches: - Local cache and - Global cache. These two caches can is set up with different parameters, such as size. The local and global cache size values should be generally extended from their default settings when SAP BW is installed. The cache size must be appropriate to manage the frequency of query calls and the number of users. The size parameters should be reviewed periodically depending on cache usage, hit ratio and overflow. Some indications that your cache size should be extended are: The number of cache entries has filled the capacity of the cache at least once. Average number of cache entries corresponds to at least 90% of the capacity or has reached this capacity around 30% of the time. Ratio of hits to gets is lower than 90%. Local Cache: The local cache is accessed by a single user within a session on an application server. Local cache data is retained in the roll area as long as it is required by the OLAP processor for that user. Global Cache: Global cache data is shared by all users across all application servers. Global cache data is retained for as long as it is required and will either be deleted when it is no longer needed, e.g. the underlying data has changed and the cache is invalidated, or depending on the persistence mode will be swapped to disk when the cache size is exceeded. The global cache size should be larger than the local cache size, as the global cache is accessed across multiple users. Fig-14 2010 SAP AG 16

Note: The values shown in the above fig may differ. BASIS team determines the best values for these settings and therefore should not be modified. T-code used for configuring the cache parameters is RSCUSTV14 or by using T-code-SPRO. Regular audit of the Cache should be done by the support team for individual system.program RSR_CACHE_RSRV_CHECK_ENTRIES can be scheduled to run on a regular basis to remove the unused cache entries. Following fig shows various Cache modes present in the t-code- RSRCACHE: Fig-15 For Cache Mode 1 and 2, the Read flag is checked for entries that were read from the Cache. (Fig-16) Fig-16 2010 SAP AG 17

For Cache modes 3 and 4, this can be checked from the context menu and by clicking Detail. (Fig-17) Fig-17 To view the cache settings for all or selected queries, the RSRREPDIR table can be viewed. Follow these steps: 1. Go to SE16. 2. Enter table name RSRREPDIR and click on Display. 3. The CACHEMODE and READMODE fields below show the settings of the individual queries. (Fig-18) Fig-18 2010 SAP AG 18

Related Content http://help.sap.com/saphelp_nw70/helpdata/en/2a/b37f425b595551e10000000a1550b0/content.htm http://help.sap.com/saphelp_nw70/helpdata/en/41/b987eb1443534ba78a793f4beed9d5/content.htm http://help.sap.com/saphelp_bw32/helpdata/en/d9/31363dc992752de10000000a114084/content.htm http://help.sap.com/saphelp_bw32/helpdata/en/00/241da12ef84f40bb6ecd3ae73d8b58/content.htm http://www.skeneintelligence.com/2011/02/cache 2010 SAP AG 19

Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document. 2010 SAP AG 20