IBM Heterogeneous SAP SysCopy To DB2

Heterogeneous SAP NetWeaver BI System Copy to IBM DB2 for Linux, UNIX and Windows
IBM SAP DB2 LUW Development
Heterogeneous SAP NetWeaver Business Intelligence (BI) System Copy to IBM DB2 for Linux, UNIX and Windows
Version 1.0
Brigitte Blser
IBM SAP DB2 for Linux, UNIX and Windows Development, IBM Lab Bblingen
-1 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
Summary
Heterogeneous SAP system copies, i.e. migrations of SAP systems to other database platforms or operating systems, are always a big effort for large databases. Migrations of SAP NetWeaver Business Intelligence (BI) systems are usually the most complex. This is because, to get a maximum of performance on each database platform, SAP NetWeaver BI makes use of different database specific features that cannot be easily mapped to each other and that are not explicitly represented in the SAP data dictionary. The SAP migration procedure for SAP NetWeaver BI contains additional steps to cope with this problem. This document describes the details of the SAP NetWeaver BI migration procedure with focus on IBM DB2 for Linux, UNIX and Windows as the target database platform. The intended audiences are SAP migration consultants involved in customer migration projects of SAP NetWeaver BI systems to IBM DB2 for Linux, UNIX and Windows.
Version 1.0 2007-07-24
Table of Contents
Summary ......................................................................................................................... 2 Table of Contents................................................................................................................ 3 List of Figures ..................................................................................................................... 5 1. Introduction............................................................................................................. 6 2. SAP BI information model ..................................................................................... 7 2.1 SAP BI information model elements .................................................................. 7 2.2 Mapping of information model elements to database tables .............................. 9 2.2.1 PSA ............................................................................................................. 9 2.2.2 DataStore Objects ....................................................................................... 9 2.2.3 InfoCubes and aggregates ......................................................................... 10 2.2.4 Other SAP BI database tables ................................................................... 12 3. SAP BI implementation on DB2 for Linux, UNIX and Windows ....................... 12 3.1 Support of DPF ................................................................................................. 12 3.2 Support of clustered indexes............................................................................. 14 3.3 Support of multi-dimensional clustering (MDC).............................................. 15 3.4 Support of DB2 9 row compression (deep compression) ................................. 16 3.5 Detailed SAP BI table layout on DB2 LUW .................................................... 17 3.5.1 PSA tables................................................................................................. 17 3.5.2 DataStore object tables ............................................................................. 17 3.5.3 InfoCube and aggregate tables.................................................................. 18 3.6 Differences to SAP BI implementations on other database platforms ............. 20 4. Issues of SAP BI system migrations..................................................................... 20 4.1 Issues related to size limits ............................................................................... 21 4.2 Issues related to database specific features and layout differences .................. 22 5. Steps of a heterogeneous SAP system copy ......................................................... 23 6. Steps of a heterogeneous SAP BI system copy .................................................... 25 6.1 Generation of the DDL for the target database ................................................. 27 6.1.1 DDL examples for migrations from Oracle to DB2 LUW ....................... 28 6.2 Exporting the source database .......................................................................... 45 6.2.1 Hints and Tips for the Export.................................................................... 46 6.3 Creation and import of the target database ....................................................... 47 6.3.1 SAP NetWeaver 2004s ............................................................................. 47 6.3.2 SAP NetWeaver 04.................................................................................. 51 6.3.3 SAP BW 3.0B and 3.1 Content................................................................. 56 6.3.4 Handling of database partition groups in multi-partition installations ..... 56 6.3.5 Modified R3load processing during target database import ..................... 58 6.3.6 Hints and tips to speed up the import........................................................ 63 6.4 SAP BI migration post processing.................................................................... 64 7. Tools for checking consistency of the DB2 LUW target database ....................... 66 7.1 Transaction DBACOCKPIT ............................................................................. 66 7.2 Checking the partitioning key of distributed SAP BI tables............................. 68 7.3 SAP BI transaction RSRV ................................................................................ 69 -3 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
Heterogeneous SAP NetWeaver BI System Copy to IBM DB2 for Linux, UNIX and Windows 8.
Potential problems, known issues and solutions / workarounds........................... 70 Important SAP notes ......................................................................................... 70 Uneven data distribution in multi-partition DB2 systems ................................ 71 Missing database indexes reported after RS_BW_POST_MIGRATION ........ 72 RS_BW_POST_MIGRATION aborts in Generation of new PSA versions. 72 Activation of aggregates or InfoCubes in the target system aborts .................. 73 Tables with incorrect DB2 features created for inactive aggregates ................ 74 9. Conclusion ............................................................................................................ 74 10. Literature............................................................................................................... 74 Appendix A - List of relevant SAP notes ......................................................................... 76 About the Author .............................................................................................................. 78 Copyrights, Trademarks & Disclaimer ............................................................................. 79 8.1 8.2 8.3 8.4 8.5 8.6
Version 1.0 2007-07-24
List of Figures
Figure 1: Data flow in SAP BI............................................................................................ 9 Figure 2: SAP BI extended star schema ........................................................................... 11 Figure 3: SAP BI database layout on DB2 LUW with one database partition ................. 13 Figure 4: SAP BI on DB2 LUW layout with multiple database partitions....................... 14 Figure 5: MDC table ......................................................................................................... 15 Figure 6: Steps of a heterogeneous SAP system copy...................................................... 24 Figure 7: SAP export directory structure for target DB platform DB2 LUW .................. 25 Figure 8: Steps of a heterogeneous SAP BI system copy................................................. 26 Figure 9: Report SMIGR_CREATE_DDL....................................................................... 27 Figure 10: Source Database Export with SAP NetWeaver '04 SAPinst........................... 45 Figure 11: Report SAP_DROP_TMPTABLES................................................................ 46 Figure 12: SAP NetWeaver 2004s - ABAP target system installation............................. 48 Figure 13: SAP NetWeaver 2004s - Exit for creating additional database partitions ...... 49 Figure 14: SAP NetWeaver 2004s - Creation of additional database partitions............... 50 Figure 15: SAP NetWeaver 2004s - Default mapping of database partition groups to partitions ................................................................................................................... 51 Figure 16: SAP NetWeaver '04 Target system installation ........................................... 52 Figure 17: SAP NetWeaver '04 Database installation method ..................................... 53 Figure 18: SAP NetWeaver '04 Adding database partitions......................................... 54 Figure 19: SAP NetWeaver '04 - Mapping of database partitions to servers ................... 55 Figure 20: SAP NetWeaver '04 Exit for installing additional database partition servers ................................................................................................................................... 56 Figure 21: Tablespace information with database partition group in DBSIZE.XML ...... 57 Figure 22: Defining additional tablespaces and database partition group in DBSIZE.XML ................................................................................................................................... 58 Figure 23: Input files to R3load for importing the target database................................... 59 Figure 24: DB6COCKPIT: Missing tables and indexes before post migration ............... 67 Figure 25: DB6COCKPIT: Missing tables and indexes after post migration .................. 68 Figure 26: RSRV: Checking database indexes of an InfoCube and its aggregates .......... 69 Figure 27: RSRV: Checking database indexes of an InfoCube and its aggregates - Result ................................................................................................................................... 70
Version 1.0 2007-07-24
1. Introduction
Heterogeneous system copies of SAP BI systems (SAP Business Warehouse (BW) or SAP NetWeaver Business Intelligence (BI)) or systems based on them, like SAP SEM and SAP SCM, are more complicated than migrations of other SAP systems. This is because these products make use of database platform specific features to get a maximum of performance for data warehouse operations. The most prominent example for this is partitioning. For several database platforms, for example Informix, Oracle and DB2 for zSeries, SAP BI supports range partitioning in the slightly different implementations available on these platforms. For DB2 for Linux, UNIX and Windows (DB2 LUW), SAP BI support hash partitioning and multi-dimensional clustering (MDC). This results in database specific properties of tables and indexes that are not available to the SAP migration tool R3load because they are not contained in the information exported from the SAP data dictionary of the source system. Additionally, there are a few differences in the structure of tables and the number and structure of secondary indexes for SAP NetWeaver BI objects on the different database platforms. R3load cannot handle this either. When creating the tables and indexes in the target database it relies on the structure information from the SAP data dictionary of the source database, and creates the tables and indexes exactly as defined there. However, when migrating a SAP BI system 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 required for the target database platform. To handle this, additional processing steps have been 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 presents the details of the migration procedure for SAP BI system releases greater or equal to SAP BW 3.0B, including SAP NetWeaver '04 BI and SAP NetWeaver 2004s BI, with focus on DB2 for Linux, UNIX and Windows as the target database platform. Intended audiences are SAP migration consultants performing heterogeneous system copies of SAP BI systems to DB2 LUW and performing non-Unicode to Unicode migrations of SAP BI systems running on DB2 LUW. It starts with a brief introduction into the SAP BI information model and the implementation of SAP BI on DB2 LUW. It discusses the specific problems of SAP BI system migrations. It continues with an overview of the steps required for a heterogeneous SAP system copy with R3load and introduces the additional steps that have to be executed for SAP BI and Sap BI based systems to handle database specific features and layouts. It explains the steps 'SQL generation', export of the source database, installation and import of the target database, and SAP BI migration post processing in detail, concentrating on aspects that are relevant for DB2 LUW as target database platform. It provides general hints and tips for speeding up database export and DB2 LUW specific recommendations for database import. It shows transactions and reports for checking the consistency of the DB2 target database after the migration. The migration procedure described here is released for SAP BI releases greater or equal to SAP BW 3.0B, including SAP NetWeaver '04 BI and SAP NetWeaver 2004s BI, and -6 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
to systems based on such releases, like SAP SCM and SAP SEM. It applies to all migrations that require R3load. This includes migrations where the database platform changes and migrations from a non-Unicode to a Unicode database on the same database platform. Releases older than SAP BW 3.0B cannot be migrated with this method. The latest information about required support packages and patches is contained in SAP note 777024 for SAP BW 3.0B and 3.1 Content, SAP note 771209 for SAP NetWeaver '04 BI, and SAP note 888210 for SAP NetWeaver 2004s BI. The following terminology is used in this document: IBM DB2 for Linux, UNIX and Windows is referred to as DB2 LUW or DB2. DB2 without reference to an operating system platform always refers to DB2 LUW. SAP BI is used to refer to SAP NetWeaver BI and previous releases of SAP BW, if the specific release is not relevant. Otherwise the official product name SAP NetWeaver 2004s BI, SAP NetWeaver '04 BI, SAP BW 3.0B, SAP BW 3.1 Content, SAP BW 2.0B, or SAP BW 2.1C is 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 BI information model

