Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata


SAP® MaxDB - Problems in BW systems

 This page provides information about SAP MaxDB instances used for BW systems.

Moderator: Birgit Malik

WIKI Space Editor: Thiago Lüttig






You should use at least MaxDB version 7.6.05 for a BW system. Problems in older versions might not be analyzed by the support anymore (see note 1178367 End of SAP MaxDB Support Dates). You don't need to upgrade your BW application if you upgrade the database version. Information about the End Of Maintenance of BW Releases can be found in the SAP Support Portal: -> Release, Upgrade & Maintenance -> Maintenance Information. Search in the PAM for your BW product to get more Information.

back to top

Known problems

Known problems concerning MaxDB used for BW systems are described in notes with component BW-SYS-DB-SDB. In case of problems please search for notes with this component in the SAP Support Portal. If the problem is not caused by the database but by the application, a message might be opened on one of the following components:

  • BW-BCT: Business Content und Extractors
  • BW-BEX: Business Explorer
  • BW-WHM: Data Warehouse Management
  • BW-EI: Extended Infrastructure
  • BW-PLA: Planning

back to top

Performance problems

Before you start to analyzer performance problems on your BW-System you should check SAP MaxDB BW Feature Package and HowTo - SAP MaxDB BW Performance (BW Feature Pack).

Performance problems can be caused by the database or by the application. When indexes or aggregates are missing, this decreases the performance of the system. Furthermore the chosen data model can be the reason for the bad performance.

  • Info cube
    In an info cube characteristics with a high cardinality should be specified as line item dimensions.
  • Aggregates
    An aggregate is only useful if a high aggregation of the infocube data is possible. You should keep in mind the following when you create an aggregate:
    • The data transfer is done bei INSERT ... SELECT
    • A high amount of data is transferred in blocks - if the chosen block size is too large, the creation of the aggregate aborts
    • The block size can be changed using transaction RSCUSTV8 - the default value is 10000000. This default value should only be changed when you define aggregates with low summarization on large info cubes.
    • Parallel creation of several aggregates might be inefficient as this might lead to paging in the data cache. Additionally indexes are created after the aggregate has been created. If there is more than one CREATE INDEX statement active in the database, only the data for the first one can be read by several server tasks in parallel - all other indexes are created sequentially.
  • Table statistics
    If the table statistics are not accurate enough the cost based optimizer might not choose the best strategy to access the data. This increases the amount of I/O and decreases the performance. The statistics are estimated. If the sample size for this estimation is not set correctly the statistics might be inaccurate. Please see notes 808060 and 797667 for further information.
  • Parameter
    If you use MaxDB version 7.5 please check notes 767635 and 901377.
    If you use MaxDB version 7.6 please check note 814704.
    Furthermore please check note 514907 concerning the RSADMIN parameters. For MaxDB these parameters should be set as follows:
    SPLIT_DATAMART_TABL_THRES <= 64 (MaxDB version 7.5)
    SPLIT_QUERY_TABL_THRES <= 64 (MaxDB version 7.5)
    SPLIT_DATAMART_TABL_THRES <= 254 (MaxDB version 7.6)
    SPLIT_QUERY_TABL_THRES <= 254 MaxDB version 7.6)
  • Indexes
    Often indexes on master data tables don't exist even if they were useful. When a selective column is specified in the WHERE condition of a query, which reduces the amount of results significantly, an index on this column would be reasonable.
    There is no relation between the dimension tables. If two columns of different dimension tables are specified in the WHERE condition of a query, it might be helpful to create a multiple index on the fact table (containing the SIDs of the dimension tables) - even if these qualifications are quite unselective. In general such a multiple index should contain two, max. three SIDs.
    In versions < 7.6 the data in the fact table is sorted by the SYSKEY. Therefore the rows are stored in the order in which they are inserted. Rows with similar time characteristics (e.g. same date) are inserted soon after each other. When a time characteristic is qualified in a query a lot of results can be expected on one data page - only a few pages have to be read to find all results. However, the MaxDB optimizer does not know this specific BW behaviour. It would rather choose an index on a more selective characteristic than on a time characteristic. Creating a multiple index on the fact table including the time characteristic and the other, selective characteristic would improve the access. Regarding the order of the columns in the index please note:
    • If parameter OPTIMIZE_JOIN_PARALLEL_SERVERS is activated (>0), the selective characteristic should be the first index column, the time characteristic the second column.
    • If parameter OPTIMIZE_JOIN_PARALLEL_SERVERS is not activated (=0), the time characteristic should be the first index column, the selective characteristic the second column.
    • If you want to create a mutliple index on two characteristics and one is qualified with BETWEEN, this column should be the second (last) index column.

back to top

Migration of BW systems

A migration of a BW system is called heterogeneous system copy if the database system is changed. Heterogeneous system copies of BW systems are only supported as pilot projects. Further information about this can be found in note 543715.

  • BW 3.5
    SAP NetWeaver -> Release 04 -> Installation -> SAP Web AS -> SAP Web AS 6.40 and Related Documentation -> Homogeneous and Heterogeneous System Copy
    Furthermore please pay attention to note 771209.
  • BW 3.0/3.1
    SAP Components -> SAP Web Application Server -> Release 6.20 -> System Copy for SAP Systems Based on Web AS 6.20
    Furthermore please pay attention to note 777024.
    3. Pfad für BW 7.0:
    SAP Netweaver -> Release 2004s -> Installation -> System Copy for SAP Systems Based on NW2004s

After a heterogeneous system migration with source system MSSQL or Oracle and target system MaxDB no single indexes are defined on the dimension tables. This can cause performance problems. Therefore you need to check note 931333 when you perform such a migration (valid for all BW releases).

back to top

Further information

Further information about SAP MaxDB in BW systems can be found in note 830468.
Detailed information about a performance analysis is available in Tuning SAP MaxDB.
Note 735598 explains how to install a MaxDB patch for a BW system.

back to top