Heterogeneous System Copy for an SAP NetWeaver BW and SAP ... · Heterogeneous System Copy for an SAP NetWeaver BW and SAP Business Information ... ABAP dictionary. ... EhP 1 for

1 © Copyright IBM Corporation 2007, 2010 All Rights Reserved.

Heterogeneous System Copy for an SAP

NetWeaver BW and SAP Business Information Warehouse System to IBM® DB2® for Linux®,

UNIX®, and Windows®

IBM Deutschland Research & Development GmbH SAP on DB2 for Linux, UNIX, and Windows Development Team

Author: Brigitte Bläser – [email protected]

mailto:[email protected]


Abstract

Heterogeneous SAP system copies (in the following referred to as migrations) of SAP systems to other database platforms or operating systems, always result in a huge effort for large databases. Migration procedures of SAP NetWeaver BW systems are usually the most complex ones. Reason is that in order to achieve an optimal performance on each database platform, SAP NetWeaver BW uses different database-specific features that cannot easily be mapped to each other and that are not explicitly represented in the ABAP dictionary. To deal with this problem, the SAP migration procedure for SAP NetWeaver BW contains additional steps. This document describes the details of the migration procedure for an SAP NetWeaver BW system to IBM® DB2® for Linux®, UNIX® and Windows® as target database platform. It covers the following SAP system releases: SAP Business Information Warehouse 3.0B and 3.1 Content, SAP NetWeaver BW ‗04, SAP NetWeaver BW 7.0 including available Enhancement Packages. This document is intended for SAP migration consultants who are involved in customer migration projects of SAP NetWeaver BW systems to IBM DB2 for Linux, UNIX and Windows.


Table of Contents

ABSTRACT ..................................................................................................................................................... 2

TABLE OF CONTENTS .................................................................................................................................. 3

LIST OF FIGURES .......................................................................................................................................... 5

TRADEMARKS ............................................................................................................................................... 7

SAP PROPRIETARY NOTICES ..................................................................................................................... 8

1. INTRODUCTION ..................................................................................................................................... 9

2. SAP NETWEAVER BW INFORMATION MODEL ............................................................................... 10

2.1 SAP NETWEAVER BW INFORMATION MODEL ELEMENTS ...................................................................... 11 2.2 MAPPING OF INFORMATION MODEL ELEMENTS TO DATABASE TABLES ................................................... 13

2.2.1 PSA .......................................................................................................................................... 13 2.2.2 DataStore Objects .................................................................................................................... 13 2.2.3 InfoCubes and Aggregates ...................................................................................................... 15 2.2.4 Other SAP NetWeaver BW Database Tables .......................................................................... 18

3. SAP NETWEAVER BW IMPLEMENTATION ON IBM DB2 FOR LUW .............................................. 18

3.1 SUPPORT OF HASH PARTITIONING ........................................................................................................ 19 3.2 SUPPORT OF CLUSTERED INDEXES ...................................................................................................... 21 3.3 SUPPORT OF MULTI-DIMENSIONAL CLUSTERING (MDC)........................................................................ 22 3.4 SUPPORT OF COMPRESSION ................................................................................................................ 23 3.5 DETAILED SAP NETWEAVER BW TABLE LAYOUT ON IBM DB2 FOR LUW ............................................. 24

3.5.1 PSA Tables .............................................................................................................................. 24 3.5.2 DataStore Object Tables .......................................................................................................... 25 3.5.3 InfoCube and Aggregate Tables .............................................................................................. 29

3.6 DIFFERENCES TO OTHER DATABASE PLATFORMS ................................................................................. 31

4. CHALLENGES OF SAP NETWEAVER BW SYSTEM MIGRATIONS ................................................ 32

5. STEPS OF A SAP SYSTEM MIGRATION ........................................................................................... 34

6. STEPS OF A SAP NETWEAVER BW SYSTEM MIGRATION ............................................................ 36

6.1 MIGRATION PREPARATIONS ................................................................................................................. 37 6.2 GENERATION OF THE DDL FOR THE TARGET DATABASE ........................................................................ 39

6.2.1 Possibilities for Influencing DDL Generation ............................................................................ 41 6.2.2 DDL Examples for Migrations from Oracle to IBM DB2 for LUW ............................................. 43

6.3 EXPORTING THE SOURCE DATABASE.................................................................................................... 58 6.3.1 Hints and Tips for the Export .................................................................................................... 60

6.4 CREATION AND IMPORT OF THE TARGET DATABASE .............................................................................. 61 6.4.1 SAP NetWeaver 7.0 and EhP 1 for SAP NetWeaver 7.0 ........................................................ 61 6.4.2 SAP NetWeaver ‘04 ................................................................................................................. 66 6.4.3 SAP Business Information Warehouse 3.0B and 3.1 Content ................................................. 71 6.4.4 Handling of Database Partition Groups in Multi-Partition Installations .................................... 71 6.4.5 Modified R3load Processing during Target Database Import .................................................. 73 6.4.6 Hints and Tips to Speed up the Import .................................................................................... 78

6.5 SAP NETWEAVER BW MIGRATION POST PROCESSING STEPS ............................................................. 78

7. TOOLS FOR CHECKING CONSISTENCY OF THE IBM DB2 FOR LUW TARGET DATABASE ..... 80


7.1 REPORT RS_BW_POST_MIGRATION ............................................................................................. 80 7.2 TRANSACTION DBACOCKPIT ............................................................................................................. 81 7.3 CHECKING THE DISTRIBUTION KEYS OF SAP NETWEAVER BW TABLES ................................................. 82 7.4 SAP NETWEAVER BW TRANSACTION RSRV ....................................................................................... 83

8. SOLUTIONS AND WORKAROUNDS FOR POTENTIAL PROBLEMS AND KNOWN ISSUES ........ 84

8.1 IMPORTANT SAP NOTES...................................................................................................................... 84 8.2 UNEVEN DATA DISTRIBUTION IN MULTI-PARTITION IBM DB2 FOR LUW DATABASES .............................. 85 8.3 MISSING DATABASE INDEXES REPORTED AFTER RS_BW_POST_MIGRATION ................................... 86 8.4 REPORT RS_BW_POST_MIGRATION ABORTS IN THE GENERATION OF NEW PSA VERSIONS ............ 86 8.5 ACTIVATION OF AGGREGATES OR INFOCUBES IN THE TARGET SYSTEM ABORTS..................................... 87 8.6 TABLES WITH INCORRECT IBM DB2 FOR LUW FEATURES CREATED FOR INACTIVE AGGREGATES........... 88

9. SUMMARY ............................................................................................................................................ 88

10. LITERATURE ........................................................................................................................................ 88

11. APPENDIX - LIST OF RELEVANT SAP NOTES ................................................................................ 89


List of Figures

Figure 1: Data flow in SAP NetWeaver BW ................................................................................................... 12 Figure 2: Structure of PSA tables .................................................................................................................. 13 Figure 3: Structure of DSO active tables ....................................................................................................... 14 Figure 4: Structure of DSO activation queue tables ...................................................................................... 14 Figure 5: Structure of write-optimized DSO tables ........................................................................................ 15 Figure 6: SAP NetWeaver BW extended star schema .................................................................................. 16 Figure 7: Structure of dimension tables ......................................................................................................... 17 Figure 8: Structure of fact tables .................................................................................................................... 17 Figure 9: IBM DB2 for LUW database layout for SAP NetWeaver BW (one database partition) .................. 20 Figure 10: IBM DB2 for LUW database layout for SAP NetWeaver BW (multiple database partitions) ....... 21 Figure 11: MDC table ..................................................................................................................................... 22 Figure 12: Distribution key of PSA tables ...................................................................................................... 24 Figure 13: Indexes of PSA tables .................................................................................................................. 25 Figure 14: MDC dimensions of PSA tables ................................................................................................... 25 Figure 15: Distribution key of DataStore object active tables ........................................................................ 26 Figure 16: Indexes of DataStore object active tables .................................................................................... 26 Figure 17: Sample MDC dimensions of DataStore object active tables ........................................................ 26 Figure 18: Distribution key of DataStore object activation queue and change log tables ............................. 27 Figure 19: Indexes of DataStore object activation queue and change log tables ......................................... 27 Figure 20: MDC dimensions of DSO activation queue and change log tables .............................................. 27 Figure 21: Distribution key of write-optimized DSO tables ............................................................................ 28 Figure 22: Indexes of write-optimized DSO tables ........................................................................................ 28 Figure 23: MDC dimensions of write-optimized DSO tables ......................................................................... 28 Figure 24: Distribution key of InfoCube fact tables ........................................................................................ 29 Figure 25: Indexes of InfoCube E fact tables................................................................................................. 29 Figure 26: Indexes of InfoCube F fact tables in SAP NetWeaver BW 7.0 ..................................................... 30 Figure 27: Indexes of InfoCube dimension tables ......................................................................................... 31 Figure 28: Steps of a SAP system migration ................................................................................................. 34 Figure 29: SAP export directory structure for target DB platform IBM DB2 for LUW .................................... 35 Figure 30: Steps of a SAP NetWeaver BW system migration ....................................................................... 37 Figure 31: Sample output of report DB6_CHECK_BI_MIGR_NOTES .......................................................... 38 Figure 32: Report SMIGR_CREATE_DDL .................................................................................................... 39 Figure 33: Options provided for IBM DB2 for LUW DDL generation (available with SAP Note 1450612) .... 42 Figure 34: Source database export with EhP 1 for SAP NetWeaver 7.0 ...................................................... 59 Figure 35: Source database export with EhP 1 for SAP NetWeaver 7.0 ...................................................... 60 Figure 36: Report SAP_DROP_TMPTABLES ............................................................................................... 61 Figure 37: EhP 1 for SAP NetWeaver 7.0 - Target system installation ......................................................... 62 Figure 38: EhP 1 for SAP NetWeaver 7.0 - Target system installation steps ............................................... 63 Figure 39: EhP 1 for SAP NetWeaver 7.0 - Exit to create additional database partitions ............................. 64 Figure 40: SAP NetWeaver 7.0 - Creation of additional database partitions ................................................ 65 Figure 41: SAP NetWeaver BW 7.0 - Mapping of database partition groups to partitions ............................ 66 Figure 42: SAP NetWeaver '04 – Target system installation ......................................................................... 67 Figure 43: SAP NetWeaver '04 – Database installation method ................................................................... 68 Figure 44: SAP NetWeaver '04 – Adding database partitions ....................................................................... 69 Figure 45: SAP NetWeaver '04 - Mapping of database partitions to servers ................................................ 70 Figure 46: SAP NetWeaver '04 – Exit step for installing additional database partition servers .................... 71 Figure 47: Tablespace information with database partition group in DBSIZE.XML ...................................... 72 Figure 48: Definition of an additional tablespace and database partition group in DBSIZE.XML ................. 73 Figure 49: Input files to R3load for the import of the target database ........................................................... 74 Figure 50: The DBA Cockpit: Missing tables and indexes before post migration .......................................... 81


Figure 51: The DBA Cockpit: Missing tables and indexes after post migration ............................................. 82 Figure 52: RSRV: Checking database indexes of an InfoCube and its aggregates ...................................... 83 Figure 53: RSRV: Checking database indexes of an InfoCube and its aggregates - Result ........................ 84


Trademarks

IBM, the IBM logo, ibm.com, AIX, DB2, DB2 Universal Database, and z/Os are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. A current list of IBM trademarks is available on the Web at ―Copyright and trademark information‖ at www.ibm.com/legal/copytrade.shtml.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Data contained in this document serves informational purposes only. National product specifications may vary.

Microsoft, Windows, Windows NT, MS SQL Server are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries

Oracle is a registered trademark of Oracle Corporation in the United States and other countries

LINUX is a registered trademark of Linus Torvalds.

Other company, product or service names mentioned may be trademarks or service marks of other companies.

http://www.ibm.com/legal/copytrade.shtml


SAP Proprietary Notices

Some of the information in this document is proprietary to SAP . No part of this information may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

This document is not subject to your license agreement or any other agreement with SAP. This document contains intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. SAP assumes no responsibility for errors or omissions in this document.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.


1. Introduction

Migrations of an SAP NetWeaver BW system or systems based on it (for example, SAP SEM and SAP SCM) are more complex than migrations of other SAP systems. Reason is that BW systems use database platform-specific features to reach a maximum of performance for data warehousing operations. The most prominent example is partitioning. For several database platforms, for example Oracle, MS SQL Server and IBM® DB2® for z/OS®, SAP NetWeaver BW supports range partitioning in slightly different implementations available on these platforms. For IBM® DB2® for Linux®, UNIX® and Windows® (in the following referred to as IBM DB2 for LUW), hash partitioning and multi-dimensional clustering (MDC) are supported. Usually, information about these features is not stored explicitly in the ABAP dictionary. During a migration, database-specific properties of tables and indexes are not available for the SAP migration tool R3load because they are not contained in the information that was exported from the ABAP dictionary of the source system.

In addition, there are certain differences in the structure of tables and the number and structure of secondary indexes for SAP NetWeaver BW objects on the different database platforms. R3load cannot handle this either. When creating the tables and indexes in the target database, R3load relies on the structure information from the ABAP dictionary of the source database, and creates the tables and indexes exactly as defined there. However, when a SAP NetWeaver BW system is migrated to another database platform, the specific features of that platform have to be implemented and the tables and indexes have to be adapted to the layout that is required by the target database platform. To cope with these challenges, additional processing steps were defined on the source and target system, and the R3load tool has been extended to deal with database-specific features and layout differences.

This document describes the details of the migration procedure with IBM DB2 for LUW as target database relevant as of the following SAP NetWeaver BW system releases:

As of SAP Business Information Warehouse 3.0B,

SAP Business Information Warehouse 3.1 Content,

SAP NetWeaver BW ‗04,

SAP NetWeaver BW 7.0,

Enhancement Package 1 for SAP NetWeaver 7.0,

It is intended for SAP migration consultants who perform migrations of SAP NetWeaver BW systems to IBM DB2 for LUW and who are performing migrations from non-Unicode SAP NetWeaver BW systems to Unicode SAP NetWeaver BW systems running on IBM DB2 for LUW.

First, a brief introduction of the SAP NetWeaver BW information model and its mapping to database tables is provided and the implementation of these tables in IBM DB2 for LUW is described. Then the specific problems of SAP NetWeaver BW system migrations are


summarized. An overview of the steps required for migration with R3load is given and the additional steps that have to be executed for SAP NetWeaver BW and SAP NetWeaver BW based systems to handle database specific features and layouts are described. The steps DDL generation, export of the source database, installation and import of the target database, and SAP NetWeaver BW migration post processing are discussed in detail, concentrating on aspects that are relevant for IBM DB2 for LUW as target database platform. Transactions and reports available for checking the consistency of the IBM DB2 for LUW target database after the migration are explained and potential problems and solution and workarounds for known issues are discussed

The migration procedure described here is released for SAP NetWeaver BW releases valid as of SAP Business Information Warehouse 3.0B, and SAP system systems based on, for example, SAP SCM and SAP SEM. It applies to all migrations that require R3load. These migrations include those where the database platform changes as well as migrations from a non-Unicode to a Unicode database on the same database platform. For more information about the required Support Packages and patches, see the following SAP Notes:

For SAP Business Information Warehouse 3.0B and 3.1 Content, see SAP Note 777024

For SAP NetWeaver BW ‗04, see SAP Note 771209 for

For SAP NetWeaver BW 7.0 and Enhancement Package 1 for SAP NetWeaver 7.0 (in the following referred to as EhP 1 for SAP NetWeaver 7.0), see SAP Note 888210.

Throughout this document, the following terminology is used:

IBM DB2 for Linux, UNIX, and Windows is referred to as IBM DB2 for LUW, DB2 for LUW, or DB2. DB2 without reference to an operating system platform always refers to IBM DB2 for LUW.

If the specific release is not relevant, SAP NetWeaver BW and previous releases of SAP Business Information Warehouse is referred to as SAP NetWeaver BW or BW system. Otherwise, the official product names, such as, SAP NetWeaver BW 7.0, EhP 1 for SAP NetWeaver BW 7.0, SAP NetWeaver BW ‗04, SAP Business Information Warehouse 3.0B, or SAP Business Information Warehouse 3.1 Content are used.