This chapter briefly introduces the SAP BI information model. For details about the SAP BI architecture and the information model please refer to [10]. The SAP BI information model supports the following conceptual layers of data warehousing: Multi-dimensional models, which enable views of data required for analytics. Operational data store, to hold current data updates from the operational transaction systems of the business. Data warehouse, to hold transformed and accurate data that has been integrated from the business processes across the enterprise to enable business decisionmaking.
2.1 SAP BI 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 may 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 BI distinguishes between two types of data used in analysis: -7 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
Key figures: sales revenue, fixed costs, sales quantity, or number of employees, etc. 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. InfoSource: InfoObjects that belong together logically, from a business point of view, are grouped into InfoSources. DataStore: DataStore objects (formerly ODS objects) describe consolidated datasets from one or several InfoSources. 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. They are very similar to the automatic summary tables available in DB2 but are implemented using regular database tables. PSA, DataStore objects, and 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 BI 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 flow of data in SAP BI. Data is normally loaded into a PSA first, and from there into DataStore objects and InfoCubes. It is also possible to directly load data into DataStore objects and InfoCubes, and from DataStore objects into InfoCubes. Data is loaded into PSA, DataStore, and InfoCubes through InfoPackages. An InfoPackage describes the data to be loaded from a source system, the data targets and how the data is to be processed. When 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.
Version 1.0 2007-07-24
Figure 1: Data flow in SAP BI
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, plus the three additional columns request ID, data package and record number that form the primary key. 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, it does not have to be extracted from the source systems again. PSA table names consist of a prefix enclosed in '/', a 'B' and a generated 10 digit number, for example /BIC/B0000176000. 2.2.2 DataStore Objects DataStore objects (formerly ODS objects) consist of key fields and data fields. Both field types are InfoObjects. The key fields of DataStore objects are usually characteristics InfoObjects (for example, order number). The data fields are usually key figure InfoObjects (for example, order quantity). At the database level, DataStore objects can consist of up to three tables: Active table: the data is used for reporting and delta update into 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. Users can define additional indexes on DataStore objects that are created on the active table to speed up reporting. The table name consists of a prefix enclosed in '/' followed by the letter -9 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
'A', the name of the DataStore object and '00', for example /BIC/AMYDSOBJ00 or /BI0/AMYDSOBJ00. Activation queue: This table contains data that is new or modified since the last activation. It is not yet available for reporting and delta update into data targets. It has the columns of the active table, plus the three additional columns request ID, data package and record number that form the primary key. The table name consists of a prefix enclosed in '/' followed by the letter 'A', the name of the DataStore object and '40' (for example /BIC/AMYDSOBJ40 or /BI0/AMYDSOBJ40). Change log: This table is used for the delta update from the DataStore object into other DataStore objects or InfoCubes. It records new data and changes to the existing active data of the DataStore object. It has the columns of the active table, plus the three additional columns request ID, data package and record number that form the primary key. The table name is constructed like a PSA table name. Up to and including SAP NetWeaver '04, SAP BI provides two types of DataStore objects: Standard DataStore objects consist of all three tables. When loading data into a standard DataStore object it is first inserted into the activation queue. To make it available for reporting and delta update it has to be activated. DataStore objects for direct update consist of only the active table. Data loaded into a DataStore object for direct update is directly available for reporting and delta update into data targets. With SAP NetWeaver 2004s a new Write-optimized DataStore object is introduced that only consists of the active table with the three additional columns request ID, data package and record identifier, i.e. the table has the structure of a change log. Writeoptimized 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. 2.2.3 InfoCubes and aggregates InfoCubes are represented in the database as a set of relational tables that is arranged according to an extended star schema, as shown in Figure 2.
- 10 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
Figure 2: SAP BI 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 needed for evaluating and reporting on those key figures. Fact tables are the largest tables in star schemas, and may contain billions of entries. Dimension tables are independent of each other. The fact table links the dimension tables and the key figures via 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 BI can have up to 16 dimensions. By default, every InfoCube has the three standard dimensions Data Package, Time, and Unit. The SAP BI 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 table. SIDs are used to keep dimension tables as small as possible, since they can also grow very large. 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 - 11 Copyright IBM Corporation, 2007 All Version 1.0 Rights Reserved. 2007-07-24
status of a request is appropriate, it can be compressed. During SAP BI InfoCube 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. Fact table names consist of a prefix enclosed in '/' followed by the letter 'F' (for the F fact table) or 'E' (for the E fact table) and the InfoCube name (for example /BIC/FMYCUBE, /BI0/FMYCUBE, /BIC/EMYCUBE, /BI0/EMYCUBE). Dimension table names consist of a prefix enclosed in '/' followed by the letter 'D', the InfoCube name and the dimension identifier or number ('P', 'T', U', 1, 2, ... 9, A, ..., D). Examples are /BIC/DMYCUBEP, /BIC/DMYCUBE1, /BI0/MYCUBEP, /BI0/DMYCUBE1. 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, /BI0/F100001, /BIC/E100001, /BI0/E100001). 2.2.4 Other SAP BI 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 a prefix enclosed in / followed by a letter identifying the type of master data table and the name of the InfoObject representing the master data. Examples are /BI0/SCUSTOMER, /BI0/PCUSTOMER, etc. 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 BI temporary tables The SAP BI 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 prefix BI0 enclosed in /, followed by 0, a digit identifying the type of temporary table or view, and an 8 digit number. Examples are /BI0/0600000001, /BI0/02000000002, etc. SAP NetWeaver 2004s BI introduces temporary 0P tables (for example /BI0/0P000000001). SAP BI temporary tables are kept in a pool to be reused, to reduce costly database catalog table creation operations. They can be dropped with report SAP_DROP_TMPTABLES.
3. SAP BI implementation on DB2 for Linux, UNIX and Windows

3.1 Support of DPF
SAP BI makes use of DB2 LUW hash partitioning. PSA, DataStore, and InfoCube and aggregate fact tables can be distributed over several database partitions. The default - 12 Copyright IBM Corporation, 2007 All Version 1.0 Rights Reserved. 2007-07-24
SAPinst installation on DB2 LUW creates a system with one database partition. Additional partitions can be created with the Add Database Partition function of SAPinst (located in folder Database Specific Features). When performing a heterogeneous system copy to DB2 LUW with SAPinst additional database partitions can be created directly. The default installation of SAP BI on DB2 LUW is shown in Figure 3 and consists of four database partition groups: 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 InfoCubes and aggregates NGRP_ODS_<SAPSID> for the tablespace containing PSA and DataStore object tables
Figure 3: SAP BI database layout on DB2 LUW with one database partition
In multi-partition installations, for keeping database partition 0 small and releasing it from operations executed on large InfoCubes, DataStore objects and PSA tables, it is recommended not to place InfoCube and aggregate fact tables, DataStore object tables and PSA tables on database partition 0. Database partition 0 not only contains the SAP - 13 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
Basis tables and SAP BI dimension and master data tables but also acts as the coordinator partition. A multi-partition database layout is shown in Figure 4. 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.
Figure 4: SAP BI on DB2 LUW layout with multiple database partitions
Large SAP BI installations sometimes implement a more complex partition design with additional database partition groups for large and small aggregates, small and mediumsized InfoCube fact tables located on subsets of the partitions. This optimizes performance if there is a mixture of small, medium-sized and large InfoCubes and DataStore objects but also complicates management. Some customers also decide to put the fact tables of very large InfoCubes into their own data classes and tablespaces. For DB2 LUW releases prior to DB2 9 this avoids that the DB2 size limits are hit for these objects. DB2 hash partitioning distributes the rows of PSA, DataStore object, and InfoCube and aggregate fact tables to one or more database partitions via a partitioning key that is defined when the table is created. The generation of the partitioning keys is hard-coded in the DB2 LUW specific SAP BI coding such that it guarantees an equal distribution of the data over all database partitions. It is also created for PSA, DataStore object and InfoCube and aggregate fact tables that reside on only one database partition.
3.2 Support of clustered indexes

A clustering index is a record based index on one or more columns, which physically organizes the data along this index. Clustering indexes organize the data along one - 14 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
dimension and can thus speed up queries that restrict on this dimension. For a clustering index, DB2 tries to maintain the clustering order but this depends on the free space available on the data pages and is not guaranteed. In SAP BI on DB2 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 database performance feature that has been introduced in DB2 LUW Version 8. MDC allows defining one or more MDC dimensions for a table according to which the table data is clustered. MDC dimensions can be single columns or groups of columns. In SAP BI, 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 thus 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 5 shows an example of an MDC table organized by two dimensions, REGION and YEAR. For this table, DB2 automatically generates a dimension block index on REGION, a dimension block index on YEAR and a combined block index on YEAR and REGION. Additional record-based indexes on REGION, YEAR or both are not required.
Figure 5: MDC table
MDC improves the performance of queries that restrict on the MDC dimensions and the performance of data warehouse data roll-in and roll-out operations. Data roll-in operations profit from block locking, i.e. the locking of whole MDC blocks instead of - 15 Copyright IBM Corporation, 2007 All Version 1.0 Rights Reserved. 2007-07-24
single data rows. Data roll-out operations profit from MDC fast delete. Whole data pages are marked as deleted instead of every single data record. In Viper 2 (DB2 9.5), asynchronous cleanup of additional row-based indexes will be provided. These speeds up delete operations even more. You find detailed information about MDC, its support in SAP BI and recommendations for using it in [6]. SAP NetWeaver 2004s BI and the SAP BI support packages 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 04 BI support package 18 In SAP NetWeaver 2004s BI the information about MDC dimensions is stored in the SAP BI metadata for InfoCubes and DataStore objects and can thus be transported within a SAP BI system landscape. In the lower releases, the information about MDC dimensions is not stored in the SAP BI metadata. Therefore it cannot be transported between systems and may get lost when InfoCubes and DataStore objects are re-activated in transaction RSA1.
3.4 Support of DB2 9 row compression (deep compression)

Row compression is a DB2 9 feature for compressing the 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 for table data significantly and can also improve performance, especially of IO-restricted systems. You find detailed information about row compression, its support in SAP BI and recommendations for using it in [6]. Support for row compression is available since the following SAP BI support packages: SAP BW 3.0B support package 33 SAP BW 3.1 Content support package 27 SAP NetWeaver 04 BI support package 19 SAP NetWeaver 2004s BI support package 8 InfoCube and aggregate fact tables, DataStore object tables and PSA tables are created with row compression activated if the global SAP BI RSADMIN parameter DB6_ROW_COMPRESSION is set to YES. The default value for this parameter is NO. The data cannot be compressed until a compression dictionary has been created. A compression dictionary can be created once some data has been inserted into the tables. Transaction RSRV provides a check and repair function for InfoCubes, DataStore objects and PSA tables that checks whether row compression is active, the table contains data and no compression dictionary exists. In this case the user can schedule a job that either creates the dictionary and compresses the existing data or only creates the dictionary for future use. Starting with Viper 2 (DB2 9.5), DB2 will automatically create a compression dictionary after some data has been inserted into a table with row compression activated. - 16 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
3.5 Detailed SAP BI table layout on DB2 LUW

3.5.1 PSA tables
The partitioning key of PSA tables consists of the record number column RECORD. PSA tables have a primary key index defined on the columns request ID, data package and record number. MDC for PSA tables is controlled with the global SAP BI RSADMIN parameter DB6_MDC_FOR_PSA. If the parameter is set to YES, PSA tables are created with MDC on the request ID column REQUEST. DB6_MDC_FOR_PSA=YES was the default in the following support packages: SAP BW 3.0B support package 32 SAP BW 3.1 Content support package 26 SAP NetWeaver 04 BI support package 18 SAP NetWeaver 2004s BI support package 1 to 9 Starting with the following support packages, DB6_MDC_FOR_PSA is set to NO by default, i.e. PSA tables are not created as MDC tables: SAP BW 3.0B support package 33 SAP BW 3.1 Content support package 27 SAP NetWeaver 04 BI support package 19 SAP NetWeaver 2004s BI support package 10 To create PSA tables as MDC tables the user has to set DB6_MDC_FOR_PSA to YES explicitly. Row compression for PSA tables is controlled with the global SAP BI RSADMIN parameter DB6_ROW_COMPRESSION. If the parameter is set to YES, PSA tables are created with compression activated. The default value for this parameter is NO.
3.5.2 DataStore object tables

The following applies to standard DataStore objects and DataStore objects for direct update: The partitioning key of DataStore object active tables consists of the logical key fields of the DataStore object. These also form the primary key index. Additional user-defined indexes have to be created non-unique. This is because of the restriction that all partitioning key columns of a table must be contained in all unique indexes. This restriction ensures that index uniqueness can be maintained locally on each database partition. Because the partitioning key of DataStore active tables consists of all key columns, additional unique indexes would have to include the key columns. The partitioning key of activation queue and change log tables consists of the record number columns. The primary key of both tables consists of the columns request ID, data package and record number. MDC support for DataStore object active tables allows the user to select MDC dimensions from the logical key fields of the DataStore object. For activation queue and - 17 Copyright IBM Corporation, 2007 All Version 1.0 Rights Reserved. 2007-07-24
change log tables MDC is controlled by RSADMIN parameter DB6_MDC_FOR_PSA. If the parameter is set to YES these tables are created with MDC on the request ID column REQUEST. In SAP NetWeaver 2004s BI, for activation queue tables the REQUEST column has been replaced by the surrogate identifier of the request (column SID). In this release, SID instead of REQUEST is the MDC dimension. Write-optimized DataStore objects introduced in SAP NetWeaver 2004s BI are handled slightly differently: Write-optimized DataStore objects only consist of the active table that has additional columns for request ID, data package ID and record ID. The partitioning key consists of the logical key fields of the DataStore object, as for the other types of DataStore objects. On these columns, the unique or non-unique index KEY is created. The index is unique if the user selects the check uniqueness of data option for the DataStore object, otherwise it is non-unique. On the columns for request ID, data package ID and record ID, the non-unique index RDR is created. This index only exists on DB2 LUW. All other database platforms create the unique primary key index ~0 on these columns. This is not supported by DB2 LUW because it would collide with the partitioning key. Therefore the active table of write-optimized DataStore object has no primary key index on DB2 LUW. MDC for the active table of write-optimized DataStore objects is controlled by RSADMIN parameter DB6_MDC_FOR_PSA. If set to YES, the request ID column is the only MDC dimension. Row compression for all DataStore object types and tables is controlled by RSADMIN parameter DB6_ROW_COMPRESSION. If the parameter is set to YES, the tables are created with compression activated. The default value for this parameter is NO.
3.5.3 InfoCube and aggregate tables

Partitioning Key The of InfoCube and aggregate fact tables consists of the dimension key columns except for the package dimension key column of the table 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 partitioning key on all key columns facilitates collocated joins in central SAP BI operations like InfoCube compression, i.e. it is not necessary to transport fact table rows in table queues from one partition to other partitions. Combined index on fact table dimension key columns E fact tables have a combined unique index defined on the dimension key columns in the following order:
time dimension, dimension 1, dimension 2, unit dimension, package dimension
Version 1.0 2007-07-24
Heterogeneous SAP NetWeaver BI System Copy to IBM DB2 for Linux, UNIX and Windows For non-MDC tables this index is defined as clustering index.
F fact tables have the same unique index if the InfoCube is an APO Cube (i.e. field BWAPPL in InfoCube management table RSDCUBE contains APO). Otherwise, this index is non-unique on SAP BI releases prior to SAP NetWeaver 2004s BI. On NetWeaver 2004s BI, for non-APO InfoCubes, the combined index on F fact tables is not created any more by default. In prior releases the index was needed for SAP BI InfoCube compression. The new implementation in SAP NetWeaver 2004s BI doesnt rely on the combined index any longer. Customers who need the index for SAP BI reporting can set RSADMIN parameter DB6_PINDEX_ON_FTABLE to YES to enforce its creation. For non-MDC tables this index is defined as clustering index. Single column indexes on fact table dimension key columns E fact tables have single-column indexes defined on the key columns of the user-defined dimensions 1 to 9 and A to D and on the time dimension key column. F fact tables have single-column indexes defined on the key columns of the user-defined dimensions 1 to 9 and A to D and on the time and package dimension 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. MDC for fact tables The user 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, the user can also select one of the time characteristics 0CALMONTH (calendar month) or 0FISCPER (fiscal period). There is a soft limit for the number of MDC dimensions of three. If the user selects 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. An additional column SID_0CALMONTH or SID_0FISCPER is inserted into the fact tables if the user selects range partitioning for an InfoCube. By default, aggregates inherit the MDC settings of the InfoCube. MDC for aggregates can be turned off 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 block index is already created on that column. Dimension tables indexes Dimension tables reside on only one database partition. They do not have a partitioning key. They have a primary key index on the dimension id column, a combined index on all - 19 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
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. Row compression Row compression for InfoCube and aggregate fact tables is controlled by RSADMIN parameter DB6_ROW_COMPRESSION in the same way as for PSA tables and DataStore object tables.
3.6 Differences to SAP BI implementations on other database platforms

DPF and MDC are unique DB2 LUW features that are not supported by other database platforms. Row compression is also supported by DB2 for zSeries where it is hardwaresupported and works with compression dictionaries at tablespace level. Some database platforms, like Oracle, DB2 for zSeries, and Informix, implement range partitioning for InfoCube and aggregate fact tables and PSA tables. 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. 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 database platform Oracle, range partitioned PSA tables have an additional column PARTNO. This is not the case on Informix. There are also differences concerning the indexes created on InfoCube and aggregate fact tables and DataStore object tables: Database platforms other than DB2 LUW implement a different column order for the combined index of fact tables. On the other database platforms, this index is not clustered. On some platforms, the combined index is not created on F fact tables. On some database platforms, 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 DB2 LUW only supports non-unique indexes. Different indexes on the active table of write-optimized DataStore objects are defined on DB2 LUW than on other database platforms. For more information about the implementation of SAP BI on DB2 for LUW, please refer to [6] and [11]. [12] provides details about the general implementation of SAP systems on DB2 LUW and features used from DB2 V8.2.2. [14] is a performance study that shows that DB2 LUW almost scales linearly when adding additional database partitions.
4. Issues of SAP BI system migrations

When migrating SAP BI systems, the following issues have to be dealt with: - 20 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
SAP BI systems tend to get very large and to contain very large tables (InfoCube fact tables, PSA tables, DataStore active and change log tables). Therefore, migrations have to be planned carefully to fit into the time window available for them. 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. Different size limits for database objects on the source and target database platform might make it necessary to move tables to new data classes and use database specific features like partitioning to fit the objects into the space available. Size limits are an issue in DB2 V8. DB2 9 supports large tablespaces (up to 16 TB) for data and indexes. Therefore size limits should no longer be an issue. When creating the tables and indexes in the target database the database specific features have to be implemented. If they are not represented explicitly in the SAP data dictionary standard R3load processing cannot handle them. This is a problem even when only migrating to a different operating system without changing the database platform. When changing the database platform the layout of tables and indexes on the target database platform might differ from the layout in the source database. The SAP data dictionary only contains the layout in the source database. The first two problems are general. They have to be dealt with in all migrations of large SAP systems containing very large tables. The third one is specific to SAP BI systems. Information about how to speed up SAP system migrations to DB2 by tuning database export and import is not further discussed in this whitepaper.
4.1 Issues related to size limits

DB2 V8 has size limits for tablespaces depending on the tablespace page size shown in Table 1. These size limits are per database partition. Tablespace Page Size 4 KB 8 KB 16 KB 32 KB Maximum Table Size 64 GB 128 GB 256 GB 512 GB
Table 1: DB2 for LUW V8 tablespace size limits
The number of tables that can be created in one tablespace is limited to 55,000. DB2 9 supports large tablespaces which increase the maximum table size considerably: Tablespace Page Size 4 KB 8 KB 16 KB Maximum Table Size 2,048 GB 4,096 GB 8,192 GB - 21 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
Heterogeneous SAP NetWeaver BI System Copy to IBM DB2 for Linux, UNIX and Windows 32 KB 16,384 GB
Table 2: DB2 9 for LUW tablespace size limits
New SAP installations on DB2 9 automatically use large tablespaces. When migrating from DB2 V8 to DB2 9, regular tablespaces can be converted to large tablespaces. On other database platforms, there are different size limits. For instance, on Informix there is a size limit per table fragment of 64 GB when the DBSPACE has a page size of 4 KB and 32 GB when the DBSPACE has a page size of 2 KB. Fragmentation is the Informix implementation of range partitioning. Table fragments reside in different DBSPACES. There is no size limit for DBSPACES themselves. When migrating to DB2, the data classes that are mapped to DBSPACES on Informix are mapped to tablespaces in DB2. Thus, when migrating from Informix to DB2 V8, the following problems might occur: The size of an Informix DBSPACE might exceed the size limit of the DB2 V8 tablespace. In this case, the DB2 tablespace could be created with a larger page size, if the DBSPACE size is less than 512 GB. This might not always help because there is also a limit of 255 rows per tablespace page. Otherwise, tables might have to be moved to other tablespaces. The size of a fragmented table in Informix might exceed the DB2 V8 tablespace size limit. The table fragments, although residing in different DBSPACES in Informix, will be imported into a single table in the tablespace associated with the table's data class in DB2. If the sum of the fragment sizes exceeds 512 GB, the table cannot be stored in a DB2 tablespace on one database partition. For SAP BI DataStore, PSA, and InfoCube fact tables several database partitions need to be created in this case. When planning the migration to DB2 V8 it is therefore necessary to get a detailed overview of the database storage objects and their sizes on the source system and to carefully plan the placement of tables in DB2 tablespaces, the tablespace page sizes, and multi-partitioning. When doing this you should always calculate enough space for future growth. When migrating from Informix you can call report SAP_BWTOOLPGM_INF to get an overview of the size and fragmentation of PSA, DataStore and InfoCube and aggregate fact tables.
4.2 Issues related to database specific features and layout differences

PSA, DataStore and InfoCube fact tables have to be created with partitioning key in the target DB2 database. If MDC is used, they have to be created with the correct MDC dimensions.
Version 1.0 2007-07-24
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 has to be created clustered. The data exported from the SAP data dictionary of the source system does not contain this information, even if the source database platform is also DB2 for LUW. Additional information is needed to create the tables and indexes correctly. This also applies to pure non-Unicode to Unicode migrations, when the source and the target system use DB2 LUW. Also in this case, the information about partitioning keys, MDC dimensions and clustered indexes is not contained in the data exported from the SAP data dictionary. When migrating from other database platforms, additional unique indexes on DataStore active tables have to be created non-unique on DB2. Otherwise SQL errors occur. The combined index on fact tables has to be created with a different column order than on the source database. Additional secondary indexes might have to be created on dimension and fact tables that do not exist in the source database. Indexes on MDC dimensions should not be created. All this information is also not available in the data exported from the SAP data dictionary of the source system. Additional information is required.
5. Steps of a heterogeneous SAP system copy

Heterogeneous SAP system copies are migrations where either the operating system platform or the database platform or both change. In most cases, heterogeneous system copies involve exporting the source database in a database independent format with the SAP R3load tool. With DB2 for LUW as database platform, migrations between the different UNIX operating system platforms can be done with database means (database backup and redirected restore) without the need to export the database with R3load. This is described in [13]. R3load is only needed in the following situations: When migrating from another database platform like Informix, Oracle, or DB2 for zSeries or iSeries. When migrating from Linux to UNIX or Windows or vice versa When migrating from non-Unicode to Unicode. Because the database code page changes usage of backup and redirected restore is not possible in this case The steps required for exporting the source system and building up the target system are shown in Figure 6 below.
Version 1.0 2007-07-24
Figure 6: Steps of a heterogeneous SAP system copy
On the source system, the following steps are executed: 1. Migration preparations consist in the execution of reports and transactions that are described in detail in [3] for systems based on SAP NetWeaver 2004s and [4] for systems based on SAP NetWeaver 04. Especially when migrating from nonUnicode 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. They define the tasks for unloading the database that can be executed sequentially or in parallel. 3. Generation of the template containing size estimations for the target database. For DB2 on LUW it 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. Unload the source database to files in a database independent format with R3load by executing the command files generated in the previous step. For DB2 LUW as target database platform the export is stored in the directory structure shown in Figure 7. - 24 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
<Export_Directory> DATA DB6 DB LABEL.ASC
DDLDB6.TPL
Figure 7: SAP export directory structure for target DB platform DB2 LUW
LABEL.ASC is the CD label created for the export. It is checked when installing the target database. The DATA subdirectory contains the exported data and the SAP data dictionary structure information. DDLDB6.TPL is a template for the DDL statements used to create tables and indexes in DB2 for LUW. It also contains a standard mapping of the SAP data classes to DB2 tablespaces. The DB6 subdirectory contains DBSIZE.XML, the template containing the size estimates for the target database. The export has to be transferred from the source server to the target server, for example via FTP. On the target server, the following steps have to be executed: 1. Generation of the SAP instance. 2. Obtain the migration key required for heterogeneous system copies from SAP. 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 the data into the target database with R3load. 5. Execute post migration reports and transactions as described in [3], [4] and [5] to complete the migration. The SAP installation programs SAPinst (for SAP systems greater or equal to Basis 6.20) and R3Setup (for older SAP Basis releases) are used to export the source system and install the target system and import the database. The SAP Service Marketplace provides information about available tools and possible optimizations for system copies under [2].
6. Steps of a heterogeneous SAP BI system copy

Starting with SAP Business Information Warehouse 3.0B, two additional steps are defined for SAP BI system migrations: On the source system, a report has to be executed that creates the target database platform DDL for creating the database specific SAP BI tables and indexes in the target database. R3load uses the DDL to create the tables and indexes correctly in the target database. - 25 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
On the target system, after database import, a report has to be executed that performs a number of SAP BI specific post migration tasks explained in SAP BI migration post processing. The complete migration process consists of the steps shown in Figure 8.
Figure 8: Steps of a heterogeneous SAP BI system copy
This procedure is not available for SAP Business Information Warehouse 2.0B and 2.1 Content systems. You should upgrade these system to SAP Business Information Warehouse 3.0B / 3.1 Content or higher and then migrate using the procedure described here. For current information about the required support packages and patches, see [1] on the SAP Service Marketplace and SAP notes 771209, 777024, and 888210. You should always use the latest version of the SAP migration tools. You will find the latest patches on the SAP Service Marketplace in the Software Download section. In the following, the steps of a SAP BI system migration are described in more detail.
Version 1.0 2007-07-24
6.1 Generation of the DDL for the target database

To create the DDL for the SAP BI object tables and indexes for the target database system run report SMIGR_CREATE_DDL in the source system. Figure 9 shows the dialog of the report. You have to Select the target database platform Specify whether a non-Unicode to Unicode conversion is involved Enter the output directory for the DDL For test purposes, DDL generation can be restricted 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 BI tables or indexes with database specific features or different implementations on the source and target database platforms.
Figure 9: Report SMIGR_CREATE_DDL
It is important that after the report has been executed and before the database export, no more changes to SAP BI database objects (e.g. activations, field changes) are made. The safest thing is to call the report directly before the export while the system is still locked for users. SAP OSS notes 777024, 771209 and 888210 list the latest fixes for each database platform. Please make always sure that you have them installed in your source system, either via the Support Package that contains them or via the correction instructions supplied. - 27 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
The output files of the report have to be placed in the DB/DB6 subdirectory of the source database export directory. R3load will use them as additional input files when creating the tables and indexes in the target database. The .SQL output files are structured as shown below:
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. For migrations to DB2 LUW, SQL is created to handle the following database specific features and implementation differences: Partitioning 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 Row compression Indexes missing on the source database platform but required for DB2, for example additional secondary indexes on dimension tables Indexes existing on the source database platform but not required for DB2 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 After migration, the SAP data dictionary on the new target system will look the same as on the source system, whereas the layout of the tables and indexes in the target database is as required for the target database platform. Thus in the target system the state in the SAP data dictionary is not consistent with the state in the database. SAP BI migration post processing adapts the information about tables and indexes in the SAP data dictionary to the state in the target database (see SAP BI migration post processing). 6.1.1 DDL examples for migrations from Oracle to DB2 LUW We discuss in section 6.3.5 how R3load uses the DDL to create all tables and indexes in the DB2 target database correctly. In general, SQL statements are only generated for tables and indexes that use DB2 LUW specific features which R3load cannot handle on its own and for tables and indexes with a different layout on DB2 LUW than in the source system. For indexes that exist in the source system but are not to be created in the DB2 LUW target database, entries without
Version 1.0 2007-07-24
sql section (i.e. with an empty SQL statement) are created. This works in the same way for all source database platforms different from DB2 LUW. If the source system already runs on DB2 LUW the DDL is created from the DB2 system catalog for all tables and indexes that use database specific features R3load cannot handle (partitioning keys, MDC, row compression, clustered indexes). Because the information is taken from the DB2 system catalog the tables and indexes will be created with exactly the same layout as in the source system. For instance, it is not possible to create MDC for non-MDC tables or activate row compression for tables that do not use it in the source system. If the source database platform is not DB2 LUW, RSADMIN parameters defined for SAP BI on DB2 LUW can be set in the source system to influence the output. For instance, if DB6_MDC_FOR_PSA is set to NO, the DDL for all PSA and PSA-like tables is created without MDC while, if DB6_MDC_FOR_PSA is set to YES, the DDL for all PSA and PSA-like tables is created with MDC on the request ID or request SID column. The following RSADMIN parameters influence the output of SMIGR_CREATE_DDL: DB6_MDC_FOR_PSA: PSA and DataStore object activation queue and change log tables are created with MDC if the parameter is set to YES and without MDC if the parameter is set to NO. YES is the default for the following support packages: o SAP BW 3.0B support package 32 o SAP BW 3.1 Content support package 26 o SAP NetWeaver 04 BI support package 18 o SAP NetWeaver 2004s BI support packages 1 to 8. In all later support packages the default has been changed to NO. In earlier support packages, MDC is not supported. DB6_ROW_COMPRESSION: PSA, DataStore object tables and InfoCube and aggregate fact tables are created with row compression activated if the parameter is set to YES and without row compression if the parameter is set to NO. NO is the default. This option is available with the following support packages: o SAP BW 3.0B support package 33 o SAP BW 3.1 Content support package 27 o SAP NetWeaver 04 BI support package 19 o SAP NetWeaver 2004s BI support packages 8. In earlier support packages row compression is not available. Note: when using row compression you should always run R3load with the option COMPRESS or LOADCOMPRESS. With this option, R3load create a compression dictionary and compresses the data during data import for tables which have compression activated. DB6_PINDEX_ON_FTABLE: the combined P index on F fact tables is created if the parameter is set to YES. It is not created if the parameter is set to NO. This only applies to SAP NetWeaver 2004s BI. In earlier releases, the index is always created. - 29 Copyright IBM Corporation, 2007 All Version 1.0 Rights Reserved. 2007-07-24
The following samples are taken from a SAP NetWeaver 2004s BI system running on Oracle. The DDL generation program determines which indexes with which properties exist on the source system and generates the DDL for the indexes required on DB2 based on this information. For other source database platform than Oracle, the generated DDL might look different. 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&" PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING; ALTER TABLE "/BIC/FBFABCUBE5" LOCKSIZE ROW; ind: /BIC/FBFABCUBE5~0 ind: /BIC/FBFABCUBE5~02 sql: CREATE INDEX "/BIC/FBFABCUBE5~02" on "/BIC/FBFABCUBE5"
Version 1.0 2007-07-24
("KEY_BFABCUBE5T") CLUSTER ALLOW REVERSE SCANS; ind: /BIC/FBFABCUBE5~03
The sql section below the tab: entry contains the CREATE TABLE statement with the correct partitioning key. The ALTER TABLE statement sets the LOCKSIZE attribute to ROW, indicating row level locking. This is always the case for non-MDC tables. For MDC tables, the LOCKSIZE attribute might also be set t o BLOCKINSERT, indicating MDC block locking. 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 would always create one. If there exists an entry for the index in the .SQL file 3load uses the SQL statement in this entry. In this case the SQL statement is empty. Therefore the index is not created. The ind: entry for primary key index /BIC/FBFABCUBE5~02 contains the SQL statement for creating the index on the time dimension key column as a clustered index. In DB2 LUW, indexes on the unit dimension key column are not created. For this fact table, index The ind: entry for primary key index /BIC/FBFABCUBE5~0 exists in the Oracle database. The empty sql section avoids that the index is created in DB2 LUW. If RSADMIN parameter DB6_PINDEX_ON_FTABLE was set to YES the following DDL would be 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&"
Version 1.0 2007-07-24
LONG IN "&locationL&" PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING ALTER TABLE "/BIC/FBFABCUBE5" LOCKSIZE ROW;
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; ind: /BIC/FBFABCUBE5~03
The P index /BIC/FBFABCUBE5~P which does not exist in the source system is created as clustered index. The SQL is stored under the entry for the primary key index /BIC/FBFABCUBE5~0. Because 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. When R3load executes the task to create the primary key index /BIC/FBFABCUBE5~0, it uses the SQL 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 DB2 LUW specific features 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,
Version 1.0 2007-07-24
"/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&" PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING; ALTER TABLE "/BIC/EBFABCUBE5" LOCKSIZE ROW; ind: /BIC/EBFABCUBE5~0 ind: /BIC/EBFABCUBE5~01 ind: /BIC/EBFABCUBE5~03
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 partitioning key. The ALTER TABLE statement sets the LOCKSIZE attribute to ROW, indicating row level locking. 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 DB2 LUW, 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 which exist in the source system from being created in the DB2 LUW target database. The ind: entry for index /BIC/FBFABCUBE5~P creates the P index on the E fact table as clustering index with the correct column order for DB2 LUW. InfoCube fact tables with range partitioning
Version 1.0 2007-07-24
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&" PARTITIONING KEY ( "KEY_ZTPHTGC11" , "KEY_ZTPHTGC1T" , "KEY_ZTPHTGC1U" ) USING HASHING; ALTER TABLE "/BIC/FZTPHTGC1" LOCKSIZE ROW; ind: /BIC/FZTPHTGC1~0 ind: /BIC/FZTPHTGC1~020 sql: CREATE INDEX "/BIC/FZTPHTGC1~020" on "/BIC/FZTPHTGC1" ("KEY_ZTPHTGC1T") CLUSTER ALLOW REVERSE SCANS; ind: /BIC/FZTPHTGC1~900
The DDL is nearly the same as in the previous example with 2 exceptions: The table contains the additional column SID_0CALMONTH used for range partitioning. This column remains in the table although DB2 LUW will not make use of it. There is an additional entry with an empty sql section for index /BIC/FZTPHTGC1~900 which exists in the source system but will not be created in the DB2 LUW target system. 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 system. In DB2 LUW the column will be maintained and - 34 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
filled correctly but not used in SAP BI reporting. Therefore it is not necessary 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&" PARTITIONING KEY ( "KEY_ZTPHTGC11" , "KEY_ZTPHTGC1T" , "KEY_ZTPHTGC1U" ) USING HASHING; ALTER TABLE "/BIC/EZTPHTGC1" LOCKSIZE ROW; ind: /BIC/EZTPHTGC1~0 ind: /BIC/EZTPHTGC1~010 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 with 2 exceptions: The table contains the additional column SID_0CALMONTH used for range partitioning. This column remains in the table although DB2 LUW will not make use of it. An entry with 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 - 35 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
Starting with the following support packages you can convert range partitioning on fact tables to MDC: SAP BW 3.0B support package 34 SAP BW 3.1 Content support package 28 SAP NetWeaver 04 BI support package 21 SAP NetWeaver 2004s BI support package 13 You also need the following SAP BASIS support packages: SAP BASIS 620 support package 62 SAP BASIS 640 support package 20 SAP BASIS 700 support package 12 To convert range partitioning to MDC, enter RP_TO_MDC in the field Database Version of report SMIGR_CREATE_DDL. Then 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&" PARTITIONING KEY ( "KEY_ZTPHTGC11" , "KEY_ZTPHTGC1T" , "KEY_ZTPHTGC1U" ) USING HASHING ORGANIZE BY ( "KEY_ZTPHTGC1P" , "SID_0CALMONTH" ); ALTER TABLE "/BIC/FZTPHTGC1" LOCKSIZE BLOCKINSERT; ind: /BIC/FZTPHTGC1~0 ind: /BIC/FZTPHTGC1~010 ind: /BIC/FZTPHTGC1~900
Version 1.0 2007-07-24
The CREATE TABLE statement for the F fact table contains the correct partitioning key and the package dimension key column and the time characteristic column as MDC dimensions (ORGANIZE BY clause). Furthermore the LOCKSIZE attribute is set to BLOCKINSERT to support MDC fast roll-in. 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 DB2 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&" PARTITIONING KEY ( "KEY_ZTPHTGC11" , "KEY_ZTPHTGC1T" , "KEY_ZTPHTGC1U" ) USING HASHING ORGANIZE BY ( "SID_0CALMONTH" ); ALTER TABLE "/BIC/EZTPHTGC1" LOCKSIZE BLOCKINSERT; ind: /BIC/EZTPHTGC1~0 ind: /BIC/EZTPHTGC1~010 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;
Version 1.0 2007-07-24
The CREATE TABLE statement contains the correct partitioning key and the time characteristic column SID_0CALMONTH as MDC dimension. The P index /BIC/EZTPHTGC1~P is created non-clustered. For aggregates, the RSADMIN parameter DB6_MDC_FOR_AGGREGATES is not evaluated. If RP_TO_MDC is selected, MDC for aggregate fact tables is generated if these tables use range partitioning in the source system. Otherwise MDC is not generated. Dimension tables The following DDL is generated for dimension tables with more than one SID_... column, if single-column indexes on the second, third, etc. SID_... columns do not exist in the source system:
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&"; ALTER TABLE "/BIC/DBBLFAB51" LOCKSIZE ROW; 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;
Version 1.0 2007-07-24
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 DB2 LUW specific features. 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 DB2 LUW target database. Again, the DDL for the additional indexes is stored there because otherwise R3load would never 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)
Version 1.0 2007-07-24
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&" PARTITIONING KEY ( "/BIC/BASIS6" , "/BIC/BASIS7" , "CALDAY" ) USING HASHING ALTER TABLE "/BIC/AZFCT_R1000" LOCKSIZE ROW;
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 partitioning key. The index /BIC/AZFCT_R100001 which is unique on the source system has to be created nonunique in DB2 LUW because it does not contain all partitioning key columns. The following DDL is generated for the activation queue table if MDC for PSA tables is activated with RSADMIN parameter DB6_MDC_FOR_PSA=YES:
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)
Version 1.0 2007-07-24
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&" PARTITIONING KEY ( "RECORD" ) USING HASHING ORGANIZE BY ( "SID" ); ALTER TABLE "/BIC/AZFCT_R0540" LOCKSIZE BLOCKINSERT;
The CREATE TABLE statement contains the correct partitioning key and SID as MDC dimension. If DB6_MDC_FOR_PSA=NO the ORGANIZE BY clause is not generated. 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,
Version 1.0 2007-07-24
"/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&" PARTITIONING KEY ( "/BIC/BASIS6" , "/BIC/BASIS7" ) USING HASHING 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;
Version 1.0 2007-07-24
The CREATE TABLE statement contains the correct partitioning key. If DB6_MDC_FOR_PSA=YES an ORGANIZE BY clause on column REQUEST would be generated additionally. Instead of the primary key index on REQUEST, DATAPAKID and RECORD the non-unique index /BIC/AZFCT_R0600RD on these columns is created. The index cannot be created as unique because it does not contain the partitioning 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&"
Version 1.0 2007-07-24
INDEX IN "&locationI&" LONG IN "&locationL&" PARTITIONING KEY ( "RECORD" ) USING HASHING; ALTER TABLE "/BI0/B0000103000" LOCKSIZE ROW;
If DB6_MDC_FOR_PSA=YES and DB6_ROW_COMPRESSION=YES the following DDL with an ORGANIZE BY clause and COMPRESS YES 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&"
Version 1.0 2007-07-24
INDEX IN "&locationI&" LONG IN "&locationL&" PARTITIONING KEY ( "RECORD" ) USING HASHING ORGANIZE BY ( "REQUEST" ) COMPRESS YES; ALTER TABLE "/BI0/B0000103000" LOCKSIZE BLOCKINSERT;
PSA tables use no other DB2 LUW specific features.
6.2 Exporting the source database

