IBM Heterogeneous SAP SysCopy to DB2

7/15/2019 IBM Heterogeneous SAP SysCopy to DB2

1/81

Heterogeneous SAP NetWeaver BI System Copy to

IBM DB2 for Linux, UNIX and Windows

IBM SAP DB2 LUW Development

- 1 -

Copyright IBM Corporation, 2007 AllRights Reserved. Version 1.02007-07-24

Heterogeneous SAP NetWeaverBusiness Intelligence (BI) SystemCopy to IBM DB2 for Linux,

UNIX and Windows

Version 1.0

Brigitte Blser

IBM SAP DB2 for Linux, UNIX and Windows

Development, IBM Lab Bblingen


2/81




- 2 -


SummaryHeterogeneous SAP system copies, i.e. migrations of SAP systems to other databaseplatforms 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 isbecause, 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.


3/81




- 3 -


Table of ContentsSummary ......................................................................................................................... 2Table of Contents................................................................................................................ 3

List of Figures ..................................................................................................................... 51. 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 ....................... 123.1 Support of DPF ................................................................................................. 123.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) ................................. 163.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.................................................................. 183.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 ............................................................................... 214.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 ....................... 286.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 ....................................................... 476.3.1 SAP NetWeaver 2004s ............................................................................. 47

6.3.2 SAP NetWeaver 04.................................................................................. 51

6.3.3 SAP BW 3.0B and 3.1 Content................................................................. 566.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........................................................ 636.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


4/81




- 4 -


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 ................................ 718.3 Missing database indexes reported after RS_BW_POST_MIGRATION........ 72

8.4 RS_BW_POST_MIGRATION aborts in Generation of new PSA versions. 728.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


5/81




- 5 -


List of FiguresFigure 1: Data flow in SAP BI............................................................................................ 9Figure 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 ......................................................................................................... 15Figure 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............................. 48Figure 13: SAP NetWeaver 2004s - Exit for creating additional database partitions ...... 49Figure 14: SAP NetWeaver 2004s - Creation of additional database partitions............... 50Figure 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 ...... 57Figure 22: Defining additional tablespaces and database partition group in DBSIZE.XML

................................................................................................................................... 58

Figure 23: Input files to R3load for importing the target database................................... 59Figure 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


6/81




- 6 -


1. IntroductionHeterogeneous system copies of SAP BI systems (SAP Business Warehouse (BW) orSAP 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 isbecause 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 inthe structure of tables and the number and structure of secondary indexes for SAPNetWeaver 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 thetables 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 onthe 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 databaseplatform. Intended audiences are SAP migration consultants performing heterogeneoussystem 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 'SQLgeneration', 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


7/81




- 7 -


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 databaseplatform. 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 note777024 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 SAPNetWeaver 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 adifferent operating system, a different database platform or both. Heterogeneoussystem copies are also called migrations.

2. SAP BI information modelThis 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 operationaltransaction systems of the business.

Data warehouse, to hold transformed and accurate data that has been integratedfrom the business processes across the enterprise to enable business decision-

making.

2.1 SAP BI information model elementsThe following are the basic elements of the information model:

InfoObject: InfoObjects are the fundamental building blocks of the informationmodel. For example, InfoObjects may contain data about customers, sales orders,

products, and so on. InfoObjects are reused in other elements of the informationmodel, such as an InfoCube, DataStore object, and InfoSource. SAP BI

distinguishes between two types of data used in analysis:


8/81




- 8 -


Key figures: sales revenue, fixed costs, sales quantity, or number ofemployees, 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, whererequested 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 ofview, are grouped into InfoSources.

DataStore: DataStore objects (formerly ODS objects) describe consolidateddatasets 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 usedto 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, summarizedviews 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 organizationalstructure, 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 directlyload 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 andhow 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 oneor more data packages, each having a configurable maximum number of records. Within

the data packages of a request, the records are numbered.


9/81




- 9 -


Figure 1: Data flow in SAP BI

2.2 Mapping of information model elements to databasetables

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 manycustomers 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. Theactive table has the key fields and the data fields of the DataStore object ascolumns. 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


10/81




- 10 -


'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 lastactivation. 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 intoother 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 DataStoreobjects:

Standard DataStore objects consist of all three tables. When loading data into astandard 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 loadedinto 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 introducedthat 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 theoverhead 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 arrangedaccording to an extended star schema, as shown in Figure 2.


11/81




- 11 -


Figure 2: SAP BI extended star schema

The star schema places several dimension tables around a central fact table. The fact tablestores 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) uniquelyidentifies a particular combination of characteristic values in a dimension table, forexample, 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 thecharacteristic 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 canbe deleted from the F fact table if the data is, for example, not consistent. If the quality