The term heterogeneous system copy refers to a copy of a SAP system to a different operating system, a different database platform, or both. Heterogeneous system copies are also called migrations.

2. SAP NetWeaver BW Information Model

SAP NetWeaver BW is an end-to-end solution for an enterprise-wide data warehouse. It is located in the information management area of SAP NetWeaver and provides data


warehousing features, reporting and analysis tools, best-practice models (business content), business-analysis applications, and administrative resources.

This chapter briefly introduces the information model of SAP NetWeaver BW. For details about the SAP NetWeaver BW architecture and the information model, see [10].

2.1 SAP NetWeaver BW Information Model Elements

The following are the basic elements of the information model:

InfoObject: InfoObjects are the fundamental building blocks of the information model. For example, InfoObjects can contain data about customers, sales orders, products, and so on. InfoObjects are reused in other elements of the information model, such as an InfoCube, DataStore object, and InfoSource. SAP NetWeaver BW distinguishes between the following types of data used in analysis: o Key figures:

Sales revenue, fixed costs, sales quantity, number of employees, etc. o Characteristics:

Customer type, fiscal year, period, or region, etc. Characteristics are used to create evaluation groups for analysis.

The underlying InfoObjects are categorized in terms of these two types of data. That is, a given InfoObject represents either a key figure or a characteristic.

DataSource: DataSources contain the definition of source data in a flat structure.

Persistent Staging Area (PSA): The PSA is the initial storage area of data, where requested data is saved unchanged from the source system according to the structure defined in the DataSource.

DataStore: DataStore objects (DSO, in SAP NetWeaver BW ‗04 and lower releases also known as ODS objects) describe consolidated data sets from one or several data sources. The data is stored in flat database tables. DataStore objects are typically used to integrate data from different sources, for delta update into InfoCubes, and for day-to-day decision-making.

InfoCube and Aggregates: InfoCubes are multi-dimensional objects that are used to answer complex business questions on topics such as revenues per region, revenues per office within each region, year-to-date revenues, and for comparisons with previous periods. Aggregates are materialized, summarized views of the data in an InfoCube. They store a subset of InfoCube data redundantly and are very similar to the automatic summary tables available in IBM DB2 for LUW but are implemented using regular database tables.


As of SAP NetWeaver BW 7.0, SAP offers the Business Warehouse Accelerator (BWA) for fast reporting. With the BWA, it is no longer necessary to maintain aggregates, which simplifies warehouse management considerably.

PSA, DataStore objects, InfoCubes and aggregates store transactional data or master data. Transactional data is generated from transactions in an Online Transaction Processing (OLTP) system. Master data, such as a customer address or an organizational structure, typically remains unchanged over a long period of time. Master data in SAP NetWeaver BW includes attributes, texts, and hierarchies. Examples of master data are items such as customer name and address, or an organizational structure.

Figure 1 shows the possible data flow in SAP NetWeaver BW. Data is normally loaded into a PSA table first, and from there into DataStore objects and InfoCubes. You can also directly load data into DataStore objects and InfoCubes, and from DataStore objects into InfoCubes.

Data is loaded into PSA, DataStore, and InfoCubes using InfoPackages. An InfoPackage describes the data to be loaded from a source system, the data targets and how the data is to be processed. If an InfoPackage is scheduled to load data from a source system, a new request ID is generated. The data to be loaded is structured into one or more data packages, each having a configurable maximum number of records. Within the data packages of a request, the records are numbered.

Figure 1: Data flow in SAP NetWeaver BW


2.2 Mapping of Information Model Elements to Database Tables

2.2.1 PSA

A PSA object is implemented as a flat database table consisting of the columns defined in the DataSource, and the following three technical columns that form the primary key:

Request ID

Data package

Record number

PSA tables can get very large because many customers keep data that has already been loaded into DataStore objects and InfoCubes in PSA. If data has to be reloaded or the contents of DataStore objects or InfoCubes have to be rebuilt, the data does not have to be extracted from the source systems again.

PSA table names consist of the namespace enclosed in '/', a 'B' and a generated 10 digit number, for example ―/BIC/B0000000001‖. Common namespace prefixes are /BI0/ for objects from the SAP NetWeaver BW Business Content and /BIC/ for customer-created objects.

Figure 2: Structure of PSA tables

2.2.2 DataStore Objects

DataStore objects consist of key fields and data fields, both of which are InfoObjects. The key fields of DataStore objects are characteristics InfoObjects (for example, order number). The data fields can be key figure or characteristics InfoObjects (for example, order quantity).

At database level, DataStore objects can consist of up to the following three tables:

Active Table: The data is used for reporting and updates to data targets. The active table has the key fields and the data fields of the DataStore object as columns. The key fields form the primary key. To speed up reporting, you can define additional indexes on DataStore objects that are created on the active table. The table name consists of the namespace enclosed in '/' and is followed by the letter 'A', which is the name of the DataStore object and '00', for example ―/BIC/ADSNAME00‖ or ―/BI0/ADSNAME00‖.


Figure 3: Structure of DSO active tables

Activation Queue: This table contains data that is new or has been modified since the last activation. It is not yet available for reporting and delta updates to data targets. The activation queue table has the columns of the active table and the following three technical key columns:

o Request SID

o Data package

o Record number.

The table name consists of the namespace enclosed in '/' followed by the letter 'A', the name of the DataStore object and '40' (for example ―/BIC/ADSNAME40‖ or ―/BI0/ADSNAME40‖).

Figure 4: Structure of DSO activation queue tables

Change Log:

This table is used for delta updates from the DataStore object into other DataStore objects or InfoCubes and for rollback of activated data from the DataStore object. It records new data and updates of the existing active data of the DataStore object. It follows the same naming convention and has the same layout as PSA tables.

Up to and including SAP NetWeaver BW ‗04, the following two types of DataStore objects are provided:

Standard DataStore objects consist of active table, activation queue table and change log table. As soon as data is loaded into a standard DataStore object, it is first inserted into the activation queue. To make this data available for reporting and delta update, it has to be activated. During the activation, new records are inserted into the active table, existing records are updated and records marked for deletion are deleted. Furthermore, before- and after-images of the data are written to the change log table.


DataStore objects for direct update consist of only the active table. Data that is loaded into a DataStore object for direct update is immediately available for reporting and delta update into data targets.

As of SAP NetWeaver BW 7.0, a new write-optimized DataStore object was introduced that consists of the active table only. Active tables of write-optimized DataStore objects contain the semantic key fields and the data fields of the DataStore object as well as the following three technical key fields:

Request ID

Data package

Record identifier

This means that the table has the structure of a change log table. Write-optimized DataStore objects are specifically designed for fast data load - without the overhead of data activation and maintenance of a change log. Reporting only plays a minor role. The naming convention for write-optimized DataStore object tables is the same as for the active tables of standard DataStore objects.

Figure 5: Structure of write-optimized DSO tables

2.2.3 InfoCubes and Aggregates

InfoCubes are represented in the database as a set of relational tables that are arranged according to an extended star schema, as shown in the following Figure 6:


Figure 6: SAP NetWeaver BW extended star schema

The star schema places several dimension tables around a central fact table. The fact table stores key figures while the surrounding dimension tables store the characteristics that are needed for evaluating and reporting on those key figures. Fact tables are the largest tables in star schemas, and can contain billions of entries.

Dimension tables are independent of each other. The fact table links the dimension tables and the key figures using dimension identifiers. A dimension identifier (DIMID) uniquely identifies a particular combination of characteristic values in a dimension table, for example, a certain product and the corresponding product group. Characteristics that are correlated, such as product and product group, are usually put in the same dimension. An InfoCube in SAP NetWeaver BW can have up to 16 dimensions. By default, InfoCubes have the three standard dimensions Data Package, Time, and Unit. The usage of the Time and Unit dimension is optional.

The SAP NetWeaver BW extended star schema stores master data about attributes, hierarchies, and text, in separate tables that are shared between InfoCubes. This reduces data redundancies because master data is stored only once, and then used by various InfoCubes.

Characteristic values in the dimension table are replaced by surrogate identifiers (SIDs). These are numeric key values (4-byte integers) that are more compact than the characteristic values. The actual characteristic values are stored in the master data table.


Figure 7: Structure of dimension tables

InfoCubes have two fact tables, the F fact table and the E fact table. The F fact table still contains information about the requests to which the data loaded belongs. Requests can be deleted from the F fact table if the data is, for example, not consistent. If the quality status of a request is appropriate, the InfoCube can be compressed (SAP NetWeaver BW InfoCube compression). During compression, data is transferred from the F-fact table to the E-fact table of the InfoCube or aggregate. Compressed requests cannot be deleted from the InfoCube anymore.

Figure 8: Structure of fact tables