You can export the source database with SAPinst. This is straightforward for SAP NetWeaver 04 and higher releases. From the SAPinst Welcome screen select item ABAP Database Content Export in either the Unicode or the non-Unicode branch of the menu tree, depending on the code page of the source system (see Figure 10).
Figure 10: Source Database Export with SAP NetWeaver '04 SAPinst
Version 1.0 2007-07-24
R3load based database export is not fully supported for SAP Business Information Warehouse 3.0B and 3.1 Content. It is recommended to export the source database with the SAPinst tool of R/3 Enterprise 4.7 Service Release 1 instead. 6.2.1 Hints and Tips for the Export Estimation of the target database size During the export SAP program R3szchk is executed to estimate the size of the database and database storage entities (tablespaces and containers on DB2) on the target database platform. The results are stored in file DBSIZE.XML in the export directory. In many cases, these size estimates are too small. This is no longer an issue for R3load because the DB2 LUW tablespaces are created with the AUTOEXTEND option. You only have to ensure that there is enough free space in the file systems for the tablespaces to grow. Handling of SAP BI temporary tables and views If during test migration you encounter any problems with SAP BI temporary tables or views you can drop them on the source system before exporting the database. To drop SAP BI temporary tables and views execute report SAP_DROP_TMPTABLES with the selections shown in Figure 11. If you want to continue using the source system after the export, this might have a small short-term performance impact because the tables have to be recreated. In general, SAP BI temporary tables are reused.
Figure 11: Report SAP_DROP_TMPTABLES
Get an overview of SAP BI table sizes in the source system When migrating from Informix, you can execute report SAP_BWTOOLPGM_INF on the source system to get an overview of the size and number of SA BI object tables and table fragmentation. This is useful as a basis for planning the layout of the target database, - 46 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
deciding about splitting packages for the export and determining the optimal unload order. The report provides the following information: InfoCubes sorted by number of rows in the fact tables Aggregates of InfoCubes DataStore tables sorted by size or alphabetically PSA tables sorted by size or alphabetically Display of the fragments of a table Speed up export of very large tables There are several options to speed up the export of very large tables: 1. Export them unsorted. This is possible for most tables except for a few ones that are listed in the SAP documentation. 2. Use a SELECT Statement to split the table contents into several parts that can be exported in parallel. 3. If the table is fragmented or range partitioned you can export the table fragments or ranges in parallel
6.3 Creation and import of the target database