12/81




- 12 -


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 thecharacteristic 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 databaseplatforms. 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 oftemporary 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, UNIXand 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


13/81




- 13 -


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 systemcopy 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 offour database partition groups:

SAPNODEGRP_ for the standard SAP basis tablespaces on databasepartition 0.

NGRP_DIM_ for the dimension tablespace, also residing on databasepartition 0

NGRP_FACT_ for the tablespace containing fact tables of InfoCubesand aggregates

NGRP_ODS_ for the tablespace containing PSA and DataStore objecttables

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


14/81




- 14 -


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 groupsNGRP_FACT_ and NGRP_ODS_ are distributed over database

partitions 1 to n while the database partition groups SAPNODEGRP_ and

NGRP_DIM_ 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 putthe 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 inthe 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


15/81




- 15 -


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 aresupported. MDC organizes the table data physically in blocks of pages. Each block

contains data records with the same values for the MDC dimensions. Importantdifferences 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

indexespoint to MDC blocks instead of individual records. For a table with multiple

MDC dimensions, block indexes are created on each dimension (dimension blockindexes) 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-inoperations profit from block locking, i.e. the locking of whole MDC blocks instead of


16/81




- 16 -


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 updelete 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 theSAP 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 MDCdimensions 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 (deepcompression)

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 informationabout 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 parameterDB6_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. Acompression 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 dataand 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.


17/81




- 17 -


3.5 Detailed SAP BI table layout on DB2 LUW

3.5.1 PSA tablesThe 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 parameterDB6_MDC_FOR_PSA. If the parameter is set to YES, PSA tables are created with MDCon the request ID column REQUEST. DB6_MDC_FOR_PSA=YES was the default in

the following support packages:



SAP NetWeaver 04 BI support package 18 SAP NetWeaver 2004s BI support package 1 to 9

Starting with the following support packages, DB6_MDC_FOR_PSA is set to NO by

default, i.e. PSA tables are not created as MDC tables:




SAP NetWeaver 2004s BI support package 10To 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 RSADMINparameter 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. Thisrestriction 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 recordnumber 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


18/81




- 18 -


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 REQUESTcolumn 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 KEYis 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, datapackage 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 onthese 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 arecreated 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 exceptfor 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_,where 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 thefollowing order:

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


19/81




- 19 -


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, thisindex is non-unique on SAP BI releases prior to SAP NetWeaver 2004s BI. On

NetWeaver 2004s BI, for non-APO InfoCubes, the combined index on F fact tables is not

created any more by default. In prior releases the index was needed for SAP BI InfoCube

compression. The new implementation in SAP NetWeaver 2004s BI doesnt rely on the

combined index any longer. Customers who need the index for SAP BI reporting can set

RSADMIN parameter DB6_PINDEX_ON_FTABLE to YES to enforce its creation.

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

Single column indexes on fact table dimension key columns

E fact tables have single-column indexes defined on the key columns of the user-defined

dimensions 1 to 9 and A to D and on the time dimension key column.

F fact tables have single-column indexes defined on the key columns of the user-defined

dimensions 1 to 9 and A to D and on the time and package dimension key columns. The

index on the time dimension key column is defined as clustering index if the combined

