SAP Business Warehouse on IBM Db2 10.5 and Higher for ...€¦ · Hardware and Software...

Database Administration Guide PUBLIC

Document Version: 4.0 – 2018-03-27

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksFor SAP Business Warehouse 7.0 (Including SAP Enhancement Packages)For SAP Business Warehouse 7.3 and HigherFor IBM Db2 10.5 and Higher

Content

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1 Document History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Naming Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 SAP Business Warehouse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Essential Settings and Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1 Db2 Parameters for SAP BW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Configuring Intrapartition Parallelism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

3 BLU Acceleration for SAP BW Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183.1 SAP BW Objects Supported with BLU Acceleration: Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 SAP BW Objects Supported with BLU Acceleration: Additional Information and Recommendations

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Checklist: Enabling an Installed SAP BW System for BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . 203.4 Prerequisites for BLU Acceleration on SAP Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Hardware and Software Requirements for BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . 22Required Minimum SAP BASIS and SAP BW Support Packages. . . . . . . . . . . . . . . . . . . . . . . . . 23Required SAP Notes for SAP BW with BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.5 Required Configuration and Settings for BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Adapting Your DB and DBM Configuration for BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . 25Setting the Db2 Threshold for the Number of Parallel BLU Queries. . . . . . . . . . . . . . . . . . . . . . . 25SAP Profile Parameters for BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Setting the Default Format of SAP BW Objects to BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . 28

3.6 Creating SAP BW Objects for BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Creating SAP BW Objects for BLU Acceleration Automatically or Manually. . . . . . . . . . . . . . . . . 30Creating Flat InfoCubes (As of SAP BW 7.4). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 Converting SAP BW Objects to BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Checking Which BW Objects Are Eligible for BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . 32Converting Row-Organized SAP BW Objects to BLU Acceleration and Vice Versa. . . . . . . . . . . . . 32Executing a Mass Conversion of Standard InfoCubes to Flat InfoCubes. . . . . . . . . . . . . . . . . . . . 34Converting Single Standard InfoCubes to Flat InfoCubes and Vice Versa. . . . . . . . . . . . . . . . . . . 35

3.8 Considerations for Creation, Copy, Aggregation, and Transport with BLU Acceleration. . . . . . . . . . . 383.9 Setting Up Parallel Batch Jobs for InfoObjects (SAP BW 7.0x Only). . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Additional Tablespaces and Data Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.1 Database and File System Layout After the Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Naming Conventions for New Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

2 P U B L I C

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration Tasks

Content