Before performing a multi-partition DB2 installation, be sure to have read carefully the DB2 documentation and the SAP installation guides. There are a number of prerequisites that have to be fulfilled. For instance, You have to reserve enough TCP/IP ports for the communication between the database partitions On UNIX systems, several file systems have to be NFS mounted on all participating servers On UNIX systems, the users and groups created for SAP and DB2 during installation have to have the same ID numbers on each server. 6.3.1 SAP NetWeaver 2004s You create and import the target database with SAPinst, as shown in Figure 12 for an ABAP system.
Version 1.0 2007-07-24
Figure 12: SAP NetWeaver 2004s - ABAP target system installation
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 the exit for installing additional database partitions is reached, as shown in Figure 13.
Version 1.0 2007-07-24
Figure 13: SAP NetWeaver 2004s - Exit for creating additional database partitions
If you want to create a multi-partition DB2 database you cancel the installation at this step and create the additional database partitions on the same server or additional servers. You create the additional partitions with the task Additional Database Partitions of SAPinst, as shown in Figure 14. You have to run SAPinst on every database partition server.
Version 1.0 2007-07-24
Figure 14: SAP NetWeaver 2004s - Creation of additional database partitions
Afterwards you continue the target system installation. When the screen shown in Figure 13 is displayed again, you continue with OK. On the next screen, you assign the database partition groups for the SAP BI tables to the database partitions, as shown in Figure 15.
Version 1.0 2007-07-24
Figure 15: SAP NetWeaver 2004s - Default mapping of database partition groups to partitions
The installation then continues with the creation of the database. 6.3.2 SAP NetWeaver 04 You create and import the target database with SAPinst, as shown in Figure 16 for a nonUnicode system.
Version 1.0 2007-07-24
Figure 16: SAP NetWeaver '04 Target system installation
During the installation process, SAPinst prompts whether to perform a standard installation or a system migration with R3load as shown in Figure 17.
Version 1.0 2007-07-24
Figure 17: SAP NetWeaver '04 Database installation method
During the installation you are prompted whether to install a single or a multi-partition system. If you select to install a multi-partition system you can add database partitions as shown in Figure 18.
Version 1.0 2007-07-24
Figure 18: SAP NetWeaver '04 Adding database partitions
You get then to the screen where you assign the database partition groups to the database partitions (like Figure 15). In an additional screen you assign the host names of the database servers to the database partitions (Figure 19).
Version 1.0 2007-07-24
Figure 19: SAP NetWeaver '04 - Mapping of database partitions to servers
If you install more than one database partition server you have to run SAPinst on each server. To do this an exit step is provided after the database instance has been created, as shown in Figure 20.
Version 1.0 2007-07-24
Figure 20: SAP NetWeaver '04 Exit for installing additional database partition servers
6.3.3 SAP BW 3.0B and 3.1 Content You should use SAPinst 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 BI. 6.3.4 Handling of database partition groups in multi-partition installations As shown in the previous section, at some point in time during the target system installation, you define the distribution of the SAP BI specific DB2 database partition groups to the database partitions (Figure 15: SAP NetWeaver 2004s - Default mapping of database partition groups to partitions). By default, these are the database partition groups NGRP_FACT_<SAPSID>, NGRP_ODS_<SAPSID> and NGRP_DIM_<SAPSID>. By default, the database partition groups for fact tables and for DataStore object and PSA tables are distributed over all database partitions. For large installations we recommend to - 56 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
not store fact and DataStore/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. This results in a high workload on this partition. Furthermore, it makes sense to keep the data volume on partition 0 small to speed up database backup. When taking backups, partition 0 has to be backed up first and then all other partitions can be backed up in parallel. For more information about database partition design see [6]. The database partition group for dimension tables resides on database partition 0 only. We strongly recommend not changing this setting. Dimension tables should reside only on database partition 0. 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 (see Figure 21).
<?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="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_FACT_'+UPPER(getContextParameter('cpSapSystemName')))]]> </exp> </fld> </row>
Figure 21: Tablespace information with database partition group in DBSIZE.XML
Version 1.0 2007-07-24
If you migrate from another database platform, DBSIZE.XML only contains the default database partition groups. If your source database is DB2 for LUW and you have defined additional database partition groups there, DBSIZE.XML contains this information. When you migrate from another database platform and you want to implement your own tablespaces and database partition groups in the DB2 target database, you can handle this as follows: SAPinst of SAP NetWeaver 2004s provides an exit step for manually creating tablespaces. You can create your own database partition groups and tablespaces in this exit step. 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 22. The distribution of database partition groups over database partitions is not defined in DBSIZE.XML but only in the 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 22: Defining additional tablespaces and database partition group in DBSIZE.XML
6.3.5 Modified R3load processing during target database import R3load uses the input files shown in Figure 23 A .TSK file, which contains the tasks to be processed for all the tables and indexes in the import job. - 58 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
A .STR file, which contains the structure of the tables and indexes as defined in the SAP data dictionary of the source system. One or more .<nnn> files, which contain the data to be imported A .cmd file, which contains the locations of the data, structure, and task files The file DDL<DBSYS>.TPL, which contains the templates for the DDL statements of the target database platform <DBSYS>. One or more .SQL files which contain the DDL generated on the source system.
Figure 23: Input files to R3load for importing the target database
Standard R3load processing extracts the structure of the tables and indexes from the .STR file and generates the DDL for creating them from this information and the templates stored in DDL<DBSYS>.TPL. With the introduction of the .SQL files this has changed. For each table or index to be processed, R3load looks for the DDL for creating it in the .SQL file and executes it if found. Otherwise, it creates the table or index based on the .STR file and the statement template. Let's return to one of the example from an Oracle to DB2 LUW migration from section 6.1 to see how R3load uses the generated DDL: The following was the DDL 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
Version 1.0 2007-07-24
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&" PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING ALTER TABLE "/BIC/FBFABCUBE5" LOCKSIZE ROW;
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; ind: /BIC/FBFABCUBE5~03
The task file contains the following entries for the F fact table (T for table creation, D for data import, P for primary key index, I for additional secondary indexes):
T D P I I I I I /BIC/FBFABCUBE5 C xeq /BIC/FBFABCUBE5 I xeq /BIC/FBFABCUBE5~0 C xeq /BIC/FBFABCUBE5~01 C xeq /BIC/FBFABCUBE5~02 C xeq /BIC/FBFABCUBE5~03 C xeq /BIC/FBFABCUBE5~04 C xeq /BIC/FBFABCUBE5~05 C xeq
R3load creates table "/BIC/FBFABCUBE5" by executing the DDL stored for it in the .SQL file. Thus, it creates the table with the correct partitioning key. The next task is to load the data into the F fact table. - 60 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
By default, there is a task for every table to create the standard primary key index 0. R3load finds the entry for it in the .SQL file. The DDL stored for it creates the clustered P index that didn't exist in the Oracle source system with the correct column order for DB2. The standard primary key index is not created. The task file contains no entry for the P index because it does not exist on the source system. R3load then continues with the indexes 01 to 05. Index 03 is not created because the section for it in the .SQL file contains no SQL statement. The other indexes are not DB2 LUW specific, therefore no DDL statements are required for them. The following was the DDL 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&" PARTITIONING KEY ( "KEY_BFABCUBE51" , "KEY_BFABCUBE52" , "KEY_BFABCUBE5T" , "KEY_BFABCUBE5U" ) USING HASHING; ALTER TABLE "/BIC/EBFABCUBE5" LOCKSIZE ROW; ind: /BIC/EBFABCUBE5~0 ind: /BIC/EBFABCUBE5~01 ind: /BIC/EBFABCUBE5~03
Version 1.0 2007-07-24
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 for table creation, D for data import, P for primary key index, I for additional secondary indexes):
T D P I I I I I I /BIC/EBFABCUBE5 C xeq /BIC/EBFABCUBE5 I xeq /BIC/EBFABCUBE5~0 C xeq /BIC/EBFABCUBE5~01 C xeq /BIC/EBFABCUBE5~02 C xeq /BIC/EBFABCUBE5~03 C xeq /BIC/EBFABCUBE5~04 C xeq /BIC/EBFABCUBE5~05 C xeq /BIC/EBFABCUBE5~P C xeq
R3load creates table "/BIC/EBFABCUBE5" by executing the DDL stored for it in the .SQL file. Thus, it creates the table with the correct partitioning 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 SQL statement. Therefore these indexes are not created. The indexes 02, 04 and 05 are not DB2 LUW specific, therefore no DDL statements are required for them. The entry for the P index contains the SQL statement to create it in the correct column order for DB2 LUW. 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 defined over the columns marked as key columns in the SAP data dictionary. However, for SAP BI 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 stored for it in the .SQL file and thus does not create it. For indexes that do exist on the source database system but are not required in the target DB2 database, entries without DDL are generated as well. The indexes will not be created in the database. SAP BI post processing later adapts the SAP data dictionary to the state in the database, i.e. it deletes indexes from the SAP data dictionary that do not exist in the target database.
Version 1.0 2007-07-24
The DDL for indexes that are required in the DB2 target database but that do not exist in the source database is appended to the standard primary key 0 index. SAP BI migration post processing later adds all indexes to the SAP data dictionary that exist in the database but not in the dictionary. If a table has a clustered index, it is not necessary to create it before the data is imported into the table. When inserting into an empty table, DB2 does not take any specific steps to preserve the clustering order. 6.3.6 Hints and tips to speed up the import
DB2 registry variable DB2_FORCE_FCM_BP When using logical partitioning on AIX systems (i.e. several partitions on one database server) you should set DB2 registry variable DB2_FORCE_FCM_BP=YES. In DB2 9, this is the default. DB2 will use a shared memory segment for communication between the logical database partitions instead of TCP/IP sockets. Communication via a shared memory segment is faster than via TCP/IP sockets. R3load import method R3load provides the following methods for importing data into DB2: -loadprocedure dbsl: row by row insert -loadprocedure fast: uses array insert to insert blocks of rows instead of single rows. This is faster than -loadprocedure dbsl. -loadprocedure fast LOAD: uses DB2 LOAD instead of SQL INSERT. For large tables this is faster than -loadprocedure fast. The following options are available for import into DB2 9 databases and support DB2 9 data row compression: -loadprocedure fast COMPRESS -loadprocedure fast LOADCOMPRESS These options cause that for tables created with compression enabled (i.e. COMPRESS YES), a compression dictionary is created after a certain number of rows has been inserted or loaded. You can define the number of rows by setting the environment variable DB6LOAD_COMPRESSION_THRESHOLD. The default value is 10,000 rows. By default, SAPinst invokes R3load with -loadprocedure fast. You can change the default by editing the SAPinst configuration file keydb.xml and changing the value of field "loadOptions". This can speed up considerably the import of large SAP BI PSA, DataStore and InfoCube fact tables. When changing the default settings for the loadprocedure parameter, R3load will decide for each table whether to use DB2 LOAD or not. For empty or very small tables it will use array insert because DB2 LOAD has some overhead that makes it slower than array insert in these cases. - 63 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
SAP OSS note 454173 contains important information about using R3load with DB2 LOAD. You should be aware of the following requirements and restrictions: DB2 LOAD uses TCP/IP ports for internal communication. By default, the ports 6000 through 60063 are reserved for LOAD. In large multi-partition environments, this might not be enough. The rule of thumb is to reserve #parallel LOADs * #logical partitions + 25% TCP/IP ports for DB2 LOAD. You define the ports for LOAD in DB2 registry variable DB2ADTLD_PORTS. For example, to reserve the ports 60000 to 6127 set DB2ADTLD_PORTS=6000:6127. When you use DB2 LOAD and create the indexes before loading the data a huge amount of temporary space might be required for sorting. Reduction of database logging You should run R3load with the -nolog option. With this option, tables will be created 'not logged initially'. When using this together with R3load import method loadprocedure dbsl or -loadprocedure fast data import will not be logged. This has no impact on R3load import with -loadprocedure fast because DB2 LOAD is not logged by default. Using the -nolog option is feasible because after the migration a database backup is mandatory. To drastically reduce logging during index creation you should use DB2 V8.2 (Fixpak 7) or higher. In Fixpak 7, the default logging behavior during index creation has been changed to only logging the beginning and the end of index creation instead of every index entry that is created. Index logging is also reduced if you create the indexes before importing the data. The default R3load behavior is to create both the primary key index and the secondary indexes after data import. To change this, edit the file DDLDB6.TPL in the export directory and change AFTER_LOAD to BEFORE_LOAD for the primary key as shown below:
prikey: AFTER_LOAD ORDER_BY_PKEY seckey: AFTER_LOAD prikey: BEFORE_LOAD ORDER_BY_PKEY seckey: BEFORE_LOAD
This slows down the import considerably because the indexes have to be maintained. But you save the index creation time after data import. Before changing the default behavior, you should try out in the test migrations whether the performance of creating the indexes before data import is acceptable or not.
6.4 SAP BI migration post processing