index on all dimension key columns does not exist.

MDC for fact tables

The user can select MDC dimensions from the user-defined InfoCube dimensions 1 to 9

and A to D and the time dimension. Alternatively to the time dimension, the user can also

select one of the time characteristics 0CALMONTH (calendar month) or 0FISCPER

(fiscal period). There is a soft limit for the number of MDC dimensions of three. If theuser selects a time characteristic an additional column SID_0CALMONTH orSID_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 partitioningfor 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


20/81




- 20 -


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 andDataStore object tables.

3.6 Differences to SAP BI implementations on otherdatabase 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 facttables 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 studythat shows that DB2 LUW almost scales linearly when adding additional database

partitions.

4. Issues of SAP BI system migrationsWhen migrating SAP BI systems, the following issues have to be dealt with:


21/81




- 21 -


SAP BI systems tend to get very large and to contain very large tables (InfoCubefact tables, PSA tables, DataStore active and change log tables). Therefore,

migrations have to be planned carefully to fit into the time window available forthem. Considerable effort might be necessary to determine the most efficient way

to export and import the very large tables through e.g. parallelization, use ofdatabase specific import methods, etc.

Different size limits for database objects on the source and target databaseplatform 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 specificfeatures have to be implemented. If they are not represented explicitly in the SAP

data dictionary standard R3load processing cannot handle them. This is a problemeven 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 largeSAP 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 limitsDB2 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


22/81




- 22 -


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 mightoccur:

The size of an Informix DBSPACE might exceed the size limit of the DB2 V8tablespace. In this case, the DB2 tablespace could be created with a larger pagesize, 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, tablesmight have to be moved to other tablespaces.

The size of a fragmented table in Informix might exceed the DB2 V8 tablespacesize 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, thetable 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 becreated 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 tocarefully 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 aggregatefact tables.

4.2 Issues related to database specific features andlayout 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.


23/81




- 23 -


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 copyHeterogeneous 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 thedifferent 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 forzSeries or iSeries.

When migrating from Linux to UNIX or Windows or vice versa

When migrating from non-Unicode to Unicode. Because the database code pagechanges 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.


24/81




- 24 -


Figure 6: Steps of a heterogeneous SAP system copy

On the source system, the following steps are executed:1. Migration preparations consist in the execution of reports and transactions that are

described in detail in [3] for systems based on SAP NetWeaver 2004s and [4] for

systems based on SAP NetWeaver 04. Especially when migrating from 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 thedatabase 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 tablespacecontainers. These estimations are often not very accurate. The real sizes have tobe 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 R3loadby 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.


25/81




- 25 -


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 datadictionary structure information. DDLDB6.TPL is a template for the DDL statementsused 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 examplevia 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 estimationsfrom 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] tocomplete 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 copyStarting 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 databaseplatform 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 inthe target database.

DATA DB LABEL.ASC

DB6 DDLDB6.TPL


26/81




- 26 -


On the target system, after database import, a report has to be executed thatperforms 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 theSAP 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.


27/81




- 27 -


6.1 Generation of the DDL for the target databaseTo 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 thedialog 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 .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, nomore 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 lockedfor 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.


28/81




- 28 -


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: sql:

ind: sql:

For each table there is an entry labeled tab: with the table name and the DDL for thetable 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 tablesand PSA tables

Row compression

Indexes missing on the source database platform but required for DB2, forexample 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 tablesAfter 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 LUWWe discuss in section 6.3.5 how R3load uses the DDL to create all tables and indexes inthe 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 thesource system but are not to be created in the DB2 LUW target database, entries without


29/81




- 29 -


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 systemcatalog 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 changelog tables are created with MDC if the parameter is set to YES and without MDCif the parameter is set to NO. YES is the default for the following supportpackages:

o SAP BW 3.0B support package 32o SAP BW 3.1 Content support package 26o SAP NetWeaver 04 BI support package 18o 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 andaggregate 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 isthe default. This option is available with the following support packages:

