IBM Heterogeneous SAP SysCopy To DB2

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

Business Intelligence (BI) System
Copy to IBM® DB2® for Linux®,
UNIX® and Windows®
Version 1.0
Brigitte Bläser
IBM SAP DB2 for Linux, UNIX and Windows
Development, IBM Lab Böblingen
-1-
© Copyright IBM Corporation, 2007 All Version 1.0
Rights Reserved. 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.
-2-
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-
8. Potential problems, known issues and solutions / workarounds........................... 70

8.1 Important SAP notes ......................................................................................... 70
8.2 Uneven data distribution in multi-partition DB2 systems ................................ 71
8.3 Missing database indexes reported after RS_BW_POST_MIGRATION ........ 72
8.4 RS_BW_POST_MIGRATION aborts in “Generation of new PSA versions”. 72
8.5 Activation of aggregates or InfoCubes in the target system aborts .................. 73
8.6 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
-4-
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
-5-
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-
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 decision-
making.
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-
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.
-8-
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-
'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. Write-
optimized DataStore objects are specifically designed for fast data load, without the
overhead of data activation and maintenance of a change log. Reporting only plays a
minor role.
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 -
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 -
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 -
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 -
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 medium-
sized 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 -
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 -
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 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 -
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 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:
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 -
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
- 18 -
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 doesn’t 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 -
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 hardware-
supported 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 -
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 Maximum Table Size

4 KB 64 GB
8 KB 128 GB
16 KB 256 GB
32 KB 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 Maximum Table Size

4 KB 2,048 GB
8 KB 4,096 GB
16 KB 8,192 GB
- 21 -
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.
- 22 -
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.
- 23 -
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 non-
Unicode to Unicode a number of reports have to be executed to make sure that the
target Unicode database can be set up correctly. For Unicode migrations please
consult [5].
2. Generation of the R3load control files. 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 -
<Export_Directory>
DATA DB LABEL.ASC
DB6 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 -
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.
- 26 -
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 -
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
- 28 -
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 -
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,
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~02" on "/BIC/FBFABCUBE5"
- 30 -
("KEY_BFABCUBE5T")
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. 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:
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL)
IN "&location&"
- 31 -
, "KEY_BFABCUBE52"
, "KEY_BFABCUBE5T"
, "KEY_BFABCUBE5U"
)
USING
HASHING
sql: CREATE INDEX "/BIC/FBFABCUBE5~P" on "/BIC/FBFABCUBE5"
("KEY_BFABCUBE5T",
"KEY_BFABCUBE51",
"KEY_BFABCUBE52",
"KEY_BFABCUBE5U",
"KEY_BFABCUBE5P")
CLUSTER
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"
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
- 32 -
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL)
IN "&location&"
, "KEY_BFABCUBE52"
, "KEY_BFABCUBE5T"
, "KEY_BFABCUBE5U"
)
USING
HASHING;
ALTER TABLE "/BIC/EBFABCUBE5" LOCKSIZE ROW;
ind: /BIC/EBFABCUBE5~0
ind: /BIC/EBFABCUBE5~P
sql: CREATE UNIQUE INDEX "/BIC/EBFABCUBE5~P" on "/BIC/EBFABCUBE5"
("KEY_BFABCUBE5T",
"KEY_BFABCUBE51",
"KEY_BFABCUBE52",
"KEY_BFABCUBE5U",
"KEY_BFABCUBE5P")
CLUSTER
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
- 33 -
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&"
PARTITIONING KEY ( "KEY_ZTPHTGC11"
, "KEY_ZTPHTGC1T"
, "KEY_ZTPHTGC1U"
)
USING
HASHING;
ALTER TABLE "/BIC/FZTPHTGC1" LOCKSIZE ROW;
ind: /BIC/FZTPHTGC1~0
sql: CREATE INDEX "/BIC/FZTPHTGC1~020" on "/BIC/FZTPHTGC1"
("KEY_ZTPHTGC1T")
CLUSTER
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 -
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"
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL)
IN "&location&"
, "KEY_ZTPHTGC1T"
, "KEY_ZTPHTGC1U"
)
USING
HASHING;
ALTER TABLE "/BIC/EZTPHTGC1" LOCKSIZE ROW;
ind: /BIC/EZTPHTGC1~0
ind: /BIC/EZTPHTGC1~P
sql: CREATE UNIQUE INDEX "/BIC/EZTPHTGC1~P" on "/BIC/EZTPHTGC1"
("KEY_ZTPHTGC1T",
"KEY_ZTPHTGC11",
"KEY_ZTPHTGC1U",
"KEY_ZTPHTGC1P")
CLUSTER
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 -
Starting with the following support packages you can convert range partitioning on fact
tables to MDC:
You also need the following SAP BASIS support packages:
• SAP BASIS 620 support package 62
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"
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL)
IN "&location&"
, "KEY_ZTPHTGC1T"
, "KEY_ZTPHTGC1U"
)
USING
HASHING
ORGANIZE BY ( "KEY_ZTPHTGC1P"
, "SID_0CALMONTH"
);
ALTER TABLE "/BIC/FZTPHTGC1" LOCKSIZE BLOCKINSERT;
- 36 -
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"
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL)
IN "&location&"
, "KEY_ZTPHTGC1T"
, "KEY_ZTPHTGC1U"
)
USING
HASHING
ORGANIZE BY ( "SID_0CALMONTH"
);
ALTER TABLE "/BIC/EZTPHTGC1" LOCKSIZE BLOCKINSERT;
ind: /BIC/EZTPHTGC1~P
sql: CREATE UNIQUE INDEX "/BIC/EZTPHTGC1~P" on "/BIC/EZTPHTGC1"
("KEY_ZTPHTGC1T",
"KEY_ZTPHTGC11",
"KEY_ZTPHTGC1U",
"KEY_ZTPHTGC1P")
- 37 -
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&"
LONG IN "&locationL&";
ALTER TABLE "/BIC/DBBLFAB51" LOCKSIZE ROW;
ind: /BIC/DBBLFAB51~0
sql: CREATE UNIQUE INDEX "/BIC/DBBLFAB51~0" on "/BIC/DBBLFAB51"
("DIMID")
ALTER TABLE "/BIC/DBBLFAB51"
ADD CONSTRAINT "/BIC/DBBLFAB51~0" primary key
("DIMID");
CREATE INDEX "/BIC/DBBLFAB51~020" on "/BIC/DBBLFAB51"
("SID_ZME_STATU")
("SID_ZCOUNTRY")
("SID_ZREGION")
- 38 -