After database import, you have to run report RS_BW_POST_MIGRATION in background on the target system. There are two variants defined for the report: Variant SAP&POSTMGR is used when the database platform has not changed, i.e. in the case of a non-Unicode to Unicode migration.
Version 1.0 2007-07-24
Variant SAP&POSTMGRDB is used when the database platform has changed. It includes a number of additional repair operations that are necessary because of the SAP BI implementation differences on the different database platforms. The two variants are defined for background processing only. It is recommended to always run the report in background because it might run for several hours. RS_BW_POST_MIGRATION executes the following post migration tasks when called with variant SAP&POSTMGRDB: Step 1: Invalidation of SAP BI programs generated on the source system that contain database platform specific code Templates are used to generate programs for certain SAP BI maintenance tasks when InfoCubes, DataStore objects and PSA tables are created. These programs may contain database platform specific code that is no longer valid on the target database platform. Post processing invalidates the programs, so that they will be regenerated the next time the tasks are executed on the target system. Step 2: Generation of target database platform specific DBDIFF entries The table DBDIFF defines divergences in the implementation of tables and indexes from the SAP default, for example absence of standard primary key 0 indexes and the like. This post processing steps creates the necessary entries in DBDIFF for the target database platform. Step 3: Adaptation of the SAP data dictionary to the state in the target database R3load processing using DDL stored in .SQL files may lead to inconsistencies between the SAP data dictionary and the database. This post processing step adapts the information in the SAP data dictionary about tables and indexes to the state in the database. Indexes that do not exist in the target databases are deleted from the SAP data dictionary. Indexes that only exist in the target database bit not in the SAP data dictionary are created there. For indexes with a different structure or different uniqueness properties in the database than in the SAP data dictionary, the data dictionary information is adapted to the state in the database. This step only applies to InfoCube and aggregate fact and dimension tables. DataStore object and PSA tables are not included. Step 4: Generation of new PSA versions On some database systems, range partitioned PSA tables have an additional partitioning column PARTNO that does not exist in DB2 LUW. This post processing step drops all empty PSA tables that have a PARTNO column, recreates them without PARTNO and recreates the ABAP programs for PSA handling. For PSA tables containing data, it creates a new PSA version without the PARTNO column. Information about PSA table versions is stored in the SAP BI management tables. For this step to be successful, the source systems from which data is loaded into the PSA tables have to be online and accessible. This is a crucial post-processing step. If it fails, - 65 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
no data can be loaded from the source systems into the migrated SAP BI system. If there are any source systems not attached report RS_BW_POST_MIGRATION will abort. Step 5: Deletion of SAP BI temporary tables SAP BI 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_DROPTMPTABLES. Step 6: Repair of the InfoCube fact views On each InfoCube and aggregate, a UNION ALL view is defined on the F and the E fact table. The SAP data dictionary cannot handle UNION ALL views. During migration the views are created incorrectly in the target database. This is corrected in migration post processing by executing a report that drops and recreates them correctly in the target database. Step 7: Repair of partitioning column This is a specific activity for inventory InfoCubes. Step 8: Other database platform specific repairs For DB2 LUW as target platform this consists of adding the correct options for collecting statistics on SAP BI tables. For InfoCube fact and dimension tables and for master data tables, distribution and detailed index statistics are collected. This information is stored in table DBSTATC because it differs from the default. This migration post processing steps creates the required entries in table DBSTATC for the tables affected. When called with variant SAP&POSTMGR the report only executes the following tasks: Step 5: Deletion of SAP BI temporary tables Step 6: Repair of InfoCube fact views Please note that it is very important that all migration post-processing steps are executed successfully. Otherwise, unexpected errors will occur in the migrated system and it will not be usable. RS_BW_POST_MIGRATION writes a log file and a spool file that you should scan carefully for any error messages.
7. Tools for checking consistency of the DB2 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 SAP data dictionary of your migrated system are in a consistent and correct state. They are discussed briefly in the following sections.
7.1 Transaction DBACOCKPIT

