Loads delayed due to Indexing Issue

Question

HI SAP GURUS ,
Please suggest correct answer as we have an issue where Deletion / Creation of Index process takes long time to complete .
Also how does the partitions in an Infocube grows & to Increase the performance what steps one should take .
Full points will be rewarded for right answers
Regards ,
Subash Balakrishnan

Answer 1

Hi Subash,
Firstly your question sis vrey generic. It depends that it is taking time in creating Index on DSO or InfoCube.
InfoCubes are more prone to Index creation issue than DSO, due to high number of uncompressed requests. However this also depnds on the database due to archicture:
ORACLE:
With Oracle database, If you have a cube with 1000 uncompressed requests and 10 dimensions (every dimension brings with it a local bitmap index) you have 1000 partitions for the table itself and 10 x 1000 index partitions which makes a total of 11.000 database objects. This amount of objects hurts most when updating statistics or dropping/recreating secondary indexes. In situations with a high load frequency you will most certainly run into problems in this area sooner or later.
If you do a statistics update, all these 11.000 objects will receive new statistics which will take some time and may raise locking problems during execution or at least a serialization when changing the statistics fields in the database catalog tables.
If you drop/recreate secondary indexes, all these objects must be removed or created in the database catalog which also is a serial operation and may again rise locking situations and/or long runtimes. Additionally there is lots of DB cost for returning the allocated disk space.
You will not experience trouble from this direction in the beginning, when the number of partitions is low. But you will run into problems randomly at first, when the number of partitions increase, and permanently, after the number of partitions have exceeded some (not specifiable, system and context dependent) threshold.
SQL Server:
With SQL Server 2005 onwards, there is limitation of 1000 partitions for a table. And each loaded uncompressed request in InfoCube is a partition in SQL Server. In BW System, each uncompressed requests are loaded in one partition and once 1000 partition limit has been reached in a SQL Server database, it will continue writing each new request to the 1000th partition and will write an error to the system log (SQL Error 7719). This is done only to avoid a hard failure when loading data, it is not the recommended business process that one should keep loading requests to the last partition. Continuing to load to the 1000th partition could cause a performance problem later when trying to delete requests and creating indexes and updating statistics of the InfoCube.
How to check number of partitions on the SQL server database:
Execute report RSDD_MSSQL_CUBEANALYZE
- Menu Settings => Expert mode
- Press the Details button
- Choose the number of minimum partitions (choose let say 500)
- Press the button Start Checks
This will display all the tables with more than 500 partitions in the database.
So, to avoid this index creation issue for InfoCubes, it is suggested that one should keep the less number of uncomressed requests in the InfoCube. Compress the InfoCube with the latest request whereever possible.
Hope this helps. Award points if helpful.
Regards
Tanuj