Hello Dr.Bjarne,

Regarding the DSO performance improvement tools available in BW when compared to InfoCube.

My Question to you is can we have tools ,available for Infocube like Partioning and rebuilding statistics, for DSO?

 How should we handle the large Base DSO's where data is flowing every year. The base DSO will be feeding many other data targets and we can not arcive data in those base DSO's.

Thanks,

Kiran

Hello Sir,

I am interested in tuning queries with custom SQL. Is there any user-exit or other way to tune the sql statement sent by SAP to the DB?

Is there any best practice for using master data tables with large record numbers? Like 100.000 entities - BUT because the attributes are time dependent - actually it can make up for a million records? Also the number of attributes are huge (and that makes time dependency a major problem). Just for information: a HR BI system with 0EMPLOYEE (extended by most of the important infotype fields (100-250 attributes)). If we chosed to load all master data into cubes or ODS, that would mean a lot of duplicate efforts at the extractor programs, and redundancy in the data we store.

Any info on what is the impact o real time data extraction and remote cubes with remote master data on the source system?

Performance issues when using virtual characteristics and key figures?

Thank you

Laszlo

Hi Suresh,

This is a multipart question, so I will try to be as spacific as possible.  First, a trick is to look at the log files during data activation. If you have have a very long-time log-file-sync, you could buffer Dimensional IDs (DIMID), System IDs (SIDS) and hierarchy IDs (HIEID) to decrease the time the system spends committing individual records to the NRIV table and syncing the log files.

Goto SNRO, click Edit -> Set Buffering -> Main memory try setting this to a higher number (normal is upto 1000, but for a very high number of IDs, you can set this upto 10,000). I would increase this to reduce the load time and the log-sync times (fewer commits). Also, I would remove the BEx flag on DSOs that are not used for reporting and also partitioning these objects to get the SID,DIMID and HIEIDs reduced.

 As to Indexes, maintaining valid Database indexes for infocubes is critical for faster data reads. This is a problem for infocubes with a high-cardinality flag set (causes the index type to change from bitmaps to b-tree). Check this in RSA1->Manage IC->Performance tab and repair these indexes in RSRV for impacted infocubes.

Background: When you flag a dimension as “high cardinality” SAP BI will use a b-tree index instead of a bit-map index. This can be substantially slower if the high cardinality does not exist in the data in general (star-joins cannot be used with b-trees).  Consider only flagging high-cardinality dimensions if a substantial amount of records exists (more than 8-10 million) or if the system is substantially unbalanced (i.e. 30+%). All these items leads to better query performance.

Dr. Berg

Hi Dr. Berg --

Nice to meet you on the chat. A reader of ours mentioned that her activation hangs for large objects and she has to restart them manually. Do you have any advice to troubleshoot this?

Thanks...

Hi Suresh,

SAP recommends for Indexing and performance reasons to flag these as ‘high-cardinality’ dimensions. However, it has minor impact to smaller cubes. I reccomend setting the high-Cardinality flag for large InfoCubes with more than 10 million rows. and a 'balance' of more the 30% (somewhat smaller for very, very large cubes).

The reason for not following the 20% rule-of-thumb is the impact of the swicth fropm bitmap to b-tree indexes (size and performance).

Dr. Berg