Call transaction DB6COCKPIT and select Diagnostics - Missing tables and indexes from the tree menu on the left side. Tables and indexes that do not exist in the database but in the SAP data dictionary and vice versa are displayed. You can use this transaction to - 66 Copyright IBM Corporation, 2007 All Version 1.0 Rights Reserved. 2007-07-24
detect inconsistencies between the database and the SAP data dictionary after SAP BI migration post processing. When you changed the database platform, before post migration, there usually are inconsistencies due to the different implementations of SAP BI on the different database platforms (Figure 24). After post migration no more inconsistencies should exist (Figure 25). When you didnt 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. Click Refresh to determine the current state.
Figure 24: DB6COCKPIT: Missing tables and indexes before post migration
Version 1.0 2007-07-24
Figure 25: DB6COCKPIT: Missing tables and indexes after post migration
7.2 Checking the partitioning key of distributed SAP BI tables

There are three function modules available for checking the partitioning keys for InfoCube fact. PSA and DataStore tables: RSDU_CHKREP_PKEY_ALL_CUBES_DB6 checks the partitioning key of all InfoCube and aggregate F and E fact tables. RSDU_CHKREP_PKEY_ALL_ODS_DB6 checks the partitioning key of the DataStore activation queue, active and change log tables. RSDU_CHKREP_PKEY_ALL_PSA_DB6 checks the partitioning key of all PSA tables. SAP OSS note 648432 explains the usage of the function modules and the output they produce. If there are errors, there is a very high probability that R3load has not used the DDL statements in the .SQL files. - 68 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
7.3 SAP BI transaction RSRV