4.3 Creating Database Partition Groups (DPF Only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4 Creating Tablespaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5 Creating Data Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.6 Changing the Data Classes of InfoCubes, DataStore Objects, and PSA Tables. . . . . . . . . . . . . . . . . . 47

Changing the Data Classes of InfoCubes and Their Aggregates. . . . . . . . . . . . . . . . . . . . . . . . . 48Changing the Data Classes of DataStore Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Changing the Data Classes of PSA Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

5 Direct Execution of Queries with Restrictions (FEMS Queries). . . . . . . . . . . . . . . . . . . . . . . . . 515.1 Queries with Local Restrictions (FEMS Queries): Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 Prerequisites and Constraints for Direct FEMS Query Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . 545.3 Enabling FEMS Query Processing in the Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.4 Enabling or Disabling FEMS Query Processing at the InfoCube or DataStore Object Level. . . . . . . . . 565.5 Enabling or Disabling FEMS Query Processing at the Query Level. . . . . . . . . . . . . . . . . . . . . . . . . . 59

6 Settings for Non-BLU Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.1 Db2 Compression (Non-BLU Systems Only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Enabling Compression Centrally Using the Global Compression Option. . . . . . . . . . . . . . . . . . . .636.2 Multidimensional Clustering (Non-BLU Systems Only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Basic Table Layout and Index Clustering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Multidimensional Clustering (MDC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Implementing Multidimensional Clustering (MDC) for SAP BW Objects. . . . . . . . . . . . . . . . . . . 68Considerations for Creation, Copy, Transport, and Aggregates with MDC. . . . . . . . . . . . . . . . . . 96

7 Db2 Database Partitioning Feature (DPF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977.1 Number of Partitions and Hardware Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.2 Arguments to Consider for and Against DPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1017.3 Implementing Multiple Partitions Using the Database Partitioning Feature. . . . . . . . . . . . . . . . . . . 102

Planning the Multipartition Database Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Adding New Data Partitions to the Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.4 Optimized Data Activation for DataStore Objects Using Massive Parallel Processing (MPP). . . . . . . .118Prerequisites and Constraints for MPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119MPP Activation Phases and Active Log Space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Example: Activating a DataStore Object Using MPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Tracing the SQL Statements Used with MPP-Optimized Data Activation. . . . . . . . . . . . . . . . . . .123Disabling and Re-Enabling MPP-Optimized Data Activation for DataStore Objects. . . . . . . . . . . 123

8 Db2 pureScale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.1 Implementing Db2 pureScale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

9 Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319.1 Dealing with System Growth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319.2 Considerations for High Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksContent P U B L I C 3

9.3 SAP BW Health Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339.4 Controlling Database Log Space Consumption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359.5 Recommendations for InfoCube Compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379.6 Improving the Compression Performance of Column-Organized InfoCubes. . . . . . . . . . . . . . . . . . . 1389.7 Activating Db2 Automatic Reorganization for Index Cleanup and Space Reclamation. . . . . . . . . . . . 1399.8 Using the Mass Cube Writer for Loading Data into InfoCubes (As of SAP NetWeaver 7.3). . . . . . . . . 1409.9 Changing the Table Layout for P, Q, and Text Tables of New InfoObjects to Row-Organized. . . . . . . . .1419.10 Temporarily Disabling BLU Acceleration for New BW Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

10 Additional Sources of Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

11 Appendix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14711.1 BLU Acceleration: Additional Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14711.2 Checklist: Upgrading an SAP BW System from Db2 10.5 FP3aSAP to 10.5 FP5SAP2. . . . . . . . . . . . 14811.3 Migrating an SAP BW System to Db2 for LUW for the Use of Db2 BLU Acceleration. . . . . . . . . . . . . 149

Migrating an SAP BW to Db2 with a Later Conversion to BLU Acceleration. . . . . . . . . . . . . . . . . 150Checklist: Migrating an SAP BW System to Db2 Including Conversion to BLU Acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Running the Migration Program for SAP BW Objects Including BLU Acceleration. . . . . . . . . . . . 152Creating a New Directory for Large Temporary Files for BLU Acceleration During Load. . . . . . . . 154

11.4 SAP BW Tables Considered for Db2 BLU Acceleration: Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 15511.5 Table Layout Options for SAP BW Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Table Layout Options for SAP BW Objects: Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Table Layout Options for Persistent Staging Areas (PSA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Table Layout Options for Standard DataStore Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Table Layout Options for DataStore Objects for Direct Update. . . . . . . . . . . . . . . . . . . . . . . . . 164Table Layout Options for Write-Optimized DataStore Objects. . . . . . . . . . . . . . . . . . . . . . . . . . 164Table Layout Options for Standard and Real-Time InfoCubes. . . . . . . . . . . . . . . . . . . . . . . . . . 166Table Layout Options for Aggregates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Table Layout Options for Flat InfoCubes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Table Layout Options for InfoObjects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

12 Disclaimer: Links to IBM Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

4 P U B L I C


Content

1 Introduction

This documentation helps you to set up and administer an SAP Business Warehouse (SAP BW) system running on IBM Db2 10.5 and higher for Linux, UNIX, and Windows.

The documentation is valid for online analytical processing systems (OLAP systems) that are based on SAP BW 7.0 (including SAP enhancement packages) and on SAP BW 7.3 and higher. This also includes SAP systems with an SAP BW component, such as SAP Supply Chain Management (SAP SCM) or SAP Strategic Enterprise Management (SAP SEM).

If you use IBM Db2 version 10.1 or lower, please use the database administration guide SAP Business Warehouse on IBM Db2 10.1 and Lower for Linux, UNIX, and Windows: Administration Tasks at http://help.sap.com/viewer/db6_bw_10_1.

Getting Started: The Essentials

You're new to SAP BW administration and eager to learn the essentials? To get an overview of the most important settings, follow the links below:

● Db2 Parameters for SAP BW [page 14]● Configuring Intrapartition Parallelism [page 15]● Checklist: Enabling an Installed SAP BW System for BLU Acceleration [page 20]

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksIntroduction P U B L I C 5

http://help.sap.com/viewer/db6_bw_10_1

http://help.sap.com/viewer/db6_bw_10_1

● Additional Tablespaces and Data Classes [page 41]

1.1 Document History

CautionBefore you start the implementation, make sure that you have the latest version of this documentation from SAP Help Portal at https://help.sap.com/viewer/db6_bw. For more information about the latest corrections and news after the publication of this guide, see SAP Note 2058468 .

This documentation is relevant only for SAP BW systems on IBM Db2 10.5 and higher. If you use IBM Db2 10.1 and lower, there's a separate guide available at https://help.sap.com/viewer/db6_bw_10_1.

The following tables provide an overview of the most important document changes of this documentation:

Document History of Current Guide

Version Date Description

4.0 2018-03-27 Completely revised and updated guide, which supersedes the previous guide.

Updates:

● Updated recommendations for intrapartition parallelism, database partitioning, and BLU Acceleration

● New program SAP_BLU_CONVERSION_CHECK_DB6 for checking BW objects as candidates for BLU Acceleration

● Updated links to additional SAP and IBM documentation

The previous version of this guide included information for all supported IBM Db2 versions, from version 9.1 to 11.1. There are now two database administration guides for SAP Business Warehouse on IBM Db2 for Linux, UNIX, and Windows: one for Db2 10.1 and lower, and one for Db2 10.5 and higher.

6 P U B L I C


Introduction

https://help.sap.com/viewer/db6_bw

http://help.sap.com/disclaimer?site=https://launchpad.support.sap.com/#/notes/2058468

https://help.sap.com/viewer/db6_bw_10_1

Document History of Previous Guide


3.8 2017-08-03 Updates:

● New program RSDU_IC_STARFLAT_MASSCONV for mass conversion of standard InfoCubes to flat InfoCubes is available.

● New RSADMIN parameter DB6_ALLOW_CDE for disabling BLU Acceleration in the entire SAP system is available.

● Compression performance of column-organized InfoCubes can be influenced using new RSADMIN parameter.

● FEMS query processing at database level is now also supported for DataStore objects.

Minor corrections and updates:

● Corrected unique indexes of InfoCubes (see Table Layout for SAP BW Objects)

● Updated default value: 3,000,000 for parameter DBMS_MAX_DELETE for multidimensional clustering

● “IBM DB2 for Linux, UNIX, and Windows” renamed to “IBM Db2 for Linux, UNIX, and Windows”.

3.75 2016-12-23 Updates:

● Creating and Converting SAP BW Objects for BLU Acceleration: New RSADMIN parameters; InfoCubes and DataStore objects can now be created with BLU Acceleration format by default

● Additional SAP Notes for BLU Acceleration● Updated SAP Profile parameters for BLU Acceleration

3.7 2016-11-24 Updates:

● Information about IBM DB2 11.1 has been added (documentation links, SAP Notes).

● As of DB2 11.1, BLU Acceleration can be used with partitioned databases (DPF) for SAP BW.

● Recommendations for using partitioning have been updated.● More details about which SAP BW tables are converted to column-organ

ized for BLU Acceleration have been added.● Database and File System Layout After the Installation was updated.

3.6 2016-07-25 Update and corrections:

● New recommendation for database configuration parameter MAX_QUERYDEGREE

● Updated and corrected information about table layout options and indexes of InfoCubes

● New RSADMIN parameter DB6_IOBJ_PQT_USE_CDE for InfoObjects

● Support for FEMS queries● Mass cube writer for loading data into InfoCubes



3.5 2016-01-15 Update and correction:

● Updated hardware and software requirements for BLU Acceleration (see Hardware and Software Requirements for BLU Acceleration [page 22])

● Corrected profile parameter dbs/db6/deny_cdefield_extension (see Checklist: Migrating an SAP BW System to Db2 Including Conversion to BLU Acceleration [page 151])

3.45 2015-11-30 Correction: Conversion of semantically partitioned InfoCubes to flat InfoCubes is not supported.

3.4 2015-11-02 Minor corrections

Addition of Setting Up Parallel Batch Jobs for InfoObjects (SAP BW 7.0x Only) [page 39]

3.3 2015-09-02 Update: As of DB2 10.5 FP5SAP2 and SAP Note 2182946, column-organized P, Q, and text tables for InfoObjects are supported.

3.25 2015-06-15 Correction about BW metadata in Redistributing Data Using Report DB6CONV

3.2 2015-03-31 Update: As of SAP Business Warehouse 7.4 SP10, the creation of flat InfoCubes using the Data Warehousing Workbench is now supported.

3.1 2015-03-24 Update: Windows supported for BLU Acceleration with DB2 10.5 FP5SAP; additional checklists and guidelines for implementing BLU Acceleration

3.0 2014-10-15 There were two guides in the past, one for SAP systems based on SAP BW 7.0 (including SAP enhancement packages), and one for SAP systems based on SAP BW 7.3 and higher. These previous guides have been merged into one guide with guide version 3.0.

Document completely revised and updated; additional recommendations for database layout planning and table layout planning

1.2 Naming Conventions

Renaming: IBM DB2 for Linux, UNIX, and Windows is now IBM Db2

You might wonder why we spell Db2 with a lowercase 'b' now. IBM has changed the database name from “IBM DB2 for Linux, UNIX, and Windows” to “IBM Db2 for Linux, UNIX, and Windows” or simply “IBM Db2”. In this documentation, we use “IBM Db2” or “Db2” to refer to the Db2 database, regardless of its version. In older SAP publications, you will also still find the old product name, but in all future documentation, we will gradually use the new term, sometimes extended by “for Linux, UNIX, and Windows” to avoid confusion with other products of the IBM Db2 family, such as IBM Db2 for z/OS or IBM Db2 for i.

8 P U B L I C


Introduction

Short Versions

In this documentation, we also use the following short versions:

Database Names

Full Name Short Version

IBM Db2 Version 11.1 for Linux, UNIX, and Windows Db2 11.1

IBM Db2 Version 10.5 for Linux, UNIX, and Windows Db2 10.5

1.3 SAP Business Warehouse

If you're just starting as an SAP BW administrator, this section might be helpful for you: It provides a short introduction to SAP BW and SAP BW objects, which will be mentioned throughout this documentation.

With SAP Business Warehouse (SAP BW), you can integrate, transform, and consolidate relevant business information from production SAP applications and external data sources. SAP BW provides an infrastructure for business planning, enterprise reporting, and analysis. Decision makers can identify target-oriented activities on the basis of the analyzed data.

SAP BW can extract master data and transaction data from various sources and store it in the data warehouse.

Data Flow in SAP BW


Objects in SAP Business Warehouse

Persistent Staging Area (PSA)The Persistent Staging Area (PSA) is the inbound storage area in SAP BW for data from the source systems. The requested data is saved unchanged in the PSA. “Unchanged” means that no summarization or transformations take place. PSAs are implemented with one database table per data source.

InfoObjectsInfoObjects are the smallest information units in SAP BW. They structure the information needed to create InfoProviders, such as InfoCubes or DataStore objects.

InfoObjects can be divided into characteristics, key figures, units, time characteristics, and technical characteristics:

● Characteristics are sorting keys, such as company code, product, customer group, fiscal year, period, or region.

● Key figures provide the values that are reported on in a query. Key figures can be a quantity, an amount, or the number of items.

● Units are also required so that the values for the key figures have meanings. Key figures of type amount are always assigned a currency key. Key figures of type quantity also have a unit of measurement.

● Time characteristics are date, fiscal year, and so on.● Technical characteristics are used for administrative purposes only within SAP BW. An example of a

technical characteristic is the request number in the InfoCube. The request number is generated when you load a request as an ID, and helps you locate the request at a later date.

If characteristics have attributes, texts, or hierarchies, they are referred to as master data-bearing characteristics. Master data remains unchanged over a long period of time, and contains information that is always needed in the same way.

InfoObjects for characteristics consist of several database tables that contain information about time-independent and time-dependent attributes, hierarchies, and texts in the languages needed. The central table for characteristics is the surrogate identifier table (SID table) that associates the characteristics with an integer called SID. The SID is used as foreign key to the characteristic in the dimension tables of InfoCubes.

Standard InfoCube and Real-Time InfoCubeFrom an analysis point of view, an InfoCube describes a self-contained data set, for example, for a business-oriented area. A standard InfoCube consists of two fact tables: the F fact table, which contains recently loaded data, and the E fact table, which contains the loaded data in compressed format. The fact tables are surrounded by dimension tables. The fact tables store the key figures of the InfoCube, whereas the characteristics of the InfoCube are stored in the dimension tables. This type of structure is also referred to as an “enhanced star schema”.

10 P U B L I C


Introduction

Enhanced Star Schema

This type of structure applies to standard InfoCubes and real-time (transactional) InfoCubes.

InfoCube AggregatesTo speed up reporting, you can create aggregates for standard InfoCubes. In aggregates, precalculated InfoCube data is stored redundantly and in an aggregated form.

DimensionsA dimension is the grouping of classification groups (characteristics) whose content is logically connected under a single generic term. For example, the customer dimension could be made up of the customer number, the customer group, and the levels of the customer hierarchy. The sales dimension could contain the characteristics Sales Person, Sales Group, and Sales Office. The time dimension could consist of the characteristics Day, Week, Month, Year, and Period.

Dimension tables are part of InfoCubes (see InfoCube [page 10] section).

Flat InfoCubesA flat InfoCube is an InfoCube with a simplified schema: only a package dimension table is created; all other dimension tables and the E fact table are eliminated. The SIDs of the master data are directly stored in the F fact table. This improves system performance when data is loaded.

In the SAP Data Warehousing Workbench (transaction RSA1), dimensions of flat InfoCubes are still visible and are maintained, that is, the InfoObjects of an InfoCube are added to the (logical) dimensions. However, the InfoCube dimensions are not materialized as dimension tables in the database.


Enhanced Star Schema for Standard InfoCubes and Star Schema for Flat InfoCubes

The structure of flat InfoCubes is optimized for use with the SAP HANA database; this is why flat InfoCubes are also referred to as “SAP HANA-optimized InfoCubes”. For databases other than SAP HANA, flat InfoCubes are available only as of SAP BW 7.4 Support Package 8.

Flat InfoCubes are supported for both cumulative and non-cumulative InfoCubes.

You can run InfoCube compression on flat InfoCubes. Compressed and uncompressed data is stored in the same fact table (the F fact table).

Flat InfoCubes have the following advantages:

● Reporting queries might run faster because fewer tables need to be joined.● Data propagation into flat InfoCubes might be faster because no dimension tables need to be maintained.

This is especially true in cases where dimension tables are very large.

The following restrictions apply to flat InfoCubes:

● Flat InfoCubes cannot be stored in the SAP Business Warehouse Accelerator (BWA).● No aggregates can be created for flat InfoCubes.

DataStore Objects

A DataStore object (DSO) serves as a storage location for consolidated and cleansed transaction data or master data at the document level. This data can be evaluated using a query. Unlike the multidimensional data storage that uses InfoCubes, the data in DataStore objects is stored in flat database tables.

12 P U B L I C


Introduction

DataStore object types include the following:

● Standard DataStore objectThis DataStore object consists of three tables (activation queue, active data, and change log) that permit detailed data storage. Data is loaded into the activation queue table using the data transfer process in SAP BW. The data is not visible in the data warehouse of the SAP BW system until it has been processed by a procedure referred to as “data activation for DataStore objects” (DSO data activation). During activation, the data is transferred from the activation queue to the active table of the DataStore object, where it can be used for further processing in the data warehouse of SAP BW. The changes to the active table are stored in the change log table.

● Write-optimized DataStore objectThis DataStore object consists of only one table of active data. Data is loaded using the data transfer process in SAP BW.

● DataStore object for direct updateThe DataStore object for direct update consists of only a table for active data, and usually receives its data from external systems through APIs for filling or deletion.

Semantically Partitioned InfoCubes and DataStore Objects (As of SAP BW 7.3)A semantically partitioned InfoCube is an InfoCube that consists of several InfoCubes with the same structure. Semantic partitioning is a property that you specify when you create an InfoCube. Semantic partitioning divides the InfoCube into several small, equally sized units (partitions).

The same applies for DataStore objects.

More Information

SAP Business Warehouse documentation for 7.0-based releases on SAP Help Portal at https://help.sap.com/viewer/p/SAP_NETWEAVER SAP NetWeaver 7.0 <Including SAP Enhancement Package> SAP NetWeaver By Key Capability Information Integration by Key Capability Business Intelligence Data Warehousing Modeling Enterprise Warehouse Data Layer and Architected Data Mart Layer

SAP Business Warehouse documentation for release 7.3 and higher on SAP Help Portal at https://help.sap.com/viewer/p/SAP_BUSINESS_WAREHOUSE SAP BW Documentation (English) Data Warehousing Modeling Enterprise Warehouse Data Layer and Architected Data Mart Layer


https://help.sap.com/viewer/p/SAP_NETWEAVER

https://help.sap.com/viewer/p/SAP_NETWEAVER

https://help.sap.com/viewer/p/SAP_BUSINESS_WAREHOUSE

https://help.sap.com/viewer/p/SAP_BUSINESS_WAREHOUSE

2 Essential Settings and Recommendations

An SAP Business Warehouse system running on IBM Db2 for Linux, UNIX, and Windows requires some settings that are different from other SAP systems running on IBM Db2. Here you'll get an overview.

● Set the necessary Db2 parameters.● We recommend that you use intrapartition parallelism.● We recommend that you use BLU Acceleration, which is available as of Db2 10.5.

2.1 Db2 Parameters for SAP BW

Ensure that Db2 parameters for SAP BW are set, including settings for the database manager, database configuration, and recommended buffer pool sizes.

For more information, see the SAP Note for your database version:

Database Version SAP Note Number

Db2 11.1 2303771

Db2 10.5 1851832

In the SAP Notes, you will find special markers for all BW-related settings:

Marker Related To

BI=YES General BW-related settings

DPF=YES Settings related to the Db2 Database Partitioning Feature (DPF)

CDE=YES Settings related to column-organized tables (BLU Acceleration)

Using the Parameter Check in the DBA Cockpit

Instead of setting the parameters manually using the command line processor (CLP), you can use the parameter check in the DBA Cockpit, which allows you to adapt the Db2 parameter settings easily. Call the DBA Cockpit (transaction DBACOCKPIT) in your system and choose Configuration Parameter Check . The DBA Cockpit automatically loads the relevant up-to-date SAP Note with the parameter settings from SAP Support Portal and compares the recommended parameter settings in the SAP Note with the current settings

14 P U B L I C


Essential Settings and Recommendations



in your SAP system. If the SAP system is an SAP BW system, this is also automatically detected by the DBA Cockpit, so the recommended parameter settings for BI=YES are selected as recommended settings. On the Parameter Settings screen of the DBA Cockpit, you can see the deviations of the current parameter settings from the recommended settings, you can correct settings, or declare deviations as intended.

More Information

DBA Cockpit documentation at http://help.sap.com/viewer/db6_dbacockpit

2.2 Configuring Intrapartition Parallelism

For SAP BW, configure Db2 intrapartition parallelism to get satisfactory performance.

Context

Intrapartition parallelism allows you to make better use of large multicore machines. With intrapartition parallelism, queries are executed by multiple Db2 agents in parallel, thus reducing the total execution time. Intrapartition parallelism subdivides what is typically considered to be a single database operation, such as index creation, database loading, or SQL queries, into multiple parts. Some or all of these operations can be run in parallel within a single database partition.

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksEssential Settings and Recommendations P U B L I C 15

http://help.sap.com/viewer/db6_dbacockpit

Parallel Execution of a Query

After the SAP system installation, the Db2 database is installed without intrapartition parallelism enabled if your SAP release is lower than SAP BW 7.5. As of SAP BW 7.5, intrapartition parallelism is enabled after the installation, but you must adapt the configuration: The configuration of intrapartition parallelism depends on the hardware of your database server and whether you use BLU Acceleration with your SAP BW system. For more information, see SAP Note 2047006 .

Procedure

1. Configure intrapartition parallelism as recommended in SAP Note 2047006 .2. Restart Db2.

16 P U B L I C


Essential Settings and Recommendations



2.3 BLU Acceleration

BLU Acceleration is a performance feature in Db2 that uses column-organized tables with high compression rates and a high degree of parallel processing.

RecommendationFor SAP Business Warehouse (SAP BW) systems running on Db2 10.5 and higher, we recommend that you use BLU Acceleration.

You want to learn more about BLU Acceleration? Read BLU Acceleration for SAP BW Objects [page 18].

You want to get started with BLU Acceleration? Read Checklist: Enabling an Installed SAP BW System for BLU Acceleration [page 20].

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksEssential Settings and Recommendations P U B L I C 17

3 BLU Acceleration for SAP BW Objects

BLU Acceleration is a performance feature in Db2 that uses column-organized tables with high compression rates and a high degree of parallel processing. Column-organized tables are optimized for analytic workloads with complex queries.

We recommend that you use BLU Acceleration for SAP BW objects. If you want to use BLU Acceleration for BW objects that have been created with row-organized tables, you can convert these tables from row-organized to column-organized. BLU Acceleration is available only on the AIX, Linux, and Windows operating systems. Your SAP BW system must also fulfill certain hardware and software minimum requirements.

After the installation, you'll still need to configure an SAP BW system to use BLU Acceleration. The following sections help you to get started:

● A checklist with all steps for enabling an SAP BW system for BLU Acceleration● Requirements, configuration, and settings for BLU Acceleration● Creating SAP BW objects with column-organized tables● Converting existing SAP BW objects from row-organized to column-organized table layout

RecommendationWe recommend that you test your extract, transform, and load (ETL) processes thoroughly before you use BLU acceleration in a production system.

3.1 SAP BW Objects Supported with BLU Acceleration: Overview

Db2 BLU Acceleration has been integrated into SAP Business Warehouse (SAP BW) 7.0 and higher for tables of particular SAP BW objects.

You can use BLU Acceleration with the following objects:

● InfoCubes with column-organized fact and dimension tables and aggregates in the database for the following InfoCube types:○ Basic cumulative InfoCubes○ Basic non-cumulative InfoCubes○ Real-time (transactional) InfoCubes○ MultiProvider with underlying column-organized basic InfoCubes○ Semantically partitioned InfoCubes (SAP BW 7.3 and higher only)

● Flat InfoCube (an InfoCube type that is optimized for column-organized tables)● Standard DataStore objects● Write-optimized DataStore objects● InfoObjects (characteristics, time characteristics, and units)

18 P U B L I C


BLU Acceleration for SAP BW Objects

● Persistent staging areas (PSAs)● BW temporary tables

The use of column-organized tables for other SAP BW objects is currently not supported.

CautionIn previous Fix Packs of Db2 10.5, a subset of the BW objects was supported. However, the use of BLU Acceleration in SAP BW with Db2 10.5 with Fix Packs lower than FP5SAP2 is no longer supported. If you still use a lower Fix Pack, we strongly recommend that you upgrade to FP5SAP2 or higher.

3.2 SAP BW Objects Supported with BLU Acceleration: Additional Information and Recommendations

Before your create SAP BW Objects with BLU Acceleration, make sure that you consider the recommendations here.

InfoCubes and DataStore Objects

BLU Acceleration is the recommended layout option for InfoCubes and DataStore objects. You can set the default setting to BLU Acceleration, so that each InfoCube or DataStore object is created with column-organized tables. Alternatively, you can also determine the table organization for each InfoCube and DataStore object individually when you create it using the Data Warehousing Workbench (transaction RSA1).

The tables for any aggregates of column-organized InfoCubes are always also created as column-organized tables.

As of SAP BW 7.4 SP 10, you can choose between standard InfoCubes and flat InfoCubes. Flat InfoCubes are a type of InfoCube optimized for column-organized tables. We recommend that you use flat InfoCubes.

InfoObjects

If you plan to use column-organized tables for the majority of your InfoCubes and DataStore objects, we recommend that you also use column-organized tables for your InfoObjects. Thus joins between row-organized and column-organized tables, which require additional processing at database level, can be avoided.

SAP BW Temporary Tables

When you use column-organized InfoCubes and DataStore objects, we recommend that you also use column-organized SAP BW temporary tables.

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksBLU Acceleration for SAP BW Objects P U B L I C 19

SAP BW query processing uses temporary tables to store intermediate results. These tables are then joined to the InfoProvider tables in the reporting queries.

If you have a mixture of row-organized and column-organized InfoCubes in your system and generate SAP BW temporary tables as column-organized tables, these column-organized temporary tables might be used in queries on row-organized InfoCubes. This might cause a small performance penalty. However, this drawback is outweighed by the performance benefit for queries on column-organized InfoCubes.

To get a stable performance, we recommend that you drop existing row-organized SAP BW temporary tables before you start working with column-organized InfoCubes and DataStore objects. You can drop existing row-organized SAP BW temporary tables using program SAP_DROP_TMPTABLES. Before you use this program, make sure that you have read SAP Note 1139396 .

3.3 Checklist: Enabling an Installed SAP BW System for BLU Acceleration

Get an overview of the required steps for enabling an installed SAP BW system for BLU Acceleration.

NoteRelevant for partitioned systems using the Db2 Database Partitioning Feature (DPF): Since the hardware recommendations for databases with row-organized tables and for databases with BLU Acceleration are different, you must repartition your database after a conversion from row-organized tables to BLU Acceleration.

Preparing an SAP BW System for BLU Acceleration

Step What to Do More Information

1 Make sure that your SAP BW system fulfills the hardware and software requirements.

Hardware and Software Requirements for BLU Acceleration [page 22]

2 Adapt your database and database manager configuration for the use of BLU Acceleration.

Adapting Your DB and DBM Configuration for BLU Acceleration [page 25]

3 Set a Db2 threshold for the number of expensive BLU queries that can run in parallel in the database.

Setting the Db2 Threshold for the Number of Parallel BLU Queries [page 25]

20 P U B L I C





4 Install the latest available version of the SAP Kernel and the DBSL library, at least the version that contains the patch from SAP Note 1911087 with the following patch text: "DB6: DROP INDEX to DROP CONSTRAINT".

If you have an SAP Kernel 7.41 or 7.42, use at least the version that contains the patch from SAP Note 2120815 .

SAP Note 1911087

SAP Note 2120815

5 Add the following SAP profile parameters to your profile and restart the application servers:

● dbs/db6/dbsl_ur_to_cc=*● dbs/db6/deny_cdefield_extension=1 (as of Db2

11.1 FP1, this parameter is no longer needed)

SAP Profile Parameters for BLU Acceleration [page 26]

6 Install the required SAP BASIS and SAP BW support packages in your system.

If you want to use flat InfoCubes, make sure that your SAP BW system is upgraded to SAP BASIS and SAP BW 7.4 Support Package 10 or higher.

Required Minimum SAP BASIS and SAP BW Support Packages [page 23]

7 Install additional SAP Notes on top of the support packages. Required SAP Notes for Preparing an SAP BW for BLU Acceleration [page 24]

Creating and Converting SAP BW Objects with BLU Acceleration

After you've done the preparation, proceed with the following steps:

Step More Information

Set the default format for new SAP BW objects to BLU Acceleration

Setting the Default Format of SAP BW Objects to BLU Acceleration [page 28]

To convert tables of existing SAP BW objects to BLU Acceleration, use program DB6CONV.

Converting Row-Organized Tables of SAP BW Objects to Column-Organized Tables and Vice Versa [page 32]

For optimal query performance on column-organized InfoCubes and DataStore objects, make sure that temporary tables in SAP BW are also column-organized.

SAP BW Objects Supported with BLU Acceleration: Additional Information and Recommendations [page 19]






Creating Flat InfoCubes

In an SAP BW system with release 7.4 and higher, you can now also create flat InfoCubes: Creating Flat InfoCubes (As of SAP BW 7.4 SP 10) [page 30]

3.4 Prerequisites for BLU Acceleration on SAP Systems

3.4.1 Hardware and Software Requirements for BLU Acceleration

Make sure that your system fulfills the hardware and software requirements for BLU Acceleration, including the operating system requirements, Db2 Fix Packs, Unicode, database layout requirements, and automatic storage.

Hardware Requirements, Operating Systems, and Db2 Version and Fix Pack

For BLU Acceleration, make sure that your hardware and software fulfills the requirements mentioned in SAP Note 1819734 .

Unicode

Your database must be a Unicode database.

If this is not the case, you must first perform a Unicode migration. To implement Db2 BLU Acceleration during the Unicode migration, proceed as described in Migrating an SAP BW System to Db2 for LUW for the Use of Db2 BLU Acceleration [page 149]. If you have performed the Unicode migration separately first, continue with Checklist: Enabling an Installed SAP BW System for BLU Acceleration [page 20].

Database Layout

In most cases, a single partition with intrapartition parallelism is sufficient for BLU Acceleration.

If you already have multiple partitions or are considering using the Db2 Database Partitioning Feature (DPF), you need Db2 11.1 or higher to combine DPF with BLU Acceleration. In addition, note that the hardware requirements and recommendations for partitioned databases with BLU Acceleration are different from the requirements for partitioned databases with row-organized tables. If you already have a partitioned database without BLU Acceleration, be prepared to repartition the database after the conversion to BLU Acceleration. For more information about the hardware requirements and the recommended partitions for DPF combined with BLU Acceleration, see Number of Partitions and Hardware Requirements [page 99].

22 P U B L I C




You cannot use BLU Acceleration with Db2 pureScale. If you currently use Db2 pureScale and want to enable BLU Acceleration, you must perform a system copy to a non-pureScale database first. To implement Db2 BLU Acceleration during system copy, proceed as described in Migrating an SAP BW System to Db2 for LUW for the Use of Db2 BLU Acceleration [page 149]. If you have performed the system copy separately first, continue with Checklist: Enabling an Installed SAP BW System for BLU Acceleration [page 20].

Automatic Storage and Reclaimable Storage Tablespaces

Ensure the following:

● Your database is set up with Db2 automatic storage.● You provide reclaimable storage tablespaces for the column-organized tables.

If you do not have reclaimable storage tablespaces, create new reclaimable tablespaces. Use the DB6CONV program to move your tables to the new tablespaces.

More Information

SAP Note 1819734

DB6CONV documentation: SAP Note 1513862

3.4.2 Required Minimum SAP BASIS and SAP BW Support Packages

For BLU Acceleration, minimum SAP BASIS and SAP BW support packages are required in your system.

SAP BW Release SAP BASIS Support Package

SAP BW Support Package Technical Name

7.00 31 33 SAPKW70033

7.01 (SAP BW 7.0 EHP 1) 16 16 SAPKW70116

7.02 (SAP BW 7.0 EHP 2) 16 16 SAPKW70216

7.11 14 14 SAPKW71114

7.30 12 12 SAPKW73012

7.31 (SAP BW 7.3 EHP 1) 13 13 SAPKW73113

7.40 7 7 SAPKW74007




3.4.3 Required SAP Notes for SAP BW with BLU Acceleration

Implement the required SAP Notes before you use BLU Acceleration.

Collective SAP Note

To prepare an installed SAP BW system for Db2 BLU acceleration, install SAP Note 1825340 on top of the required support packages. This SAP Note is a collection of corrections for using BLU Acceleration in SAP Business Warehouse Releases 7.0, 7.02, 7.30, 7.31, and 7.40. This SAP Note includes other required SAP Notes that are regularly extended and updated. Therefore, you can use this SAP Note in transaction SNOTE as a generic update mechanism for the use of BLU Acceleration in SAP BW.

The SAP Note is also relevant if you migrate an SAP BW system to Db2 and to BLU Acceleration or if you upgrade an SAP BW system running on Db2 10.5 from FP3aSAP to FP5SAP2 and higher.

Additional SAP Notes

In addition to the collective SAP Note, make sure that you also implement the following SAP Notes:

SAP Note Number Description

2168105 (only for SAP BW 7.4 and higher) Conversion from standard to flat InfoCube might create compressed records with duplicate keys

2204240 DB6: Updates to DB6specific RSADMIN parameters

2378365 (only for SAP BW 7.4 and higher) BW Flat InfoCubes in DB systems (except for SAP HANA)

2519266 (only for SAP BW 7.4 and higher) Fix for data loss during standard to flat InfoCube conversion

24 P U B L I C








3.5 Required Configuration and Settings for BLU Acceleration

3.5.1 Adapting Your DB and DBM Configuration for BLU Acceleration

Ensure that your Db2 configuration is adapted for BLU Acceleration. This includes settings for the database manager, database configuration, recommended buffer pool sizes, and intrapartition parallelism.

Procedure

1. Adapt your database and database manager configuration as described in the following SAP Notes:

Relevant for Db2 Version SAP Note

11.1 2303771

10.5 1851832

The following configuration areas are different for BLU Acceleration and must be adapted:

○ INSTANCE_MEMORY○ The sort parameters SHEAPTHRES_SHR and SORTHEAP

NoteYou must manually set the sort parameters for Db2 BLU Acceleration. Even if you use the self-tuning memory manager (STMM), the sort parameters aren't tuned automatically by Db2.

2. Use intrapartition parallelism with the settings recommended in SAP Note 2047006 .

3.5.2 Setting the Db2 Threshold for the Number of Parallel BLU Queries

Set a Db2 threshold for the number of expensive BLU queries that can run in parallel in the database.

Context

You can use the db6_update_db script to remove the SAPspecific service classes and workloads and to establish a workload management (WLM) threshold. This WLM threshold limits the number of costly queries





that can be executed in parallel, which prevents an overload of the CPU resources of the database server. The number of queries that are allowed to run in parallel is determined by the script, along with the help of the Db2 configuration advisor.

Procedure

1. Download the latest version of the db6_update_db script from SAP Note 1365982 .

2. Run db6_update_db.sh with option -activate_blu to generate the SQL script db6_update_db_out.sql.

3. Run the db6_update_db_out.sql script.

The db6_update_db_out.sql script sets the concurrency threshold. Because the concurrency threshold is not compatible with the standard SAP WLM settings, the script drops the SAP WLM setup before it creates the concurrency threshold.

If any workloads are still running while the script tries to drop the SAP WLM setup, the corresponding DROP WORKLOAD commands might fail. However, the workloads are disabled, so you can continue with the setup of BLU Acceleration in SAP BW.

4. If there are workloads that could not be dropped, run the db6_update_db_out.sql script again later to drop the workloads completely.

3.5.3 SAP Profile Parameters for BLU Acceleration

For BLU Acceleration, you need to add SAP profile parameters to your profile and restart the application servers.

SAP Profile Parameter Setting Comment

All Db2 versions: dbs/db6/dbsl_ur_to_cc=* This parameter sets the default Db2 isolation level in the SAP system to currently committed. This applies to all SQL statements that run with isolation level uncommitted read (UR) by default. This parameter is needed to avoid potential data inconsistencies during the update of existing data and during the insertion of new master data in the SAP BW system.

26 P U B L I C




SAP Profile Parameter Setting Comment

Db2 10.5 and 11.1 GA only: dbs/db6/deny_cdefield_extension=1

NoteAs of Db2 11.1 FP1, this parameter is no longer needed; do not set it.

This parameter setting prevents operations that extend the length of a VARCHAR column in a column-organized table from running in the SAP BW system. Extending the length of a VARCHAR column in a column-organized table is not supported with Db2 10.5 and causes the following SQL error SQL1667N:

The operation failed because the operation is not supported with the type of the specified table. Specified table: <tabschema>.<tabname>. Table type: “ORGANIZE BY COLUMN”. Operation: “ALTER TABLE”. SQLSTATE=42858.

When the SAP profile parameter is set, the ABAP Dictionary triggers a table conversion if a length extension of a VARCHAR column in a column-organized table is requested.

As of Db2 11.1 MP1 FP1, Db2 can extend the length of a VARCHAR column in a column-organized table. To avoid unnecessary table conversions, do not set this parameter in Db2 11.1 MP1 FP1 or higher.

NoteThese parameters do not appear in transaction RZ11 because they cannot be changed dynamically.


3.5.4 Setting the Default Format of SAP BW Objects to BLU Acceleration

To get a consistent performance, we recommend that you set the default format of all SAP BW objects to BLU Acceleration.

Context

By default, SAP BW objects are created with row-organized tables. To ensure that new SAP BW objects are created with column-organized tables (BLU Acceleration), set the following RSADMIN parameters to YES:

SAP BW Object Type RSADMIN Parameter Available as of

InfoCubes DB6_INFOCUBE_USE_CDE SAP Notes 2204240 and 2390851 or the SAP BW releases and sup

port packages mentioned in these SAP Notes

DataStore objects DB6_DSO_USE_CDE SAP Notes 2204240 and 2390851 or the SAP BW releases and sup

port packages mentioned in these SAP Notes

InfoObjects DB6_IOBJ_USE_CDE SAP Note 1825340 or the SAP BW releases and support packages mentioned in this SAP Note

PSAs DB6_PSA_USE_CDE SAP Note 1825340 or the SAP BW releases and support packages mentioned in this SAP Note

SAP BW temporary tables DB6_TMP_USE_CDE SAP Note 1825340 or the SAP BW releases and support packages mentioned in this SAP Note

Changes to the RSADMIN parameters take effect only when new SAP BW objects are created. Existing tables are not affected.

In addition to the parameters mentioned in the table, there is an additional parameter DB6_ALLOW_CDE that you can use to enable or disable BLU Acceleration for the entire system. By default, this parameter is set to YES, so use this parameter only if you want to disable BLU Acceleration. For more information, see Temporarily Disabling BLU Acceleration for New BW Objects [page 142].

28 P U B L I C












Procedure

1. Call the ABAP editor (transaction SE38) and run program SAP_RSADMIN_MAINTAIN.

2. Enter the relevant RSADMIN parameter in the OBJECT field and YES in the VALUE field.

Example: Parameter and Value for InfoObjects

3. Make sure that the radio button INSERT is selected.4. Choose Execute.

The program now changes the respective RSADMIN parameter to the new value.

5. If necessary, repeat the procedure for more parameters.


3.6 Creating SAP BW Objects for BLU Acceleration

3.6.1 Creating SAP BW Objects for BLU Acceleration Automatically or Manually

When BLU Acceleration is set as default in the SAP BW system, all new SAP BW objects are automatically created as column-organized. When you create InfoCubes and DataStore objects, you can also manually set the clustering options to BLU Acceleration.

Creating SAP BW Objects with BLU Acceleration Automatically

We recommend that you set the default format of all SAP BW objects to BLU Acceleration using RSADMIN parameters (see Setting the Default Format of SAP BW Objects to BLU Acceleration [page 28]). With this setting, all eligible SAP BW objects are created with column-organized tables automatically, and you need not take any additional action.

Manually Selecting BLU Acceleration During the Creation of Standard InfoCubes and DataStore Objects

When you create InfoCubes and DataStore objects, you can decide for each object individually whether to create it with column-organized tables:

1. Create a new InfoCube or DataStore object in the Data Warehousing Workbench (transaction RSA1).

2. From the menu, choose Extras DB Performance Clustering .3. In the following dialog box Selection of Clustering, choose Column-Organized and continue.

3.6.2 Creating Flat InfoCubes (As of SAP BW 7.4)

As of SAP BW 7.4 SP10, you can create flat InfoCubes in the Data Warehousing Workbench.

Prerequisites

Flat InfoCubes are also available in SAP BW 7.4 as of Support Package 8. Only as of SAP BW 7.4 SP10 can you create flat InfoCubes directly in the Data Warehousing Workbench. With SAP BW 7.4 SP 8 or SP 9, you must create a standard InfoCube first. Then convert it to a flat InfoCube using program RSDU_REPART_UI.

Flat InfoCubes are not available with SAP BW 7.4 SP 7 or lower.

30 P U B L I C



Procedure

1. Call the Data Warehousing Workbench (transaction RSA1).

2. Create a new InfoCube.3. Select the checkboxes Standard InfoCube and Flat InfoCube:

Dialog: Create New InfoCube

4. Enter the required data in the Create New InfoCube dialog and choose Create.

The Edit InfoCube window in the Data Warehousing Workbench opens.5. If required, make additional changes to the new InfoCube and save.


3.7 Converting SAP BW Objects to BLU Acceleration

3.7.1 Checking Which BW Objects Are Eligible for BLU Acceleration

Use program SAP_BLU_CONVERSION_CHECK_DB6 for an overview of the BW objects in your SAP BW system that can be converted to a column-organized format for BLU Acceleration.

Prerequisites

You have implemented SAP Note 2532409 or the support packages mentioned in this SAP Note.

Context

The program checks which SAP BW objects can be converted to a column-organized format. You can choose the BW object types (InfoCubes, DataStore objects, InfoObjects) that you want to check for eligibility.

NoteThe program is only a check; it doesn't convert any BW objects.

Procedure

1. Call the ABAP editor (transaction SE38).

2. Run program SAP_BLU_CONVERSION_CHECK_DB6.

3.7.2 Converting Row-Organized SAP BW Objects to BLU Acceleration and Vice Versa

To convert row-organized SAP BW objects to BLU Acceleration, or vice versa, use program DB6CONV.

Prerequisites

Version 6.00 is the required minimum version of program DB6CONV that supports conversion from row-organized tables to BLU Acceleration. To be able to use program DB6CONV with the conversion capabilities for

32 P U B L I C




column-organized tables, you need Db2 10.5 with at least FP5SAP2. We recommend that you always use the latest version of DB6CONV. You can find the DB6CONV program attached to SAP Note 1513862 .

NoteFor partitioned databases using the Db2 Database Partioning Feature (DPF) only: Since the hardware recommendations for databases with row-organized tables and for BLU Acceleration are different, be prepared to repartition your database after a conversion from row-organized tables to BLU Acceleration.

Context

As of Db2 10.5 FP5SAP2, the conversion from row-organized tables to column-organized tables and vice versa is supported for the following SAP BW objects:

● DataStore objects (except for DataStore objects with non-unique secondary indexes, which should not be converted to column-organized)

● InfoObjects (master data)● Persistent Staging Areas (PSAs)● Standard InfoCubes (but see the caution)

CautionAlways use the DB6CONV program to convert to column-organized tables. Do not use native Db2 tools such as db2convert or the stored procedure ADMIN_MOVE_TABLE. The DB6CONV program ensures that all tables of a BW object are converted, and also ensures that the constraints on the converted tables are created as required by SAP BW.

To convert standard InfoCubes to BLU Acceleration, we strongly recommend that you convert standard InfoCubes to flat InfoCubes (possible as of SAP BW 7.4 SP 8). The performance of flat InfoCubes is better than the performance of InfoCubes that remain with a standard star schema but have column-organized tables. To convert standard row-organized InfoCubes to flat InfoCubes and vice versa, you cannot use program DB6CONV. Use program RSDU_IC_STARFLAT_MASSCONV or RSDU_REPART_UI instead.

If you have already used the DB6CONV program to convert InfoObjects to row- and column-organized tables and you have changed the RSADMIN parameter DB6_IOBJ_PQT_USE_CDE for InfoObjects in the meantime, open a customer incident under BW-SYS-DB-DB6. Get advice from SAP support before you start any further conversions.

Procedure

To convert row-organized SAP BW objects to BLU Acceleration and vice versa, follow the instructions of the DB6CONV documentation, which is attached to SAP Note 1513862 .




Related Information

Executing a Mass Conversion of Standard InfoCubes to Flat InfoCubes [page 34]Converting Single Standard InfoCubes to Flat InfoCubes and Vice Versa [page 35]

3.7.3 Executing a Mass Conversion of Standard InfoCubes to Flat InfoCubes

As of SAP Business Warehouse (SAP BW) 7.4 SP 9, you can use program RSDU_IC_STARFLAT_MASSCONV to execute a mass conversion of standard InfoCubes to flat InfoCubes.

Prerequisites

You are using SAP BW with the following minimum releases and support packages:

SAP BW Release Minimum Support Package

7.4 SP 9 with SAP Note 2446889

7.5 and higher General availability with SAP Note 2446889

Caution

In addition, make sure that you have implemented the relevant HotNews (SAP Note 2519266 ).

InfoCubes with inventory data can have requests that contain historic inventory data (history transaction data). Make sure that you compress these requests before you start the conversion. In addition, make sure that you have a recent full backup of your system before you start the conversion.

Context

You can use the program RSDU_IC_STARFLAT_MASSCONV for the following use cases:

● You want to use BLU Acceleration and you already have a number of row-organized standard InfoCubes in your system. You want to convert these standard InfoCubes to flat InfoCubes with a flat structure and column-organized tables.

● You want to convert column-organized InfoCubes with a standard format (“star schema”) to flat InfoCubes.

NoteThe conversion to flat InfoCubes is not supported for semantically partitioned InfoCubes.

34 P U B L I C






Procedure


2. Start program RSDU_IC_STARFLAT_MASSCONV.

3. Confirm that you have compressed historic data in inventory InfoCubes and that you have created a full backup of your system.

The Convertible InfoCubes tab page shows a list of InfoCubes that can be converted. The Non-Convertible InfoCubes tab page shows the InfoCubes that cannot be converted to the flat format. On the Conversion Jobs tab page, you find all jobs that have already run, that are scheduled, or that are currently running.

4. Review the list of InfoCubes that can't be converted and the reasons why.5. If necessary, address the reasons why some InfoCubes cannot be converted and choose Regenerate

Worklist.6. Select the InfoCubes on the Convertible InfoCubes tab page that you want to convert.

7. To schedule a conversion, choose Schedule Conversion on the Convertible InfoCubes tab page.

Results

All InfoCubes that are scheduled for conversion are shown on the Conversion Jobs tab page.

You can use Refresh Display of Worklist to update the lists on the Convertible InfoCubes and Non-Convertible InfoCubes tab pages.

3.7.4 Converting Single Standard InfoCubes to Flat InfoCubes and Vice Versa

You can use program RSDU_REPART_UI to convert single standard InfoCubes to flat InfoCubes and vice versa. To convert more than a few standard InfoCubes to flat InfoCubes, we recommend that you use program RSDU_IC_STARFLAT_MASSCONV, which supports parallel jobs and mass conversions.

Prerequisites

CautionBefore you use this program, make sure that you have implemented the relevant HotNews (SAP Note 2519266 ).



Procedure

1. Call the ABAP editor (transaction SE38) and run program RSDU_REPART_UI.

2. Enter the name of the InfoCube and select conversion type Non-flat to flat.3. Choose Initialize.4. Check the questions in the following dialog boxes carefully. Confirm the questions by choosing Yes:

a. Confirm that you have taken a database backup.

A backup is important when you convert existing InfoCubes with data to flat InfoCubes. During the conversion, new database tables are created, the data is copied to the new tables, and the old tables are dropped. With a database backup, you can always return to where you were before the conversion was started.

b. Confirm that you have compressed all requests that contain historical movements.

The compression is important when you convert existing InfoCubes with data to flat InfoCubes. To compress historical movements of standard InfoCubes, select the No Marker Update checkbox in the compression window. For flat InfoCubes, compression is handled differently: you define directly in the Data Transfer Process (DTP) whether you're loading requests that contain historical movements. However, this definition affects only requests that are newly loaded after the conversion of the InfoCube to a flat InfoCube. Requests that contain historical movements and that already reside in the F fact table can no longer be detected and correctly compressed after the conversion.

When you convert existing InfoCubes with data, the system checks whether any uncompressed requests with package dimension ID 1 or 2 exist. You must compress these requests before the conversion. The package dimension IDs 1 and 2 are reserved for marker records of non-cumulative InfoCubes and for historical movement data in flat InfoCubes.

c. Confirm the information message that the conversion request for the InfoCube has been created.d. In the Start Time dialog window, choose Immediate (or schedule a job for a later point in time).e. Confirm the information message that a conversion request has been started in the background.

5. To monitor the progress of the conversion, choose Monitor in the entry screen of program RSDU_REPART_UI.

36 P U B L I C



Monitoring the Progress of the Conversion in RSDU_REPART_UI

Results

When the conversion job finishes, you have a flat InfoCube that has only two tables: the F fact table and the package dimension table. Both of these tables are now column-organized.

Related Information

Executing a Mass Conversion of Standard InfoCubes to Flat InfoCubes [page 34]


3.8 Considerations for Creation, Copy, Aggregation, and Transport with BLU Acceleration

Copying BW Objects

When you copy an existing DataStore object, InfoCube, or aggregate, the target BW object inherits the column-organized table organization settings of the source BW object. However, before you activate the target BW object, you can change its settings. To do so, choose Extras DB Performance Clustering from the menu of the Edit <BW Object> screen.

When you copy an existing InfoObject or PSA, the target BW object organization is derived from the RSADMIN parameter settings for the respective object.

Transporting BW Objects

When you transport a BW object from your development system to the production system, the following happens:

● If the BW object already exists in the production system and contains data, the current table organization (row- or column-organized) is retained.

● If the BW object is a DataStore object, an InfoCube, or an aggregate and does not yet exist in the production system or does not contain any data, the table organization settings from the development system are used. If the tables already exist, they are dropped and re-created.As of SAP Note 2550929 and the support packages mentioned in this SAP Note, this also applies to flat InfoCubes.

● If the BW object is an object other than a DataStore object, an InfoCube or an aggregate and does not yet exist in the production system or does not contain any data, the table organization settings are derived from the RSADMIN parameter settings in the production system. If the tables already exist, they are dropped and re-created.

Considerations for InfoCubes Only

Creating Semantically Partitioned InfoCubes

When you select column-organized tables for the InfoCube, the tables of all partitions of the semantically partitioned InfoCube are also automatically created as column-organized.

38 P U B L I C




Reusing Predefined InfoCubes from BI ContentYou might want to reuse InfoCubes predefined by SAP as they are available with BI Content for SAP BW. When you install SAP BI Content, the following applies:

● If the RSADMIN parameter DB6_INFOCUBE_USE_CDE is set to YES, row-organized InfoCubes from BI Content are created as column-organized InfoCubes (with star schema) during installation.

● If the RSADMIN parameter DB6_INFOCUBE_USE_CDE is set to NO, row-organized InfoCubes are created with the default clustering settings for Db2, which is index clustering.

● Flat InfoCubes from BI Content are created as flat InfoCubes during installation. They are only created as row-organized if the RSADMIN parameter DB6_ALLOW_CDE is set to NO.

Aggregates for InfoCubesWith BLU Acceleration, if the query performance on column-organized InfoCubes is fast enough, you might not need aggregates anymore. However, if needed, you can also create aggregates for column-organized InfoCubes. The tables for any aggregates of column-organized InfoCubes are also created as column-organized tables.

3.9 Setting Up Parallel Batch Jobs for InfoObjects (SAP BW 7.0x Only)

In SAP BW 7.0, 7.01, and 7.02 systems, set up parallel batch jobs if you have InfoObjects with column-organized attribute tables (P, Q tables). If the data transfer processes that load and activate new master data run with several parallel batch jobs, you get a better performance.

Context

This is required only for SAP BW 7.0, 7.01, and 7.02 because the tables are looked up using single statements in these releases. Therefore, parallel processing is needed on the application server to improve performance. As of SAP BW 7.3, this is no longer necessary because the tables are now looked up using FOR ALL ENTRIES statements, which are faster than single statements.

Procedure

1. Edit the data transfer process and turn on semantic groups as follows:a. On the Extraction window, choose Semantic Groups.

A dialog window for the selection of key fields appears.b. Select one or more key fields and choose OK.

2. From the menu of the data warehousing workbench, choose Goto Settings for Batch Manager... .3. In the Number of Processes field, enter the number of parallel processes with which you want to run the job.


4. Save your entries.

40 P U B L I C



4 Additional Tablespaces and Data Classes

After you've installed the SAP BW system, the only tablespaces available are those created by the installer. If you plan to create large InfoCubes, DataStore objects, or PSA tables, where large is more than 500 GB per InfoCube, DataStore object, or PSA table, we recommend that you create additional data tablespaces, index tablespaces, and data classes for each new object in advance.

You can also create additional tablespaces for smaller SAP BW objects, where you assign several small and medium-sized InfoCubes, DataStore objects, or PSA tables to the same tablespace and data class. It doesn't matter here whether you use a single-partition database or a partitioned database.

If you are planning to create a partitioned database, you must also create database partition groups.

NoteConsider carefully whether it's necessary to use the Db2 Database Partitioning Feature (DPF). Read the sections about DPF first before you start creating database partitioning groups and tablespaces.

Related Information

Number of Partitions and Hardware Requirements [page 99]

4.1 Database and File System Layout After the Installation

During an SAP BW system installation, default buffer pools, database partition groups, and tablespaces are created. You must adapt the default database layout for production operation of your SAP BW system.

Throughout this section, we distinguish between SAP BASIS database objects and SAP BWspecific database objects.

Buffer Pools

The default buffer pool IBMDEFAULTBP is automatically created during an SAP system installation. IBMDEFAULTBP has a page size of 16 KB and is enabled for tuning by the Db2 Self-Tuning Memory Management (STMM). We recommend that you enable STMM in non-partitioned database servers.

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksAdditional Tablespaces and Data Classes P U B L I C 41

Database Partition Groups

SAP Basis Database Partition GroupThe SAP basis database partition group is SAPNODEGRP_<SAPSID>. It must only contain partition 0.

SAP BW-Specific Database Partition GroupsThe following SAP BWspecific database partition groups are created during the SAP system installation:

Database Partition Group Description

NGRP_FACT_<SAPSID> Default database partition group for fact tables of InfoCubes and aggregates

NGRP_DIM_<SAPSID> Default database partition group for dimension tables

It must only contain partition 0.

NGRP_ODS_<SAPSID> Default database partition group for DataStore object tables and PSA tables

You need additional database partition groups only if you are using the Db2 Database Partitioning Feature (DPF).

Tablespaces

All tablespaces use the default buffer pool IBMDEFAULTBP, have a page size of 16 KB, and have an extent size 2.

SAP BASIS TablespacesAll SAP BASIS tablespaces must be located on partition 0 only. The SAP BW master data is located in SAP BASIS tablespaces.

The following SAP BWspecific tablespaces are created during the SAP system installation in various database partition groups:

SAP BWSpecific Tablespaces

Tablespace Description Database Partition Group Corresponding Data Class

<SAPSID>#ODSD Data tablespace for DataStore objects and PSA tables

NGRP_ODS_<SAPSID> DODS

<SAPSID>#ODSI Index tablespace for DataStore objects and PSA tables

NGRP_ODS_<SAPSID> DODS

<SAPSID>#FACTD Data tablespace for the InfoCube and aggregate fact tables

NGRP_FACT_<SAPSID> DFACT

42 P U B L I C


Additional Tablespaces and Data Classes

Tablespace Description Database Partition Group Corresponding Data Class

<SAPSID>#FACTI Index tablespace for the InfoCube and aggregate fact tables

NGRP_FACT_<SAPSID> DFACT

<SAPSID>#DIMD Data tablespace for dimensions

NGRP_DIM_<SAPSID> DDIM

<SAPSID>#DIMI Index tablespace for dimensions

NGRP_DIM_<SAPSID> DDIM

If your system was first installed with SAP BW 3.1 or lower, the prefix PSAP is still used. During an upgrade, the tablespace names do not change.

After installation, all partition groups are located on partition 0 (the administrative partition).

This is the default after the installation. We recommend that you assign large SAP BW objects to their own tablespaces.

Database Containers of SAP BW-Specific Tablespaces

The database container layout depends on whether the database has been enabled for Db2 automatic storage management during the installation.

By default, the database is enabled for Db2 automatic storage management. Four sapdata directories for permanent data and four saptmp directories for temporary data are assigned as storage paths to the database. For each tablespace, one container is created in each storage path. This applies to the tablespaces for permanent data as well as to the temporary tablespaces. By default, the temporary tablespace is created as an automatic storage tablespace based on the SMS (system-managed space) infrastructure, with one container in each saptmp directory. For more recommendations for automatic storage, see SAP Note 1895425

.

For compatibility reasons, the SAP installation tool also provides an exit to manually create tablespaces and containers. A preconfigured script creates standard DMS (database managed space) tablespaces with one file container in each sapdata directory. The SAP installer creates all DMS tablespaces with file containers in automatic resize mode. Db2 automatically extends the size of all tablespaces in automatic resize mode as long as there is space left in the sapdata directories.

CautionWe recommend that you do not use DMS file tablespaces in automatic resize mode. DMS tablespaces are deprecated as of Db2 10.1 and must not be used.




4.2 Naming Conventions for New Objects

Use naming conventions for database partition groups, tablespaces, containers, and data classes to ensure consistency and secure upgrades.

If you create new tablespaces for single large SAP BW objects or containers for tablespaces, use the following naming conventions:

Naming Conventions for Tablespaces and Containers

Object Type Naming Convention Comment

Tablespace <SAPSID>#<BWObjectIdentifier><Type>

<BWObjectIdentifier> is the technical name of the BW object for which you create the new tablespace.

<Type> can be “D” for Data Tablespaces or “I” for Index Tablespaces.

Container (for a tablespace) Use the name of the tablespace also as container name

-

If you create new data classes for SAP BW objects such as InfoCubes, DataStore objects, and PSA tables, use the following naming conventions:

Naming Conventions for Data Classes

Table Type Name Prefix

Fact table ZF*

Dimension table ZD*

Aggregate table ZA*

DataStore table ZO*

PSA table ZP*

NoteKeep in mind that not defining data classes according to the naming conventions has an impact on future upgrades of your system.

Entries that are not located in the customer namespace are not recognized as customer entries and are lost when you upgrade.

44 P U B L I C



For databases with Db2 Database Partitioning Feature (DPF) only: If you create separate database partition groups for single large SAP BW objects, use the following naming conventions:

Naming Conventions for Database Partition Groups (DPF Only)

Object Name Description

NGRP_AGGR_<SAPSID>#<InfoCubeIdentifier> Use this naming convention for the fact tables of aggregates. <InfoCubeIdentifier> is the technical name of the InfoCube to which the aggregate belongs.

NGRP_FACT_<SAPSID>#<InfoCubeIdentifier> Use this naming convention for the fact tables of InfoCubes. <InfoCubeIdentifier> is the technical name of the InfoCube.

NGRP_ODS_<SAPSID>#AQ_<ODSIdentifier> Use this database partition group naming convention for the activation queue table of DataStore objects. <ODSIdentifier> is the technical name of the DataStore to which the activation queue table belongs.

NGRP_ODS_<SAPSID>#ODS_<ODSIdentifier> Use this naming convention for the active table and the change log table of a DataStore object. <ODSIdentifier> is the technical name of the DataStore object.

NGRP_PSA_<SAPSID>#<PSAIdentifier> Use this naming convention for PSA tables. <PSAIdentifier> is the technical name of the PSA.

DBA Cockpit

We recommend that you use the DBA Cockpit to create new database partition groups, tablespaces, and data classes.

For more information, see the documentation Database Administration Using the DBA Cockpit: IBM Db2 for Linux, UNIX, and Windows at http://help.sap.com/viewer/db6_dbacockpit.

4.3 Creating Database Partition Groups (DPF Only)

After installation, standard database partition groups are already available. Create additional database partition groups only if you want to use the Db2 Database Partitioning Feature (DPF).

Context

In a DPF setup, a database partition group determines the partitions on which a tablespace is created. You can assign several tablespaces to one database partition group.



NoteYou don't need to create database partition groups in a single-partition database. Only if you plan to use DPF later, do we recommend that you create database partition groups. Doing so allows you to add partitions more easily at a later point in time.

Before you decide whether to use DPF, read the relevant chapters about DPF and its benefits and disadvantages.

Procedure

● To create a new database partition group, use the DBA Cockpit as described in Database Administration Using the DBA Cockpit: IBM Db2 for Linux, UNIX, and Windows at http://help.sap.com/viewer/db6_dbacockpit.

Related Information

Arguments to Consider for and Against DPF [page 101]Planning the Multipartition Database Layout [page 103]

4.4 Creating Tablespaces

You can create tablespaces in a database partition group and store tables inside these tablespaces. This is how you can decide if your tables are distributed over several database partitions.

Procedure

1. Identify the database partition group where you want to create your tablespace. The tablespace is distributed over the partitions of the database partition group.

2. Create the new tablespace using the DBA Cockpit as described in Database Administration Using the DBA Cockpit: IBM Db2 for Linux, UNIX, and Windows at http://help.sap.com/viewer/db6_dbacockpit.

46 P U B L I C






4.5 Creating Data Classes

If you have created new tablespaces, you must make them known to the SAP BW system. Therefore, you define new data classes for the fact tables, aggregates, DataStore, and PSA tablespaces, similar to the default data classes DFACT and DODS.

Context

A data class is the counterpart of a tablespace in the SAP system. It combines a data tablespace with an index tablespace and defines a logical name for this combination. This logical name is referenced in the ABAP Dictionary and in the SAP BW metadata.

You assign a data class in the SAP BW Data Warehousing Workbench when you create a new SAP BW object, such as an InfoCube, DataStore object, or PSA table. The assigned data class determines the tablespace and the corresponding database partition group for the SAP BW object.

Procedure

1. Identify the data and index tablespace for which you want to define a data class.2. Create the new data class using the DBA Cockpit as described in Database Administration Using the DBA

Cockpit: IBM Db2 for Linux, UNIX, and Windows at http://help.sap.com/viewer/db6_dbacockpit.

4.6 Changing the Data Classes of InfoCubes, DataStore Objects, and PSA Tables

If you have created new database partition groups, tablespaces, and data classes, you can assign InfoCubes, DataStore Objects, and PSA tables to the new data classes. When you create a new BW object, it's first assigned to the default data class. Change the data class of an existing BW object as long as the BW object does not contain any data.



4.6.1 Changing the Data Classes of InfoCubes and Their Aggregates

For each InfoCube that you want to store in a separate tablespace, you must overwrite the default data classes for the InfoCube and its aggregates with new data classes.

Context

By default, the fact tables of an InfoCube and its aggregates are created in the tablespace that is defined in the data class DFACT. By default, the dimension tables are created in the tablespace that is associated with the data class DDIM.

NoteYou can assign fact tables of an InfoCube to new data classes only as long as the InfoCube does not contain any data.

Procedure

1. In your SAP BW system, start the Data Warehousing Workbench.2. Create a new InfoCube or choose an existing one.3. In the context menu, choose Change.

4. Choose Extras DB Performance Maintain DB-Storage Parameters .5. To change the data class for fact tables of an InfoCube, navigate to the InfoCube: Logical Storage Parameter

area and enter the required value in the Data Type field for fact tables.6. To change the data class for InfoCube dimension tables (if you created separate tablespaces for them),

navigate to the InfoCube: Logical Storage Parameter area.7. Enter the required value in the Data Type field for dimension tables.8. By default, the aggregate fact tables of an InfoCube are created in the same data class as the fact tables of

the InfoCube. To change the data class for all subsequently created aggregates of an InfoCube, navigate to the Aggregates: Logical Storage Parameter area and enter the required value in the Data Type field for fact tables.

9. Choose Continue.10. To activate the InfoCube, choose Activate from the application toolbar.

Tables are created in the tablespaces associated with the assigned data class.

NoteTo change the data class of aggregates that have already been filled, deactivate the aggregates first. Then reactivate and refill them.

48 P U B L I C



4.6.2 Changing the Data Classes of DataStore Objects

For each DataStore object that you want to store in a separate tablespace, you must overwrite the default data class for the DataStore object with a new data class.

Context

By default, all tables of a DataStore object are created in the tablespace that is defined for the data class DODS.

NoteYou can assign the tables of a DataStore object to new data classes only as long as the Data Store object does not contain any data.

Procedure

1. In your BW system, start the Data Warehousing Workbench.2. Create a new DataStore object or choose an existing one.3. In the context menu, choose Change.

4. Choose Extras DB-Performance Maintain DB-storage parameters .5. To change the data class for the active table of the DataStore object, navigate to the area Logical Storage

Parameter for DataStore (Active Records) and enter the required value in the Data Type field.

NoteThe change log table is created in the same data class.

6. To change the data class for the activation queue table, navigate to the area Logical Storage Parameter for DataStore (Activation Queue) and enter the required value in the Data Type field.

7. Choose Continue.8. To activate the DataStore object, choose Activate from the application toolbar.


4.6.3 Changing the Data Classes of PSA Tables

For each PSA table that you want to store in a separate tablespace, you must overwrite the default data class for the PSA table with a new data class.

Context

By default, the PSA tables are created in the data class DODS. You can change the data class of a PSA table if the corresponding DataSource has been assigned to an InfoSource or to a data transfer process. Once the transfer structure of the InfoSource has been activated, you cannot change the data class of the PSA table.

NoteDuring the data transfer process, a PSA table is created when the DataSource of the data transfer process is activated.

Procedure

1. In your BW system, start the Data Warehousing Workbench.2. Create a new Data Transfer Process or select the DataSource of an existing Data Transfer Process.

3. Choose Goto Technical Attributes .4. To change the data class of PSA tables, enter the required value in the Data Class for PSA Table field.5. Choose Transfer.6. To activate the DataSource, choose Activate from the application toolbar.

50 P U B L I C



5 Direct Execution of Queries with Restrictions (FEMS Queries)

Queries with local restrictions can be expensive to process because they might require a lot of data transfer between the database and the application server and additional processing in the OLAP processor. If you implement the direct execution of such queries in the database, this can speed up performance.

As of SAP BW 7.5 SP 4, queries with local restrictions can be completely processed in the IBM Db2 database.

NoteTo be able to execute queries with local restrictions in the IBM Db2 database, you must be part of a pilot program. To register for the pilot program, open a customer incident on component BW-SYS-DB-DB6.

5.1 Queries with Local Restrictions (FEMS Queries): Introduction

Learn more about how queries with local restrictions work and why processing of these queries in the database improves performance.

FEMS Queries

BW reporting queries may contain global restrictions (FEMS0) and local restrictions (FEMSn) for the different cells in the output of the report. Queries with local restrictions are also referred to as “FEMS queries”.

Performance Considerations

Queries with local restrictions might involve many characteristics. Therefore, the result set of an SQL query can be large; further processing in the OLAP processor might be expensive. Processing queries with local restrictions completely in the database and returning the correct key figure value for each local restriction can speed up processing considerably. Less data needs to be transferred between database and application server, and less data needs to be further processed in the OLAP processor.

Direct processing of FEMS queries in the database often speeds up performance, but it depends on the amount of data transfer.

Processing of FEMS queries directly in the database is faster than the traditional processing when the amount of data that needs to be transferred between database and application server to evaluate the FEMS restrictions

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksDirect Execution of Queries with Restrictions (FEMS Queries) P U B L I C 51

is considerably reduced. This is often the case when the FEMS restrictions are defined on additional characteristics which themselves do not occur in the output report. However, when the amount of data transferred cannot be reduced, FEMS query processing in the database might take longer than traditional query processing because the SQL queries are more complex.

Example

The following example illustrates a query with restrictions:

The query contains a global restriction on calendar year 2013:

There are local restrictions on columns 1, 2, 3, and 4, and on rows 1 and 2 of the output report. The local restrictions on the output columns of the report are time restrictions to the first, second, third, and fourth quarter of year 2013. The local restrictions on the output rows of the report are restrictions to sales organization 1 and 2. The key figure to be displayed is the sum of sales order items for these quarters for each customer region number of customer orders handled in sales organization 1 and 2. With different local restrictions defined for each row and column of the output report, the query contains 8 FEMS <> FEMS0 (one for each cell in the output report).

52 P U B L I C


Direct Execution of Queries with Restrictions (FEMS Queries)

By default, FEMS queries are processed in such a way that a more general SQL query is executed in the database that returns the key figures and all the characteristics that are needed for the evaluation of the local restrictions. The SAP BW OLAP processor uses this result to calculate the correct key figure value for each cell in the report output. The standard SQL statement that is executed for the BW query for this example is as follows:

Sample Code

SELECT "F"."/B49/S_CURRENCY" AS "S____181", "F"."/B49/S_SLSORG" AS "S____158", "F"."SID_0CALMONTH" AS "S____006", SUM ( "F"."/B49/S_NET_PRICE" ) AS "Z____182_SUM", COUNT_BIG( * ) AS "Z____043_SUM"FROM"/BIC/FCFEMS01" "F"JOIN "/BIC/DCFEMS01P" "DP" ON "F" . "KEY_CFEMS01P" = "DP" . "DIMID" WHERE (((("F"."SID_0CALYEAR" = 2013)) AND (("DP"."SID_0CHNGID" = 0)) AND (("DP"."SID_0REQUID" <= 26148)))) AND (((("F"."/B49/S_SLSORG" = 195)) AND (("F"."SID_0CALMONTH" IN (201301,201302,201303)))) OR ((("F"."/B49/S_SLSORG" = 196)) AND (("F"."SID_0CALMONTH" IN (201301,201302,201303)))) OR ((("F"."/B49/S_SLSORG" = 195)) AND (("F"."SID_0CALMONTH" IN (201304,201305,201306)))) OR ((("F"."/B49/S_SLSORG" = 196)) AND (("F"."SID_0CALMONTH" IN (201304,201305,201306)))) OR


((("F"."/B49/S_SLSORG" = 195)) AND (("F"."SID_0CALMONTH" IN (201307,201308,201309)))) OR ((("F"."/B49/S_SLSORG" = 196)) AND (("F"."SID_0CALMONTH" IN (201307,201308,201309)))) OR ((("F"."/B49/S_SLSORG" = 195)) AND (("F"."SID_0CALMONTH" IN (201310,201311,201312)))) OR ((("F"."/B49/S_SLSORG" = 196)) AND (("F"."SID_0CALMONTH" IN (201310,201311,201312)))) )GROUP BY "F"."/B49/S_CURRENCY","F"."/B49/S_SLSORG","F"."SID_0CALMONTH"

The result set of the SQL query contains the values for the following characteristics:

● "/B49/S_CURRENCY"● "F"."/B49/S_SLSORG"● "F"."SID_0CALMONTH"

The SAP OLAP processor needs these characteristics to evaluate the FEMS restrictions. In the WHERE clause, the SQL query also contains all the local restrictions combined by OR.

The SAP BW OLAP processor may omit these restrictions completely or simplify them if the SQL statement gets too complicated. As you can see from this example, local restrictions might involve many characteristics so that the result set of the SQL query can be large. Then further processing in the OLAP processor of the SAP BW system might be expensive. Therefore, processing queries with local restrictions completely in the database can speed up processing considerably.

5.2 Prerequisites and Constraints for Direct FEMS Query Execution

To process FEMS queries completely in the IBM Db2 database, different prerequisites and constraints apply.

Prerequisites

You must be part of a pilot program. To register for the pilot program, open a customer incident on component BW-SYS-DB-DB6.

You need IBM Db2 for Linux, UNIX, and Windows 10.5 FP7 or higher, and you need SAP BW 7.5 SP4 or higher.

In addition, you need the following SAP Notes:

● 2341880 : Corrections for the Pushdown of Local Restrictions to the Database Layer● 2485186 : DB6: DB6specific Corrections for the Pushdown of Local Restrictions to the Database Layer● 2488766 : FEMS Pushdown Performance Improvements● 2497715 : DB6: FEMS Pushdown Performance Improvements● 2494488 : Invalid BW Queries for Hierarchy Filters with FEMS Pushdown

54 P U B L I C








For InfoCubes, you need the following SAP Notes or the support packages mentioned in these SAP Notes:

● SAP Note 2302681● SAP Note 2329587

For DataStore objects, you need the following SAP Notes or the support packages mentioned in these SAP Notes:

● 2418901● 2457117

Constraints

The following constraints apply:

● Only DataStore objects and flat cumulative InfoCubes are supported. FEMS query processing in the database is not available for inventory InfoCubes or standard InfoCubes with row-organized or column-organized tables, that is, “star schema” InfoCubes.

● For queries that contain fewer than two local restrictions, FEMS query processing in the database is not used.

● If two local restrictions exist, FEMS processing in the database is used only when it substantially reduces the amount of data returned from the database to the application server. This is the case when characteristics that are needed only for the evaluation of the local restrictions are processed in the database. The characteristics are not returned to the application server. SAP BW considers FEMS processing in the database as beneficial if at least two such characteristics exist. You change the threshold of at least two characteristics by changing the RSADMIN parameter DB6_FEMS_CHA_THRES.

● If the BW query involves currency, unit, or other conversions, the conversions can't be processed directly in the database. The result set of the SQL query returned to the application server still contains the currencies and units. The conversions can then be performed in the SAP OLAP processor. However, other characteristics needed for the evaluation of the local restrictions are not contained in the result set.

5.3 Enabling FEMS Query Processing in the Database

By default, FEMS query processing in the database is disabled. You can enable FEMS query processing in the database by setting RSADMIN parameter USE_FEMS_IN_DB to X.

Context

Setting this RSADMIN parameter enables FEMS query processing in the database for the entire SAP BW system. You can also enable or disable the FEMS query processing in the database at the InfoProvider level and at the query level.






NoteYou cannot enable FEMS query processing in the database and use a Business Warehouse Accelerator (BWA) system at the same time. Once you enable FEMS query processing in the database, the BWA can no longer be used.

Procedure


2. Enter the RSADMIN parameter USE_FEMS_IN_DB in the OBJECT field and X in the VALUE field.

Related Information

Enabling or Disabling FEMS Query Processing at the InfoCube or DataStore Object Level [page 56]Enabling or Disabling FEMS Query Processing at the Query Level [page 59]

5.4 Enabling or Disabling FEMS Query Processing at the InfoCube or DataStore Object Level

You can enable or disable FEMS query processing in the database at InfoCube or DataStore object level using the Data Warehousing Workbench.

Procedure


2. Open the InfoCube or the DataStore object for display.

3. From the menu, choose Extras InfoProvider Properties Change .

56 P U B L I C



4. To enable FEMS query processing in the database for the InfoCube or DataStore object, select a value of 2 or higher in the SAP HANA/BWA Ops field.


5. To disable FEMS query processing in the database for the InfoCube or DataStore object, select the value 0.

Results

FEMS query processing in the database is enabled or disabled for the selected InfoCube or DataStore object. You can still override the setting for FEMS query processing in the database for individual BW queries.

Related Information

Enabling or Disabling FEMS Query Processing at the Query Level [page 59]

58 P U B L I C



5.5 Enabling or Disabling FEMS Query Processing at the Query Level

You have enabled FEMS query processing in the database for an InfoCube or DataStore object, but you want to override this setting for individual SAP BW queries? That's possible.

Procedure

1. Call the query monitor (transaction RSRT).

2. Enter the name of the query.

3. Select Properties.

In the Query Properties dialog box, option Operations in BWA/HANA is set to the InfoProvider to which the query belongs. This is the default.


4. To change the setting, unselect the checkbox InfoProvider Setting.5. To enable FEMS query processing in the database for the query, select a value of 2 or higher in the

Operations in BWA/HANA field.

60 P U B L I C



To disable FEMS query processing in the database for the BW query, select value 0 No optimized operations in SAP HANA/no BWA.


6 Settings for Non-BLU Systems

If you run SAP Business Warehouse without BLU Acceleration, consider using Db2 compression and multidimensional clustering (MDC).

Db2 compression settings and MDC are relevant only for non-BLU systems. BLU Acceleration comes with its own compression, so special settings for Db2 compression are only needed for non-BLU systems. Systems with BLU Acceleration use column-organized tables instead of MDC as a clustering option.

6.1 Db2 Compression (Non-BLU Systems Only)

Db2 compression is relevant only if you use row-organized tables. Column-organized tables (BLU Acceleration) are always automatically compressed, and as such require no decision with regard to compression on your side.

Db2 row compression and index compression considerably save space on disk and in the buffer pool. In addition, Db2 compression also reduces the need for I/O and thus has a positive impact on performance. We recommend that you use Db2 compression.

Compression is globally controlled by the Db2 global variable SAP<SID>.GLOBAL_COMPRESSION_OPTION, which defines whether newly created database tables are compressed after creation. The setting applies for all tables in the database, including SAP BWspecific tables.

If you install an SAP BW system using the currently available software provisioning manager, Db2 compression is enabled by default in your newly installed system and you don't need to do anything. If you installed your SAP BW system a long time ago, however, you may need to enable Db2 compression manually.

In older releases and support packages of SAP BW, the Db2 global variable SAP<SID>.GLOBAL_COMPRESSION_OPTION was not available. Instead, it was possible to use RSADMIN parameter DB6_ROW_COMPRESSION to control compression. For compatibility, this RSADMIN parameter is still available, but you should not use it if SAP<SID>.GLOBAL_COMPRESSION_OPTION is available.

To check whether your system has not fully enabled Db2 compression, use the DBA Cockpit (transaction DBACOCKPIT). For more information, see the DBA Cockpit documentation at https://help.sap.com/viewer/db6_dbacockpit.

62 P U B L I C


Settings for Non-BLU Systems

https://help.sap.com/viewer/db6_dbacockpit


6.1.1 Enabling Compression Centrally Using the Global Compression Option

With the global compression option, you can specify whether all newly created tables are compressed.

Prerequisites

To use the global compression option in SAP BW, you need the following minimum support packages:

● SAP BW 7.0 Support Package 30● SAP BW 7.01 Support Package 13● SAP BW 7.02 Support Package 13● SAP BW 7.3 Support Package 8● SAP BW 7.31 Support Package 5● SAP BW 7.4 (no Support Package required)

Context

The Db2 global variable SAP<SID>.GLOBAL_COMPRESSION_OPTION determines the Db2 compression settings at table creation time.

Setting the variable has no effect on existing tables that already contain data. If you reactivate a table that already contains data, compression settings are not changed. If an empty object is activated, however, the database tables are dropped and re-created using the current compression settings. To change the compression of an existing table that already contains data, use the DBA Cockpit or program DB6CONV.

Procedure

1. You can enable row compression during the installation of the SAP BW system by selecting Use Db2’s Row Compression in the appropriate dialog of SAP's software provisioning manager.This sets the global compression option to YES. As of Db2 10.5, the default compression type is adaptive compression.For more information, see the installation guide for SAP systems based on SAP NetWeaver.

2. If you have not enabled compression during installation, you can also enable compression later, for example, using the command line, the DBA Cockpit, or program DB6CONV.

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksSettings for Non-BLU Systems P U B L I C 63

More Information

Topic Further Information

Global compression option in general SAP Note 1690077

Global compression option in SAP BW 7.0-based releases SAP Note 1742347

Global compression option in SAP BW 7.3 and higher SAP Note 1716996

Installation of SAP systems http://support.sap.com/sltoolset System Provisioning

Installation Option of Software Provisioning Manager

Installation Guides - Application Server Systems

DBA Cockpit https://help.sap.com/viewer/db6_dbacockpit

Program DB6CONV SAP Note 1513862

6.2 Multidimensional Clustering (Non-BLU Systems Only)

In SAP BW systems without BLU Acceleration, you can use multidimensional clustering (MDC) to speed up database performance.

In SAP BW systems, there is a default table layout for each object. Depending on the SAP BW object, on the SAP BW release, and on the database version, this default table layout is a basic layout or multidimensional clustering (MDC). Here you'll get an overview of how the basic layout and MDC work and how you can implement MDC. This is relevant if you don't use BLU Acceleration for your SAP BW system. Note, however, that MDC is only the second-best solution in comparison to BLU Acceleration. As of Db2 10.5, we recommend that you use column-organized tables (Db2 BLU Acceleration), which considerably improves database performance.

6.2.1 Basic Table Layout and Index Clustering

Learn more about the basic table layout and index clustering and why you should prefer multidimensional clustering (MDC) and BLU Acceleration to index clustering.

Basic Table Layout

In the basic table layout of SAP BW, regular tables and indexes are used. The basic table layout is available for all BW objects and on all operating systems. Where appropriate and useful, the basic table layout uses Db2 index clustering.

64 P U B L I C






http://help.sap.com/disclaimer?site=http%3A%2F%2Fsupport.sap.com%2Fsltoolset



RecommendationYou can stay with the basic layout, but we recommend that you use multidimensional clustering or column-organized tables instead.

Index Clustering

With index clustering, Db2 attempts to maintain the physical order of data records of a table according to the key order of an index (the clustering index). Data records with the same key values or key values in the same range are stored physically close together. Clustering indexes improve the performance of range queries that have predicates containing the key (or keys) of the clustering index. Performance improves with a clustering index because only a part of a table needs to be accessed, and prefetching is more efficient.

Only one index can be designated as the clustering index, and all other indexes are non-clustering, because the data can only be physically clustered along one index.

Example: Table with a Clustering Index and a Non-Clustering Index

In the example shown here, two indexes are defined for the table Sales: a clustering index for Region with the values East, West, North, and South, and a non-clustering index for Year with values from 2018 to 2020. Four records in the table make up a data page. The order of the records in the data pages of the table is the same as the order of keys in the clustering index Region. As opposed to the clustering index, the order of the keys in the index Year can be found on random data pages throughout the table. Therefore, scans on the clustering index Region exhibit better I/O performance and benefit more from sequential prefetching than scans on the non-clustering index Year.


Disadvantages of Index Clustering

Although index clustering improves performance, it also has some disadvantages:

● Only one index can be designated as the clustering index, and all other indexes are non-clustering.● Clustering is not guaranteed.

Since space is filled up in the data pages over time, clustering is not guaranteed. An INSERT operation attempts to add a record physically close to records that have the same or similar clustering key values. If no space can be found in the ideal location, the record is inserted elsewhere in the table. Over time, such insertions degrade the quality of the clustering.To reestablish the best clustering of a table and to set up data pages with additional free space to accommodate future clustered INSERT requests, periodic table reorganizations are required.

6.2.2 Multidimensional Clustering (MDC)

Multidimensional clustering (MDC) is a Db2 feature for clustering data in tables according to multiple dimensions in a flexible, continuous, and automated way.

Advantages

MDC overcomes the disadvantages of standard index clustering in the following ways:

● No need for reorganizations to retain clustering over timeWhereas the quality of traditional clustering indexes decreases over time, Db2 automatically preserves clustering of MDC tables when data is inserted or updated.

● Clustering according to more than one dimensionMDC allows you to cluster a table physically according to more than one key or dimension. With MDC, the benefits of single-dimensional clustering are extended to multiple dimensions or clustering keys.

In addition, MDC has the following main advantages:

● Performance of queries with restrictions on MDC columns can be significantly improved.● Performance of INSERT and DELETE operations can be improved.● MDC indexes are much smaller than traditional indexes.● Automatic space reclamation is available.

Due to its ability to cluster data along multiple dimensions, MDC helps to improve performance of data warehouse applications that are based on multidimensional data models. MDC is fully integrated into SAP Business Warehouse (SAP BW).

Blocks and Block Indexes

MDC physically organizes data in a table into blocks according to clustering values. Each block contains only records with identical values in the MDC columns. As a result, all records in a block are perfectly clustered

66 P U B L I C



according to MDC columns. The number of I/O operations that are required to process queries with restrictions on these MDC columns is drastically reduced.

MDC also introduces the concept of block indexes. For each MDC dimension, a block index is automatically created by Db2. Block indexes are structurally the same as regular indexes, except that they point to blocks instead of records. Block-based indexes are much smaller than regular record-based indexes. Therefore, block indexes consume less disk space and can be scanned faster.

If more than one dimension is specified for MDC, Db2 also creates an additional composite block index that contains all MDC dimensions.

Example: Composite Block Index

Improved Loading and Deletion of Data

MDC provides fast roll-in and roll-out capabilities that improve performance when larger parts of a table are loaded or deleted.

The performance of INSERT statements is improved by the fast roll-in capability of MDC tables. The fast roll-in capability reduces the amount of information that is written to the database log files. In addition, MDC provides block-level locking, which is automatically activated by SAP BW when bulks of data are inserted into separate cells by different processes. Block-level locking reduces the demand for memory in the Db2 lock list.

The performance of DELETE statements is improved by the fast roll-out capability of MDC tables. The fast roll-out capability flags MDC blocks as deleted and releases the data pages later on. DELETE statements that contain only restrictions on the MDC columns can be processed fast because they can mark complete extents as free instead of deleting single records. In addition, Db2 uses asynchronous index cleanup during deletion, which makes the deletion much faster.


After deletions, completely free extents can be returned from an MDC table to the tablespace using the Db2 REORG TABLE RECLAIM EXTENTS command. This operation is performed automatically by the Db2 automatic table maintenance daemon if you have configured Db2 automatic table maintenance according to SAP recommendations.

InfoPackage Deletion

If you do not use MDC, InfoPackage deletions are split into several database transactions. For PSA tables and change log tables of DataStore objects, one data package of the InfoPackage is deleted per database transaction. For F tables of InfoCubes, you can configure the number of rows deleted in each database transaction by setting RSADMIN parameter DBMS_MAX_DELETE. The default is 3,000,000 rows per database transaction. Each deletion of a table row is written to the database log, which contributes considerably to log space consumption.

If you use MDC, log space consumption decreases because InfoPackage deletion benefits from the fast rollout capabilities of MDC. If the MDC dimensions are chosen correctly, the DELETE statement contains only restrictions on the MDC columns, whole extents are marked as free instead of deleting single records. In addition, Db2 uses asynchronous index cleanup, which further reduces log space consumption and speeds up performance even more, because the deletion process does not have to wait for the index cleanup to complete.

6.2.3 Implementing Multidimensional Clustering (MDC) for SAP BW Objects

6.2.3.1 Implementing MDC for SAP BW Objects: Overview

To implement multidimensional clustering (MDC), you must set the relevant parameters for each SAP BW object. Get a quick overview how this is done.

Required Actions and Parameters

The following table summarizes how you set up MDC for all SAP BW objects for which MDC is supported. The default settings might depend on the support package level of your SAP Business Warehouse system and your database version. For more information, see the respective SAP Notes mentioned in this table.

68 P U B L I C



Implementing MDC for SAP BW Objects: Required Actions and Parameters

Table Required User Action and MDC Dimension

Lock Size Comments

PSA MDC is the default. You cannot choose any other MDC dimension than the request ID.

Only if you want to switch off MDC as the default clustering option, do you need to set the RSADMIN parameter DB6_MDC_FOR_PSA to NO.

Block This default is available with SAP Note 1481572

and the support packages mentioned in this SAP Note.

Standard DataStore object – activation queue table

MDC is the default. You cannot choose any other MDC dimension than the request ID.


NoteDespite its misleading name, DB6_MDC_FOR_PSA is the correct RSADMIN parameter for PSAs and for DataStore objects, too.



Standard DataStore object – change log table

MDC is the default. You cannot choose any other MDC dimension than the request ID.


Row This default is available with SAP Note 1481572


Standard DataStore object – active table

To enable MDC, choose the appropriate option in the clustering dialog of the Data Warehousing Workbench (transaction RSA1). You can choose the key fields as MDC dimensions.

Row -









Lock Size Comments

DataStore object for direct update – change log table

MDC is the default. You cannot choose any MDC dimension other than the request ID.


Row This default is available with SAP Note 1481572


DataStore object for direct update – active table

To enable MDC, choose the appropriate option in the clustering dialog of the Data Warehousing Workbench. You can choose the key fields as MDC dimensions.

Row -

Write-optimized DataStore object

MDC is the default. You cannot choose any MDC dimension other than the request ID.




F fact table – InfoCube MDC is the default, with the package dimension key as default MDC dimension.

To add more MDC dimensions, choose the appropriate option in the clustering dialog of the Data Warehousing Workbench. You can choose userdefined dimension ID fields and one time characteristic as MDC dimensions.

Only if you want to switch off MDC as the default clustering option, do you need to set the RSADMIN parameter DB6_MDC_FOR_FTAB to NO. If the parameter is set to NO, index clustering is used.



E fact table – InfoCube To enable MDC, choose the appropriate option in the clustering dialog of the Data Warehousing Workbench. You can choose userdefined dimension ID fields and one time characteristic as MDC dimensions.

Block -

70 P U B L I C










Lock Size Comments

F fact table – aggregate By default, the aggregates defined for the InfoCube inherit the MDC settings from the InfoCube.

Only if you want to switch off MDC as the default clustering option, do you need to set the RSADMIN parameter DB6_MDC_FOR_AGGREGATES to NO.

Block -

E fact table – aggregate By default, the aggregates defined for the InfoCube inherit the MDC settings from the InfoCube.

Only if you want to switch off MDC as the default clustering option, do you need to set the RSADMIN parameter DB6_MDC_FOR_AGGREGATES to NO.

Block -

Additional Parameters

RSADMIN Parameter Description Default Value

DB6_MAX_MDC_COLS Defines the default maximum number of MDC dimensions for InfoCubes and for the active tables of DataStore objects

3

Setting RSADMIN Parameters

To set an RSADMIN parameter, proceed as follows:

1. Call the ABAP editor (transaction SE38).2. Run program SAP_RSADMIN_MAINTAIN.

More Information

Setting Up MDC for New Standard InfoCubes and DataStore Objects [page 72]

SAP Note 832621



6.2.3.2 Setting Up MDC for New Standard InfoCubes and DataStore Objects

For many SAP BW objects, MDC is the default and you cannot change their MDC dimensions. For InfoCubes and active tables of DataStore objects, however, you can choose MDC clustering options in the Data Warehousing Workbench.

Background

As of SAP Notes 1759015 and 1481572 and the relevant support packages for SAP BW mentioned in these SAP Notes, the default clustering option for standard InfoCubes and for the activation queue table and the change log table of DataStore objects is MDC. You can select MDC manually only for the active table of standard DataStore objects and of DataStore objects for direct update when you create them. In addition, you can change the default clustering settings or add more MDC dimensions than the default MDC dimensions to an InfoCube. You can perform these changes in the clustering dialog of the Data Warehousing Workbench when you create new InfoCubes and DataStore objects.

NoteThe documentation about implementing MDC always refers to standard InfoCubes, including real-time InfoCubes. You cannot create flat InfoCubes with MDC because they are column-organized and designed for SAP BW systems with BLU Acceleration.

6.2.3.2.1 Choosing the Right MDC Dimensions

For standard InfoCubes and the active tables of DataStore objects, you can choose MDC dimensions manually. Decide carefully which MDC dimensions are best for your specific needs.

For all other SAP BW objects and tables, MDC dimensions are fixed and cannot be changed (see Implementing MDC for SAP BW Objects: Overview [page 68]).

This section helps you to find the right MDC dimensions for InfoCubes and DataStore objects and to achieve the following:

● Improve the performance of queries● Improve the performance of INSERT and DELETE statements● Limit disk space consumption● Reduce database log space consumption

NoteIf you have created InfoCubes or DataStore objects with MDC and, after running the SAP BW system for some time, you have the impression that the MDC dimensions are not optimally chosen, you can use the MDC Advisor to improve your MDC dimensions. The MDC Advisor analyzes collected BW reporting queries to provide you with an MDC proposal. For more information, see Improving MDC Settings Using the MDC Advisor [page 86].

72 P U B L I C





General Considerations

For standard InfoCubes, the request dimension ID field is predefined as an MDC dimension, which considerably improves the performance of InfoCube compression. In addition, you can select the time dimension ID field and all dimension ID fields of userdefined dimensions as MDC dimensions.

Instead of the time dimension ID field, you can also choose the time characteristics Calendar Month (0CALMONTH) or Fiscal Period (0FISCPER) as MDC dimensions.

For DataStore objects, MDC dimensions can only be InfoObject fields that were selected as key fields. This also includes InfoObjects that are time characteristics, such as Calendar Month (0CALMONTH) or Fiscal Period (0FISCPER).

Improving the Performance of Queries

The response time of a query on an MDC table improves only if the query is restricted to one or more MDC dimensions. Therefore, choose MDC dimensions for which restrictions in your queries occur frequently.

Most queries have a restriction on a time period. Therefore, you should select the time dimension for InfoCubes or a time characteristic for DataStore objects as follows:

● If most of the queries are restricted to the time characteristic 0CALMONTH or 0FISCPER, choose this time characteristic as MDC dimension.

● If you expect more granular queries, select the time dimension ID field as MDC dimension for InfoCubes or an adequate InfoObject that is a time characteristic for DataStore objects.

Improving the Performance of INSERT and DELETE Statements

The performance of INSERT and DELETE statements is improved by the fast roll-in and roll-out capability of MDC tables. This applies to any MDC dimension selection.

For InfoCubes, the request dimension ID field is predefined as an MDC dimension, which improves the performance of INSERT and DELETE statements on the F fact table and InfoCube compression. Only if you do not use InfoCube compression, consider deselecting the request dimension ID field as an MDC dimension. Each additional MDC dimension increases the risk of sparsely filled MDC blocks, which increases disk space consumption.

Limiting Disk Space Consumption

By default, the maximum number of MDC dimensions is limited to three.

The more MDC dimensions you select, the more granular the blocks become and are therefore more likely to be sparsely filled. For each value combination that occurs in one or more data rows, at least one block is reserved in the MDC dimensions. If the table is distributed across several partitions, blocks are allocated on all partitions on which a value combination occurs. If there are only a few rows for each value combination on each


partition, a bigger portion of each block remains empty, and the number of allocated data pages is larger than required. This not only leads to a waste of disk space, but it also has a negative impact on the query performance because many sparsely filled data pages have to be read from disk.

To limit disk space consumption for InfoCubes, choose the MDC dimensions according to the expected cardinalities of the InfoCube’s dimensions and characteristics:

● Choose only InfoCube MDC dimensions with a low cardinality.● If a characteristic occurs often in restrictions of queries and has a low cardinality, define a line item

dimension for this characteristic and select it as an MDC dimension.Verify that the characteristic does have a low cardinality. For example, choosing characteristics like country or material group, which are part of larger dimensions such as customer or material and which usually have a high cardinality, can lead to unnecessarily high disk space consumption. In exceptional cases, the characteristics country or material group may have a low cardinality. Under these circumstances, selecting them as MDC dimensions might limit the space consumption and improve query performance.

To limit disk space consumption for DataStore objects, similar rules apply: As MDC dimensions, choose key InfoObjects of the DataStore object with a low cardinality, especially if you choose more than one MDC dimension.

In addition, make sure that you use tablespaces with extent size 2 for MDC objects. Larger extent sizes lead to substantially increased disk space consumption, particularly if you have sparsely filled blocks.

Disk Space Consumption of Typical MDC Selections for InfoCubesAs a rule of thumb, you can expect the following estimated disk space consumption of MDC selections for InfoCubes:

● MDC selection with the time dimension and the request dimension: The disk space consumption is similar to index clustering because the MDC dimensions request and time are often correlated. The E fact table is clustered on the single MDC dimension time.

● MDC selection with a time characteristic and the request dimension: The disk space consumption is similar to index clustering because the F fact tables are clustered on two correlated MDC dimensions and the E fact table on a single MDC dimension.

● MDC selection with a time characteristic and a user-defined dimension: If the MDC selection is not appropriate for the actual data distribution in the MDC dimensions, disk space consumption with MDC can be higher than disk space consumption with index clustering.

Disk Space Consumption of Typical MDC Selections for DataStore ObjectsAs a rule of thumb, you can expect the following estimated disk space consumption of MDC selections for DataStore objects:

● MDC selection with one time characteristic only: The disk space consumption depends on the number of records with the same value for the time characteristic. If there are enough records in each MDC logical cell to fill at least one extent to 90% or more, disk space consumption is not a problem.

● MDC selection with two characteristics: If the MDC selection is not appropriate for the actual data distribution in the MDC dimensions, disk space consumption can be considerably higher compared to MDC with only the time characteristic or without MDC.

74 P U B L I C



Reducing the Database Log Space Consumption

To improve performance and reduce log space consumption of the database during InfoPackage deletion, we recommend that you include the package dimension in the MDC dimensions of an InfoCube.

6.2.3.2.2 Changing the Default MDC Dimensions for New or Empty Standard InfoCubes

Use the Data Warehousing Workbench to change the MDC default dimensions for new or empty InfoCubes.

Context

When you create new InfoCubes in the Data Warehousing Workbench, you can change the default MDC dimensions.

As of SAP Note 1759015 and the relevant support package levels for SAP BW mentioned in this SAP Note, InfoCubes are created with MDC as the default clustering option and the package dimension key as the MDC dimension. When you create a new InfoCube, you can leave the default clustering as it is or you can use the clustering dialog in the Data Warehousing Workbench to adapt MDC dimensions to your needs.

NoteYou cannot change the clustering settings of an existing active InfoCube that already contains data. Instead, recluster the InfoCube as described in Reclustering InfoCubes [page 80].

Procedure

1. In your SAP BW system, call the Data Warehousing Workbench (transaction RSA1).2. In the tree structure, navigate to an InfoArea where you either want to create a new InfoCube or select an

existing one.3. From the context menu, choose Create InfoCube... or Change, depending on the choice you have made in

the previous step.4. Define the dimensions and key figures of the InfoCube.

5. Choose Extras DB Performance Clustering .



The Selection of Clustering dialog box appears:

Dialog Box "Selection of Clustering"

If the InfoCube already contains data, the dialog box is inactive.6. Make sure that Multidimensional Clustering is selected and continue.

The Multidimensional Clustering dialog box appears:

Multidimensional Clustering7. To define MDC dimensions in the Multidimensional Clustering dialog box, proceed as follows:

○ To define the package dimension key column as an MDC dimension for the F fact table, select Package Dimension on F Fact Table in the Package Dimension group box. With SAP Note 1759015 , this is

76 P U B L I C




selected by default. Without SAP Note 1759015 , you can select the package dimension, but you also need to select additional MDC dimensions.

○ To define the time dimension ID field as an MDC dimension on both fact tables, choose Dim. ID of Time Dimension in the Selected Column field.When the InfoCube is activated or reclustered, the fact tables do not contain an additional SID field for the time characteristics 0CALMONTH or 0FISCPER. The secondary index on the time dimension ID field is not created. Instead, an MDC block index is created.

○ To define a time characteristic as an MDC dimension on both fact tables, choose Fiscal year/period or Calendar year/month in the Selected Column field.A time characteristic appears in the drop-down list only if it exists in the InfoCube. When the InfoCube is activated or reclustered, an additional field for the SID value of the time characteristic is added to the F fact table and E fact table. A block index is created on this additional field.

○ To define a userdefined dimension as an MDC dimension on both fact tables, add a number in the Stat. No. field in the Char. Dimension group box for the dimension.When the InfoCube is activated or reclustered, the secondary index on the dimension ID field is not created. Instead, an MDC block index is created.

The status numbers indicate the order of the MDC dimensions. If you select an item in the Selected Column field, the inactive Status Number field is automatically filled with 1.As a result, the selected column is always the first MDC dimension. If the Selected Column field is empty, the status number is 0. In the Char. Dimension group box, you can manually add a number in the Stat. No. field of a dimension. The status numbers must be consecutive. No more than three MDC dimensions can be selected, including the time dimension.If you also select the request ID as MDC dimension, the request ID does not receive a status number.

More Information

Table Layout Options for Standard InfoCubes [page 166]

Choosing the Right MDC Dimensions [page 72]

6.2.3.2.3 Changing the Default MDC Dimensions for New or Empty DataStore Objects

Use the Data Warehousing Workbench to change the default MDC dimensions for the active tables of new or empty DataStore objects.

Context

When you create new DataStore objects, you can define MDC dimensions only for active tables. For all other tables of DataStore objects, the request ID is the default MDC dimension if you have implemented SAP Note 1481572 or the support package levels mentioned in this SAP Note. You cannot define any other MDC dimensions.




NoteYou cannot change the clustering of an existing active DataStore object that already contains data. Instead, recluster it as described in Reclustering DataStore Objects [page 83].

Procedure

1. In your SAP BW system, call the Data Warehousing Workbench (transaction RSA1).

2. In the tree structure, navigate to an InfoArea where you either want to create a new DataStore object or select an existing one.

3. From the context menu, choose Create New DataStore Object... or Change, depending on the choice you have made in the previous step.

4. Define the key fields and the data fields of the DataStore object.

5. Choose Extras DB Performance Clustering .

The Selection of Clustering dialog box appears:

Dialog Box "Selection of Clustering"

6. Make sure that Multi-Dimensional Clustering is selected and continue.

78 P U B L I C



The dialog box Multi-Dimensional Clustering appears:

Dialog Box "Multi-Dimensional Clustering"

7. To select MDC dimensions from the InfoObjects that belong to the key of the DataStore object, enter a status number in the Stat.No. field.

The status numbers define the order of the MDC dimensions. The status numbers that you enter must be consecutive. You cannot enter more than three MDC dimensions.

6.2.3.3 Reclustering SAP BW ObjectsRecluster InfoCubes and DataStore objects if you want to change the MDC layout for InfoCubes and DataStore objects that already contain data.

NoteYou cannot recluster write-optimized DataStore objects and PSA tables.

Reclustering Process

During reclustering, target tables are created as copies of the fact tables of InfoCubes and of the active table of DataStore objects with the new clustering settings. The data is then copied from the source tables to the target


tables. Then, the original source tables are renamed, so that you can keep them as backups, and the target tables are renamed to the names of the original source tables.

For InfoCubes, the clustering settings of their aggregates are adapted to the clustering settings of the InfoCube. Therefore, if you select MDC for an InfoCube, the aggregates will be MDC-clustered as well. If you select index clustering, the aggregates will also be index-clustered. Using index clustering requires that you first deactivate the aggregates, then reactivate them to be refilled.

CautionReclustering can take a long time, as the data needs to be copied to a new table with the new clustering settings. Also, before you start to recluster DataStore objects and InfoCubes, we strongly recommend that you perform a complete backup of the database.

Blocked, Forbidden, and Allowed Operations During Reclustering

During reclustering, a write lock is acquired for the InfoCube or DataStore object so that operations that add, delete, or change data in these objects are blocked. During the write lock, read operations are allowed. While the source and target tables are renamed, a read lock that blocks all reporting functions is acquired for InfoCubes. For DataStore objects, a read lock is not acquired. You must make sure that no reporting or delta updates into other InfoProviders are executed.

6.2.3.3.1 Reclustering InfoCubes

Use the Data Warehousing Workbench to recluster a standard InfoCube.

Prerequisites

You have created a backup of your database.

Procedure

1. In your SAP BW system, call the Data Warehousing Workbench (transaction RSA1).2. Navigate to the InfoCube for which you want to create and schedule a reclustering job.

3. From the context menu, choose Additional Functions Reclustering .

80 P U B L I C



The Reclustering of InfoProviders dialog box appears:

Reclustering of InfoProviders4. To define new data classes for the InfoCube or its aggregates, enter the data class names in the Target Data

Class field.5. To enable row compression for the InfoCube, choose Compress InfoCube Fact Tables / DataStore Active

Tables.The database creates the compression dictionary automatically. Therefore, you cannot change the number of inserted lines before compression.

6. To specify the size of data packages to be copied in one transaction from the source tables to the target tables, enter the required value in the Commit Size (MB) field.This value restricts the size of the units of work so that log overflows do not occur. The default value is 300 MB.

7. To continue, choose Initialize.8. Confirm that you have created a backup of your database.9. In the Selection of Clustering dialog box, choose multidimensional clustering.


The Multi-Dimensional Clustering dialog box appears:

Multidimensional Clustering10. Enter all required values in the Multi-Dimensional Clustering dialog box as follows:

○ In the Package Dimension field, you can specify the request ID as an MDC dimension.○ In the Selected Column field of the Time Dimension group box, you can choose a time characteristic or

the time dimension ID field.○ In the Char. Dimension group box, you can select one or more userdefined dimensions by entering a

number in the Stat.No. field. The numbers indicate the order of the MDC dimensions. The numbers must be consecutive. You cannot enter more than three MDC dimensions.

○ To estimate the MDC disk space consumption based on your entries, choose the Execute Space Check checkbox.The estimation is based on the data currently stored in the InfoCube. The estimated percentage of free space for the fact tables and the aggregates appears in a message window. If the percentage of free space is higher than 33%, consider selecting different MDC dimensions.

For more information about the required entries, see Setting Up MDC for New or Empty Standard InfoCubes Using the Data Warehousing Workbench [page 75], starting with step 7.

11. Confirm your entries.A message window indicating that a new reclustering request has been created appears.

12. Confirm the message window.13. In the Start Time dialog box, schedule the reclustering job as a background job.

You can monitor the job using transaction SM37 or using the BW request monitor.

82 P U B L I C



Related Information

Monitoring and Maintaining Reclustering Jobs [page 85]

6.2.3.3.2 Reclustering DataStore Objects

Use the Data Warehousing Workbench to recluster a DataStore object. You can only recluster standard DataStore objects and DataStore objects for direct update. Write-optimized DataStore objects cannot be reclustered.

Prerequisites

You have created a backup of your database.

During the reclustering of DataStore objects, no read lock is set because this is not supported. Therefore, do not execute any reporting on the DataStore object and any delta updates in other InfoProviders while reclustering is running.

Procedure

1. In your BW system, call the Data Warehousing Workbench (transaction RSA1).2. Navigate to the DataStore object for which you want to create and schedule a reclustering job.

3. From the context menu, choose Additional Functions Reclustering .4. To define new data classes for the DataStore object, enter the data class names in the Target Data Class

field.5. To enable row compression for the DataStore object, choose Compress InfoCube Fact Tables / DataStore

Active Tables.The database automatically creates the compression dictionary. Therefore, you cannot change the number of inserted lines before compression.

6. To specify the size of data packages to be copied in one transaction from the source table to the target table, enter the required value in the Commit Size (MB) field.This value restricts the size of the units of work to prevent log overflows. The default value is 300 MB.

7. To continue, choose Initialize.8. Confirm that you have created a backup of your database.9. In the Selection of Clustering dialog box, choose multidimensional clustering.


The Multidimensional Clustering dialog box appears:

Multidimensional Clustering10. Enter all required values in the Multidimensional Clustering dialog box as follows:

○ To select MDC dimensions from the InfoObjects that belong to the key of the DataStore object, enter a status number in the Stat.No. field.The status numbers define the order of the MDC dimensions. The status numbers that you enter must be consecutive.

○ To estimate the disk space consumption for MDC based on your entries, select the Execute Space Check checkbox.The estimation is based on the data that is currently stored in the DataStore object. The estimated percentage of free space for the active table appears in a message window. If the percentage of free space is higher than 33%, consider selecting different MDC dimensions.

11. Confirm your entries.12. Confirm the message window.13. In the Start Time dialog box, schedule the reclustering job as a background job.

You can monitor the job using transaction SM37 or the BW request monitor.

Related Information

Monitoring and Maintaining Reclustering Jobs [page 85]

84 P U B L I C



6.2.3.3.3 Monitoring and Maintaining Reclustering Jobs

Use the Data Warehousing Workbench to monitor a reclustering job for an InfoCube or a DataStore object.

Procedure


2. Navigate to the InfoCube or DataStore object for which you want to monitor the reclustering job and right-click.

3. From the context menu, choose Reclustering.4. On the Reclustering of InfoProviders screen, choose Monitor.

The icons for the steps in the reclustering jobs mean the following:

○ Green: Steps that have already been completed○ Yellow: Steps that are currently being executed○ White: Steps that have not yet been started○ Red: Steps that have failed

In the case of failed steps, the reclustering request has aborted and is also shown with a red icon.5. You can proceed with the following:

○ To display the details of a reclustering step, double-click it. Step details, along with their start and end times, appear in the right frame.

○ To delete a reclustering job from the monitor, choose Delete Request from the context menu of the selected InfoCube or DataStore object. The request is removed from the monitor.

CautionDo not delete aborted requests until you are sure that the InfoCube or DataStore object is consistent. If you delete a reclustering request, all tables remain in the current state. The system does not restore the InfoCube or DataStore object to the state before reclustering.

○ To reset an aborted reclustering request, choose Reset Request from the context menu of the selected InfoCube or the DataStore object. Locks on the InfoCube or DataStore objects are removed and the target tables are deleted.

○ To restart an aborted reclustering job, choose Restart Request from the context menu of the selected InfoCube or DataStore object after you have removed the cause of the failure. The reclustering job continues with the failed step.

○ To restart a failed step, choose Restart Step from the context menu of the selected InfoCube or DataStore Object after you have removed the cause of the failure. The reclustering job continues with the failed step. If the step successfully completes, the job proceeds with the remaining steps.


6.2.3.4 Improving MDC Settings Using the MDC Advisor

The MDC advisor is a tool that proposes multidimensional clustering (MDC) settings for tables by analyzing queries that are executed on these tables. Use the MDC Advisor if you have existing DataStore objects or InfoCubes and you have the impression that the MDC dimensions are not optimal for your needs.

Features

The MDC advisor has been integrated into the DBA Cockpit as of SAP enhancement package 1 for SAP Business Warehouse 7.0.

Use the MDC advisor to collect SAP BW reporting queries for InfoCubes and DataStore objects. The MDC advisor analyzes the collected SAP BW reporting queries and returns an MDC proposal for the fact tables of an InfoCube and for the active table of a DataStore object. Based on this MDC proposal, you can recluster the analyzed InfoCubes and DataStore objects using the Data Warehousing Workbench (transaction RSA1).

Constraints

If an InfoCube has one or both of the time characteristics SID_0FISCPER and SID_0CALMONTH, these time characteristics only exist as columns in the time dimension table but not in the fact tables of the InfoCube. With SAP enhancement package 1 for SAP Business Warehouse 7.0, the MDC advisor cannot take these columns into account.

As of SAP enhancement package 2 for SAP Business Warehouse 7.0, this has changed. The MDC advisor has been enhanced to simulate the existence of these columns in the fact tables and can thus also propose these columns as MDC dimensions.

6.2.3.4.1 Creating a New Tablespace for Temporary BW Tables

The MDC advisor needs temporary BW tables to analyze BW reporting queries. These tables are stored under new names. We recommend that you create a new tablespace for the temporary BW tables to ensure that there is enough free space to store them.

Context

You can use the DBA Cockpit to create new tablespaces.

86 P U B L I C



Procedure

To create a new tablespace, follow the instructions in the documentation Database Administration Using the DBA Cockpit: IBM Db2 for Linux, UNIX, and Windows at https://help.sap.com/viewer/db6_dbacockpit.

6.2.3.4.2 Setting Thresholds for the Collection Process

To limit disk space consumption during the collection process of the MDC advisor, set thresholds for queries and BW temporary tables.

Context

When you use the MDC advisor, disk space consumption can increase significantly. To avoid this, the following thresholds have been introduced:

● Query ThresholdRestricts the number of queries that can be collected during a single collection process

● Temporary BW Table ThresholdRestricts the number of temporary BW tables that can be stored during a single collection process

The thresholds apply to all InfoProviders with the status RUNNING.

If one or both of the thresholds are reached, the SAP BW query collection process stops. You can adapt the thresholds in the MDC advisor.

Procedure

1. To access the MDC advisor, call the DBA Cockpit (transaction DBACOCKPIT) in your SAP BW system.

2. In the navigation frame, choose BW Administration MDC Advisor .3. Choose Change Thresholds on the BW Administration: MDC Advisor screen.



The dialog box Change Thresholds for Collecting Process appears:

Change Thresholds for Collecting Process4. Adapt the thresholds as needed.

By default, both thresholds are set to 1,000. The maximum value that you can choose for the thresholds is 10,000.

Caution○ If you change the Temporary BW Table Threshold, take into account the size of the tablespace where

the temporary BW tables are stored.○ If you change the Query Threshold, take into account the size of the tablespace SYSTOOLS where the

BW reporting queries are stored.

6.2.3.4.3 Adding an InfoProvider to the MDC Advisor Analysis

Start working with the MDC Advisor by selecting InfoProviders (DataStore objects or InfoCubes) to be analyzed by the MDC Advisor.

Prerequisites

● You have created a new tablespace for new temporary BW tables (see Creating a New Tablespace for Temporary BW Tables [page 86].

● You have set the thresholds for the collection process (see Setting the Thresholds for the Collection Process [page 87]).

Procedure

1. Call the DBA Cockpit (transaction DBACOCKPIT).

88 P U B L I C



2. In the navigation frame, choose BW Administration MDC Advisor .3. On the Input tab page, choose Add InfoProvider.4. Specify the InfoProvider that you want to analyze.5. Specify the user who is authorized to collect BW reporting queries.

To collect BW reporting queries for all users, enter an asterisk (*).6. Specify the tablespace where you want to store the temporary BW tables.

If your database is managed by automatic storage, the SAPTOOLS tablespace is shown by default.7. To confirm your input, choose Add.

Result

The InfoProvider, the name of the specified tablespace, and the name of the specified user is shown on the Input tab page.

6.2.3.4.4 Starting and Stopping the Collection Process of BW Reporting Queries

Before the MDC advisor can begin analyzing results, you must start and stop the collection process of BW reporting queries.

Context

You can start the collection process for the following:

● InfoProviders (DataStore objects or InfoCubes) that have been newly added to the MDC Advisor for analysis

● InfoProviders for which you have already collected queries (status COLLECTED)● InfoProviders that have already been analyzed using the MDC Advisor (status ANALYZED)

You can only collect BW reporting queries that are directly executed on the database. For queries that are repeatedly executed, you must disable the query caching using transaction RSRT or RSRCACHE.

RecommendationWe recommend that you start the collection process and let it run until the most important BW reporting queries are executed. You can either start the most important BW reporting queries manually during the collection process, or you let the collection process run for a specified time (for example, one working day) so that all BW reporting queries that are typically used have run. Remember that you must stop the collection process manually.


Procedure

Starting the Collection Process1. Call the DBA Cockpit (transaction DBACOCKPIT).

2. In the navigation frame, choose BW Administration MDC Advisor .3. On the Input tab page, select one or more InfoProviders and choose Start Collection.

The statuses of the InfoProviders switch to RUNNING, and the start time of the collection process is shown in the Start column. BW reporting queries that are executed by the specified user are now collected.

Stopping the Collection Process1. Call the DBA Cockpit (transaction DBACOCKPIT).

2. In the navigation frame, choose BW Administration MDC Advisor .3. On the Input tab page, select one or more InfoProviders with the status RUNNING and choose Stop

Collection.4. Confirm the message.

The statuses of the selected InfoProviders switch to COLLECTED, and the stop time of the collection process is shown in the Stop column. The number of collected queries is shown in the Number of Queries column.

6.2.3.4.5 Running an Analysis of the Collected SAP BW Reporting Queries

After you have executed the collection of SAP BW reporting queries, you can start the analysis process of the MDC Advisor.

Procedure


2. In the navigation frame, choose BW Administration MDC Advisor .3. On the Input tab page, select one or more InfoProviders with the status COLLECTED.

You can analyze only InfoProviders with the status COLLECTED.4. To evaluate the collected queries with the MDC Advisor, choose Analyze.5. Specify the time when the BW reporting queries should be analyzed using a background job.

Result

As of SAP enhancement package 2 for SAP Business Warehouse 7.0 or higher, the InfoProvider shows the status ANALYZING during the analysis process of the MDC Advisor. Furthermore, on the Result tab page, the message The analyzing process is running is shown for the InfoProviders that are currently being analyzed.

90 P U B L I C



You can monitor the background job using the DBA Planning Calendar, which is also part of the DBA Cockpit. The results are shown on the Result tab page when the job has finished.

The collected BW reporting queries and the stored temporary BW tables are deleted at the end of the analysis process to free the used disk space.

The analysis results are available for further evaluation (see Evaluating the Results of the MDC Advisor [page 91]).

6.2.3.4.6 Evaluating the Results of the MDC Advisor

You can view the results of the MDC Advisor on the Result tab page, for example, the proposed MDC dimensions, the used space, and the estimated performance improvement.

Procedure


2. In the navigation frame, choose BW Administration MDC Advisor .3. Choose the Result tab page.

For each analyzed InfoProvider, a directory node is shown with the following entries:

Column Description

InfoProvider Name of the analyzed InfoProvider

MDC Dimensions Results of the MDC Advisor analyzing process

Status Status number of the proposed MDC dimension

This field appears if the MDC Advisor returns an MDC setting for the InfoProvider.

Estimated Improvement Estimated performance improvement that you can achieve with MDC


Estimated Space Increase Estimated increase of used disk space through MDC


NoteThe tables might use more disk space if you change the clustering settings of an InfoProvider to MDC.


The following types of result nodes can exist:

● MDC ProposalThe MDC Advisor returns an MDC proposal for the InfoProvider.To see the proposed MDC dimensions with their status number, expand the InfoProvider node. Additionally, the estimated performance improvement that you can achieve by using MDC and the estimated space increase through MDC are shown.

NoteYou can change the clustering of the InfoProvider according to the results of the MDC Advisor by executing the Reclustering function in the Data Warehousing Workbench (transaction RSA1).

For more information, see Reclustering SAP BW Objects [page 79].

● No MDC Settings ProposedThe MDC Advisor cannot propose MDC settings for the collected BW reporting queries.

● No Queries CollectedThe MDC Advisor did not collect any BW reporting queries for the InfoProvider.

● Additional ProposalsThe SAP BW system allows MDC settings with time characteristics SID_0FISCPER and SID_0CALMONTH.○ If you are using SAP enhancement package 1 for SAP BW 7.0 and there is an additional node for the

time characteristics SID_0FISCPER or SID_0CALMONTH, try MDC settings with these time characteristics.

○ If you are using SAP enhancement package 2 for SAP BW 7.0 or 7.3 and higher, the MDC Advisor can also take into account the time characteristics SID_0FISCPER and SID_0CALMONTH. If one of these time characteristics is an appropriate proposal for an MDC dimension, it is shown as a normal node on the Result tab page.

○ If you choose SID_0CALMONTH or SID_0FISCPER as an MDC dimension, an additional field is added to the E and F fact tables that contain the SID values for this characteristic, and an MDC block index is created on this field.

RecommendationThere are no restrictions on the package dimension in BW reporting queries. Therefore, the MDC Advisor makes no recommendations regarding the package dimension.

If you are using InfoCube compression to collapse your requests from the F fact table to the E fact table, we recommend that you choose the package dimension as an MDC dimension. The package dimension ensures better performance of INSERT and DELETE operations on the F fact table. However, InfoCube compression is not always needed (see Recommendations for InfoCube Compression [page 137]). If you do not use InfoCube compression, dispense with the package dimension as MDC dimension. Additional, unneeded MDC dimensions unnecessarily waste disk space (see the Limiting Disk Space Consumption section in Choosing the Right MDC Dimensions [page 72]).

6.2.3.4.7 Implementing the Results of the MDC Advisor

As of SAP BW 7.02 Support Package 11, SAP BW 7.3 SP06, and SAP BW 7.4 and higher, you can directly start an MDC reclustering process from the MDC advisor result screen in the DBA Cockpit. For lower releases and

92 P U B L I C



support packages, you need to start MDC reclustering using the Data Warehousing Workbench (transaction RSA1).

Context

The evaluation process of the MDC advisor ends with one of the following result nodes:

● MDC ProposalThe MDC advisor returned an MDC proposal for the InfoProvider. You can now implement this MDC proposal for the InfoProvider.

● No MDC Settings ProposedThe MDC advisor cannot propose an MDC setting for the collected BW reporting queries.

NoteWith SAP enhancement package 1 for SAP BW 7.0, the MDC advisor can't offer advice about the time characteristics SID_0FISCPER and SID_0CALMONTH. If restrictions on these time characteristics exist in the BW reporting query, the result node Additional Proposals is created. If you use the proposed time characteristic as an MDC dimension, perform a space check in transaction RSRV on the Analysis and Repair of BW Objects screen as described in Checking the Disk Space Consumption of MDC InfoCubes and DataStore Objects [page 94].

Procedure

Implementing the Results of the MDC advisor (SAP BW 7.02 and SAP BW 7.3 and Higher)

1. Double-click the result node MDC Proposal or No MDC Settings proposed.The MDC Reclustering of InfoProviders screen appears. The InfoCube or DataStore Object field is populated with the name of the InfoProvider that was evaluated.

2. You can enter values in the other fields as described in Reclustering SAP BW Objects [page 79].3. To start the MDC reclustering process, choose Initialize.4. For InfoCubes, proceed as described in Reclustering InfoCubes [page 80], and for DataStore objects, as

described in Reclustering DataStore Objects [page 83].If the MDC advisor returned an MDC proposal, the proposal is already set in the Multi-Dimensional Clustering dialog box.

5. To monitor the reclustering background job on the Monitor Requests screen, choose the Monitor pushbutton on the MDC Reclustering of InfoProviders screen. Alternatively, you can use the DBA Planning Calendar in the DBA Cockpit.

Implementing the Results of the MDC advisor (SAP BW 7.0 and 7.01)

Start the MDC reclustering as described in Reclustering SAP BW Objects [page 79].


6.2.3.4.8 Deleting the Results of the MDC Advisor Analysis

You can delete all results and temporary data created by an analysis in the MDC Advisor when you don't need them anymore.

Procedure


2. In the navigation frame, choose BW Administration MDC Advisor .3. On the Input tab page, select one or more InfoProviders and choose Delete.

For InfoProviders that you selected, the following items are deleted:

○ The InfoProvider entry on the Input tab page○ The BW reporting queries that have been collected○ The temporary BW tables○ The results of the MDC Advisor○ The results on the Result tab page

NoteYou can always delete the entries for an InfoProvider, regardless of the InfoProvider status.

6.2.3.5 Checking the Disk Space Consumption of MDC InfoCubes and DataStore Objects

Check the disk space consumption if you are using multidimensional clustering (MDC).

Context

One possible reason for high disk space consumption might be unsuitably defined multidimensional clustering (MDC) for InfoCubes and DataStore objects.

To check the disk space consumption of InfoCubes and DataStore objects that are using MDC, use the check function in transaction RSRV. In SAP BW systems with release 7.3 and higher, you can also check the disk space consumption of all MDC InfoProviders using the BW health checks in the DBA Cockpit [page 133].

If more than 33% of the space allocated is free space, consider reclustering the InfoProvider.

CautionBefore executing the check, make sure that the database statistics are current.

94 P U B L I C



Procedure

1. In your BW system, call Analysis and Repair of BW Objects (transaction RSRV).

Analysis and Repair of BW Objects

2. Choose Tests in Transaction RSRV All Elementary Tests Database .3. Drag and drop the test Check space consumption of MDC InfoProviders in DB2/UDB into the frame on the

right side.4. Double-click it, then specify the name of the InfoProvider.5. To start the test, choose Execute.

The percentage of free disk space for an InfoCube is calculated using the database statistics of the fact tables and the aggregate fact tables of the InfoCube.The percentage of free disk space for a DataStore object is calculated using the database statistics of the active table of the DataStore object.


6.2.4 Considerations for Creation, Copy, Transport, and Aggregates with MDC

Copying BW Objects

When you copy an existing BW object, the target BW object inherits the clustering and table organization settings from the source BW object. However, before you activate the target BW object, you can change its settings. To do so, choose Extras DB Performance Clustering from the menu of the Edit <BW Object> screen.

Transporting BW Objects

When you transport a BW object from your development system to the production system, the following happens:

● If the BW object already exists in the production system and contains data, the current clustering settings and table organization are retained.

● If the BW object does not yet exist in the production system or does not contain any data, the clustering and table organization settings from the development system are used. If the tables already exist, they are dropped and re-created.

Considerations for InfoCubes Only

Creating Semantically Partitioned InfoCubes

When you create a semantically partitioned InfoCube, the clustering settings that you select for the semantically partitioned InfoCube are propagated to the partitions of the InfoCube. Therefore, when you select MDC tables for the InfoCube, the tables of all partitions of the semantically partitioned InfoCube are also automatically created with MDC.

Reusing Predefined InfoCubes from BI Content

You might want to reuse InfoCubes that are predefined by SAP as they are available with BI Content for SAP BW. When you install the SAP BI Content, InfoCubes are created with the default clustering settings for Db2. To use the InfoCubes from BI Content with different clustering settings, change the clustering settings in the Data Warehousing Workbench after you have installed the InfoCubes. Then reactivate the InfoCubes.

Aggregates for InfoCubes

Aggregates of MDC InfoCubes are also created with MDC.

96 P U B L I C



7 Db2 Database Partitioning Feature (DPF)

The Db2 Database Partitioning Feature allows you to distribute large databases over multiple database partitions that are physically placed on one or more servers. With DPF, you can scale out the Db2 database of SAP BW to multiple servers.

Architecture and Use

DPF is set up as follows:

Database Partitioning Feature: Setup Overview

DPF is a shared-nothing scale-out solution. The data is distributed evenly to the Db2 partitions using a distribution key. One Db2 member is assigned to each Db2 partition and this member takes over processing of

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksDb2 Database Partitioning Feature (DPF) P U B L I C 97

the data of this partition. The Db2 catalog is located in one special partition, the administration partition. In a DPF setup for SAP BW, the administration partition has the following functions:

● Catalog function● Coordination function, that is, all application servers connect to this partition● Storage of non-partitioned data (SAP BASIS, master data, dimension tables)

Query processing with DPF runs as follows:

Database Partitioning Feature: Query Processing

The Db2 member to which your application server is connected acts as a "coordinator member" and receives the SQL statements from the application (steps 1 and 2 in the graphic). The SQL statements are processed by the coordinator member. Any sub-operations are forwarded to all other members that have data that is affected by the statement (step 3). All members carry out their work locally on their data set and return the result to the coordinating member (step 4). This means that an individual statement can scale with the number of DPF members, provided each member has a sufficiently large amount of work. The coordinator member consolidates the result set and returns it to the application server (step 5).

The DPF shared-nothing architecture is well-suited for tasks in which large data sets must be read or changed. In SAP BW, only the following tables can be distributed:

● E and F fact tables of InfoCubes

98 P U B L I C


Db2 Database Partitioning Feature (DPF)

● DataStore objects● PSA tables

These tables reside in separate tablespaces and separate database partition groups that can be distributed. All remaining tables and tablespaces must be placed in the catalog partition. All SAP application servers must connect to the catalog partition. Connections to other Db2 DPF members are not supported.

Physical vs. Logical Database Partitioning

If you install database partitions on different hosts, this is referred to as physical partitioning. The separate partitions together make up one database, allowing you to assign the computing power of more than one host to the database of your SAP BW system.

As opposed to physical partitioning, “logical partitioning” refers to a scenario where you have several database partition servers running on the same host. This means that the configuration can contain more database partitions than hosts.

NoteWe recommend that you do not use logical partitioning except on very large symmetric multiprocessing (SMP) machines.

7.1 Number of Partitions and Hardware Requirements

Here you will find some guidelines on how many partitions you should set up in a multipartition database layout, and the required hardware. This information will also give you an idea whether your hardware is large enough so that database partitioning is beneficial.

Number of Partitions

Before you decide on the number of partitions and the hardware, you need to know about the different database partition types:

● Administration partitionThe administration partition is the database partition that contains the database catalog, SAP BASIS tables, SAP BW master data, and SAP BW dimension tables. All SAP work processes must be connected to the administration partition.You can optionally store small InfoCube fact tables, DataStore object tables, or PSA tables on the administration partition.

● Data partitionA data partition is a database partition that contains the InfoCube or aggregate fact tables, DataStore object tables, or PSA tables. Ideally, each data partition has the same data volume and the same data access workload.


Hardware Requirements for Database Partitions

Each database partition has a specific minimum hardware requirement. In addition, each data partition needs to hold enough records of every distributed BW object.

In addition, the hardware requirements depend on whether you use row-organized or column-organized tables (BLU Acceleration). As of Db2 11.1, BLU Acceleration can be used with partitioned databases (DPF) for SAP BW. The hardware requirements for Db2 DPF with BLU Acceleration differ from the hardware requirements for DFP with row-organized tables because of the inherent parallelism of Db2 BLU Acceleration.

The hardware and data volume requirements listed below are minimum requirements per data partition. This does not mean that you should implement partitioning when your data volume or assigned hardware exceeds the values listed. Instead, take performance measurements into account when you decide on the implementation of partitioning. If you implement DPF partitioning, you need at least two data partitions and one administration partition. The hardware requirements below are for each partition, which means you need to have at least two times the data volume listed below before you should consider partitioning.

RecommendationTo determine the optimal number of database partitions, we recommend that you run a performance test using a customerspecific workload.

For optimal performance, make sure that there are no I/O throughput and communication bottlenecks between database partitions. We recommend that you use a fast network switch for physical database partitions, for example, a Gigabit Ethernet switch.

Hardware Requirements for each Database Partition

System Setup Cores Main Memory Data Volume (Data Partitions Only)

With BLU Acceleration

Intrapartition parallelism for each partition

Use at least 16 cores for each data partition.

For each data partition, you must assign all cores of a socket to the database partition. For example, you have a 4-socket machine with 8 cores per socket. In this case, you can assign 16 cores from 2 sockets, 24 cores from 3 sockets, or 32 cores from 4 sockets to the database partition.

For the administration partition, use 20% - 25% of the cores available for the complete database.

Use at least 256 GB for each data partition. Maintain 16 GB memory for each core ratio.

For the administration partition, use 20% of the memory available for the complete database.

At least 80 million records per data partition

100 P U B L I C



System Setup Cores Main Memory Data Volume (Data Partitions Only)

Without BLU Acceleration

Intrapartition parallelism for each partition

Use at least 4 cores for each data partition.

For the administration partition, use 20% of the cores available for the complete database.

Use at least 16 GB memory for each data partition.

For the administration partition, use 20% of the memory available for the complete database.

At least 20 million records per data partition

NoteSince the hardware recommendations for databases with row-organized tables and for BLU Acceleration are different, you'll need to repartition your database if you convert from row-organized tables to BLU Acceleration.

For DPF with BLU Acceleration, you need the correction instructions of SAP Note 2360030 or the SAP BW support packages mentioned in this SAP Note.

The number of CPUs and the size of the main memory per database partition could be higher for very large SAP BW systems that have a high concurrent workload, for example, several hundred database connections and more than 100 SAP BW queries running in parallel.

7.2 Arguments to Consider for and Against DPF

When is DPF more useful than the recommended single partition with intrapartition parallelism? Here are some recommendations to guide you.

Advantages of DPF

DPF can have the following advantages as compared to a single partition with intrapartition parallelism:

● With intrapartition parallelism, queries are parallelized. Whether change operations are also parallelized depends on if you use BLU Acceleration. With BLU Acceleration, INSERT operations are parallelized as of Db2 11.1 MP2 FP2, whereas UPDATE and DELETE operations are currently not parallelized. With row-organized tables, change operations are not parallelized. With DPF, change operations are executed in parallel on the affected partitions, which can improve database-intensive ETL operations (InfoCube compression, aggregate rollup).

● The performance of the database administration tasks, for example, backups, restores, table reorganizations, index creations, and RUNSTATS executions, improves due to database partitioning parallelism.



Disadvantages of DPF

DPF has the following disadvantages as compared to a single partition with intrapartition parallelism:

● Use DPF only if there is enough data stored on every partition and if enough hardware resources are assigned to each partition. If this is not the case, DPF will actually have a negative performance impact due to the additional complexity and communication cost.

● DPF requires an increased administration effort, for example, for backup, recovery, and configuration.● The use of the self-tuning memory manager (STMM) has some restrictions (see SAP Note 1132282 ).● Db2 HADR cannot be used with DPF.● DPF is not a high-availability solution. If a DPF member fails, the data of this partition remains unavailable

until the member is online again. If you have high-availability requirements, you must also set up a high-availability solution.

DPF and BLU Acceleration

As of Db2 11.1, you can use BLU Acceleration with partitioned databases (DPF) for SAP BW. However, you should consider DPF with BLU Acceleration only in the following cases:

● You want to scale out across multiple machines.● You are using a very large symmetric multiprocessing (SMP) machine with so many cores and such a large

main memory that it cannot be used efficiently with a single partition.

The hardware requirements for Db2 DPF with BLU differ from those for DPF with row-organized tables because of the inherent parallelism of Db2 BLU.

When you migrate from Db2 with DPF and row-organized tables to BLU Acceleration, you will not be able to keep your current DPF partitioning layout because BLU Acceleration requires a different hardware layout. This is particularly true if you used logical DPF partitioning with Db2 row-organized tables. Therefore, during the migration to BLU acceleration, you'll want to migrate to a single partition system in most cases. To continue using DPF after the migration to BLU Acceleration, you will need to reduce the number of database partitions significantly to comply with the hardware requirements of BLU Acceleration.

For more information about the required hardware for BLU Acceleration, see SAP Notes 1819734 and 2047006 .

7.3 Implementing Multiple Partitions Using the Database Partitioning Feature

During the standard SAP installation, an SAP BW system is created with one database partition. Learn how you can implement a multipartition database using the Db2 Database Partitioning Feature (DPF).

102 P U B L I C






7.3.1 Planning the Multipartition Database Layout

1. Figure out the hardware you'll need.The hardware sizing must reflect the size of the final hardware that is needed for the installation as closely as possible. Determine the number of machines and the amount of processors, memory, and disks that you need for the chosen hardware platform. For more information and guidance, see Number of Partitions and Hardware Requirements [page 99].

2. Plan the database layout.For more information, see the following sections:○ Number of Partitions and Hardware Requirements [page 99]○ Recommendations for Data Distribution [page 103]○ Considerations for Distributing SAP BW Objects [page 104]○ Dealing with System Growth [page 131]

3. Create database partition groups, tablespaces, and data classes. Assign your InfoCubes, DataStore objects, and PSA tables to the new data classes.For more information, see Additional Tablespaces and Data Classes [page 41] and Adding New Data Partitions to the Database [page 107].

7.3.1.1 Recommendations for Data Distribution

When you plan the data distribution in an SAP BW system, consider the location of SAP BASIS tables, parallel processing, and database configuration and buffer pool size.

Location of SAP BASIS Tables

SAP BASIS tables, SAP BW master data tables, and InfoCube dimension tables must be located on partition 0. If you expect that the number of distinct values in one dimension is close to the fact table cardinality, you should use a line item dimension for this dimension in the layout of the InfoCube.

Parallel Processing

For PSA tables, InfoCube and aggregate fact tables, and DataStore object tables, the basic idea is that larger tables should be distributed on more database partitions than smaller tables to increase the degree of parallel processing.

To keep the table distribution simple and easy to manage, tables are classified in size categories, which are mapped to a specified number of database partitions as described in the following list:

● Don't distribute mall tables. Small tables are stored on database partition 0. For small data volumes, a high degree of parallel processing does not improve but degrades performance.

● Distribute larger tables across several database partitions, depending on the table size and the number of data partitions available.


● When you distribute tables, make sure that at least a minimum data volume is stored on every data partition. For more information about the required minimum data volumes, see Number of Partitions and Hardware Requirements [page 99].

● In addition, there are certain restrictions for table distribution in an SAP BW system. For more information, see Considerations for Distributing SAP BW Objects [page 104].

Database Configuration and Buffer Pool Size

Make sure that the database configuration and the buffer pool size are the same on all data partitions. Since the workload on the administration partition is different from the workload on the data partitions, you might have to use a different configuration on the administration partition. For example, you might have to increase the sort heap configuration on the administration partition.

Related Information

Number of Partitions and Hardware Requirements [page 99]Examples of DPF Database Layouts [page 106]

7.3.1.2 Considerations for Distributing SAP BW Objects

Before you distribute SAP BW objects across multiple partitions, there are several recommendations to consider.

If you plan to create several small or medium-sized InfoCubes, DataStore objects, or PSA tables, you can assign them all to one data class or tablespace. For larger InfoCubes, DataStore objects, or PSA tables, you may want to use separate database partition groups, separate data tablespaces, separate index tablespaces, and separate data classes for each new object.

Separating large SAP BW tables of InfoCubes, DataStore, or PSA objects on different tablespaces allows you to locate InfoCubes, DataStore objects, or PSA tables on different partitions.

If the tables differ largely in size, then the largest table should determine the number of partitions over which the data should be distributed.

InfoCubes and Their Aggregates

For InfoCubes and their aggregates, consider the following:

● Both fact tables of an InfoCube are stored in the same data class and therefore in the same data and index tablespaces. You can distribute large InfoCube fact tables over several partitions.

● The dimension tables of an InfoCube are stored by default in the data class DDIM. Dimension tables must reside on partition 0 and cannot be distributed.

104 P U B L I C



● You can assign a different data class to the aggregates of an InfoCube. The fact tables of all aggregates must reside in the same data class and in the same data and index tablespace. You can distribute large aggregate fact tables over several partitions.

● All aggregates of an InfoCube must reside in the same data class and in the same tablespace. This tablespace can be different from the tablespace of the InfoCube. If you have small and large aggregates for one InfoCube, you must distribute either all of them or none of them.

For more information about assigning the tables of an InfoCube and its aggregates to data classes, see Assigning InfoCubes and their Aggregates to Data Classes [page 48].

DataStore Objects

For DataStore objects, consider the following:

● You must store both the active table and the change log table of a DataStore object in one data class and therefore in the same data and index tablespace. You can store the activation queue table of a DataStore object in a separate data class and tablespace.

● You can also store all three types of tables of a DataStore object (active table, activation queue table, and change log table) in the same tablespace.

● You can distribute large active and change log tables over several partitions.● The activation queue tables are much smaller than the active and the change log tables. You can therefore

store the activation queue tables of all DataStore objects on a single database partition.

For more information about assigning the tables of a DataStore object to data classes, see Assigning DataStore Objects to DataClasses [page 49].

Persistant Staging Areas (PSAs)

PSA tables belong to a DataSource. You can distribute large PSA tables over several partitions.

For more information about assigning a PSA table to a data class, see Assigning PSA Tables to Data Classes [page 50].


7.3.1.3 Examples of DPF Database Layouts

You can either distribute large BW tables across all database partitions or distribute groups of tables across partition subsets.

Large BW Tables Are Distributed Across All Partitions

The following is an example of a database layout for an SAP BW system with multiple database partitions:

Data Distribution Using Five Partitions

All InfoCube fact tables, DataStore object tables, and PSA tables are large enough to be distributed across partition 1 to 4. BLU Acceleration is not used and all aggregate fact tables are too small to be distributed. Therefore, all aggregate fact tables are located on the administration partition.

The database configuration and the buffer pool size are the same on all data partitions. Depending on the workload, the database configuration values and buffer pool size on the administration partition might need to be larger.

106 P U B L I C



Groups of Tables Are Distributed Across Partition Subsets

The following example describes the database layout for a large BW system with eight database partitions. The BW tables are put into two different groups and stored on data partitions as follows:

● Small BW aggregate and InfoCube fact tablesThese tables are too small to be distributed. Therefore, the tables are stored on database partition 0.

● To use parallel processing in the database, large InfoCube and aggregate fact tables, and large DataStore object and PSA tables are distributed across the eight data partitions.

● Medium-sized PSA tables, DataStore object tables, and InfoCube and aggregate fact tables are split into two groups. Each group is distributed on four of the data partitions.

Data Distribution Across Partition Subsets

The database configuration and the buffer pool size are the same on all data partitions. Depending on the workload, the database configuration values and buffer pool size on the administration partition are typically larger.

7.3.2 Adding New Data Partitions to the Database

Learn how to add new data partitions to the database and how to redistribute the data (if required).

7.3.2.1 Preparing New Database Partitions

To prepare new database partitions, perform the following steps:

1. Create additional database partitions [page 108].2. Update the database configuration for each new partition [page 109].3. Add containers to the temporary tablespace on each new partition [page 110].


7.3.2.1.1 Creating New Database Partitions

To create additional database partitions, follow the installation guide for SAP NetWeaver.

Context

You may need to create additional database partitions in the following scenarios:

● You have just installed your SAP BW system, which, by default, gets a single-partition database. You now want to create additional database partitions because you want to operate your SAP BW on a multi-partition database.

● You want to add new database partition servers to an existing multipartition installation.

Procedure

Use the SAP installer as described in Adding Database Partitions to a Database Instance in the installation guide for SAP NetWeaver, at http://support.sap.com/sltoolset System Provisioning Installation Option of Software Provisioning Manager Installation Guides - Application Server Systems .

The SAP installer offers that you can create the following tablespace types:

● Data and index tablespaces managed by Db2’s automatic storage managementThis is the default for the installation of an SAP BW system. If you choose this option, the SAP installer assigns the sapdata directories to the database, which automatically distributes all tablespaces over the sapdata directories. In addition, the database automatically adjusts the tablespace size as long as there is enough free space left in the sapdata directories.

● DMS file tablespaces in automatic resize modeFor backward compatibility, the installer still allows you to create DMS tablespaces. However, DMS tablespaces are deprecated as of Db2 10.1 and should not be used.

RecommendationWe recommend that you assign large DataStore object tables, large fact tables, and large PSA tables to their own tablespaces. You can distribute them over several database partitions.

108 P U B L I C




7.3.2.1.2 Updating the Database Configuration for Each New Database Partition

After you have created additional partitions, check and update the database configuration.

Context

In an installation using DPF, each partition has its own database configuration.

To check the recommended values of these database configuration parameters for your database version, see the respective SAP Notes:

Database Version SAP Note Number

Db2 11.1 2303771

Db2 10.5 1851832

The DBA Cockpit uses the information in these SAP Notes in its parameter check automatically, so there's no need for you to check the parameters manually.

Procedure

1. Check the database configuration of a partition using the DBA Cockpit.2. Update the database configuration parameters for new database partitions using the DBA Cockpit.

For more information about performing these steps, see the documentation Database Administration Using the DBA Cockpit, section Configuration: Database (and following). You can find this documentation at https://help.sap.com/viewer/db6_dbacockpit.

NoteBy default, new database partitions are created with log paths that are not specific to the SAP system ID. Therefore, always make sure that you set the parameter NEWLOGPATH to <log_path>. After changing the NEWLOGPATH parameter, stop and restart the SAP system.





7.3.2.1.3 Adding Containers to the Temporary Tablespace on Each New Database Partition

After you have created new database partitions, adapt the temporary tablespaces accordingly.

Context

If you still do not use Db2's automatic storage management, you must add containers to the temporary tablespace on these partitions.

RecommendationWe recommend that you enable automatic storage management instead.

Procedure

1. In your SAP system, call the DBA Cockpit (transaction DBACOCKPIT).

2. In the navigation frame, choose Space Containers .3. Select the PSAPTEMP16 tablespace and choose Add.4. Select an empty row and enter the new container path, the new database partition ID, and the new

container size.

NoteCreate new containers in the partitionspecific directories <temp16_container_path>.

<temp16_container_path> is the SAP standard path for tablespace containers of the temporary system tablespace with a page size of 16 KB.

○ UNIX and Linux: “/db2/<SAPSID>/sapdata<i>/NODE<nnnn>/temp16”○ Windows: “<drive_letter>:\db2\<SAPSID>\sapdata<i>\NODE<nnnn>\temp16”

where <nnnn> is a four-digit partition number, for example, 0001 for partition 1.

5. Save your changes by choosing Execute.

7.3.2.2 Redistributing Data

After adding new partitions to your SAP system, you can choose between different tools to redistribute data over the new database partitions: the program DB6CONV, R3load and the BW data distribution wizard. Consider carefully the advantages and disadvantages of each tool.

110 P U B L I C



RecommendationTo make sure that all tables are evenly and correctly distributed over all existing database partitions, we also recommend that you check the distribution keys of all tables.

Related Information

Checking the Distribution Keys of All Tables (Optional) [page 112]

7.3.2.2.1 Redistributing Data: Tool Options

For redistributing data, you can choose between program DB6CONV, R3load, and the BW data distribution wizard. Consider carefully which tool is best for your purpose.

Context

You can either add new partitions to existing database partition groups, or create new database partition groups and move existing data to the new database partition group.

RecommendationRedistributing an existing database partition group is only possible for very small data volumes, and it's not recommended. Instead, we recommend that you create new database partition groups and move existing data using program DB6CONV or R3load.

Program DB6CONV

Program DB6CONV is the recommended option for redistributing data within an existing system. You can use program DB6CONVto create, schedule, and monitor conversion jobs that move tables from old tablespaces to new tablespaces. It also lets you to move the table online, and avoids large log space consumption. For more information, see SAP Note 1513862 .

R3load

With R3load, you can unload existing tablespaces that you want to redistribute, and load the data into new tablespaces. You can use R3load to redistribute tablespaces that have a high number of large tables.



CautionR3load requires downtime of the entire SAP system.

BW Data Distribution Wizard

The BW data distribution wizard is integrated into the DBA Cockpit. You can add new partitions to an existing database partition group and redistribute the database partition group. You can use this wizard to redistribute tablespaces that have a large number of small tables.

CautionThis tool is available for compatibility with older SAP BW releases. Use it only for tables with little or no data. We recommend that you use program DB6CONV for all other cases.

With the BW data distribution wizard, you add new partitions to the existing database partition groups, and all tables are automatically redistributed in the background using the DB2 REDISTRIBUTE command.

With the BW data distribution wizard, the table that is currently being redistributed cannot be accessed. Using the BW data distribution wizard also requires free log space of at least the amount of the largest distributed table since each table is redistributed in one unit of work. Therefore, you might need to increase the active log space.

You can redistribute data using the BW data distribution wizard without logging. If you do, we strongly recommend that you perform a backup before and after the data redistribution.

7.3.2.2.2 Checking the Distribution Keys of All Tables (Optional)

Data distribution across database partitions is controlled by a distribution key. In SAP BW systems, the correct distribution key is defined automatically during table creation. However, before you redistribute data, we recommend that you check the distribution keys of your tables. Incorrect distribution keys can lead to an uneven distribution of table data across data partitions.

You can also perform these checks if your tables are located on a single partition, for example, before you redistribute the tables to a larger number of partitions.

Checking the Distribution Keys of all Tables (SAP BW 7.0x Systems Only)

Check the distribution keys of your tables using the following function modules:

● RSDU_CHKREP_PKEY_ALL_CUBES_DB6● RSDU_CHKREP_PKEY_ALL_ODS_DB6

112 P U B L I C



● RSDU_CHKREP_PKEY_ALL_PSA_DB6

If the distribution keys are not welldefined, you can repair them using these function modules.

Checking the Distribution Keys of all Tables (SAP BW 7.3 and Higher)

To check the distribution keys of your tables, use the BW health checks in the DBA Cockpit.

If there are tables with missing or incorrect distribution keys, the InfoProviders appear in the Results of Consistency Check window. To repair missing or incorrect distribution keys of InfoProvider tables, we recommend that you execute the following function modules instead of using the Repair pushbutton that is provided for the InfoProvider:

● RSDU_CHKREP_PKEY_ALL_CUBES_DB6● RSDU_CHKREP_PKEY_ALL_ODS_DB6● RSDU_CHKREP_PKEY_ALL_PSA_DB6

Additional Information About the Function Modules

For more information about these function modules, see SAP Note 648432 .

If you use the function modules, keep the following in mind:

● If the source tablespace resides on a single partition, missing distribution keys are created and incorrect distribution keys are repaired immediately if possible.

CautionBefore you try to repair tables with wrong distribution keys, make sure that you have read SAP Note 1589962 and – if necessary – implement the correction instructions that are attached to this SAP Note.

● If the source tablespace is distributed over two or more partitions, you cannot repair distribution keys unless you create a new table and copy the data into it. Each function module then creates a conversion job in program DB6CONV for all distributed tables with wrong distribution keys that are detected. You must then to run program DB6CONV to start the conversion job for these tables.For more information about DB6CONV and the conversion jobs, see SAP Note 1513862 and the DB6CONV documentation that is attached to that SAP Note.

By default, the source and target tablespaces for the repair conversions are the same. Therefore, if you need to repair missing or incorrect distribution keys of tables and you want to redistribute these tables to a new database partition group, you must run DB6CONV twice. The first run corrects the distribution keys, and the second run redistributes and moves the tables to the new tablespaces.





More Information

Using the BW Health Checks [page 133] (for SAP BW 7.3 and higher)

7.3.2.2.3 Redistributing Data Using Program DB6CONV

You can use program DB6CONV to redistribute data across multiple partitions by performing a tablespace conversion.

Things to Consider Before Using DB6CONV

Before you redistribute data using program DB6CONV, consider the following:

● SAP BW stores additional metadata for each SAP BW object. Program DB6CONV cannot change information about the data classes that are stored in the SAP BW metadata tables. To move all tables from a tablespace to a new tablespace, update the existing data classes with the names of the new tablespaces. Thus the existing data class assignment is kept for all tables but points to the new tablespaces. No additional update of SAP BW metadata is necessary.If you want to move only some SAP BW objects from a tablespace to a new tablespace, the SAP BW metadata for these SAP BW objects will continue to point to the old assignment. Since the BW metadata cannot be changed after the BW object creation, leave the metadata as it is.

● If you want to redistribute the tables with the LOAD option, you must perform a complete backup after all tables have been redistributed.

Prerequisites

1. You have created new database partitions.2. You have created new database partition groups.3. You have created new tablespaces in the new database partition groups.4. You have imported program DB6CONV into your SAP system as described in SAP Note 1513862 .

NoteIf you are in doubt about the correctness of your distribution keys, check the distribution keys of the tables.

Procedure

To redistribute data across multiple partitions, schedule a tablespace conversion job in program DB6CONV as described in the documentation attached to SAP Note 1513862 .

114 P U B L I C





More Information

SAP Note 1513862

Related Information

Creating New Database Partitions [page 108]Creating Database Partition Groups (DPF Only) [page 45]Creating Tablespaces [page 46]Checking the Distribution Keys of All Tables (Optional) [page 112]

7.3.2.2.4 Redistributing Data Using R3load

To redistribute tablespaces that contain many large tables, you can use R3load via the migration monitor.

Context

The migration monitor helps you perform and control the unload and load process, which is performed by R3load, during data redistribution. For SAP NetWeaver-based systems and SAP BW systems as of release 7.0, the Migration Monitor is integrated into the SAP installation and system copy tool. However, to copy single tablespaces, you must start the Migration Monitor in manual mode.

If you are using R3load for data redistribution, you can also move the data from several tablespaces to a single large tablespace.

For more information about the Migration Monitor, see SAP Note 784118 .

Caution● If you redistribute data using R3load and the Migration Monitor, be aware that system downtime is

required.● Make sure that you perform a complete backup of the database before you redistribute the data with

R3load.

Prerequisites

1. You have created new database partitions.2. You have created new database partition groups.3. You have created new tablespaces in the database partition groups.




NoteIf you are in doubt about the correctness of your distribution keys, check the distribution keys of your tables.

4. To create the DDL statements for databasespecific table structures, you have run program SMIGR_CREATE_DDL on your SAP system. Place the output files of the program in the .../DB/DB6 subdirectory of the R3load export directory. R3load uses these DDL statements to create the tables correctly with Db2 features such as distribution key, multidimensional clustering (MDC) settings, and row compression before loading the data into new tablespaces.For more information about program SMIGR_CREATE_DDL, see SAP Note 888210 .

5. You must have stopped your SAP system to prevent your data from being changed.6. Your database system is running.

Procedure

1. Download the SAR-package of the Migration Monitor tool as described in SAP Note 784118 and unpack it.You can find information about how to use the Migration Monitor in the document MigrationMonitor.pdf that is attached to the Migration Monitor package.

2. Unload the required tablespaces as follows:1. Generate R3load control files using the R3ldctl command.2. Unload the selected tablespaces using the Migration Monitor, which uses the generated control files

from the previous step.3. Drop the tables that were stored in the tablespaces that you unloaded in step 2.4. Drop the tablespaces that you already unloaded in step 2.

Otherwise, you cannot load tables into the new tablespaces because the tables are created with the same table names in the new tablespaces, and duplicate table names are not allowed.

5. Create new tablespaces in the new database partition group.

NoteAlways create the data tablespaces and the corresponding index tablespaces.

6. Load the required tablespaces as follows:1. Edit the generated R3load control file DDLDB6.TPL and map the data classes to the new partitioned

tablespaces (that is, the tablespaces that you created in the new database partition group) instead of to the unloaded tablespaces.

NoteIf you are moving data from several tablespaces to a single tablespace, map all data classes to the name of the new tablespace.

2. To load all tables into the new partitioned tablespaces, call R3load from the Migration Monitor tool.7. Once the data redistribution finishes successfully, proceed as follows:


116 P U B L I C





2. In the navigation frame, choose Configuration Data Classes .3. Check the data class mapping to the new tablespaces.

The existing data class must contain the new tablespace names.

Related Information

Creating New Database Partitions [page 108]Creating Database Partition Groups (DPF Only) [page 45]Creating Tablespaces [page 46]

7.3.2.2.5 Redistributing Database Partitioning Groups Using the BW Data Distribution Wizard

The BW data distribution wizard is a legacy tool for altering existing database partition groups and tablespaces.

CautionThis tool is available for compatibility with older SAP BW releases. Use it only if you have tables with little or no data, for example, immediately after SAP system installation. In the background, the BW data distribution wizard moves data using the DB2 REDISTRIBUTE tool in one single database transaction. This causes a very high demand on the log space and is impossible for large data volumes. We recommend that you use program DB6CONV for all other cases.

Prerequisites

You have created new database partitions.

If you are in doubt about the correctness of your distribution keys, perform the checks as described in Checking the Distribution Keys of all Tables [page 112]. Otherwise, the BW data distribution wizard chooses table partitioning that is based on the first column of the primary key.

Procedure


2. In the navigation frame, choose BW Administration BW Data Distribution .3. Follow the instructions on the screen.

The basic process flow is as follows:1. Assign new partitions to database partition groups by selecting the appropriate checkboxes for these

new partitions.


You can use the BW data distribution wizard to reduce the number of partitions on which the existing tablespaces are distributed. For example, if a tablespace with small aggregate tables is located on four different database partitions, you can use the wizard to move all tables with small aggregates to partition 0. To do this, deselect all database partitions except partition 0 for the small aggregate partition group.

2. Add tablespace containers on each new partition.The wizard’s proposal for container names and the total number of pages is based on the existing tablespace containers that are located on the existing database partition with the lowest number. You can add additional tablespace containers and you can also change the proposed values.

NoteIf the tablespaces are enabled for Db2's automatic storage management, all additional tablespace containers on new partitions are automatically created, and you can skip this step.

3. Check the distribution keys of all partitioned tables.The wizard should not find any tables with wrong or missing distribution keys. If the wizard does find such tables, choose Back and check the distribution keys of all partitioned tables again before you continue. Otherwise, all tables in the list are automatically partitioned on the first column of the primary index.

4. Redistribute the database partition groups.In this step, you determine if and when the affected tablespaces are redistributed.

Related Information

Checking the Distribution Keys of All Tables (Optional) [page 112]

7.4 Optimized Data Activation for DataStore Objects Using Massive Parallel Processing (MPP)

Activation of new data in DataStore objects can be a time-consuming operation. As of SAP BW 7.3, an alternative data activation in standard DataStore objects is available that is optimized for exploiting the Db2 Database Partitioning Feature (DPF). This data activation is called massive parallel processing (MPP) activation.

NoteMassive parallel processing is relevant only if you use the Db2 Database Partitioning Feature (DPF) and row-organized DataStore objects.

Standard DataStore objects consist of three transparent, flat tables (activation queue, active data, and change log). Data is loaded into the activation queue table using the data transfer process in SAP BW. The data is not visible in the data warehouse of the SAP BW system until it has been processed by a procedure called “data activation for DataStore objects” (DSO data activation). During data activation for DataStore objects, the data

118 P U B L I C



is transferred from the activation queue to the active table of the DataStore object. The changes to the active table are also stored as change history in the change log table.

MPP significantly reduces the runtime of data activation for DataStore objects that are distributed over many database partitions. With MPP activation, large SQL statements process the data to be activated in parallel on all the database partitions where the DataStore object resides. The workload is shifted from the application server of the SAP BW system to the database, which results in faster processing. Therefore, activating data using MPP is more efficient than splitting the data activation into multiple parallel jobs on the SAP application server.

More Information

http://help.sap.com/nw73 Application Help Function-Oriented View Business Warehouse Data Warehousing Data Warehouse Management Controlling Data Warehouse Processes Further Processing Data Processing Data in the DataStore Object

7.4.1 Prerequisites and Constraints for MPP

Prerequisites

A standard DataStore object is eligible for MPP-optimized data activation if the following conditions apply:

● You use Db2 DPF.● In SAP BW, in the Data Warehousing Workbench (transaction code RSA1), the Unique Data Records

checkbox is not selected in the settings of the DataStore object. In this case, MPP-optimized data activation can be applied only to unique records in the data to be activated. Non-unique records, which occur several times due to the semantic key in the requests to be activated, are processed using standard activation.

● For SAP systems lower than SAP BW 7.3 Support Package 8 or SAP BW 7.31 Support Package 5, the following applies: In the Data Warehousing Workbench, SID generation is not set to During Activation in the settings of the DataStore object (where SID stands for surrogate identifier).

● As of SAP BW 7.3 Support Package 8 and SAP BW 7.31 Support Package 5, the generation of SIDs during data activation for DataStore objects has also been optimized for IBM Db2 for Linux, UNIX, Windows. Therefore MPP-optimized data activation for DataStore objects can also be applied when SID generation is set to During Activation in the settings of the DataStore object. MPP-optimized SID generation can be used only with MPP-optimized data activation for DataStore objects. For more information about MPP-optimized SID generation, see SAP Note 1693998 .

● The DataStore object is row-organized and distributed over at least four database partitions.

RecommendationIf enough CPU resources are available, performance increases with the number of database partitions where the DataStore object is located. Although MPP-optimized data activation can already be used for DataStore objects that are distributed over four database partitions, we recommend eight database partitions or more.


http://help.sap.com/disclaimer?site=http%3A%2F%2Fhelp.sap.com%2Fnw73


● For MPP-optimized data activation, the SAP BW system automatically creates a new table (the join table) for the DataStore object. The DataStore object is eligible for MPP-optimized data activation if this new table can be created in the tablespace where the active table of the DataStore object resides. This table can be created if the record length does not exceed the maximum record length allowed for the tablespace. For more information, see SAP Notes 1621978 and 1619782 .

If the conditions above are fulfilled and the DataStore object is activated, the new join table is created for the DataStore object in addition to the activation queue table, the active table, and the change log table. This new table follows the naming conventions for the activation queue and active tables of standard DataStore objects and has the suffix 60.

Note● If you are upgrading your SAP system from a lower SAP BW release to SAP BW 7.3 and higher, you have

to reactivate the DataStore objects for which you want MPP-optimized data activation to be used.If the DataStore object fulfills the conditions described above, the join table is created during the reactivation of the DataStore object. Subsequent data activations then use the MPP-optimized method.

● Starting with Support Package 2 of SAP BW 7.3, you can repartition the activation queue tables of standard DataStore objects in a way that the same columns are used for hash partitioning as for the active table and the join table. Repartitioning improves the performance of MPP-optimized data activation because fewer records have to be transferred between database partitions during the execution of the LEFT OUTER JOIN operation (see also MPP Activation Phases and Active Log Space [page 121]). For more information, see SAP Note 1515687 .

Constraints

● A data activation that is restarted after it's been aborted always uses the same method that was used in the arborted activation. You cannot switch to another activation method.

● With MPP, workload is shifted from the application server to the database server. Make sure that your database server has enough capacity to handle the additional workload.

● Depending on the amount of data, significantly more active log space might be required when MPP-optimized data activation in DataStore objects is used. Therefore, you might have to increase the active log space, for example, by increasing the number of primary log files, or by increasing the log file size.The active log space needed for MPP-optimized data activation depends on the number of records to be processed in one transaction and on the record length. The number of records processed in one database transaction during MPP-optimized data activation can be up to three times as high as the number of records in the requests in the activation queue that are to be activated. When calculating the active log space needed for your database, you should also take into account other database transactions that are running in parallel. For more information, see MPP Activation Phases [page 121].For more information about the log space used for database transactions, see Db2 log records in the IBM Db2 Knowledge Center.

120 P U B L I C






7.4.2 MPP Activation Phases and Active Log Space

Get an overview of the MPP activation phases. The overview also gives you an idea how much active log space is needed for MPP. The active log space needed for MPP-optimized data activation depends on the number of records to be processed in one transaction and on the record length.

With MPP-optimized data activation, all records to be activated are processed in the following large database transactions:

1. LEFT OUTER JOINA left outer join is performed on the data to be activated and on the data in the active table of the DataStore object. The result is inserted into the new join table. The record length of the join table is approximately the record length of the activation queue table, plus the record length of the active table. The number of records inserted into the join table corresponds to the number of records in the requests to be activated in the activation queue table.

2. INSERTRecords that do not yet exist in the active table are inserted into the active table and an after-image record is inserted into the change log table.In the worst case, the number of records inserted into the active table corresponds to the number of records in the join table. In the same database transaction, the same number of records is inserted into the change log table (that is, for each record inserted into the active table, its after-image is inserted into the change log table).

3. UPDATERecords that exist in the active table are updated. For each record, a before-image and an after-image record are written to the change log table.In the worst case, the number of records updated in the active table corresponds to the number of records in the join table. In the same database transaction, double the number of records is inserted into the change log table (that is, for each record updated in the active table, its before-image and its after-image are inserted into the change log table).

4. DELETERecords to be deleted are deleted from the active table. For each record, a before-image record is written to the change log table.In the worst case, the number of records deleted from the active table corresponds to the number of records in the join table. In the same database transaction, the same number of records is inserted into the change log table (that is, for each record deleted in the active table, its before-image is inserted into the change log table).

7.4.3 Example: Activating a DataStore Object Using MPP

Here's a typical example of how you activate a DataStore object using MPP.

Procedure

1. In your SAP BW system, in the Data Warehousing Workbench (transaction RSA1), create the standard DataStore object ZMYDSO.


2. Leave the Unique Data Records checkbox unselected.3. Assign a data class to the active table and the change log table.

This data class is mapped to a data tablespace and to an index tablespace that are distributed over eight database partitions.

4. Activate the DataStore object.

Result

When you activate the DataStore object, the following tables are created:

Table Name Description

/BIC/AZMYDSO40 Activation queue table

/BIC/AZMYDSO60 Join table (new)

/BIC/AZMYDSO00 Active table

/BIC/B<nnnnnnnnnn> Change log table

The change log table, join table, and active table are created in the same tablespace that is distributed over eight database partitions. The activation queue table can be assigned to a different data class that is mapped to a different tablespace.

RecommendationWith MPP-optimized data activation, we recommend that you distribute all DSO tables (including the activation queue table) over the same database partitions. This guarantees a high benefit from parallel SQL statement execution and minimizes the overhead of record transfers between database partitions.

The join table has the following properties:

● It is approximately twice as wide as the active table. The join table contains the fields of the activation queue table, the fields of the active table, and an additional field, ACTIVATN_METHOD.

● The distribution key consists of the semantic key fields of the DataStore object.● MDC is defined on three fields: ACTIVATN_METHOD, A__0RECORDMODE, and M__0RECORDMODE.● The table has no standard primary key index and no other unique or non-unique indexes.

122 P U B L I C



7.4.4 Tracing the SQL Statements Used with MPP-Optimized Data Activation

You can trace the SQL statements that were executed during MPP-optimized data activation of DataStore objects and their runtime using program RSODSO_MPP_SQL_LOG.

Procedure

1. In your SAP system, call transaction SE38.2. Enter RSODSO_MPP_SQL_LOG in the Program field and choose Execute.3. To add a DataStore object to the list of objects for which SQL statements are collected, choose Add

DataStore.4. To activate the logging of SQL statements for a DataStore object, select the DataStore object and choose

Activate.You can display the SQL statements that were executed during a data activation by selecting the DataStore object from the list and choosing Show SQL.A dialog box appears containing the request IDs for which SQL statements have been collected during data activation. To display the SQL statements, double-click a request ID. The statement runtime is shown below each statement.

5. To switch off logging of SQL statements for a DataStore object, select the DataStore object from the list and choose Switch Off.

6. To delete the SQL logs collected for a DataStore object, select the DataStore object from the list and choose Delete Logs.

Note

With SAP Note 1736026 , you can optionally collect the access plans of the complex SQL statements that are executed during MPP-optimized DSO data activation. We recommend that you do this when you experience slow performance. The access plans are written to the SQL log together with the SQL statements and their runtime.

7.4.5 Disabling and Re-Enabling MPP-Optimized Data Activation for DataStore Objects

You can disable MPP-optimized data activation for a single DataStore object or for all DataStore objects. Disabling MPP-optimized data activation for all DataStore objects might be relevant, for example, if you are not sure yet whether there are enough CPU resources and active log space available on your database servers.

As of SAP BW 7.3 Support Package 9, SAP BW 7.31 Support Package 7, and SAP BW 7.4 Support Package 4, MPP-optimized SID generation and MPP-optimized DSO data activation can be enabled and disabled using the transaction RSODSO_SETTINGS. As of SAP BW 7.3 Support Package 8 and SAP BW 7.31 Support Package 5, you can use the maintenance view V_RSODSOMPPSWTCH. For lower support packages, you need to edit table RSODSOMPPSWTCH.



In the following, you can find the description for disabling and re-enabling data activation using transaction RSODSO_SETTINGS and maintenance view V_RSODSOMPPSWTCH. If you use lower support packages where the view is not yet available, follow the instructions in SAP Note 1645327 .

More Information

SAP Note 1645327

SAP Note 1730017

7.4.5.1 Disabling MPP-Optimized Data Activation Using Transaction RSODSO_SETTINGS

Disabling MPP-optimized data activation might be relevant, for example, if you are unsure whether there are enough CPU resources and active log space available on your database servers.

Prerequisites

You have an SAP BW system with at least SAP BW 7.3 Support Package 9, SAP BW 7.31 Support Package 7, or SAP BW 7.4 Support Package 4.

Procedure

1. In your SAP BW system, call transaction Parameters for DataStore Objects (transaction RSODSO_SETTINGS).

2. To disable MPP-optimized data activation for a single DataStore object, double-click the relevant DataStore object.

3. To disable MPP-optimized data activation for all DataStore objects, choose Change System Defaults.4. Under Expert Settings: MPP, choose Edit.5. In the following dialog box, enter X in the Classic Act. field.

This enables the “classic activation” of DataStore objects instead of the MPP-optimized data activation.6. Leave the remaining fields empty.7. Save your entries.

124 P U B L I C






7.4.5.2 Re-Enabling Disabled MPP-Optimized Data Activation Using Transaction RSODSO_SETTINGS

Follow this procedure if you want to re-enable MPP-optimized data activation that you have previously disabled.

Procedure

1. In your SAP BW system, call transaction Parameters for DataStore Objects (transaction RSODSO_SETTINGS).

2. If you have disabled MPP-optimized data activation for all DataStore objects and you want to re-enable the MPP-optimized data activation for all DataStore objects, choose Change System Defaults.

3. If you have disabled MPP-optimized data activation for all DataStore objects and you want to enable the MPP-optimized data activation for selected DataStore objects, double-click the relevant DataStore objects.

4. Under Expert Settings: MPP, choose Edit and enter the following data:

Field Name User Entry

Classic Act. No entry (False)

Access: SID Handling AJ (Antijoin)

With antijoin, the SID generation for DataStore objects runs on the database. This improves performance during MPP-optimized data activation as part of the load is shifted from the application server to the database. We recommend that you use this setting if you use MPP-optimized data activation. For DataStore objects that are not explicitly disabled or re-enabled, antijoin is the default for MPP-optimized data activation.



7.4.5.3 Disabling MPP-Optimized Data Activation Using View V_RSODSOMPPSWTCH

For SAP BW systems with lower releases and support packages, transaction RSODSO_SETTINGS is not available. Instead, you can use view V_RSODSOMPPSWTCH to disable MPP-optimized data activation.

Prerequisites

You have an SAP BW system with at least SAP BW 7.3 Support Package 8 and SAP BW 7.31 Support Package 5. In this case, maintenance view V_RSODSOMPPSWTCH is available. For lower support packages, you need to edit table RSODSOMPPSWTCH.

Procedure

1. In your SAP BW system, call transaction Edit Table Views (SM30) and edit view V_RSODSOMPPSWTCH.

2. To disable MPP-optimized data activation for a single DataStore object, choose New Entries and enter the following data:


DataStore Enter the name of the DataStore object for which you want to disable MPP-optimized data activation.

Classic Act. Select this checkbox.

This enables the “classic activation” of DataStore objects instead of the MPP-optimized data activation.

Access: SID Handling Standard Access

3. To disable MPP-optimized data activation for all DataStore objects, choose the Create button and enter the following data:


DataStore $ALL$

Classic Act. Select this checkbox.

Access: SID Handling Standard Access


126 P U B L I C



7.4.5.4 Re-Enabling Disabled MPP-Optimized Data Activation Using View V_RSODSOMPPSWTCH

Follow this procedure if you want to re-enable MPP-optimized data activation that you have previously disabled.

Procedure

1. In your SAP BW system, call transaction Edit Table Views (SM30) and edit view V_RSODSOMPPSWTCH.

2. To re-enable MPP-optimized data activation for a single DataStore object for which you have disabled MPP-optimized data activation before, delete the entry for the DataStore object in view V_RSODSOMPPSWTCH.

3. If you have disabled MPP-optimized data activation for all DataStore objects and you want to re-enable it for selected DataStore objects again, proceed as follows:a. For each DataStore object for which MPP-optimized data activation should be enabled, add one new

entry to view V_RSODSOMPPSWTCH.b. Make sure that the checkbox Classic Act. is not selected.c. In the Access: SID Handling field, select Antijoin.

With antijoin, the SID generation for DataStore objects runs on the database. This improves performance during MPP-optimized data activation as part of the load is shifted from the application server to the database. We recommend that you use this setting if you use MPP-optimized data activation. For DataStore objects that are not explicitly disabled or re-enabled using view V_RSODSOMPPSWTCH, antijoin is the default for MPP-optimized data activation.



8 Db2 pureScale

Db2 pureScale is a shared-disk scale-out and high-availability solution.

NoteYou cannot combine Db2 BLU Acceleration with Db2 pureScale.

Setup

Db2 pureScale Setup

In a Db2 pureScale environment, all members work on the same shared dataset. For changing operations, the cluster caching facility (CF) coordinates which member is allowed to carry out a change at which time. This differs from Db2 DPF, where the data is distributed across different partitions and where each member works only on its local data.

With Db2 pureScale, SAP application servers can connect to any Db2 member. However, all of the work processes of an application server must connect to the same Db2 member, to optimize the data locality and minimize the coordination effort via CF. If a Db2 member fails or must be shut down for maintenance, the connections of all work processes that are connected to this member are transferred to another member. Once

128 P U B L I C


Db2 pureScale

the member is online again, all of the connections that were previously redirected are transparently and automatically directed back to the member.

For more information about the prerequisites and constraints for using Db2 pureScale with SAP BW systems, see SAP Note 1745053 (SAP BW 7.0x) and SAP Note 1716996 (SAP BW 7.30 and higher).

Recommendations

Db2 pureScale is supported with SAP BW, but it is only one option among many if you need a scale-out or a high-availability solution. Before you decide on Db2 pureScale, consider carefully the following alternatives:

● Db2 Database Partitioning Feature (DPF, for scale-out)● Db2 HADR (for high availability, non-DPF only)

Special Considerations and Constraints for Db2 pureScale

Before you use Db2 pureScale, consider also the following:

● Db2 pureScale is currently only available on AIX and Linux.● Db2 pureScale has special hardware requirements. For more information, see the database guide Running

an SAP System on IBM Db2 with the pureScale Feature at https://help.sap.com/viewer/p/DB6.● You cannot combine Db2 pureScale with BLU Acceleration (column-organized tables) or with

multidimensional clustering (MDC).

Deciding Between Db2 pureScale and Db2 DPF for Scale-Out

Both Db2 pureScale and the Db2 Database Partitioning Feature (DPF) can be used to scale out your SAP BW system across multiple servers, but they each use different scale-out approaches. If you are deciding between Db2 pureScale and DPF for a SAP BW system, consider the following:

● Multidimensional clustering (MDC) tables and column-organized tables (BLU Acceleration) are currently not supported with Db2 pureScale, but they are supported with DPF.

● DPF scales every operation with the number of data partitions involved because all members involved work on their local data in parallel. In contrast to DPF, in Db2 pureScale, each request is processed by only one single Db2 member that the application server is connected to. However, this Db2 member can parallelize request execution within the member using intrapartition parallelism.

● Db2 DPF is not a high-availability solution. If a member fails, the data of this partition is not available until the member is online again.

● DPF parallelizes backup and recovery using the partitions. With Db2 pureScale, backup and recovery are executed by one member.

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksDb2 pureScale P U B L I C 129



https://help.sap.com/viewer/p/DB6

Deciding Between Db2 pureScale and Db2 High Availability Disaster Recovery (HADR)

Db2 pureScale is only one possible high-availability solution. We recommend that you consider HADR with BLU Acceleration as an alternative. If you are deciding between Db2 pureScale and Db2 HADR, consider the following:

● For a single-partition system, you can easily set up a high availability and disaster recovery solution using Db2 HADR. The administration effort for such a system tends to be lower than for Db2 pureScale.

● You cannot combine Db2 HADR and DPF. However, in many cases, a single partition with intrapartition parallelism and HADR is a good choice.

8.1 Implementing Db2 pureScale

Follow these steps to implement Db2 pureScale in an SAP BW environment:

For the prerequisites for Db2 pureScale with SAP BW, see SAP Note 1745053 (SAP BW 7.0x) or SAP Note 1716996 (SAP BW 7.30 and higher).

To install an SAP system running on Db2 pureScale or to update an existing SAP system to Db2 pureScale, follow the SAP guides for Db2 pureScale at https://help.sap.com/viewer/p/DB6.

130 P U B L I C


Db2 pureScale




9 Best Practices

9.1 Dealing with System Growth

Here's some information about system growth, typical growth scenarios, and the options to deal with it.

In SAP BW systems, the following typical growth scenarios include the following:

● Increased data volume● Increased workload● New SAP BW application areas

Some of the recommendations below apply only to DPF environments, but others apply to all types of database layout.

Increased Data Volume

When deciding how to handle increased data volume best, consider the following:

● Increase CPU and memoryWith each data load from the source systems to the SAP BW system, the data volume increases on the database. Therefore, the query response time can increase, too. To reduce query response time, you can increase the CPU and the memory capacity on the SAP BW system.

● Use near-line storageTo slow down the data volume increase, you can also use a near-line storage (NLS) database. NLS is a category of data persistency that is similar to archiving. Using an NLS database enables you to transfer historical read-only InfoProvider data (for example, InfoCubes and DataStore objects) to an additional NLS database. The database server and the storage devices of the NLS solution can be on the same server as the SAP BW system or on a dedicated server. However, you can still access the separated data in the NLS database transparently from an SAP BW system. For more information, see the guide Enabling SAP Business Warehouse Systems to Use IBM Db2 for Linux, UNIX, and Windows as Near-Line Storage (NLS) on SAP Help Portal at http://help.sap.com/viewer/db6_nls.

● DPF only: Add new database partitionsIf you use DPF, you can also add new data partitions to compensate increased data volume. You can add new database partitions by upgrading existing servers or by adding one or more new servers. To take advantage of the newly added database partitions, you'll need to redistribute the data on the old and new data partitions. For more information about redistributing data, see Redistributing Data [page 110].

Increased Workload

You may face increased workload with an unchanged data volume from an increase of query activity. Reasons for such increased activity can be, for example, recently added SAP BW applications or additional users. An

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksBest Practices P U B L I C 131

http://help.sap.com/viewer/db6_nls

increased workload may result in a longer query response time. To reduce the query response time, you can add additional CPU and memory capacity.

We recommend that you do not add DPF partitions to handle increased workload with unchanged data volume. Add more data partitions only if the data volume increased significantly along with the workload.

New SAP BW Application Areas

With the introduction of new SAP BW application areas, additional SAP BW objects have been created. These objects introduce additional data volume and workload. In response, you can increase the CPU and memory capacity on your SAP BW system. If you are using DPF, you can also add new data partitions and distribute the new tables only across the new partitions. The workload goes to separate database partitions and does not interfere with the already existing workload.

NoteMake sure that for all these growth scenarios you have evenly distributed the data volume and workload across all data partitions.

9.2 Considerations for High Availability

There are several options for making your SAP BW system highly available. Whether you can use some of these partially depends on the database layout that you have chosen.

Options for High Availability

High Availability Option Description Constraints More Information

Db2 High Availability Disaster Recovery (HADR)

High Availability Disaster Recovery (HADR) is a replication feature of Db2 that makes the database server highly available. In this scenario, you have two separate Db2 database servers, a primary and a standby. Both servers are kept in sync. In the event of a failure, the standby database server takes over the workload.

You cannot combine HADR with DPF.

IBM documentation for IBM Db2 for Linux, UNIX, and Windows: HADR Multiple standby databases, at http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0059994.html

Installation guide IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms at https://help.sap.com/viewer/db6_samp

132 P U B L I C


Best Practices

http://help.sap.com/disclaimer?site=http%3A%2F%2Fpublib.boulder.ibm.com%2Finfocenter%2Fdb2luw%2Fv10r1%2Ftopic%2Fcom.ibm.db2.luw.admin.ha.doc%2Fdoc%2Fc0059994.html







https://help.sap.com/viewer/db6_samp


High Availability Option Description Constraints More Information

Cold standby (shared-disk scenario)

In the cold standby setup of Db2, you use two database servers, a primary and a “cold standby”. The database is located on a disk that is shared by the two database servers. Since the database servers share a disk, this setup is sometimes also referred to as a “shared-disk scenario”.

- High Availability in an SAP Business Warehouse Multi-Partition DB2 Environment Using SA MP at http://scn.sap.com/docs/DOC-23176

Installation guide IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms at https://help.sap.com/viewer/db6_samp

Db2 pureScale Db2 pureScale lets you scale your database solution to multiple database servers called Db2 members that work on shared data.

The main focus of Db2 pureScale is on scalability and high availability.

You need Db2 10.5 or higher to combine HADR with Db2 pureScale.

You cannot combine BLU Acceleration or MDC with pureScale.

Db2 pureScale [page 128]

Installation Guide: Running an SAP System on DB2 pureScale at https://help.sap.com/viewer/p/DB6

9.3 SAP BW Health Checks

As of SAP BW 7.3, the DBA Cockpit provides BW health checks that you can use to check if the main Db2 features for SAP BW have been correctly implemented on your system.

Context

Use BW health checks to identify the following:

● If there is a high disk space consumption due to unsuitably defined multidimensional clustering (MDC) for InfoCubes and DataStore objects

● If you have wrong distribution keys for InfoCube or aggregate fact tables, DataStore object tables, or PSA tables

● If the fact tables of your InfoCubes are distributed over the same database partitions● If the partitioning columns SID_0CALMONTH or SID_0FISCPER of InfoCube or aggregate fact tables are

filled correctly


http://help.sap.com/disclaimer?site=http%3A%2F%2Fscn.sap.com%2Fdocs%2FDOC-23176







Available Checks

The following checks are available in the DBA Cockpit (transaction DBACOCKPIT):

Check Description

MDC Space Check If MDC is defined for an InfoCube or DataStore object, this check verifies whether the disk space consumption exceeds a specific threshold. The MDC space check processes all InfoCubes and all standard and transactional DataStore objects.

Distribution Key Check This check verifies if the distribution keys of the InfoProviders and PSA tables have been correctly defined. The distribution key check processes all InfoCubes and their aggregates, all standard, transactional, and write-optimized DataStore objects, and all PSA tables.

Since distribution keys are created automatically, it is unlikely that SAP BW tables have the wrong distribution keys. It might be an issue if SAP BW tables are reactivated outside of the BW Data Warehousing workbench, for example, directly in the ABAP Dictionary. Even if your SAP BW system resides on a single database partition only, distribution keys are always generated for fact tables, DataStore object tables, and PSA tables.

RecommendationWe recommend that you check the distribution keys before you move from one to several database partitions. You can repair incorrect distribution keys if the tables that are affected reside on a single database partition. For more information, see Checking the Distribution Keys of All Tables (Optional) [page 112].

If the tables are distributed over several database partitions, you must use the DB6CONV program. Depending on the amount of data in the tables, the program may run for a long time. For more information, see Redistributing Data Using Program DB6CONV [page 114].

134 P U B L I C


Best Practices

Check Description

BW-Specific Layout Check This check verifies that both fact tables of an InfoCube are distributed over the same database partitions and that the columns SID_0CALMONTH or SID_0FISCPER are filled correctly with data if MDC is defined for an InfoCube with one of these columns.

NoteThis check does not replace the check Test of Partitioning Column for InfoCube in SAP BW transaction RSRV.

More Information

For more information about how to use BW health checks in your SAP environment, see Database Administration Using the DBA Cockpit: IBM Db2 for Linux, UNIX, and Windows at https://help.sap.com/viewer/p/DB6.

9.4 Controlling Database Log Space Consumption

Certain operations in an SAP BW system require a considerable amount of log space in the database. In the worst case, a BW function might stop with the error message that the database log space has been exceeded. By setting SAP BW parameters, you can control the log space consumption of the following operations:

● Aggregate build/change run● InfoPackage load from file into PSA or InfoCube● InfoPackage load from source system into PSA or InfoCubes

In addition, you can reduce log space consumption during InfoPackage deletion using multidimensional clustering (MDC).

Aggregate Build/Change Run

To control the log space consumption for aggregate build or change runs, set parameter BLOCKSIZE. In your SAP BW system, call transaction SPRO and choose SAP Reference IMG SAP Customizing Implementation Guide SAP NetWeaver Business Intelligence Peformance Settings Parameters for Aggregates .

By default, parameter BLOCKSIZE is set to 100,000,000 records. We recommend that you change this setting to a value between 5,000,000 and 10,000,000. In this way, you reduce the sorting of large temporary tables that are stored on disk and you also reduce log space consumption.




CautionDo not set parameter BLOCKSIZE to lower values because doing so may result in an SQL WHERE statement that forces the optimizer to use an index other than the clustering index or MDC index.

For more information about the parameter BLOCKSIZE, see SAP Note 780104 .

For information about the implementation of the Db2specific aggregate build, see SAP Note 1020173 .

InfoPackage Load from File into PSA or InfoCube

To control the log space consumption for InfoPackage loads from a file into PSAs or InfoCubes, set parameter PACKAGE SIZE. In your SAP BW system, call transaction SPRO and choose SAP Reference IMG SAP Customizing Implementation Guide SAP NetWeaver Business Intelligence Links to Other Source Systems

Maintain Control Parameters for the data transfer .

Parameter PACKAGE SIZE determines how many records are inserted in one transaction. The value for PACKAGE SIZE should be between 50,000 and 100,000. Don't use very small values; they can have a negative impact on performance.

InfoPackage Load from Source System into PSA or InfoCubes

To control the log space consumption for InfoPackage loads from a source system into PSAs or InfoCubes, set parameter MAXSIZE in table ROIDOCPRMS in the source system. For more information about setting this parameter, see SAP Note 417307 .

Parameter MAXSIZE determines the size of a data package. The unit of measurement is KB.

CautionIf you are using parallel load processes and are loading data into several data targets concurrently, log space consumption increases.

InfoPackage Deletion

Using multidimensional clustering (MDC) significantly reduces the log space consumption during the deletion of InfoPackages from PSA tables, change log tables of DataStore objects, and F fact tables of an InfoCube.

For more information, see the section Faster InfoPackage Deletion in Multidimensional Clustering (MDC) [page 66].

136 P U B L I C


Best Practices




9.5 Recommendations for InfoCube Compression

You must apply compression to non-cumulative InfoCubes. For all other InfoCubes, apply compression only if doing so significantly reduces the data volumes within these InfoCubes.

What's InfoCube Compression

You can use InfoCube compression to reduce the data volume within an InfoCube. During the InfoCube compression, rows with duplicated keys are summarized in the E fact table, and the corresponding data packages are deleted from the F fact table.

Recommendations

We recommend that you use InfoCube compression in SAP BW systems running on IBM Db2 for Linux, UNIX, and Windows only sparingly and with caution, for the following reasons:

● InfoCube compression is a time-consuming operation. Moreover, the InfoCube cannot be accessed during the E fact table insert and update phases of the compression.

● For SAP BW systems running on IBM Db2, the InfoCube compression is not required in many cases because E and F fact tables of an InfoCube are sufficiently optimized for query performance. This might be different for SAP BW systems running on other databases.

Therefore, apply compression to InfoCubes only if doing so significantly reduces the data volume within these InfoCubes, or if they are non-cumulative.

This recommendation applies to both row-organized and for column-organized InfoCubes (including flat InfoCubes).

Applying InfoCube Compression

In the Data Warehousing Workbench (transaction RSA1), use the Manage InfoCubes function to compress InfoCubes.

NoteIn addition, for column-organized InfoCubes, you can set the RSADMIN parameter DB6_ICCOMPR_USE_DGTT.


Related Information

Improving the Compression Performance of Column-Organized InfoCubes [page 138]

9.6 Improving the Compression Performance of Column-Organized InfoCubes

To improve the compression performance of column-organized InfoCubes, set the RSADMIN parameter DB6_ICCOMPR_USE_DGTT to YES. However, compression is not always advisable.

Prerequisites

You have implemented SAP Note 2457005 or the SAP support packages mentioned in this SAP Note.

Context

While of column-organized InfoCubes are being compressed, temporary tables are used to store intermediate results. With the RSADMIN parameter set, temporary tables are created as not-logged declared global temporary tables (DGTTs). With not-logged DGTTs, there is no logging overhead and no Db2 system catalog overhead since DGTTs are not stored in the Db2 system catalog.

NoteThis applies to both column-organized InfoCubes with a star schema and flat InfoCubes.

Before you use compression, consider the recommendations (see Recommendations for InfoCube Compression [page 137]).

Procedure


2. Run program SAP_RSADMIN_MAINTAIN.

3. Set the RSADMIN parameter DB6_ICCOMPR_USE_DGTT to YES.

138 P U B L I C


Best Practices


9.7 Activating Db2 Automatic Reorganization for Index Cleanup and Space Reclamation

Db2 automatic reorganization (AUTO REORG) automates index cleanup (REORG CLEANUP) and the release of completely empty extents after deletions (REORG RECLAIM). We recommend that you activate Db2 auto reorg.

Context

REORG RECLAIM is available for the following:

● As of Db2 9.7: MDC tables● As of Db2 10.1: Indexes● As of Db2 10.5: BLU tables

Even though the index cleanup and space reclamation activities are executed using the REORG utility, they are a local maintenance of objects rather than actual reorganizations. Therefore, activating Db2 auto reorg is less expensive than a true reorganization, which requires a downtime.

Procedure

● To check how much free space can be reclaimed from a table, you can use the field RECLAIMABLE_SPACE of the functions ADMIN_GET_TAB_INFO. As of SAP enhancement package 2 of SAP Business Warehouse 7.0, you can also use the DBA Cockpit.

● To activate Db2 auto reorg for index cleanup and space reclamation, follow the instructions in SAP Note 975352 . To configure the Db2 AUTO_REORG policy, you can use the Db2 command line, or as of SAP enhancement package 2 of SAP Business Warehouse 7.0, you can use the DBA Cockpit.

RecommendationWe recommend that you use the DBA Cockpit, if possible.

More Information

● SAP Note 975352● Database Administration Using the DBA Cockpit: IBM Db2 for Linux, UNIX, and Windows

at https://help.sap.com/viewer/p/DB6● Documentation ADMINTABINFO administrative view and ADMIN_GET_TAB_INFO table function - retrieve

table size and state information in the IBM Knowledge Center at http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.sql.rtn.doc/doc/r0052897.html





http://help.sap.com/disclaimer?site=http%3A%2F%2Fpic.dhe.ibm.com%2Finfocenter%2Fdb2luw%2Fv10r5%2Ftopic%2Fcom.ibm.db2.luw.sql.rtn.doc%2Fdoc%2Fr0052897.html

http://help.sap.com/disclaimer?site=http%3A%2F%2Fpic.dhe.ibm.com%2Finfocenter%2Fdb2luw%2Fv10r5%2Ftopic%2Fcom.ibm.db2.luw.sql.rtn.doc%2Fdoc%2Fr0052897.html

9.8 Using the Mass Cube Writer for Loading Data into InfoCubes (As of SAP NetWeaver 7.3)

As of SAP BW 7.3, the mass cube writer is available. It is a faster method for loading data into InfoCubes than the method of loading data using single record lookups.

Prerequisites

You are using SAP NetWeaver 7.3 or higher. In addition, you have implemented SAP Note 1637069 or the support packages mentioned in this SAP Note.

Context

The previous method of loading data uses single record lookups during the determination of SIDs for master data and dimension IDs for the InfoCube dimension tables. The mass cube writer uses FOR ALL ENTRIES statements where many lookups can be bundled into one SQL statement. The mass cube writer is usually much faster, especially for flat InfoCubes and for InfoCubes that use BLU Acceleration. For BLU Acceleration, the blocking factor for the FOR ALL ENTRIES statements that are used to look up SID and DIM ID values is set to 1000, that is, 1000 lookups are performed with one SQL statement. As of SAP BW 7.5, performance of FOR ALL ENTRIES statements is further optimized by an implementation that performs all lookups in only one SQL statement (SAPTOOLS.MEMORY_TABLE).

For flat InfoCubes, the mass cube writer is used by default. For standard InfoCubes with the star schema, you'll need to enable it.

Procedure


2. Run program SAP_RSADMIN_MAINTAIN to change the RSDD_ENABLE_MASS_CUBE_WRITE parameter to X.

140 P U B L I C


Best Practices


9.9 Changing the Table Layout for P, Q, and Text Tables of New InfoObjects to Row-Organized

Use the RSADMIN parameter DB6_IOBJ_PQT_USE_CDE to control whether P, Q, and text tables of InfoObjects are created as row-organized or column-organized tables.

Context

CautionUse parameter DB6_IOBJ_PQT_USE_CDE only when the performance of column-organized P, Q, and text tables causes serious issues.

You can use the RSADMIN parameter DB6_IOBJ_USE_CDE to set the table format of InfoObject tables to column-organized. This setting includes P, Q, and text tables of InfoObjects, which are then also created as column-organized tables. If you need to create InfoObjects with P, Q, and text tables with row-organized tables while the rest of the InfoObject tables remain column-organized, you can use the RSADMIN parameter DB6_IOBJ_PQT_USE_CDE.

Changes to the RSADMIN parameter DB6_IOBJ_PQT_USE_CDE take effect only when new InfoObjects are created or when an InfoObject is converted to BLU Acceleration using program DB6CONV. There is no effect on existing tables.

The setting of the RSADMIN parameter DB6_IOBJ_PQT_USE_CDE also affects the behavior of program DB6CONV. If the parameter is not set or set to YES, the program converts P, Q, and text tables to column-organized. If the parameter is set to NO, the program converts P, Q, and text tables to row-organized.

The DB6_IOBJ_PQT_USE_CDE parameter only has an effect if DB6_IOBJ_USE_CDE is set to YES.

Procedure


2. To change the table format of P, Q and text tables to row-organized, enter DB6_IOBJ_PQT_USE_CDE in the OBJECT field and enter NO in the VALUE field.


Related Information



9.10 Temporarily Disabling BLU Acceleration for New BW Objects

You can use the RSADMIN parameter DB6_ALLOW_CDE to control whether any new SAP BW objects are created using BLU Acceleration.

Prerequisites

You need SAP Note 2019648 or the SAP Business Warehouse releases and support packages mentioned in this SAP Note.

Context

By default, the RSADMIN parameter DB6_ALLOW_CDE is set to YES. This means that if the prerequisites for BLU Acceleration are met and the relevant RSADMIN parameters for individual BW objects are set, the system creates the BW objects as column-organized by default.

However, you might want to prevent BLU Acceleration being used for new objects in your system in cases such as the following :

● You want to activate flat InfoCubes from SAP BI Content. However, either you do not want to use BLU Acceleration, or your system is not yet prepared for it (for example, the relevant tablespaces are not available, not enough CPU or memory, and so on). For example, this might be relevant in an SAP Solution Manager system.

● You want to transport InfoCubes from a test system with BLU Acceleration to a production system in which BLU Acceleration is not yet used. If you have disabled BLU Acceleration in the target system and transport a column-organized InfoCube, the InfoCube is activated with row-organized tables. In these cases, either index clustering is used or multidimensional clustering if the partitioning column in the BW meta data is filled with 0CALMONTH, 0CALWEEK, or 0FISCPER.

In these cases, you might want to set the RSADMIN parameter DB6_ALLOW_CDE to NO.

Procedure


2. Enter DB6_ALLOW_CDE in the OBJECT field and NO in the VALUE field.


142 P U B L I C


Best Practices


Related Information



10 Additional Sources of Information

Here you can find additional sources of information about SAP on IBM Db2, including online information from SAP and IBM, and SAP Notes.

Online Information from SAP

Type of Information Internet Address

Database administration guide for SAP on IBM Db2 for Linux, UNIX, and Windows

http://help.sap.com/db6_admin

Database administration using the DBA Cockpit: IBM Db2 for Linux, UNIX, and Windows


Installation guide for SAP Systems based on SAP NetWeaver http://support.sap.com/sltoolset > System Provisioning

Installation guide: IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms


High Availability in an SAP Business Warehouse Multi-Partition Db2 Environment Using SA MP

SAP Community at https://archive.sap.com/documents/docs/DOC-23176

Installation guide for SAP systems running on Db2 with the pureScale Feature

https://help.sap.com/viewer/p/DB6 Installation

Database upgrade guide for IBM Db2 for Linux, UNIX, and Windows

http://help.sap.com/viewer/db6_upgrade_11_1


Product Availability Matrix (PAM) on SAP Support Portal http://support.sap.com/en/release-upgrade-maintenance.html

Homepage of SAP on IBM Db2 for Linux, UNIX, and Windows in the SAP Community Network

https://www.sap.com/community/topic/db2-for-linux-unix-and-windows.html

144 P U B L I C


Additional Sources of Information

http://help.sap.com/db6_admin




http://help.sap.com/disclaimer?site=https%3A%2F%2Farchive.sap.com%2Fdocuments%2Fdocs%2FDOC-23176

http://help.sap.com/disclaimer?site=https%3A%2F%2Farchive.sap.com%2Fdocuments%2Fdocs%2FDOC-23176




http://help.sap.com/disclaimer?site=http%3A%2F%2Fsupport.sap.com%2Fen%2Frelease-upgrade-maintenance.html

http://help.sap.com/disclaimer?site=http%3A%2F%2Fsupport.sap.com%2Fen%2Frelease-upgrade-maintenance.html

http://help.sap.com/disclaimer?site=https%3A%2F%2Fwww.sap.com%2Fcommunity%2Ftopic%2Fdb2-for-linux-unix-and-windows.html

http://help.sap.com/disclaimer?site=https%3A%2F%2Fwww.sap.com%2Fcommunity%2Ftopic%2Fdb2-for-linux-unix-and-windows.html

Online Information from IBM

IBM Db2 Knowledge Center

Database Version Internet Address

Db2 11.1 http://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.kc.doc/welcome.html

Db2 10.5 https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.kc.doc/welcome.html

SAP Notes

Db2 Standard Parameter Settings

SAP Note Number Title

2303771 DB6: Db2 11.1 Standard Parameter Settings

1851832 DB6: Db2 10.5 Standard Parameter Settings

Database Layout and Partitioning


1745053 DB6: Support for Db2 pureScale in SAP NW BW 7.0x and 7.11

648432 DB6: New function modules for hash partitioning

BLU Acceleration


1819734 DB6: Use of BLU Acceleration

1825340 DB6: Use of BLU Acceleration with SAP BW and applications based on SAP BW

1834310 DB6: Use of DB2 BLU Acceleration with Db2 near-line storage

Multidimensional Clustering (MDC)


832621 DB6: RSADMIN parameters for MDC in SAP NetWeaver 7.x BW

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksAdditional Sources of Information P U B L I C 145

http://help.sap.com/disclaimer?site=http%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSEPGG_11.1.0%2Fcom.ibm.db2.luw.kc.doc%2Fwelcome.html

http://help.sap.com/disclaimer?site=http%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSEPGG_11.1.0%2Fcom.ibm.db2.luw.kc.doc%2Fwelcome.html

http://help.sap.com/disclaimer?site=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSEPGG_10.5.0%2Fcom.ibm.db2.luw.kc.doc%2Fwelcome.html

http://help.sap.com/disclaimer?site=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSEPGG_10.5.0%2Fcom.ibm.db2.luw.kc.doc%2Fwelcome.html










1335017 DB6: “Remove Redundant Restrictions” can return wrong results (SAP NetWeaver BW 7.0x only)

Compression


1742347 DB6: Global Compression Option in SAP NW BW 7.0x and 7.11

1716996 DB6: Global Compression Option/Db2 pureScale for NW BW 7.3x

MPP-Optimized DataStore Object Activation


1645327 DB6: MPP-optimized DSO Data Activation in SAP NW BW 7.3

1515687 DB6: Performance Optimization DSO Data Activation (SAP NetWeaver BW 7.3 and higher)

Database Administration and System Copy


888210 NW 7.0 / 7.10: System copy (supplementary note)

1513862 DB6: Table conversion using DB6CONV

General Troubleshooting


374502 DB6: Db2 for LUW – BW Performance – Overview of SAP Notes

780104 DB6: Performance impact of BLOCKSIZE on Aggregate Build

146 P U B L I C


Additional Sources of Information










11 Appendix

11.1 BLU Acceleration: Additional Information

Compression

With BLU Acceleration, data is stored in column-organized tables and it is always compressed. However, this compression is not indicated when you call up the storage parameters of a table. Column-organized tables are created with the keyword ORGANIZE BY COLUMN. When you call up the storage parameters of a table, this keyword is displayed.

Synopsis Tables

Along with each column-organized table, Db2 typically creates a corresponding synopsis table. The synopsis table is automatically maintained when data is inserted or loaded into the column-organized table and is used for data skipping during SQL query execution. Space consumption and the cost for updating the synopsis tables when the data in the column-organized table is changed are much lower than the space consumption and update costs of secondary indexes. Synopsis tables reside in the SYSIBM schema and follow the naming convention of SYN<timestamp>_<column-organized table name>.

With Db2 10.5 FP3aSAP or lower, depending on the transaction size, the synopsis might become larger than expected (see SAP Note 2034090 ).

To solve this issue, with Db2 10.5 as of FP4, synopsis tables are no longer created for InfoCube dimension tables. This is achieved with the Db2 registry setting DB2_CDE_WITHOUT_SYNOPSIS=%:/%/D%, which is part of DB2_WORKLOAD=SAP. If you have created column-organized InfoCubes with Db2 10.5 FP3aSAP or lower and you are running your system on Db2 10.5, you can remove the dimension synopsis tables after you have implemented FP4 or higher.

As of Db2 11.1, MP2 FP2, this issue no longer exists. Therefore, the DB2_CDE_WITHOUT_SYNOPSIS setting has been removed from DB2_WORKLOAD=SAP and synopsis tables are created again with SAP BW. There's no longer any need to remove them.

More Information

For more information about column-organized tables, see the IBM Knowledge Center for IBM Db2 10.5 at:

http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.wn.doc/doc/c0060311.html

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksAppendix P U B L I C 147


http://help.sap.com/disclaimer?site=http%3A%2F%2Fpic.dhe.ibm.com%2Finfocenter%2Fdb2luw%2Fv10r5%2Ftopic%2Fcom.ibm.db2.luw.wn.doc%2Fdoc%2Fc0060311.html

11.2 Checklist: Upgrading an SAP BW System from Db2 10.5 FP3aSAP to 10.5 FP5SAP2

If you use BLU Acceleration and if you still use Db2 10.5 FP3aSAP, we strongly recommend that you upgrade to FP5SAP2 or higher.

Prerequisites

You have already at least the following SAP BASIS and SAP BW support packages installed:

SAP BW Release SAP BASIS Support Package

SAP BW Support Package Technical Name

7.00 29 31 SAPKW70031

7.01 (SAP BW 7.0 EHP 1) 14 14 SAPKW70114

7.02 (SAP BW 7.0 EHP 2) 14 14 SAPKW70214

7.11 12 12 SAPKW71112

7.30 10 10 SAPKW73010

7.31 (SAP BW 7.3 EHP 1) 9 9 SAPKW73109

7.40 5 5 SAPKW74005

Make sure that you have installed the latest available version of the SAP Kernel and the DBSL library, at least the version that contains the patch from SAP Note 1911087 with the following patch text: "DB6: DROP INDEX to DROP CONSTRAINT". If you have an SAP Kernel 7.41 or 7.42, use at least the version that contains the patch from SAP Note 2120815 .

Procedure

To upgrade your SAP BW system to Db2 10.5 Fix Pack 5SAP2, proceed as follows:


1 Upgrade to the required SAP BASIS and SAP BW support packages.


2 Install additional SAP Notes on top of the support packages.

Required SAP Notes for SAP BW with BLU Acceleration [page 24]

148 P U B L I C


Appendix





● dbs/db6/dbsl_ur_to_cc=*● dbs/db6/

deny_cdefield_extension=1 (not needed if you upgrade to Db2 11.1. FP1 or higher)


4 To create new SAP BW objects with column-organized tables, set the relevant RSADMIN parameters in SAP BW.


5 To convert tables of existing row-organized InfoCubes and DataStore objects to a column-organized layout, use program DB6CONV.

Converting Row-Organized Tables of SAP BW Objects to Column-Organized Tables and Vice Versa [page 32]

6 For optimal query performance on column-organized InfoCubes and DataStore objects, make sure that temporary tables in SAP BW are also column-organized.


11.3 Migrating an SAP BW System to Db2 for LUW for the Use of Db2 BLU Acceleration

You want to migrate an existing SAP BW system to IBM Db2 for Linux, UNIX, and Windows and use Db2 BLU Acceleration after the migration. A migration is needed in the following cases:

● Your SAP BW system runs on another database platform and you want to migrate to Db2.● Your system runs on Db2, but uses Db2 pureScale. Db2 pureScale is not supported with BLU Acceleration,

so you must migrated to a single-member database.● Your system has more than one partition (using Db2 Database Partitioning Feature (DPF)). The hardware

requirements and recommendations for partitioned databases with BLU Acceleration differ from the requirements for partitioned databases with row-organized tables. After checking the hardware requirements for DPF with BLU Acceleration, you realize that it is advisable to run the BW system with only a single partition.

In these cases, you have the following options:

● You migrate the SAP BW system to Db2 with a single member and to row-organized tables. You then convert selected SAP BW objects (InfoCubes, DataStore objects, InfoObjects, PSA tables) to BLU Acceleration using program DB6CONV.


● You migrate the SAP BW system to Db2, including a direct migration to column-organized tables for all or selected SAP BW objects.

11.3.1 Migrating an SAP BW to Db2 with a Later Conversion to BLU Acceleration

You want to migrate your SAP BW system to the database IBM Db2 for Linux, UNIX, and Windows with a single member only. You intend to convert selected SAP BW objects to a column-organized table layout after the migration.

Prerequisites

Make sure that the target system fulfills the hardware and software requirements for BLU Acceleration. For more information, see Hardware and Software Requirements for BLU Acceleration [page 22].

Procedure

1. In the source system, run program SMIGR_CREATE_DDL and choose one of the following options:

○ Keep source settings○ Use BW basic table layout○ Use multidimensional clustering (MDC) for BW

2. Perform the SAP BW migration as usual, including the execution of the SAP BW post-migration program RS_BW_POST_MIGRATION.

If you have not chosen the option Keep Source Settings in program SMIGR_CREATE_DDL, run the variant SAP&POSTMGRDB Postproc. System Copy New DB.

3. When the system is up and running on Db2, continue with Checklist: Preparing an Installed SAP BW System for BLU Acceleration [page 20].

150 P U B L I C


Appendix

11.3.2 Checklist: Migrating an SAP BW System to Db2 Including Conversion to BLU Acceleration

With this checklist, you get an overview for migrating your SAP BW system to IBM Db2 on a single member. With the migration, you can also migrate your tables to BLU Acceleration.

Prerequisites

Ensure that the target database of the migration fulfills the hardware and software requirements for BLU Acceleration. For more information, see Hardware and Software Requirements for BLU Acceleration [page 22].

Procedure

To prepare an installed SAP BW system for BLU Acceleration, proceed as follows:


1 Upgrade the source system to the required support package levels for Db2 BLU Acceleration.


2 Install additional SAP Notes on top of the support packages.

Required SAP Notes for Preparing an SAP BW for BLU Acceleration [page 24]

3 Run program SMIGR_CREATE_DDL. Running the Migration Program for SAP BW Objects Including BLU Acceleration [page 152]

4 Before you load the data into the target system, create a separate directory for large temporary files.

Creating a New Directory for Large Temporary Files for BLU During R3Load [page 154]

5 Use the software provisioning manager (SWPM) to perform your system copy. Make sure that the target database instance fulfills the hardware and software requirements for BLU Acceleration.

Hardware and Software Requirements for BLU Acceleration [page 22]

6 Set a Db2 threshold for the number of expensive BLU queries that can run in parallel in the database.

Setting the Db2 Threshold for the Number of Parallel BLU Queries [page 25]




● dbs/db6/dbsl_ur_to_cc=*● dbs/db6/

deny_cdefield_extension=1 (no longer needed as of Db2 11.1 FP1)


8 Perform standard SAP NetWeaver post-migration tasks and run program RS_BW_POST_MIGRATION with the variant SAP&POSTMGRDB Postproc. System Copy New DB.

9 To create new SAP BW objects with column-organized tables, set the relevant RSADMIN parameters in SAP BW.


10 For optimal query performance, on column-organized InfoCubes and DataStore objects, make sure that temporary tables in SAP BW are also column-organized. To do this, set set the RSADMIN parameter DB6_TMP_USE_CDE in SAP BW to YES.

Old temporary tables should no longer exist because the RS_BW_POST_MIGRATION program drops them.


SAP BW Objects Supported with BLU Acceleration: Additional Information and Recommendations [page 19]

11.3.3 Running the Migration Program for SAP BW Objects Including BLU Acceleration

You can specify in migration program SMIGR_CREATE_DDL that the target layout of BW objects after migration is BLU Acceleration.

Prerequisites

You have applied SAP Note 1825340 to your source system.

152 P U B L I C


Appendix


Context

You run an SAP BW migration (see Checklist: Migrating an SAP BW System to Db2 Including Conversion to BLU Acceleration [page 151]). In the migration program SMIGR_CREATE_DDL, you can specify which SAP BW objects should have BLU Acceleration as a target layout of a migration:

● All SAP BW objects for which BLU Acceleration is supported● InfoCubes only● InfoCubes, including only the InfoObjects to which the InfoCubes refer● List of SAP BW objects specified in a file● List of SAP BW objects specified in a file, including the InfoObjects that are referenced in the InfoCubes and

DataStore objects selected for migration to BLU Acceleration

Procedure

Migrating all SAP BW Objects or all InfoCubes with Target Layout BLU AccelerationRun program SMIGR_CREATE_DDL with one of the following options:

● Use BLU for BW InfoCubesThe fact and dimension tables of InfoCubes and BW temporary tables are generated as column-organized tables.

● Use BLU for BW InfoCubes, including InfoObjectsThe fact and dimension tables of InfoCubes, the S-, X-, and Y-tables of InfoObjects that are referred to in the InfoCubes, and BW temporary tables are generated as column-organized tables.

● Use BLU for all eligible BW ObjectsAll BW objects that are currently supported for BLU Acceleration are generated as column-organized tables (this includes all DataStore objects without secondary indexes).

Migrating a Selection of SAP BW Objects with Target Layout BLU Acceleration1. Create a file with the names of the SAP BW objects that should have table layout BLU Acceleration after

migration. Each object name must be in its own line.2. In the source system, set RSADMIN parameter DB6_MIGRATE_TO_CDE_FILE for the path and name of the

file (there is a 30-character limit for path and name).3. If the file exists and can be read, program SMIGR_CREATE_DDL also provides the following options:

○ Use BLU for selected BW ObjectsA column-organized table layout is generated only for the tables of the BW objects listed in the file.

○ Use BLU for selected BW Objects incl. InfoObjectsA column-organized table layout is also generated for the InfoObjects that are referenced in the InfoCubes and DataStore objects that should be migrated to BLU Acceleration.

More Information

SAP Note 1825340



11.3.4 Creating a New Directory for Large Temporary Files for BLU Acceleration During Load

During the migration of your SAP BW system, before you load the data into the target system, you need to create a separate directory for temporary files that are generated during R3load. This directory is used when you use R3load with the CLI LOAD option to load data into column-organized (BLU) tables.

Use Case of the Directory

This directory is needed to store large temporary files that are generated for compression dictionary creation for BLU tables during CLI LOAD. As a default, each temporary file for a large column-organized table might grow as large as 128 GB. More space might be needed if multiple concurrent R3load proccesses use CLI LOAD for column-organized tables. As a default, these temporary files are created on the database server in the directory /db2/<SID>/db2<sid>/NODE####/SQL####/load. If the file system containing this directory is not large enough, a file system full condition might arise.

Creating the Directory for the Temporary Files

To avoid the a file system full condition in the default directory for temporary files, CLI LOAD lets you redirect the temporary files to a different directory. In current R3load versions, you can use the environment variable DB6LOAD_TEMP_FILES_PATH to specify a directory for the tempoary CLI LOAD files. Use this environment variable if you are loading into column-organized tables and if there is not enough free space in the /db2/<SID> file system. The directory specified by DB6LOAD_TEMP_FILES_PATH must exist on the Db2 server and be writable for the Db2 instance-owning user (for example, db2<dbsid>).

Prerequisites

On SAP kernel version 7.20 - 7.21 and 7.41 - 7.42, an R3load version is needed with the following patch text: DB6: “R3load creates large temporary files loading into BLU tables”.

More Information

SAP Note 2115034

154 P U B L I C


Appendix


11.4 SAP BW Tables Considered for Db2 BLU Acceleration: Overview

Get an overview of the SAP BW tables that can be converted to a column-organized table layout.

The table lists the most relevant tables of each SAP BW object and whether they can be column-organized. For some SAP BW objects such as InfoObjects, only some of their tables can be converted to column-organized, while the rest of the tables remain row-organized. For other SAP BW objects, you can control with RSADMIN parameters whether tables are converted to row-organized or to column-organized. Note that this is intended, as not every table conversion to column-organized really results in a performance benefit. The defaults and possible settings listed here are considered by program DB6CONV as of version 6.30 when you convert tables from row-organized to column-organized and vice versa.

List of Tables of SAP BW Objects: Candidates for BLU Acceleration

SAP BW Object Object Type Table Name Can Be Column-Organized

Comments

DataStore object Standard Only if no secondary indexes exist

/.../A...00 Yes

/.../B... No

/.../A...40 No

Write-optimized /.../A...00 Yes Only if no secondary indexes exist

Direct Update /.../A...00 No

InfoCube Standard or real-time

/.../F... Yes F fact table

/.../E... Yes E fact table

/.../D... Yes Dimension tables

InfoCube for SAP APO

/.../9F... No

/.../9E... No

/.../9D... No

Flat /.../F... Yes F fact table

Flat InfoCubes are always column-organized.

/.../D... Yes Package dimension table

InfoObject -

/.../S... Yes


SAP BW Object Object Type Table Name Can Be Column-Organized

Comments

/.../P... Yes As of Db2 10.5 FP5SAP2, the table is column-organized per default.

/.../Q... Yes As of Db2 10.5 FP5SAP2, the table is column-organized per default.

/.../X... Yes

/.../Y... Yes

/.../T... Yes As of Db2 10.5 FP5SAP2, the table is column-organized per default.

Other No

PSA -

/BIC/B... Yes

Other No

11.5 Table Layout Options for SAP BW Objects

The following sections describe the table layout for each SAP BW object:

● The basic table layout and the indexes that are created on these tables● Whether multidimensional clustering (MDC) is supported and how it is applied● Whether column-organized tables are supported

11.5.1 Table Layout Options for SAP BW Objects: Overview

Get an overview of the available table layout options for SAP BW objects.

SAP BW Object Basic Layout Multidimensional Clustering (MDC)

Column-Organized Tables

Default Table Layout

Persistent staging area (PSA)

Yes Yes Yes MDC

156 P U B L I C


Appendix

SAP BW Object Basic Layout Multidimensional Clustering (MDC)

Column-Organized Tables

Default Table Layout

Standard DataStore objects

Yes Yes Yes MDC for the activation queue and change log tables, basic layout for the active table

DataStore objects for direct update

Yes Yes No Basic layout

Write-optimized DataStore objects

Yes Yes Yes MDC

Standard and real-time InfoCubes

Yes, with index clustering

Yes Yes MDC on package dimension column of F fact tables, index clustering on E fact tables

Aggregates for standard InfoCubes

Yes, with index clustering

Yes Yes MDC on package dimension column of F fact tables, index clustering on E fact tables (inherited from InfoCube)

Flat InfoCubes No No Yes Column-organized

BW temporary tables Yes No Yes Basic layout

InfoObjects (Characteristics, time characteristics, units)

Yes No Yes Basic layout

Recommendations

We recommend BLU Acceleration (column-organized tables) as the best option, and MDC as second choice if BLU Acceleration is not technically possible.

For SAP BW objects that are a combination of InfoProviders (such as InfoSets, which are joins of InfoProviders), we recommend BLU Acceleration with a homogeneous table layout. That is, all its component parts should have column-organized tables.


11.5.2 Table Layout Options for Persistent Staging Areas (PSA)

Learn more about the table layout options for PSA tables, including the basic table layout, multidimensional clustering, and column-organized tables.

A PSA table has all fields of the respective transfer structure and a technical key that consists of the following fields:

● Request ID● Data package ID● Record number

The technical key addresses a single row uniquely and is the primary key. A request can contain multiple data packages, each of which has a configurable maximum number of records.

A PSA table can reside in a partitioned tablespace. The distribution key is always the record number field.

Basic Table Layout and Indexing

Without MDC, a PSA table has only the primary key covering the request ID, the data package ID, and the record number.

Example: Basic Table Layout and Indexing of a PSA Table


MDC is the default table layout for PSA tables.

The only allowed MDC dimension for PSA tables is the request ID field. The reason for this is that all database operations on PSA tables are performed by request. Therefore, organizing the data in the PSA table by request ID results in better performance of the database operations. With MDC, records that belong to the same request are stored in the same blocks (extents), which speeds up the deletion of a request, for example.

Additional space consumption for MDC is minimal because MDC is performed on a single field and it is likely that a request has more records than can be stored in a single block (extent). With MDC, the lock size of a PSA table is set to BLOCKINSERT to reduce locking during INSERT and to speed up data loading into the PSA.

158 P U B L I C


Appendix

The following figure shows the index settings and the possible MDC settings of a PSA table:

Example: MDC of a PSA Table

BLU Acceleration

You can use column-organized tables for PSAs. The unique indexes (primary keys) of row-organized tables become unique constraints on column-organized tables; non-unique indexes are not necessary with BLU Acceleration.

Example: Layout of a Column-Organized PSA Table

By default, column-organized tables are not created for PSAs. To create PSAs with column-organized tables, set the RSADMIN parameter DB6_PSA_USE_CDE to YES. For more information, see Creating Column-Organized Tables for Master Data and PSAs [page 28].


11.5.3 Table Layout Options for Standard DataStore Objects

Learn more about the possible table layouts for standard DataStore objects, which includes the basic table layout, multidimensional clustering, and column-organized tables.

A standard DataStore object consists of the following database tables:

● Activation queue table● Change log table● Active table

Data is loaded into the activation queue table using the data transfer process in SAP BW. During data activation for DataStore objects, the data is transferred from the activation queue to the active table of the DataStore object, where it can be used for further processing in the data warehouse of SAP BW. The changes to the active table are stored in the change log table.

The structure of the activation queue table is similar to a PSA table. The activation queue table has fields of all InfoObjects and a technical key that consists of three fields, that is, request SID, data package ID, and record number. The technical key is the primary key. All operations on the activation queue table are performed by request. An activation queue table can reside in a partitioned tablespace. The distribution key is always the record number field.

The change log table has the same structure as the activation queue table except for the request ID field, which replaces the request SID field. The technical or primary key consists of three fields, that is, request ID, data package ID, and record number. A change log table can reside in a partitioned tablespace. The distribution key is always the record number field.

The active table contains the fields for all InfoObjects. The primary key consists of the InfoObject fields that were selected as key fields by the user before the DataStore object was activated. An active table can reside in a partitioned tablespace. The distribution key always contains all user-selected key fields.


Without MDC, an activation queue has only a primary key defined by the technical key, that is, request SID, data package ID, and record number.

160 P U B L I C


Appendix

Example: Basic Table Layout and Indexing of the Activation Queue Table of a DataStore Object

Without MDC, a change log table has only a primary key defined by the technical key, that is, request ID, data package ID, and record number.

Example: Basic Table Layout and Indexing of the Change Log Table of a DataStore Object

Without MDC, an active table has only a primary key defined by InfoObjects.

Example: Basic Table Layout and Indexing of the Active Table of a DataStore Object



MDC is the default table layout for the activation queue table and the change log table of DataStore objects. MDC is also available as an option for active tables. You'll need to select MDC explicitly as the clustering option in the Data Warehousing Workbench when you create DataStore objects.

Activation queue tables with MDC have the request SID field as their only MDC dimension, which improves the performance of INSERT, READ, and DELETE operations. You cannot change the MDC dimension. The lock size is set to BLOCKINSERT.

Example: MDC of the Activation Queue Table of a DataStore Object

The change log table has the request ID field as the only MDC dimension for the same reasons as the activation queue table. The lock size is set to ROW because multiple processes can simultaneously write to the same request.

Example: MDC of the Change Log Table of a DataStore Object

162 P U B L I C


Appendix

In active tables, MDC dimensions can only be InfoObject fields that were selected as key fields. The lock size is always set to ROW because multiple activation processes can write concurrently to the same MDC logical cell of the active table.

By default, no secondary indexes are created and no clustering is used for the active table. While you can create additional indexes any time, even if the DataStore object already contains data, you can change the MDC settings only when the DataStore object is empty as described in Setting Up MDC for New Standard InfoCubes and DataStore Objects [page 72]. To change the MDC settings for a DataStore object that contains data, see Reclustering DataStore Objects [page 83].

Example: MDC of the Active Table of a DataStore Object

BLU Acceleration

You can use column-organized active tables for standard DataStore objects. The unique indexes of row-organized active tables become unique constraints on column-organized tables; non-unique indexes are not necessary with BLU Acceleration.

Example: Table Layout of Column-Organized Active Table of a Standard DataStore Object

Active tables of DataStore objects can be converted to column-organized only if no secondary indexes exist. Note that all other tables of standard DataStore objects remain row-organized.


Related Information

Setting the Default Format of SAP BW Objects to BLU Acceleration [page 28]Creating SAP BW Objects for BLU Acceleration Automatically or Manually [page 30]

11.5.4 Table Layout Options for DataStore Objects for Direct Update

A DataStore object for direct update consists only of the active table. The basic layout of active tables of DataStore objects for direct update is exactly the same as for active tables of standard DataStore objects.

For DataStore objects for direct update, MDC is supported, but BLU Acceleration is not.

Related Information

Changing the Default MDC Dimensions for New or Empty DataStore Objects [page 77]

11.5.5 Table Layout Options for Write-Optimized DataStore Objects

For write-optimized DataStore objects, the basic table layout, MDC, and BLU Acceleration are supported.

A write-optimized DataStore object consists of a single table similar to a PSA table that contains the fields for all InfoObjects and a technical key with the following fields:

● Request ID● Data package ID● Record number


A secondary index, which can either be unique or non-unique, is created for the user-selected key fields. Another non-unique secondary index is created on the technical key fields.

164 P U B L I C


Appendix

Basic Table Layout and Indexing of the Write-Optimized DataStore Object STORE

The table can reside in a partitioned tablespace. The distribution key always contains all user-selected key fields.


MDC is the default table layout for write-optimized DataStore objects.

With MDC, tables have the request ID field as their only MDC dimension, which improves the database performance of INSERT and DELETE operations. The lock size is set to BLOCKINSERT.

You cannot change the MDC dimensions for the write-optimized DataStore object.

MDC of the Write-Optimized DataStore Object STORE


BLU Acceleration

You can use column-organized tables for write-optimized DataStore objects. The unique indexes of row-organized tables become unique constraints on column-organized tables; non-unique indexes are not necessary with BLU Acceleration.

Example: Table Layout of Column-Organized Write-Optimized DataStore Object Table

Active tables of write-optimized DataStore objects can be converted to column-organized only if no secondary indexes exist.

Related Information


11.5.6 Table Layout Options for Standard and Real-Time InfoCubes

For standard and real-time InfoCubes, the basic table layout, MDC, and BLU Acceleration are supported as table layouts.

Standard InfoCubes and real-time InfoCubes consist of the following tables:

● Dimension tables● F fact table● E fact table

A dimension table contains a dimension ID field and SID fields for all InfoObjects that are assigned to the dimension. The primary key contains only the dimension ID field. A dimension table cannot reside in a partitioned tablespace and therefore has no distribution key. No clustering is used for dimension tables.

166 P U B L I C


Appendix

The F fact table contains dimension ID fields for all dimensions and fields for all key figures. A primary key is not created for this table. Secondary indexes are created on each dimension ID field except for the unit dimension. Line item dimensions contain a field with SID values for the line item characteristic in the F fact table instead of a dimension ID field. The F fact table can reside in a partitioned tablespace and the distribution key contains all dimension ID fields except for the package dimension ID field.

Data is loaded and deleted by request into and from the F fact table. Reading data is not performed by request, and queries are usually restricted on dimension ID fields. Each of these requests has its own request ID, which is included in the fact table in the package dimension. This makes it possible to pay particular attention to individual requests. One advantage of the request ID concept is that you can subsequently delete complete requests from the InfoCube. However, the request ID concept can also cause the same data record (where all characteristics are the same except the request ID) to appear more than once in the fact table. This unnecessarily increases the volume of data and affects system performance when you analyze data, since each time you execute a query, the system has to perform aggregation using the request ID.

E fact tables contain compressed fact table data resulting from InfoCube compression. InfoCube compression compresses the data of the F fact table using the package dimension ID field. The compressed data is inserted in the E fact table and deleted from the F fact table. For the data in the E fact table, the relation to the request ID is lost.

Real-time InfoCubes differ from standard InfoCubes in their ability to support parallel write accesses. Standard InfoCubes are technically optimized for read accesses to the disadvantage of write accesses.


Index clustering can be used for the F fact tables and E fact tables of standard InfoCubes. However, MDC is the default clustering option for F fact tables of standard InfoCubes.

If you decide on the basic table layout, you can use index clustering for the F fact table to improve query performance. To improve performance of queries that contain restrictions on the time dimension (which is in general the case for all queries), the clustering index is the secondary index on the time dimension ID field.

If the InfoCube does not contain any time characteristics, the clustering index is the secondary index on the package dimension ID field. In this rare case, index clustering improves only the performance of DELETE operations while it has no influence on the query performance.


In the following example, an InfoCube contains three userdefined dimensions and two cumulative key figures. The following figure shows the clustering settings for F fact tables and E fact tables when you are using index clustering:

Example: Index Clustering of an InfoCube

The figure below shows the clustering settings of dimension tables with default settings:

Example: Basic Table Layout of Dimension Tables

168 P U B L I C


Appendix

Dimension tables have a secondary non-unique index over the characteristic SIDs. If the data load property DIMID One-to-One is chosen, they have a secondary unique index over the characteristic SIDs:

Example: Basic Table Layout of Dimension Tables with Data Load Property "DIMIDs One-to-One"


MDC is the default table layout for F fact tables of standard InfoCubes, which speeds up data INSERT and DELETE operations and further improves query performance.

The default MDC dimension is the package dimension key for F fact tables, which improves the performance of InfoCube compression. Additional MDC dimensions can be the time dimension ID field and all dimension ID fields of the userdefined dimensions.

Instead of the time dimension ID field, you can choose the time characteristic Calendar Month (0CALMONTH) or Fiscal Period (0FISCPER) as MDC dimensions. An additional field is added to the E and F fact tables that contain the SID values for this characteristic and an MDC block index is created on this field.

Starting with the following support packages, you can also choose the time characteristic Calendar Week (0CALWEEK) as an MDC dimension:

● SAP BW 7.0 SP 36● SAP BW 7.01 SP 19● SAP BW 7.02 SP 19● SAP BW 7.11 SP 16● SAP BW 7.3 SP 15● SAP BW 7.31 SP 18● SAP BW 7.40 SP 15● SAP BW 7.50 SP 3 and higher releases

If you select a dimension as an MDC dimension, the secondary index on the dimension ID field is not created. Instead, a database-internal block index is created that does not appear in the ABAP Dictionary. If you select MDC, the lock size of the table is BLOCKINSERT.

The E fact table has exactly the same fields as the F fact table and also doesn't have a primary key. Instead, a unique compound index is created that contains all dimension ID fields. This index is called P index and is the clustering index if index clustering is used. The distribution key is the same as for the F fact table. Data is inserted into the E fact table only with InfoCube compression. The relation to a request is lost, and you can only


perform selective deletion. MDC is applied to the E fact table in the same way as to the F fact table except for the package dimension ID field that is not added to the MDC dimensions.

The following figure shows the clustering settings for F fact tables and E fact tables when you are using MDC:

Example: MDC of an InfoCube

In the above figure, the InfoCube contains three userdefined dimensions and two cumulative key figures. MDC has been defined on the time characteristic 0CALMONTH and on the package dimension ID field. Only the fact tables are shown.

For more information about choosing the right MDC dimensions and about how to define MDC dimensions for a standard InfoCube, see Setting Up MDC for New Standard InfoCubes and DataStore Objects [page 72].

BLU Acceleration

You can use column-organized tables for fact and dimension tables of cumulative and non-cumulative InfoCubes. The InfoCubes can be part of MultiProviders. As of SAP BW 7.3, semantically partitioned InfoCubes are also supported.

With column-organized InfoCubes, index management has become easier. The unique indexes of row-organized tables become unique constraints on column-organized tables; non-unique indexes are not necessary with BLU Acceleration. For fact tables, this means that there are no secondary indexes defined. The only constraint is the unique P index on the E fact table, which you never need to drop.

170 P U B L I C


Appendix

Example: Column-Organized InfoCube - F and E Fact Tables

In column-organized dimension tables with standard data load properties, there is only the primary key constraint on the dimension ID, and an additional unique constraint over the dimension ID and the characteristics surrogate identifiers (SIDs).

Example: Column-Organized InfoCube - Dimension Table

Column-organized dimension tables have the primary key constraint on the dimension ID and an additional unique constraint over the characteristic SIDs and the dimension ID. If the data load property DIMID One-to-


One is chosen, column-organized dimension tables have the primary key constraint on the dimension ID and an additional unique constraint only over the characteristic SIDs:

Example: Column-Organized InfoCube with Data Load Property "DIMIDs One-to-One" - Dimension Table

Other aspects of index management have also become easier: When you load data into InfoCubes, you can drop fact table indexes before the data load and re-create them after the load. For row-organized InfoCubes with many indexes defined on the fact tables, re-creating fact table indexes might take a long time if the fact table is large. Since column-organized tables need only primary key and unique constraints but not secondary indexes, operations in SAP BW for dropping and re-creating indexes for column-organized tables do not perform any work and are consequently very fast. Therefore, if you included dropping and re-creating fact table indexes in your process chains, there is no need to modify the process chains if you start using column-organized tables.

Checking and repairing indexes remain the same for column-organized tables: SAP BW transaction RSRV provides an option to check and repair the indexes of an InfoCube. You can also run this check for column-organized InfoCubes.

Related Information


11.5.7 Table Layout Options for Aggregates

An aggregate is a copy of its basis InfoCube with the reduction of one or several characteristics, dimensions, or key figures. The key figures are aggregated for the remaining dimensions.

If an aggregate contains an unchanged dimension of the basis InfoCube with the same characteristics, the dimension table of the basis InfoCube is reused by the aggregate rather than a new dimension table being created. The fact tables contain the same dimension IDs for this dimension as the fact tables of the basis InfoCube. If an aggregate contains a reduced dimension of the basis InfoCube, which has fewer characteristics,

172 P U B L I C


Appendix

a new dimension table is created. If the aggregate does not exceed the maximum number of characteristics (16), dimensions of the basis InfoCube are split into a number of line item dimensions by creating a line item dimension in the aggregate for each characteristic.

The fact tables contain the dimension ID fields of the aggregate dimensions and the fields of the aggregate key figures. The layouts of indexes and distribution keys are the same as for the fact tables of an InfoCube.

The clustering of the aggregate’s fact tables is inherited from the clustering of the basis InfoCube. The default for InfoCubes is MDC.


If index clustering is used, the clustering index for the F fact table is the secondary index on the time dimension ID field or, if the time dimension does not exist, the secondary index on the request dimension ID field. The clustering index for the E fact table is the P index.


If the basis InfoCube uses MDC (the default), a dimension ID field in the aggregate’s fact table is an MDC dimension if the dimension is unchanged and points to a dimension of the basis InfoCube that has been defined as an MDC dimension. If MDC is defined on a time characteristic, the aggregate’s fact tables are only clustered on that characteristic if the aggregate contains it. If the aggregate does not contain any unchanged MDC dimensions, index clustering is used instead. This is also the case if MDC has been disabled for the aggregate in the aggregate maintenance screen by selecting Change Partitioning from the Aggregate menu or the context menu of the aggregate.

Column-Organized Tables (BLU Acceleration)

With BLU Acceleration, creating and maintaining aggregates for InfoCubes usually not required because analytic processing is faster. If aggregates are required, they have the same table format as their corresponding InfoCubes, that is, aggregates of column-organized InfoCubes are column-organized.


11.5.8 Table Layout Options for Flat InfoCubes

The tables of flat InfoCubes are always created as column-organized tables.

BLU Acceleration

To optimize reporting performance on flat InfoCubes, the InfoObjects that occur in the InfoCubes should also be implemented with column-organized tables.

A flat InfoCube consists of the following tables:

● F fact table● Package dimension table

As opposed to standard InfoCubes, flat InfoCubes do not have any further dimension tables or E fact tables. In the SAP Data Warehousing Workbench (transaction RSA1), InfoCube dimensions are still visible and are maintained, that is, the InfoObjects of an InfoCube are added to the dimensions. However, they are not materialized as dimension tables in the database.

The F fact table contains the package dimension key column, columns for the SIDs of the characteristics, and key figure columns. The F fact table of flat InfoCubes has no primary key or unique constraint and no secondary indexes. Therefore, there is no overhead for index management.

The F fact table can reside in a partitioned tablespace and the distribution key contains the SID fields of the first InfoObject in all logical dimensions, except for the package dimension.

Flat InfoCube: Column-Organized F Fact Table

174 P U B L I C


Appendix

The column-organized package dimension tables have a primary key constraint on the dimension ID and an additional unique constraint over the characteristic SIDs:

Flat InfoCube: Column-Organized Package Dimension Table

Related Information

Creating Flat InfoCubes (As of SAP BW 7.4) [page 30]SAP Business Warehouse [page 9]

11.5.9 Table Layout Options for InfoObjectsTable layout options for InfoObjects include the basic table layout, multidimensional clustering, and BLU Acceleration.

Relevant tables for InfoObjects such as characteristics, time characteristics, or units include:

● Tables for the surrogate identifier (SID tables)● Time-independent attribute SID tables (X tables)● Time-dependent attribute SID tables (Y tables)● Time-independent attribute tables (P tables)● Time-dependent attribute tables (Q tables)● Text tables

The existence of X and Y tables depends on whether the InfoObject has navigation attributes. Characteristics typically have navigation attributes. In addition to the tables mentioned above, InfoObjects can have hierarchy tables (which are always row-organized).

Tables for InfoObjects cannot reside in a partitioned tablespace and therefore have no distribution keys.


In SID tables, the SID is an integer ID for the InfoObject, which is used as a foreign key for the InfoObject in the dimension tables of InfoCubes. All SID tables also have a character value field for the InfoObject, which


corresponds to the customerspecific description of the InfoObject in the SAP BW system (such as a material number). In addition, the SID table contains multiple flags used for updates and administration.

In the basic layout and indexing of an SID table, the character value field of the InfoObject is the primary key. In addition, the SID table has a unique index defined by the SID.

Example: Basic Table Layout of SID Tables

The X table of InfoObjects has a primary key defined by the SID and the object version (OBJVERS) fields and a secondary non-unique index defined by the object version and the character value.

Example: Basic Table Layout of X Tables

The Y tables for time-dependent InfoObject attributes have two indexes: the primary key on the fields for the SID, the object version, and the to-date, and an additional non-unique index on the fields OBJVERS, DATETO, DATEFROM, and the character value of the InfoObject (in this example, VC_PROD1).

176 P U B L I C


Appendix

Example: Basic Table Layout of Y Tables

The P tables for time-independent InfoObject attributes have a primary key defined by the character value of the InfoObject and the object version (OBJVERS) field.

Example: Basic Table Layout of P Tables

The Q tables for time-dependent InfoObject attributes have a primary key defined by the character value of the InfoObject and the fields OBJVERS and DATETO.


Example: Basic Table Layout of Q Tables

The text tables of InfoObjects have a primary key defined by the character value of the InfoObject and by the language key (LANGU field).

Example: Basic Table Layout of Text Tables

If you need more (non-unique) indexes for InfoObject tables, you'll need to define them manually.

BLU Acceleration

You can use column-organized SID tables (/BI*/S*) and column-organized X, Y, P and Q tables for InfoObjects. You can also use column-organized text tables for InfoObjects. This applies to characteristics, time characteristics, and units. These are the tables that frequently occur in SAP BW reporting queries. The hierarchy tables of InfoObjects remain row-organized.

178 P U B L I C


Appendix

NoteThe range of InfoObject tables that can be column-organized was extended with Db2 10.5 FP5SAP2, so that P, Q, and text tables are now also supported. If you converted InfoObjects to column-organized on a lower Db2 level than 10.5 FP5SAP2, then P, Q, and text tables are still row-organized. After you have upgraded to Db2 FP5SAP2 and higher, use the DB6CONV program to convert these tables to column-organized.

The unique indexes of row-organized tables become unique constraints on column-organized tables; non-unique indexes are not necessary with BLU Acceleration.

Example: Table Layout of Column-Organized SID Table

Example: Table Layout of Column-Organized X Table


Example: Table Layout of Column-Organized Y Table

Example: Table Layout of Column-Organized P Table

180 P U B L I C


Appendix

Example: Table Layout of Column-Organized Q Table

Example: Table Layout of Column-Organized Text Table

By default, column-organized tables are not implemented for InfoObjects. To enable BLU Acceleration for InfoObjects, set RSADMIN parameter DB6_IOBJ_USE_CDE to YES. For more information, see Creating Column-Organized Tables for InfoObjects and PSAs [page 28].

RecommendationIf you plan to use column-organized tables for the majority of your InfoCubes and DataStore objects, we recommend that you also use column-organized tables for your InfoObjects. Doing so avoids joins between row-organized and column-organized tables, which require additional processing at the database level.

If performance with column-organized P and Q tables and text tables is not as expected, you may decide to keep P and Q tables and text tables row-organized. For this purpose, set the RSADMIN parameter DB6_IOBJ_PQT_USE_CDE to NO. For more information, see Changing the Table Layout for P, Q, and Text Tables of New InfoObjects to Row-Organized [page 141].


12 Disclaimer: Links to IBM Documentation

By following links to IBM Documentation you are leaving the SAP product documentation and entering a site that is not hosted by SAP. By using the link, YOU AGREE that unless expressly stated otherwise in your agreements with SAP you are about to access an external webpage which is not part of SAP’s offering:

(i) the content of the linked-to site and any further external site is not product documentation and you may not infer any product documentation claims against SAP based on this information;

(ii) the fact that SAP provides links to external sites does not imply that SAP agrees or disagrees with the contents and information provided on such sites. SAP does not guarantee the correctness of the information provided.

(III) SAP DOES NOT GIVE ANY REPRESENTATION REGARDING THE QUALITY, SAFETY, SUITABILITY, ACCURACY OR RELIABILITY OF ANY EXTERNAL WEBPAGE OR ANY OF INFORMATION, CONTENT AND MATERIALS PROVIDED THEREON;

(IV) YOU VISIT THOSE EXTERNAL WEBPAGES ENTIRELY AT YOUR OWN RISK. SAP SHALL NOT BE DIRECTLY OR INDIRECTLY RESPONSIBLE OR LIABLE FOR ANY DAMAGE OR LOSS CAUSED OR ALLEGED TO BE CAUSED BY OR IN CONNECTION WITH YOUR USE OF OR RELIANCE ON ANY CONTENT, GOODS OR SERVICES AVAILABLE ON OR THROUGH ANY SUCH LINKED WEBPAGE.

182 P U B L I C


Disclaimer: Links to IBM Documentation

Important Disclaimers and Legal Information

HyperlinksSome links are classified by an icon and/or a mouseover text. These links provide additional information.About the icons:

● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your agreements with SAP) to this:

● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any

damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information.

Beta and Other Experimental FeaturesExperimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use the experimental features in a live operating environment or with data that has not been sufficiently backed up.The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example CodeAny software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Gender-Related LanguageWe try not to use genderspecific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.

SAP Business Warehouse on IBM Db2 10.5 and Higher for Linux, UNIX, and Windows: Administration TasksImportant Disclaimers and Legal Information P U B L I C 183

go.sap.com/registration/contact.html

© 2018 SAP SE or an SAP affiliate company. All rights reserved.No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. The information contained herein may be changed without prior notice.Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary.These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.Please see https://www.sap.com/about/legal/trademark.html for additional trademark information and notices.

https://go.sap.com/registration/contact.html

https://go.sap.com/registration/contact.html

https://www.sap.com/about/legal/trademark.html

SAP Business Warehouse on IBM Db2 10.5 and Higher for ...€¦ · Hardware and Software...

Documents

Transcript of SAP Business Warehouse on IBM Db2 10.5 and Higher for ...€¦ · Hardware and Software...