Skip to Content
Technical Articles

BW Accelerator Upgrade: P3 : Is Cube Roll Up Failing ?

Hello Everyone,


In the anticipation of blogging about a new topic, I am going to wrap up my BW Accelerator upgrade series with this Blog.


I have also shared my experiences on BW Accelerator Upgrade in


BW Accelerator Upgrade: P1

BW Accelerator Upgrade: P2: Practical Usage Scenario of back up modes


If you haven’t already read these blogs please consider them for reading.


In this blog, I would like to write about how to tackle the scenario where roll up of cubes starts failing after BWA upgrade.




After our BWA upgrade when were done with the re indexing of the cubes and  our  daily batch loads started .In couple of Process chains the Rollup step got failed.




Before I start with the approach towards solution, let me just quickly brief the steps for Rollup processing in terms of table sequence.


If we observe the rollup for the cubes which are BWA indexed. We can categorize the rollup processing for our understanding purpose as below.


SID Table Processing :  Here SID tables for all the characteristics present in the cube will be processed and if there is any new data for any characteristic it will be rolled up. Both these cases will be clear from the logs.


Logs when there is no new data for Characteristic XXXX:

Index for table ‘/BIC/SXXXX’ is being processed

No new data for index of table ‘/BIC/SXXXX’


Logs when there is new data for Characteristic XXXXX:

Index for table ‘/BIC/SXXXXX’ is being processed

Delta mode for index ‘/BIC/SXXXXX’ set to ‘Off’ (duration: ‘0.065069’)

Read-/fill mode: ‘D’ (Restriction by JOIN with ‘RSDDTREXNEWSID’)

Index of master data table(s) for InfoObject ‘XXXXX’


Fact Table Processing:  Here Fact table of the cube will be processed and all the new data will be rolled up.


Logs for the Fact table indexing of the Cube ZXXX:


Delta mode for index ‘/BIC/FZXXX’ set to ‘Off’ (duration: ‘0.035520’)

Read from ‘F-‘ fact table

Index ‘P03_BIC: FZXXXX’ for BIA index filled (written records ‘Record Count’):

Prepare optimize for BIA subindex ‘P03_BIC: FZXXX’:

Commit optimize for BIA subindex ‘P03_BIC: FZXXX’:


Dimension Table Processing    Here Dimension tables for all the dimensions of the cube will be processed and if there is any new data it will be rolled up.


Logs when there is no new data for the Dimension of the cubes:

Index for table ‘/BIC/DZXXX1’ is being processed

No new data for index of table ‘/BIC/DZXXXX1’


Logs when there is new data for the Dimension of the cubes:

Index for table ‘/BIC/DZXXX2’ is being processed

Delta mode for index ‘/BIC/DZXXX2’ set to ‘Off’ (duration: ‘0.040980’)

Read-/fill mode: ‘D’ (Restriction by JOIN with ‘RSDDTREXNEWDIMID’)

Index ‘P03_BIC:DZXXX2’ for BIA index filled (written records ‘1’):

Prepare optimize for BIA subindex ‘P03_BIC:DZXXX2’:

Commit optimize for BIA subindex ‘P03_BIC:DZXXX2’:


Issue:  Now in our case Rollup failed in any of the above mentioned steps. Sometimes it was fact table while sometime it was SID table.


Please find below the error messages.







Solution:   For fixing the any of the above issue please follow the steps below.


Step1: Delete the BWA Indexes of the cube from RSDDV

Step 2: Recreate the Indexes of the cube (DO NOT FILL INDEXES) from RSDDV

Step 3: Run the program RSDDTREX_SINGLE_TABLE_INDEX (New Creation of an Index for S/D/F Table of a Cube with BIA Index) by giving your cube name and table name as /BIC/SXXXXXXX or /BIC/ZXXXXX (for whichever table the load has failed) and the reason as any free text.

Step4: Fill BIA index of this cube from RSDDV.


What SAP has to say about this program?



The program or function module RSDDTREX_SINGLE_TABLE_INDEX can be used to delete and rebuild individual indexes that belong to active BI Accelerator (BIA) indexes. It is an internal repair tool and is not released for general use.

The function is sometimes executed automatically in the system as part of standard SAP processes. Examples include: During the adjustment of the BIA index to InfoCube metadata changes; when restarting a process after a termination during a commit optimization; and during repairs that are performed as part of a check in transaction RSRV.

The setup of the individual index always occurs after an inbound check, with correct lock logic, and with logging that makes it possible to examine the process.

SAP Support may use this program in exceptional cases and after careful analysis to minimize the resources needed for a repair. Such a repair is only required if your system has a fatal error (such as incorrect data in an index) that has to be analyzed by SAP Support.

We do not support the use of the program in any other situation. If you use the program in other situations, we will not provide any assistance for problems that occur. If this function was a part of standard SAP systems, it could also be executed in BIA maintenance transactions. This is most certainly not the case.

SAP reserves the right to change the program or function module at any time, and to change, rename or to delete the interface.

As of BI Support Package 16 or the implementation of Note 1094810, the use of the program is logged again separately and you can no longer call the function module outside SAP standard processes.

You must be Logged on to comment or reply to a post.
  • Hi Vikram,
    One thing that was not clear for me from this blog, is how you came to this solution? Was it recommended by SAP Support or is it something you tried and it worked? What other solutions you tried before using this program?


    • Hi Vitaliy,

      Thanks for reading the blog.Actually we first faced this issue during our Quality upgrade and there we tried options like RSRV inconsistency check,Delete and Rebuilding the Index etc.But no luck with them…Finally we got to know about this program from the OSS.Running only the program also didnt work.Then the solution was acheived after some trials.But then it was a success for all the cubes for the same issue.Also it worked absolutely fine when we get the error in Production.


      • Interesting, indeed. I am curious what’s the SAP’s take on this, because certainly single-index-rebuild program was not created for this. Although it happened for me to use this program as well 🙂


  • Greetings,

    We used the program to fix the exact same issue and it worked for a while, but then we were struck with another issue where index gets distributed on BWA blades but with several masters for one index part (there MUST be only one master index part) which caused topology issues that made all cube rollups and fillups to BWA fail. You can see the index topology by going to TREXADMIN -> Index Landscape (make sure that no more than one “+master” exist in one row)

    The solution came with BWA Rev 53 (actually it was part of Rev 50 but 53 is the latest and most stable as recommended by SAP) in which the indexes were partitioned and distributed correctly after SAP fixed their BWA reorg algorithms.

    The problem with RSDDTREX_SINGLE_TABLE_INDEX is that it will put all the data in one blade! Another issue is that SAP itself is very cautious in using this program so you never know what it might cause.

    A cleaner way to resolve your issue would’ve been by rebuilding all InfoCube indexes that share that table.

    So if you had an issue with /BIC/SMATERIAL for example, first identify the InfoCubes indexes that share that table from RSDDTREXDIRTABL by restrciting the “Table Name” to /BIC/SMATERIAL. Afterthat delete all the identified indexes. Then recreate and fill the same indexes.

    This should resolve the issue otherwise SAP support must be notified to take a closer look into your issue.

    Regards… Ali.