RSRV can be used for checking the indexes of sample InfoCubes and their aggregates Figure 26). 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. When double-clicking the InfoCube parameter, the available InfoCubes are displayed. After selecting an InfoCube, click Execute to run the test for this InfoCube and its aggregates. A report with the check results, as shown in Figure 27, is displayed.
Figure 26: RSRV: Checking database indexes of an InfoCube and its aggregates
Version 1.0 2007-07-24
Figure 27: RSRV: Checking database indexes of an InfoCube and its aggregates - Result
8. Potential problems, known issues and solutions / workarounds

8.1 Important SAP notes
Before starting a migration you should check the following SAP notes: 777024: BW 3.0 and BW 3.1 System Copy (supplementary note) 771209: NW04: System copy (supplementary note) 888210: NW2004s: System copy (supplementary note) Each note contains a database platform specific section with references to all relevant enhancements and fixes. These notes are regularly updated with the latest information. You should apply the fixes listed in these notes to avoid the problems in the following sections. - 70 Copyright IBM Corporation, 2007 All Version 1.0 Rights Reserved. 2007-07-24
SAP note 1023410 implements conversion of range partitioning on the source system to MDC on the DB2 target system. MDC support for SAP BW 3.0B, SAP BW 3.1 Content, and SAP NetWeaver 04 was introduced with the following support packages: Support package 32 for SAP BW 3.0B Support package 26 for SAP BW 3.1 Content Support package 18 for SAP NetWeaver 04 In these support packages and in support packages 1 to 9 for SAP NetWeaver 2004s, MDC for PSA tables is the default. If you do not want the DDL created to contain MDC for PSA tables you have to set DB6_MDC_FOR_PSA=NO on the source system before executing SMIGR_CREATE_DDL.
8.2 Uneven data distribution in multi-partition DB2 systems

After import into DB2, you notice that some database partitions contain much more data than others, although you distributed all tables evenly over the database partitions. This usually indicates that the partitioning keys of the tables distributed over the database partitions are not correct. This happens if R3load does not apply 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 in which 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. If you detect this problem after the import you can do nothing to repair it. You have to drop the affected tables and repeat the import. During R3load processing you have the following options for checking that the generated DDL is used: Check the R3load log file. It contains a warning message when no file with DDL statements to be applied is found. You can do some sanity checking: after one or a few tables in the task file have been processed run the DB2 db2look tool for them and compare the output to the DDL in the .SQL files.
Version 1.0 2007-07-24
After the import, you should always execute the function modules RSDU_CHKREP_PKEY_ALL_CUBES_DB6, RSDU_CHKREP_PKEY_ALL_PSA_DB6 and RSDU_CHKREP_PKEY_ALL_ODS_DB6 in the target system to ensure that all partitioning keys are correct.
8.3 Missing database indexes reported after RS_BW_POST_MIGRATION

After execution of RS_BW_POST_MIGRATION, DBACOCKPIT check Diagnostics Missing tables and indexes shows a large list of database indexes missing. These indexes could be: P indexes of F fact tables (like /BIC/F~P, /BI0/F~P, /BIC/FP, /BI0/FP) in a SAP NetWeaver 2004s system: You have not implemented SAP note 1049456. In SAP NetWeaver 2004s BI, P indexes on F fact tables are no longer created by default. However, step 2 of RS_BW_POST_MIGRATION inserts entries into table DBDIFF for these indexes. When an entry in table DBDIFF exists for an index the index is reported as missing. If you delete the entries for these indexes manually from table DBDIFF and refresh the table buffer these index errors are no longer reported. 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): You have implemented SAP notes 884124 and 933610 but not SAP note 948780. Step 3 of report RS_BW_POST_MIGRATION has created the 000 or P00 indexes in the SAP data dictionary. These indexes should neither exist in the SAP data dictionary nor in the database. To fix this issue a repair report is available that removes these indexes from the SAP data dictionary.
8.4 RS_BW_POST_MIGRATION aborts in Generation of new PSA versions

The post migration step Generation of new PSA versions can only be executed successfully if the source systems are attached to the SAP BI 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 fix this issue later and make sure that at least all other post migration steps are executed completely, you can generate a new variant for RS_BW_POST_MIGRATION that omits the generation of new PSA versions and run the report with this variant. Currently it is not possible to selectively generate new PSA versions for some source systems. - 72 Copyright IBM Corporation, 2007 All Version 1.0 Rights Reserved. 2007-07-24
8.5 Activation of aggregates or InfoCubes in the target system aborts

