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

[Former Member]

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.

 

Scenario:

 

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?

 

SAP Note 1098260 to run RSDDTREX_SINGLE_TABLE_INDEX

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.