Fact table names consist of the namespace enclosed in '/' followed by the letter 'F' (for the F fact table) or 'E' (for the E fact table) and the InfoCube name. Dimension table names consist of the namespace enclosed in '/' followed by the letter 'D', the InfoCube name and the dimension identifier or number ('P', 'T', U', 1, 2, ... 9, A, ..., D).

For InfoCubes created and used in an SAP SCM system, the naming convention is as follows: Fact table names consist of the namespace enclosed in '/' followed by ‗9A‘ followed by the letter 'F' (for the F fact table) or 'E' (for the E fact table) and the InfoCube name. Dimension table names consist of the namespace enclosed in '/' followed by ‗9A‘ followed by the letter 'D', the InfoCube name and the dimension identifier or number ('P', 'T', U', 1, 2, ... 9, A, ..., D).

Aggregates are actually a separate InfoCube with their own fact and dimension tables. However, aggregates might share the dimension tables of the corresponding InfoCube if those tables have the appropriate structure. Aggregate table names are constructed like InfoCube table names. Instead of the InfoCube name, they contain the aggregate number (for example ―/BIC/F100001‖, ―/BIC/E100001‖).


2.2.4 Other SAP NetWeaver BW Database Tables

Master Data Tables

Master data tables store the relationship between surrogate identifiers (SIDs) and the characteristic values, attributes, texts, and hierarchies. Master data table names consist of the namespace enclosed in ‗/‘ followed by a letter that identifies the type of master data table and the name of the InfoObject representing the master data. Typical master data tables (for InfoObject 0CUSTOMER from the SAP NetWeaver BW Business Content) are:

/BI0/SCUSTOMER – SID table

/BI0/PCUSTOMER – Non-time-dependent attributes table

/BI0/QCUSTOMER – Time-dependent attributes table

/BI0/XCUSTOMER - Non-time-dependent attributes SID table

/BI0/YCUSTOMER - Time-dependent attributes SID table

/BI0/HCUSTOMER – Hierarchy table

/BI0/ICUSTOMER – SID structure of hierarchy table

/BI0/KCUSTOMER – Conversion of hierarchy nodes to SID table

Master data tables are standard SAP tables without database-specific features or layout differences on different database platforms. They do not require any special processing during migration.

SAP NetWeaver BW temporary tables

The SAP NetWeaver BW OLAP engine creates temporary tables and views during query processing to store intermediate results and results of hierarchy evaluations. Table and view names consist of the namespace ―BI0‖ enclosed in ‗/‘, followed by ‗0‘, a digit that identifies the type of temporary table or view, and an 8 digit number. Examples are ―/BI0/0600000001‖, ―/BI0/02000000002‖, etc. SAP NetWeaver BW temporary tables are kept in a pool so that they can be reused to reduce costly database catalog table creation operations. SAP NetWeaver BW 7.0 introduces temporary 0P tables to store materialized partial results from complex BW queries (for example ―/BI0/0P000000001‖). 0P tables have an individual structure that makes reuse difficult. Therefore, 0P tables are dropped when they are no longer needed.

3. SAP NetWeaver BW Implementation on IBM DB2 for LUW

SAP NetWeaver BW supports and uses the following IBM DB2 for LUW features:

Hash partitioning using the database partitioning feature (DPF)

Multi-dimensional clustering

Compression

Clustered indexes


In addition, there are differences in the indexes created on SAP NetWeaver BW object tables between IBM DB2 for LUW and other database platforms supported by SAP NetWeaver BW. In the following, the layout of SAP NetWeaver BW object tables and indexes on IBM DB2 for LUW is discussed. This includes the implementation of hash partitioning, MDC, and row compression and an overview of the indexes that are created.

3.1 Support of Hash Partitioning

With the DPF feature, PSA, DataStore object, InfoCube and aggregate fact tables can be distributed over several database partitions. During a normal installation on IBM DB2 for LUW with the SAP installation tool SAPinst, typically a system with one database partition is created. You can add additional partitions to an existing database instance by choosing ―Add Database Partition on the Welcome screen of the SAPinst tool (see the folder Database Specific Features). The default installation of SAP NetWeaver BW on IBM DB2 for LUW is shown in Figure 9. The following four database partition groups are part of the installation:

SAPNODEGRP_<SAPSID> for the standard SAP basis tablespaces on database partition 0.

NGRP_DIM_<SAPSID> for the dimension tablespace, also residing on database partition 0

NGRP_FACT_<SAPSID> for the tablespace containing fact tables of SAP NetWeaver BW InfoCubes and aggregates

NGRP_ODS_<SAPSID> for the tablespace containing PSA and DataStore object tables


Figure 9: IBM DB2 for LUW database layout for SAP NetWeaver BW (one database partition)

Database partition 0 contains the SAP Basis tables and SAP NetWeaver BW dimension and master data tables, and acts as the coordinator partition. The SAP application servers all connect to database partition 0.

A typical multi-partition database layout is shown in Figure 10. The database partition groups NGRP_FACT_<SAPSID> and NGRP_ODS_<SAPSID> are distributed over database partitions 1 to n while the database partition groups SAPNODEGRP_<SAPSID> and NGRP_DIM_<SAPSID> reside on database partition 0. To keep database partition 0 small and to reduce the workload, it is recommended not to place large InfoCube and aggregate fact tables, DataStore object tables and PSA tables on database partition 0.


Figure 10: IBM DB2 for LUW database layout for SAP NetWeaver BW (multiple database partitions)

In large SAP NetWeaver BW installations, sometimes a more complex partition design has been implemented with additional database partition groups for large and small aggregates, small and medium-sized InfoCube fact tables located on subsets of the partitions. Having a mixture of small, medium-sized and large InfoCubes and DataStore objects can optimize performance but also complicate system management. Some customers also decide to put the fact tables of very large InfoCubes into their own data classes and tablespaces.

IBM DB2 for LUW hash partitioning distributes the rows of PSA, DataStore object, and InfoCube and aggregate fact tables to one or more database partitions using a distribution key that is defined when the table is created. The generation of the distribution keys has been hard-coded in SAP NetWeaver BW coding specific to the IBM DB2 for LUW such that it guarantees an equal distribution of the data over all database partitions. The distribution key is created for all fact tables, DataStore object tables, and PSA tables even if they reside on only one database partition.

For more information about the number of recommended database partitions based on given hardware resources and the database size, see [6].

3.2 Support of Clustered Indexes

A clustering index is a record-based index on one or more columns that physically organizes the data along this index. Clustering indexes organize the data along one dimension and can therefore speed up queries that are restricted on this dimension. For a clustering index, the DB2 database tries to maintain the clustering order. However, the clustering order depends on the free space that is available on the data pages and that is not guaranteed.


In SAP NetWeaver BW on IBM DB2 for LUW, clustered indexes are created on InfoCube F and E fact tables if these tables do not use multi-dimensional clustering (MDC).

3.3 Support of Multi-Dimensional Clustering (MDC)

Multi-dimensional clustering (MDC) is a performance feature that was introduced with IBM DB2 UDB for UNIX and Windows Version 8. With MDC, you can define one or more MDC dimensions for a table according to which the table data is clustered. An MDC dimension can be a single column or a group of columns. In SAP NetWeaver BW, only single column MDC dimensions are supported. MDC organizes the table data physically in blocks of pages. Each block contains data records with the same values for the MDC dimensions. Important differences to clustered indexes are that tables can be organized along more than one dimension and that the clustering is always guaranteed.

MDC uses indexes that are block-based. These indexes are much smaller than regular record-based indexes and therefore consume less disk space and can be scanned faster. Block indexes point to MDC blocks instead of individual records. For a table with multiple MDC dimensions, block indexes are created on each dimension (dimension block indexes) and on the combination of all dimensions.

Figure 11 shows an example of an MDC table that is organized by two dimensions (REGION and YEAR). For this table, a dimension block index on REGION, a dimension block index on YEAR and a combined block index on YEAR and REGION are automatically generated. Additional record-based indexes on REGION, YEAR or both are not required.

Figure 11: MDC table

MDC improves the performance of queries that contain restrictions on the MDC dimensions and the performance of data warehouse data roll-in and roll-out operations. Data roll-in operations benefit from block locking, that is, the locking of whole MDC blocks instead of single data rows. Data roll-out operations benefit from MDC fast delete operations. When data is deleted such that the only conditions in the WHERE clause


apply to MDC dimensions, a procedure called MDC rollout deletion can be used. MDC rollout deletion marks complete data pages instead of single data records as deleted. As of IBM DB2 Version 9.5 for LUW, asynchronous cleanup of additional row-based indexes that are defined on MDC tables is provided. The delete operation returns when the pages have been marked as deleted and the block indexes have been updated. Additional row-based indexes are cleaned up afterwards asynchronously in the background. This improves the performance of data delete operations considerably. In IBM DB2 9.7 for LUW, the ability to return empty extents of MDC tables to the tablespace online has been added. In IBM DB2 Version 9.5 for LUW and lower, MDC tables can only be reorganized offline. You find detailed information about MDC, its support in SAP NetWeaver BW and recommendations for using it in [6], [15], and [16].

All Support Packages of SAP NetWeaver BW 7.0 and higher and the Support Packages of SAP NetWeaver BW listed below provide MDC support for InfoCube and aggregate fact tables, DataStore objects tables, and PSA tables:

SAP BW 3.0B Support Package 32

SAP BW 3.1 Content Support Package 26

SAP NetWeaver BW ‗04 Support Package 18

In SAP NetWeaver BW 7.0 and higher releases, the information about MDC dimensions of fact tables and DSO active tables is stored in the SAP NetWeaver BW metadata for InfoCubes and DataStore objects and can be transported within a SAP NetWeaver BW system landscape. In the SAP releases lower than SAP NetWeaver 7.0, the information about MDC dimensions of fact tables and DSO active tables is not stored in the SAP NetWeaver BW metadata. As a consequence, it cannot be transported between systems and might even get lost when empty InfoCubes and DataStore objects are re-activated in transaction RSA1.

3.4 Support of Compression

Row compression was introduced in IBM DB2 V9.1 for LUW to compress data rows in tables. Row compression is dictionary-based. The compression dictionary is stored in the table data object. Row compression reduces the disk space consumption of table data significantly and can also improve performance, especially for IO-restricted systems. You find detailed information about row compression, its support in SAP NetWeaver BW and recommendations for using it in [6].

Row compression has been supported as of the following SAP NetWeaver BW Support Packages:




SAP NetWeaver BW 7.0 Support Package 8

If the global SAP NetWeaver BW RSADMIN parameter DB6_ROW_COMPRESSION is set to YES, InfoCube and aggregate fact tables, DataStore object tables, and PSA tables are created with row compression activated. The default value for this parameter is NO.


As of the following SAP Support Packages the default value of this parameter has been changed to YES for SAP NetWeaver BW 7.0 and higher if the DB2 database version is at least IBM DB2 Version 9.5 for LUW and the DB2 Storage Optimization license is installed (for more information see SAP Note 1481572):


EhP 1 for SAP NetWeaver BW 7.0 Support Package 8

Data cannot be compressed until a compression dictionary has been created. A compression dictionary can be created after data has been inserted into the tables. As of IBM DB2 Version 9.5 for LUW, the DB2 database automatically creates a compression dictionary after a small amount of data has been inserted into a table with row compression activated. You do not have to create compression dictionary manually. For IBM DB2 V9.1 for LUW, SAP NetWeaver BW transaction RSRV provides a check and repair function for InfoCubes, DataStore objects and PSA tables. This repair function checks whether row compression is active, if the table contains data and if a compression dictionary exists. If no compression dictionary exists the user can schedule a job that either creates the dictionary and compresses the existing data or only creates the dictionary for future use.

With IBM DB2 9.7 for LUW, index compression was introduced. That is, indexes of compressed tables are automatically created with index compression activated. SAP NetWeaver BW leverages this functionality. There is no separate SAP NetWeaver BW option or parameter that you can use to activate or deactivate index compression.

3.5 Detailed SAP NetWeaver BW Table Layout on IBM DB2 for LUW

3.5.1 PSA Tables

The distribution key of PSA tables consists of the record number column RECORD.

Figure 12: Distribution key of PSA tables

PSA tables have a primary key index defined on the columns request ID (REQUEST), data package (DATAPAKID) and record number (RECORD). There are no additional secondary indexes.


Figure 13: Indexes of PSA tables

MDC for PSA tables is controlled by the global SAP NetWeaver BW RSADMIN parameter DB6_MDC_FOR_PSA. If the parameter is set to YES, PSA tables are created with MDC on column REQUEST. By default, DB6_MDC_FOR_PSA is set to NO, that is PSA tables are not created as MDC tables (for exceptions, see SAP Note 1000382). To create PSA tables as MDC tables, you must set parameter DB6_MDC_FOR_PSA to YES explicitly.

If your database is IBM DB2 9.7 for LUW and as of the following SAP NetWeaver BW Support Packages, the default has been changed to YES (for more information, see SAP Note 1481572):


EhP 1 for SAP NetWeaver BW 7.0 Support Package 8

Note: We recommend that you use MDC for SAP NetWeaver BW 7.0 and higher releases on IBM DB2 9.7 for LUW. The main advantage of using MDC for PSA tables, DSO activation queue tables, DSO change log tables, and F fact tables is the good performance of MDC rollout delete operations combined with the ability to return empty extents to the tablespace online.

Figure 14: MDC dimensions of PSA tables

Row compression for PSA tables is controlled by the global SAP NetWeaver BW RSADMIN parameter DB6_ROW_COMPRESSION. If the parameter is set to YES, PSA tables are created with compression activated.

3.5.2 DataStore Object Tables

Active Tables of Standard DataStore Objects and DataStore Objects for Direct Update

The distribution key of active tables consists of the semantic key fields of the DataStore object.


Figure 15: Distribution key of DataStore object active tables

The semantic key fields also form the primary key index. Note: SAP NetWeaver BW allows additional unique indexes to be created on subsets of the semantic key fields of DataStore objects. However, the creation of additional unique indexes is not supported on IBM DB2 for LUW. It would violate the constraint that all distribution key fields must be included in each unique index (to allow uniqueness to be checked locally on each database partition). Therefore, only non-unique indexes can be created. This is shown in Figure 16 with the additional optional index 010 as an example.

Figure 16: Indexes of DataStore object active tables

With MDC supported for active tables, you can select MDC dimensions from the semantic key fields of the DataStore object, as shown in Figure 17.

Figure 17: Sample MDC dimensions of DataStore object active tables

Standard DataStore Object Activation Queue and Change Log Tables

The distribution key of activation queue and change log tables consists of the record number column.


Figure 18: Distribution key of DataStore object activation queue and change log tables

Up to and including SAP NetWeaver BW ‗04, the primary key index of activation queue and change log tables consists of the columns request ID, data package and record number. In SAP NetWeaver BW 7.0, the REQUEST column in activation queue tables has been replaced by the surrogate identifier of the request (column SID).

Figure 19: Indexes of DataStore object activation queue and change log tables

For activation queue and change log tables, MDC is controlled by RSADMIN parameter DB6_MDC_FOR_PSA in the same way as for PSA tables. For activation queue tables, the SID column (SAP NetWeaver BW 7.0 and higher releases) or the REQUEST column (SAP NetWeaver BW ‗04 and lower releases) is chosen as the only MDC dimension if DB6_MDC_FOR_PSA is set to YES. For change log tables, REQUEST is chosen as MDC dimension in all SAP NetWeaver BW and SAP Business Information Warehouse releases.

Figure 20: MDC dimensions of DSO activation queue and change log tables

Write-Optimized DataStore Objects

Write-optimized DataStore objects only consist of the active table with the additional technical key columns REQUEST, DATAPAKID, and RECORD.

The distribution key consists of the semantic key fields of the DataStore object.


Figure 21: Distribution key of write-optimized DSO tables

The implementation of write-optimized DataStore object indexes is different in IBM DB2 for LUW than in the other relational databases that are supported by SAP NetWeaver BW.

By default, the active table of write-optimized DataStore objects has a primary key index that is defined on the technical key columns REQUEST, DATAPAKID and RECORD. This index cannot be implemented in IBM DB2 for LUW because it would be in conflict with the distribution key which consists of the semantic key columns. Therefore, in an IBM DB2 for LUW database, a non-unique index with ABAP dictionary (DDIC) name RDR is created on the technical key columns. The table itself is marked as having no primary key index in the ABAP dictionary. A function module RSDU_FASTSTORE_CHECK_UNIQUE is provided for checking the uniqueness of the technical key. This function module is called while BW data is being loaded into write-optimized DataStore objects.

If you select the ‗check uniqueness of data‘ option for the DataStore object in the SAP NetWeaver BW Data Warehousing Workbench, a unique index KEY is created on the semantic key fields of the DSO.

Figure 22: Indexes of write-optimized DSO tables

MDC for the active table of write-optimized DataStore objects is controlled by RSADMIN parameter DB6_MDC_FOR_PSA. If this parameter is set to YES, the REQUEST column is the only MDC dimension.

Figure 23: MDC dimensions of write-optimized DSO tables

For all DataStore object types and tables, row compression is controlled by RSADMIN parameter DB6_ROW_COMPRESSION. If the parameter is set to YES, the tables are created with compression activated.


3.5.3 InfoCube and Aggregate Tables

Fact Tables

The distribution key of InfoCube and aggregate fact tables consists of the dimension key columns of the table except for the package dimension key column in the order

dimension 1, dimension 2, … ,time dimension, unit dimension.

The dimension key columns are named KEY_<InfoCube name><Dimension Identifier>, where <Dimension identifier> is P, T, U, 1 to 9, or A to D. The total number of dimensions is limited to 16.

Defining the distribution key on all key columns facilitates collocated joins in central SAP NetWeaver BW operations like InfoCube compression. That is, it is not necessary to transport fact table rows in table queues from one partition to other partitions.

Figure 24: Distribution key of InfoCube fact tables

E fact tables have a combined unique index named P that is defined on the dimension key columns in the following order:

time dimension, dimension 1, dimension 2, unit dimension, package dimension

For non-MDC tables, this index is defined as clustering index.

E fact tables have single-column indexes that are defined on the key columns of the user-defined dimensions 1 to 9 and A to D, and on the time dimension key column.

Figure 25: Indexes of InfoCube E fact tables

Whether or not the P index is created on F fact tables depends on the SAP NetWeaver BW release and the properties of the InfoCube:

F fact tables of InfoCubes that are created and used in an SAP SCM system have a unique P index defined on all dimension columns in the same way as for E fact tables. In the SAP NetWeaver BW InfoCube management table RSDCUBE, entries for SCM InfoCubes have the value ‗APO‘ in the field BWAPPL. You can


identify SCM InfoCube tables also by their name: prefix enclosed in ‗/‘ followed by ‗9A‘ followed by table type (‗F‘, ‗E‘, ‗D‘) and the InfoCube name (for example, F fact table: /BIC/9AF<Cube>, E fact table: /BIC/9AE<Cube>, time dimension table: /BIC/9AD<Cube>T). This applies to all SAP NetWeaver BW releases.

In SAP NetWeaver BW releases prior to SAP NetWeaver BW 7.0, the P index on F fact tables is created as a non-unique index.

As of SAP NetWeaver BW 7.0 and higher, the P index on F fact tables of non-SCM InfoCubes is created by default only for InfoCubes that allow delta load (flag DELTA_LOAD set to ‗X‘ in table RSDCUBE). For these InfoCubes, the P index on F fact tables is created as a non-unique index. For other InfoCubes, the P index on F fact tables is not needed any more for SAP NetWeaver BW InfoCube compression or other ETL operations. Therefore, it is no longer created by default. If you need the index for SAP NetWeaver BW reporting, you can set RSADMIN parameter DB6_PINDEX_ON_FTABLE to YES to enforce its creation. In this case, the index is created as a non-unique index.

If the P index on the F fact table exists and the F fact table does not use MDC, the P index is the clustering index.

F fact tables have single-column indexes defined on the key columns of the user-defined dimensions 1 to 9 and A to D (index names 040 – 160), and on the time (index name 020) and package dimension (index name 020) key columns. The index on the time dimension key column is defined as clustering index if the combined index on all dimension key columns does not exist and if the InfoCube uses the time dimension. For F fact tables without P index of InfoCubes without time dimension, the index on the package dimension key column is the clustering index.

Figure 26: Indexes of InfoCube F fact tables in SAP NetWeaver BW 7.0

You can select MDC dimensions from the user-defined InfoCube dimensions 1 to 9 and A to D, and the time dimension. Alternatively to the time dimension, you can also select one of the time characteristics 0CALMONTH (calendar month) or 0FISCPER (fiscal period). There is a soft limit of three for the number of MDC dimensions.

If you select a time characteristic, an additional column SID_0CALMONTH or SID_0FISCPER is inserted into the fact tables after the dimension key columns and before the key figure columns. This is similar to the implementation of range partitioning for other database platforms: range partitioning is supported on the time characteristics 0CALMONTH or 0FISCPER. If the user selects range partitioning for an InfoCube, an additional column SID_0CALMONTH or SID_0FISCPER is inserted into the fact tables.


For the F fact tables, you can also select the package dimension key column as MDC dimension.

By default, aggregates inherit the MDC settings of the InfoCube. You can turn off MDC for aggregates by setting RSADMIN parameter DB6_MDC_FOR_AGGREGATES=NO. The default setting is DB6_MDC_FOR_AGGREGATES=YES.

If an InfoCube dimension is selected as MDC dimension, no single column index is created on the dimension key column. This is because a MDC dimension block index is already created on that column.

For InfoCube and aggregate fact tables, row compression is controlled by RSADMIN parameter DB6_ROW_COMPRESSION. If the parameter is set to YES, the tables are created with compression activated.

Dimension Tables

Dimension tables reside on only one database partition. They do not have a distribution key.

They have a primary key index on the dimension ID column DIMID, a combined index on all or, for tables with more than 16 SID columns, the first 16 SID columns, and single column indexes on the second, third, etc., SID column.

Figure 27: Indexes of InfoCube dimension tables

MDC is not used for dimension tables.

Row compression is not used for dimension and master data tables.

3.6 Differences to Other Database Platforms

DPF and MDC are unique IBM DB2 for LUW features that are not supported by other database platforms. Compression is also supported by IBM DB2 for z/OS and in the latest releases of Oracle and MS SQL Server.

On some database platforms, like Oracle, IBM DB2 for z/OS, IBM DB2 for i, and MS SQL Server, InfoCube and aggregate fact tables and PSA tables are implemented with range partitioning. For InfoCube fact tables, range partitioning can be defined on the time characteristics 0CALMONTH (calendar month) or 0FISCPER (fiscal period). In this case, an additional column SID_0CALMONTH or SID_0FISCPER is added to the fact tables. For F fact tables, range partitioning is often implemented on the package dimension key


column to support fast deletion of requests by dropping the database partition where the request resides.

By default aggregates inherit the partitioning settings of the InfoCube. Partitioning for single aggregates can also be turned off in the aggregate maintenance screen.

On some database platforms, range partitioned PSA tables have an additional column PARTNO.

There are also differences concerning the indexes that are created on InfoCube and aggregate fact tables, and DataStore object tables.

Database platforms other than IBM DB2 for LUW implement the combined index of fact tables with a different column order and not clustered. On some platforms, the combined index P is not created on F fact tables or the additional single column indexes on the second, third, etc. SID column of dimension tables are not created.

Other database platforms support additional unique indexes on DataStore object active tables while IBM DB2 for LUW only supports non-unique indexes. As described previously, different indexes on the active table of write-optimized DataStore objects are defined on IBM DB2 for LUW than on other database platforms.

For more information about the implementation of SAP NetWeaver BW on IBM DB2 for LUW, refer to [6] and [12]. [13] provides details about the general implementation of SAP systems on IBM DB2 for LUW.

4. Challenges of SAP NetWeaver BW System Migrations If you want to migrate an SAP NetWeaver BW system, you have to deal with the following challenges:

SAP NetWeaver BW systems tend to get very large and to contain very large tables (InfoCube fact tables, PSA tables, DataStore active and change log tables). Considerable effort might be necessary to determine the most efficient way to export and import the very large tables through e.g. parallelization, use of database specific import methods, etc. Therefore, you have to plan such a migration carefully so that it fits in the available time frame.

Different limits for the size and number of database objects on the source and target database platform might require you to move tables to new data classes and to use database-specific features like partitioning to fit the objects into the available space. Size limits have been an issue in IBM DB2 UDB for UNIX and Windows Version 8. As of IBM DB2 for LUW V9.1, large tablespaces (up to 16 TB) for data and indexes are supported. The only limit that still exists is the maximum number of 55,000 tables per tablespace. Migrations of systems where all tables are stored in one data class in the source database might require you to move part of the tables to different data classes and IBM DB2 for LUW tablespaces.

When the tables and indexes in the target database are created, the database-specific features have to be implemented. If the features are not represented


explicitly in the ABAP dictionary, standard R3load processing cannot handle them. This is a problem even if the system is only moved to a different operating system without changing the database platform. If the database platform is changed, the layout of tables and indexes on the target database platform might differ from the layout in the source database. The ABAP dictionary only contains the layout in the source database.

The first two issues are general. You will have to deal with them during all migrations of large SAP systems and are, therefore, not discussed in this document any further. For more information about how to speed up SAP system migrations to IBM DB2 for LUW by tuning database export and import, refer to [11].

The third issue is specific to SAP NetWeaver BW systems. For migrations to IBM DB2 for LUW, you have to ensure to handle the following correctly:

PSA, DataStore, and InfoCube fact tables have to be created with a distribution key in the target DB2 database.

If MDC is used, the tables have to be created with the correct MDC dimensions.

If compression is to be used, the tables have to be created with compression enabled.

The combined indexes on fact tables have to be created clustered for non-MDC tables. If the combined index on the F fact table does not exist, the index on the time dimension key column or the package dimension key column has to be created as clustered index.

If you migrate an SAP system from a different database platform to IBM DB2 for LUW, you have to consider the following:

o Additional unique indexes on DataStore active tables have to be created as a non-unique index on DB2. Otherwise, SQL errors occur.

o The combined index on fact tables has to be created with a different column order than on the source database.

o On dimension and fact tables, additional secondary indexes that do not exist in the source database might have to be created.

o Other indexes that are existing in the source database might not be needed in DB2 and should not be created.

o Row-based indexes on MDC dimension columns should not be created.

The data exported from the ABAP dictionary of the source system does not contain the necessary information to create the tables and indexes with all database-specific features. Additional information is needed to correctly create the tables and indexes. This is also true for pure non-Unicode to Unicode migrations when the source and the target database platform are both IBM DB2 for LUW. Also in this case, the information about distribution keys, MDC dimensions, clustered indexes and compression is not contained in the data exported from the ABAP dictionary.


Since the information needed is not available in the data that was exported from the ABAP dictionary of the source system, additional information is required.

5. Steps of a SAP System Migration

SAP system migrations are system copies where either the operating system platform or the database platform, or both change. In most cases, migrations involve the export of the source database in a database independent format with the SAP R3load tool. With IBM DB2 for LUW as database platform, you can perform migrations between the different UNIX operating system platforms using database means (for example, database backup and redirected restore) without having to export the database with R3load. This is described in [14]. R3load is only needed in the following situations:

When performing a migration from another database platform like Oracle, MS SQL Server, MaxDB, or IBM DB2 for z/OS or IBM DB2 for i

When performing a migration from Linux to UNIX or Windows or vice versa

When performing a migration from a non-Unicode to a Unicode system because since the database code page changes, you cannot use the backup and redirected restore method.

The steps required to export the source system and to build up the target system are shown in Figure 28 below.

Figure 28: Steps of a SAP system migration

On the source system, the following steps are executed:


1. Migration preparations that consist in the execution of reports and transactions that are described in detail in [3] for systems based on SAP NetWeaver 7.0 and in [4] for systems based on SAP NetWeaver ‘04. Especially when migrating from non-Unicode to Unicode a number of reports have to be executed to make sure that the target Unicode database can be set up correctly. For Unicode migrations please consult [5].

2. Generation of the R3load control files The R3load control files define the tasks for unloading the database that can be executed sequentially or in parallel.

3. Generation of the template that contains size estimations for the target database For IBM DB2 for LUW, the template contains the size estimations for the tablespaces and tablespace containers. These estimations are often not very accurate. The real sizes have to be determined during a test migration.

4. Generation of the command files for the database export.

5. Unloading of the source database to files in a database independent format with R3load by executing the command files generated in the previous step

For IBM DB2 for LUW as target database platform, the export is stored in the directory structure shown in Figure 29.

Figure 29: SAP export directory structure for target DB platform IBM DB2 for LUW

LABEL.ASC is the CD label created for the export. It is checked when the target database is installed. The DATA subdirectory contains the exported data and the ABAP dictionary structure information. DDLDB6.TPL is a template for the DDL statements that is used to create tables and indexes in IBM DB2 for LUW. It also contains a standard mapping of the SAP data classes to DB2 tablespaces. The DB6 subdirectory contains the DBSIZE.XML file, which is the template containing the size estimates for the target database.

You have to make the export available on the target server.

On the target server, the following steps have to be executed:

1. Generation of the SAP instance

2. Obtaining the migration key required for system migrations from SAP

DATA DB LABEL.ASC

DB6 DDLDB6.TPL

<Export_Directory>


3. Creation of the target database with tablespace sizes based on the estimations from the source database and the sizes obtained from test migration.

4. Import of the data into the target database with R3load

5. Execution of post migration reports and transactions as described in [3], [4] and [5] to complete the migration.

Usually, the SAP installation tool SAPinst and the SAP migration monitor tool (MigMon) are used to export the source system, to install the target system, and to import the database.

The SAP Service Marketplace provides information about available tools and possible optimizations for system copies under [2].

6. Steps of a SAP NetWeaver BW System Migration As of SAP Business Information Warehouse 3.0B, two additional steps to the ones described above have to be performed for SAP NetWeaver BW system migrations:

On the source system, a report has to be run that generates the target database-specific DDL for creating SAP NetWeaver BW tables and indexes. R3load executes the DDL during target database import.

On the target system, after database import, a report has to be run that performs a number of SAP NetWeaver BW-specific post-migration tasks.

The complete migration process consists of the steps shown in Figure 30.


Figure 30: Steps of a SAP NetWeaver BW system migration

For current information about system copy in general and the required Support Packages and patches, see the SAP Notes 771209, 777024, and 888210, and the information provided in [2].

You should always use the latest patches of the SAP migration tools. You will find them on SAP Service Marketplace in the Software Download section.

In the following, the SAP NetWeaver BW-specific migration steps are described in more detail.

6.1 Migration Preparations

For migrations to IBM DB2 for LUW, make sure that you read SAP Note 1281430 that provides a transport containing report DB6_CHECK_BI_MIGR_NOTES. This report checks whether the source system fulfills the prerequisites for a migration to IBM DB2 for LUW. The report checks the installed Support Packages and lists important SAP Notes (Kernel, SAP_BASIS, SAP_BW) that should be implemented before the migration. The report handles SAP Notes that are relevant for the migration to IBM DB2 for LUW (that is, corrections for report SMIGR_CREATE_DDL and BW-migration post processing). The report also handles the minimum Support Packages and SAP hot news notes that should be installed before the migrated system is used in a production environment.


Figure 31: Sample output of report DB6_CHECK_BI_MIGR_NOTES

Note: It is highly recommended to follow the recommendations of report DB6_CHECK_BI_MIGR_NOTES. Especially make sure that the minimum required Support Packages and the hot news notes are installed. Otherwise, unpredictable errors might occur if the migrated system is used in a production environment.

The minimum required SAP NetWeaver BW and SAP Business Information Warehouse Support Packages for a migration to IBM DB2 for LUW are as follows:

SAP Business Information Warehouse 3.0B: Support Package 33

SAP Business Information Warehouse 3.0 Content: Support Package 27

SAP NetWeaver BW ‗04: Support Package 23

SAP NetWeaver BW 7.0: Support Package 18

EhP 1 for SAP NetWeaver BW 7.0: no minimum required Support Package


6.2 Generation of the DDL for the Target Database To create the DDL for the SAP NetWeaver BW object tables and indexes for the target database system, you have to run report SMIGR_CREATE_DDL in the source system. Figure 32 shows the appropriate screen of the report where you have to do the following:

Select the target database platform (choose DB6 for IBM DB2 for LUW)

Specify whether a non-Unicode to Unicode conversion is involved

Enter the output directory for the DDL

For test purposes, you can restrict the DDL generation to a single table or a single SAP data class. The DDL is stored in files named <DATACLASS>.SQL for each SAP data class that contains SAP NetWeaver BW tables or indexes with database specific features or different implementations on the source and target database platforms.

Figure 32: Report SMIGR_CREATE_DDL

It is important that after the report has been executed and before the database is exported, no more changes to SAP NetWeaver BW database objects (for example, activations, field changes) are made. The safest thing is to call the report directly before the export while the system is locked for users.

The output files of the report have to be placed in the DB/DB6 subdirectory of the source database export directory. R3load uses them as additional input files when creating the tables and indexes in the target database.

The .SQL output files are structured as follows:


tab: <Table name> sql: <DDL Statement(s) for table> ind: <Index name> sql: <DDL Statement(s) for index>

For each table, there is an entry labeled ―tab:‖ with the table name and the DDL for the table labeled ―sql:‖. For each index, there is an entry labeled ―ind:‖ with the index name and the DDL for the index.

Note: Starting with the Support Packages listed in SAP Note 1324665, report SMIGR_CREATE_DDL creates an additional file named SQLFiles.LST that contains a list with the names of all .SQL files that have been generated.

For migrations to IBM DB2 for LUW, report SMIGR_CREATE_DDL creates DDL to handle the following database-specific features and implementation details:

Distribution keys for PSA tables, DataStore object tables, and InfoCube fact tables

Clustered indexes on InfoCube and aggregate fact tables

MDC dimensions of InfoCube and aggregate fact tables, DataStore object tables and PSA tables

Compression

For migrations from other database platforms the following implementation differences are handled:

o Indexes missing on the source database platform but required in the DB2 database, for example additional secondary indexes on dimension tables.

o Indexes existing on the source database platform but not required in the DB2 database. For these indexes, entries with an empty sql section (i.e. with an empty DDL statement) are created.

o Differences in uniqueness and column order of indexes on the source database platform, for example the differences in the column order of the combined index on InfoCube fact tables

o Conversion of range partitioning to MDC

We discuss in section 6.4.5 how R3load uses the DDL to create all tables and indexes in the IBM DB2 for LUW target database correctly.

In general, DDL statements are only generated in the following cases:

For tables and indexes using features that are specific to IBM DB2 for LUW and that R3load cannot handle on its own

In migrations from other database platforms, for tables and indexes with a different layout in a DB2 database than in the source database.

The DDL generation program determines which tables and indexes with which properties exist on the source system and - based on this information - generates the DDL for the target system. Therefore, the DDL generated for IBM DB2 for LUW as target database platform might look different for different source database platforms.


For migrations from other database platforms, the ABAP dictionary on the target system will look the same after the migration as on the source system whereas the layout of the tables and indexes in the target database is as required for IBM DB2 for LUW. Thus the state in the ABAP dictionary might not be consistent with the state in the database. During SAP NetWeaver BW migration post-processing, the information about tables and indexes is adapted in the ABAP dictionary to the layout in the target database (see chapter 6.5).

6.2.1 Possibilities for Influencing DDL Generation

SAP Note 1450612 provides a number of options to influence DDL generation that you can select from a drop down list, which is displayed when you choose the F4 help for the field Database Version on the screen of report SMIGR_CREATE_DDL.

For system copies without changing the database platform (IBM DB2 for LUW to IBM DB2 for LUW), you can choose between the following options:

Compress all tables: DDL generated for a table always contains COMPRESS YES, regardless of the type of the table. COMPRESS YES is also added for dimension and master data tables.

Keep current compression settings: Only when a table is compressed in the source database the DDL generated for it contains COMPRESS YES.

Do not compress: DDL generated for a table does not contain COMPRESS YES, regardless of whether the table is compressed in the source database or not.

For MDC, there are no options are provided. The DDL generated for tables contains the same MDC dimensions as in the source database. This is because, if the source system already runs on IBM DB2 for LUW, the DDL is created using the information about distribution keys, clustered indexes, and MDC from the database system catalog. Therefore, tables and indexes are created with exactly the same features as in the source system. For instance, it is not possible to generate DDL with MDC for tables that do not use MDC in the source database. The only exception is row compression. The DDL generation options listed above let you generate DDL with the COMPRESS YES option, even if the tables are uncompressed in the source database and vice versa.

For system copies from other database platforms to IBM DB2 for LUW the following DDL generation options are available:

Compress all tables, use MDC for BW: DDL generated for all tables contains compression. MDC is contained for PSA, DSO activation queue and DSO change log tables and range-partitioned fact tables are converted to use MDC.

Compress all tables, do not use MDC for BW: DDL generated for all tables contains compression but MDC is not used.

Compress BW fact/DSO/PSA tables, use MDC: DDL generated for fact, DSO, and PSA tables contains compression. MDC is contained for PSA, DSO activation queue and DSO change log tables and range partitioned fact tables are converted to use MDC.


Compress BW fact/DSO/PSA tables, do not use MDC: DDL generated for fact, DSO, and PSA tables contains compression but MDC is not used.

Do not compress but use MDC for BW: DDL generated for tables does not contain compression. However, MDC is contained for PSA, DSO activation queue and DSO change log tables and range partitioned fact tables are converted to MDC.

Do not compress and do not use MDC for BW: DDL generated for tables includes neither compression nor MDC.

Figure 33: Options provided for IBM DB2 for LUW DDL generation (available with SAP Note 1450612)

If you did not implement SAP Note 1450612, DDL generation can be influenced only for system copies from other database platforms to IBM DB2 for LUW. If the source system already runs on IBM DB2 for LUW, the DDL is generated with exactly the same features as in the source database (including compression). Even though the SAPinst tool provides an option to create all tables compressed in the target database, report SMIGR_CREATE_DDL also generates a DDL for tables without any other features specific to IBM DB2 for LUW - except for compression. This implies that, when all tables in the DB2 source database are compressed, for each table a CREATE TABLE statement containing the COMPRESS YES option is generated.

If you did not implement SAP Note 1450612 has not been implemented and the source database platform is not IBM DB2 for LUW, you can set SAP NetWeaver BW RSADMIN parameters in the source system before you run report SMIGR_CREATE_DDL to influence the DDL generation. The following RSADMIN parameters influence the output of SMIGR_CREATE_DDL if IBM DB2 for LUW is not the source database platform:

DB6_MDC_FOR_PSA: If the parameter is set to YES, PSA tables and DataStore object activation queue and change log tables are created with MDC , and if the parameter is set to NO, these tables are created without MDC. The default value


for this parameter is NO (for exceptions, see SAP Note 1000382). You have to set it to YES explicitly even if you have implemented SAP Note 1481572.

We recommend that you use MDC for PSA and PSA-like tables if the target database uses at least IBM DB2 for LUW 9.7 Fix Pack 1 for SAP.

DB6_ROW_COMPRESSION: If the parameter is set to YES, PSA, DataStore object tables and InfoCube and aggregate fact tables are created with row compression activated, and if the parameter is set to NO, these tables are created without row compression. The default value for this parameter is NO. You have to set it to YES explicitly even if you have implemented SAP note 1481572. For the available R3load options to achieve optimal compression rates when loading the target database see [11].

For the conversion of range partitioned fact tables to use MDC, enter RP_TO_MDC in the field Database Version. This is recommended for SAP NetWeaver BW 7.0 and higher if the target database uses at least IBM DB2 9.7 for LUW Fix Pack 1 for SAP.

The following restriction applies independently of the implementation of SAP Note 1450612: MDC for fact tables can only be generated if the InfoCube is implemented with range partitioning on a time characteristics in the source database. A CREATE TABLE statement is generated such that the time characteristics column is the only MDC dimension on the E fact table, and the time characteristics and the package dimension key column are the two MDC dimensions on the F fact table. In the future, it is also allowed to define the package dimension key column as the only MDC dimension on the F fact table and to not use MDC for the E fact table. This setting supports fast deletion of InfoPackages from InfoCube F fact tables.

Furthermore, the usage of RSADMIN parameter DB6_PINDEX_ON_FTABLE is also independent of the implementation of SAP Note 1450612 is: If the parameter is set to YES, the combined P index on F fact tables is created. If the parameter is set to NO, it is not created. This only applies to SAP NetWeaver BW 7.0. In earlier releases, the index is always created.

6.2.2 DDL Examples for Migrations from Oracle to IBM DB2 for LUW

In the following, samples of the DDL that is generated for SAP NetWeaver BW tables are shown. The samples shown were generated on an Oracle database. In all examples, RSADMIN parameter DB6_ROW_COMPRESSION was set to YES.

InfoCube Fact Tables without Range Partitioning

The following DDL is generated for a standard F fact table of an InfoCube that does not use range partitioning:

tab: /BIC/FBFABCUBE5 sql: CREATE TABLE "/BIC/FBFABCUBE5" ("KEY_BFABCUBE5P" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5T" INTEGER DEFAULT 0 NOT NULL,


"KEY_BFABCUBE5U" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE51" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE52" INTEGER DEFAULT 0 NOT NULL, "/BIC/BCRMEM_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BCRMEM_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BRTNSVAL" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BRTNSQTY" DECIMAL(000017,000003) DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES

PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING;

ind: /BIC/FBFABCUBE5~0

ind: /BIC/FBFABCUBE5~02 sql: CREATE INDEX "/BIC/FBFABCUBE5~02" on "/BIC/FBFABCUBE5" ("KEY_BFABCUBE5T") CLUSTER ALLOW REVERSE SCANS;


The sql section below the ―tab:‖ entry contains the CREATE TABLE statement with the correct distribution key (PARTITIONING KEY (…) USING HASHING clause). Note that to specify the distribution key, PARTITIONING KEY( …) USING HASHING is still used instead of the newer DISTRIBUTE BY HASH (…) syntax.

The ―ind:‖ entry for primary key index /BIC/FBFABCUBE5~0 contains no sql section. Fact tables do not have a primary key index but standard R3load processing always creates one. If there exists an entry for the index in the .SQL file, R3load uses the DDL statement in this entry. In this case, the DDL statement is empty. Therefore, the index is not created.

The ―ind:‖ entry for index /BIC/FBFABCUBE5~02 contains the DDL statement for creating the index on the time dimension key column as a clustered index.


In a SAP NetWeaver BW DB2 database, indexes on the unit dimension key column are not created. For this fact table, index 030 exists in the Oracle database. The empty sql section avoids that the index is created in the target database.

If RSADMIN parameter DB6_PINDEX_ON_FTABLE was set to YES, the following DDL was generated:

tab: /BIC/FBFABCUBE5 sql: CREATE TABLE "/BIC/FBFABCUBE5" ("KEY_BFABCUBE5P" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5T" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5U" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE51" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE52" INTEGER DEFAULT 0 NOT NULL, "/BIC/BCRMEM_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BCRMEM_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BRTNSVAL" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BRTNSQTY" DECIMAL(000017,000003) DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING;

ind: /BIC/FBFABCUBE5~0 sql: CREATE INDEX "/BIC/FBFABCUBE5~P" on "/BIC/FBFABCUBE5" ("KEY_BFABCUBE5T", "KEY_BFABCUBE51", "KEY_BFABCUBE52", "KEY_BFABCUBE5U", "KEY_BFABCUBE5P") CLUSTER ALLOW REVERSE SCANS;



The P index /BIC/FBFABCUBE5~P that does not exist in the source system is created as clustered index. The DDL statement for creating the P index is stored under the entry for the primary key index /BIC/FBFABCUBE5~0. Since the index does not exist in the source system, no entry in the R3load.TSK files is created for it. If it was stored under its own index name in the .SQL files, R3load would never process it. If R3load executes the task to create the primary key index /BIC/FBFABCUBE5~0, it uses the DDL statement to create the P index instead.

An entry for index /BIC/FBFABCUBE5~02 is not needed because it is not created as clustering index and, therefore, has no features specific to IBM DB2 for LUW that R3load cannot handle.

The following DDL is generated for a standard E fact table of an InfoCube that does not use range partitioning:

tab: /BIC/EBFABCUBE5 sql: CREATE TABLE "/BIC/EBFABCUBE5" ("KEY_BFABCUBE5P" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5T" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5U" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE51" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE52" INTEGER DEFAULT 0 NOT NULL, "/BIC/BCRMEM_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BCRMEM_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BRTNSVAL" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BRTNSQTY" DECIMAL(000017,000003) DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING;

ind: /BIC/EBFABCUBE5~0




ind: /BIC/EBFABCUBE5~P sql: CREATE UNIQUE INDEX "/BIC/EBFABCUBE5~P" on "/BIC/EBFABCUBE5" ("KEY_BFABCUBE5T", "KEY_BFABCUBE51", "KEY_BFABCUBE52", "KEY_BFABCUBE5U", "KEY_BFABCUBE5P") CLUSTER ALLOW REVERSE SCANS;

The sql section below the ―tab:‖ entry contains the CREATE TABLE statement with the correct distribution key.

The ―ind:‖ entry for primary key index /BIC/EBFABCUBE5~0 contains no sql section. This avoids that a primary key index is created for the table.

In an SAP NetWeaver BW DB2 database, indexes on the unit dimension key column are not created on F and E fact tables, and indexes on the package dimension key column are not created on E fact tables. The empty sql sections prevent the indexes existing in the source system from being created in the target database.

The ―ind:‖ entry for index /BIC/FBFABCUBE5~P creates the P index on the E fact table as clustering index with the column order that is required for IBM DB2 for LUW.

InfoCube Fact Tables with Range Partitioning

The following DDL is generated for a standard F fact table of an InfoCube that uses range partitioning if range partitioning is not converted to MDC:

tab: /BIC/FZTPHTGC1 sql: CREATE TABLE "/BIC/FZTPHTGC1" ("KEY_ZTPHTGC1P" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC1T" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC1U" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC11" INTEGER DEFAULT 0 NOT NULL, "SID_0CALMONTH" INTEGER DEFAULT 0 NOT NULL, "/BIC/HTGKF1" INTEGER DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "KEY_ZTPHTGC11" , "KEY_ZTPHTGC1T" , "KEY_ZTPHTGC1U" ) USING HASHING;


ind: /BIC/FZTPHTGC1~0

ind: /BIC/FZTPHTGC1~020 sql: CREATE INDEX "/BIC/FZTPHTGC1~020" on "/BIC/FZTPHTGC1" ("KEY_ZTPHTGC1T") CLUSTER ALLOW REVERSE SCANS;


The DDL is nearly the same as in the previous example apart from the following exceptions:

The table contains the additional column SID_0CALMONTH used for range partitioning. This column remains in the table although it will not be used in the DB2 database.

There is an additional entry with an empty sql section for index /BIC/FZTPHTGC1~900 that exists in the source system but it will not be created in the DB2 target database.

Range partitioning is implemented such that the E fact table is partitioned on the time characteristic and the F fact table is partitioned on the package dimension key column. To provide efficient access to the time characteristic column in the F fact table, the index ~900 is created in the Oracle database. In the IBM DB2 for LUW database, the column is maintained and filled correctly but it is not used in SAP NetWeaver BW reporting. Therefore, you do not have to create an index on it.

The following DDL is generated for a standard F fact table of an InfoCube that uses range partitioning if range partitioning is not converted to MDC:

tab: /BIC/EZTPHTGC1 sql: CREATE TABLE "/BIC/EZTPHTGC1" ("KEY_ZTPHTGC1P" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC1T" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC1U" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC11" INTEGER DEFAULT 0 NOT NULL, "SID_0CALMONTH" INTEGER DEFAULT 0 NOT NULL, "/BIC/HTGKF1" INTEGER DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "KEY_ZTPHTGC11" , "KEY_ZTPHTGC1T" , "KEY_ZTPHTGC1U" ) USING HASHING;


ind: /BIC/EZTPHTGC1~0


ind: /BIC/EZTPHTGC1~P sql: CREATE UNIQUE INDEX "/BIC/EZTPHTGC1~P" on "/BIC/EZTPHTGC1" ("KEY_ZTPHTGC1T", "KEY_ZTPHTGC11", "KEY_ZTPHTGC1U", "KEY_ZTPHTGC1P") CLUSTER ALLOW REVERSE SCANS;

The DDL is nearly the same as in the previous example apart from the following exceptions:

The table contains the additional column SID_0CALMONTH that is used for range partitioning. This column remains in the table although it is not used in the DB2 database.

An entry with an empty sql section for index /BIC/EZTPHTGC1~030 is not created because the index does not exist in the source system.

InfoCube Fact Tables with Range Partitioning and Conversion of Range Partitioning to MDC

Starting with the following Support Packages, you can convert range partitioned fact tables such that they use MDC:





You also need the following SAP Basis Support Packages:

SAP Basis 620 Support Package 62



Note that for SAP NetWeaver BW ‗04 and lower releases, MDC for fact tables is only supported with restrictions (for more information, see SAP Note 942909).

To convert range partitioning to MDC, enter RP_TO_MDC in the field Database Version of report SMIGR_CREATE_DDL or choose appropriate options from the F4 help of field Database Version when SAP Note 1450612 is implemented. The following output is created for the F fact table of the previous example:

tab: /BIC/FZTPHTGC1 sql: CREATE TABLE "/BIC/FZTPHTGC1" ("KEY_ZTPHTGC1P" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC1T" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC1U" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC11" INTEGER


DEFAULT 0 NOT NULL, "SID_0CALMONTH" INTEGER DEFAULT 0 NOT NULL, "/BIC/HTGKF1" INTEGER DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES

PARTITIONING KEY ( "KEY_ZTPHTGC11" , "KEY_ZTPHTGC1T" , "KEY_ZTPHTGC1U" ) USING HASHING ORGANIZE BY ( "KEY_ZTPHTGC1P" , "SID_0CALMONTH" ); ALTER TABLE "/BIC/FZTPHTGC1" LOCKSIZE BLOCKINSERT;




The CREATE TABLE statement for the F fact table contains the correct distribution key and two MDC dimensions in the ORGANIZE BY clause (the package dimension key column and the time characteristic column). Furthermore, the LOCKSIZE attribute is set to BLOCKINSERT to support MDC fast roll-in. With LOCKSIZE set to BLOCKINSERT, MDC blocks instead of single rows are locked when data is inserted into the table.

The index /BIC/FZTPHTGC1~010 on the package dimension key column is not created because this column is a MDC dimension and, therefore, has a MDC block index.

There is no entry for index /BIC/FZTPHTGC1~020. This index is not created as clustered index because the table is an MDC table.

Again, the primary key index /BIC/FZTPHTGC1~0 and the index /BIC/FZTPHTGC1~900 on the time characteristic column SID_0CALMONTH are not created in the IBM DB2 for LUW target database.

The following output is generated for the E fact table:

tab: /BIC/EZTPHTGC1 sql: CREATE TABLE "/BIC/EZTPHTGC1" ("KEY_ZTPHTGC1P" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC1T" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC1U" INTEGER DEFAULT 0 NOT NULL, "KEY_ZTPHTGC11" INTEGER DEFAULT 0 NOT NULL, "SID_0CALMONTH" INTEGER DEFAULT 0 NOT NULL,


"/BIC/HTGKF1" INTEGER DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES

PARTITIONING KEY ( "KEY_ZTPHTGC11" , "KEY_ZTPHTGC1T" , "KEY_ZTPHTGC1U" ) USING HASHING ORGANIZE BY ( "SID_0CALMONTH" ); ALTER TABLE "/BIC/EZTPHTGC1" LOCKSIZE BLOCKINSERT;



ind: /BIC/EZTPHTGC1~P sql: CREATE UNIQUE INDEX "/BIC/EZTPHTGC1~P" on "/BIC/EZTPHTGC1" ("KEY_ZTPHTGC1T", "KEY_ZTPHTGC11", "KEY_ZTPHTGC1U", "KEY_ZTPHTGC1P") ALLOW REVERSE SCANS;

The CREATE TABLE statement contains the correct distribution key and the time characteristic column SID_0CALMONTH as MDC dimension. The LOCKSIZE is set to BLOCKINSERT. The P index /BIC/EZTPHTGC1~P is created non-clustered.

Note that for aggregate fact tables the RSADMIN parameter DB6_MDC_FOR_AGGREGATES is not evaluated. If RP_TO_MDC is selected, the DDL for aggregate fact tables is generated with MDC if these tables use range partitioning on the time characteristics in the source system. Otherwise, the DDL is generated without MDC.

Dimension Tables

If single-column indexes on the second, third, etc. SID columns do not exist in the source system, the following DDL is generated for dimension tables with more than one SID column:

tab: /BIC/DBBLFAB51 sql: CREATE TABLE "/BIC/DBBLFAB51" ("DIMID" INTEGER DEFAULT 0 NOT NULL, "SID_ZCOORDER" INTEGER DEFAULT 0 NOT NULL, "SID_ZME_STATU" INTEGER DEFAULT 0 NOT NULL, "SID_ZCOUNTRY" INTEGER DEFAULT 0 NOT NULL, "SID_ZREGION" INTEGER DEFAULT 0 NOT NULL,


"SID_ZEANUPC" INTEGER DEFAULT 0 NOT NULL, "SID_ZDISTR_CH" INTEGER DEFAULT 0 NOT NULL, "SID_ZFABSHPTO" INTEGER DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&";

ind: /BIC/DBBLFAB51~0 sql: CREATE UNIQUE INDEX "/BIC/DBBLFAB51~0" on "/BIC/DBBLFAB51" ("DIMID") ALLOW REVERSE SCANS; ALTER TABLE "/BIC/DBBLFAB51" ADD CONSTRAINT "/BIC/DBBLFAB51~0" primary key ("DIMID"); CREATE INDEX "/BIC/DBBLFAB51~020" on "/BIC/DBBLFAB51" ("SID_ZME_STATU") ALLOW REVERSE SCANS; CREATE INDEX "/BIC/DBBLFAB51~030" on "/BIC/DBBLFAB51" ("SID_ZCOUNTRY") ALLOW REVERSE SCANS; CREATE INDEX "/BIC/DBBLFAB51~040" on "/BIC/DBBLFAB51" ("SID_ZREGION") ALLOW REVERSE SCANS; CREATE INDEX "/BIC/DBBLFAB51~050" on "/BIC/DBBLFAB51" ("SID_ZEANUPC") ALLOW REVERSE SCANS; CREATE INDEX "/BIC/DBBLFAB51~060" on "/BIC/DBBLFAB51" ("SID_ZDISTR_CH") ALLOW REVERSE SCANS; CREATE INDEX "/BIC/DBBLFAB51~070" on "/BIC/DBBLFAB51" ("SID_ZFABSHPTO") ALLOW REVERSE SCANS;

The CREATE TABLE statement does not contain any features specific to IBM DB2 for LUW. Dimension tables are created without distribution key and without MDC. With SAP Note 1450612, DDL for dimension tables can be generated with the COMPRESS YES option if a DDL generation option containing Compress all tables is selected.

The ―ind‖ section for primary key index /BIC/DBBLFAB51~0 contains the DDL for the primary key index and the DDL for all additional secondary indexes that do not exist in the source system but need to be created in the IBM DB2 for LUW target database. Again, the DDL for the additional indexes is stored in the ―ind‖ section for primary key index /BIC/DBBLFAB51~0 because otherwise R3load cannot find it.

DataStore Object Tables

The following DDL is generated for the active table of a standard DataStore object that has an additional unique index besides the primary key index:

tab: /BIC/AZFCT_R1000 sql: CREATE TABLE "/BIC/AZFCT_R1000" ("/BIC/BASIS6" SAPDB6VARCHAR(000010)


DEFAULT ' ' NOT NULL, "/BIC/BASIS7" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "CALDAY" SAPDB6VARCHAR(000008) DEFAULT '00000000' NOT NULL, "/BIC/AO1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS2" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS3" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/KLAMM1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/REF1B1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/REF2REF1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/KENNZ1" INTEGER DEFAULT 0 NOT NULL, "/BIC/KENNZ2" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/KENNZ3" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/KENNZ4" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/KENNZ5" SAPDB6VARCHAR(000008) DEFAULT '00000000' NOT NULL, "/BIC/KENNZ6" SAPDB6VARCHAR(000006) DEFAULT '000000' NOT NULL, "/BIC/KENNZ7" INTEGER DEFAULT 0 NOT NULL, "CURRENCY" SAPDB6VARCHAR(000005) DEFAULT ' ' NOT NULL, "UNIT" SAPDB6VARCHAR(000003) DEFAULT ' ' NOT NULL, "RECORDMODE" SAPDB6VARCHAR(000001) DEFAULT ' ' NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "/BIC/BASIS6" , "/BIC/BASIS7" , "CALDAY" ) USING HASHING;

ind: /BIC/AZFCT_R100001 sql: CREATE INDEX "/BIC/AZFCT_R100001" on "/BIC/AZFCT_R1000" ("/BIC/BASIS7") ALLOW REVERSE SCANS;


The CREATE TABLE statement contains the correct distribution key. The index /BIC/AZFCT_R100001, which is unique in the source system, has to be created as a non-unique index in the IBM DB2 for LUW database because the index does not contain all distribution key columns.

If a DDL generation option containing use MDC was chosen or if RSADMIN parameter DB6_MDC_FOR_PSA was set to YES, the following DDL is generated for the activation queue table of the DataStore object:

tab: /BIC/AZFCT_R0540 sql: CREATE TABLE "/BIC/AZFCT_R0540" ("SID" INTEGER DEFAULT 0 NOT NULL, "DATAPAKID" SAPDB6VARCHAR(000006) DEFAULT '000000' NOT NULL, "RECORD" INTEGER DEFAULT 0 NOT NULL, "/BIC/BASIS6" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS7" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "CALDAY" SAPDB6VARCHAR(000008) DEFAULT '00000000' NOT NULL, "/BIC/AO1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS2" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS3" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/KLAMM1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/REF1B1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/REF2REF1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/KENNZ1" INTEGER DEFAULT 0 NOT NULL, "/BIC/KENNZ2" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/KENNZ3" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/KENNZ4" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/KENNZ5" SAPDB6VARCHAR(000008) DEFAULT '00000000' NOT NULL, "/BIC/KENNZ6" SAPDB6VARCHAR(000006) DEFAULT '000000' NOT NULL, "/BIC/KENNZ7" INTEGER DEFAULT 0 NOT NULL, "CURRENCY" SAPDB6VARCHAR(000005) DEFAULT ' ' NOT NULL, "UNIT" SAPDB6VARCHAR(000003)


DEFAULT ' ' NOT NULL, "RECORDMODE" SAPDB6VARCHAR(000001) DEFAULT ' ' NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "RECORD" ) USING HASHING ORGANIZE BY ( "SID" ); ALTER TABLE "/BIC/AZFCT_R0540" LOCKSIZE BLOCKINSERT;

The CREATE TABLE statement contains the correct distribution key and ―SID‖ as MDC dimension. The table option LOCKSIZE is set to BLOCKINSERT.

If a DDL generation option containing use MDC was chosen or if RSADMIN parameter DB6_MDC_FOR_PSA was set to YES, the following DDL is generated for the active table of a write-optimized DataStore object:

tab: /BIC/AZFCT_R0600 sql: CREATE TABLE "/BIC/AZFCT_R0600" ("REQUEST" SAPDB6VARCHAR(000030) DEFAULT ' ' NOT NULL, "DATAPAKID" SAPDB6VARCHAR(000006) DEFAULT '000000' NOT NULL, "PARTNO" INTEGER DEFAULT 0 NOT NULL, "RECORD" INTEGER DEFAULT 0 NOT NULL, "/BIC/BASIS6" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS7" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/AO1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS2" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/BASIS3" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/KLAMM1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/REF1B1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/REF2REF1" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/KENNZ1" INTEGER DEFAULT 0 NOT NULL, "/BIC/KENNZ2" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/KENNZ3" DECIMAL(000017,000002)


DEFAULT 0 NOT NULL, "/BIC/KENNZ4" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/KENNZ5" SAPDB6VARCHAR(000008) DEFAULT '00000000' NOT NULL, "/BIC/KENNZ6" SAPDB6VARCHAR(000006) DEFAULT '000000' NOT NULL, "/BIC/KENNZ7" INTEGER DEFAULT 0 NOT NULL, "CURRENCY" SAPDB6VARCHAR(000005) DEFAULT ' ' NOT NULL, "UNIT" SAPDB6VARCHAR(000003) DEFAULT ' ' NOT NULL, "RECORDMODE" SAPDB6VARCHAR(000001) DEFAULT ' ' NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "/BIC/BASIS6" , "/BIC/BASIS7" ) USING HASHING

ORGANIZE BY ( "REQUEST" ); ALTER TABLE "/BIC/AZFCT_R0600" LOCKSIZE BLOCKINSERT;

ind: /BIC/AZFCT_R0600~0 sql: CREATE INDEX "/BIC/AZFCT_R0600RD" on "/BIC/AZFCT_R0600" ("REQUEST", "DATAPAKID", "RECORD") ALLOW REVERSE SCANS;

The CREATE TABLE statement contains the correct distribution key and ―REQUEST‖ as MDC dimension.

Instead of the primary key index on ―REQUEST‖, ―DATAPAKID‖ and ―RECORD‖ the non-unique index /BIC/AZFCT_R0600RD on these columns is created. The primary key index or a unique index on these columns cannot be created because it would not contain the distribution key columns.

PSA Tables

The following DDL is generated for a PSA table:

tab: /BI0/B0000103000 sql: CREATE TABLE "/BI0/B0000103000" ("REQUEST" SAPDB6VARCHAR(000030) DEFAULT ' ' NOT NULL, "DATAPAKID" SAPDB6VARCHAR(000006) DEFAULT '000000' NOT NULL, "PARTNO" INTEGER DEFAULT 0 NOT NULL, "RECORD" INTEGER


DEFAULT 0 NOT NULL, "/BIC/ZFABSHPTO" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/ZEANUPC" SAPDB6VARCHAR(000018) DEFAULT ' ' NOT NULL, "/BIC/ZCOORDER" SAPDB6VARCHAR(000012) DEFAULT ' ' NOT NULL, "/BIC/ZREGION" SAPDB6VARCHAR(000003) DEFAULT ' ' NOT NULL, "/BIC/ZDISTR_CH" SAPDB6VARCHAR(000002) DEFAULT ' ' NOT NULL, "CALDAY" SAPDB6VARCHAR(000008) DEFAULT ' ' NOT NULL, "/BIC/ZME_STATU" SAPDB6VARCHAR(000002) DEFAULT ' ' NOT NULL, "/BIC/ZCRMEM_VA" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "CURRENCY" SAPDB6VARCHAR(000005) DEFAULT ' ' NOT NULL, "/BIC/ZCRMEM_QT" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "UNIT" SAPDB6VARCHAR(000003) DEFAULT ' ' NOT NULL, "/BIC/ZINVCD_VA" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "/BIC/ZINVCD_QT" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "/BIC/ZRTNSVAL" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "/BIC/ZRTNSQTY" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "/BIC/ZCOUNTRY" SAPDB6VARCHAR(000003) DEFAULT ' ' NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "RECORD" ) USING HASHING;

If a DDL generation option containing use MDC was chosen or if RSADMIN parameter DB6_MDC_FOR_PSA was set to YES, the following DDL with an ORGANIZE BY clause would be generated:

tab: /BI0/B0000103000 sql: CREATE TABLE "/BI0/B0000103000" ("REQUEST" SAPDB6VARCHAR(000030) DEFAULT ' ' NOT NULL, "DATAPAKID" SAPDB6VARCHAR(000006) DEFAULT '000000' NOT NULL, "PARTNO" INTEGER DEFAULT 0 NOT NULL, "RECORD" INTEGER


DEFAULT 0 NOT NULL, "/BIC/ZFABSHPTO" SAPDB6VARCHAR(000010) DEFAULT ' ' NOT NULL, "/BIC/ZEANUPC" SAPDB6VARCHAR(000018) DEFAULT ' ' NOT NULL, "/BIC/ZCOORDER" SAPDB6VARCHAR(000012) DEFAULT ' ' NOT NULL, "/BIC/ZREGION" SAPDB6VARCHAR(000003) DEFAULT ' ' NOT NULL, "/BIC/ZDISTR_CH" SAPDB6VARCHAR(000002) DEFAULT ' ' NOT NULL, "CALDAY" SAPDB6VARCHAR(000008) DEFAULT ' ' NOT NULL, "/BIC/ZME_STATU" SAPDB6VARCHAR(000002) DEFAULT ' ' NOT NULL, "/BIC/ZCRMEM_VA" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "CURRENCY" SAPDB6VARCHAR(000005) DEFAULT ' ' NOT NULL, "/BIC/ZCRMEM_QT" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "UNIT" SAPDB6VARCHAR(000003) DEFAULT ' ' NOT NULL, "/BIC/ZINVCD_VA" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "/BIC/ZINVCD_QT" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "/BIC/ZRTNSVAL" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "/BIC/ZRTNSQTY" SAPDB6VARCHAR(000017) DEFAULT ' ' NOT NULL, "/BIC/ZCOUNTRY" SAPDB6VARCHAR(000003) DEFAULT ' ' NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "RECORD" ) USING HASHING ORGANIZE BY ( "REQUEST" ); ALTER TABLE "/BI0/B0000103000" LOCKSIZE BLOCKINSERT;

6.3 Exporting the Source Database For SAP Business Information Warehouse 3.1 Content and higher releases, you can easily export the source database using the SAP installation tool SAPinst. For example, on the Welcome screen of SAPinst of EhP 1 for SAP NetWeaver BW 7.0, choose Software Life-Cycle Options –> System Copy. Select the source database and SAP system type and execute the export steps in the corresponding folder (see Figure 34 and Figure 35).


Figure 34: Source database export with EhP 1 for SAP NetWeaver 7.0


Figure 35: Source database export with EhP 1 for SAP NetWeaver 7.0

R3load-based database export is not fully supported for SAP Business Information Warehouse 3.0B. It is, therefore, recommended to export the source database with the SAPinst tool of R/3 Enterprise 4.7 Service Release 1 instead.

6.3.1 Hints and Tips for the Export

You find detailed information about optimizing the export of the source database in [11]. Therefore, only the handling of SAP NetWeaver BW temporary tables is discussed in this document.

Handling of SAP NetWeaver BW Temporary Tables and Views If during test migrations you encounter any problems with SAP NetWeaver BW temporary tables or views, you can drop them on the source system before you export the database. To drop SAP NetWeaver BW temporary tables and views execute report SAP_DROP_TMPTABLES with the selections shown in Figure 36. If you want to continue


using the source system after the export, this might have a small short-term impact on the performance because temporary SID tables (type 06) and temporary hierarchy tables (type 02) have to be recreated. In general, these types of SAP NetWeaver BW temporary tables are created once, put into a temporary table pool, taken from the pool when needed and returned to the pool after usage.

Figure 36: Report SAP_DROP_TMPTABLES

6.4 Creation and Import of the Target Database

Before you perform a multi-partition IBM DB2 for LUW database installation, make sure that you carefully read the DB2 documentation and the SAP installation guides. There are a number of prerequisites that have to be fulfilled, for example:

You have to reserve enough TCP/IP ports for the communication between the database partitions.

On UNIX systems, several file systems have to be mounted via NFS on all servers where the database is installed.

On UNIX systems, the users and groups created for the SAP system and the DB2 database during installation must have the same ID numbers on all servers where the database is installed

6.4.1 SAP NetWeaver 7.0 and EhP 1 for SAP NetWeaver 7.0

You create and import the target database using the SAPinst tool. Select the type of system that you want to install and perform the installation steps in the corresponding folder as described in the SAP installation documentation (see Figure 37 and Figure 38 for the SAPinst tool of EhP 1 for SAP NetWeaver 7.0).


Figure 37: EhP 1 for SAP NetWeaver 7.0 - Target system installation


Figure 38: EhP 1 for SAP NetWeaver 7.0 - Target system installation steps

You provide all required input, including the directory where the migration export resides and the migration key, and start the installation. The installation proceeds until after the database manager configuration has been updated. Then, an exit for the installation of additional database partitions is provided, as shown in Figure 39.


Figure 39: EhP 1 for SAP NetWeaver 7.0 - Exit to create additional database partitions

If you want to create a multi-partition IBM DB2 for LUW database, cancel the installation at this step and create the additional database partitions on the servers where they should reside. You create the additional partitions with the task Additional Database Partitions of the SAPinst tool, as shown in Figure 40. You have to run the SAPinst tool on every database partition server.


Figure 40: SAP NetWeaver 7.0 - Creation of additional database partitions

Afterwards, you continue the first SAPinst session to complete the target system installation. When the screen shown in Figure 39 is displayed again, you continue with OK. On the next screen, you assign the database partition groups for the SAP NetWeaver BW tables to the database partitions, as shown, for example, in Figure 41. According to the recommended layout, distribute the database partition groups for fact, DataStore object, and PSA tables over the database partitions 1 to n while the database partition group for dimension tables should reside on database partition 0 only.


Figure 41: SAP NetWeaver BW 7.0 - Mapping of database partition groups to partitions

The installation continues with the creation of the database.

6.4.2 SAP NetWeaver ‘04

You create and import the target database with the SAPinst tool, as shown in Figure 42 for a Unicode system.


Figure 42: SAP NetWeaver '04 – Target system installation

During the dialog phase of SAPinst, you have to specify if you want to perform a standard installation or a system migration with R3load as shown in Figure 43. Choose Standard System Copy/Migration (R3load-Based) and continue.


Figure 43: SAP NetWeaver '04 – Database installation method

During the dialog phase of SAPinst, you are prompted whether to install a single or a multi-partition system. If you decide to install a multi-partition system, you can add database partitions as shown in Figure 44.


Figure 44: SAP NetWeaver '04 – Adding database partitions

On the next screen, you assign the database partition groups to the database partitions (see Figure 41). In the following screen, you assign the host names of the database servers to the database partitions (see Figure 45).


Figure 45: SAP NetWeaver '04 - Mapping of database partitions to servers

If you install more than one database partition server, you have to run the SAPinst tool on each server. To do this, an exit step is provided after the database instance has been created, as shown in Figure 46.


Figure 46: SAP NetWeaver '04 – Exit step for installing additional database partition servers

6.4.3 SAP Business Information Warehouse 3.0B and 3.1 Content

You should use the SAPinst tool from the 6.20/6.40 Patch Collection for the installation. With the 6.20/6.40 Patch Collection the installation of the target system works in the same way as described for SAP NetWeaver ‘04. For more information, see the SAP Notes 967555 and 967556.

6.4.4 Handling of Database Partition Groups in Multi-Partition Installations

As shown in the previous section, at some point during the target system installation, you define the distribution of the DB2 database partitions groups to the database partitions (Figure 41).

Information about the database partition groups of the source system is stored in the file DBSIZE.XML in the DB/DB6 subdirectory of the export. For each tablespace, it contains the database partition group to which the tablespace belongs in the Nodegroup field of the tablespace XML description (similar as shown in Figure 47).

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE tables SYSTEM "keydb.dtd" >


<tables> <tableset srcid="this file was created by R3szchk.exe"> <table name="tDB6_TABLESPACES_DEFAULT " namespaces="DB6"> ...

<row> <fld name="TablespaceName"> <strval> <![CDATA[SAPSID#FACTD]]> </strval> </fld> … <fld name="TablespaceType"> <strval> <![CDATA[FACT]]> </strval> </fld> <fld name="Nodegroup"> <exp> <![CDATA[('NGRP_FACT_'+UPPER(getContextParameter('cpSapSystemName')))]]> </exp> </fld>

</row>

Figure 47: Tablespace information with database partition group in DBSIZE.XML

If you migrate your system from another database platform, DBSIZE.XML only contains the default database partition groups. If your source database is IBM DB2 for LUW and you have defined additional database partition groups there, DBSIZE.XML contains this information.

If you migrate your system from another database platform and you want to implement your own tablespaces and database partition groups in the DB2 target database, you can do so as follows:

The SAPinst tool of SAP NetWeaver 7.0 and higher provides an exit step for the manual creation of tablespaces. In this exit step, you can create your own database partition groups and tablespaces.

For SAP NetWeaver ‘04 and earlier releases, you can add your own database partition groups and tablespaces manually to DBSIZE.XML, for example as shown in Figure 48.

The distribution of database partition groups over database partitions is not defined in DBSIZE.XML but only on the respective SAPinst dialog or directly at database level.

... <row> <fld name="TablespaceName"> <strval> <![CDATA[SAPSID#MYTBSP]]> </strval> </fld> <fld name="TablespaceSize"> <exp>( SWITCH ( getContextParameter('UNICODE') ) : ( CASE (= 'YES') RETURN ( '100' ), CASE (DEFAULT) RETURN ( '100' ) ) )</exp></fld> <fld name="NumberOfContainer">


<strval> <![CDATA[1]]> </strval> </fld> <fld name="TablespaceType"> <strval> <![CDATA[FACT]]> </strval> </fld> <fld name="Nodegroup"> <exp> <![CDATA[('NGRP_MYGRP_'+UPPER(getContextParameter('cpSapSystemName')))]]> </exp> </fld>

</row>

Figure 48: Definition of an additional tablespace and database partition group in DBSIZE.XML

By default, the SAPinst tool proposes to distribute the default database partition groups for fact tables, for DataStore object, and PSA tables (NGRP_FACT_<SAPSID> and NGRP_ODS_<SAPSID>) over all database partitions. We recommend that you do not store large or medium-sized fact and DataStore or PSA data on database partition 0. Database partition 0 contains all SAP BASIS and master data tables and serves as the coordinator partition for all connections to the database, which already results in a high workload on this partition. For more information about the recommended number of database partitions and the recommended table distribution, see [6].

The database partition group for dimension tables resides on database partition 0 only. We strongly recommend that you do not change this setting. Dimension tables should reside only on database partition 0.

6.4.5 Modified R3load Processing during Target Database Import

R3load uses the following input files as shown in Figure 49:

A .TSK file containing the tasks to be processed for all the tables and indexes in the import job

A .STR file containing the structure of the tables and indexes as defined in the ABAP dictionary of the source system

One or more .<nnn> files containing the data to be imported

A .cmd file containing the locations of the data, structure, and task files

The file DDL<DBSYS>.TPL containing the templates for the DDL statements of the target database platform <DBSYS>

One or more .SQL files containing the DDL generated on the source system


Figure 49: Input files to R3load for the import of the target database

The standard R3load processing reads the structure of the tables and indexes from the .STR file and generates the DDL of the tables and indexes from the structure and the templates that are stored in DDL<DBSYS>.TPL. With the introduction of the .SQL files, this process has changed. For each table or index to be processed, R3load looks up the DDL for creating it in the .SQL file and executes the DDL if found. Otherwise, R3load creates the table or index based on the .STR file and the statement template.

Let us now return to one of the examples of a migration from Oracle to IBM DB2 for LUW from chapter 6.1 to see how R3load uses the generated DDL:

The following DDL was created for the F fact table:

F Fact Table: tab: /BIC/FBFABCUBE5 sql: CREATE TABLE "/BIC/FBFABCUBE5" ("KEY_BFABCUBE5P" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5T" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5U" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE51" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE52" INTEGER DEFAULT 0 NOT NULL, "/BIC/BCRMEM_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BCRMEM_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_QT" DECIMAL(000017,000003)


DEFAULT 0 NOT NULL, "/BIC/BRTNSVAL" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BRTNSQTY" DECIMAL(000017,000003) DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING;

ind: /BIC/FBFABCUBE5~0 sql: CREATE INDEX "/BIC/FBFABCUBE5~P" on "/BIC/FBFABCUBE5" ("KEY_BFABCUBE5T", "KEY_BFABCUBE51", "KEY_BFABCUBE52", "KEY_BFABCUBE5U", "KEY_BFABCUBE5P") CLUSTER ALLOW REVERSE SCANS;


The task file contains the following entries for the F fact table (where T stands for table creation, D for data import, P for primary key index, and I for additional secondary indexes): T /BIC/FBFABCUBE5 C xeq D /BIC/FBFABCUBE5 I xeq P /BIC/FBFABCUBE5~0 C xeq I /BIC/FBFABCUBE5~01 C xeq I /BIC/FBFABCUBE5~02 C xeq I /BIC/FBFABCUBE5~03 C xeq I /BIC/FBFABCUBE5~04 C xeq I /BIC/FBFABCUBE5~05 C xeq

R3load creates the table "/BIC/FBFABCUBE5" by executing the DDL that is stored for the table in the .SQL file. This means that R3load creates the table with the correct distribution key.

The next task is to load the data into the F fact table.

By default, there is a task for every table to create the standard primary key index 0. R3load finds the appropriate entry for the index in the .SQL file. With the DDL stored under the entry for index 0, R3load creates the clustered P index that did not exist in the Oracle source database with the correct column order for the DB2 target database. The standard primary key index is not created.

The task file contains no entry for the P index because the index does not exist on the source system. R3load then continues with the indexes 01 to 05. Index 03 is not created


because the respective section in the .SQL file contains no DDL statement. The other indexes are not specific to IBM DB2 for LUW. Therefore, no DDL statements are required for them.

The following DDL was generated for the E fact table:

E Fact Table tab: /BIC/EBFABCUBE5 sql: CREATE TABLE "/BIC/EBFABCUBE5" ("KEY_BFABCUBE5P" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5T" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE5U" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE51" INTEGER DEFAULT 0 NOT NULL, "KEY_BFABCUBE52" INTEGER DEFAULT 0 NOT NULL, "/BIC/BCRMEM_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BCRMEM_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_VA" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BINVCD_QT" DECIMAL(000017,000003) DEFAULT 0 NOT NULL, "/BIC/BRTNSVAL" DECIMAL(000017,000002) DEFAULT 0 NOT NULL, "/BIC/BRTNSQTY" DECIMAL(000017,000003) DEFAULT 0 NOT NULL) IN "&location&" INDEX IN "&locationI&" LONG IN "&locationL&" COMPRESS YES PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING; ALTER TABLE "/BIC/EBFABCUBE5" LOCKSIZE ROW;




ind: /BIC/EBFABCUBE5~P sql: CREATE UNIQUE INDEX "/BIC/EBFABCUBE5~P" on "/BIC/EBFABCUBE5" ("KEY_BFABCUBE5T", "KEY_BFABCUBE51", "KEY_BFABCUBE52", "KEY_BFABCUBE5U",


"KEY_BFABCUBE5P") CLUSTER ALLOW REVERSE SCANS;

The task file contains the following entries for the E fact table (T stands for table creation, D for data import, P for primary key index, and I for additional secondary indexes): T /BIC/EBFABCUBE5 C xeq D /BIC/EBFABCUBE5 I xeq P /BIC/EBFABCUBE5~0 C xeq I /BIC/EBFABCUBE5~01 C xeq I /BIC/EBFABCUBE5~02 C xeq I /BIC/EBFABCUBE5~03 C xeq I /BIC/EBFABCUBE5~04 C xeq I /BIC/EBFABCUBE5~05 C xeq I /BIC/EBFABCUBE5~P C xeq

R3load creates the table "/BIC/EBFABCUBE5" by executing the DDL that is stored for the table in the .SQL file. This means that R3load creates the table with the correct distribution key.

The next task is to load the data into the F fact table.

In the .SQL file, the entries for the standard primary key index 0 and the indexes 01 and 03 contain no DDL statement. Therefore, these indexes are not created.

The indexes 02, 04, and 05 are not specific to IBM DB2 for LUW. Therefore, no DDL statements are required for them. The indexes are created based on the information in the .STR file.

The entry for the P index contains the DDL statement to create the index in the correct column order in the DB2 database.

In general, indexes are handled in the following way:

For non-existing primary key 0 indexes, an entry without DDL statement is generated. By default, all SAP tables have a primary key index with label 0 that is defined over the columns marked as key columns in the ABAP dictionary. However, for SAP NetWeaver BW fact tables, this index is not created in the database. Standard R3load processing would create it based on the information in the .STR file. When R3load processes the index, it executes the empty DDL statement that is stored in the .SQL file and thus does not create the index.

For indexes that do exist on the source database but are not required in the DB2 target database, entries without a DDL statement are generated, too. The indexes are not created in the database. During SAP NetWeaver BW post processing steps, the information about tables and indexes in the ABAP dictionary is adapted to the implementation of the tables and indexes in the database, that is, indexes that do not exist in the target database are deleted from the ABAP dictionary.

The DDL statements for indexes that are required in the DB2 target database but that do not exist in the source database is appended to the sql section for the standard primary key 0 index. During SAP NetWeaver BW migration post


processing steps, all indexes that exist in the database but not in the dictionary are added to the ABAP dictionary.

If a table has a clustered index, you do not have to create it before the data is imported into the table. When data is inserted into an empty table, the DB2 database takes no specific steps to preserve the clustering order.

6.4.6 Hints and Tips to Speed up the Import

You find detailed information about all possibilities to speed up the import in [11]. Therefore, this topic is not further discussed here.

6.5 SAP NetWeaver BW Migration Post Processing Steps After the database import, you have to run report RS_BW_POST_MIGRATION on the target system in the background. The following variants are defined for the report:

Variant SAP&POSTMGR You use this variant if the database platform has not changed, that is in the case of a non-Unicode to Unicode migration.

Variant SAP&POSTMGRDB You use this variant if the database platform has changed. It includes a number of additional repair operations that are necessary because of the SAP NetWeaver BW implementation differences on the different database platforms.

The two variants are defined for background processing only. We recommend that you always run the report in background because it might run for several hours.

Report RS_BW_POST_MIGRATION executes the following post migration tasks when called with variant SAP&POSTMGRDB:

Step 1: Invalidation of SAP NetWeaver BW programs that were generated on the source system containing database-specific code

In SAP NetWeaver BW, templates are used to generate programs for certain maintenance operations when InfoCubes, DataStore objects and PSA tables are created. These programs can contain database-specific code that is no longer valid on the target database platform. During post processing, these programs are invalidated so that they will be regenerated the next time the operations are executed in the new target system.

Step 2: Adaptation of the information about tables and indexes in the ABAP dictionary to the implementation in the target database for InfoCubes and aggregates

If R3load uses the DDL stored in .SQL files to create tables and indexes, this can lead to inconsistencies between the information about the tables and indexes that is stored in ABAP dictionary and the implementation of the tables and indexes in the database. This post processing step adapts the information in the ABAP dictionary about tables and indexes to the implementation of the tables and indexes in the database. Indexes that do not exist in the target database are deleted from the ABAP dictionary. Indexes that only


exist in the target database but not in the ABAP dictionary are created in the ABAP dictionary. For indexes with a different structure or different uniqueness properties in the database than in the ABAP dictionary, the ABAP dictionary information is adapted to the implementation in the database. This step only applies to InfoCube, aggregate fact, and dimension tables. DataStore object and PSA tables are not included.

Step 3: Generation of target database-specific DBDIFF entries

The table DBDIFF defines divergences in the implementation of tables and indexes from the SAP default. This post processing steps creates the necessary entries in DBDIFF for the target database platform.

Step 4: Generation of new PSA versions

On some database systems, range-partitioned PSA tables have an additional partitioning column PARTNO that PSA tables in DB2 databases do not have. During migration, PSA tables that have a PARTNO column in the source database are created with the PARTNO column in the DB2 target database. During this post processing step, all empty PSA tables that have a PARTNO column are dropped and recreated without PARTNO. Furthermore, the ABAP programs accessing the PSA tables are re-created. For PSA tables containing data, a new PSA version without the PARTNO column is created. Information about PSA table versions is stored in the SAP NetWeaver BW management tables.

For this step to be successful, the source systems from which data is loaded into the PSA tables need to be online and accessible. This is a crucial post-processing step. If it fails, no data can be loaded from the source systems into PSA tables that have not been processed in this step.

Step 5: Deletion of SAP NetWeaver BW temporary tables

SAP NetWeaver BW temporary tables from the source system cannot be used in the target system. In this migration post processing step they are deleted with report SAP_DROP_TMPTABLES.

Step 6: Repair of the InfoCube fact views

A UNION ALL view is defined on the F and the E fact table of each InfoCube and aggregate. Since the ABAP dictionary cannot handle UNION ALL views, these views are created incorrectly in the target database during the migration. This is corrected during migration post processing steps by executing a report that drops and recreates these views correctly.

Step 7: Other database-specific repairs

For IBM DB2 for LUW as target database platform, the following actions are performed:

Adapting the ABAP dictionary entries for DataStore object tables to the implementation in the target database:

o Change uniqueness information for unique indexes in the source database that have been created non-unique in the DB2 target database


o Add index RDR for write-optimized DSO tables to the ABAP dictionary and set the flag that the table has no standard primary index

Adding the correct options for collecting statistics on SAP NetWeaver BW tables. For InfoCube fact and dimension tables, and for master data tables, distribution statistics and sampled detailed index statistics are collected. This information is stored in table DBSTATC. During this migration post-processing step, the required entries in table DBSTATC for the tables affected are created. Note that this information is only used when automatic statistics collection of IBM DB2 for LUW is turned off.

Adapting the SAP NetWeaver BW InfoCube meta data when range-partitioned fact tables have been converted to using MDC.

As of SAP NetWeaver BW 7.0 Support Package 23 (EhP 1 for SAP NetWeaver BW 7.0 Support Package 6), report RS_BW_POST_MIGRATION checks the consistency of the database as the first step before executing steps 1 to 7. For IBM DB2 for LUW, the distribution keys and indexes of the BW object tables are checked. Inconsistencies that are detected are written to the job log and are repaired if possible.

When you call this report with variant SAP&POSTMGR report RS_BW_POST_MIGRATION, only the following tasks are executed:

Step 5: Deletion of SAP NetWeaver BW temporary tables

Step 6: Repair of InfoCube fact views

It is very important that all migration post-processing steps are executed successfully. Otherwise, unexpected errors can occur in the migrated system and it will not be usable. Report RS_BW_POST_MIGRATION writes a log file and a spool file that you should scan carefully for error messages.

7. Tools for Checking Consistency of the IBM DB2 for LUW Target Database

There are a number of transactions and reports available that you can execute to make sure that the DB2 database and the ABAP dictionary of your migrated system are in a consistent and correct state. They are discussed briefly in the following sections.

7.1 Report RS_BW_POST_MIGRATION

As of SAP NetWeaver BW 7.0 Support Package 23 (EhP 1 for SAP NetWeaver BW 7.0 Support Package 6), the report checks whether SAP NetWeaver BW object tables have been correctly implemented. In particular, it checks distribution keys and indexes. The output is written to the log file of report RS_BW_POST_MIGRATION.


7.2 Transaction DBACOCKPIT Call transaction DBACOCKPIT and select Diagnostics - Missing Tables and Indexes in the navigation frame of the DBA Cockpit. Tables and indexes that do not exist in the database but in the ABAP dictionary and vice versa are displayed. You can use this transaction to detect inconsistencies between the database and the ABAP dictionary after SAP NetWeaver BW migration post processing has completed. If you changed the database platform before post migration, there usually are inconsistencies due to the different implementations of SAP NetWeaver BW tables and indexes on the different database platforms (Figure 50). After post migration, there should be no more inconsistencies (Figure 51). If you did not change the database platform, also before post migration no inconsistencies should exist. When selecting the menu item, always the saved state of the last execution is displayed. To determine the current state, choose Refresh.

Figure 50: The DBA Cockpit: Missing tables and indexes before post migration


Figure 51: The DBA Cockpit: Missing tables and indexes after post migration

7.3 Checking the Distribution Keys of SAP NetWeaver BW Tables

The following function modules check the distribution keys for fact, PSA and DataStore tables:

RSDU_CHKREP_PKEY_ALL_CUBES_DB6 This function module checks the distribution key of all InfoCube and aggregate F and E fact tables

RSDU_CHKREP_PKEY_ALL_ODS_DB6 This function module checks the distribution key of the DataStore activation queue, active and change log tables

RSDU_CHKREP_PKEY_ALL_PSA_DB6 This function module checks the distribution key of all PSA tables.


For more information about the usage of these function modules and the output they produce, see SAP Note 648432. If there are many errors, it is likely that R3load has not used the DDL statements that were generated by report SMIGR_CREATE_DDL.

7.4 SAP NetWeaver BW Transaction RSRV You can use transaction RSRV to check the indexes of single InfoCubes and their aggregates (Figure 52). Select the item ―Database Indices of an InfoCube and its Aggregates‖ from the menu tree on the left side and draw it to the right frame. By double-clicking the InfoCube parameter, the available InfoCubes are displayed. After you have selected an InfoCube, choose Execute to run the test for this InfoCube and its aggregates. A report with the check results, as shown in Figure 53, is displayed.

Figure 52: RSRV: Checking database indexes of an InfoCube and its aggregates


Figure 53: RSRV: Checking database indexes of an InfoCube and its aggregates - Result

8. Solutions and Workarounds for Potential Problems and Known Issues

8.1 Important SAP Notes Before you start a migration, make sure that you check the following SAP Notes:

777024: BW 3.0 and BW 3.1 System Copy (supplementary note)

771209: NW04: System copy (supplementary note)

888210: NW 7.0: System copy (supplementary note) Each note contains a database-specific section with references to relevant enhancements and corrections. These SAP Notes are regularly updated. We recommend that you apply the corrections listed in these SAP Notes to avoid the problems discussed in the following sections.


8.2 Uneven Data Distribution in Multi-Partition IBM DB2 for LUW Databases

You imported data into a multi partition DB2 database and distributed fact, DataStore object and PSA tables over database partitions 1 to n. After the import, you notice that some database partitions contain a lot more data than others.

Usually, this situation indicates that the distribution keys of the distributed tables are not correct, which can happen if R3load does not use the DDL statements generated by report SMIGR_CREATE_DDL when creating the tables. This can have several reasons:

The .SQL files are not stored in the correct location (DB/DB6 subdirectory of directory containing the source system export).

The file access permissions prevent R3load from reading the files (the <sapsid>adm user needs read access).

The file names do not correspond to the data classes where the tables reside (R3load reads the DDL statements for tables and indexes in data class DFACT from DFACT.SQL, etc.). Especially, if you want to move tables to new data classes, you have to make sure that the DDL statements are available in a .SQL file with the name of the new data class.

In most cases, you notice the problem already during the data import. Without .SQL files, R3load creates - when loading the data - unique primary key indexes on F fact tables that often results in duplicate key errors. If you detect this problem after the import, you cannot easily repair it. You have to drop the affected tables and repeat the import.

During R3load processing, you can check that the generated DDL is used by doing one of the following:

Check the R3load log file. It contains a warning message if there is no file with DDL statements to be applied available.

You can perform a few health checks: after one or a few tables in the task file have been processed, run the db2look tool of IBM DB2 for LUW and compare the output to the DDL in the .SQL files.

After the import, we recommend that you always execute the following function modules in the target system to ensure that all distribution keys are correct:

RSDU_CHKREP_PKEY_ALL_CUBES_DB6

RSDU_CHKREP_PKEY_ALL_PSA_DB6

RSDU_CHKREP_PKEY_ALL_ODS_DB6

As of SAP NetWeaver BW 7.0 Support Package 23 (EhP 1 for SAP NetWeaver BW 7.0 Support Package 6), these function modules are executed in the database consistency check step of report RS_BW_POST_MIGRATION.


8.3 Missing Database Indexes Reported after RS_BW_POST_MIGRATION

After having executed report RS_BW_POST_MIGRATION, you check for missing tables and indexes in the DBA Cockpit (transaction DBACOCKPIT, Diagnostics Missing Tables and Indexes). These indexes could be, for example:

P indexes of F fact tables (like /BIC/F…~P, /BI0/F…~P, /BIC/F…P, /BI0/F…P) in a SAP NetWeaver 7.0 system

000 or P00 indexes on InfoCube fact or dimension tables (like /BIC/F…~P00, /BIC/E…~P00, /BIC/D…~000, /BI0/F…~P00, /BI0/E…~P00, /BI0/D…~000)

This problem only occurs if you do not follow the recommendations for the minimum required Support Package-Level for a migration to IBM DB2 for LUW. We strongly recommend that you implement the required Support Packages before the migration.

8.4 Report RS_BW_POST_MIGRATION Aborts in the Generation of New PSA Versions

The post migration step Generation of new PSA versions can only be executed successfully if the source system is attached to the SAP NetWeaver BW system. If this is not the case, the report aborts when processing the first transfer structure for which the source system is not accessible.

If you are only doing a test migration where you cannot attach the source systems, or you want to correct this issue later and to make sure that at least all other post migration steps are executed completely, you can generate a new variant for RS_BW_POST_MIGRATION. This new variant omits the generation of new PSA versions and run the report with this variant.

In SAP NetWeaver BW 7.0 Support Package 18, the following options have been added for the generation of new PSA versions:

The option to generate new PSA versions for selected source systems only

The option to generate new PSA versions only for transfer structures that were generated in a specified time interval

These options are needed because the generation of new PSA versions often ran for a very long time. With these new options, the generation of new PSA versions can be split into several runs. PSAs urgently needed can be regenerated first followed by less important ones.

Before you use the migrated system in a production environment, you have to make sure that you have regenerated the PSAs for all source systems that you need in production. Otherwise, the data load from these sources will not be successful.


8.5 Activation of Aggregates or InfoCubes in the Target System Aborts

This error can occur in the following variants:

An SQL error occurs that indicates that the tablespaces for the tables do not exist.

You did not implement SAP Note 919530. When report SMIGR_CREATE_DDL is executed in the source system, entries in table DDSTORAGE for DB2 were created. These entries contain the names of the tablespaces where the tables resided in the source system. These tablespaces might not exist in the target system. If during InfoCube or aggregate activation in the target system these invalid entries are used, an SQL error occurs. As a workaround, you can delete entries with value ‗DB6‘ in column DBSYSABBR from table DDSTORAGE in the target system directly after the migration.

The InfoCube contains data, and the application log contains the error message ―structure change at field level‖ and the message that a table conversion has to be run.

This can occur on SAP NetWeaver BW 7.0 systems if you did not implement SAP Note 1062348 or if you activated the InfoCube already once before you implemented SAP Note 1062348.

The error only occurs for InfoCubes that used range partitioning in the source system and that were not converted to MDC. As discussed in section 6.2.2, the additional column used as partitioning column in the source database is not deleted in the DB2 target database. In addition, the information that the column exists in the SAP NetWeaver BW metadata in table RSDCUBE is kept. Due to a program error that is corrected by SAP Note 1062348, this information is accidentally deleted when the InfoCube is activated again. The first reactivation completes without error message but deletes the metadata. The second activation tries to remove the partitioning column from the fact tables that require a table conversion if the tables contain data.

You transport an InfoCube definition from a development system to the production system. On the production system, the InfoCube exists and contains data. As soon as the transport is processed, the activation of the InfoCube with the changed definition fails. Again, the error messages are ―structure change at field level‖ and ―table conversion needed‖.

This problem can occur on SAP NetWeaver BW 7.0 for InfoCubes that used range partitioning on the source system. If such an InfoCube is changed and reactivated in the development system and it contains no data, the partitioning column is dropped and the SAP NetWeaver BW metadata is updated accordingly. If the new InfoCube definition is transported to a target system were the InfoCube contains data, the partitioning column cannot be dropped and the InfoCube activation fails. To solve the problem, apply SAP Note 1145297.


These problems do not occur if you follow the recommendations for the minimum required Support Package level for a migration to IBM DB2 for LUW. We strongly recommend that you implement the required Support Packages before the migration.

8.6 Tables with Incorrect IBM DB2 for LUW Features Created for Inactive Aggregates

When report SMIGR_CREATE_DDL is executed on a source system that is not running IBM DB2 for LUW, DDL for aggregates that are not active cannot be generated. The log of report SMIGR_CREATE_DDL contains a message like, for example, the following: ‘Failed to create storage parameters for table: <table name>‘. If the tables for these aggregates have not been properly removed from the ABAP dictionary, they are created in the target database with incorrect distribution key or indexes. This might lead to index errors that are reported in the DBA Cockpit. However, this is not an issue because when the aggregates are reactivated in SAP NetWeaver BW, the tables are dropped and re-created correctly in the DB2 database.

9. Summary In this document, the migration procedure for an SAP NetWeaver BW system and SAP systems based on SAP NetWeaver BW with IBM DB2 for LUW as target database was described in detail. The following list is a summary of the topics that were thoroughly discussed in this document:

The features of IBM DB2 for LUW supported in SAP NetWeaver BW

The layout of SAP NetWeaver BW tables on IBM DB2 for LUW

The steps of the SAP NetWeaver BW system migration process, especially DDL statement generation with report SMIGR_CREATE_DDL and SAP NetWeaver BW migration post processing

Examples for the IBM DB2 for LUW DDL statements generated for BW tables and indexes and options available for influencing the DDL statement generation

The transactions and reports for checking the consistency of the IBM DB2 for LUW target database after a migration

The potential problems and known issues of SAP NetWeaver BW migrations to IBM DB2 for LUW and the solutions and workarounds available for them

10. Literature

[1] SAP SDN – SAP on DB2 for Linux, UNIX and Windows (http://www.sdn.sap.com/irj/sdn/db6)

[2] System copy and migration information in the SAP Developer Network, http://www.sdn.sap.com/irj/sdn/systemcopy

[3] ―System Copy Guide: System Copy for SAP Systems Based on SAP NetWeaver 7.0 SR3 ABAP‖, http://service.sap.com/instguides

http://www.sdn.sap.com/irj/sdn/db6

http://www.sdn.sap.com/irj/sdn/systemcopy

http://service.sap.com/instguides


[4] "Homogeneous and Heterogeneous System Copy for SAP Systems Based on SAP Web Application Server 6.40", http://service.sap.com/instguides

[5] Unicode information in the SAP Developer Network, https://www.sdn.sap.com/irj/sdn/i18n?rid=/webcontent/uuid/c09cb763-f841-2a10-bcb1-

d4cc8973e1eb

[6] ―Database administration Guide: SAP NetWeaver Business Warehouse 7.0 and Higher — Administration Tasks: IBM DB2 for Linux, UNIX, and Windows‖, http://service.sap.com/instguides

[7] SAP NetWeaver Installation: ―SAP NetWeaver 7.0 SR3 ABAP on AIX: IBM DB2 Universal Database for UNIX and Window‖, http://service.sap.com/instguides

[8] ―SAP NetWeaver ‗04 SR1: Installation Guide SAP Business Warehouse 3.5‖, http://service.sap.com/instguides

[9] SAP Installation Guide: SAP Business Information Warehouse Server 3.1 on UNIX: IBM DB2 Universal Database for UNIX and Windows, http://service.sap.com/instguides

[10] Kevin McDonald, Andreas Wilmsmeier, David C. Dixon, W.H. Inmon: "Mastering the SAP Business Information Warehouse", Wiley Publishing Inc., 2002

[11] ―DB2 Optimization Techniques for SAP Database Migration And Unicode Conversion‖, SG24-7774, IBM redbook , http://www.redbooks.ibm.com/

[12] ―Building and Scaling SAP Business Information Warehouse on DB2 ESE‖, SG24-7094, IBM redbook, http://www.redbooks.ibm.com/

[13] IBM Redbook ―SAP Solutions on IBM DB2 V8.2.2 Handbook", SG24-6765, http://www.redbooks.ibm.com/

[14] Marianne Nesiem: " Copying Your SAP/R3 System Across Platforms Using DB2 Universal Database V8 Redirected Restore", http://www7b.software.ibm.com/dmdd/library/techarticle/0308nesiem/0308nesiem.html, July 2003

[15] Andreas Christian: Multi Dimensional Clustering and Deployment in SAP Business Warehouse, http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/20654a07-2ec1-2a10-

1ab2-931f84067976

[16] Carola Langwald: FAQ about Multidimensional Clustering (MDC) for IBM DB2 LUW, http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e07a3f54-

a90d-2d10-38ac-8c7a9c1ac584

11. Appendix - List of Relevant SAP Notes The following list contains the most important SAP Notes related to migration to IBM DB2 for LUW, as of June 2010.


https://www.sdn.sap.com/irj/sdn/i18n?rid=/webcontent/uuid/c09cb763-f841-2a10-bcb1-d4cc8973e1eb

https://www.sdn.sap.com/irj/sdn/i18n?rid=/webcontent/uuid/c09cb763-f841-2a10-bcb1-d4cc8973e1eb





http://www.redbooks.ibm.com/



http://www7b.software.ibm.com/dmdd/library/techarticle/0308nesiem/0308nesiem.html

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/20654a07-2ec1-2a10-1ab2-931f84067976

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/20654a07-2ec1-2a10-1ab2-931f84067976

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e07a3f54-a90d-2d10-38ac-8c7a9c1ac584

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e07a3f54-a90d-2d10-38ac-8c7a9c1ac584


771209: NW04: System copy (supplementary note)

777024: BW 3.0 and BW 3.1 System Copy (supplementary note)

888210: NW2004s: System copy (supplementary note)

1475318: DB6:Fixes and new DDL generation options in SMIGR_CREATE_DDL

1450612: DB6: Fixes and new options for SMIGR_CREATE_DDL

1399649: DB6: Abort in report SMIGR_CREATE_DDL

1397192: DB6: Migration adjustment of DataStore object indexes

1376813: DB6: Database consistency checks after BW migration

1329275: DB6: Corrections SMIGR_CREATE_DDL for SAP NW 7.1x

1324665: SMIGR_CREATE_DDL: save list of generated .SQL files

1309055: DB6: SMIGR_CREATE_DDL generates corrupt CREATE TABLE command

1281430: DB6: Check notes needed for SAP NW BW system copy to DB6

1167138: DB6: Row compression in BI migrations from other platforms

1150148: DB6: BI Migration: Range-part. to MDC: RSDCUBE not updated

1145297: Activation of transported InfoCube fails

1062348: DB6: InfoCube activation fails

1049456: DB6: Index errors reported in DB02 after migration to DB6

1023410: DB6: BW Migration: Conversion of range partitioning to MDC

1025454: Error activating DataStore/InfoCube/DTP with DB2 9

1010353: DB6: ‚COMPRESS NO‘ in output of SMIGR_CREATE_DDL

1000382: DB6: MDC for PSA tables activated automatically in BW 3.x

971135: DB6: Changes in Multi-dimensional Clustering

948780: Incorrect indexes in ABAP dictionary after post-migration

933610: Heterogeneous system migration follow-on for Note 884124

919530: Error in aggregate activation after heterogeneous SAP NetWeaver BW system copy

917571: ABAP short dump in report SAP_..._DBSTATC_DB6

894290: DB6: SQL error -104 during R3load import in BW migr.

884124: Cube activation terminates after heterogeneous system migration

880219: DB6: Het. System Copy – Changes in DDL creation for indexes

858220: DB6: BW migr.: Changes in DDL creation for clustered indexes

833924: DB6: Migration: SQL generation fails for FACT tables

822819: Corrections for heterogeneous system copy

656491: How to migrate a SAP BW 3.x system to DB6

454173: DB6: R3load migration accelerated through CLI LOAD

799745: DB6: R3load error message "statement text too long"

780179: DB6: R3load option ' -nolog' results in termination

827805: DB6: No LOAD for pool tables

822251: DB6: Performance problems during R3laod export

677447: INST: System Copy for SAP Systems based on SAP WebAS 6.30

799465: Datamart on partitioned InfoCube returns SQL Syntax Error

548016: Conversion to Unicode

Documents

Heterogeneous System Copy for an SAP NetWeaver BW and SAP ... · Heterogeneous System Copy for an SAP NetWeaver BW and SAP Business Information ... ABAP dictionary. ... EhP 1 for