This error may occur in the following variants: 1. An SQL error occurs, indicating that the tablespaces for the tables do not exist. You have not implemented SAP note 919530. When executing report SMIGR_CREATE_DDL in the source system, entries in table DDSTORAGE for DB6 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 DB6-specific entries from table DDSTORAGE in the target system directly after the migration. 2. 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 may occur on SAP NetWeaver 2004s systems if you have not implemented SAP note 1062348 or you have 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 shown in section 6.1.1, the additional column used as partitioning column in the source system is not deleted in the DB2 LUW target system. Also the information that the column exists in the SAP BI metadata in table RSDCUBE is kept. Due to a program error fixed with the SAP note 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 which requires a table conversion if the tables contain data. 3. You transport an InfoCube definition from a development system to the production system. On the production system, the InfoCube exists and contains data. When 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 also occurs on SAP NetWeaver 2004s for InfoCubes that used range partitioning on the source system of the migration and is not solved yet. If the InfoCube is empty in the development system and changed and reactivated there the partitioning column is dropped and the SAP BI metadata updated accordingly. - 73 Copyright IBM Corporation, 2007 All Rights Reserved.
Version 1.0 2007-07-24
If this definition is transported to a target system were the InfoCube contains data the partitioning column cannot be dropped and the InfoCube activation fails.
8.6 Tables with incorrect DB2 features created for inactive aggregates
When running report SMIGR_CREATE_DDL on a non-DB2 system, DDL for aggregates that are not active cannot be generated. The output of report SMIGR_CREATE_DDL will contain messages like: Failed to create storage parameters for table: <table name>. If the tables for these aggregates have not been properly removed from the SAP data dictionary they will be created in the target database with incorrect partitioning key or indexes. This might lead to index errors in DBACOCKPIT. This is not a problem. When the aggregates are reactivated the tables will be dropped and recreated correctly in the DB2 system
9. Conclusion
This document has provided the details of the migration procedure for SAP BI and SAP BI-based systems, when the target database platform is DB2 LUW. Compared to other SAP system migrations, SAP BI system migrations require two additional steps to handle database specific features and implementation differences on different database platforms. The SAP BI information model and the implementation of SAP BI on DB2 LUW have been introduced briefly. The specific problems of SAP BI system migrations have been discussed. The steps of the migration process, i.e. SQL generation, export of the source database, installation and import of the target database, and SAP BI migration post processing have been discussed. Hints and tips for speeding up the export of the source database and the import into DB2 have been provided. Finally, transactions and reports for checking the consistency of the DB2 LUW target database after a migration have been described.
10. Literature
[1] SAP Service Marketplace, SAP NetWeaver BI section (http://service.sap.com/bi), Services & Implementation - Migration [2] General system copy information at the SAP Service Marketplace, http://service.sap.com/systemcopy [3] System Copy Guide: System Copy for SAP Systems Based on SAP NetWeaver 7.0 SR2 ABAP, 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] SAP Unicode Conversion Guides, http://service.sap.com/unicode@sap, Unicode library - Unicode conversion library
Version 1.0 2007-07-24
[6] Database administration Guide: SAP NetWeaver Business Intelligence 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 SR2 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] Building and Scaling SAP Business Information Warehouse on DB2 ESE, SG24-7094, IBM redbook, http://www.redbooks.ibm.com/ [12] IBM Redbook SAP Solutions on IBM DB2 V8.2.2 Handbook", SG24-6765, http://www.redbooks.ibm.com/ [13] 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/0308nesi em.html, July 2003 [14] Andreas Christian, Karl Fleckenstein, Stefan Kammerer: Performance Study for SAP Business Information Warehouse on DB2 Universal Database EEE http://www7b.boulder.ibm.com/dmdd/library/techarticle/0208christian/0208chri stian.html
Version 1.0 2007-07-24
Appendix A - List of relevant SAP notes

The following list contains the most important SAP notes related to migration to DB2, as of September 2007. 771209: NW04: System copy (supplementary note) 777024: BW 3.0 and BW 3.1 System Copy (supplementary note) 888210: NW2004s: System copy (supplementary note) 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: Unsinnige Indizes im DDIC nach Postmigration 933610: Heterogeneous system migration follow-on for Note 884124 919530: Error in aggregate activation after heterogeneous SAP NetWeaver BI system copy 917571: ABAP shortdump 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 - 76 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
799465: Datamart on partitioned Infocube returns SQL Syntax Error 615531: DB6: How to migrate a SAP BW 2.x system to DB6 548016 Conversion to Unicode
Version 1.0 2007-07-24
About the Author

Brigitte Blser is a Software Engineer at the IBM Bblingen Lab. She is responsible for integrating DB2 LUW solutions into SAP NetWeaver BI applications. Brigitte joined IBM 1984 and worked as software engineer in several database related projects. She has more than 15 years of experience with DB2 and 7 years of experience with SAP basis and SAP BI technology.
Version 1.0 2007-07-24
Copyrights, Trademarks & Disclaimer

Copyright IBM Corporation, 2007 All Rights Reserved. The SAP screenshots shown in the following figures are Copyright SAP AG and are used with SAPs kind permission: Figure 9: Report SMIGR_CREATE_DDL Figure 10: Source Database Export with SAP NetWeaver '04 SAPinst Figure 11: Report SAP_DROP_TMPTABLES Figure 12: SAP NetWeaver 2004s - ABAP target system installation Figure 13: SAP NetWeaver 2004s - Exit for creating additional database partitions Figure 14: SAP NetWeaver 2004s - Creation of additional database partitions Figure 15: SAP NetWeaver 2004s - Default mapping of database partition groups to partitions Figure 16: SAP NetWeaver '04 Target system installation Figure 17: SAP NetWeaver '04 Database installation method Figure 18: SAP NetWeaver '04 Adding database partitions Figure 19: SAP NetWeaver '04 - Mapping of database partitions to servers Figure 20: SAP NetWeaver '04 Exit for installing additional database partition servers Figure 24: DB6COCKPIT: Missing tables and indexes before post migration Figure 25: DB6COCKPIT: Missing tables and indexes after post migration Figure 26: RSRV: Checking database indexes of an InfoCube and its aggregates Figure 27: RSRV: Checking database indexes of an InfoCube and its aggregates Result All trademarks or registered trademarks mentioned herein are the property of their respective holders.
The information in this presentation may concern new products that IBM may or may not announce. Any discussion of OEM products is based upon information which has been publicly available and is subject to change. The specification of some of the features described in this presentation may change before the General Availability date of these products.
REFERENCES IN THIS PUBLICATION TO IBM PRODUCTS, PROGRAMS, OR SERVICES DO NOT IMPLY THAT IBM INTENDS TO MAKE THESE AVAILABLE IN ALL COUNTRIES IN WHICH IBM OPERATES. IBM MAY HAVE PATENTS OR PENDING PATENT APPLICATIONS COVERING SUBJECT MATTER IN THIS DOCUMENT. THE FURNISHING OF THIS DOCUMENT DOES NOT IMPLY GIVING LICENSE TO THESE PATENTS.
Version 1.0 2007-07-24
The following terms are registered trademarks of International Business Machines Corporation in the United States and/ or other countries: AIX, AIXwindows, AS/ 400, DB2, e( logo), IBM, IBM( logo), Information Warehouse, Netfinity, NUMA- Q, OS/ 2, OS/390, OS/ 400, Parallel Sysplex, PowerPC, PowerPC( logo), RISC System/ 6000, RS/ 6000, S/ 390, Sequent, SP2, System/ 390, The Engines of e- business, ThinkPad, Tivoli( logo), TURBOWAYS, VisualAge, WebSphere. The following terms are trademarks of International Business Machines Corporation in the United States and/ or other countries: AIX/ L, AIX/ L( logo), AS/ 400e, DB2 OLAP Server, DB2 Universal Database, e- business (logo), HACMP/ 6000, Intelligent Miner, iSeries, Network Station, NUMACenter, PowerPC Architecture, PowerPC 604, POWER2 Architecture, pSeries, Shark, SP, Tivoli Enterprise, TME 10, Videocharger, Visualization Data Explorer, xSeries, zSeries. A full list of U. S. trademarks owned by IBM may be found at http://iplswww.nas.ibm.com/wpts/trademarks/trademar.htm NetView, Tivoli and TME are registered trademarks and TME Enterprise is a trademark of Tivoli Systems, Inc. in the United States and/ or other countries. Microsoft, Windows, Windows NT and the Windows logo are registered trademarks of Microsoft Corporation in the United States and/ or other countries. SAP, mySAP, SAP NetWeaver, SAP NetWeaver BI, SAP BW, SAP R/3, SAP SCM, SAP SEM and other SAP products and services mentioned herein are trademarks or registered trademarks of SAP AG in Germany and in several other countries. More about SAP trademarks at. http://www.sap.com/company/legal/copyright/trademark.asp UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. Oracle is a registered trademark of Oracle Corporation in the United Status and/or other countries. LINUX is a registered trademark of Linus Torvalds. Intel and Pentium are registered trademarks and MMX, Itanium, Pentium II Xeon and Pentium III Xeon are trademarks of Intel Corporation in the United States and/ or other countries. Java and all Java- based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States and/ or other countries. Other company, product and service names may be trademarks or service marks of others. Information is provided "AS IS" without warranty of any kind. Information concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does - 80 Copyright IBM Corporation, 2007 All Rights Reserved. Version 1.0 2007-07-24
not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products.
Version 1.0 2007-07-24

IBM Heterogeneous SAP SysCopy To DB2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IBM Heterogeneous SAP SysCopy To DB2

Uploaded by

Copyright:

Available Formats

Heterogeneous SAP NetWeaver BI System Copy to IBM DB2 for Linux, UNIX and Windows

IBM SAP DB2 LUW Development

-1 Copyright IBM Corporation, 2007 All Rights Reserved.

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

-2 Copyright IBM Corporation, 2007 All Rights Reserved.

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

IBM SAP DB2 LUW Development

-4 Copyright IBM Corporation, 2007 All Rights Reserved.

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

-5 Copyright IBM Corporation, 2007 All Rights Reserved.

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

IBM SAP DB2 LUW Development

2. SAP BI information model

2.1 SAP BI information model elements

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

-8 Copyright IBM Corporation, 2007 All Rights Reserved.

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

Figure 1: Data flow in SAP BI

2.2 Mapping of information model elements to database tables

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

- 10 Copyright IBM Corporation, 2007 All Rights Reserved.

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

Figure 2: SAP BI extended star schema

IBM SAP DB2 LUW Development

3. SAP BI implementation on DB2 for Linux, UNIX and Windows

IBM SAP DB2 LUW Development

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

Figure 4: SAP BI on DB2 LUW layout with multiple database partitions

3.2 Support of clustered indexes

IBM SAP DB2 LUW Development

3.3 Support of multi-dimensional clustering (MDC)

Figure 5: MDC table

IBM SAP DB2 LUW Development

3.4 Support of DB2 9 row compression (deep compression)

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

3.5 Detailed SAP BI table layout on DB2 LUW

3.5.2 DataStore object tables

IBM SAP DB2 LUW Development

3.5.3 InfoCube and aggregate tables

- 18 Copyright IBM Corporation, 2007 All Rights Reserved.

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

3.6 Differences to SAP BI implementations on other database platforms

4. Issues of SAP BI system migrations

IBM SAP DB2 LUW Development

4.1 Issues related to size limits

Table 1: DB2 for LUW V8 tablespace size limits

Version 1.0 2007-07-24

IBM SAP DB2 LUW Development

Table 2: DB2 9 for LUW tablespace size limits

4.2 Issues related to database specific features and layout differences