Skip to Content


RSBATCH – This transaction can be used to set up the number of parallel processes to be used for various processes like data load using DTP, Attribute change run, DSO activation, etc.


Delta Maintenance per Data targets – If a data-source has more than one target, each target can have separate delta.  Also the data transfer is optimized for parallel processing (and DTP determines the processing mode).


Simplified Data flow bypassing PSA – In data transfer process (DTP) maintenance, you can specify that data is not extracted from the PSA of the DataSource but is requested straight from the data source at DTP runtime.  The Do not extract from PSA but allow direct access to data source indicator is displayed for the Full extraction mode if the source of the DTP is a DataSource.

Expert mode for DTP debugging – Apart from setting breakpoints you can also specify the records which are to be used to simulate and also specify a temporary store to write to. 


Write-optimized DSO – This DSO can be used as a staging layer to store your data which is immediately available for further processing, no activation required.  The system does not create SID’s and no need to activate data; this will help you process more data faster.  With WO DSO object you can use the system generated key ‘Technical Key’ by setting the flag ‘Do Not Check Uniqueness of Data’, if you do choose to check the uniqueness of data the system generates an index on the semantic key. 


Expert-Routine in Transformation – You can use this concept to build your own routine types and will also need to implement message transfer to the monitor. 

With SPS14 the master data read performance was improved.  The master data is no longer read for each key in the data package.  Instead, all master data of the data package is stored temporarily.  More details in OSS note 1092539. 


Master Data Deletion – Depending the volume of data to be deleted different algorithm is used.  Packaged read of SID tables to avoid memory overflow, parallelism for scalability and foreground or background processing.



Front End 


Safety Belt – To restrict the number of cells that are transferred from ABAP to JAVA when a web report is executed also known as ‘Safety Belt’. Note 1127156, by adding this parameter “BICS_DA_RESULT_SET_LIMIT_DEF” to the RSADMIN table you can specify as to what is the upper limit for the number of cells to be transferred.  The recommendation is 50,000.


Delta Cache – With 3.x when data was loaded to a target the OLAP Cache was invalidated making it inefficient.  With 7.0 there is a new option called ‘Delta Cache’ made available for use with targets that a loaded frequently.


Multi-provider cache partitioning – In addition to the Delta cache there is another new option provided to improve performance of query results.  The data from individual part providers in a multi-provider can be cached separately or grouped together.  This setting can be changed in RSRT.




Stateless mode of web template – Whne this flage is turned on in a web template the memory that is used to render the report is not released,  but once the report is done rendering it is released and allows more users to login.



JavaScript Virus Scan – Some virus scanner products even check for executed JavaScript in the browser, this can lead to significant performance degradation.  More detains in OSS note 1061240.

Inherent changes no settings or parameter changes needed 

  1. In SAP BW 3.x, data selections could be split only to a certain degree into smaller selections that are run in parallel.  With the new release, all query splits can be parallelized. The system performs splits of Multi-provider into part-providers, splits of part provider into aggregates and splits of aggregates/part-providers into E and F tables automatically (if there are enough dialog processes available).
  2. To look up statistics in detail of a query at runtime execute it on the web and add parameter “&PROFILING=X” at the end of the URL and execute it.  Perform your OLAP navigations, to look up the statistics click on the link at the top that says “Click here to view BI statistics”.  More details in the OSS note 1048691.
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. John Skrabak
    Good collection of info on performance gains/ options.  I’m not sure that all the OLAP cache enhancements have been reported on elsewhere, so it’s good to seem them pulled together.

    Another performance tweak I thought about blogging about was the changes to the dimension table indexing in BI 7.0 that I have not seen mentioned in any of the upgrade docs. 

    In 3.5, a dimension table had two indexes created on it, one on the DimID, and a multicolumn index on all the characteristics in the, with column order based on the sequence in which the characteristics appeared in the cube.

    Sometimes, it made sense on some of the larger dim tables to add additional indexes on characteristics that were used in the query selection criteria.  Now in BI 7.0, a separate index is created on each characteristic of a dimension table.  This can help query performance in many cases, with the greatest benedit being on cubes with large dim tables.  


Leave a Reply