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: https://support.sap.com-> Release, Upgrade & Maintenance -> Maintenance Information. Search in the PAM for your BW product to get more Information.
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:
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.
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).
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.