("SID_ZEANUPC")
("SID_ZDISTR_CH")
("SID_ZFABSHPTO")
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)
"CALDAY" SAPDB6VARCHAR(000008)
DEFAULT '00000000' NOT NULL,
"/BIC/AO1" SAPDB6VARCHAR(000010)
"/BIC/KLAMM1" SAPDB6VARCHAR(000010)
"/BIC/REF1B1" SAPDB6VARCHAR(000010)
"/BIC/REF2REF1" SAPDB6VARCHAR(000010)
"/BIC/KENNZ1" INTEGER
DEFAULT 0 NOT NULL,
"/BIC/KENNZ2" DECIMAL(000017,000003)
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
"/BIC/KENNZ5" SAPDB6VARCHAR(000008)
- 39 -

DEFAULT 0 NOT NULL,
"CURRENCY" SAPDB6VARCHAR(000005)
"UNIT" SAPDB6VARCHAR(000003)
"RECORDMODE" SAPDB6VARCHAR(000001)
DEFAULT ' ' NOT NULL)
IN "&location&"
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")
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 non-
unique 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:
("SID" INTEGER
DEFAULT 0 NOT NULL,
"DATAPAKID" SAPDB6VARCHAR(000006)
"RECORD" INTEGER
DEFAULT 0 NOT NULL,
- 40 -

DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
IN "&location&"
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:
("REQUEST" SAPDB6VARCHAR(000030)
"PARTNO" INTEGER
DEFAULT 0 NOT NULL,
"RECORD" INTEGER
DEFAULT 0 NOT NULL,
- 41 -
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
IN "&location&"
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")
- 42 -
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"
"PARTNO" INTEGER
DEFAULT 0 NOT NULL,
"RECORD" INTEGER
DEFAULT 0 NOT NULL,
"/BIC/ZFABSHPTO" SAPDB6VARCHAR(000010)
"/BIC/ZEANUPC" SAPDB6VARCHAR(000018)
"/BIC/ZCOORDER" SAPDB6VARCHAR(000012)
"/BIC/ZREGION" SAPDB6VARCHAR(000003)
"/BIC/ZDISTR_CH" SAPDB6VARCHAR(000002)
"/BIC/ZME_STATU" SAPDB6VARCHAR(000002)
"/BIC/ZCRMEM_VA" SAPDB6VARCHAR(000017)
"/BIC/ZCRMEM_QT" SAPDB6VARCHAR(000017)
"/BIC/ZINVCD_VA" SAPDB6VARCHAR(000017)
"/BIC/ZINVCD_QT" SAPDB6VARCHAR(000017)
"/BIC/ZRTNSVAL" SAPDB6VARCHAR(000017)
"/BIC/ZRTNSQTY" SAPDB6VARCHAR(000017)
"/BIC/ZCOUNTRY" SAPDB6VARCHAR(000003)
IN "&location&"
- 43 -
)
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"
"PARTNO" INTEGER
DEFAULT 0 NOT NULL,
"RECORD" INTEGER
DEFAULT 0 NOT NULL,
"/BIC/ZFABSHPTO" SAPDB6VARCHAR(000010)
"/BIC/ZEANUPC" SAPDB6VARCHAR(000018)
"/BIC/ZCOORDER" SAPDB6VARCHAR(000012)
"/BIC/ZREGION" SAPDB6VARCHAR(000003)
"/BIC/ZDISTR_CH" SAPDB6VARCHAR(000002)
"/BIC/ZME_STATU" SAPDB6VARCHAR(000002)
"/BIC/ZCRMEM_VA" SAPDB6VARCHAR(000017)
"/BIC/ZCRMEM_QT" SAPDB6VARCHAR(000017)
"/BIC/ZINVCD_VA" SAPDB6VARCHAR(000017)
"/BIC/ZINVCD_QT" SAPDB6VARCHAR(000017)
"/BIC/ZRTNSVAL" SAPDB6VARCHAR(000017)
"/BIC/ZRTNSQTY" SAPDB6VARCHAR(000017)
"/BIC/ZCOUNTRY" SAPDB6VARCHAR(000003)
IN "&location&"
- 44 -
)
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
- 45 -
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 -
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.
- 47 -
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.
- 48 -
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.
- 49 -
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.
- 50 -
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 non-
Unicode system.
- 51 -
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.
- 52 -
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.
- 53 -
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).
- 54 -
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.
- 55 -
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 -
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
- 57 -
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 -
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:
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
- 59 -
DEFAULT 0 NOT NULL,

DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL)
IN "&location&"
, "KEY_BFABCUBE52"
, "KEY_BFABCUBE5T"
, "KEY_BFABCUBE5U"
)
USING
HASHING
sql: CREATE INDEX "/BIC/FBFABCUBE5~P" on "/BIC/FBFABCUBE5"
("KEY_BFABCUBE5T",
"KEY_BFABCUBE51",
"KEY_BFABCUBE52",
"KEY_BFABCUBE5U",
"KEY_BFABCUBE5P")
CLUSTER
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 /BIC/FBFABCUBE5 C xeq
D /BIC/FBFABCUBE5 I xeq
P /BIC/FBFABCUBE5~0 C xeq
I /BIC/FBFABCUBE5~01 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 -
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"
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL,
DEFAULT 0 NOT NULL)
IN "&location&"
, "KEY_BFABCUBE52"
, "KEY_BFABCUBE5T"
, "KEY_BFABCUBE5U"
)
USING
HASHING;
ALTER TABLE "/BIC/EBFABCUBE5" LOCKSIZE ROW;
- 61 -
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
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 /BIC/EBFABCUBE5 C xeq
D /BIC/EBFABCUBE5 I xeq
P /BIC/EBFABCUBE5~0 C xeq
I /BIC/EBFABCUBE5~01 C xeq
I /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.
- 62 -
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 -
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 prikey: BEFORE_LOAD ORDER_BY_PKEY
seckey: AFTER_LOAD 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.
- 64 -
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 -
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 -
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 didn’t 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
- 67 -
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 -
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
- 69 -
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 -
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.
- 71 -
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/F…P,
/BI0/F…P) 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 -
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 -
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
- 74 -
[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”,
[8] “SAP NetWeaver ‘04 SR1: Installation Guide SAP Business Warehouse 3.5”,
[9] SAP Installation Guide: SAP Business Information Warehouse Server 3.1 on
UNIX: IBM DB2 Universal Database for UNIX and Windows,
[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
- 75 -
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 -
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
- 77 -
About the Author

Brigitte Bläser is a Software Engineer at the IBM Böblingen 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.
- 78 -
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 SAP’s 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.
- 79 -
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 -
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.
- 81 -

IBM Heterogeneous SAP SysCopy To DB2

Uploaded by

Document Information

Original Description:

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 SAP DB2 LUW Development

IBM DB2 for Linux, UNIX and Windows

Heterogeneous SAP NetWeaver

8. Potential problems, known issues and solutions / workarounds........................... 70

2. SAP BI information model

2.1 SAP BI information model elements

Key figures: sales revenue, fixed costs, sales quantity, or number of

Figure 1: Data flow in SAP BI

2.2 Mapping of information model elements to database

2.2.2 DataStore Objects

2.2.3 InfoCubes and aggregates

Figure 2: SAP BI extended star schema

status of a request is appropriate, it can be compressed. During SAP BI InfoCube

2.2.4 Other SAP BI database tables

3. SAP BI implementation on DB2 for Linux, UNIX

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

3.2 Support of clustered indexes

3.3 Support of multi-dimensional clustering (MDC)

Figure 5: MDC table

3.4 Support of DB2 9 row compression (deep

3.5 Detailed SAP BI table layout on DB2 LUW

3.5.2 DataStore object tables

change log tables MDC is controlled by RSADMIN parameter DB6_MDC_FOR_PSA. If

3.5.3 InfoCube and aggregate tables

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

3.6 Differences to SAP BI implementations on other

4. Issues of SAP BI system migrations

4.1 Issues related to size limits

Tablespace Page Size Maximum Table Size

Tablespace Page Size Maximum Table Size

4.2 Issues related to database specific features and

5. Steps of a heterogeneous SAP system copy

Figure 6: Steps of a heterogeneous SAP system copy

6. Steps of a heterogeneous SAP BI system copy

Figure 8: Steps of a heterogeneous SAP BI system copy

6.1 Generation of the DDL for the target database

Figure 9: Report SMIGR_CREATE_DDL

ind: <Index name>

6.1.1 DDL examples for migrations from Oracle to DB2 LUW

• DB6_ROW_COMPRESSION: PSA, DataStore object tables and InfoCube and

• DB6_PINDEX_ON_FTABLE: the combined P index on F fact tables is created

CREATE INDEX "/BIC/DBBLFAB51~050" on "/BIC/DBBLFAB51"

DEFAULT '00000000' NOT NULL,

DEFAULT ' ' NOT NULL,

The CREATE TABLE statement contains the correct partitioning key. If

6.2 Exporting the source database

6.2.1 Hints and Tips for the Export

Figure 11: Report SAP_DROP_TMPTABLES

6.3 Creation and import of the target database

6.3.1 SAP NetWeaver 2004s

Figure 12: SAP NetWeaver 2004s - ABAP target system installation

Figure 14: SAP NetWeaver 2004s - Creation of additional database partitions

6.3.2 SAP NetWeaver ‘04

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

6.3.3 SAP BW 3.0B and 3.1 Content

6.3.4 Handling of database partition groups in multi-partition installations

6.3.5 Modified R3load processing during target database import

DEFAULT 0 NOT NULL,

6.3.6 Hints and tips to speed up the import