Escolar Documentos
Profissional Documentos
Cultura Documentos
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
th
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. .
SAP BW
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
SAP BW
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
SAP BW
SAP BW
1. Go to BEx Query Designer and open the query for which the OLAP Cache needs to be filled.- Fig1
Fig-2
SAP BW
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
SAP BW
4. Give the variable values and click on the save button : (Fig-5 & Fig-6)
Fig-5
Fig-6
SAP BW
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
SAP BW
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 its 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
SAP BW
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 doesnt 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
SAP BW
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
SAP BW
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
Read all Data
Advantages
Fast query navigation after first call, as all the data is present in the OLAP Cache.
Disadvantages
First call is slow Requires more memory in OLAP Cache
Recommedations
Use this read mode only with small Infocubes. Queries having few free chararteristics.
User have to wait for additional calls if the selection differs from the first call
It selects smallest amount of data in the first call, so that changes to navigation require read access to database.
Note: The default setting for a new query is Read Mode H: Query to Read When You Navigate or Expand Hierarchies.
SAP BW
Cache Mode:
The Cache mode determines whether and in what way the query results are to be saved in the OLAP cache. (Fig-13).
Fig-13 Following are the different modes: Cache is Inactive (0) 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. Its 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)
SAP BW
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.
SAP BW
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
SAP BW
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
SAP BW
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
SAP BW
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
SAP BW
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
SAP BW