o SAP BW 3.0B support package 33o SAP BW 3.1 Content support package 27o SAP NetWeaver 04 BI support package 19o 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 compressionactivated.

DB6_PINDEX_ON_FTABLE: the combined P index on F fact tables is createdif 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.


30/81




- 30 -


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 onthe 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" INTEGERDEFAULT 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"


31/81




- 31 -


("KEY_BFABCUBE5T")

CLUSTER

ALLOW REVERSE SCANS;


The sql section below the tab: entry contains the CREATE TABLE statement with thecorrect 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 indexis 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 theOracle database. The empty sql section avoids that the index is created in DB2 LUW.

If RSADMIN parameter DB6_PINDEX_ON_FTABLE was set to YES the following

DDL would be generated:tab: /BIC/FBFABCUBE5

sql: CREATE TABLE "/BIC/FBFABCUBE5"("KEY_BFABCUBE5P" INTEGER

DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,

"KEY_BFABCUBE5U" INTEGER

DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,"/BIC/BINVCD_VA" DECIMAL(000017,000002)

DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,

"/BIC/BRTNSVAL" DECIMAL(000017,000002)

DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL)

IN "&location&"



32/81




- 32 -




, "KEY_BFABCUBE52"

, "KEY_BFABCUBE5T", "KEY_BFABCUBE5U"

)

USING

HASHING

ALTER TABLE "/BIC/FBFABCUBE5" LOCKSIZE ROW;


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 asclustered 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 inthe 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 indexinstead.

An entry for index /BIC/FBFABCUBE5~02 is not needed because it is not created asclustering index and therefore has no DB2 LUW specific features that R3load cannothandle.

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

tab: /BIC/EBFABCUBE5

sql: CREATE TABLE "/BIC/EBFABCUBE5"

("KEY_BFABCUBE5P" INTEGER

DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,"KEY_BFABCUBE5U" INTEGER

DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,


33/81




- 33 -


"/BIC/BINVCD_VA" DECIMAL(000017,000002)

DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL,"/BIC/BRTNSVAL" DECIMAL(000017,000002)

DEFAULT 0 NOT NULL,


DEFAULT 0 NOT NULL)

IN "&location&"




, "KEY_BFABCUBE52"

, "KEY_BFABCUBE5T"

, "KEY_BFABCUBE5U"

)

USINGHASHING;

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 facttables 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


34/81




- 34 -


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" INTEGERDEFAULT 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 rangepartitioning. 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


35/81




- 35 -


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 usesrange 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,

"SID_0CALMONTH" INTEGERDEFAULT 0 NOT NULL,

"/BIC/HTGKF1" INTEGER

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~010

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 rangepartitioning. This column remains in the table although DB2 LUW will not makeuse of it.

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

InfoCube fact tables with range partitioning and conversion of rangepartitioning to MDC


36/81




- 36 -


Starting with the following support packages you can convert range partitioning on fact

tables to MDC:

SAP BW 3.0B support package 34 SAP BW 3.1 Content support package 28


SAP NetWeaver 2004s BI support package 13You 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 fieldDatabase 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,

"SID_0CALMONTH" INTEGER

DEFAULT 0 NOT NULL,"/BIC/HTGKF1" INTEGER

DEFAULT 0 NOT NULL)

IN "&location&"




, "KEY_ZTPHTGC1T"

, "KEY_ZTPHTGC1U"

)

USING

HASHING

ORGANIZE BY ( "KEY_ZTPHTGC1P"

, "SID_0CALMONTH"

);

ALTER TABLE "/BIC/FZTPHTGC1" LOCKSIZE BLOCKINSERT;





37/81




- 37 -


The CREATE TABLE statement for the F fact table contains the correct partitioning key

and the package di

Date post:	30-Oct-2015
Category:	Documents
Upload:	kishore-dammavalam
View:	92 times
Download:	0 times

IBM Heterogeneous SAP SysCopy to DB2

Documents