Redbook Building and Scaling SAP Business Information Warehouses On DB2 UDB ESE sg247094 PDF

Front cover
Building and Scaling

SAP Business Information
Warehouse
house on DB2 UDB ESE
DB2 enables best scalability, and high
performance for SAP BW
DB2 data partitioning and

parallelism - key advantages
Configuration examples
to start with and grow
Chuck Ballard
Andreas Christian
Theodor Kuebler
Rodrigo Schiavon
ibm.com/redbooks
International Technical Support Organization
Building and Scaling SAP Business Information

Warehouse on DB2 UDB ESE
June 2004
SG24-7094-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page ix.
First Edition (June 2004)
This edition applies to Version 3.5 of SAP Business Information Warehouse, and Version 8.1 of
DB2 Universal Databse Enterprise Server Edition.
© Copyright International Business Machines Corporation 2004. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Management summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Structure of the redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapter 1. SAP Business Information Warehouse (BW) . . . . . . . . . . . . . . . 7

1.1 Data warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 Informational databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 Data warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 SAP BW positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 SAP business solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 SAP NetWeaver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 SAP Business Intelligence and SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 SAP BW customer scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.7 Requirement for scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 2. SAP BW technical overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1 SAP BW information model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Dataflow in SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Information access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Extended star schema (InfoCubes). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Dataload into InfoCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7 Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7.1 Aggregate example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7.2 Maintaining aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.8 Compression of requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.9 Operational data store (ODS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.10 The SAP BW functional components . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.11 SAP BW business content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 3. DB2 UDB ESE technical overview. . . . . . . . . . . . . . . . . . . . . . . 43
© Copyright IBM Corp. 2004. All rights reserved. iii

3.1 The architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Functions and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.1 Database objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.2 Concurrency, locking and isolation levels . . . . . . . . . . . . . . . . . . . . . 53
3.2.3 Parallel processing and partitioning . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.4 Cost-based optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.5 Join methods for distributed tables . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.6 Static and dynamic SQL statements . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.7 DB2 64-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3 DB2 monitoring and tuning tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4 DB2 Version 8: a few highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.4.1 Catalog caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.4.2 RUNSTATS enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.4.3 Multi-dimensional clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.4.4 Concurrency features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4.5 High availability features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.4.6 Connection concentrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.4.7 Merge statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.4.8 Multi-FixPak install for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Chapter 4. Building SAP BW on DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.1 Value of building SAP BW on DB2 UDB ESE . . . . . . . . . . . . . . . . . . . . . . 82
4.1.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.2 High performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1.3 Ease of administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2 Business advantage: the value proposition. . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.1 Low TCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2 Reduced sizing risk and cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.3 SAP BW on DB2: value details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.1 Architecture and features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.2 Database layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.3.3 Parallel processing on multiple database partitions . . . . . . . . . . . . . 93
4.3.4 Intra-partition parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.3.5 SAP BW query processing on DB2 . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.3.6 Use of distribution statistics for query optimization . . . . . . . . . . . . . 105
4.3.7 New features of the DBA Cockpit 6.40 . . . . . . . . . . . . . . . . . . . . . . 106
Chapter 5. Project test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.1 Hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.2 Software configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2.1 Operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.2.2 Database management system . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.2.3 SAP Business Information Warehouse . . . . . . . . . . . . . . . . . . . . . . 114
iv SAP BW and DB2

5.2.4 Front-end software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.3 Installation, scaling, and performance test scenarios . . . . . . . . . . . . . . . 115
5.4 SAP BW sample application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Chapter 6. Implementing SAP BW on DB2 . . . . . . . . . . . . . . . . . . . . . . . . 121

6.1 Sizing SAP BW on DB2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.2 Implementation approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.2.1 The Implementation Assistant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.3 Preinstallation activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.3.1 Component considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.4 Installation planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.4.1 The SAP Installation Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.4.2 The installation checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.4.3 System planning and preparation . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.5 Installation procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.5.1 Installing the IBM DB2 Universal Database . . . . . . . . . . . . . . . . . . 143
6.5.2 Installing the Central Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.5.3 Installing the SAP Database Instance . . . . . . . . . . . . . . . . . . . . . . . 157
6.6 Post-installation activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.6.1 Additional post-installation activities . . . . . . . . . . . . . . . . . . . . . . . . 164
6.7 Business Information Warehouse definitions . . . . . . . . . . . . . . . . . . . . . 172
6.7.1 BW general settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.7.2 Installing the SAP Business Content Add-on . . . . . . . . . . . . . . . . . 173
6.7.3 Installing an additional Dialog Instance. . . . . . . . . . . . . . . . . . . . . . 179
6.8 HACMP for high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.8.1 High availability and fault tolerance. . . . . . . . . . . . . . . . . . . . . . . . . 186
6.8.2 HACMP clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Chapter 7. Administration of SAP BW. . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

7.1 Role-based administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
7.2 DB2 UDB administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
7.3 Periodic activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
7.3.1 Storage management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.3.2 Tablespace and container administration . . . . . . . . . . . . . . . . . . . . 204
7.3.3 The optimizer and runstats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.3.4 Tablespace reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
7.4 Backup and recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
7.4.1 Defining a backup/recovery strategy and policy . . . . . . . . . . . . . . . 217
7.4.2 Managing the DB2 UDB logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
7.4.3 Performing DB2 UDB backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.4.4 Database recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
7.5 Authorization to administer SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
7.6 Archiving SAP BW data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Contents v
Chapter 8. SAP BW performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
8.1 The approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.2 Health check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.2.1 SAP Notes related to performance and system configuration . . . . 250
8.2.2 How to keep DB2 database statistics current with SAP BW . . . . . . 254
8.2.3 How to control DB2 log space consumption with SAP BW . . . . . . . 254
8.2.4 Recommended configuration parameters . . . . . . . . . . . . . . . . . . . . 256
8.3 Performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
8.3.1 General SAP BW tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
8.3.2 Tuning DB2 UDB ESE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
8.4 Performance monitoring of SAP BW on DB2 UDB . . . . . . . . . . . . . . . . . 268
8.4.1 Performance bottlenecks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
8.4.2 Proactive monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
8.4.3 Problem analysis and resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Chapter 9. Scaling out the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

9.1 Options for installing and scaling the database . . . . . . . . . . . . . . . . . . . . 298
9.2 Scaling steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
9.2.1 Partitioning the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
9.2.2 Relocating database containers . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
9.2.3 Moving database partitions to another server . . . . . . . . . . . . . . . . . 312
9.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Chapter 10. Scalability factors of SAP BW on DB2 UDB ESE. . . . . . . . . 317

10.1 DB2 scalability studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
10.2 Performance study for SAP BW on DB2 UDB EEE . . . . . . . . . . . . . . . 319
10.2.1 Hardware environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
10.2.2 Scalability of single and multi-user SAP BW queries . . . . . . . . . . 320
10.2.3 Scalability of dataload from PSA into InfoCube . . . . . . . . . . . . . . 324
10.2.4 Summary of scalability test results . . . . . . . . . . . . . . . . . . . . . . . . 325
10.3 SAP Business Warehouse on DB2 UDB Sun Cluster . . . . . . . . . . . . . . 326
10.3.1 Hardware and software setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
10.3.2 Description of tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
10.3.3 Results of scalability tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
10.4 Performance of partitioned and unpartitioned database . . . . . . . . . . . . 330
Appendix A. SQL analysis with SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . 333
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
vi SAP BW and DB2

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Contents vii
viii SAP BW and DB2
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright IBM Corp. 2004. All rights reserved. ix

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® HACMP™ Redbooks™

Database 2™ ibm.com® Redbooks (logo)™
DB2 Universal Database™ Informix® Redbooks (logo) ™
DB2® IBM® Tivoli®
DRDA® IMS™ TotalStorage®
Enterprise Storage Server® MQSeries® WebSphere®
eServer™ OS/390® xSeries®
™ pSeries® z/OS®
^™ Red Brick™ zSeries®
The following terms are trademarks of other companies:
Intel and Intel Inside (logos) are trademarks of Intel Corporation in the United States, other countries, or
both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, and service names may be trademarks or service marks of others.
x SAP BW and DB2

Preface
The primary objective of this IBM Redbook is to demonstrate and document the
process of:
򐂰 Installing
򐂰 Administering
򐂰 Tuning
򐂰 Scaling
SAP Business Information Warehouse with DB2® Universal Database™ (UDB)

Enterprise Server Edition (ESE).
Another important goal of this book is to familiarize you with the architecture and
functionality of SAP BW and DB2 UDB ESE. In particular, we explain specific
functions of DB2 UDB ESE that are utilized by SAP BW to deliver high-end
performance. We also provide details about the SAP BW graphical front-end,
and other important functions that are developed as part of the SAP-IBM
cooperation.
We have a particular focus on scalability. Scaling up your system means to

attach additional servers to handle increasing data volumes and growing
numbers of users. As part of this redbook project, we installed SAP BW 3.5 with
DB2 UDB ESE V8 on a single database sever and then scaled up the database
system by attaching a second machine.
Measuring scalability factors that are achieved with SAP BW on DB2 was out of
scope for this project. Therefore, we refer to two studies, which show that SAP
BW with DB2 scales linear, or close to linear, in the area of SAP BW queries and
data load.
A high level overview of the structure and contents of the redbook is presented in
the “Introduction” on page 1.
SAP acknowledgement: We want to express our appreciation to SAP AG

and their employees for their help and cooperation in the writing of this redbook.
In some sections we have used graphics and text from SAP publicly available
materials, and have made every effort to accurately represent the SAP products
and solutions. We thank SAP AG for their consent to use these materials.
There is a significant amount of information in this redbook, with which you

should become familiar. Are you ready to begin?
© Copyright IBM Corp. 2004. All rights reserved. xi

The team that wrote this redbook
This redbook was produced by a team of specialists from around the world,
representing IBM® and IBM Business Partners. The team primarily worked at the
International Technical Support Organization location in San Jose, California,
and are depicted below:
Left to right: Chuck Ballard, Rodrigo Schiavon, Andreas Christian, Theo Kuebler.
The following are brief biographical descriptions of the team members:
Chuck Ballard is a Project Leader at the International Technical Support

Organization, in San Jose, California. He has over 35 years experience, holding
positions in the areas of Product Engineering, Sales, Marketing, Technical
Support, and Management. His expertise is primarily in the areas of database,
data management, data warehousing, business intelligence, and process
re-engineering. He has written extensively on these subjects, taught classes, and
presented at conferences and seminars worldwide. Chuck has both a Bachelors
degree and a Masters degree in Industrial Engineering from Purdue University.
Andreas Christian works at the SAP DB2 UDB Development / Porting Center in
Walldorf Germany. He provides technical support, consultancy, and knowledge
transfer, in the area of SAP BW/DB2 UDB for customers, consultants, IBM
partners, and IBM marketing and pre-sales. He started to work for IBM in 1999
as a member of the IBM SAP BW/DB2 UDB porting team. In addition to his
xii SAP BW and DB2

development activities, he has performed many SAP BW/DB2 UDB installations
and upgrades, and helped customers to migrate their SAP BW systems to DB2
UDB ESE. In 2002, he investigated DB2 scalability with SAP BW. The results of
this study validate DB2’s unique scalability across multiple database servers and
were published through IBM/SAP.
Theodor H. Kuebler is a consultant and trainer for SAP and Data Management
products. He is founder of the Logos Informations Syteme (LIS) AG in
Switzerland (www.lis-ag.ch), an IBM enabled Education Center for IBM Software
(ECIS), and an IBM Business Partner, providing classroom and onsite courses in
Data Management, Tivoli®, and WebSphere®. He has 12 years experience in
implementation and tuning of SAP products on database management systems,
such as DB2 UDB, Adabas-D, and Oracle, and on different platforms. He
teaches SAP Basis courses for Z/OS and DB2, worldwide.
Rodrigo A. Schiavon is an SAP consultant and works in the outsourcing area at

IBM Brazil, with 6 years experience in implementation and tuning of SAP
products. He is an SAP certified consultant in R/3 and BW systems.
Additional contributors
Assistance and cooperation was also received from other contributors and
organizations, and we recognize them in this section:
David Bellion is a technical director at Oserve Ltd., an IBM Business Partner in

London, England. We give a special thanks to David for his advice and content,
based on many years experience with SAP product implementations.
From IBM locations worldwide:

Bernd Beyrodt, DB2/Informix® SAP Technical Presales EMEA, Boeblingen,
Germany
Brigitte Blaeser, DM Development (SAP DB2 UDB Development / Porting
Center), Walldorf, Germany
Karl Heinz Engler, Manager, SAP DB2 UDB Development / Porting Center,
Boeblingen, Germany
Thomas Fiebig, mySAP BI on DB2 UDB, Business Partner Support, and
Development, Boeblingen, Germany
Karl Fleckenstein, DM Development, SAP DB2 UDB Development / Porting
Center, Walldorf, Germany
Dan Graham, Worldwide BI Sales Support, Southbury, Connecticut
Wladimir Lanin, DM Development, SAP DB2 UDB Development / Porting Center,
Walldorf, Germany
Preface xiii
Martin Mezger, IBM DB2 Project at SAP, SAP Global Support, Technology
Infrastructures and Enablement, Boeblingen, Germany
Dirk Nakott, DM Development, SAP DB2 UDB Development / Porting Center,
Boeblingen, Germany
Steve Rees, Manager, DB2 Performance and Advanced Technology, Markham,
ON, Canada
Jens Seifert, DM Development, SAP DB2 UDB Development / Porting Center,
Boeblingen, Germany
Volker Susok, SAP Technology Alliance Manager, Boeblingen, Germany
Robin Van Boeschoten, DB2 Performance and Advanced Technology,
Markham, ON, Canada
Siegfried Wurst, DM Development, SAP DB2 UDB Development / Porting
Center, Boeblingen, Germany
From SAP AG, in Walldorf, Germany:

Bernhard Woerner, SAP Development Manager
Torsten Ziegler, SAP DB2 Development Manager
Klaus Werner, SAP BW Regional Implementation Group
From the ITSO, San Jose Center:

Mary Comianos, Operations and Communications
Yvonne Lyon, Technical Editor
Deanna Polm, Residency Administration
Emma Jacobs, Graphics Designer
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
xiv SAP BW and DB2

Comments welcome
Your comments are important to us!
We want our Redbooks™ to be as helpful as possible. Send us your comments

about this or other Redbooks in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an Internet note to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. QXXE Building 80-E2
650 Harry Road
San Jose, California 95120-6099
Preface xv
xvi SAP BW and DB2
Introduction
The purpose of this redbook is to demonstrate the processes of implementing

and scaling SAP Business Information Warehouse (BW) on IBM DB2 Universal
Database (UDB) Enterprise Server Edition (ESE) and to show the advantages of
using this product set. The topics discussed in this redbook are important
because:
򐂰 There is a dramatic increase in demand for business intelligence and the
required infrastructure.
򐂰 Data volumes being collected by businesses are growing at an ever
increasing rate. This imposes new requirements to manage, control, and use,
this data for business intelligence purposes.
򐂰 Business users are demanding high performance and fast response times,
even in the face of growing data volumes and an increasing number of users.
򐂰 Businesses are demanding that their decision support data be more current,
and integrated across the enterprise, to provide the information needed to
survive in the competitive business environment of today.
This redbook demonstrates the capabilities of DB2 UDB ESE to meet SAP BW
requirements. Because typical SAP BW systems have fast growing data volumes
and an increasing number of users, scalability will prove to be a critical decision
factor in the selection of a database management system on which to implement
SAP BW.
© Copyright IBM Corp. 2004. All rights reserved. 1

Management summary
SAP BW is positioned as a central business intelligence platform and is one of
the core components of SAP NetWeaver. It supports both the strategic and the
operational decision making process. SAP NetWeaver is a comprehensive
integration and application platform, designed to work with your existing systems
and software. SAP NetWeaver serves as the backbone for the SAP solutions,
enabling companies to realize additional value from existing IT investments. The
products and components that comprise SAP NetWeaver include a portal, an
application server, a Web server, a data warehouse, and an integration platform.
By reducing the need for custom integration, it helps you lower your total cost of
ownership across your entire IT landscape.
IBM DB2 Universal Database Enterprise Server Edition is a parallel and scalable
database management system. It is capable of processing very large data sets,
while delivering high performance. This is enabled by several features that are
specifically designed for data warehouse applications, and the classes of
parallelism that are supported. SAP BW provides a convenient graphical
front-end to administer and monitor DB2. Because of the tight integration of the
two products, and due to DB2 features that simplify the administration and
increase database availability, SAP BW with DB2 is robust and easy to use.
DB2 UDB ESE is currently the only SAP-certified parallel database

management system for SAP BW, which is capable of deploying multiple
database servers. With DB2 UDB ESE you can attach additional database
servers to your existing SAP BW installation as your business grows.
Therefore DB2 meets one of the most important SAP BW requirements, which is
scalability at the database server level. This requirement is important because,
typically, over time, an SAP BW database constantly grows, has more and more
source systems attached, and has an ever increasing number of users. To keep
response times stable in this environment, requires a scalable database system.
SAP BW with DB2 scales linear, or close to linear, in the area of SAP BW queries
and data load. These excellent scalability factors are not self-evident. They result
from the advantages of the DB2 shared-nothing architecture and its approach to
parallel processing.
With this redbook, we show the potential and value of building your SAP BW on
DB2 UDB ESE. The performance and scalability of the combination of DB2 and
SAP BW provides a powerful business intelligence solution that enables you to
start small and grow to a very large environment, while retaining investments in
your existing hardware.
2 SAP BW and DB2

The implementation
In the course of this redbook project we implemented SAP BW3.5 on DB2 UDB
ESE V8. We began with the installation of SAP BW and DB2 on an IBM
pSeries® 650, the high-performance and highly scalable line of UNIX servers.
Next we implemented a multi-server environment by partitioning the DB2
database and attaching a second pSeries 650 server. This approach of scaling
up your database system is unique to DB2, and the required steps can be carried
out easily.
The operation of SAP BW includes administration, monitoring, and tuning.

An important requirement is the ability to administer and modify the system
environment with minimal impact to operations. DB2 UDB ESE Version 8
provides robust support in this area. Monitoring DB2 database operations can be
easily accomplished through the DBA Cockpit, SAP’s graphical front-end to DB2,
that was developed in a joint project with IBM/SAP cooperation. It provides a
wealth of information about the DB2 database that is quickly and easily available.
Changes to the DB2 database configuration, as well as administration tasks, can
also be applied through this graphical user interface. Administering many
components through a common interface is a valuable capability. It can save you
time and money in resources and training. We will explain in detail how to
administer, monitor, and tune SAP BW on DB2 UDB ESE.
Leading performance with DB2

IBM has demonstrated leadership in the SAP BW 3.5 Standard Application
Benchmark on DB2 UDB ESE, which was certified on April 27, 2004.
In addition to being the first Linux based SAP BW 3.5 Standard Application
Benchmark result, it is also the leading 8-way result (query phase), leading Intel®
based result (query phase), and SAP BW 3.x result (query and load phase 2).
The benchmark was executed on IBM eServer™ xSeries® 455 (eight

1.5GHz/6MB Intel Itanium 2 processors, 32GB of memory) running IBM DB2
Universal Database 8.1 and SUSE Linux SLES 8 with an IBM TotalStorage®
FAStT700 storage solution.
DB2 and the xSeries 455 achieved measured throughput of 98,424 navigation
steps per hour in the Query Phase, 1.279 seconds average dialog response time,
and an average CPU utilization of 96 percent for the database server. Total load
throughput measured 33,515,065 rows per hour for the first phase and
10,954,707 rows per hour for the second phase, yielding a total average load
throughput of 8,256,119 rows per hour.
The SAP BW Standard Application Benchmark consists of two phases that run
consecutively (as of SAP BW 3.0). Step 1 is the Load Phase, which consists of
the reading of master data from an external flat file structure and the loading of
Introduction 3
transactional data from external flat files into the operational data store and the
InfoCube. After this, the aggregates are built. Finally, statistics and bitmapped
indices on the Fact Table and the rollup of aggregates are refreshed. The key
figure is throughput of data in rows/hour. Step 2 is the Query Phase, which
simulates the actions in an SD (Sales and Distribution) InfoCube. The key figure
is the number of dialog steps/hour.
Structure of the redbook

This section includes a brief description of the topics presented in this redbook
and how they are structured.
Tip for decision makers: We recommend that you read Chapter 4 first, to
become familiar with the business advantages of using DB2 UDB ESE with
SAP BW.
򐂰 Chapter 1 introduces SAP BW and positions it within the SAP product set.
We first introduce the concepts of data warehousing and then describe SAP
BW as a solution implementation of those concepts. A high level description
of the SAP BW architecture is described to enable a better understanding of
the components and how they interact. A sample scenario is introduced to
show a typical SAP BW environments and to explain important system
requirements.
򐂰 Chapter 2 continues with the overview of SAP BW, but presents more
detailed and technical information regarding the architecture, components,
and operation of BW. This promotes a deeper understanding of SAP BW and
the benefits to be gained.
򐂰 Chapter 3 provides an introduction to the DB2 Universal Database Enterprise
Server Edition (DB2 UDB ESE), which is the database management system
used for this redbook. Among other topics, we explain the architecture, the
different types of parallelism that are available and the different options to
scale the DB2 database system, depending on the hardware which is used.
We also talk important new features in DB2 UDB ESE version 8.
򐂰 Chapter 4 combines concepts and functionality from the previous chapters to
describe how DB2 and SAP BW are integrated and deployed for a robust and
scalable data warehousing solution. We discuss some of the initiatives with
IBM and SAP for enhanced integration of DB2 and SAP BW. The result is a
low TCO (total cost of ownership), high performance, ease of use, and the
best scalability to handle the rapid growth in data volumes and number of end
users.
4 SAP BW and DB2

򐂰 Chapter 5 describes the environment used for this redbook project. This
environment was used to install and configure DB2 and SAP BW, and to run
some scalability tests. We also describe the sample applications used during
the testing.
򐂰 Chapter 6 describes the actual implementation of SAP BW with DB2. It
provides information and recommendations in areas such as sizing, planning,
tools, implementation preparation, installation, and post-installation activities.
It is valuable information as you prepare your implementation of SAP BW with
DB2 as the underlying database management system.
򐂰 Chapter 7 introduces the important area of administration. Once the products
are installed and configured, there is a continuing, and on-going, set of
required systems operations and management activities. We discuss the
different roles involved in the operations management that enable continued
high availability and deterministic performance. There are significant tools
and capabilities available with SAP BW to help with these ongoing tasks.
򐂰 Chapter 8 discusses the topic of performance tuning of the SAP BW and DB2
implementation. We provide guidelines and recommendations for managing
the performance gathered from this redbook project, as well as from other
performance related projects completed by other organizations within IBM.
This is valuable information that can help you achieve and maintain the levels
of performance required in your enterprise.
򐂰 Chapter 9 demonstrates the process of scaling up the DB2 database system
by attaching a second database server and moving some of the database
partitions to the second server. This capability is unique to DB2. We also
show how you can add new partitions to the database and how to redistribute
the data over all partitions
򐂰 Chapter 10 continues with the topic of scalability. We present the scalability
factors that are achieved with SAP BW on DB2 for the most performance
critical SAP BW operations. A scalability factor describes the increase of
performance when increasing the number of machines that are part of the
database system. SAP BW with DB2 scales linear, or close to linear in the
area of SAP BW queries and data load.
Appendix A includes technical information to help in the analysis of your DB2

and SAP BW environment. In particular, it focuses on the analysis of your SQL
statements by using tools and capabilities that are included with SAP BW. This
will enable you to keep your transactions and applications running at best
efficiency and effectiveness.
With this overview of the redbook, it is now time to make your reading selections
and get started.
Introduction 5
6 SAP BW and DB2
1
Chapter 1. SAP Business Information

Warehouse (BW)
This chapter provides an overview of the SAP Business Information Warehouse
(SAP BW) and positions it within the SAP product set. First, we review some of
the concepts of data warehousing, and its use as the base for business
intelligence. SAP BW is a solution implementation of those concepts.
In the fast-moving business environment of today, there is an increasing need for

more, and better, business information. It is a necessity to meet the demands of
the business, and to stay ahead of the competition. Data warehousing and
business intelligence (BI) systems deliver that information.
Rapid growth is also being experienced in many enterprises, in terms of data,

numbers of information users, and query complexity. This, in turn, has intensified
the requirement for data warehousing and BI systems to support that rapid
growth. Business scenarios are presented that help describe these
requirements.
To satisfy those requirements, an intense demand has been generated for

increased scalability in data warehousing environments. Scalability is required
both for the application and the database management system. This demand is
among the most important of the requirements for data warehousing, and we
believe the best solution for it is DB2. You will find more information regarding
the scalability of DB2 in the subsequent chapters of this redbook.

1.1 Data warehousing
Businesses today have to contend with a growing flood of data. And as
companies in virtually every industry have learned, being able to understand that
data is critical to everything from increasing efficiency to retaining customers and
growing revenues. To take advantage of their data, enterprises turned to the
concept of data warehousing. The concept was to pull together large amounts of
data and create a unified, consistent view of customers, operations, and other
areas of the business. This data would then provide the information desperately
needed by enterprise decision makers.
It is important to understand that the term, enterprise decision maker, does not
refer only to enterprise executives and strategic decision makers. When using
this term, we are referring to any enterprise employee responsible for decision
making. The data warehousing technology implies delivery of an accurate and
consistent source of information available to all enterprise employees for their
decision-making purposes.
1.1.1 Informational databases

Previous to the concept of data warehousing, enterprises provided business
related information on a more-or-less ad hoc basis to satisfy each specific
requirement. To do this, the required data was gathered from the various
business processes and data sources, analyzed, manipulated, and formatted for
easy access and understanding by the decision makers. Then it was stored in
what was called an informational database. But, it was rarely an easy exercise.
The data in an enterprise is typically oriented to the particular business

processes found in the different business functional areas. It is used to satisfy
the needs of those particular business processes, and therefore not integrated.
In fact, the data is typically stored on numerous heterogeneous data structures in
numerous business functional areas. It has to be extracted for each particular
requirement. This often introduced data inconsistency and many times resulted
in redundant extracts created by different business functional areas, which can
result in data integrity issues.
In addition, the data was typically collected as needed so each source had a
different date and time of currency. That is, each data extract was accurate - but
as of a different point in time!
Therefore, a good deal of work has to take place to manipulate and merge the
data, to enable the resulting information to be accurate. Even then, it is only
accurate as of that specific point-in-time. So, it cannot be readily combined with
information obtained by other similar extract processes. With the lack of good
tools to help with this effort, each extract required a custom built extract program.
8 SAP BW and DB2

The process very soon became a development and maintenance nightmare.
1.1.2 Data warehousing

The solution, though not necessarily simple, quick, or easy, is data warehousing.
With a consistent structure and methodology, resulting in trusted data sources,
the demand for data warehousing solutions began to grow very quickly.
Data warehousing was originally developed to satisfy strategic decision making,

rather than operational decision making. Strategic decisions are considered to be
more global to the enterprise and long-term in nature, whereas operational
decisions are short-term and more involved with the day-to-day business
operations. Over time, these two requirements have continued to move closer
together. In fact, with the fast moving business environment of today, there is a
growing requirement for realtime business intelligence. This, of course, brings
with it the requirement for realtime data warehousing, which also increases the
demand for scalable, high-performance, database management systems to
support it.
A simplistic view of data warehousing is the collection of business related

historical data that requires some or all of the characteristics listed below:
򐂰 Platform, database, and application independence are highly desirable.
򐂰 Data is collected for defined time periods, such as a business cycle.
򐂰 A subject oriented collection of data from the available business data sources
is possible (for example, data for a customer or product).
򐂰 The data are not changeable (not volatile) to enable the reports, analysis
results, and queries, to be repeatable.
򐂰 New data are continually loaded to the data warehouse. At the appropriate
determined retention time, it will be archived.
򐂰 Data should be provided in an easily understandable and accessible manner
to enable analysis, even by non-technical users.
򐂰 The data warehouse is a separate structure from the operational data
sources and serves as a source for analytical applications.
To meet the requirements for data warehousing and scalable database

management systems, solutions are offered by software providers such as SAP
and IBM. In fact, that is why the focus of this redbook is on a solution comprising
products from both SAP and IBM. In particular, it is on the use of an SAP BW
implementation built on a scalable IBM DB2 database management system.
Chapter 1. SAP Business Information Warehouse (BW) 9

1.2 SAP BW positioning
SAP Business Information Warehouse is the central reporting tool for almost all
SAP business solutions. It grew out of the increasing demand for more flexible
and powerful reporting capabilities for the data stored in SAP Enterprise
Resource Planning (ERP) R/3 systems. The initial purpose was to develop a
reporting server for applications running in the R/3 systems. Since then the SAP
product architecture has evolved and is now more integrated and solution
oriented, from an enterprise-wide perspective.
Figure 1-1 shows the position of SAP Business Information Warehouse as a

component of the SAP product offering. This offering basically consists of two
building blocks:
򐂰 The mySAP Business Suite: A family of adaptive business solutions
򐂰 SAP NetWeaver: The SAP integration and application platform
SAP NetWeaver is the technical foundation of the mySAP Business Suite

solutions, SAP xApps composite applications, partner solutions, and customer
custom-built applications. If a customer buys an SAP business solutions, SAP
Netweaver is delivered as part of that solution.
mySAP Business Suite

mySAP CRM
mySAP SCM
mySAP HLM
mySAP PLM
Marketplace
mySAP HR
Financials
mySAP
mySAP
SAP Mobile Infrastructure
mySAP Enterprise Portal
mySAP Business Intelligence SAP BW
SAP Master Data Management

SAP Exchange Infrastructure
SAP Web Application Server
SAP NetWeaver
Figure 1-1 Position of SAP BW in the SAP product set
10 SAP BW and DB2

1.3 SAP business solutions
SAP provides a family of business solutions which are included in the mySAP
Business Suite. A customer can choose a subset of the solutions or the entire
suite.
SAP positions its products as business solutions rather than IT based technology
solutions. When clients purchase a mySAP solution they receive the necessary
IT software components to implement the solution. In addition, SAP BW is now
delivered with predefined business content to allow clients to implement the
business solution faster and with lower effort.
For example, if a customer purchased the mySAP Financials solution then

technically this would consist of an R/3 ERP system containing the required
financial applications, SAP NetWeaver, and SAP BW as one of its components.
SAP BW would take data from mySAP Financials for data warehousing,
analysis, and query and reporting purposes.
Financial Solution
System FI1
System BW1
(mySAP ETL (SAP BW)
Financials)
SAP WebAS, SAP Exchange Infrastructure,…
Figure 1-2 SAP solution example
The mySAP Business Suite currently includes the following solutions:
mySAP™ Customer Relationship Management (mySAP CRM): An integrated

CRM solution that facilitates service across all customer touch points
mySAP™ Financials: A solution for operational, analytical, and collaborative

financial management

mySAP™ Human Resources (mySAP HR): A human resources solution
mySAP™ Marketplace: An online marketplace solution that allows a company

to buy, sell, and conduct business
mySAP™ Product Lifecycle Management (mySAP PLM): A collaborative

solution for designers, engineers, and suppliers
mySAP™ Supplier Relationship Management (mySAP SRM): Covers the

supply cycle – from strategic sourcing to operational procurement and supplier
enablement
mySAP™ Supply Chain Management (mySAP SCM): Covers the area of

supply chain management
1.4 SAP NetWeaver

SAP NetWeaver is the integration and application platform used across all SAP
solutions. The SAP NetWeaver technology framework is depicted in Figure 1-3.
With its Enterprise Services Architecture, this Web-based platform allows the
integration and alignment of people, information, and business processes across
business and technology boundaries. It integrates information and applications
from many sources and is interoperable with primary technology standards.
As a general-purpose platform, it enables companies to build applications or

integrate their existing applications and infrastructure; and simplifies the
development, deployment, and administration, of enterprise services. SAP BW is
included in the business intelligence component of SAP NetWeaver.
Using SAP NetWeaver, IT organizations can:

򐂰 Manage their infrastructure as a single entity.
򐂰 Ensure that mission-critical business processes are reliable, secure, and
scalable.
򐂰 Unify integration technologies into a single platform and use preconfigured
business content, which can reduce the need for custom integration and
shorten the implementation time of custom development and integration
projects.
SAP has developed a composite application framework, which is a unified

application development platform that contains the tools, methodologies, rules,
user interface patterns, and services, that allow SAP and its partners to build
packaged composite applications.
12 SAP BW and DB2

Figure 1-3 shows the SAP NetWeaver integration elements, such as:
򐂰 People Integration
򐂰 Information Integration
򐂰 Process Integration
򐂰 Application Platform, including ABAP and Java (J2EE)
The various components and applications in NetWeaver are discussed further in

subsequent chapters of this redbook.
Figure 1-3 SAP NetWeaver framework
SAP BW is placed in the Information Integration area and provides an end-to-end

solution for an enterprise-wide data warehouse. SAP NetWeaver is the technical
foundation of mySAP Business Suite solutions and enables Enterprise Services
Architecture, the SAP blueprint for service-oriented business solutions. It makes
integrative operation a fundamental property of each SAP solution, to ensure
seamless interaction with any other SAP or non-SAP solution. As a result, it
allows a company to unify and align people, information, and business processes
across technologies and organizations.

SAP NetWeaver includes the following components and tools:
򐂰 SAP Mobile Infrastructure: This is a platform-independent run-time
environment for mobile solutions. These solutions allow employees to access
and use business-critical information anywhere in both connected and
disconnected modes.
򐂰 mySAP Enterprise Portal: This provides employees, partners, and
customers with instant, secure, and role-based, access to information and
applications. It enables the capability to integrate SAP solutions, third-party
applications, legacy systems, databases, unstructured documents, internal
and external Web content, and collaboration tools. It uses open standards,
Web services, and integration with other SAP NetWeaver components, to
support heterogeneous systems from all major technology providers.
򐂰 mySAP Business Intelligence: This allows you to identify, integrate, and
analyze disparate business data from heterogeneous sources. It supports
strategic, tactical and operational decision making.
򐂰 SAP Master Data Management: This enables companies to store, augment,
and consolidate master data while ensuring consistent distribution to all
systems and applications in their IT infrastructure.
򐂰 SAP Exchange Infrastructure: This provides open integration technologies
that support collaboration among SAP and non-SAP components, both within
and beyond enterprise boundaries.
򐂰 SAP Web Application Server: This provides software life-cycle
management, including design, development, execution and monitoring. It is
a Web development and run-time infrastructure for all business applications.
1.5 SAP Business Intelligence and SAP BW

SAP Business Intelligence, and SAP BW as its major component, provides data
warehousing features, reporting and analysis tools, best-practice models
(Business Content), business-analysis applications, and administrative
resources. It enables employees at all organizational levels to make better
informed business decisions.
SAP Business Intelligence is integrated with all other SAP NetWeaver

components and supports industry standards such as XML, XML for Analysis
(XMLA), OLE DB for OLAP (ODBO), Common Warehouse Metadata
Interchange (CWMI), business application programming interface (BAPI), the
ABAP programming language, Java™ 2 Platform Enterprise Edition (J2EE), and
JDBC interfaces.
14 SAP BW and DB2

It includes tools and interfaces for enhancing and extending existing business
content or integrating with third-party analysis and reporting tools. It also allows
users to personalize content and the way they access it.
SAP Business Intelligence currently comprises the following functions and

technologies:
򐂰 Data Warehousing:
– Data extraction, transformation, and loading (ETL)
– Data warehouse management: Monitoring and control of data staging
processes
– Data modelling: Definition of data structures, such as InfoCubes
򐂰 Business Intelligence Platform:
– Online analytical processing (OLAP): Interactive reporting on large,
multi-dimensional data sets
– Data mining: Recognition of behavioral patterns and dependencies (such
as decision trees, clustering, scoring, and customer segmentation)
– Alerting: Identifying exceptions and automatic notification of decision
makers
򐂰 Business Intelligence Suite:
– Reporting and analysis: Web-based, or runs on top of MS Excel
– Web application design: Supports design of Web pages to display reports
– Planning and simulation: (available as add-on)
– Portal integration: Integration of portals
1.6 SAP BW customer scenario

An example of a typical SAP customer scenario is depicted in Figure 1-4. In this
example, SAP BW is implemented in four stages:
1. In the first stage, the customer implements an SAP CRM system and an SAP
BW system. The SAP BW system loads data from the SAP CRM system on a
daily basis. After stage 1 is in production, about 250 users, most of whom are
engaged in reporting activities, are working concurrently on the SAP BW
system. The SAP CRM system data extraction process runs every evening.
2. In the second stage, an SAP HR system is connected to the SAP BW system.
The HR data is loaded into the SAP BW system once a week. Additional
users begin accessing the SAP BW system, increasing the total number of
concurrent users to 850.

3. In the third stage, an SAP Finance (FI) system is connected to SAP BW. The
financial data is loaded daily into the SAP BW system. The number of SAP
BW users is now doubled to a total of 1700 concurrent users.
4. In the final stage, a non-SAP legacy system is connected to SAP BW. Data is
extracted from the legacy system and loaded into the SAP BW once a week.
The number of concurrent SAP BW users increases again, to a final total of
8600 users.
Stage 1 Stage 2 Stage 3 Stage 4
BW
Non-SAP
CRM HR FI Legacy
System
Time
Figure 1-4 Typical SAP BW scenario
16 SAP BW and DB2

SAP BW customers typically keep between 4 and 5 years of historic data in their
SAP BW system. Figure 1-5 shows the anticipated growth of the SAP BW
database.
Figure 1-5 Example for SAP BW data growth
Because more and more systems are connected over time, the volume of data
that has to be loaded in the given nightly maintenance window is constantly
increasing until the final stage is implemented. At that point, a total of 4 GB of
data is loaded on average per day. The volume of data continues to grow until a
total of 7 TB is reached. After 4 years, the customer begins to archive part of their
warehouse data, which keeps the total data volume at a constant size.
Figure 1-6 shows the anticipated growth of users that are working concurrently
on the SAP BW system. All numbers were taken from an actual SAP BW
hardware sizing.

Figure 1-6 Example for growing number of concurrent SAP BW users
An SAP BW system can potentially function as a central repository for current

and historical reporting data for many SAP and non-SAP systems. The database
size and the processing power requirements will increase over time, and thus the
added emphasis on scalability.
1.7 Requirement for scalability

As the number of users and the volume of data grow over time, the system
performance and response times can suffer. In addition, the given maintenance
window for dataload and other SAP BW administration tasks can become a
bottleneck. The historical, and ongoing, growth of SAP BW systems emphasizes
the need for scalability. In particular, database server scalability is a critical
requirement.
Scalability does not stand in isolation, however. It is not, for example, simply a
means of enabling growth in the ability to store larger volumes of data. With
scalability comes the need to support the loading and updating of that increasing
volume of data. In addition, there will typically be an associated growth in the
number of users as well. With additional users will come an increase in query
load, and the requirement to maintain acceptable performance levels. This is
depicted in Figure 1-7.
18 SAP BW and DB2

As you can see, scalability is a multidimensional issue. You will need a system
design that is flexible and can handle the increasing system demands. Possible
solutions to the issue are as follows:
򐂰 Initially, buy sufficient hardware to support the planned requirements for the
final stage of your implementation — meaning the stage at which the data
warehouse is planned to reach its maximum data volume. Then configure
your system for that maximum capacity right at the beginning. There are, of
course, disadvantages to this approach. For example:
– You need to immediately purchase more hardware capacity than is
currently needed.
– The initial project investment is much higher than required.
– You have committed to current hardware technology, which may limit your
ability to take advantage of new technologies and cost reductions.
– The overall total cost of ownership (TCO) will most probably be higher with
this approach.
򐂰 Add more processing power, and database storage capacity, as the system
grows. This is called scaling. A major requirement for scaling a system is a
design requiring a minimum of administration effort and system disruption.
As examples, adding resources to an existing system may involve some of
the following activities:
– Moving data to different storage devices
– Moving some or all data to different storage device technologies
– Re-partitioning the data for best use of resources
– Re-balancing the data across storage devices to maintain performance

Number
Of Users Volume
Of Data
Increasing
Need
scalability
to maintain
System performance
Performance
Time
Figure 1-7 Need for scalability
In the following chapters of this redbook, we will further describe how DB2 UDB
ESE provides scalability, and, in particular, show its unique ability to attach
additional resources to an existing DB2 database system.
This has been a high-level overview and discussion of SAP BW. Chapter 2, “SAP
BW technical overview” on page 21, will take the discussion to another level of
detail. This will promote understanding of the framework and architecture from a
more technical perspective. This additional information will demonstrate why
DB2 is the best DBMS for enabling scalability.
20 SAP BW and DB2

2
Chapter 2. SAP BW technical overview

SAP Business Information Warehouse is the primary component of the SAP
Business Intelligence offering. It supports both the strategic and the tactical (or
operational) decision making process.
This chapter continues with the discussion started in Chapter 1, “SAP Business
Information Warehouse (BW)” on page 7. It describes in more technical detail the
structure and operation of SAP BW. This will provide you with a better
understanding of the architecture, framework, and components of SAP BW, and
how they work together to enable an enterprise data warehousing solution.
Let’s start with some basic structural elements and see how they all work
together to enable the SAP BW functional components that comprise the SAP
BW architecture.

2.1 SAP BW information model
The SAP BW information model is a basic structural element in the SAP BW
architecture. It is designed to enable support of a range of decision makers. To
do this, it supports the following conceptual layers of data warehousing:
򐂰 Multidimensional models, which enable views of data required for analytics.
򐂰 Operational data store (ODS), to hold current data updates from the
operational transaction systems of the business.
򐂰 Data warehouse, to hold transformed and accurate data that has been
integrated from the business processes across the enterprise to enable
business decision making.
The information model is based on a fundamental building block called an

InfoObject. For example, InfoObjects may contain data about customers, sales
orders, products, and so on. An InfoObject can be reused in other elements of
the information model, such as an InfoCube, ODS, and InfoSource. These
elements are described later in this section.
InfoObjects also carry metadata that describes the data contained in the
InfoObject, such as its origin, history, and technical properties. An InfoObject has
three classes of metadata:
򐂰 Technical metadata: This describes technical properties, such as data type
and field length.
򐂰 User metadata: This carries information about authorizations.
򐂰 Business definitions: These form the basis for a common understanding of
business terms, such as key performance indicators.
Business definitions are particularly important in the SAP BW information model.

They eliminate semantic discrepancies in data elements across systems and
organizational units, and ensure that data is consistent and reliable. SAP BW
contains several thousands of InfoObject templates that include business
definitions.
Metadata plays a fundamental role in turning data into information. To clarify,

information is typically defined as data-in-context. In that process, the metadata
provides the context and an understanding of how various data elements are
linked. Business rules are applied to the combination of data and metadata to
create useful business information. The information model of SAP BW provides
consistent and integrated metadata for all objects across the data warehousing
process.
22 SAP BW and DB2

Figure 2-1 shows the elements of the SAP BW information model, all of which
store metadata. In addition, three of the four elements also store transactional or
master data. These are the PSA, ODS object, and InfoCube. Master data is data
that remains unchanged over long periods of time. Examples of master data are
such items such customer name and address, or an organizational structure.
Data Info ODS Info

Source Mapping
Source Object Cube
and Update Update
ODS Info
PSA Transfer Rules Object Rules Cube
Rules
Figure 2-1 Elements of the information model
In addition to InfoObjects, here is a list of other key elements in the information

model:
򐂰 DataSource: Data is transferred into SAP BW in a flat structure. That is, it is
a table rather than a multidimensional data structure. DataSources contain
the definitions of the source data.
򐂰 Persistent Staging Area (PSA): In the SAP BW information model, data is
physically stored in PSA objects. These are collections of flat tables holding
extracted data that has not yet been cleaned or transformed. The PSA is the
initial storage area of data, where requested data is saved unchanged from
the source system according to the structure defined in the DataSource.
򐂰 InfoSource: InfoObjects that belong together logically, from a business point
of view, are grouped into InfoSources. InfoSources (and their underlying
InfoObjects) can be filled with any data from within the enterprise or from
external sources. They can hold both transactional data and master data.
– Transactional data is generated from transactions in an Online
Transaction Processing (OLTP) system, such as SAP R/3; it is
quantifiable; and it can be granular.
– Master data, such as a customer address or an organizational structure,
typically remains unchanged over a long period of time. Master data in
SAP BW includes attributes, texts, and hierarchies.
򐂰 Operational data store (ODS) object: This describes a consolidated dataset
from one or several InfoSources. In contrast to the multidimensional data
models of InfoCubes, data in ODS objects is stored in flat, transparent,
Chapter 2. SAP BW technical overview 23

database tables. ODS object data can be updated into InfoCubes or other
ODS objects using a delta update. Data in an ODS object can be analyzed
with the SAP BW Business Explorer (BEx) tool, that is included in the
business intelligence suite of mySAP BI. It is typically used to integrate data
that comes from different sources, for delta update into InfoCubes and for
day-to-day decision making.
򐂰 InfoCubes: These are containers that organize data around its
multidimensionality, in terms of business dimensions. They are used to
answer complex business questions on topics such as revenues per region,
revenues per office within each region, year-to-date revenues, and for
comparisons with previous periods. InfoCubes can be accessed by the SAP
BW Business Explorer for reporting and Online Analytical Processing (OLAP)
analysis.
More information on this topic can be found in the SAP Technical Brief entitled
Data Warehousing with mySAP Business Intelligence, which can be found on the
SAP Web site.
2.2 Dataflow in SAP BW

Data flow was depicted at a very high level in Figure 2-1 on page 23 for an overall
understanding. Next, Figure 2-2 provides a more complete view of the possible
flow of data in SAP BW. Data is normally loaded into a PSA first, and from there
into ODS and InfoCubes. It is also possible to directly load data into the ODS and
InfoCubes, and from ODS to InfoCube.
Operational
Data Store
Persistent (ODS)
Staging
Any Area Information
Source (PSA) Data Warehouse Access
Multi-dimensional
Models
Master
data
Figure 2-2 Dataflow in SAP BW
24 SAP BW and DB2

Data can be loaded from various heterogeneous data sources, such as:
򐂰 R/3 systems
򐂰 Non-R/3 systems
򐂰 Flat files
򐂰 XML files
򐂰 Other databases (via DB Connect)
ETL process: When data is loaded into SAP BW, it is integrated, standardized,
synchronized, and enriched. This is performed through processes known as
extraction, transformation, and loading (ETL). You have to ensure that the ETL
process captures and loads the full range of required data, while avoiding an
overload of irrelevant data. Data is often stored in different formats, with different
data types and different lengths. In addition, a data type may have the same
name but a different meaning in the different systems where it is used. All of
these data differences require resolution to enable the data from the various
sources to be combined and integrated in the data warehouse, and to provide
meaningful and accurate information. Data has to be collected and cleansed to
eliminate duplication and incorrect values. And it then has to be enriched so that
it is transformed into practical, business-descriptive information.
The transformation, cleansing, and enrichment of data is implemented as

follows:
򐂰 A DataSource is assigned to an InfoSource through the transfer rules in SAP
BW. Transfer rules map the fields of the DataSource to the InfoObjects that
make up the InfoSource. A rich library of transformation functions, which
represent business logic, can be applied at this point.
򐂰 SAP BW update rules handle the subsequent flow of data from InfoSources to
ODS objects and InfoCubes.
򐂰 In many cases, the data that is stored in the PSA object (and described in the
DataSource) has an incomplete set of metadata. Metadata is added during
the creation and bundling of InfoObjects to create the InfoSource.
2.3 Information access

In SAP BW, objects that can be analyzed are called InfoProviders. As shown in
Figure 2-3, there are two classes of InfoProviders:
򐂰 Those that contain physical data, such as InfoObjects, InfoCubes, and ODS
objects.
򐂰 Those that do not contain physical data, such as InfoSets, RemoteCubes,
and MultiProviders.

InfoCubes, ODS objects, and InfoObjects have been already introduced in 2.1,
“SAP BW information model” on page 22.
MultiProvider
InfoObject InfoCube ODS Object InfoSet RemoteCube
Data Data Data
Figure 2-3 SAP BW InfoProviders
MultiProviders are used to combine data from various objects. As shown in

Figure 2-3, a MultiProvider itself does not contain any data. A MultiProvider
provides access to data from several InfoProviders and makes it available for
reporting and analysis. A MultiProvider can be assembled from different
combinations of InfoProviders.
An InfoSet is a semantic layer using ODS objects and master data to create
reports from these objects, in particular joins between these objects. InfoSets are
created and changed in the InfoSet Builder. You can define reports based on
InfoSets using the BEx Query Designer.
A RemoteCube is an InfoCube whose transaction data is managed externally

rather than in SAP BW. Only the structure of the RemoteCube is defined in SAP
BW. Data for reporting is read from another system using a BAPI.
2.4 Hierarchies
SAP BW allows the definition of hierarchies on InfoObjects. Hierarchies can be
unbalanced, unleveled, and also time dependent. Figure 2-4 shows an example
of a sales hierarchy that is organized by region.
Hierarchies can be used for reporting. For example, with a structure such as
shown in Figure 2-4, you could retrieve the total sales. Or you could retrieve only
the sales result of a particular branch of the sales organization, such as North
America. With SAP BW, unleveled or dynamic hierarchies are stored as
parent-child lists.
26 SAP BW and DB2

WW Sales
North America Europe Asia & Pacific
US Canada East Central
East West
Figure 2-4 Sales hierarchy
The parent-child list that corresponds to Figure 2-4 is shown in Table 2-1.
Table 2-1 Parent-child list of example sales hierarchy

Predecessor Successor
WW Sales Asia and Pacific
WW Sales North America
North America Canada
North America US
US West
US East
WW Sales Europe
Europe East
Europe Central
If there are restrictions on hierarchies within a query, the results, that is, the
corresponding leafs of the hierarchy nodes that you select, are stored in
hierarchy result tables. The names of those tables consist of the prefix for SAP
BW tables (/BI0 or /BIC) followed by the digits 02. “/BI0/0200000001” is an
example of the name of a hierarchy result table.

2.5 Extended star schema (InfoCubes)
SAP uses an extended star schema in defining and creating InfoCubes. It
contains two types of data used in analysis:
򐂰 Key figures: Sales revenue, fixed costs, sales quantity, or number of
employees, etc.
򐂰 Characteristics: Customer type, fiscal year, period, or region are some
examples. Characteristics are used to create evaluation groups for analysis.
The underlying InfoObjects that make up an InfoCube are categorized in terms of

these two types of data. That is, a given InfoObject represents either key figures
or characteristics. A third type of InfoObject, attributes, contains metadata
describing other InfoObjects.
An InfoCube is represented in the database as a set of relational tables, as

shown in figure Figure 2-5. These are arranged according to the star schema, a
technique that organizes data in terms of data facts and business dimensions.
SID Table Master SID Table Master
SID Table Master Hierarchies Text Hierarchies Text SID Table Master
Hierarchies Text Hierarchies Text
dimension
SID Table Master
SID Table Master Hierarchies Text
Hierarchies Text dimension Fact dimension
SID Table Master
Hierarchies Text
dimension
SID Table Master
dimension
Hierarchies Text SID Table Master
Hierarchies Text
SID Table Master SID Table Master
Hierarchies Text Hierarchies Text
Figure 2-5 .Extended Star Schema
28 SAP BW and DB2

The star schema places several dimension tables around a central fact table.
The fact table stores key figures, while the surrounding dimension tables store
the characteristics needed for evaluating and reporting on those key figures. Fact
tables are the largest tables in star schemas, and they may contain billions of
entries.
Dimension tables are independent of each other. The fact table links the
dimension tables and the key figures. To link these tables, dimension identifiers
are used. A dimension identifier uniquely identifies a particular combination of
characteristic values in a dimension table, for example, a certain product and the
corresponding product group. Characteristics that are correlated, such as
product and product group, are usually put in the same dimension.
An InfoCube in SAP BW can have up to 16 dimensions. By default, every

InfoCube has the three standard dimensions Data Package, Time, and Unit.
SAP BW uses an extended star schema, which builds on the basic star schema
by storing master data about attributes, hierarchies, and text, in separate tables
that are shared between InfoCubes. This reduces data redundancies because
master data is stored only once, and then used by various InfoCubes.
In Figure 2-6, actual characteristic values, such as the name of a region, are
shown in the dimension tables. In reality, characteristic values are replaced by
surrogate identifiers (SIDs). These are numeric key values (4-byte integers), that
are more compact than the characteristic values. The actual characteristic values
are stored in the master table. Therefore, you have foreign key relationships
between each characteristic in a dimension table and the corresponding
attribute, hierarchy, and text tables. SIDs are used to keep dimension tables as
small as possible, since they can also grow very large.

Master data
Customer # Name Location
13970522 Brightview, Inc. Palo Alto
Customer dimension
Request dimension InfoCube
R Data Request # C Customer # Region …
0 13970522 west ...
... R P C T Quantity Revenue Discount Sales overhead

250 500,000 $ 50,000 $ 280,000 $
E - Fact table 50 100,000 $ 7,500 $ 60,000 $
(R=0)
… … … ...
F - Fact table R P C T Quantity Revenue Discount Sales overhead

(R>0)
150 300,000 $ 30,000 $ 180,000 $
30 50,000 $ 2,500 $ 20,000 $
… … … ...
Product dimension
P Product # Product group … T Period Fiscal year …

2101004 displays ... 10 1997 ...
Time dimension
Figure 2-6 Foreign-key relationships
SAP BW provides the option to define a very large dimension as a line item
dimension. In this case, the corresponding dimension is not stored as a separate
table, but rather it is stored directly in the fact table. This eliminates the
necessary join operation between dimension and fact table during SAP BW
query processing, which can provide improved query performance.
2.6 Dataload into InfoCube

When data is loaded from PSA or ODS into an InfoCube, it must be transformed
from a flat table structure into the extended star schema. Figure 2-7 shows the
steps that are required to transfer a new record from a PSA table into an
InfoCube and the corresponding master data tables.
The steps are as follows:

1. The record is selected from the PSA table.
2. Transfer and update rules are applied.
30 SAP BW and DB2

SID Customer SID Product SID Prod. Group SID City SID Country
1 Lufthansa 1 A320 1 Computers 1 Boston 1 US
2 Air France 2 Concorde 2 Airplanes 2 Paris 2 France
Master data
3 4
P SID Product SID Product Group
InfoCube 1
2
1
2
2
2
Product dimension
C SID Customer P C R Quantity Revenue R SID SID

City Country
1 1 1 1 1 25 60000 $
1 1 1
2 2 1 2 1 50 120000 $
2 2 2
2 2 2 1 25000000 $
Customer dimension
Region dimension
Fact table
5
Attributes
2 Key Figures
PSA Product
Concorde
Prod Group
Airplanes
Customer
Air France
City
Paris
Country
France
Quantity
1
Revenue
25000000 $
A320 Airplanes Lufthansa Munich Germany 2 30000000 $
1
Figure 2-7 Steps during dataload into InfoCube
3. The master data tables are checked to see if the attribute values from the
PSA record already exist. If this is the case, the corresponding surrogate
identifiers (SIDs) are retrieved from the master data tables. If the attribute
values do not yet exist, they are inserted in the master data tables and
corresponding SIDs are generated. In the given example the attribute values
Concorde and Airplanes are inserted in the master data tables.
4. The dimension tables are checked to see if the combination of SID values
that correspond to the attribute values from the PSA record exist in the
dimension tables. For example, the product dimension table is checked to
see if the SID combination 2/2 exists, which corresponds to the attribute
combination Concorde/Airplanes. If the SID combination exists, the
corresponding dimension identifier is retrieved. If the SID combination does
not exist, it is inserted in the dimension table and a corresponding dimension
identifier is generated.
5. After the dimension identifiers that correspond to the given attribute values
are retrieved/generated, a new record is inserted into the fact table. It
contains the key figures from the PSA record and the corresponding
dimension identifiers.

2.7 Aggregates
Aggregates represent another technique for improving query performance. They
are materialized, summarized views of the data in an InfoCube, and store a
subset of InfoCube data in a redundant form. When an appropriate aggregate for
a query exists, the summarized data can be read directly from the database
during query execution instead of having to perform this summarization during
runtime. In SAP BW, the system generates suggestions for creating optimal
aggregates. The system administrator can then decide whether to create those
aggregates.
Aggregates reduce the volume of data to be read from the database, speed up
query execution time, and reduce the overall load on the database. To use
aggregates you must build and maintain them, and they require additional space
in the database. Aggregates are very similar to the automatic summary tables
defined in DB2.
An easy way to conceptualize an aggregate is to think of it as providing a similar

benefit as adding another index to a database table. Aggregates require no
special knowledge by the end-user, and in fact are completely transparent to the
end-user. The only way an end-user might recognize the existence of an
aggregate is by the performance gain that is observed.
2.7.1 Aggregate example

The contents of an example InfoCube are shown in Table 2-2. It is an example of
an aggregate and is based on a very simplified InfoCube that has the two
characteristics Country and Customer, and the key figure Sales.
Table 2-2 Simplified InfoCube

Country Customer Sales
USA Blue Soft 10
Germany Ocean Networks 15
USA Funny Duds 5
Canada Ocean Networks 10
Canada Thor Industries 10
Germany Funny Duds 20
USA Blue Soft 25
32 SAP BW and DB2

Table 2-3 shows another sample aggregate, one that only contains the country
characteristic, and the key figure, sales.
Table 2-3 Aggregate: Country

Country Sales
USA 40
Germany 35
Canada 20
These example aggregates could be used by a query that reports the sales by
country or total sales. The aggregates could also be used for reports according
to a navigation attribute for the characteristic country or according to a hierarchy
containing the countries. If during query navigation there is a drilldown, or a
selection is made for a particular customer, these aggregates would not be used.
This is because the aggregates do not contain any detailed information about a
particular customer, only summarized customer data.
The next example is an aggregate that is grouped according to the nodes of a

hierarchy level. The hierarchy is shown in Figure 2-8.
Level 1 World
Level 2 America Europe
Level 3 USA Canada Germany
Figure 2-8 Hierarchy of Country
The aggregate is shown in Table 2-4. That aggregate can be used by queries
that report on sales for a hierarchy node on level 2 or higher. In this example, in
Figure 2-8, those are the nodes labeled “Europe”, “America”, and “World”. It can
also be used by queries that have this country hierarchy as a presentation
hierarchy in the drilldown, but the drilldown goes no lower than the second level.
Table 2-4 Aggregate of Country hierarchy level 2

Customer Sales
America 60
Europe 35

2.7.2 Maintaining aggregates
There are a number of activities required to maintain aggregates. For example,
they must be loaded (filled with data), calculated, activated, and updated.
Activating and filling

In order to use an aggregate in the first place, it must be defined, activated, and
filled. When activated, the required tables are created in the database from the
aggregate definition. Technically speaking, an aggregate is actually a separate
BasicCube with its own fact table and dimension tables. However, aggregates
might share the dimension tables of the corresponding InfoCube if those tables
have the appropriate structure. Upon creation, every aggregate is assigned a
technical name, which is a unique number consisting of six digits where the first
digit is always set to 1. The table names that make up the logical object that is
the aggregate are then derived in a similar manner, as are the table names of an
InfoCube. For example, if the aggregate has the technical name 100001, the fact
tables have the following names: /BIC/E100001 and /BIC/F100001. Its
dimensions, which are not the same as those in the InfoCube, have table names
such as /BIC/D100001P, /BIC/D100001T, and so on.
When you fill an aggregate, you load it with data. This action can only be
triggered from the aggregate maintenance. Also note that an aggregate can be
filled from the data of a larger aggregate that is already filled. This means that
very highly summarized aggregates, as a rule, can quickly obtain data from other
aggregates. In contrast, it can take a long time to build aggregates from the
InfoCube. Because of this, all aggregates are filled in background processes. If
there are several aggregates scheduled to be filled in one process, a hierarchy
sequence for the aggregates is determined first, and it is then processed
sequentially. This guarantees that very highly summarized aggregates are built
from the more detailed aggregates.
Roll-up
If aggregates are defined, new data packets that are loaded into the InfoCube
cannot be used for reporting until they are written to the aggregates by a
so-called “roll-up”. In other words, data that has been recently loaded into an
InfoCube is not visible for reporting, from the InfoCube or aggregates, until an
aggregate roll-up takes place. During this process you can continue to report
using the data that existed prior to the recent data load. The new data is only
displayed by queries that are executed after a successful roll-up.
There are three different options for rolling up data:

򐂰 You can set up the InfoCube so that every data packet is automatically rolled
up into the aggregate if it is technically correct and the quality has been
ensured.
34 SAP BW and DB2

򐂰 The roll-up can be also started manually from the Administrator Workbench.
This is appropriate if the data of several packets form a logical unit and are
only valid if they are released together. For example, assume that different
plants deliver their data at different times to be loaded into an InfoCube. It
would not be valid to make any of the data visible until all plants have
delivered their data to be loaded into the InfoCube as a consistent set.
򐂰 Another option to start the roll-up manually is by executing the program
RSDDK_AGGREGATES_ROLLUP. This program can either be scheduled
periodically, or an event chain constructed to include aggregate roll-up.
Change-run: Hierarchy-attribute realignment run

If you change master data, navigation attributes or hierarchies usually change as
well. It is therefore recommended that you adjust the data in the aggregates after
loading the master data. To assure that reporting delivers consistent results, the
master data and hierarchies are kept in two versions:
򐂰 The active version, where you can see the query
򐂰 The modified version, which at some point will become the active version
The change-run, also called hierarchy-attribute realignment run, adjusts the data
in the aggregates and turns the modified version of the navigation attributes and
hierarchies into an active version. In almost every phase of the change-run, you
can continue reporting on the old master data and hierarchies.
You can either start the change-run manually in the Administrator Workbench or
with a program RSDDS_AGGREGATES_MAINTAIN. You can give the program
a list of characteristics and hierarchies that are to be taken into account for the
change-run. By default, all those characteristics are taken into account whose
master data you loaded or changed manually, and all the hierarchies that were
marked for the realignment run.
The change-run takes places in different phases:

򐂰 A list of all navigation attributes and hierarchy levels that have actually
changed, is generated. Then the relevant aggregates that are to be adjusted
are generated from this list.
򐂰 The system adjusts the aggregates and calculates the percentage of change
per aggregate. If the percentage is small, the changes are calculated
explicitly. If the percentage is large, the aggregate is completely rebuilt in a
temporary table.
򐂰 Master data and hierarchies are activated.
򐂰 The temporary aggregate tables are renamed. When running on DB2 UDB,
the indices are also renamed at this stage.

2.8 Compression of requests
Data is loaded into an InfoCube by using smaller pieces, called requests. The
data is first stored in the F-fact table of the InfoCube. Requests can be deleted
from the F-Fact table if the data is, for example, not consistent. If the quality
status of a request is appropriate, the request can be compressed, which
significantly reduces the required storage space for the data. During
compression, data is transferred from the F-fact table to the E-fact table of the
InfoCube or aggregate, as shown in Figure 2-9. Compressed requests can only
be deleted by deleting the entire contents of the InfoCube.
Request 1 to n
E- Fact table (compressed data)
Condensor
Request n Request n+2 Request n+3
F- Fact table (uncompressed)
Figure 2-9 Compression of requests
The processing steps that occur during compression of requests, when running
on DB2 UDB ESE, are explained in detail in “Collocated joins during
compression of requests” on page 97.
2.9 Operational data store (ODS)

An ODS object stores consolidated transaction data from one or several
InfoSources. In contrast to the multidimensional data models of InfoCubes, data
in ODS objects is stored in flat, transparent, database tables. ODS object data
can be updated into InfoCubes or other ODS objects using a delta update. Data
in an ODS object can be analyzed with the SAP BW Business Explorer.
An ODS object contains a key (for example, order number) as well as data fields
(key figures). As opposed to InfoCubes, fields in an ODS object can be
36 SAP BW and DB2

overwritten. This is useful to process document structures, for example. If you
change documents in an OLTP system, the changes not only affect numeric
fields such as order quantity, but also non-numeric fields such as status and
delivery date. To reflect these changes in the ODS object, the relevant fields in
the ODS objects must be overwritten and set to the current value.
Figure 2-10 shows an example of two layers of ODS objects that are used to
update order and delivery information. These ODS objects allow you to
determine, for example, which orders are open, partly delivered, or completely
delivered.
InfoCube
Update Rules
Order-
Delivery
Level 2
Update Rules Update Rules
ODS
Order Level 1
Delivery
Transfer Rules / Update Rules
PSA
Order Delivery
Figure 2-10 Using multiple layers of ODS objects to integrate data
The ODS objects can store the data at the same level of granularity as offered
from the PSA (that is, the source system) because aggregation can be
performed later during reporting.
The example shows how the ODS can be used to integrate data that describes
the same processes but that potentially comes from different source systems
(DataSources). The data can be loaded into SAP BW and stored in different PSA
tables, each having their own Transfer Structure. Integration is achieved by
applying Transfer Structure specific rules (that is, transfer rules) while
transferring the data into the same consolidated structure (communication
structure of an InfoSource) of an ODS object.

Thus the ODS objects of the inner level of the operational data store (level 2 in
Figure 2-10 on page 37) offer data that is subject oriented, consolidated, and
integrated, with respect to the same process that is operated on different source
systems.
The first level ODS objects are part of the foundation of the data warehouse
because it represents the transactional data archive. This data can be accessed
to create new reporting scenarios based on integrated and consolidated data
from the past.
On the database level, every ODS object consists of three transparent tables:
򐂰 Active table: The data in this table is used for reporting.
򐂰 Activation queue: This table contains data that is new or modified since the
last activation.
򐂰 Change log table: The change log is used for the delta update from the ODS
object into other ODS objects or InfoCubes.
Figure 2-11 shows the steps that occur during activation of ODS data. In this
example, we assume that document 123, with an amount of 100, is already
loaded into the activation table of the ODS object.
Active table Change log
Doc-No. Item Amount Doc-No. Item Amount

123 1 100 123 1 -100
123 1 60 123 1 60
Activate
1. Insert new 2. Insert old record
record, Delete (negative value),
old record Insert new
record
Doc-No. Item Amount
New record
123 1 60 3. Delete
ODS Activation queue

new
record
Figure 2-11 Activation of data in ODS
When data is activated in the ODS, the following steps occur:

1. The new/modified data is transferred into the active table. The corresponding
old record is deleted from the active table.
38 SAP BW and DB2

2. The old record of the active table is saved as a negative (-100) value in the
change log, and the new record is also stored in the change log (60).
3. The new/modified data is deleted from the activation queue.
If all the records are activated, you can propagate the changes from the change
log to the datasets of the related ODS Objects and/or InfoCubes, in a separate
step. The amount is therefore reduced by 40 in the related data targets in the
example.
2.10 The SAP BW functional components

So far, we have discussed a number of key elements used in SAP BW. In this
section we show how those elements are combined to form the functional
components that comprise the SAP BW architecture.
Figure 2-12 shows the primary functional components of SAP BW:

򐂰 Business Explorer: This tool is used to define and execute SAP BW queries.
It comprises the following tools:
– BEx Analyzer and BEx Browser are two tools used to execute SAP BW
queries. The BEx Analyzer is based on Microsoft® Excel.
– Query Designer is used to define and design the queries.
– Web Application Designer is used to define and design the layout of Web
based reports.
򐂰 OLAP Engine: When a user executes an SAP BW query, or query navigation
takes place, the OLAP engine processes the query. It splits the request into
several database queries. The system then looks for the best possible
aggregate for each of the database queries. It generates SQL statements
which are then executed on the underlying database system. If an SAP BW
query contains restrictions on hierarchies, the OLAP engine resolves those
restrictions and determines the corresponding leaf nodes of the hierarchy
subtree. Finally, it consolidates the results of the executed SQL statements
and sends this information back to the Business Explorer.
򐂰 Staging Engine: This engine provides all processing that is collectively
described as extraction, transformation, and loading (ETL). This is the
process of accessing source data, cleaning, transforming, and integrating it,
and then loading it into the data warehouse. The ETL processing is discussed
in 2.2, “Dataflow in SAP BW” on page 24.
򐂰 Administrator Workbench: This allows the BW administrator to perform all
data warehouse modeling and maintenance tasks within a single, unified
environment. The workbench allows the administrator to back up and manage

objects, define new objects and data flows, and to manage security,
archiving, and other tasks.
The Administrator Workbench has the following components:
– Meta Data Maintenance to allow the administrator to specify and maintain
the InfoCubes, ODS definitions, and technical data.
– Scheduler to schedule the transfer of data from the source data systems
at regular intervals.
– Data Load Monitor to supervise the load and staging processes.
– Data Access Monitor to obtain statistics on BW usage.
Enterprise Portal - Reporting

Business
Explorer BEx Analyzer BEx Browser
InfoCubes
Meta Data OLAP Engine

SAP BW ODS
Server Staging Engine
Master Data
PSA
Administrator Workbench
BAPI Other Interfaces
Source R/3 Non-R/3 SAP BW File

Systems
Extraction, Transformation, and Loading
Figure 2-12 SAP BW functional components
The communication between the SAP systems is based on Standard TCP/IP.

In addition, SAP provides Remote Function Call (RFC) and Application Link
Enabling (ALE) protocols. Using the ALE distribution models, selected business
objects can be synchronized in different SAP Systems. This synchronization of
the business objects is performed via the Business Application Programming
Interface (BAPI). The business objects are transferred using the Intermediate
Documents (IDocs).
40 SAP BW and DB2

2.11 SAP BW business content
To accelerate the SAP BW implementation, SAP provides a component called
Business Content. It incorporates best practices and the business process
knowledge of SAP. The content, depicted in Figure 2-13, includes preconfigured
programs for extracting data, data models, and a wide range of predefined
templates for reports and analyses. It supports both industry-specific and
domain-specific models and templates in areas such as customer relationship
management and supply chain management. It includes predefined BW
elements such as:
򐂰 + 11,000 InfoObjects
򐂰 + 340 ODS Objects
򐂰 + 600 InfoCubes
򐂰 + 120 MultiProviders
򐂰 + 3,200 Queries
򐂰 + 1,900 Workbooks
򐂰 + 800 Roles
SAP BW predefined Business Content

- An example of available material -
+600 InfoCubes
+11,000 InfoObjects
+120 MultiProviders
+340 ODS Objects +3,200 Queries

ODS
+1,900 Excel Workbooks
+ 800 User Roles
Figure 2-13 SAP BW business content
This content can be used as is, or can be modified to meet any particular
requirements. It represents a wealth of supplied content that helps speed the
implementation and shorten the time to realize benefits.
As can be seen, SAP BW is a robust solution for data warehousing and business
intelligence. This has been a brief overview to supply sufficient information to
enable a better understanding of the remaining contents of this redbook. There is
more detailed information available concerning this offering that can be accessed
from your IBM representative, or directly from SAP.

42 SAP BW and DB2
3
Chapter 3. DB2 UDB ESE technical

overview
This chapter provides an introduction to DB2 Universal Database Enterprise
Server Edition (DB2 UDB ESE). DB2 UDB ESE is available on Windows® and
major UNIX® platforms, such as AIX®, Solaris, HP-UX, and Linux. DB2 has
considerable strengths in scalability, performance, availability, and in support of
Internet architecture.
Scalability and high availability

DB2 UDB ESE allows processing of complex SQL statements on very large data
sets. It has different approaches to high-end scalability and provides two classes
of parallelism. On single servers, intra-partition parallelism can be deployed to
make use of multiple CPUs. To utilize multiple servers, or to further increase
performance on single servers, DB2 UDB ESE also offers inter-partition
parallelism.
In addition, DB2 integrates with IBM AIX HACMP™ to provide failover support to
improve availability.

Internet architecture
DB2 UDB provides native support for Java (for writing user-defined functions and
stored procedures), and for JDBC. DB2 integration with WebSphere and its
enterprise Java support extends this capability even further. Enterprise
JavaBeans (EJB) and Java servlets are supported in this integrated
environment, as are distributed Java-based transactions via JDBC Version 2,
and the Java Transaction APIs.
XML support is provided via a no-charge XML Extender to DB2, that includes an
XML-aware text search, an XML datatype, and complete integrated XML
management capabilities. XML-aware searches are easy to perform using the
DB2 Net Search Extender.
Based on the strong cooperation between SAP and IBM, DB2 has become very
convenient to manage through SAP applications. All DB2 administration
functions are accessible via SAP transaction ST04. More details about DB2 in an
SAP Business Warehouse environment are described in Chapter 4, “Building
SAP BW on DB2” on page 81.
44 SAP BW and DB2

3.1 The architecture
Figure 3-1 shows a general overview of the architecture and processes for DB2
UDB. On the client side, local or remote applications such as SAP BW work
processes are linked with the DB2 Universal Database client library. Local clients
communicate using shared memory and semaphores; remote clients connect to
the database server through TCP/IP.
On the server side, activity is controlled by either DB2 processes (on UNIX) or
DB2 threads (on Windows). We refer to DB2 processes and threads as engine
dispatchable units (EDUs). EDUs are shown as circles or groups of circles in
Figure 3-1.
DB2 agents are the most common type of EDUs and perform most of the SQL
processing. A single SQL statement can be processed by one or multiple DB2
agents. Multiple subagents can be assigned if the server has multiple processors
or is part of a partitioned database. For example, in a symmetric multiprocessing
(SMP) environment, multiple SMP subagents can exploit the available
processors. All agents and subagents are managed using a pooling algorithm
that minimizes the creation and destruction of EDUs.
Buffer pools are DB2’s database cache. They are areas of database server
memory where database pages of user table data, index data, and catalog data
are temporarily moved and can be modified. Buffer pools are a key determinant
of database performance because data in memory can be accessed much faster
than data from disk. Therefore, if more of the data needed by applications is
present in a buffer pool, the applications will realize significantly improved
performance.
Chapter 3. DB2 UDB ESE technical overview 45

Figure 3-1 DB2 UDB architecture and processes overview
Pre-fetching of data is another DB2 capability for significantly improving

performance. Prefetchers retrieve data from disk and move it into the buffer pool
before applications actually need the data. For example, applications that scan
through large volumes of data would have to wait for data to be moved from disk
into the buffer pool if there were no data prefetchers.
Agents of the application send asynchronous read-ahead requests to a common

prefetch queue. As prefetchers become available, they execute those requests
by using big-block or scatter-read input operations to bring the requested pages
from disk to the buffer pool. If you have multiple disks for storage of the database
data, the data can be striped across the disks. Striping data lets the prefetchers
retrieve the data from multiple disks at the same time. This technique further
enhances performance.
46 SAP BW and DB2

Page cleaners move data from the buffer pool back to disk. Page cleaners are
background EDUs that are independent of the application agents. They look for
pages from the buffer pool that are no longer needed and write the pages to disk.
Page cleaners ensure that there is room in the buffer pool for the pages being
retrieved by the prefetchers. Without the independent prefetchers and the page
cleaner EDUs, the application agents would have to do all of the reading and
writing of data between the buffer pool and disk storage. Page cleaners are
triggered to run based on multiple events. Most notably, soft checkpoints will be
raised to ensure fast recoverability of the database.
All databases maintain log files that keep records of database changes and to
support rollback operations. If a database needs to be restored and the
transactions recovered to a point beyond the time of the last full backup, the logs
are required to roll the data forward to that point in time. There are two logging
strategy choices:
򐂰 Circular logging: In this strategy, the log records fill the log files and then
overwrite the initial log records in the initial log file. The overwritten log
records are not recoverable. This type of logging is used, if the database
configuration parameters LOGRETAIN and USEREXIT are set to NO. Using
this setup, the rollforward command cannot be used.
򐂰 Retain log records: In this strategy, a log file is archived after it has been
filled with log records. New log files are made available for log records.
Retaining log files enables roll-forward recovery. Roll-forward recovery
reapplies changes to the database based on completed units of work
(transactions) that are recorded in the log. You can specify that roll-forward
recovery is to the end of the logs, or to a particular point in time before the
end of the logs. This is the default type of logging for SAP BW.
All changes to regular data and index pages are written to the log buffer first. The
data in the log buffer is written to disk by the logger process, for example, if the
client application issues a COMMIT statement, if the log buffer is full, or after a
second at latest.
3.2 Functions and components

This section describes some of the functions and components that provide the
robust capabilities of DB2 UDB ESE. These capabilities are required of a DBMS
to enable support of an SAP BW, or any other data warehousing, environment.
The capability to scale with the growing volumes of data being generated by
companies today is essential. But, at the same time, it must be able to maintain
the performance and query response times required by the user community.

First we discuss key functions and capabilities of DB2 that provide the required
data warehousing support. Then we discuss some of the interesting and
important capabilities delivered with the latest version, which is DB2 UDB ESE
Version 8.
3.2.1 Database objects

To understand the capabilities of DB2, you must first know the database objects
defined and used by it. An understanding of those objects and their structure will
help you appreciate how DB2 delivers such robust capability.
In addition, understanding the structure and functionality at this detailed level will
enable you to better compare it with other database systems. With this
knowledge, you will be able to see how DB2 can deliver superior scalability and
still maintain the required levels of performance.
Key technologies used to enable superior scalability are parallelism and

partitioning. We begin with a basic discussion of these technologies in this
section, and then discuss them in more detail in subsequent chapters of this
redbook. Of course, there are a number of other important technologies that
support, and are used with, parallelism and partitioning. As examples, consider
concurrency and locking strategies and join methods for both local and
distributed joins.
Central to all these technologies, and a key differentiator for DB2, is the cost
based optimizer. This component enables DB2 to provide the best performance
at the lowest resource cost. In addition to enabling the functionality required, it
gives you the best use of the resources you have available, at the lowest cost.
Let’s start with the base building blocks of a DBMS: the database objects.
Figure 3-2 shows the relationship between the various DB2 database objects
that provide the infrastructure.
48 SAP BW and DB2

System
Table spaces are where tables are stored:
Instances SMS
Each container is a
directory in the file
space of the operating
Databases system.
Tablespaces
- Or -
Tables
Indexes DMS
Each container is a
Long data fixed, pre-allocated file
or a physical device
such as a disk
Figure 3-2 Relation between DB2 database objects
Instances
An instance (sometimes called a database manager) is DB2 code that manages
data. It controls what can be done to the data, and manages system resources
assigned to it. Each instance is a complete environment. It contains all the
database partitions defined for a given parallel database system. An instance
has its own databases (which other instances cannot access), and all its
database partitions share the same system directories. It also has separate
security from other instances on the same server (system).
Important: Please note that SAP Instances are not equivalent to DB2
Instances. SAP Systems may be able to run multiple SAP Instances
(application servers). Each SAP System will connect to a DB2 database within
a DB2 Instance.

Databases
A DB2 database presents data as a collection of tables. A table consists of a
defined number of columns and any number of rows. Each database includes a
set of system catalog tables that describe the logical and physical structure of the
data, a configuration file containing the parameter values allocated for the
database, and a recovery log with ongoing transactions and archivable
transactions.
Tablespaces
A DB2 database is organized into parts called tablespaces. A tablespace is a
place to store tables. When creating a table, you can decide to have certain
objects such as indexes and large object (LOB) data kept separately from the
rest of the table data. A tablespace can also be spread over one or more physical
storage devices.
A tablespace consists of containers. A container is an allocation of physical

storage (such as a file or a device). As shown in Figure 3-3, a tablespace can be
either system managed space (SMS) or database managed space (DMS). For
an SMS tablespace, each container is a directory in the file space of the
operating system, and the operating system's file manager controls the storage
space. For a DMS tablespace, each container is either a fixed size pre-allocated
file or a physical device such as a disk, and the database manager controls the
storage space.
Important: For SAP environments, DMS tablespaces are recommended.

They provide better performance than SMS tablespaces. Starting with SAP
Web Application Server 6.20 (SAP BW3.0B), the use of SMS tablespaces is
also supported by SAP.
Tables
A table consists of data logically arranged in columns and rows. All database and
table data is assigned to tablespaces. Table data is accessed using the
Structured Query Language (SQL). When creating a table, you can decide to
store all related objects (for example, indexes and large object data) in the same
tablespace, or keep them in separate tablespaces.
System catalog tables

Each DB2 database includes a set of system catalog tables, which contain
information about the definitions of database objects such as user tables, views,
and indexes, as well as security information about the authority that users have
on these objects. They are created when the database is created, and are
updated during the course of normal operation. You cannot explicitly create or
drop them, but you can query and view their contents using the catalog views.
50 SAP BW and DB2

Database partitions and partition groups
Partitioning is a technique used to segment the data in a database, either
logically on one server, or physically, which means distributing it over multiple
servers. This can provide a number of advantages, such as these:
򐂰 The ability to attach additional servers to provide support for growing data and
number of users
򐂰 Enabling faster access to the data because of parallel processing of the data
on each partition
򐂰 Increased concurrent access to data for concurrently running applications or
processes
򐂰 Distribution of the data across multiple servers and storage devices
򐂰 Faster reorganizations
򐂰 Faster recovery in the event of hardware or software failures
All of these advantages can combine to give DB2 high scalability, faster
performance, and higher data availability.
A DB2 database can either be partitioned or non-partitioned. If the database is

partitioned, the data and processing can be distributed among all of the database
partitions in the DB2 Instance. The partitions can be located on different physical
servers (physical partitioning) or on the same server (logical partitioning) or
both.
Database partitions have the following characteristics:

򐂰 Each partition has its own buffer pools, sort areas, and logging.
򐂰 Each partition has its own set of database configuration parameters
򐂰 Each partition is backed up separately. The catalog partition (partition 0) has
to be backed up first. All other partitions can then be backed up in parallel.
򐂰 All table data of a partitioned tablespace is distributed over all assigned
database partitions.
Tip: Partitioning a DMS tablespace results in larger size limits for the
tablespace, because the size is limited per partition: 256 GB for 16 KB page
size, and 512 GB for 32 KB page size. For example, with 16k page size, a
4-partition system will be able to hold 256GB x 4 = 1 TB per tablespace.
You can define database partition groups, which can comprise all or a subset of
the database partitions. When creating a tablespace, you assign it to a database
partition group and define which tablespace containers are located in a particular
database partition.

Partitioning key, partition map, and hash partitioning
When creating a table in a partitioned tablespace, you define a partitioning key
for that table. The partitioning key determines how the table data is distributed to
the database partitions. As shown in Figure 3-3, DB2 uses a hash function to
determine on which database partition a particular table row is stored.
Social Insurance Number Name Location

123-456-789 JoeBoston Toronto
Partition Key hashed
to value: "8"
Hash
0 1 2 3 4 5 6 7 8 9 10 11 12 ...
value
Partition 1 2 3 1 2 3 1 2 3 3 3 3 1 ...
Hash value “8”

assigned to Partition 3
Partition 1 Partition 2 Partition 3
Figure 3-3 Hash partitioning
When a new row is inserted into a partitioned table, the row’s hash key value is
used as input to a hash function that maps it to a hash value between 0 and
4095. A partition map is used to store the mapping between hash values and
database partitions. For each hash value it contains the corresponding database
partition number. The table row is stored on the partition number that is retrieved
from the partition map. The same hash function is used to retrieve rows from
partitioned tables.
52 SAP BW and DB2

Buffer pools
As already explained in 3.1, “The architecture” on page 45, a buffer pool is the
main memory which is allocated to cache table and index data pages as they are
being read from disk, or being modified. The purpose of the buffer pool is to
improve system performance. Data can be accessed much faster from memory
than from disk; therefore, the fewer times the database manager needs to read
from or write to a disk (I/O), the better the performance.
You can create more than one buffer pool and assign it to particular tablespaces.
If a tablespace is located on multiple database partitions, the corresponding
buffer pool is created on each partition. For example, if you define two partitions
on a single server and a tablespace on both partitions, two separate memory
areas will be allocated for the corresponding buffer pool, one for each partition.
3.2.2 Concurrency, locking and isolation levels

In any shared data access environment involving queries and updates, a locking
mechanism is required to guarantee the integrity of data. DB2 provides
concurrency control by means of locks on rows, tables, or tablespaces. In SAP
environments, users will not have to control the level or granularity of locking.
Nevertheless, a good understanding of DB2's capabilities will be helpful in
maintaining a high level of concurrency and performance.
Important: While locking provides data integrity, poor application code or

wrong configuration of DB2’s locking mechanism (like locklist size) can have a
significant negative impact on response times and application throughput.
The isolation level determines how data is locked or isolated from other
processes, while the data is being accessed. To explain the isolation levels
provided by DB2, we first introduce the different effects that could occur without
locking:
򐂰 Lost updates: Two applications, A and B, might both read the same row from
the database and both calculate new values for one of its columns based on
the data these applications read. If A updates the row with its new value and
B then also updates the row, the update performed by A is lost.
򐂰 Access to uncommitted data: Application A might update a value in the
database, and application B might read that value before it was committed.
Then, if the value of A is not later committed, but backed out, the calculations
performed by B are based on uncommitted (and presumably invalid) data.
򐂰 Non-repeatable reads: Some applications involve this sequence of events:
a. Application A reads a row from the database, then goes on to process
other SQL requests.

b. In the meantime, application B either modifies or deletes the row and
commits the change.
c. Later, when application A attempts to read the original row again, it
receives the modified row or discovers that the original row has been
deleted.
򐂰 Phantom reads: The phantom read phenomenon occurs when:
a. Your application executes a query that reads a set of rows based on some
search criterion.
b. Another application inserts new data or updates existing data that would
satisfy your application's query.
c. Your application repeats the query from the first step (within the same unit
of work).
When the query is repeated in the third step, some additional (“phantom”) rows
are returned as part of the result set that were not returned when the query was
initially executed in the first step.
DB2 supports the following isolation levels:

򐂰 Repeatable Read (RR)
򐂰 Read Stability (RS)
򐂰 Cursor Stability (CS)
򐂰 Uncommitted Read (UR)
RR is the most restrictive level, while UR is the least restrictive.
Important: Whenever possible, SAP BW uses isolation level uncommitted

read to provide maximum concurrency.
Table 3-1 summarizes the different isolation levels in terms of the undesirable
effects previously discussed.
Table 3-1 Summary of different isolation levels

Isolation Level Access to Nonrepeatable Phantom read
uncommitted data reads phenomenon
Repeatable Read Not possible Not possible Not possible
Read Stability Not possible Not possible Possible
Cursor Stability Not possible Possible Possible
Uncommitted Read Possible Possible Possible
54 SAP BW and DB2

When the number of locks held on rows exceed a certain threshold, a lock
escalation occurs from row locks to a table lock. A lock escalation is an internal
mechanism that is invoked by the DB2 lock manager to reduce the number of
locks held. DB2 uses lock escalations to be able to continue processing in those
situations. A side-effect of lock escalations is a reduced concurrency at the
application level.
Important: In SAP environments, configuration of DB2 is provided in a way to

minimize the likelihood of lock escalations. SAP DB2 monitors are provided to
control the occurrence of lock escalations. In this case, appropriate
countermeasures can be provided. For example, increasing the lock list size.
More frequent application commits may also be a solution. SAP BW provides
several parameters, such as BLOCKSIZE for example, that influence the
frequency of commits.
3.2.3 Parallel processing and partitioning

In this section we describe concepts that are critical for providing scalability. We
begin with a classification of two types of parallel processing that are utilized in
DB2, and their relationship to partitioning. We also provide an overview of the
most important hardware environments that are supported and how you can
scale up in the different environments:
򐂰 Single partition on a single SMP (symmetric multiprocessor) server
򐂰 Multiple partitions on a single SMP server
򐂰 Multiple partitions on multiple SMP servers
Single partition on a single SMP server

This environment is depicted in Figure 3-4. Typically it is made up of several
equally powerful processors within the same server, which is called a symmetric
multiprocessor (SMP) system.

,
CPU CPU CPU CPU
Memory
Database Partition
SMP
Server
Disks
Figure 3-4 Single partition on single SMP server
Resources, such as disk space and memory, are shared. With multiple
processors available, different database operations such as loading data,
backup/restore, and index creation, can take advantage of multiple processors.
Most importantly, DB2 can divide the work of a single query among available
processors to improve processing speed. This is called intra-partition
parallelism. Typically a single query comprises several operations, as shown in
Figure 3-5. If intra-partition parallelism is activated, these operations are
processed concurrently by multiple database agents. For example, one agent
performs a table scan and passes intermediate results to another agent, which
concurrently starts to process a join operation. This kind of pipeline processing
results in faster execution times for the query.
56 SAP BW and DB2

Query 1
SORT
Query 2
JOIN
SORT
JOIN
SCAN SCAN
TIME
Sequential Parallel processing with

processing intra-partition parallelism
Figure 3-5 Example for query processing with intra-partition parallelism
To scale an SMP system, you can add more processors. However, with shared
memory and shared disks, the DB2 agents are effectively sharing all of the
database data. You can increase the I/O capacity of the database partition
associated with your processors by increasing the number of disks and I/O
adapters, as shown in Figure 3-6. You can establish I/O servers to specifically
deal with I/O requests. Having one or more I/O servers for each disk allows for
more than one I/O operation to take place at the same time.
Figure 3-6 Adding disks and I/O adapters

If you have reached maximum capacity or scalability, you can consider moving to
a system with multiple partitions.
Multiple partitions on a single SMP server

A logical database partition differs from a physical partition in that it is not given
control of an entire server. Although the server has shared resources, database
partitions do not share the resources.
Important: Multiple logical partitions share processors, but disks and memory
(for example, buffer pools) are not shared.
Logical database partitions provide scalability. Multiple database managers

running on multiple logical partitions may make fuller use of available resources
than a single database manager could. When partitioning the database, you
administer and recover each partition separately.
Figure 3-7 illustrates how queries are processed if multiple partitions are
configured.
SELECT ... FROM ...

Inter–partition
parallelism
SELECT ... FROM ... SELECT ... FROM ...
Intra–partition parallelism Intra–partition parallelism

process process
process process
process process
process process
Distributed Table
Database Partition 0 Database Partition 1
Figure 3-7 Query processing in partitioned environment
58 SAP BW and DB2

A coordinating agent splits the query into subqueries, one for each database
partition. Each subquery only processes the subset of the table data that is
located on a particular database partition. This type of parallelism is called
inter-partition parallelism. If intra-parallel is also switched on, each subquery is
not just processed by one agent, but by multiple agents as discussed in the last
section. When a subagent is processing a subquery, it might be required to
communicate with other subagents to exchange data.
Inter-partition parallelism scales better than intra-partition parallelism because

there is virtually no limit to the number of partitions that can be created. Larger
data sets can be split into many smaller subsets, which can be processed
concurrently.
On the other hand, when using intra-partition parallelism to process a query,

there can be limits to the number of concurrent subagents that work on certain
SQL queries. The reason is that not all operations that are required to process
those queries can be executed concurrently. Some operations need to be
finished completely before the following operations can start.
Multiple partitions on multiple SMP servers

This environment is shown in Figure 3-8. In this case the data and processing is
distributed over multiple servers. All the servers are connected by a
communications facility. This environment is referred to by many different
names, including cluster, massively parallel processing (MPP) environment, and
shared-nothing configuration.
The latter name accurately reflects the arrangement of resources in this

environment. For example, with one partition on each server, each partition has
its own set of processors, memory, and disks. In addition, it is of course possible
to logically partition each SMP server in an SMP cluster configuration.
A partitioned database environment allows a database to remain a logical whole,

despite being physically divided across more than one partition. The fact that
data is partitioned remains transparent to most users. Work can be divided
among the database managers; each database manager in each partition works
against its own part of the database.

Communications Facility
Big SMP Server Big SMP Server

Communications Facility Communications Facility
Figure 3-8 Multiple partitions on multiple SMP servers
3.2.4 Cost-based optimizer

To obtain data from database tables applications submit SQL queries. The DB2
SQL Compiler transforms the query into an executable access plan. As part of
this compile process, a powerful DB2 cost-based optimizer analyzes a query. It
consults information in the database catalog to help it process the query. This,
for example, includes information about existing indexes and table statistics, for
example, information about the number of rows in the table or the occurrence
and distribution of values. The optimizer develops alternative strategies, called
access plans, for processing the query. It then chooses the plan it believes will
process the query with the least resource cost.
In DB2, a query is represented as a query graph model in an internal, in-memory

database, as depicted in Figure 3-9.
60 SAP BW and DB2

SQL Query
SQL Compiler
Visual db2exfmt db2explain

Explain Tool Tool
Figure 3-9 The DB2 query compilation process
The model in Figure 3-9 is used to process the query in the following steps:
򐂰 Parse query: The SQL compiler analyzes the SQL query to validate the
syntax. If any syntax errors are detected, the SQL compiler stops processing
and returns the appropriate SQL error to the application that submitted the
query. When parsing is complete, an internal representation of the query is
created and stored in the query graph model.
򐂰 Check semantics: The compiler ensures that there are no inconsistencies
among parts of the statement. As a simple example of semantic checking, the
compiler verifies that the data type of the column specified for the YEAR
scalar function is a datetime data type.
The compiler also adds the behavioral semantics to the query graph model,
including the effects of referential constraints, table check constraints,
triggers, and views. The query graph model contains all of the semantics of
the query, including query blocks, subqueries, correlations, derived tables,
expressions, data types, data type conversions, code page conversions, and
partitioning keys.

򐂰 Rewrite query: The compiler uses the global semantics stored in the query
graph model to transform the query into a form that can be optimized more
easily and stores the result in the query graph model.
For example, the compiler might move a predicate, altering the level at which
it is applied and potentially improving query performance. This type of
operation movement is called general predicate pushdown. In a partitioned
database environment, the following query operations are more
computationally intensive:
– Aggregation
– Redistribution of rows
– Correlated subqueries, which are subqueries that contain a reference to a
column of a table that is outside of the subquery.
򐂰 Pushdown analysis (federated databases): This step is bypassed unless
you are executing federated database queries, that is, queries which access
data that is not in the local database.
The major task in this step is to recommend to the optimizer whether an
operation can be remotely evaluated or pushed-down at a data source. This
type of pushdown activity is specific to data source queries and represents an
extension to general predicate pushdown operations.
򐂰 Optimize access plan: Using the query graph model as input, the optimizer
portion of the compiler generates many alternative execution plans for
satisfying the query. To estimate the execution cost of each alternative plan,
the optimizer uses the statistics for tables, indexes, columns and functions.
Then it chooses the plan with the smallest estimated execution cost. The
optimizer uses the query graph model to analyze the query semantics and to
obtain information about a wide variety of factors, including indexes, base
tables, derived tables, subqueries, correlations and recursion.
The optimizer can also consider different types of pushdown operation,
aggregation and sort, which can improve performance by pushing the
evaluation of these operations to the Data Management Services component.
The optimizer also considers whether there are different sized buffer pools
when determining page size selection. If the database is partitioned, this is
also considered as well as the ability to enhance the chosen plan for the
possibility of intra-query parallelism in a symmetric multiprocessing (SMP)
environment. This information is used by the optimizer to help select the best
access plan for the query.
The output of this step of the compiler is an access plan. This access plan
provides the information captured in the Explain tables. The information used
to generate the access plan can be captured with an Explain snapshot.
62 SAP BW and DB2

򐂰 Remote SQL generation (federated databases): The final plan selected by
the optimizer might consist of a set of steps that operate on a remote data
source. For operations that are performed by each data source, the remote
SQL generation step creates an efficient SQL statement based on the
data-source SQL dialect.
򐂰 Generate “executable” code: In the final step, the compiler uses the access
plan and the query graph model to create an executable access plan, or
section, for the query. This code generation step uses information from the
query graph model to avoid repetitive execution of expressions that need to
be computed only once for a query. Examples for which this optimization is
possible include code page conversions and the use of host variables.
3.2.5 Join methods for distributed tables

The DB2 optimizer selects different methods to join tables that are distributed
over several database partitions. These are some examples:
򐂰 Directed Join
򐂰 Broadcast Join
򐂰 Collocated Join
Figure 3-10 illustrates the Directed Join. On each partition, each row of table A
is sent to one particular partition, where it is joined with the data of table B on
that partition.
Table A
Directed Join
Table B
Partition 0 Partition 1 Partition N
Figure 3-10 Directed Join
During processing of a Broadcast Join, on each partition the data of table A is

sent to each of the other database partitions where it is joined with local data of
table B. This is shown in Figure 3-11.

Table A
Broadcast Join
Table B
Figure 3-11 Broadcast join
A Collocated Join does not require any communication between database

partitions because all corresponding rows of table A and B are on the same
partition. Because no communication is required, this is a very efficient way of
joining distributed tables. The Collocated Join is used during SAP BW
InfoPackage compression. It is explained in more detail in Chapter 4, “Building
SAP BW on DB2” on page 81.
3.2.6 Static and dynamic SQL statements

DB2 supports two types of SQL statements:
򐂰 Dynamic SQL
򐂰 Static SQL
Dynamic SQL statements are cached until they are either invalidated, freed for
space management reasons, or the database is shut down. Because of the
caching, dynamic SQL statements do not need to be compiled often by DB2, but
they must be compiled at least once when you execute the application. If
required, dynamic SQL statements are recompiled implicitly by the DB2 SQL
compiler whenever a cached statement becomes invalid.
Static SQL statements are persistent, because information about access plans
for static SQL is stored in the system catalog tables. When a static SQL
statement is executed, the database manager will use the information stored in
the system catalog tables to determine how to access the data and provide
results for the query.
Important: In SAP environments, dynamic SQL is utilized, because of its

flexibility and lack of administration overhead.
64 SAP BW and DB2

3.2.7 DB2 64-bit
Old and existing 32-bit servers are confined to limited address space, which is
operating system dependent. For new databases, the increased addressable
memory of 64-bit computing can be leveraged to improve the performance for
database operations, because it enables, for example, larger bufferpools and sort
areas. With ample memory, key tables or even entire databases can be made
buffer pool resident. This can be very beneficial for large databases.
DB2 provides a 64-bit engine with full support for 64-bit and 32-bit clients,
management tools, and associated subsystems like the Spatial Extender.
For UNIX platforms (excluding Linux), the installation is the same for both 32-bit
and 64-bit environments. When DB2 Version 8 is installed on a UNIX server, both
the 32-bit and 64-bit files are laid down. One can choose either the 32-bit or
64-bit option at instance creation time, at which point instance links will be set up
to point to the appropriate libraries and executables.
For Windows and Linux, there is a separate install image for 32-bit and 64-bit
environments, since coexistence is not supported for these platforms.
In a DB2 64-bit environment, there are no changes to data on disk — existing

data's cardinality characteristics are the same whether it is used by a 32-bit or
64-bit instance. Databases in the UNIX versions of DB2 (not including Linux) that
are created and operate in 64-bit mode can be moved back to a 32-bit instance
by dropping the 64-bit instance, creating a new 32-bit instance, and then
re-cataloging the database in the new instance.
Attention: This is not supported in a Windows or Linux environment, since

they require different hardware architectures.
3.3 DB2 monitoring and tuning tools

DB2 UDB provides several tools that can be used for monitoring or analyzing
database performance. A good part of this functionality is integrated into the SAP
BW graphical user interface. Transaction ST04 is the main SAP interface to
monitor and administrate DB2. For more information, please check Chapter 4,
“Building SAP BW on DB2” on page 81 and Chapter 7, “Administration of SAP
BW” on page 193.

Here is a brief overview of the available DB2 monitoring and tuning tools:
򐂰 Snapshot Monitor: Captures performance information at periodic points of
time.
򐂰 Event Monitor: Provides a summary of activity at the completion of events
such as SQL statement execution, transaction completion, or when an
application disconnects. In DB2 Version 8, Event Monitors can write data to
DB2 tables instead of files or pipes, thus enabling the information to be
processed more easily using SQL.
򐂰 Explain Facility: Provides information about how DB2 will access the data in
order to resolve the SQL statements.
򐂰 db2batch Tool: Provides performance information (benchmarking tool).
򐂰 CLI/ODBC/JDBC Trace Facility: Traces all the function calls of DB2 CLI
Driver, for problem determination and tuning applications using CLI, ODBC,
or SQLJ, or just to better understand what a third-party application is doing.
򐂰 db2diag.log: Prior to DB2 Version 8, this log had various degrees of
diagnostic information recorded, depending upon the DIAGLEVEL database
manager configuration parameter. There are five valid values for this
parameter, ranging from zero to four. The default value is three, which
captures all errors and warnings. A value of four captures informational
messages as well. This file can be found in the SQLLIB/db2instance
directory.
.
Important: In DB2 Version 8, this log has been split into two —
db2diag.log and db2admin.log
The db2admin.log is used on all platforms for administration notification

messages, while the db2diag.log is used by troubleshooting personnel. The
db2admin.log contains user-friendly messages that enable a DBA to resolve
minor issues. An API is available (db2AdminMsgWrite) that can be invoked to
write messages to the db2admin.log file — messages written by the API are
distinguished from messages written by DB2. A new NOTIFYLEVEL dbm cfg
parameter has been introduced that behaves like the DIAGLEVEL parameter,
and provides granularity with respect to the severity of messages that are
written to the db2admin.log.
򐂰 Design Advisor Wizard: Helps the administrator determine the best set of
indexes for a given workload. A workload contains a set of weighted SQL
statements that can include queries as well as updates. The wizard
recommends which new indexes should be created, which existing indexes to
keep, and which existing indexes to drop. The Design Advisor Wizard can be
invoked from the DB2 Control Center, or using the db2advis utility.
Figure 3-12 shows the recommendation screen.
66 SAP BW and DB2

Figure 3-12 Design Advisor Wizard
򐂰 Configuration Advisor Wizard: Helps to tune the performance of the

database, by updating configuration parameters to match business
requirements. The administrator specifies available memory and workload
details and the wizard recommends appropriate values for the database
configuration parameters. The Configuration Advisor Wizard can be invoked
from the DB2 Control Center. Figure 3-13 shows the performance section of
the Configuration Advisor Wizard.

Figure 3-13 Performance section of the Configuration Advisor Wizard
򐂰 Health Monitor and Health Center: DB2 Version 8 has two features to help
you monitor the health of DB2 systems — the Health Monitor and the Health
Center. These tools add a management by exception capability to DB2 UDB
by alerting the DBA to potential system health issues. This enables the DBA
to address health issues before they become real problems that affect your
system’s performance.
68 SAP BW and DB2

The Health Monitor is a server-side tool that constantly monitors the health of
the instance, even without user interaction. If the Health Monitor finds that a
defined threshold has been exceeded (for example, the available log space is
not sufficient), or if it detects an abnormal state for an object (for example, an
instance is down), the Health Monitor will raise an alert. When an alert is
raised, two things can occur:
– Alert notifications can be sent by e-mail or to a pager address, allowing
you to contact whoever is responsible for a system.
– Preconfigured actions can be taken. For example, a script or a task can be
run.
The Health Center provides the graphical interface to the Health Monitor. The
DBA can use it to configure the Health Monitor, and to view the rolled up alert
state of DB2 Instances and database objects. The DBA can use the Health
Monitor’s drill-down capability to access details about current alerts, and
obtain a list of recommended actions on resolving the alert.
Here are some guidelines to help you understand the use of the tools:
򐂰 Choose the Snapshot Monitor or Event Monitor to gather data about DB2’s
operation, performance, and the applications using it. This data is maintained
as DB2 runs, and can provide important performance and troubleshooting
information.
򐂰 Choose the Explain Facility to analyze the access plan of an SQL statement,
or a group of SQL statements.
򐂰 Choose the db2batch tool to measure and analyze the performance of a set
of SQL statements. Performance times are returned along with Snapshot
Monitor data for analysis. Explain information can be gathered for use by the
Explain Facility.
򐂰 Choose the CLI/ODBC/JDBC Trace Facility to track activity between a CLI
client and DB2. This facility can help pinpoint long running statements, and
analyze the time spent in the client application, DB2, or the network.
򐂰 The Design Advisor Wizard and the Configuration Advisor Wizard should be
run after significant changes to the workload have occurred, or are
anticipated. Given the potential for significant resource consumption by these
wizards, these executions should be relegated to offpeak hours.
򐂰 Use the Health Monitor and Health Center to take a proactive approach to
manage the DB2 environment by exploiting its management by exception
capabilities.

Some of the monitoring tools include information collected by one or more of the
other monitoring tools. For example, db2batch and the Event Monitor also
display information collected by the Snapshot Monitor.
Important: For DB2 databases running SAP applications, SAP provides

configuration advice through EarlyWatch and GoingLife service reports. This
advice should be implemented on the DB2 level, since it contains very specific
insights to DB2.
3.4 DB2 Version 8: a few highlights

This section provides a short overview of some of the interesting features in DB2
UDB Version 8.
3.4.1 Catalog caching

This feature extends the existing catalog cache to provide a cache on all
partitions in an multi-partition system. These caching enhancements help to
improve the overall database performance for the following operations:
򐂰 Compiling SQL statements and binding packages, including usage of
user-defined functions and stored procedures
򐂰 Operations that involve checking database-level privileges
򐂰 Operations that involve checking execute privilege for user-defined functions
and stored procedures
In particular, the performance of applications that are connected at non-catalog

nodes greatly benefit from this feature. This is the case, for example, if you have
multiple SAP BW dialog instances, where each of them is connected to a
different physical database partition (server).
The following information is cached on all partitions:

򐂰 Systable information, including all its packed descriptors
򐂰 Authorization information, including sysdbauth information and execute
privileges of user-defined functions and stored procedures
70 SAP BW and DB2

3.4.2 RUNSTATS enhancements
A number of features for collecting statistics are now available:
򐂰 Statistics gathering during Create Index processing
򐂰 Collection of statistics only for specific columns
򐂰 Collection of statistics on column combinations
򐂰 Page-level sampling
򐂰 Faster (sampled) collection of the DETAILED index statistics
򐂰 Percentage of table pages to sample to collect statistics
3.4.3 Multi-dimensional clustering

Multi-dimensional clustering (MDC) provides an elegant method for flexible,
continuous, and automatic clustering of data along multiple dimensions. This
results in significant improvement in the performance of queries, as well as
significant reduction in the overhead of data maintenance operations, such as
reorganization, and index maintenance operations during insert, update, and
delete operations. Multi-dimensional clustering is primarily intended for data
warehousing and large database environments, and it can also be used in online
transaction processing (OLTP) environments.
MDC enables a table to be physically clustered on more than one key (or
dimension) simultaneously. As shown in Figure 3-14, prior to DB2 Version 8, DB2
only supported single-dimensional clustering of data, through clustering indexes.
In the example on the left side, we assume we have a clustering index on column
region. Using this index, DB2 maintains the physical order of data on pages in
the key order of the index, as records are inserted and updated in the table.
Clustering indexes greatly improve the performance of range queries that have
predicates containing one or more keys of the clustering index. With good
clustering, only a portion of the table needs to be accessed and, when the pages
are sequential, more efficient prefetching can be performed.

All records in
this block are
Region Region from the West
region and
from the year
2000
East East North South West
97 98 99 99 00
Year Year
Prior to MDC With MDC

Figure 3-14 Multi-dimensional clustering
With MDC, these benefits are extended to more than one dimension, or
clustering key. MDC tables are managed by block according to the clustering
dimensions that are defined. Each insert transparently places a row in an existing
block that satisfies all dimensions, or creates a new block. Dimension indexes
are BLOCK-based, which results in much smaller indexes. In addition, MDC
tables also support record-based indexes.
In terms of query performance, range queries involving any combination of

specified dimensions of the table will benefit from clustering. Not only will these
queries access only those pages having records with the correct dimension
values, these qualifying pages will be grouped by extents. Furthermore, although
a table with a clustering index can become unclustered over time as space fills
up in the table, an MDC table is able to maintain its clustering over all
dimensions automatically and continuously, thus eliminating the need to
reorganize the table to restore the physical order of the data.
Important: It is planned to utilize MDC for fact-tables and ODS-tables in the

next SAP BW release.
72 SAP BW and DB2

3.4.4 Concurrency features
In this section we describe a number of DB2 features that can improve
concurrency.
Type-2 indexes
DB2 Version 8 adds support for type-2 indexes. The primary advantages of
type-2 indexes are:
򐂰 They improve concurrency because the use of next-key locking is reduced to
a minimum. Most next-key locking is eliminated because a key is marked
deleted instead of being physically removed from the index page.
򐂰 They support the multi-dimensional clustering feature; that is, they are
required for MDC tables.
򐂰 A table must have only type-2 indexes before online table reorg and online
table load can be used against the table.
򐂰 An index can be created on columns that have a length greater than 255
bytes.
All new indexes are created as type-2 indexes, except when you add an index on
a table that already has type-1 indexes. In this case the new index will also be a
type-1 index because you cannot mix type-1 and type 2 indexes on a table. All
indexes created before DB2 Version 8 were type-1 indexes. To convert type-1
indexes to type-2 indexes, use the REORG INDEXES command.
SQL statements not blocked by non-qualifying rows

This new DB2 feature further increases concurrent processing of SQL
statements. It drastically reduces row locks when processing SQL statements
that use isolation level CS (cursor stability) or RS (read stability) and incorporate
one of the following operations:
򐂰 Table or block index (MDC tables) scan with data predicates to evaluate
򐂰 Row ID (RID) index scan with index predicates.
When such a scan operation is processed, this feature avoids locking

non-qualifying records.

3.4.5 High availability features
In this section we describe a number of DB2 features to enable high availability.
Advanced backup scenarios

Partially implemented in DB2 UDB V7.2, but fully supported in DB2 UDB V8.1,
DB2 now provides support for advanced backup and recovery scenarios which
go beyond the traditional use of the DB2 BACKUP/RESTORE commands.
Modern storage servers are offering methods for near-instant copies for files
through techniques called “flash copy”, “split mirror”, or the like.
By using DB2's new SUSPEND/RESUME WRITE commands, DB2 databases

can safely be copied on these servers within seconds. These database copies
may be initialized using the new db2inidb utility and put to further use, such as
source for normal DB2 backup, hot standby database, or complete database
clone. Using the relocation option of db2inidb, databases, and instances can
easily be renamed. SAP's latest brdb6brt tool provides support to generate
relocation input files for db2inidb.
Important: Multi-terabyte data warehouses can now be backed up with

virtually no performance impact. In addition, this new way to copy DB2
databases allows you to setup SAP test and consolidation systems within
minutes — using automation scripts instead of spending many hours using
traditional backup and redirected restore.
74 SAP BW and DB2

Online table and index reorganization
This new feature enables read and write (online) table access when reorganizing
a table. It also provides the capability for monitoring the status and progress of a
table reorganization. There are two ways of reorganizing a table:
򐂰 Reorganizing a table according to an index. The result is that the table is
clustered according to this index as shown in Figure 3-15. In addition,
freespace is reclaimed.
򐂰 If no index is used, only freespace is reclaimed.
Table available for

Select, Insert,
Update, and
Delete access
during Reorg
Figure 3-15 Online table reorganization according to an index
An online reorganization is allowed only on tables with type-2 indexes and

without extended indexes. It is executed in-place. That is, rows are moved within
the existing table object to re-establish clustering, reclaim free space, and
eliminate overflows. This results in minimal extra storage requirements. In
addition, you can perform the table reorganization incrementally by interrupting it
and then continuing the operation at a later time.

The processing steps for online reorg using an index are shown in Figure 3-16.
Is used, when an index Data Records

is specified, or a Free Space
clustering index
defined Time
Vacate
11 Page Ranges are

vacated
Fill
Then, the free Vacate

22 pages are filled
based on the Fill
clustering index
Vacate
DB2 REORG TABLE ....INDEX .... INPLACE ....

Figure 3-16 Online reorg using an index
During online index reorganization, the entire index object (that is, all indexes on
the table) is rebuilt. A shadow copy of the index object is made, leaving the
original indexes and the table available for read and write access. Any concurrent
transactions that update the table are logged. Once the logged table changes
have been forward-fitted and the new index (the shadow copy) is ready, the new
index is made available. While the new index is being made available, all access
to the table is prohibited.
Online Load
This feature enables read access to tables during DB2 LOAD operations. The
tablespace which is loaded is available for full read/write access.
Online Drop Container and addition of Stripe Sets

Tablespace administration has been further enhanced with DB2 Version 8. With
the previous version you could already resize (increasing/decreasing) tablespace
containers online. In addition, you can now drop a tablespace container without
shutting down the database. You can now also add new containers without
needing to redistribute the existing data, by adding a new stripe set.
76 SAP BW and DB2

Online buffer pool configuration
DB2 Version 8 now allows to administrate bufferpools online. You can perform
the following operations without the need to stop and start the database:
򐂰 Change the size of bufferpools
򐂰 Add additional bufferpools
򐂰 Delete existing bufferpools
Online parameter changes and automatic parameter changes

It is now possible to change database and database manager parameters online,
for example, the sortheap parameter. In addition, you can now flag certain
parameters as automatic. If you set a parameter to automatic, DB2 will
automatically adjust the parameter to reflect current resource requirements.
3.4.6 Connection concentrator

For applications with many simultaneous user connections, the connection
concentrator may improve performance by allowing many more client
connections to be processed efficiently. It also reduces memory use for each
connection, and decreases the number of context switches.
The MAX_CONNECTIONS parameter determines the maximum size of the idle agent
pool. If more agents are created than is indicated by the value of this parameter,
they will be terminated when they finish executing their current requests, rather
than be returned to the pool.
The connection concentrator is enabled when MAX_CONNECTIONS is greater than

MAX_COORDAGENTS. In this case, there may be more connections than coordinator
agents to service them. An application is in an active state only if there is a
coordinator agent servicing it. Otherwise, the application is in an inactive state.
Requests from an inactive application will be queued until a database
coordinator agent is assigned to service the application.
With connection concentrator enabled, the MAX_CONNECTIONS parameter will be

used as a guideline for how large the agent pool will be when the system work
load is low. A database agent will always be returned to the pool, no matter what
the value of MAX_CONNECTIONS parameter is. Based on the system load and the
time agents remain idle in the pool, the logical agent scheduler may terminate as
many of them as necessary to reduce the size of the idle pool to this parameter
value. As a result, both of these parameters can be used to control the load on
the system.

Figure 3-17 describes the connection concentrator concept.
N Client N Client
Connections Connections
N Coordinator N Coordinator
Connections Connections
f(N) SubAgents
f(N) SubAgents
Bufferpool(s) Bufferpool(s)
Page Cleaners Page Cleaners

and Preftechers and Preftechers
Tablespaces Tablespaces
Enable by setting MAX_CONNECTIONS > MAX_COORDAGENTS

For example:
UPDATE DBMCFG USING MAX_CONNECTIONS 5000 MAX_COORDAGENTS 500
Figure 3-17 Connection concentrator concept
SAP dispatches database connections on the application level. Therefore the

use of the DB2 connection concentrator is not necessary in an SAP environment.
3.4.7 Merge statement

The MERGE statement combines an UPDATE and an INSERT operation in one
statement. Here is an example where this feature can be deployed. Let’s assume
you have the following common database design:
򐂰 A master table contains existing or current knowledge of a domain (for
example, a parts table).
򐂰 A transaction table contains a set of changes to be applied to the master
table, for example, updates to objects that already exist in the master table, or
the creation of new objects that should be inserted into the master table.
To apply the changes from the transaction table to the master table, prior to DB2
Version 8, two separate operations were required:
򐂰 An UPDATE operation for those rows already existing in the master table
򐂰 An INSERT operation for those rows that do not exist in the master table
78 SAP BW and DB2

The MERGE-Statement makes processing of these separate operations more
efficient as well as easier for the user to specify. Example 3-1 gives the syntax.
Example 3-1 Syntax of the MERGE statement

MERGE INTO account AS a
USING (SELECT id, sum(balance) sum_balance FROM transaction
GROUP BY id) AS t
ON a.id = t.id
WHEN MATCHED THEN
UPDATE SET
balance = a.balance + t.sum_balance
WHEN NOT MATCHED THEN
INSERT (id, balance) =
(t.id, t.sum_balance);
3.4.8 Multi-FixPak install for UNIX

This feature was requested by customers. It allows you to have different FixPak
levels on the same server for a number of reasons:
򐂰 Especially, SAP customers usually have a production system running on a
particular level of code, and do not want to switch to a new FixPak level until it
is thoroughly tested.
򐂰 Different teams from a customer may require different fixes. A team may not
wish to switch to a different level once it has started using a level of code that
is suited to its needs.
Prior to DB2 Version 8, multiple servers were required to run more than one level
of DB2 at the same version.
In addition, you now have different options to install FixPaks:

򐂰 Regular FixPak: This is installed on top of the existing code, and behaves
exactly as FixPaks did in the past.
򐂰 Alternate FixPak: This is similar to a fully installable image. It has the same
level of code as the regular FixPak. Utilities are provided to install this as a
“FixPak” — but it is for command line use only.

80 SAP BW and DB2
4
Chapter 4. Building SAP BW on DB2

This chapter describes how SAP Business Information Warehouse is deployed
on DB2.
IBM has several teams of IBM developers located at SAP AG in Germany. In

1998 a new dedicated team of IBM developers was gathered together to work
along with the SAP Business Information Warehouse developers to port SAP
BW functionality to DB2 UDB ESE. Whenever IBM ships a new DB2 release, this
team surveys the new DB2 features and considers how they can be used to
improve SAP BW performance, scalability, and ease of maintenance. Selected
DB2 features are then incorporated into SAP BW.
Another joint IBM/SAP team is working on the integration of DB2 with SAP
products in general. They have developed, for example, a powerful graphical
interface to maintain and monitor DB2 from within SAP applications.
Yet another joint IBM/SAP team develops code that is part of the SAP installation
tool, SAPinst, to facilitate the installation process of SAP BW on DB2 UDB ESE.
In the following sections we provide an overview of selected DB2 features,

explain how they are utilized, and illustrate the value for the customer.

4.1 Value of building SAP BW on DB2 UDB ESE
What is the specific value for SAP BW customers using DB2 UDB Enterprise
Server Edition as the database management system? Here is a brief list of
capabilities that can help begin to answer that question:
򐂰 Lower total cost of ownership (TCO): This is low in comparison to other
non-scalable database platforms.
򐂰 Scalability: This is DB2’s unique ability to attach additional database servers
to an existing SAP BW environment, as well as being able to exploit all
database servers within a single SAP BW query.
򐂰 High performance: This is due to several DB2 features that are specifically
designed for data warehouse applications (such as the star join) and the
different types of parallelism that are supported by DB2 UDB ESE.
򐂰 Ease of use: Tight integration of DB2 with SAP BW and DB2 features both
serve to simplify administration and increase availability.
4.1.1 Scalability
When SAP talks about SAP Business Information Warehouse system demands,
scalability continues to be one of the most important requirements. For SAP BW,
the limiting factor is the computing power of the database server. With DB2 UDB
ESE, IBM’s parallel and scalable database, this limitation does not exist.
The new SAP product strategy implies that SAP BW (as one component of SAP
NetWeaver) will be part of almost every SAP installation. As described in 1.6,
“SAP BW customer scenario” on page 15, during the life cycle of an SAP
implementation, the following factors lead to a continuous growth of the SAP BW
system:
򐂰 More data has to be loaded in a given timeframe: Several SAP modules
are connected to SAP BW over a certain time frame. For example, a
company starts to implement Human Resources (HR) and in a later step
Finance (FI). This results in more data that has to be uploaded in a given
maintenance window (for example, during the night or the weekend).
򐂰 The total volume of data in SAP BW constantly grows: At least for the first
4 to 5 years, data volume grows because many customers want to have
online access to at least 4 years of data.
򐂰 The number of concurrent SAP BW queries increases: This happens
because with a growing number of connected SAP BW systems, the number
of users that need to run queries will also increase over time.
82 SAP BW and DB2

򐂰 The execution time of BW queries increases: This is primarily due to the
growing volume of data that must be processed, and the growing complexity
of BW queries.
This growth is likely to result in bottlenecks in the SAP BW system. To resolve or

avoid those bottlenecks, a scalable system is required. Figure 4-1 shows a
typical SAP BW 3-tier system environment. SAP BW is scalable at the
presentation layer and the application layer, to resolve performance bottlenecks.
Important: With DB2 UDB ESE, SAP Business Warehouse is also scalable at
the database server level.
DB2 Multi-Partitioning concept:

Shared-Nothing = Each partition Unique to DB2: Scalability
accesses its own local data
Fast
Communication
SAP BW
Database
Server
SAP BW
Application
Server
Network
Presentation
Server
Figure 4-1 DB2 UDB ESE provides the unique ability to scale SAP BW at the database level
Chapter 4. Building SAP BW on DB2 83

This means you can attach additional physical machines to the existing database
server and distribute both data and processing over all the database servers.
DB2 supports a shared-nothing architecture, as opposed to shared-data
architectures, so each database server can have its own local attached storage
and work on a subset of the total Business Warehouse data. This arrangement
has several advantages:
򐂰 Improved scalability: Due to the shared-nothing architecture, SAP BW
queries scale almost linearly, as more servers are attached to the DB2
database system. For details on the actual scalability factors that are
achieved for the most performance critical SAP BW operations, for example,
dataload and BW queries, please refer to Chapter 10, “Scalability factors of
SAP BW on DB2 UDB ESE” on page 317.
򐂰 Lower TCO: Several smaller servers with local attached storage are less
expensive than a large SMP server. More details on TCO are provided below.
A unique feature of DB2 is the ability to fully exploit all available database servers
to process a single SAP BW query. This is depicted in Figure 4-2.
Select * from A,B FRA 15 27 . . . . . .

W here A.C = B.C AKL 27 13 . . . . . .
Optimizer
Engine Engine Engine
Table A
Table B
Figure 4-2 DB2 exploits all available database servers to process a single query
84 SAP BW and DB2

Chapter 3, “DB2 UDB ESE technical overview” on page 43, provides more
details about the DB2 architecture and the different types of parallelism that are
supported.
4.1.2 High performance

DB2 UDB ESE delivers high performance due to parallel query processing and
other unique features, some of which are specifically designed for data
warehouse applications. Among those features are:
򐂰 Inter-partition parallelism (parallel processing on multiple DB partitions)
򐂰 Intra-partition parallelism (parallel processing on a single partition)
򐂰 Cost based optimization of queries
򐂰 Parallel database backup/restore
򐂰 Star join and hash join
򐂰 Dynamic bitmap indexes
We will look at these features in more detail later.
4.1.3 Ease of administration

Figure 4-3 shows an example of the DBA Cockpit 6.40. The DBA Cockpit is a
graphical user interface that was developed by a joint IBM/SAP team to
administer and monitor DB2 from within SAP. For more information, refer to 4.3.7,
“New features of the DBA Cockpit 6.40” on page 106.

Figure 4-3 Graphical front-end to administrate and monitor DB2 from within SAP
DB2 tight integration with SAP BW greatly simplifies administration and

monitoring tasks. You can use the graphical front-end to resize tablespaces, add
tablespace containers, analyze query access plans, analyze lockwaits or
deadlocks, take snapshots and analyze resource consumptions, and schedule
database statistics, as examples. Please refer to Chapter 7, “Administration of
SAP BW” on page 193 and Chapter 8, “SAP BW performance” on page 249 for
details.
86 SAP BW and DB2

In addition, DB2 provides several features that help to simplify database
management. Please refer to Chapter 3, “DB2 UDB ESE technical overview” on
page 43 for examples regarding:
򐂰 Maintenance operations on tablespaces
򐂰 Support for automatic management of DB2 database resources
򐂰 Improved database availability during different operations such as table
reorganization and table load.
4.2 Business advantage: the value proposition

We have discussed many functions and features of DB2 and SAP BW that
enable a robust and powerful data warehousing implementation. Now let us see
how that translates into business benefit, and determine a real value proposition
for the use of the products together.
4.2.1 Low TCO

DB2 has what is called a shared-nothing architecture that has a unique ability to
scale at the database level. This results in a lower TCO for an SAP BW
implementation, for the following reasons:
򐂰 Multiple physical servers are less expensive than one large SMP database
server.
򐂰 Storage that is attached locally to each server is less expensive than a large
shared storage system.
򐂰 With DB2 you can defer the cost for hardware up to the time when you
actually need the hardware. This decreases your initial investment, and your
long term investment since costs for hardware typically decrease over time.
The fact that you can add additional DB servers as needed, enables you to
start with a smaller machine and attach additional machines to your database
system as required.
With other database platforms you would have to purchase a server that is
powerful enough to handle the final stage of your system’s growth path. And
that final stage might not be reached until several years in the future.

4.2.2 Reduced sizing risk and cost
Performing a reliable hardware sizing is a difficult task for any system
implementation, including SAP BW. Figure 4-4 shows the relationship between
accuracy and complexity/costs for sizing SAP BW. The more accuracy you need,
the more complex and expensive is the sizing.
Basic tools /
Extrapolation
Accuacy
More from Customer tailored
T-Shirt sizing
sophisticated evaluation / test benchmark
sizing approach systems
Complexity / effort / costs

Figure 4-4 Relationship between accuracy and costs for SAP BW hardware sizing
In its sizing guide, “Sizing - ASAP for BW Accelerator”, SAP clearly points out
that:
򐂰 Their detailed sizing approach is based on assumptions, and that in some
cases it may result in an inaccurate sizing.
򐂰 A reliable sizing can only be performed with a customer tailored benchmark.
Important: DB2 helps mitigate the risk of inaccurate hardware sizing.

Because of its scalability, in case of a hardware bottleneck, you can easily
upgrade your database system by attaching additional servers.
On other database platforms a bottleneck, due to an inaccurate hardware sizing,

might require a migration to a new (larger) SMP machine. By doing so you would
lose your investment in the existing hardware and the time and implementation
effort expended prior to the realization.
However, because of DB2’s flexible scaling approach, you may even be able to
begin implementation without an expensive customer tailored benchmark.
Please refer to 6.1, “Sizing SAP BW on DB2” on page 122 for more details on
SAP BW sizing.
88 SAP BW and DB2

4.3 SAP BW on DB2: value details
In this section we describe a number of features, benefits, and capabilities
realized when running SAP BW on DB2 UDB ESE. These are significant
advantages of DB2, and can enable a robust implementation for SAP BW users.
The following sections discuss some details that support the value statements
made in 4.1, “Value of building SAP BW on DB2 UDB ESE” on page 82.
4.3.1 Architecture and features

In this section we describe the architecture of SAP BW on DB2. We also discuss
a number of features significant to the combination of the products. Figure 4-5
shows the different software layers of SAP BW when used with DB2:
򐂰 The SAP BW functionality is represented by the top layer, which is
implemented in ABAP (Advanced Business Application Programming).
򐂰 The SAP Basis layer provides common functions, which are used in most
SAP modules.
򐂰 The SAP Kernel is the base layer and represents the basic support functions
and capabilities.
򐂰 All the SAP software then interfaces with the infrastructure database
management system component, which is DB2 UDB ESE.
Those functions for which a special implementation exists, for DB2 UDB ESE,
are shown in the boxes with dashed lines. As you can see, there is also
DB2-specific functionality for installation and upgrade.
SAP Business Information Warehouse (ABAP)

Compression, Delete, Utilities,
Database SAP BW Query Processing
dependent
parts SAP Basis Layer (ABAP)
Base Tools Performance Monitor, DBA
Cockpit, Dictionary, Explain
SAP Kernel (C)

SAP Tools Dispatcher, Task Handler, Dynpro Interpreter,ABAP Interpreter,
Buffer Manager,Data-Base Access Manager, DB Interface (C)
Installation
Administration Database Support Layer Performance Monitor Interface,
Upgrade (DBSL), Trace (CLI) DBA Cockpit Interface (CLI,C-APIs)
DB2 UDB ESE

Figure 4-5 Database dependent parts of SAP BW on DB2 UDB ESE

Here are some of the specific aspects of using DB2 with SAP BW:
򐂰 DB2 database layout: A specific DB2 database layout is used for SAP BW.
򐂰 SAP BW functions: For these functions, a special implementation exists
when running on DB2 UDB ESE (the boxes with dashed lines, in the top layer
of Figure 4-5). SAP typically implements their applications independent of the
underlying database platform, using OpenSQL. But for some performance
critical operations, special database dependent functions are deployed. This
often involves the development of specific ABAP code.
򐂰 Important DB2 features: Certain DB2 features are deployed transparently
by SAP BW, such as those for which no special application development is
required.
Each of these topics is discussed further in the following sections.
4.3.2 Database layout

If you are not familiar with the database partitioning concept of DB2, we
recommend reading Chapter 3, “DB2 UDB ESE technical overview” on page 43
first. Also refer to the guide, SAP BW3.5 Administration Tasks in Multi-Partition
Installations: IBM DB2 UDB for UNIX and Windows, which provides many layout
suggestions.
Figure 4-6 shows the default tablespace, and buffer pool, layouts used for SAP
BW. By default, the system is installed with only one database partition. The
following tablespaces exist:
򐂰 Multiple tablespaces for R/3 tables, all with 4K page size. Those are not
specific to SAP BW.
򐂰 One tablespace for dimension tables and one for indexes on dimension
tables, both with 4K page size.
򐂰 One tablespace for InfoCube and aggregate fact tables and one for
corresponding indexes, both with 16K page size.
򐂰 One tablespace for PSA and ODS tables and one for corresponding indexes,
both with 16K page size.
򐂰 One tablespace for temporary tables with 4K page size.
򐂰 One tablespace for temporary tables with 16K page size.
The following bufferpools are created as part of a default installation:

򐂰 IBMDEFAULTBP, which is assigned to all tablespaces with 4K page size.
򐂰 BP_STD_16K, which is assigned to all tablespaces with 16K page size.
90 SAP BW and DB2

Part 0 Part 1 Part 2 Part N
IBMDEFAULTBP
for R/3, master- Buffer
and dim. data pools
BP_STD_16K for fact, ODS, PSA data
R/3 tables
DIMD, DIMI
Fact and aggregate tables (FACTD, FACTI)

Table-
PSA and ODS tables (ODSD, ODSI) spaces
PSAPTEMP
PSAPTEMP16
Figure 4-6 Default buffer pool and tablespace layout
By default, only one database partition is created: If you initially install the
system with more than one database partitions, the following tablespaces and
bufferpools are created on all partitions:
򐂰 Tablespaces for InfoCube and aggregate fact tables
򐂰 Tablespaces for PSA- and ODS tables
򐂰 Temporary tablespace PSAPTEMP16
򐂰 Buffer Pool BP_STD_16K
Important: If you plan to scale your database system by adding servers later
on, you should configure multiple partitions during SAP BW installation. It is
much easier to install SAP BW with multiple partitions, than to add database
partitions later on. Multiple partitions are required to use multiple servers for
your database system.
Multiple partitions are also a prerequisite to deploy inter-partition parallelism,

which can significantly improve performance for specific SAP BW operations
when running on servers with multiple processors.

Figure 4-7 shows the suggested tablespace and buffer pool layout for multiple
Part 0 Part 1 Part 2 Part N

IBMDEFAULTBP
For R/3, master-
and dim. data Buffer
pools
BP_STD_16K for fact, ODS and PSA data
Aggregate data
R/3 tables
Dim. tables
Aggregate tables InfoCube1
Fact tables
Dim. tables
Aggregates InfoCube2 Table-
Fact tables spaces
ODS activation
queue
ODS active/change log table
PSA tables
PSAPTEMP
PSAPTEMP16
Figure 4-7 Suggested database layout on multiple partitions
These are the primary differences when compared to the default layout:
򐂰 The data for fact, PSA, and ODS active tables is not located in partition 0.
This reduces the total backup and restore times, because partition 0 must
always be backed up first and restored first.
򐂰 For large InfoCubes, fact data is in separate tablespaces for easier
manageability.
򐂰 Aggregate fact data is in one or more separate tablespaces. This enables
you, for example, to assign a dedicated buffer pool to aggregates. As
aggregates are small when compared to InfoCubes, and are more frequently
accessed, this separation can considerably increase overall buffer pool hit
ratio. If aggregate fact tables are small, they should not be distributed. This
will avoid unnecessary inter-partition parallelism.
92 SAP BW and DB2

򐂰 Dimension tables can also be separated by InfoCube. However, this may not
be necessary if there are only small dimension tables.
򐂰 Separate tablespaces are used for PSA and ODS tables. You might consider
putting them on different physical disks. This can improve data load
performance when loading from the PSA into the ODS.
򐂰 Multiple tablespaces are used for ODS tables: one tablespace only on
partition 0 for the activation queue, and another tablespace for the ODS
active tables and change log tables, which are distributed on all database
partitions. This separation improves performance, since you can put the
tablespaces on different physical disks. During activation, data is read from
one tablespace (activation queue) and written to the other tablespace (active
table and change log).
򐂰 A dedicated buffer pool is used for aggregate data. Once again, this can help
to improve overall buffer pool hit ratio.
4.3.3 Parallel processing on multiple database partitions

When you extend your database management system by attaching additional
database servers and configuring multiple database partitions, DB2 deploys the
additional hardware using inter-partition parallelism. This type of partitioning is
called physical partitioning. It improves performance for the following operations:
򐂰 SAP BW queries
򐂰 Dataload into PSA and data targets
򐂰 Aggregate build and rollup
򐂰 Compression of requests
򐂰 Index build
򐂰 Collecting runstats
򐂰 Table reorganization
򐂰 Database backup/restore
Partitioning an existing database without attaching additional servers (logical

partitioning) will also speed-up most of the above operations, if the database is
running on an SMP (multi-processor) machine. This is so because the available
CPUs can be deployed more effectively with inter-partition parallelism.
Chapter 10, “Scalability factors of SAP BW on DB2 UDB ESE” on page 317,
describes scalability factors that are achieved for the most performance critical
operations when going from one to multiple database partitions.
The following sections discuss topics that are related to SAP BW systems built
on DB2 databases with multiple database partitions.

Connecting SAP BW Instances to multiple database partitions
Figure 4-8 depicts an SAP BW system with multiple database servers and
multiple application servers. SAP BW Instances can only connect to the first
logical database partition of each DB2 database server. If you have only one
database server with multiple logical database partitions, all SAP BW Instances
connect to database partition 0. If multiple SAP BW Instances are configured,
they should be distributed (connected) evenly to the database servers as shown
in Figure 4-8. The goal is to distribute the workload evenly to all database
servers.
BW BW BW BW
Application Application Application Application
Server 1 Server 2 Server 3 Server 4
DB Server 1 DB Server 2
Partition 0 Partition 1 Partition 2 Partition 3
R/3,
master,
dimension
Fact tables
tables
PSA and ODS tables
TCP/IP Communication
Figure 4-8 Multiple SAP BW Instances connected to multiple database servers
If all SAP BW Instances are connected to the first database server, this server
can become a bottleneck. The reason is that the database server, the database
partition to which the instance connects, has to compile (prepare) all SQL
statements that are issued by this instance. Preparing an SQL statement can be
computationally expensive, especially when executing SAP BW queries.
The workload on a database server can be reduced as follows:

򐂰 Connect fewer SAP BW Instances to that server. This means viewer agents
prepare SQL statements on this server.
򐂰 Reduce the number of database partitions on that server. This reduces the
number of database agents that execute statements on this server.
94 SAP BW and DB2

In general, database servers which do not hold partition 0 have to communicate
via an external network or switch with the database server that contains partition
0 to access R/3 tables, master data tables, and dimension tables. Those tables
are all located on partition 0.
Communication between partitions might also be required during processing of

BW queries, to exchange intermediate results between those DB2 database
agents that are processing the query.
Important: A fast network connection between the database servers is

required if your database is located on multiple servers. The connection could
be accomplished by a switch, for example.
Partitioning keys for PSA, ODS, and fact tables

When SAP BW 3.5 is installed, and PSA, ODS, and fact tables are activated,
SAP BW automatically creates a partitioning key on those tables. The goal of
selecting a particular partitioning key is to guarantee an even distribution of the
corresponding data on all database partitions. It is important to have an even
distribution of the workload for all subagents that are processing a query.
In SAP BW the following partitioning keys are used:

򐂰 PSA tables: column RECORD
򐂰 ODS tables:
– Activation Queue Tables (/BIC/A..40): column RECORD
– Change Log Tables (/BIC/A..00): column RECORD
– Active Tables (/BIC/A..50): key fields of ODS object
򐂰 Fact tables: All dimension key columns, but not the request dimension:
DIM1, DIM2, DIM3, …., DIM-Time, DIM-Unit
Notice that the partitioning key for fact tables differs from the partitioning key for
PSA tables. Therefore, when loading from PSA into an InfoCubes, records might
be relocated to different partitions. This results in communication between
Inter-partition parallelism during SAP BW query processing

When multiple database partitions are configured, SAP BW queries are
processed concurrently on each partition. For details regarding inter-partition
parallelism during query processing, please refer to 3.2.3, “Parallel processing
and partitioning” on page 55.

DB2 insert buffering
Insert buffering is a DB2 feature that significantly increases SQL INSERT
performance on distributed tables, such as the PSA, ODS, and fact, tables. This
DB2 feature is transparent to SAP BW.
BW Application
Server
Array Insert
Buffer Buffer
Partition 1 Partition 2
PSA, ODS, Fact tables
Figure 4-9 Insert buffering
Buffered inserts cause the following activities to occur:

򐂰 The database manager opens one 4 KB buffer for each database partition on
which the table resides (in Figure 4-9 we only show the buffers on partition 0).
򐂰 The INSERT statement issued by SAP BW causes the row (or rows) to be
placed into the appropriate buffer (or buffers).
򐂰 The database manager returns control to SAP BW.
򐂰 The rows in the buffer are sent to the partition when the buffer becomes full,
or when an event occurs that causes the rows in a partially filled buffer to be
sent. A partially filled buffer is flushed when one of the following events
occurs:
– The application issues a COMMIT (implicitly or explicitly through
application termination) or ROLLBACK.
– The application issues another statement that causes a savepoint to be
taken.
96 SAP BW and DB2

In any of these situations, where another statement closes the buffered insert,
the coordinator partition waits until every database partition receives the
buffers and the rows are inserted. It then executes the other statement (the
one closing the buffered insert), if all the rows were successfully inserted.
This buffering avoids single record transfers between partitions, which would
result in much higher overall communication time.
To activate insert buffering, you have to add the following two lines to the
db2cli.ini file, which is located in /db2/db2<sid>/sqllib/cfg:
[common]
InsertBuffering=2
Collocated joins during compression of requests

During compression of requests, data is transferred from the F-fact table to the
E-fact table of the InfoCube or aggregate. Figure 4-10 depicts a compression
example with the following processing steps:
1. Insert rows from the F-fact table into the E-fact table, which have a
combination of dimension IDs that do not yet exist in the E-fact table.
2. Update rows of the E-fact table with records from the request that have the
same combinations of dimension IDs (for example, add key figures).
3. Delete the request from the F-fact table after compressing it.
Package Dim1 Dim2 Key Fig.

0 1 3 50 45
0 2 2 45
50 25
45
1 3 1 10 15 E-Fact Table
1.
3. 2. 1 3 1 10 15
1 2 2 5 20
... F-Fact
F-FactTable
Table
Figure 4-10 Compression of a request
When SAP BW is running on DB2, it uses searched INSERT and UPDATE

statements to compress requests. Depending on the type of the InfoCube
(cumulative or non-cumulative), it uses between two and four searched
statements to update the E-fact table. Using searched statements has the
advantage that all fact data is processed locally on the database server. No fact
data has to be transferred between database and application server.

Part of the searched INSERT and UPDATE statements is a join between F-fact
and E-fact tables. These tables are collocated, which means that they are on the
same partitions and have the same partitioning key. For this reason, DB2 can
use a collocated join, as shown in Figure 4-11.
On each partition, it joins only the local data of the F-fact and E-fact tables on
that partition. No communication between partitions is required. Therefore, the
compression scales linearly with the number of database servers. Thus, if you
double the number of database servers, the request is compressed twice as fast.
Table A
Collocated Join
Table B
Figure 4-11 DB2 uses a collocated join when compressing requests
Collocated joins are also used in other situations. For example, dimension tables
are locally joined with master data or hierarchy tables. In general, collocated
joins can be used for tables that belong to the same nodegroup, or for tables that
are not distributed and reside on the same partition.
Table reorganization and index build on multiple partitions

For partitioned tables, index build and table reorganization run concurrently on
each of the partitions. This results in improved performance.
Collecting runstats on multiple partitions

Collecting runstats is done for data that is located on the connected partition.
This means that the runstats command works only on a subset of the table data.
This results in faster creation of database statistics.
It is planned that, in a future FixPak, DB2 Version 8 will provide the option to
collect statistics on all database partitions.
Database backup/restore on multiple partitions

You always have to back up and restore partition 0 first, because it contains the
system catalog tables. The rest of the partitions can then be backed up and
restored concurrently, which results in better performance. To reduce backup
and restore times, try to keep partition 0 small. For example, do not put fact or
PSA tables on this partition.
98 SAP BW and DB2

Log file management on multiple partitions
Each partition has its own private log files. These are archived and retrieved
concurrently on each partition by the user exit. An example of the log file
archiving procedure on multiple partitions is shown in Figure 4-12.
Tivoli Storage Manager

User brarchive
Exit User brrestore
Exit User
Exit
Log Log Log Log Log

Files Files Files Archive Retrieve
User User User
Exit Exit Exit
Figure 4-12 Log file management example on multiple database partitions
In this example, indirect archiving to Tivoli Storage Manager (TSM) is used. The
user exit program (db2uext2) copies log files from log_dir to the log_archive
directory. From there, the files are then archived to TSM by the brarchive
program. The following shared directories are used for log file archiving and
retrieval when using indirect archiving: /db2/<DBSID>/log_archive,
/db2/<DBSID>/log_retrieve.
In addition to indirect archiving, you can also use direct archiving. Figure 4-13
provides a complete overview of the different archiving methods. More details
can be found in the database administration guide, SAP on IBM DB2 Universal
Database for UNIX and Windows.

IBM Software Group
Direct archiving TSM
DB2 LOG DIR User exit VENDOR

Control Center
Extension
STANDBY
DIR
DISK
TSM
Indirect archiving ADMIN DB
VENDOR
TDP
LOG
DB2 LOG DIR User exit brarchive
ARCHIVE
TAPE
STANDBY LOG
brrestore
DIR RETRIEVE
SCRIPT
Figure 4-13 Different archiving methods
4.3.4 Intra-partition parallelism

Intra-partition parallelism can speed-up several database operations, such as
SQL query processing (sort, joins, etc.) or index build as examples. It can be
used on partitioned and non-partitioned databases. It can be switched on or off
by using the database manager parameter INTRA_PARALLEL, and it is
transparent to SAP BW.
For more details regarding intra-partition parallelism during query processing,

refer to 3.2.3, “Parallel processing and partitioning” on page 55.
4.3.5 SAP BW query processing on DB2

This section provides a discussion of a number of topics relevant to SAP BW
query processing on DB2 UDB. These are some of the DB2 advantages that will
enable scalability, as well as enable improved levels of performance.
Dynamic SQL statements versus database views

In SAP BW 3.x, Open SQL is used to process SAP BW queries. This
implementation is database independent. Because SAP basis 6.20 allows the
creation of dynamic SQL statements, SAP BW 3.x can avoid the use of database
views.
100 SAP BW and DB2

In SAP BW 2.x, native SQL is used for BW query processing and views are
created and dropped on most database platforms during BW query processing.
There are some issues when using views, such as these:
򐂰 A database catalog access is required to create or drop a view, which can
impact performance.
򐂰 Many SAP Basis dictionary tables, such as DDNTT and DDNTF, are
accessed when a view is created.
򐂰 The view only exists during execution of the BW query. Therefore, the
analysis of BW queries with the ST05 trace is not possible afterwards.
Attention: When running SAP BW 2.x on DB2 UDB ESE, DB2 Common
Table Expressions are used, instead of views, to improve query performance.
Literals versus host variables

On DB2 UDB ESE there is an option to use host variables or literals for
processing queries (see SAP Note 542346). SAP BW uses literals by default.
Literals allow the DB2 optimizer to use distribution statistics (histograms) to
optimize the query access plan. This can result in considerably improved
performance, especially in the case of very long running, complex queries.
If you only have short running queries (< 3 seconds) and often execute the same
BW queries with identical restrictions, it may be useful to use host variables for
SAP BW queries. In this case, DB2 can reuse previously generated access
plans. This avoids compilation of queries and can improve performance.
A description of how to switch between host variables and literals is given in

8.2.4, “Recommended configuration parameters” on page 256.
Queries with hierarchies

Figure 4-14 shows an example of an SAP BW query with restrictions on
hierarchies.

Sales
BW Query uses
North America
a hierarchy to Asia & Pacific
select customers US Canada Europe
from certain
East West
regions East Central
Figure 4-14 SAP BW query with restriction on hierarchy
To process such a query, SAP BW creates hierarchy result tables

(/BI0/02000...). These tables can be reused by other SAP BW queries. To
combine these results tables, it uses views on most database platforms as
shown in the following example.
Example 4-1 Combining hierarchy result tables

VIEW ( table1 UNION table2 UNION ...tableN)
Attention: When running on DB2 UDB ESE, Common Table Expressions are
used to combine hierarchy result tables instead of views. This improves query
performance.
102 SAP BW and DB2

Star joins with dynamic bitmap indexes
The following example shows the simplified structure of a typical SAP BW query:
Example 4-2 Structure of SAP BW queries

SELECT FROM sales sa, store st, period pe, product pr
WHERE
st.store_id = sa.store_id AND
pr.product_id = sa.product_id AND
pe.period_desc =sa.period_desc AND
pe.year between 1995 and 1996 AND
pr.producer in ('TETRA','WISA')
GROUP BY st.store_id, pe.year
In the example, fact table sales is joined with its dimension tables store, period,
and product. In addition, a WHERE condition (predicate) on table product is
defined.
Important: If the foreign key columns in the fact table are single-column
indexes, which is the case in SAP BW, and there is a relatively high selectivity
across all dimension tables, DB2 can use a star join with index ANDing. This
can significantly increase performance.
This join method can be accomplished through the following steps:

1. Process each dimension table by performing a semi-join between the
dimension table and the foreign key index of the fact table to determine
qualifying rows of the fact table.
2. Hash the fact table row ID (RID) values to dynamically create bitmaps.
3. Use AND predicates against the previous bitmap for each bitmap. This is
called index ANDing.
4. Determine the surviving RIDs after processing the last bitmap.
5. Optionally sort these RIDs.
6. Fetch a base table row.
7. Re-join the fact table with each of its dimension tables, accessing the
columns in dimension tables that are needed for the SELECT clause.
8. Reapply the residual predicates.
Steps 1 to 6 of this processing are depicted in Figure 4-15. The advantage of

creating bitmap indexes dynamically is that they do not have to be stored on disk.
Therefore, no I/O-operations and compression/decompression are required,
which improves performance (static bitmap indexes are usually compressed
before they are stored on disk).

Dimension Tables
store_id 1 2
name
Semi-
period_desc
city Join Dynamic Bitmaps
year region
product_id Fact table Row Ids 0 1 1 1 0 ..... 1 0 1 0 1 1
zip_code Semi-
brandmonth AND
size day Join
producer
caselot Semi-
Fact table Row Ids 0 1 1 0 0 ..... 1 0 0 0 1 1 3
Join AND
Fact table Row Ids 0 0 1 1 0 ..... 1 0 1 0 1 0
Fact Table
product_id Index on product_id 0 0 1 0 0 ..... 1 0 0 0 1 0
period_desc
store_id Index on period_desc
dollars Index on store_id
4
units 5 Surviving Fact table Row Ids
price
sales
Fetch Sort
6
Figure 4-15 Star join with dynamic bitmap index ANDing
Hash joins
Hash joins can significantly improve performance of certain queries, especially in
data warehouse environments such as SAP BW, where the queries are typically
quite large and complex. In DB2 UDB Version 8, hash joins are always
considered when optimization level 5 or higher is used. By default, SAP BW uses
optimization level 5. With DB2 Version 7, hash joins are only considered when
the registry variable DB2_HASH_JOIN is set to YES.
When joining two tables, regardless of which join method is used, one table will
be selected to be the OUTER table, and another table will be the INNER table.
The optimizer decides which will be the OUTER table and which will be the
INNER table based on the calculated cost and the join method selected. The
OUTER table will only be scanned once. The INNER table may be scanned
multiple times, depending on the type of join and indexes that are present on the
table.
Hash joins require one or more equality join predicates between the joined
tables. The fact that they can handle more than one equality predicate between
the joined tables is a distinct advantage over other join methods.
104 SAP BW and DB2

A hash join comprises the following steps:
򐂰 The designated INNER table is scanned and the rows copied into memory
buffers drawn from the sort heap specified by the sortheap database
configuration parameter. The memory buffers are divided into partitions
based on a hash value that is computed on the columns of the join predicates.
If the size of the INNER table exceeds the available sort heap space, buffers
from selected partitions are written to temporary tables.
򐂰 When the inner table has been processed, the OUTER table is scanned and
its rows are matched to rows from the INNER table by first comparing the
hash value computed for the columns of the join predicates. If the hash value
for the OUTER row column matches the hash value of the INNER row
column, the actual join predicate column values are compared.
򐂰 OUTER table rows that correspond to partitions not written to a temporary
table are matched immediately with INNER table rows in memory. If the
corresponding INNER table partition was written to a temporary table, the
OUTER row is also written to a temporary table. Finally, matching pairs of
partitions from temporary tables are read, the hash values of their rows are
matched, and the join predicates are checked.
For the full performance benefits of a hash join, you should consider the following
suggestions:
򐂰 You may need to change (increase) the value of the sortheap database
configuration parameter and the sheapthres database manager configuration
parameter.
򐂰 Hash join performance is best if you can avoid hash loops and overflow to
disk. To tune hash join performance, estimate the maximum amount of
memory available for sheapthres, then tune the sortheap parameter. Increase
its setting until you avoid as many hash loops and disk overflows as possible,
but do not reach the limit specified by the sheapthres parameter.
򐂰 Increasing the sortheap value should also improve performance of queries
that have multiple sorts.
򐂰 If intra-partition parallelism is enabled, the hash join may be executed in
parallel.
4.3.6 Use of distribution statistics for query optimization

When DB2 processes an SQL statement, it first generates an access plan. To
help the DB2 cost-based optimizer generate the most efficient access plans,
especially for SAP BW queries, SAP BW on DB2 uses so called distribution
statistics for some of the SAP BW tables. More details about DB2’s advanced
cost-based query optimization are provided in 3.2.4, “Cost-based optimizer” on
page 60.

The following different types of DB2 statistics are used by SAP BW:
򐂰 Basic statistics: These statistics provide information about the number of
records (cardinality) of a table. Such statistics can be collected fast, but do
not provide detailed information.
򐂰 Distribution statistics: These statistics provide information about the
distribution of the values that occur in a table. Generation of this type of
statistics takes longer, but they also help the cost-based optimizer to
generate better access plans. That is, SQL statements that access the
corresponding tables are likely to perform better. For large tables that are
accessed by complex statements, it is in general advisable to use detailed
statistics.
Depending on the type of tables, the following types of statistics are collected in
SAP BW:
򐂰 SAP Basis tables: Basic Statistics
򐂰 SAP BW ODS, PSA tables: Basic Statistics
򐂰 SAP BW Fact, Dimension, Master Data tables: Distribution Statistics
You can use a planning calendar, by using transaction ST04, to schedule the
automatic collection of database statistics. For more details refer to 7.3.3, “The
optimizer and runstats” on page 207.
4.3.7 New features of the DBA Cockpit 6.40

The DBA Cockpit 6.40 provides several new useful features. Here are the most
important features to consider:
򐂰 Maintenance of node groups and bufferpools is done. The maintenance of
tablespaces was already introduced with DBA Cockpit 6.20.
򐂰 The database configuration can now be modified from within the DBA
Cockpit.
򐂰 An Audit Log now tracks all maintenance actions.
򐂰 Remote DB2 database monitoring is now possible. Prior to release 6.40 it
was possible to monitor remote DB2 databases, if they were part of an SAP
system installation. Now it is also possible to monitor remote DB2 systems
that are not part of an SAP system.
106 SAP BW and DB2

򐂰 Enhancements in the runstats configuration and processing. Most
importantly, runstats jobs that are planned in the DBA planning calendar can
now process runstats concurrently on multiple database tables, which
reduces the processing time for database statistics on multi-processor
machines. Figure 4-16 shows the new scheduling panel for creating a
runstats job in the DBA planning calendar.
Figure 4-16 DBA Cockpit 6.40 can process runstats concurrently on multiple tables

108 SAP BW and DB2
5
Chapter 5. Project test environment

This chapter covers the hardware and software environment that was used for
this redbook project. In it we describe the different installation and scaling
scenarios that were tested, and show how they apply to SAP BW customer
environments. Finally, we describe the SAP BW sample application that was
used for the project testing.

5.1 Hardware configuration
The hardware used was primarily chosen to enable us to demonstrate how well
SAP BW can scale on DB2 UDB ESE. We describe scenarios of scaling within a
single server, and in a multi-server clustered environment. The operating system
used for this project was IBM AIX, and we used IBM pSeries servers for the
hardware. In particular we used the IBM pSeries 650 (P650). These servers were
mainly used for the SAP BW Central Instance and the Database Instance. The
hardware configurations are described below in Table 5-1. As you can see, we
also used the pSeries 630 (P630). However, these were mostly used as
application servers as we ran the various scaling scenarios. The actual scaling
tests were performed with the P650 servers.
To clearly demonstrate the scalability, particularly when multiple servers were

used, a shared data storage environment was used. This enabled a consistent
methodology to analyze other variables, such as performance, as we scaled BW.
For example, as we scaled processors and servers within the cluster, queries
could be run in each scenario and provide comparable results. The data storage
used was the IBM FASt T700 Storage System, with a RAID storage
configuration. That hardware configuration used is depicted in Figure 5-1.
pSeries 650 pSeries 650 pSeries 630 pSeries 630
A B C D
FiberChannels
Switch 1 Switch 2 205 GB RAID/5 (vg1)
85 GB RAID/5 (vg2)
FASt T700
Storage
Figure 5-1 Hardware environment
110 SAP BW and DB2

The basic description of the hardware is summarized in Table 5-1. The function,
in terms of landscape, of each machine in each scenario is described in 5.3,
“Installation, scaling, and performance test scenarios” on page 115.
Note: Throughout this redbook the alias name P650 A is used to refer the first
P650 and the alias name P650 B to refer the second P650, as shown in
Appendix 5-1, “Basic hardware description” on page 111.
Table 5-1 Basic hardware description

Alias name Product Number of CPU clock Memory size
name processors (in mhz) (in GB)
P650 A pSeries 650 8 1200 32

model 6M2
P650 B pSeries 650 8 1200 32

model 6M2
P630 C pSeries 630 4 1200 4

model 6C4
P630 D pSeries 630 4 1200 4

model 6C4
The storage system is an IBM FASt T700, using a Fibre Channel. The disks were
RAID5 configured, as is typical in most customer environments.
Note: Please consult your disk supplier and verify SAP recommendations in
the installation guide SAP Web Application Server Installation. That is
necessary because the disk design and architecture can significantly
influence the BW system performance.
5.2 Software configuration

This section describes the software and release levels used in this redbook
project. Basically, the environment consisted of the operating system, the
database management system (DB2 UDB ESE), and SAP BW. The intent was to
keep the environment simple and focus on testing the scalability objectives. This
enabled an implementation that gave consistent and clean results. That is, there
were no other software systems or applications running that would interfere with
measurements.
Chapter 5. Project test environment 111

5.2.1 Operating system
For the operating system, we selected IBM AIX. Some of the release level
and configuration parameters are listed in Table 5-2. The information listed in
the table columns (Parameters and Specifications) represents the values we
used for this redbook project.
Although there are other operating systems that could be used, AIX provides
excellent support for DB2 parallelism and partitioning. And these were the
capabilities of most specific interest in this project.
Table 5-2 Operating system environment

Parameters Specifications
AIX 5.2 oslevel, 5.2.0.0
64 bits bootinfo -K 64
ML 2 (at least) instfix -i | grep ML

All filesets for 5.2.0.0_AIX_ML were found.
All filesets for 5200-01_AIX_ML were found.
All filesets for 5200-02_AIX_ML were found.
Asynchronous lsdev -Cc aio

I/O aio0 Available Asynchronous I/O (Legacy)
Swap Space 64 bits SAP kernel at least 20 GB.

lsps -s
vmtune Memory on server is less than 1.5GB :

vmtune -p5 -P10
Memory on server 1.5GB or more:
vmtune -p3 -P8
C++ Runtime 6.0.0.0 lslpp -l | grep xlC.rte

(at least) xlC.rte 6.0.0.0 COMMITTED C Set ++ Runtime
Java Runtime Instance running only Web AS ABAP :

java 1.3.1
Instance running Web AS ABAP + J2EE :
java 1.4.1
112 SAP BW and DB2

Filesets bos.rte
(using command bos.adt
lslpp -l to check)
bos.data
bos.sysmgt
bos.diag.rte
bos.msg.en_US
bos.net.nfs
bos.net.tcp
perfagent
bos.loc.iso.en_US
bos.loc.iso.de_DE
bos.iconv.de_DE
bos.iconv.com
devices.*
printers.rte
X11.base
X11.apps
X11.motif
X11.fnt.iso1
X11.loc.en_US
X11.msg.en_US
X11.Dt
xlC.rte
Note: If possible, distribute the swap area across more than one disk. But, do
not put the sapdata and swap area on the same disk.
5.2.2 Database management system

For the database management system, we used DB2 Universal Database
(UDB). And to enable us to partition the database as desired, we selected the
Enterprise Server Edition (ESE). The particular parameters and specifications
used are shown in Table 5-3.

Table 5-3 Database environment
DB2 Universal Database, Version 8.1 (64 bits) for AIX, which was
Enterprise Server Edition delivered via SAP CD number 51019377
DB2 FixPak (FP) FP3, which was delivered via SAP CD

number 51020286
Note: If you elect to use the latest available DB2 FixPak for your
implementation, first verify that it is in compliance with SAP.
5.2.3 SAP Business Information Warehouse

The latest version of SAP BW (BW 3.5) was installed for this project. All the
components of SAP BW are part of the NetWeaver integration platform. For
more information on the NetWeaver platform, refer to 1.4, “SAP NetWeaver” on
page 12. Some of those components are:
򐂰 Central Instance
򐂰 Database Instance
򐂰 Dialog Instance
򐂰 Gateway Instance
The primary components installed are listed in Table 5-4.
The business content add-on was installed and provides pre-configured

information models, including extractors, several thousand InfoObjects, several
hundred InfoCubes, and ODS objects, as well as predefined templates for
reports and analyses with corresponding technical and business definitions.
Table 5-4 BW environment

Parameter Specification
NetWeaver Web Application Server 6.40 (64 bits)

and DB2 UDB ESE for AIX
BW BW 3.5
Business Content 351
114 SAP BW and DB2

Note: Please verify that the latest version of SPAM and the latest versions of
support packages are available for all components (including SAP_BASIS,
SAP_ABA, SAP_BW, PI_BASIS, and BI_CONT).
5.2.4 Front-end software

SAP continues to use SAPGUI 6.20 for NetWeaver 6.40. However, we
recommend that you upgrade to the latest patch (including SAPSetup, GUI, and
BW).
You can download the latest patch available using SAP Service Marketplace by
using the following link:
http://service.sap.com/patches
5.3 Installation, scaling, and performance test scenarios

As part of this project we performed the following tests:
򐂰 SAP BW3.5 and DB2 V8 installation test.
򐂰 Scaling the DB2 database system by adding an additional database server.
򐂰 Some scalability tests, such as comparing the runtimes of performance
critical operations for the different scenarios depicted in Table 5-5.
The technical steps to set up the installation are described in detail in Chapter 6,
“Implementing SAP BW on DB2” on page 121. The technical steps to scale out
the system by adding additional hardware and database partitions are described
in Chapter 9, “Scaling out the database” on page 297. In Chapter 10, “Scalability
factors of SAP BW on DB2 UDB ESE” on page 317, we summarize the results of
two studies about SAP BW scalability, when running on DB2. We also provide
the results of the measurements we performed as part of this redbook project.
Table 5-5 provides an overview of the different installation and scaling scenarios,
and the hardware that is used in each scenario. The computing power, in terms
of the number of processors and number of disks, is doubled when going from
scenario 2 to scenario 3.

Table 5-5 Description of installation and scaling scenarios
Scenario Number of Number of Number of Brief description
servers Processors database
partitions
1 1 p650 8 1 BW Installation
2 1 p650 8 4 Partitioning of database
3 2 p650 16 4 1 database server added
Next we describe the scaling scenarios we tested:
Scenario 1: This scenario comprises an SAP BW system with a single database

partition on a single database server. It currently reflects the configuration of the
majority of SAP BW on DB2 UDB ESE customers. However, it is assumed that
this will change, and more and more customers will start with multiple database
partitions from the beginning. The purpose of this scenario is primarily to
demonstrate how to install an SAP BW and DB2 system.
Scenario 2: This scenario was created from Scenario 1 by re-partitioning the

database to expand from one to four partitions.
The advantage of re-partitioning a DB2 database on an SMP server is that time

consuming database operations, such as an SQL query, index build, or
backup/restore, can be processed concurrently on each of the database
partitions. This means the available processors can be fully utilized even, for a
single running operation. If, for example, a BW power user executes a very
complex BW query, this query will be processed concurrently on all processors
which results in much faster execution times. The technical concepts of DB2
parallel processing features are described in more detail in Chapter 3, “DB2 UDB
ESE technical overview” on page 43.
If you want to scale your database system by adding additional SMP servers,
you must partition your database. The different options to partition the DB2
database are described in Section 4.3.1, “Architecture and features” on page 89.
The purpose of this scenario is to show the required steps and tools to
re-partition the database. This is relevant for most SAP BW andDB2 customers
that are currently running on a single partition. In addition, we compare the
execution times between Scenario 1 (unpartitioned) and Scenario 2 (partitioned)
for certain performance critical BW operations to demonstrate the advantage of
partitioning.
116 SAP BW and DB2

Scenario 3: This scenario was created from Scenario 2 by adding a second
SMP server and shared disk, and moving two of the four database partitions to
the second SMP server.
If you cannot add processors to your database server, adding additional servers
is the next step in order to scale the database system. This might become
necessary, for example, if SAP BW system response times increase due to
growing data volumes, growing number of users, or increasing complexity of
queries. The ability to add database servers to your database system is a unique
feature of DB2 UDB ESE. This feature has many advantages, such as in terms of
TCO (total cost of ownership) as described in Section 4.2, “Business advantage:
the value proposition” on page 87.
The purpose of this scenario is to show how to attach additional SMP servers to
your database system.
5.4 SAP BW sample application

To be able to monitor the system during typical SAP BW operations, we used the
SAP BW 3.0 Benchmark Suite to set up a data model and to generate and load
data.
The data model is shown in Figure 5-2. It consists of a sales and distribution
InfoCube 0SD_C01. In addition, an ODS object, ODSBENCH, is used. During
the project we performed the following steps:
򐂰 Load 30 InfoPackages concurrently from flat file into PSA.
򐂰 Collecting runstats on PSA.
򐂰 Drop InfoCube indexes.
򐂰 Load 30 InfoPackages concurrently from PSA into InfoCube.
򐂰 Recreate InfoCube indexes.
򐂰 Rollup the InfoPackages from InfoCube 0SD_C01 into the aggregates.
򐂰 Compress an InfoPackage.
򐂰 Load from PSA into ODS.
򐂰 Activate the InfoPackages in the ODS.

Figure 5-2 Datamodel of SAP BW benchmark cube 0SD_C01
118 SAP BW and DB2

To generate flat files for master data and transaction data, we use PERL scripts,
which are part of the benchmark tools. We generated and loaded the following
master data:
򐂰 100,000 products
򐂰 100,000 customers
򐂰 9 divisions
򐂰 9 distribution channels
򐂰 100 versions
򐂰 1000 salesorgs
򐂰 22 countries
򐂰 100 types
Ten aggregates are defined for the InfoCube with approximately the same
volume of data as the InfoCube. The aggregate definitions are shown in
Table 5-6.
Table 5-6 Aggregates of InfoCube 0SD_C01

Nr Definition
1 Material number: *
Country of the sold-to party: *
Valuetype for reporting: *
2 Division: F, B2
Material number: *
3 Division: F, B3
Material number: *
4 Division: F, B4
Material number: *
5 Division: F, B5
Material number: *
6 Distr. Channel: *
Division: *
Material number: H/BW_SDK_BMK///0MATERIAL 2

Nr Definition
7 Distr. Channel: *
Division: *
8 Distr. Channel: *
Division: *
9 Division: *
Country of the sold_to_party: *
10 Division: *
The FASt T700 storage system used for the tests provided a total of 290 GB of
free space. This generated and loaded between 30 million and 60 million records
of transactional data as described in Chapter 10, “Scalability factors of SAP BW
on DB2 UDB ESE” on page 317.
Loading 60 million records was the largest scenario possible with the available
disk space. This maps to the 4 GB SAP BW benchmark scenario. 60 million
records in the PSA consume about 30 GB disk space (24 GB for table data and 6
GB for index data). Additional disk space is required to load the transactional
data from PSA into the InfoCube, the ODS, and the aggregates.
To see a realistic percentage of disk activity during our tests, we limited the
amount of real memory to be used by the database (bufferpools and sortheap).
SAP recommends to configure about 1/3 of real memory for bufferpools
(database cache) and 1/4 of real memory for sortheap (see 8.2, “Health check”
on page 250, and SAP Note 584952 for details).
Therefore, when testing with 60 million records, which refers to the 4 GB

benchmark scenario, we limited the bufferpools to 1.3 GB and the total sort
space to 1 GB. When testing with 30 million records, we used 0.65 GB for
bufferpools and 0.5 GB for sortheap.
120 SAP BW and DB2

6
Chapter 6. Implementing SAP BW on

DB2
This chapter provides information about the implementation of SAP BW with the
IBM DB2 Universal Database (DB2).
Included in this chapter are discussions on the following topics:

򐂰 Sizing SAP BW on DB2
򐂰 Recommended implementation tools
򐂰 Installation planning activities
򐂰 Preparing the implementation steps
򐂰 Installation of IBM DB2 Universal Database Enterprise Server Edition
(DB2 UDB ESE) on the IBM AIX operating system
򐂰 Installing SAP NetWeaver
򐂰 Post-installation activities

6.1 Sizing SAP BW on DB2
Before starting with the description of the SAP BW implementation phases, tools,
and activities, we provide some information about sizing SAP BW in general, and
DB2 in particular.
SAP considers two major areas to estimate hardware requirements for SAP BW:
򐂰 Data staging (for data load into PSA, and from PSA into data targets)
򐂰 SAP BW queries
To help estimate hardware requirements, SAP provides the sizing guide, Sizing -
ASAP for BW Accelerator, and a tool called QuickSizer. There are some
important factors that make it difficult to estimate hardware requirements. As
examples, there are uncertainties in the area of SAP BW queries such as the
following:
򐂰 You cannot exactly predict the usage patterns of queries — that is, how often
certain queries are executed by how many users in a given timeframe. The
QuickSizer makes some assumptions about user categories and number of
users in each category, based on customer surveys.
򐂰 You often do not have detailed information about the final complexity of the
queries. Therefore, response times are hard to predict. In addition, queries
might need to be modified in the production environment. Changing a small
aspect of a query can completely change, and potentially increase, the
execution time.
򐂰 The execution times of BW queries heavily depend on the existence and
usage of aggregates. If you cannot actually test your BW queries on a system
with the final setup of aggregates, you can only make rough assumptions
about required hardware resources.
Since complex SAP BW queries are more typically database server bound, this
makes it difficult to estimate hardware requirements for the database server.
The data staging area (dataload) is more application server bound, and sizing
this area brings the following uncertainties:
򐂰 The QuickSizer assumes that there are no customer specific transformation
and update rules, which is often not the case. If customers define their own
transformation and update rules, this can create an additional load, which is
primarily on the application server.
122 SAP BW and DB2

The following tools are available to automatically perform multi-user SAP BW
query stress tests:
򐂰 RSRTRACE lets you record queries, and RSRCATTTRACE lets you play
them back. BW statistics can then be used to analyze query runtimes. Since
RSRTRACE and RSRCATTTRACE are written for SAP BW2.0, there are
some restrictions for SAP BW3x, for example, regarding usage of SAP
MultiCubes (which are pre-joined views of two or more cubes represented as
an OLAP cube to the end user).
򐂰 The SAP BW 3x benchmark tools provide a benchmark driver that can
simulate multiple concurrent users executing SAP BW queries. Those queries
run on the benchmark cube by default. However, you can modify the involved
scripts to execute your own queries and navigational steps.
The following steps explain how to derive hardware requirements and how to
determine the number of database partitions on DB2 UDB ESE:
򐂰 Data volume, complexity of queries, number of concurrent users, and
maintenance window determines required SAPS (SAP unit of measure for
computing power).
򐂰 Required SAPS determines the number of processors needed on the
selected hardware platform.
򐂰 Number of processors on each server determines number of logical partitions
on that server.
򐂰 Recommended are 1-4 processors per partition. In most cases DB2 can
utilize between 2-4 processors per partition when executing a single running
SAP BW query. This requires that INTRA_PARTITION parallelism is switched
on. If INTRA_PARTITION parallelism is switched off, only one processor can
be utilized per partition for single running queries. If you have a high
concurrent workload (many users that run queries concurrently), you might
consider switching INTRA_PARTITION parallelism off to reduce the number
of database agents.
򐂰 If you plan to connect a second database server to the existing storage
system later on, you may want to configure more partitions to avoid
re-partitioning your data later on. For details about scaling your database
system, please refer to 3.2.3, “Parallel processing and partitioning” on
page 55 and Chapter 9, “Scaling out the database” on page 297.
Important: The most reliable method to estimate required hardware capacity

is to perform actual measurements on a test system and extrapolate the
requirements for SAPS, memory, and disk space.
Chapter 6. Implementing SAP BW on DB2 123

6.2 Implementation approaches
During the first step of the SAP BW implementation process, you can define the
implementation and operation strategy. This strategy could be based, for
example, on one of the following approaches:
򐂰 Big Bang Approach: In this approach, components and systems are
installed independently from the existing environment.
򐂰 Phased Implementation: In this approach, the new SAP environment
integrates existing business processes and data.
򐂰 Roll-Out Implementation: This approach includes steps from the Big Bang
Approach and Phased Implementation.
SAP provides the methodology and tools to guide you during the implementation
of SAP NetWeaver. The methodology is based on the ValueSAP Roadmaps,
which was formerly known as AcceleratedSAP (SAP).
The implementation tools provide these features:

򐂰 Implementation Assistant
򐂰 Q&Adb (Question & Answer DB)
򐂰 Integrated Implementation Guide (IMG)
򐂰 Profile Generator
򐂰 Transport Management System
6.2.1 The Implementation Assistant

ValueSAP is shipped with the product. It can be installed, with the associated
CDs, on an individual PC or on a server defined during the BW Implementation
Project. After starting the implementation assistant, the BW Project is selectable,
as depicted in Figure 6-1.
124 SAP BW and DB2

Figure 6-1 BW Project in ValueSAP
Users can log in with:

򐂰 user = asap
򐂰 default password = asap
The Implementation Roadmap, as depicted in Figure 6-2, is then displayed.

ASAP (Accelerated SAP Implementation) is the SAP recommended
methodology for the implementation.
Figure 6-2 The Implementation Roadmap
SAP recommends using the ValueSAP phases, tasks, and activities for the
implementation project. Those phases are listed below. We do not describe or
discuss all of the single steps for the phases, but rather provide a high-level
discussion of those roadmap phases and their advantages.

1. Phase: Project Preparation
In this first phase you provide the needed information for sizing the resources. To
assist in this effort, SAP provides:
򐂰 The Questionnaires, where you describe:
– The number of users
– The thinktime (the time between entering two consecutive dialog steps)
– The SAP modules, where the SAP user is performing the transactions
– The required response time.
򐂰 The QuickSizer. Based on the gathered data, the system can be sized using
the SAP QuickSizer tool. Using the QuickSizer makes the sizing of the
hardware easier and faster. You can start this Web-based tool from the Web
site located at:
https://www.service.sap.com/quicksizing
An SAP Service Marketplace User ID will be required to access the
QuickSizer. As a result of using this tool you will get the technical sizing
requirements.
The illustration in Figure 6-3 shows a list of the needed tasks and activities for
project preparation.
Figure 6-3 The sizing steps
126 SAP BW and DB2

2. Phase: Business Blueprint
During the second phase, the Business Blueprint, the Implementation
Assistant guides the project members in developing the Business Information
Warehouse design.
The Application Consultant is the primary person involved in these tasks and
activities, as shown in Figure 6-4. However, technical consultants, such as the
DB2 and SAP Administrator, with their knowledge and experience, should also
be involved. This is especially important for the evaluation of performance and
the load aspects.
Figure 6-4 Develop and define the BW Design

3. Phase: The Realization
During this phase:
򐂰 The system landscape is defined.
򐂰 One BW (Business Information Warehouse) system is installed.
򐂰 The basic configuration is performed.
The steps to complete this phase are depicted in Figure 6-5. For the system
tests, Test Plans should be defined.
Figure 6-5 The sizing steps
In addition, the ValueSAP gives a description of the activities, including their

prerequisites and dependencies. The illustration in Figure 6-6 shows how
ValueSAP provides the information to develop test plans.
128 SAP BW and DB2

Figure 6-6 Develop technical test plan
ValueASP also provides templates and master documents, which are very
helpful. Even the recommended role, such as DB Administrator or Application
Consultant, are assigned to the appropriate task. The illustration in Figure 6-7,
shows examples from the available documents. It lists the related templates for
security and testing the BW environment, and describes the involved roles, such
as database administrator or business consultant, as well.
Figure 6-7 Access to the security and testing documents

4. Phase: Final Preparation
The Final Preparation phase describes:
򐂰 Establishment of operations support
򐂰 Run of technical and performance tests according to the defined test plans
򐂰 Cut-over to the production system
򐂰 Final approval for going live
5. Phase: Going Live and Support

The last phase of the implementation process guides you through the important
activities after production has started. During this phase the technical
consultants provide:
򐂰 production support, such as:
– Monitoring the system according the checklists
– Monitoring the performance
– Performing backups
򐂰 Help desk support
򐂰 Implementing improvements for availability and performance.
6.3 Preinstallation activities

In this section we discuss the activities that must be planned and performed prior
to the installation of SAP BW on DB2. Successful planning and completion of
these activities will enable an organized approach to the installation. This will
then make it faster and easier to track progress and understand all the steps
required for success.
6.3.1 Component considerations

Prior to installation, there are a number of activities to be performed that should
be clarified by the project team. Some of these are discussed in the following
sections.
Hardware and operating system considerations

The hardware (HW) and operating system (OS) resources required are based on
the sizing results. Depending on the installed HW and OS, additional functions
may be provided. Here are some examples:
򐂰 Logical Partitioning (LPAR) of the system, such as can be done on an IBM
pSeries processor running with AIX.
򐂰 Distribution of data, and multiple access paths to the disks.
130 SAP BW and DB2

DB2 considerations
DB2 UDB V8 provides database partitioning. In a partitioned environment, a
database is distributed across multiple partitions. One or more partitions can
reside on one or more different servers. Each partition is responsible for a portion
of the total data housed in the database. When more than one database partition
is installed, parallel access to the database objects may be available. This
depends on:
򐂰 Systems life cycle
򐂰 Estimated database size
򐂰 Size of database objects like tables, indexes
򐂰 Needed response time for dialog
򐂰 Scheduled runtime for background jobs
The project team will need to define the DB2 UDB structure and decide on such
questions as these:
򐂰 Is database partitioning necessary?
򐂰 How many database partitions will be needed?
򐂰 How should the database partitions be distributed?
򐂰 Should partitions be located on one or more systems?
SAP NetWeaver considerations

The SAP NetWeaver is introduced in 1.4, “SAP NetWeaver” on page 12. It is the
integration and application platform used across all SAP solutions. As such, the
installation of all SAP BW components are part of that platform. The following
subsections discuss considerations for implementing those components.
SAP system landscape and installation options

In the SAP system landscape, defined during the implementation phases, you
can have systems with different roles. For example you might define a baseline
system as a preconfigured basis for all of your subsidiaries, or as a test system.
Within a system landscape, the systems are connected. These are the
installation options:
򐂰 First, a decision needs to be made as to which type of system must be
installed. Examples are:
– Baseline
– Development
– Quality assurance
– Production

򐂰 The Web Application Server (WAS) 6.40 includes the following basic
installation options. SAP calls them Basic System Variants:
– SAP Web AS ABAP system: This installs the ABAP functions of SAP
Web AS. No J2EE Engine will be installed.
– SAP Web AS ABAP+J2EE system: This consists of the ABAP
functionality of SAP Web AS and the SAP J2EE Engine.
– SAP Web AS J2EE system: This installs the SAP J2EE Engine and
auxiliary services. No ABAP Engine is installed.
The project team then needs to clarify the functionality to be installed.
򐂰 The SAP NetWeaver WAS includes several installable main components:
– Central Instance. The Central Instance controls the additional Dialog
Instances and provides the interface for the Database Instance
installation. You can install the Central Instance with the SAP J2EE
Engine. If you install an SAP system with the SAP J2EE Engine, a Central
Services Instance is also part of your SAP system. The central services
(SCS) form the basis of communication and synchronization for the J2EE
cluster. A Central Services Instance consists of the message service and
the enqueue service:
• The message service knows the status of the Dialog Instances, and
provides load balancing for the application server. Additionally, it
controls the J2EE dispatcher and server processes.
• The enqueue service manages database locks during an SAP
Business Transaction. It also synchronizes data across the J2EE
cluster.
– Database Instance: A Database Instance is a mandatory installation
component of an SAP Web AS, and BW system.
– Dialog Instances: if required. Dialog Instances are SAP Instances that
include only dispatcher, IGS, and CCMS (Computing Center Management
System) agents.
– Gateway Instance: if required. The Gateway Instance provides
communication facilities based on TCP/IP and SNA.
– Front-ends: provide access to the SAP NetWeaver components. SAP
provides front-ends based on Microsoft Windows and JAVA.
The project team has to define the distribution of the instances. The following
options are available:
򐂰 Minimal component distribution: The minimal system installs all of the
mandatory components on a single system. We used the minimal component
distribution for this redbook project.
132 SAP BW and DB2

The illustration in Figure 6-8 shows that the Central Instance and the
Database Instance are installed on the same system, System 1.
S ys te m 1
C e n tr a l In s ta n c e D a ta b a s e In s ta n c e
A B A P P ro c e s s o r
M essage Enqueue D a ta b a s e O b je c ts
S e rv e r S e rv e r
W o rk P ro c e s s e s
Figure 6-8 The Central Installation - Minimum Distribution
򐂰 Maximal Component Distribution: The mandatory components, such as

the Central Instance and the Database Instance, are installed on different
systems. This is depicted in Figure 6-9. The Central Instance is on System 1
and the Database Instance is on System 2.
System 1 System 2
Central Instance Database Instance
ABAP Processor
Message Enqueue Database Objects

Server Server
Work Processes
Figure 6-9 The Distributed Installation
The distribution of the components for the LAN SAP Web AS J2EE system and
the installation of SAP Web AS J2EE systems is described in the documentation,
Installation Guide - SAP Web Application Server Java on UNIX: IBM DB2
Universal Database for UNIX and Windows.

6.4 Installation planning
First of all, for installation planning the project team members need access to the
required documentation. SAP provides the Installation Guide CD, which
includes all of the necessary documents. If you only need selected documents,
you can download them from the SAP service marketplace WEB site:
http://www.service.sap.com/instguides
During this project installation, we used the following documentation:

򐂰 SAP NetWeaver '04 Installation Guide: SAP Web Application Server ABAP
Installation on UNIX: IBM DB2 Universal Database for UNIX and Windows.
򐂰 SAP® Software on UNIX: OS Dependencies: For components based on
SAP® Web Application Server 6.40.
򐂰 SAP NetWeaver '04 Installation Guide: SAP Web Application Server Java on
UNIX: IBM DB2 Universal Database for UNIX and Windows.
򐂰 SAP BW 3.5 Administration Tasks on IBM DB2 Universal Database for UNIX
and Windows.
Additionally, you will find important information in the following places:

򐂰 SAPinst Troubleshooting Guide. This provides support for errors encountered
during the installation process.
򐂰 SAP Service Marketplace Web site. This site provides downloads, hints, and
notes. It is located at:
http://www.service.sap.com
򐂰 SAP Library. The SAP Library is shipped with the product CDs and includes
the SAP NetWeaver Documentation.
6.4.1 The SAP Installation Notes

It is mandatory to download the newest versions of the SAP installation Notes,
which provide document corrections, and additional hints. Very often the
Installation Guides refer to SAP Notes, and many of the SAP Notes refer to other
related notes and documents. Please read the SAP Notes thoroughly and use
the recommendations.
134 SAP BW and DB2

Important: During the Installation Planning Phase you must see the most
current SAP Notes. The following list is only a brief overview of the SAP Notes:
򐂰 Mandatory Notes:
– 668603 - SAP Web AS Installation on UNIX
– 69114 - DB6: SAP Web AS ABAP 6.40 on UNIX
– 668602 - SAP Software on UNIX:OS Dependencies 6.30
– 611361 - Hostnames of SAP servers
򐂰 Referenced from installation guide:
– 409127 - DB6: DB2 UDB Dual Logging
– 147634 - DB6: Hints and tricks for creating DB2 Tablespaces
– 362325 - DB6: Table convertion with DB6CONV
– 101809 - DB6: Supported FixPaks for DB2 UDB for UNIX and Windows
򐂰 Optional Notes:
– 544623 - New Installation of Unicode SAP systems
– 171356 - Linux only: SAP software on Linux Essential comments
– 79991 - Multi Language Support / Unicode
– 73606 - R/3 language combinations (non-Unicode)
– 42305 - RSCPINST (NLS installation tool)
During the planning activities you should review, evaluate, and document the
following items:
򐂰 System design (according sizing)
򐂰 SAP System Landscape
򐂰 Storage (disk) design and architecture
򐂰 Service level agreements (SLAs)
6.4.2 The installation checklists

SAP provides checklists in the installation documentation, which are dependent
upon the installation options. Examples are as follows:
򐂰 Installation Checklist for SAP Web AS (Central System)
򐂰 Installation Checklist for SAP Web AS (Distributed System)
򐂰 Installation Checklist for a Dialog Instance
򐂰 Installation Checklist for a Gateway Instance
򐂰 Installation Checklist for Additional Components
Based on the SAP Notes, these checklists, and the document SAP® Software on
UNIX: OS Dependencies, the system administrator checks the prerequisites.

The list depicted in Figure 6-10 and in Figure 6-11 shows the IBM AIX, the HP
Tru64 UNIX, the LINUX, and the SUN Solaris related content of the document,
SAP® Software on UNIX: OS Dependencies.
2 AIX: OS-Dependent Installation Steps

2.1 AIX: Requirements Checklist
2.2 AIX: Mounting a CD
2.3 AIX: Checking and Modifying the UNIX Kernel (Oracle only)
2.4 AIX: Checking and Modifying the UNIX Kernel (IBM DB2 UDB for UNIX only)
2.5 AIX: Volume Groups, File Systems, Raw Devices, Swap Space
2.5.1 AIX: Size of a Logical Partition
2.5.2 AIX: Setting up Swap Space
2.5.3 AIX: Creating Volume Groups
2.5.4 AIX: Setting up File Systems
2.5.5 AIX: Setting up Raw Devices
2.6 AIX: Mounting Directories via NFS
2.7 AIX: Creating UNIX Groups and Users
2.8 AIX: Troubleshooting
3 HP Tru64 UNIX: OS-Dependent Installation Steps

3.1 HP Tru64 UNIX: Requirements Checklist
3.2 HP Tru64 UNIX: Mounting a CD
3.3 HP Tru64 UNIX: Checking and Modifying the UNIX Kernel
3.4 HP Tru64 UNIX: File Systems, Raw Devices and Swap Space
3.4.1 HP Tru64 UNIX: Preparing Hard Disks
3.4.2 HP Tru64 UNIX: Setting up Swap Space
3.4.3 HP Tru64 UNIX: Setting up Standard File Systems
3.4.4 HP Tru64 UNIX: Setting up Advanced File Systems
3.4.5 HP Tru64 UNIX: Setting up Raw Devices
3.5 HP Tru64 UNIX: Mounting Directories via NFS
3.6 HP Tru64 UNIX: Creating UNIX Groups and Users
3.7 HP Tru64 UNIX: Troubleshooting
Figure 6-10 OS-Dependent Installation Steps for AIX and HP Tru64 UNIX
136 SAP BW and DB2

5 Linux: OS-Dependent Installation Steps
5.1 Linux: Requirements Checklist
5.2 Linux: Mounting a CD
5.3 Linux for zSeries®: Mounting a CD
5.4 Linux: Checking the Linux Kernel
5.5 Linux: File Systems and Swap Space
5.5.1 Linux: Preparing Hard Disks
5.5.2 Linux: Setting up Swap Space
5.5.3 Linux: Setting up Standard File Systems
5.6 Linux: Exporting Directories via NFS
5.7 Linux: Creating Linux Groups and Users
6 Solaris: OS-Dependent Installation Steps

6.1 Solaris: Requirements Checklist
6.2 Solaris: Preparing the Installation
6.3 Solaris: Mounting a CD
6.4 Solaris: Checking and Modifying the UNIX Kernel
6.5 Solaris: File Systems, Raw Devices, Swap Space
6.5.1 Solaris: Preparing Hard Disks
6.5.2 Solaris: Setting up Swap Space
6.5.3 Solaris: Creating File Systems
6.5.4 Solaris: Accessing Raw Devices
6.6 Solaris: Mounting Directories via NFS
6.7 Solaris: Creating UNIX Groups and Users
6.8 Solaris: Troubleshooting
Figure 6-11 OS-Dependent Installation Steps for LINUX and SUN Solaris
The installation procedure in 6.5, “Installation procedure” on page 142, provides

the details for installing in the AIX environment.
6.4.3 System planning and preparation

This section provides detailed information about the system planning and
preparation activities used in this redbook project environment.

1. We obtained the required documentation, which included:
– The installation guides
– The OS-Dependencies document
– The available administration guides
– The current SAP Notes (which we downloaded):
• For the installation
• Referred to in the installation documents
• Referred to in other notes.
2. We did not implement the following items:
– Unicode character-set
– Multiple components in one database (MCOD). With MCOD you are able
to implement more than one SAP System in one Database. See redbook:
SAP on DB2 Universal Database for OS/390® and z/OS®: Multiple
Components in One Database (MCOD), SG24-6914-00
– Lightweight Directory Access Protocol (LDAP) for SAP Logon. Using the
LDAP functionality the user administration of the different operating
systems and applications can be centralized. SAP, AIX, MS Windows XP,
and most Operating Systems support LDAP.
3. Using the Fiber Channel (FC) attached FastT-700 Storage system and SAN
Switches, we configured two independent access paths to the 290 GB of
shared disks used in the project.
We prepared and defined the Volume Groups, Logical Volumes, and
Filesystems, according the DB2 and SAP Documentation. Example 6-1
shows the details of the definitions. As can be seen, we added space for the
benchmark and the scalability tests.
Example 6-1 The Volume Group and File System Definitions

db2bi:/ >lsvg
rootvg
tmpvg
sapvg
sapdatavg
bwtestvg
db2bi:/ >df -k
Filesystem 1024-blocks Free %Used Iused %Iused Mounted on
/dev/hd4 262144 237876 10% 2105 4% /
/dev/hd2 2359296 253212 90% 41878 42% /usr
/dev/hd9var 262144 251060 5% 482 1% /var
/dev/hd3 786432 551028 30% 66 1% /tmp
/dev/hd1 262144 252592 4% 94 1% /home
/proc - - - - - /proc
/dev/hd10opt 262144 253372 4% 389 1% /opt
/dev/lv_bwcds 8126464 1290308 85% 425 1% /bwcds
138 SAP BW and DB2

/dev/fslv00 786432 306512 62% 16 1% /sapcd1
/dev/fslv01 786432 131088 84% 81 1% /sapcd2
/dev/fslv02 524288 144392 73% 114 1% /sapcd3
/dev/fslv03 262144 212520 19% 88 1% /sapcd4
/dev/fslv04 524288 238592 55% 33 1% /sapcd5
/dev/fslv05 786432 195736 76% 27 1% /sapcd6
/dev/fslv06 524288 180088 66% 67 1% /sapcd7
/dev/fslv10 25690112 5961480 77% 462 1% /bwbench
/dev/lv_db2 131072 120892 8% 48 1% /db2/BW1
/dev/lv_db2log 5242880 3931168 26% 26 1% /db2/BW1/log_dir
/dev/lv_db2log2 5242880 5241752 1% 4 1% /db2/BW1/log_dir2
/dev/lv_db2arch 5242880 5241752 1% 4 1% /db2/BW1/log_archive
/dev/lv_db2arch2 5242880 5241752 1% 4 1% /db2/BW1/log_archive2
/dev/lv_db2retr 1310720 1310192 1% 4 1% /db2/BW1/log_retrieve
/dev/lv_db2temp 1310720 1310152 1% 15 1% /db2/BW1/saptemp1
/dev/lv_db2dump 655360 571536 13% 7 1% /db2/BW1/db2dump
/dev/lv_sapd1 19660800 12707412 36% 13 1% /db2/BW1/sapdata1
/dev/lv_bwfact 20971520 20967992 1% 4 1% /db2/BW1/sapdata11
/dev/lv_bwpsa 20971520 20967992 1% 4 1% /db2/BW1/sapdata12
/dev/lv_bwods 20971520 20967992 1% 4 1% /db2/BW1/sapdata13
/dev/lv_bwaggr 20971520 20967992 1% 4 1% /db2/BW1/sapdata14
/dev/lv_sapmnt 1048576 721196 32% 674 1% /sapmnt/BW1
/dev/lv_usrsap 1048576 883436 16% 280 1% /usr/sap/BW1
/dev/lv_trans 2621440 1372196 48% 103 1% /usr/sap/trans
/dev/lv_sapinst 1048576 986796 6% 161 1% /sapmnt/BW1/install
/dev/fslv07 786432 315256 60% 24 1% /sapcd8
/dev/lv_sapcd1 786432 383596 52% 36 1% /sapcdbw1
/dev/lvdbinsttmp 3932160 2100792 47% 4884 2%
/sapmnt/BW1/db2inst
4. At this step you can optionally create the operating system users
<sapsid>adm or db2<dbsid> manually. Because the SAP NetWeaver
installation procedure, SAPinst, creates the user automatically, we did not
perform this activity.
5. We modified the UNIX kernel parameters and swap space according the
recommendations given by documentation SAP Software on UNIX: OS
Dependencies and the SAP Notes. For BW Systems, a swap space of at
least 20 GB is recommended. Example 6-2 shows our definitions.
Additionally, some user related kernel parameter must be changed. For
example, the number of processes per user was set to 500.

Example 6-2 the available swap space
db2bi:/ >lsps -a
Page Space Physical Volume VolumeGroup Size %Used Active Auto Type
paging01 hdisk3 tmpvg 10240MB 1 yes yes lv
paging00 hdisk0 rootvg 10240MB 1 yes yes lv
hd6 hdisk0 rootvg 512MB 3 yes yes lv
6. We chose an SAP system ID <sapsid> as BW1. The SAP system ID is a

three character ID which defines the SAP System Name. We recommend that
you define a naming convention for your enterprise and use meaningful
names - not only for the <sapsid>, but for all names in your system
environment.
7. We defined the database name to be BW1.
8. We prepared the system for SAPinst. Using the
B6:WEBAS:6.40:SAPINST:Master Installation CD DB2/UDB:I386 LINUX_32
AIX_64 IA64: we installed on the Central System the SAPinst Server code.
We followed these prerequisites:
– Installed JAVA 1.4.1 Runtime Environment.
– Disk Space of 300 MB must be provided for the installation directory.
Changed the permissions to 777.
– Changed directory to the installation directory.
– Entered the following command to start SAPinst from the SAP Master CD:
<SAP_Master_CD>/SAPINST/UNIX/<OS>/sapinst.
– Started the sapinstgui from the MS Windows environment, and then
downloaded the appropriate files. Example 6-3 shows the files:
Example 6-3 sapinstgui files for FTP download to Windows

db2bi:/sapcd10/SAPINST/NT/I386 >ls -l
total 75224
drwxr-xr-x 2 root system 256 Feb 16 09:47 JAR
drwxr-xr-x 9 root system 256 Feb 16 09:47 WEBAS_640
drwxr-xr-x 5 root system 256 Feb 16 09:47 XI_30
-rwxr-xr-x 1 root system 2043 Feb 16 09:47 catalog.dtd
-rwxr-xr-x 1 root system 1079 Feb 16 09:47 messages.dtd
-rwxr-xr-x 1 root system 389773 Feb 16 09:47 messages.xml
-rwxr-xr-x 1 root system 21027 Feb 16 09:47 product.catalog
-rwxr-xr-x 1 root system 22165751 Feb 16 09:47 sapinst.exe
-rwxr-xr-x 1 root system 7956978 Feb 16 09:47 sapinstgui.exe
-rwxr-xr-x 1 root system 2479 Feb 16 09:47 startinstgui.bat
db2bi:/sapcd10/SAPINST/NT/I386 >
140 SAP BW and DB2

– The startinstgui.bat on the PC starts the sapinst client. Figure 6-12 shows
the result.
Figure 6-12 The SAP Installation GUI Welcome screen
Note: SAPinst GUI caused segment failures on the pSeries with AIX V5 64bit
server. SAP Notes 668603 supplies the solution, which is to set the following
parameters in the installation shell:
ulimit -d unlimited
ulimit -s unlimited
You could set this parameter with smitty in the associated user (root)
definitions as well.
9. We prepared the required CDs for the installation. All of the needed CDs were
copied to disk, which reduces the installation time and provides for
unattended loading of the database export CDs. Example 6-4 lists the SAP
provided CDs for the installation.
Example 6-4 The Installation CDs

db2bi:/sapcdbw1 >pg LABEL.ASC
DB6:AKK:6.40:KERNEL:SAP Kernel IBM DB2 UDB for Unix and Windows:I386 LINUX_32
AIX_64 IA64:CD51020xxx
db2bi:/sapcd1 >pg LABEL.ASC

DB6:8.1FP3:RDBMS:DB2 Universal Database Release 8.1 FP3 for AIX:CD51020286

SAP:WEBAS:6.40:EXPORT(1/3):WEB AS 6.40 Export CD 1/3:CDxxxxxxxx



SAP:IGS:640:IGS:*:I386 LINUX_32 HPIA64 HP11_64 AIX_64 SUNOS_64 LINUXIA64_64
DEC_64 IA64:*

SAP:WEBAS:6.40:LANGUAGE(1/2):Language Disc:CDxxxxxxxx

SAP:R/3:640:ISINST:R/3 Add-On Installation BI_CONT 351:CD51020636

DB6:8.1:RDBMS:DB2 Universal Database Release 8.1 for AIX:CD51019377
db2bi:/sapcdbw8 >pg LABEL.ASC

SAP:J2EE-CD:630:J2EE-CD:*:AIX4_64 I386 LINUX_32 AIX_64 IA64:*

DB6:WEBAS:6.40:SAPINST:Master Installation CD DB2/UDB:I386 LINUX_32 AIX_64
IA64:CD5102xxxx
The following CDs are available for the installation:

򐂰 DB2 Universal Database Release 8.1 for AIX CD
򐂰 WEBAS 6.40 Master Installation CD
򐂰 SAP Kernel IBM DB2 UDB for UNIX and Windows CD
򐂰 Three WEBAS:6.40:EXPORT CDs
򐂰 Additional documentation CDs
Now the planning and preparation activities are finished, and the installation
steps can be performed.
6.5 Installation procedure

In this section we describe the installation of the Web Application Server (WAS)
ABAP in detail. The installation procedure includes the following four basic steps:
1. Install IBM DB2 Universal Database for UNIX and Windows Version 8.
2. Perform the installation of the WAS ABAP Central Instance for SAP
NetWeaver WAS 6.40 BW.
142 SAP BW and DB2

3. Install the Database Instance.
4. Install additional Dialog Instances if necessary. The installation of the DB2
Administration Client Software is a prerequisite for this step.
The SAP NetWeaver 6.40 includes, in addition to the ABAP Engine, the JAVA
J2EE Engine. Optionally, you may install the SAP Web Application Server Java
on UNIX as well. The following basic steps outline the installation of the SAP
WAS Java environment (however, we do not describe the details of the
installation of the WAS JAVA environment in this document):
1. IBM DB2 Universal Database for UNIX and Windows Version 8 is installed
during the ABAP installation.
2. Perform the installation of the Web Application Server J2EE Central Services.
The documentation uses the term Central Services to distinguish between the
ABAP and the Java environment.
If the Central Services are on an distributed system, which means the
Database Server and the Central Services are separated, the installation of
the of the DB2 Administration Client Software must be performed as a
prerequisite.
These are some optional installation steps:

3. Install additional Dialog Instances if necessary. The installation of the DB2
Administration Client Software is a prerequisite for this step.
4. Install the front-ends.
5. Install the SAP NetWeaver Developer Workplace. The SAP NetWeaver
Developer Workplace provides a development environment to create Java
applications. It includes the SAP NetWeaver Developer Studio and the SAP
Java Integrated Development Environment (IDE). For the installation of the
SAP NetWeaver Developer Workplace, you have to obtain the Installation
Guide - SAP NetWeaver Developer Workplace. The SAP NetWeaver
Developer Studio is SAP's own environment for developing Java-based,
multi-layered business applications.
6.5.1 Installing the IBM DB2 Universal Database

The installation of IBM DB2 Universal Database for UNIX is first step that must
be performed. Next, we assign the needed space for the installation.
򐂰 We provided 600 MB of free space in the following file system and directory:
– For AIX: /usr/opt
– For Solaris, Linux, HP-UX: /opt

򐂰 The database software will be extracted to a temporary directory. Additional
free space from approximately 1.5 GB must be available. Create a temporary
directory and switch to it using the following commands:
– mkdir <tmp_dir>
– cd <tmp_dir>
Access the database CD with <cd_mount> and enter the following commands
that are associated with your operating system:
– HP-UX:
/cdrom/UNIX/HP11_64/SAPCAR -xvf /cdrom/UNIX/HP11_64/DB2HPUX.SAR
– AIX:
/cdrom/UNIX/AIX/SAPCAR -xvf /cdrom/UNIX/AIX/DB2AIX.SAR
– Linux:
/cdrom/UNIX/LIN_32/SAPCAR -xvf /cdrom/UNIX/LIN_32/DBLIN.SAR
– Solaris:
/cdrom/UNIX/SUN/SAPCAR -xvf /cdrom/UNIX/SUN/DB2SUN.SAR
The subdirectory /DBSW is created. This directory is temporary and can be

deleted after you have finished the installation.
The free space for the DB2 UDB installation is available now, and the installation
can be started.
1. Log on as user root and set the DISPLAY variable.
– on c-sh setenv DISPLAY <hostname>:0.0
– on k-sh export DISPLAY=<hostname>:0.0
2. Go to the subdirectory <tmp_dir>/DBSW, entering cd <tmp_dir>/DBSW
For Solaris only:
If directory /var/tmp is empty, db2setup will delete this directory. To prevent
this, create an empty file in directory /var/tmp: + touch /var/tmp/DUMMY.
3. To start the installation, enter the command: ./db2setup
144 SAP BW and DB2

We have performed the steps listed in Example 6-5 on our AIX system to prepare
DB2 UDB setup and installation.
Example 6-5 Prepare DB2 UDB Setup

db2bi:/ >mkdir /sapmnt/BW1/db2inst
db2bi:/ >mount /sapmnt/BW1/db2inst - mount the created the logical volume
db2bi:/ >cd /sapmnt/BW1/db2inst
db2bi:
/sapmnt/BW1/db2inst >/dbcd1/UNIX/AIX/SAPCAR -xvf /dbcd1/UNIX/AIX/DB2AIX.SAR
Subdirectory ./DBSW is created automatically. SAPCAR writes the DB2
installation data to this subdirectory.
db2bi:/sapmnt/BW1/db2inst > cd /sapmnt/BW1/db2inst/DBSW
db2bi:/sapmnt/BW1/db2inst/DBSW > export DISPLAY=db2bi:0.0
db2bi:/sapmnt/BW1/db2inst/DBSW >./db2setup
The db2setup displays the IBM DB2 Setup Launchpad. It is depicted in

Figure 6-13.
Figure 6-13 The DB2 Setup Launchpad
4. After clicking the Install Products pane, you will receive a screen with the
procedure that allows you to select the installation options. This is depicted in
Figure 6-14.

Figure 6-14 Select the product to install
5. Select the DB2 UDB Enterprise Server Edition, and click Next.
6. Click Next on the Introduction screen.
7. Accept the license agreement, and click Next.
8. After selecting Typical Installation, click Next.
9. Choose Install DB2 Enterprise Server Edition on this computer, and click
Next.
10.Enter the password and user name for the DB2 Administration Server, and
click Next.
11.Select Do not create a DB2 Instance, and then click Next.
12.Do not change the defaults on the Contacts screen. Just click Next.
13.Do not set up SMTP notification.
14.On the next screen, click Finish to begin the installation.
15.After the installation has completed, click Finish again.
Installing DB2 UDB FixPaks

The DB2 UDB FixPaks include program enhanchments and corrections. Read
the SAP Installation Notes thoroughly, to decide which FixPaks have been tested
by SAP and should be installed. Typically the CDs include a DB2 FixPak.
However, always check the IBM Web sites and SAP Notes for any updated
information. The FixPak implementation is very similar to the DB2 installation.
146 SAP BW and DB2

And, every FixPak is accompanied by a document called APARLIST.TXT that
describes the problem fixes it contains.
FixPaks are cumulative. This means that the latest FixPak for any given version
of DB2 contains the updates from all previous FixPaks for the same version of
DB2. We recommend that you keep your DB2 environment running at the latest
FixPak level to maintain a problem-free operation.
When installing a FixPak on a partitioned DB2 UDB ESE system, all

participating servers must have the same FixPak installed while the system is
offline. Each FixPak may have specific prerequisites. See the FixPak README
that accompanies the FixPak for more information.
You can download the latest DB2 FixPak from the IBM DB2 UDB and DB2
Connect Online Support Web site at:
http://www.ibm.com/software/data/db2/udb/winos2unix/support
Each FixPak contains a set of Release Notes and a README file. The README
file provides instructions for installing the FixPak. In the following section we list
the typical installation steps.
Installation steps
You will need about 1.5 GB of free space for the temporary directory <tmp_dir>.
1. Log on as user root.
2. Create a new file system with 1.5 GB or use an existing one. The FixPak
software must be temporarily unpacked to disk.
3. Access the Fixpak through mounting the CD or Filesystem.
4. If You use the SAP CD an AIX systems enter:
<CD_mount>/UNIX/AIX/SAPCAR -xvf <CD_mount>/UNIX/AIX/DB2FP<nr>.SAR
The Subdirectory FIXPAK is created.
The source directory can be defined on other operating systems by using the
command that corresponds to your operating system in the following list:
SUN
<CD_mount>/UNIX/SUN/SAPCAR -xvf <CD_mount>/UNIX/SUN/DB2FP<nr>.SAR
Linux
<CD_mount>/UNIX/LIN_32/SAPCAR -xvf <CD_mount>/UNIX/LIN_32/DB2FP<nr>.SAR
HP
<CD_mount>/UNIX/HP11_64/SAPCAR -xvf <CD_mount>/UNIX/HP11_64/DB2FP<nr>.SAR

5. From the location of the unpacked database software, switch to subdirectory:
cd UNIX/AIX/FIXPAK
Or, on other operating systems, switch to the subdirectory:
OS related /FIXPAK/
6. To start the installation of the FixPak, enter:
./installFixPak
The screens and prompts guide you through the installation steps.
DB2 UDB ESE should now be installed, and the recommended SAP FixPaks all
applied. The next step is the installation of the SAP WAS Central Instance
Installation.
6.5.2 Installing the Central Instance

The first order of business is to make sure you have the prerequisites.
Prerequisites
The recommended changes in the SAP Notes and the SAP® Software on UNIX:
OS Dependencies are entered and reviewed.
Prior starting the SAPinst routine, the library path must be set. If you restart
SAPinst at a later time, make sure that the variable is still set.
As user root, set the library path environment variable according to the following
tables.
Table 6-1 shows the values for the library path environment variable for different
operating systems
Table 6-1 Value of library path environment variable

Operating system Variable value
AIX (64 Bit) /usr/sap/<SAPSID>/SYS/exe/run:/usr/opt/db2_08_01/lib64
Linux (32 Bit) /usr/sap/<SAPSID>/SYS/exe/run:/opt/IBM/db2/V8.1/lib
HP-UX,Solaris (64 Bit) /usr/sap/<SAPSID>/SYS/exe/run:/opt/IBM/db2/V8.1/lib64
Table 6-2 shows the name of the library path environment variable for different
operating systems.
148 SAP BW and DB2

Table 6-2 Name of library path environment variable
Operating system Variable name
AIX LIBPATH
Linux, SUN D_LIBRARY_PATH
HP-UX, SHLIB_PATH
Needed filesystems
We then defined the logical volumes, as depicted in Table 6-3:
Table 6-3 Logical volume definitions

Volumegroups Content
rootvg UNIX code, programs, definitions, swap
sapvg SAP kernel, SAP infrastructure Data, DB2 code
sapdatavg SAP database
sapdatavg2 Benchmark and test data

bwtestvg BW data
Next we defined the SAP related filesystems that were prepared for the
installation. They are depicted in Example 6-6:
Example 6-6 SAP related filesystems

Filesystem 1024-blocks Free %Used Iused %Iused Mounted on
DB2 Code
/dev/hd10opt 262144 253372 4% 389 1% /opt
CDs copied to DISK

/dev/lv_bwcds 6553600 667712 90% 423 1% /bwcds
/dev/fslv00 786432 382524 52% 35 1% /sapcd1
/dev/fslv01 786432 131088 84% 81 1% /sapcd2
/dev/fslv01 786432 131088 84% 81 1% /sapcd2
/dev/fslv02 524288 144392 73% 114 1% /sapcd3
/dev/fslv03 262144 212520 19% 88 1% /sapcd4
/dev/fslv04 524288 238592 55% 33 1% /sapcd5
/dev/fslv05 786432 195736 76% 27 1% /sapcd6
/dev/fslv06 524288 180088 66% 67 1% /sapcd7
/dev/fslv07 786432 235552 71% 104 1% /sapcd8
/dev/fslv08 1310720 219760 84% 12211 20% /sapcd9
/dev/fslv09 524288 231660 56% 571 2% /sapcd10

Benchmark data
/dev/fslv10 1048576 1036436 2% 13 1% /bwbench
DB2 UDB DATA, LOG. LOG Archive, TEMP, DUMP

/dev/lv_db2 131072 130688 1% 21 1% /db2/BW1
/dev/lv_db2log 5242880 5241752 1% 4 1% /db2/BW1/log_dir
/dev/lv_db2log2 5242880 5241752 1% 4 1% /db2/BW1/log_dir2
/dev/lv_db2arch 5242880 5241752 1% 4 1% /db2/BW1/log_archive
/dev/lv_db2arch2 5242880 5241752 1% 4 1% /db2/BW1/log_archive2
/dev/lv_db2retr 1310720 1310192 1% 4 1% /db2/BW1/log_retrieve
/dev/lv_db2temp 1310720 1310192 1% 4 1% /db2/BW1/saptemp1
/dev/lv_db2dump 655360 654932 1% 4 1% /db2/BW1/db2dump
Filesystems for Database objects: Tablespaces, Containers, etc.

/dev/lv_bwfact 20971520 20967992 1% 4 1% /db2/BW1/sapdata11
/dev/lv_bwpsa 20971520 20967992 1% 4 1% /db2/BW1/sapdata12
/dev/lv_bwods 20971520 20967992 1% 4 1% /db2/BW1/sapdata13
/dev/lv_bwaggr 20971520 20967992 1% 4 1% /db2/BW1/sapdata14
Because of the benchmark, the filesystem sizes are larger than recommended.
Now, the SAPinstGUI can be started.

򐂰 The startinstgui.bat file on the PC starts the sapinst client. Figure 6-15 shows
the result.
Figure 6-15 The SAPinstGUI Welcome screen
150 SAP BW and DB2

򐂰 The required CDs are then copied to disk. This reduces the installation time
and provides an unattended loading option of the database export CDs.
After connecting to the SAPinst Server, the Welcome screen appears.

Figure 6-16 shows the available options to install. In this case, they are:
򐂰 WEB AS 6.40
򐂰 SAP PB Business Information Warehouse 3.5
򐂰 SAP XI (Exchange Infrastructure) 3.0.
Figure 6-16 The SAPinst Welcome screen

As a first step, according to Figure 6-17, we select SAP Web AS 6.40 based an
ABAP System for the Central Instance installation.
Figure 6-17 Selecting the Central Instance installation
152 SAP BW and DB2

In this redbook we do not show all of the single installation steps. In the following
Figure 6-18, and in Figure 6-21 on page 156, we show a summary of the
necessary definitions and installation parameters. The SAP NetWeaver
Installation Guide describes the parameters in detail.
Figure 6-18 Summary-1 of installation parameters
The basic definitions and parameters are:

򐂰 The SAP System ID = BW1 to identify the SAP System
򐂰 The Instance number=00. The Instance number identifies the SAP Instance,
which includes an SAP dispatcher and the associated work processes.
Additionally, using the Instance number parameter, the SAPinst creates
TCP/IP ports and the associated services. For example, based on Instance
number 00 the ports 3200, 3300, and 3600 will be created. This is illustrated
in Example 6-7.

Example 6-7 The generated port entries in /etc/services
sapmsBW1 3600/tcp # SAP System Message Port
sapdp00 3200/tcp # SAP System Dispatcher Port
sapdp00s 4700/tcp # SAP System Dispatcher Security Port
sapgw00 3300/tcp # SAP System Gateway Central Instance Port
sapgw00s 4800/tcp # SAP System Gateway Security Port
򐂰 Additionally, the SAPinst asks for the hostname, the database ID and ports,
and userids as well.
We show the Group and the user definition screens in the following figures.
First look at Figure 6-19, and focus on the Additional information heading.
This additional information tells us that the group ID or user ID must be the
same on the additional instances. This then relates to the Group ID number.
In our case, as shown here, the GroupID is 200. That means that on all
additional instances, the same number must be defined, because all UNIX
Systems perform the security activities based on the userID UID or group ID
GID related number.
Figure 6-19 Define the Group sapsys
154 SAP BW and DB2

The installation asks for groups and users. You are able to define the needed
users and groups manually by using the Installation Guides.
However, we recommend that you allow the installation procedure to create the
users and the groups. In this case, you have to fill out the screens provided as
illustrated in Figure 6-20. The screen asks to enter the User ID, the Password,
and the Login Shell. SAP recommends that you work in the c-shell environment.
Figure 6-20 Define a User

After reviewing the installation definitions and parameters on the screens shown
in Figure 6-18 on page 153 and Figure 6-21 here, you could run the installation
by clicking the Start button.
Figure 6-21 Summary-2 of installation parameters
If you have any problems during the installation of the Central Instance, see the
installation log. The installation log is visible using the View Log button which
displays the content of the sapinst.log file.
If an error has occurred, you could restart the installation by clicking the Retry
button. Only in very few cases will it be necessary to clean the directories and
perform the full installation again. This cleanup of the directories is described in
the Installation Guides as well.
The Central Instance installation process:

򐂰 Implements the given definitions and parameters
򐂰 Creates the necessary users and groups
򐂰 Checks the filesystems
156 SAP BW and DB2

򐂰 Installs the SAP Kernel, which includes:
– Compiled executable to start/stop an instance and associated processes
– Interfaces to the Database and the SAPGUI
– Interfaces to other SAP Systems
򐂰 Adapts the filesystems — it assigns the ownership and the read, write, and
execute access.
After all steps run successfully, you will see the screen depicted in Figure 6-22. It
shows that the installation has finished successfully.
Figure 6-22 Install the Central Instance finished successfully
When the Central Instance installation has finished successfully, you can run the
installation of the Database Instance.
6.5.3 Installing the SAP Database Instance

Based on sizing, the decision was made, to install the Database Instance on the
same hardware system as the Central Instance. For safekeeping the logs, we
moved the content of the installation directory to a backup directory.
From the installation directory we again started the SAPinst routine, using the
SAPinstGUI on the PC. By entering the appropriate IP-address and Port 21212,
the welcome screen shown in Figure 6-23 is displayed. We have now begun the
installation of the Database Instance.

Figure 6-23 Start the Installation of the Database Instance
The Database Instance installation process:

򐂰 Checks whether or not the Central Instance is installed successfully
򐂰 Checks user and group definitions
򐂰 Checks the DB2 UDB runtime environment
򐂰 Checks the available filesystems and free space
򐂰 Checks the database objects, such as these:
– Database Instance
– Database schema
– Tablespaces
– Tablespace containers
– Tables and views
– Indexes
򐂰 Loads the database from the tree export CD, provided by the installation
package (and in our project, copied to filesystems).
򐂰 Builds the necessary RFC (Remote Function Call) connections
In this section we show the installation flow graphically. However, we only use
selected screens rather than including all of the screens, as it is a lengthy
process.
To begin the process, you must again enter the SAP SID (System ID), which in
our project was BW1.
158 SAP BW and DB2

With the next step you must choose the installation method according to the
screen shown in Figure 6-24. Two methods are provided:
򐂰 The Standard Installation, from the provided Export CDs
򐂰 A System Copy from an existing SAP installation.
Figure 6-24 The Database Installation Method
For this new installation we have selected the Standard Installation. The
SAPinstgui guides you though the process. You will be asked for such
information as:
򐂰 The hostname, db2bi
򐂰 The SAP administrator user, bw1adm
򐂰 The SAP DB administrator user, db2bw1
򐂰 The group definition, for example, the Database Maintenance Group
򐂰 The available resources, such as swap space and available memory
򐂰 The location of path to the DB2 UDB software, as depicted in Figure 6-25
Figure 6-25 The Path to DB2 UDB

򐂰 The location of the kernel and export CDs. The illustration in Figure 6-26
shows how you can define the path of the export CD. Additionally, you should
let the procedure check the location.
Figure 6-26 The Location of the Export CD
򐂰 The sapdata directories. The sapdata 1 to sapdata xx directories, by default,

include the tablespaces.
򐂰 The name and location of the Temporary Tablespaces.
At this time you must define whether or not you want to use multiple database
partitions. The installation procedure offers you the screen depicted in
Figure 6-27.
Figure 6-27 Single- or Multi partitioned Database
We selected the Single Database partition type for our installation. If you select
single database partitioning, you may choose to define the intrapartitioning
function, which allows you to have parallel access to the database.
During the next steps we define the physical database structure, which includes
the tablespace, indexspace, and container definitions. The installation screens
allow you to adapt the default definitions when your requirements differ from the
standard installation. Figure 6-28 shows the changeable fields for tablespaces.
160 SAP BW and DB2

Figure 6-28 Specifying tablespaces
Each tablespace might contain one or more containers. The installation routine
provides processes to add or change container data as well. These include the
assignment of the containers to other then originally defined directories.
If the database physical structure is defined, you can either accept or redefine
the database bufferpools. Figure 6-29 shows how the bufferpools can be
specified.
Figure 6-29 The Buffer Pool Definition
If all required definitions are performed, the database load options should be
specified. For the database load, parallel jobs are selectable. In our installation
we selected six parallel jobs, which reduces the database load time significantly.

Figure 6-30 shows the available options.
Figure 6-30 Specifying the Load Parameters
After choosing the National Language Option, the installation procedure lists all
the defined parameters for a review. If necessary, the parameters can either be
modified again or you can start the installation by clicking the Start button.
The running activities and steps are marked, as depicted in Figure 6-31.
Additionally, the progress of the currently executing step is displayed.
162 SAP BW and DB2

Figure 6-31 The Installation Progress window
After the database load, the SAPinst starts collecting the runstats to create the
optimizer used statistics.
The runtime for the installation is dependent on the available resources and the
sizing. In our project the installation of the Database Instance ran about two
hours.
The Database Instance is now installed, and the Post-installation activities can
now be started.
6.6 Post-installation activities

After the installation has successfully finished, the Post-installation activities
must be performed. Some of those activities are described in this section.
For example, after installation you must check that you can start and stop the
SAP system. In the SAP Kernel directory /sapmnt/BW1/exe, there are scripts
named startsap and stopsap that are available to start and stop the system.

You must login to the SAP System as user bw1adm (<sapsid>adm), which is the
SAP administrator user. Then you can perform actions such as:
򐂰 Starting the SAP system: This can be performed by entering the command,
startsap, which starts the Database Instance and the Central Instance.
By using options that have been added to the startsap command, the main
components can be started separately. For example:
– startsap DB starts the Database Instance
– startsap R3 starts the Central Instance
Of course, if the database is not running, the Database Instance cannot be

started. Therefore, always make sure that the database is started first.
򐂰 Stopping the SAP system: This action can be performed by entering the
command, stopsap. This stops the Central Instance and the Database
Instance.
򐂰 Logging on to the SAP system: Now you can validate that you can log on to
the SAP system using the SAP provided standard users, sap* and DDIC.
The SAP system must be already started, and an installed front-end tool,
such as SAPGUI for Windows or Java, must be available.
6.6.1 Additional post-installation activities

The Installation Guide describes the required steps for the post-installation
activities in detail. And, you must go through each of these steps. In addition, you
can use the integrated System Administration Assistant.
The SAP System Administration Assistant (SSAA transaction) provides a single

point of control for all systems in the system landscape. It consists of system
management transactions and it provides periodic tasks to monitor and check
the system health. Additionally, it provides assistance and step-by-step guidance
for post installation activities and upgrades.
164 SAP BW and DB2

Figure 6-32 shows the starting screen of the SSAA.
Figure 6-32 The System Administration Assistant start screen
As depicted in Figure 6-32, functions such as Administrative Functions,

Development and Customizing Activities, and Installation Tasks, are provided by
this transaction.
By clicking on the execute symbol, a picture of a small clock, the available

function will displayed. Figure 6-33 shows the tasks provided.

Figure 6-33 The Post-Installation Tasks in the System Administration Assistant
By opening the Installation Follow-up Work folder, the Post-Installation

Activities will be displayed, as shown in Figure 6-33. The System Administration
Assistant then guides you through all of the needed tasks and steps, such as
those listed. The screen also provides direct access to the SAP documentation.
By clicking the list symbol, the associated documentation pages will be opened.
A single task, for example, the first step: Installation Check, can be started by
clicking the clock symbol next to the associated task.
166 SAP BW and DB2

We do not describe all of the single steps, because the provided guidance and
the related documentation does that very well. We encourage you to use it.
However, as examples, we comment on a few of the single tasks.
If you use a language other than German or English, you will have to install the
appropriate language for the client copy.
After the installation, the recommended SAP Notes must be implemented.

Example 6-8 shows the adoption of the DB2 parameters according to the
SAP Note 584952 for the SAP Business Information Warehouse SAP BW.
We changed the DB2 parameters in the Command Line Processor for DB2,
where the DB2 UDB commands can be entered directly. We do not explain all of
the single parameters. You will find any comments and hints concerning those
parameters in the SAP Note 584952.
As can be seen by the comments in Example 6-8, there is a requirement to

restart the DB2 UDB after some of the changes have been made.
Example 6-8 DB2 parameter changes recommended in SAP Note 584952

db2 => UPDATE DB CFG FOR BW1 USING LOCKLIST 40000
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
db2 => UPDATE DB CFG FOR BW1 USING SORTHEAP 15000
SQL5155W The update completed successfully. The current value of SORTHEAP
may adversely affect performance.
db2 => UPDATE DB CFG FOR BW1 USING STMTHEAP 10000
db2 => UPDATE DB CFG FOR BW1 USING AVG_APPLS 3
db2 => UPDATE DBM CFG USING SHEAPTHRES 150000
DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.
db2 => UPDATE DBM CFG USING INTRA_PARALLEL YES
successfully.
db2 => UPDATE DBM CFG USING MAX_QUERYDEGREE 4
successfully.
db2 => UPDATE DBM CFG USING NUM_POOLAGENTS 80
successfully.
db2 => UPDATE DBM CFG USING INSTANCE_MEMORY AUTOMATIC
successfully.
db2 => UPDATE DBM CFG USING AGENTPRI SYSTEM
successfully.

db2 => UPDATE DBM CFG USING MAX_COORDAGENTS 1024
successfully.
db2 => UPDATE DBM CFG USING MAX_CONNECTIONS 1024
successfully.
db2 => UPDATE DBM CFG USING MAXCAGENTS 1024
successfully.
db2 => UPDATE DB CFG FOR BW1 USING MAXAPPLS AUTOMATIC
db2 => UPDATE DB CFG FOR BW1 USING BLK_LOG_DSK_FUL YES
db2 => UPDATE DB CFG FOR BW1 USING INDEXREC restart
db2 => UPDATE DB CFG FOR BW1 USING LOGRETAIN RECOVERY
db2 => UPDATE DB CFG FOR BW1 USING USEREXIT on
SQL1363W One or more of the parameters submitted for immediate modification
were not changed dynamically. For these configuration parameters, all
applications must disconnect from this database before the changes become
effective.
db2 =>
In addition, the SAP Support Packages must be downloaded and installed

from the SAP Service Marketplace or from the SAP File Server sapserv3,
sapserv4, sapserv5, sapserv6, or sapserv7. The location and the IP-addresses for
these servers are shown in Table 6-4.
Table 6-4 The SAP FTP Servers sapservx

SAP FTP-Server IP Address Location
sapserv3 147.204.2.5 Germany, Walldorf
sapserv4 204.79.199.2 USA, Foster City
sapserv5 194.39.138.2 Japan, Tokyo
sapserv6 147.204.96.8 Australia, Sidney
sapserv7 194.39.134.35 Singapore
168 SAP BW and DB2

After installing the required support packages and corrections, we started the
Client Copy. The term, Client Copy, has nothing to do with term Client/Server. It
represents independent business units or subsidiaries in an enterprise. A Client
has its own independent and secured data environment in an SAP System.
In a BW system, SAP delivers the clients 000 and 066. They are defined as:
򐂰 Client 000 is the SAP reference Client.
򐂰 Client 066 is the Early Watch Client, which is used from SAP when there are
customer requested support activities.
For the Client Copy, the following activities must be performed:

򐂰 Logon to User sap* on client 000
򐂰 Start the client maintenance transaction with /nscc0 in the command field
򐂰 The table T000 will be opened, as shown in Figure 6-34. It shows the
available clients and basic definitions.
Figure 6-34 Define the Client 900

By clicking the New Entries button, the screen shown in Figure 6-35 appears.
You can use this screen to define the client number, the client role, the client
change options, and the CATT (Computer Aided Test Tool).
By using the screen depicted in Figure 6-35, values can be entered. Then the
save symbol, represented by the small yellow diskette, must be clicked.
Figure 6-35 Add the client 900
170 SAP BW and DB2

The Client is created now. As the illustration in Figure 6-36 shows, you can
Login to the new client with sap* and the well known password, pass.
Figure 6-36 Login to the new Client 900
Using the transaction /nscc4, you select the copy options as desired for the
client copy activity. Here are some data areas that are selectable:
򐂰 Customizing
򐂰 User definitions
򐂰 Application data
The installation is now finished and complete.
At this point, the ASP business consultants typically start with entering additional
SAP BW (Business Information Warehouse) related activities and definitions.
These steps are described in the following section.

6.7 Business Information Warehouse definitions
After the installation of the NetWeaver 6.40, BW related definitions must be
performed. If needed, the BW Business Content must be installed as well.
6.7.1 BW general settings

Setting the BW General Settings should be performed by the business consultant
in cooperation with the technical consultant. For the general settings, please use
the Implementation Guide (IMG). The IMG is an integrated part of SAP
NetWeaver and guides you through the definition steps. You start the IMG by
entering the transaction SPRO_ADMIN and selecting the SAP Reference IMG.
The opened IMG is shown in Figure 6-37.
Figure 6-37 The SAP Reference IMG with opened BW Settings
172 SAP BW and DB2

6.7.2 Installing the SAP Business Content Add-on
After installing the Central Instance in the BW system, you must install the
Business Content Add-on. In this redbook project, we used BI_CONT 351. SAP
recommends that you install all support packages available for this Add-on.
Note: Please check the SAP Note 634214 to verify the minimum requirements
necessary to install BI_CONT 351 and get the password to install this Add-on.
The following are steps to install the Business Content Add-on:

1. Insert CD51020636 Add-On Installation BI_CONT 351.
Tip: In the CD 51020636 Add-on Installation BI_CONT 351, there is an

Add-on installation procedure in a PDF file in the directory /<cdrom>/DOCU/.
You can also download this file to help you install the BI_CONT Add-on.
2. Log-on to the system as user <sid>adm and perform the following:

a. cd /<cdrom>/DATA
b. cp KIBIDIH.SAR to /usr/sap/trans
c. cd /usr/sap/trans
d. Disassemble package using the commands:
SAPCAR -xvf KIBIDIH.SAR
The disassembled package appears in the EPS inbox of the transport
directory as:
EPS/in/CSR0120031469_0017447.PAT
3. Next, log-on as Client 000 (a user different than SAP* and DDIC) and go to
the transaction SAINT. This is the SAP Add-on Installation Tool.
If you need information about the user authorization, please check the Add-on
installation guide (page 7).

4. Load the Add-on package as described in Figure 6-38.
Figure 6-38 Transaction SAINT - Load BI_CONT package
5. The system confirms the successful upload of the package, as depicted in

Figure 6-39.
Figure 6-39 Upload successful
174 SAP BW and DB2

6. After the upload, the package can be viewed in the main screen of the SPAM
(SAP Patch Manager), as depicted in Figure 6-40.
7. Select the package and click the Continue button.
Figure 6-40 Select the package

8. Check to see that the correct package has been selected and click the
Continue button, as depicted in Figure 6-41.
Figure 6-41 Check the selected package
176 SAP BW and DB2

9. Read SAP Note 634214 and get the installation password, as described in
Figure 6-42.
Figure 6-42 Password Add-on installation
10.Now you can click the Start Options button to install the Add-on. This is
depicted in Figure 6-43. It may be best to start in background mode, as this
will enable the maximum run time dialog parameter to be reached. In our
project environment, this package took about 30 minutes to run.
Tip: Before starting the package installation, make sure that you have enough
free space in the BW tablespaces. Some guidelines are shown here:
<SID>#BTABD — at least 1 GB free

<SID>#PROTD — at least 350 MB free
<SID>#POOLD — at least 1 GB free
<SID>#POOLI — at least 1 GB free
<SID> #STABI — at least 1 GB free

Figure 6-43 Select start option
11.You can check the Add-on installation in the main screen of SAINT, see
Figure 6-44. Another way to see the Add-on installation is to go to transaction
SE16 and list the contents of table AVERS.
Figure 6-44 Check Add-on installation in your system
12.Apply all support packages for this Add-on using transaction SPAM, and
check all relevant notes to define the queue correctly.
This completes the Add-on installation.
178 SAP BW and DB2

6.7.3 Installing an additional Dialog Instance
After the Central Instance installation, you can install a Dialog Instance in
another logical partition (LPAR) or in another server.
In this redbook project, the Dialog Instance is installed on a separate server from
the Central Instance. The servers and equipment used were described before in
Table 5-1 on page 111. You can see a diagram of the project configuration in
Figure 6-45.
Central and Database

Instances Application Server
C
A EtherNet 100MB
P-Series 630
P-Series 650
FiberChannel
FiberChannel Switch 2
Switch 1
205 GB RAID/5 (vg1)
FASt T700
Storage
Figure 6-45 Landscape for Application Server installation

1. To install an application server on another server, first you need to check all
requirements for the operational system. You can use the same information
used for the Central Instance installation, described in 6.5.2, “Installing the
Central Instance” on page 148.
2. The next step is to install DB2 Administration Client as described on page 84
of the SAP NetWeaver’04 Installation Guide.
Notes:
򐂰 For the standard installation of the DB2 Administration Client v.8,
the files reside in the /usr/opt directory. If you want to use the standard
installation, you should have at least 300 MB in /usr/opt for this client.
򐂰 When you create the /db2 file system, it should contain at least 20 MB for
the home for user db2<sid>.
a. Install the DB2 FixPak Software according to page 82 of the SAP

NetWeaver’04 Installation Guide.
At this point, you can begin the Dialog Instance installation steps.
Notes:
򐂰 You need to create the file system /usr/sap/<SID> with at least 500 MB.
򐂰 From the Central Instance server, export the /sapmnt/<SID> file system to
the application server.
򐂰 From the application server, mount the NFS (Network File System) with the
mount point: /sapmnt/<SID>
180 SAP BW and DB2

You can see the SAP File System structure depicted in Figure 6-46.
Central and Database instance Application Server
p-Series 650 p-Series 630
Sap usr Sap usr
<SAPSID> trans NFS trans <SAPSID>
<instance name> SYS <instance name> SYS
log data work exe profile global log data work exe profile global
dbg opt run dbg opt run

NFS sapmnt NFS ctrun
sapmnt
Symbolic Link <SAPSID> <SAPSID>
ctrun = SAPCPE
is active exe profile global exe profile global
Figure 6-46 SAP File systems environment
Tip: If you have the same operating system in the Central Instance and the
Application Server, you can activate sapcpe. Please refer to page 105 in the
SAP NetWeaver’04 Installation Guide.
3. ABAP Dialog Instance Installation procedure:

a. Be certain that the user root is defined as unlimited.
b. Mount the SAPINST CD.
c. Create an installation directory with at least 400 MB, and permissions 777.
d. Using the default installation directory, as user root, enter the following
command:
/<cdrom>/SAPINST/UNIX/AIX_64/sapinst
The results of this command are depicted in Figure 6-47.

Figure 6-47 SAPINST wait for client connection
e. Now start the SAPINST in your PC, using the appropriate IP and port
number, as shown in the example in Figure 6-48.
Figure 6-48 SAPINST client connection
f. Select: Install a Dialog Instance on the ABAP System folder, as shown in

Figure 6-49.
Figure 6-49 Select ABAP non-Unicode Dialog Instance
182 SAP BW and DB2

g. Enter the SAP System ID by using the same name as the Central Instance
and choose one system number for your application server. See
Figure 6-50 as an example.
Figure 6-50 ABAP Dialog Instance parameters
h. Next enter the Central Instance parameters, as depicted in Figure 6-51.
Figure 6-51 Central Instance parameters

i. Now enter the Database Instance parameters, as depicted in Figure 6-52.
Figure 6-52 Database Instance parameters
j. Now you can continue with the installation with the following steps:
• Select Instance memory management.
• Specify no LDAP support.
• Specify the location of the Instance Files: /sapmnt.
• Specify the database specific parameters.
• Specify the operational system group and user.
• Do not extract the SAP System Kernel.
• Check SAP System ports.
• Specify the path to the Database Software.
• Enter the location of IGS software.
• Start the installation.
k. Log-on to the system as user <sid>adm and execute the following
command:
R3trans -d
Tip: If you have a problem starting the Dialog Instance, it may be because the
database connection has not been established. Verify that there is a database
connection.
184 SAP BW and DB2

l. To activate sapcpe, refer to page 105 of the SAP NetWeaver’04
Installation Guide.
m. Next, start the application server. Status can be seen, as shown in
Figure 6-53.
Figure 6-53 Dialog Instance Active
Installation of the Dialog Instance is now complete.
6.8 HACMP for high availability

In this section we discuss the topic of a high availability environment for your
applications. Such applications might be processing customer orders or
performing stock trading transactions, for example. These types of transactions
are critical and must not be lost, even in the event of hardware or software
failures. Or, they are critical because they represent revenue that would be lost if
the system were not available.
In addition to minimizing the impact of a failed resource, a primary goal of high

availability software is to minimize, or eliminate, the need to take your resources
out of service during maintenance and reconfiguration activities.
HACMP has two products, namely, HACMP Classic and HACMP/ES (Enhanced
Scalability). HACMP/ES has some in-built features, which allow application
monitoring. The easiest form of this is process monitoring where you can add
specific process names, and HACMP will monitor these and take action if these
processes vanish. The level of action that can be taken can be fine-tuned from
something as simple as alerting Tivoli to instigating failover.
Process monitoring is becoming increasingly important, and will continue as the

industry evolves to realtime business intelligence. To enable access to more
current information, it is suggested that ES version should be used.

6.8.1 High availability and fault tolerance
HACMP is typically used for building UNIX-based highly available computing
platforms. HACMP software ensures that critical resources, such as applications,
are available for processing. There are two major components:
򐂰 High availability (HA)
򐂰 Cluster multi-processing (CMP)
High availability is sometimes confused with simple hardware availability. Fault

tolerant, redundant systems (such as RAID data storage), and dynamic switching
technologies, provide recovery of certain hardware failures but do not provide the
full scope of error detection and recovery required to keep a complex application
highly available.
Fault tolerance relies on specialized hardware to detect a hardware fault and

instantaneously switch to a redundant hardware component — whether the failed
component is a processor, memory board, power supply, I/O subsystem, or
storage subsystem. Although this cutover is apparently seamless and offers
non-stop service, a high premium is paid in both hardware cost and performance
because the redundant components do no processing. More importantly, the
fault tolerant model does not address software failures, which is by far the most
common reason for downtime.
For example, a complex application requires access to elements such as:

򐂰 Nodes (processor and memory)
򐂰 Network interfaces (including external devices in the network topology)
򐂰 Disk or storage devices.
In addition, there are other even more critical factors that enter in to cause
unplanned system outages. These are such things as:
򐂰 Operator errors
򐂰 Environmental problems
򐂰 Application and operating system errors
With these types of elements, reliable and recoverable hardware just cannot
protect against failures caused by them.
High availability is not simply redundant hardware. It is a set of system-wide,

shared resources that cooperate to guarantee essential services. High
availability combines software with hardware to minimize downtime by quickly
restoring essential services when a system, component, or application fails.
While this is not instantaneous recovery, services are restored very rapidly. Often
the downtime is measured in periods of less than a minute.
186 SAP BW and DB2

Fault tolerance, then, is an environment that essentially has no downtime but at a
very high cost. A highly available environment is one that may have a minimal
period of downtime, and at a much lower cost. Many clients are willing to absorb
a small amount of downtime with high availability rather than pay the much
higher cost of providing duplicate hardware based fault tolerance. Additionally,
the duplicate hardware cannot be used for normal day-to-day processing.
6.8.2 HACMP clusters

HACMP provides a highly available environment by identifying a set of resources
that are required for high availability. And, it defines a protocol that nodes can
use to ensure that these resources are available. The clustering model is
extended by defining relationships among processors so that each can provide
the service of the other.
An HACMP cluster is made up of the following physical components:

򐂰 Nodes
򐂰 Shared external disk devices
򐂰 Networks
򐂰 Network interfaces
򐂰 Clients.
Nodes form the core of an HACMP cluster, and are processors that run both AIX
and the HACMP software. The HACMP software supports pSeries uniprocessor
and symmetric multiprocessor (SMP) systems, and the Scalable POWERParallel
processor (SP) systems as cluster nodes. To the HACMP software, an SMP
system looks just like a uniprocessor. SMP systems provide a cost-effective way
to increase cluster throughput. Each node in the cluster can be a large SMP
server, extending an HACMP cluster far beyond the limits of a single system and
allowing thousands of clients to connect to a single database.
In an HACMP cluster, to ensure the availability of applications, they are put

under the control of HACMP, where measures are taken to ensure that the
applications remain available to client processes even if a component in a cluster
fails. To ensure availability, in case of a component failure, HACMP moves the
application (along with resources that ensure access to the application) to
another node in the cluster.
Clustering two or more servers to back up critical applications is a cost-effective

high availability option. You can use more of your sites computing power while
ensuring that critical applications resume operations after a minimal interruption
caused by a hardware or software failure.

Cluster multi-processing is accomplished by a group of loosely coupled servers
networked together, sharing disk resources. In a cluster, multiple servers
cooperate to provide a set of services or resources to clients. It also provides a
gradual, scalable growth path. It is easy to add a processor to the cluster to
share the growing workload. You can also upgrade one or more of the
processors in the cluster to a more powerful model. If you were using a fault
tolerant strategy, you must add two processors, one as a redundant backup that
does no processing during normal operations.
The HACMP software allows you to combine physical components into a wide
range of cluster configurations to meet your requirements. Figure 6-54 shows an
example of an HACMP cluster. You can see that the nodes and disks are all
connected with redundant busses to enable uninterrupted communications. One
node can pick up the workload of a failed node, and the disks are mirrored in the
event of a disk failure.
HACMP builds on the inherent reliability of the hardware to provide higher

availability for applications and enables upgrades and reconfiguration without
interrupting operations.
Clients
Nodes
LAN
Disk Busses
Shared disk with mirrors
Figure 6-54 HACMP cluster
188 SAP BW and DB2

HACMP software optimizes availability by allowing for the dynamic
reconfiguration of running clusters. Most routine cluster maintenance tasks, such
as adding or removing a node or changing the priority of nodes participating in a
resource group, can be applied to an active cluster without stopping and
restarting cluster services.
SAP BW on a DB2 multi-partition database, can also be installed in an HACMP

cluster of physical servers. One database partition can be located on each
server. This configuration requires that the network connection has sufficiently
low latency times to provide the network speed that is required for
communication between the database partitions.
In addition, you can keep an HACMP cluster online while making configuration
changes by using the Cluster Single Point of Control (C-SPOC) facility. C-SPOC
makes cluster management easier, as it allows you to make changes to shared
volume groups, users, and groups across the cluster from a single node. The
changes are propagated transparently to other cluster nodes.
High availability is typically associated with business-critical transaction

environments. However, this capability is becoming increasingly important as
businesses evolve towards realtime business intelligence. In a data warehousing
environment, such as with SAP BW, an HACMP cluster could run a database
server to service the client queries being used for business intelligence.
HACMP resource groups

A resource group in HACMP is a group that contains all the components that are
to be protected with HACMP. This includes such components as network
adapters, IP addresses, and volume groups. Three types of resource groups
have been defined:
1. Concurrent Resource Groups: The resource is active on all nodes within
the cluster at the same time. If one node fails the resource group does not
move as other nodes continue to provide service.
2. Rotating Resource Groups: Resource group is active on one node only,
and in the event of failover the resources are taken over by other nodes in the
cluster. This node then becomes the primary node in the cluster (fallback to
the original node is not required).
3. Cascading Resource Groups: Similar to the rotating resource group except
in the event of failover the resources need to return to the original node.

Each clustered system will be have a single resource group with at least two
nodes. The nodes within the cluster will not be equal. That is, one node will
always be the primary and the other node will be seen as a standby.
The resource group will be defined as Cascading utilizing the without fallback
option. This will allow the resources to be returned to the primary server after
failover has occurred in a controller manner. Configuring the resource group
without this option allows fallback when service to the primary server is restored
resulting in a second application outage.
There are also tools within HACMP/ES to enable measurement of application

availability. HACMP/ES collects time-stamps, and logs that contain monitoring
information. This information can be used to provide a report of application
availability, whenever required. However, availability of the application is
measured from the HACMP point of view - which may be different than a
measurement taken from the end-users point of view. This difference can be
reconciled based on the particular requirements.
HACMP in a multi-partition database environment

Figure 6-55 shows an example of SAP BW on a DB2 multi-partition database,
which is installed in an HACMP cluster of six physical servers. One database
partition is located on each server. This example was taken from an actual
customer installation. As shown in the figure, the servers are hosted at two
different locations, which are connected via a high-speed MAN (metropolitan
area network) link.
This is an unusual configuration and requires that the network connection has
sufficiently low latency times to provide the network speed that is required for
FCM communication between the database partitions.
190 SAP BW and DB2

Site 1
Server 1 Server 2 Server 3
R/3tablespaces
Temp tablespaces PSAPTEMP, PSAPTEMP16
PSA/ODS, Fact tablespaces
Arrows represent failover direction over MAN link
Server 4 Server 5 Server 6

Temp tablespaces PSAPTEMP, PSAPTEMP16
PSA/ODS, Fact tablespaces
Site 2
Figure 6-55 Example for SAP BW/DB2 database in HACMP failover configuration
There are a number of approaches that can be used to enable high availability,
depending on client requirements. HACMP offers a robust capability and can
meet the requirements of many businesses.

192 SAP BW and DB2
7
Chapter 7. Administration of SAP BW

This chapter introduces the SAP Business Information Warehouse (BW)
administration facilities. Different roles are involved in the operations
management, which must provide high availability and deterministic performance
for the SAP BW System. Typically the required availability is described in a
Service Level Agreement (SLA).
First we describe the standard SAP administration tasks are first described, and
then some of the more typical administration activities involved with SAP BW.

7.1 Role-based administration
Here are some of the basic roles that are involved in the administration tasks:
򐂰 The Database Administrator is responsible for the regular day-to-day
maintenance and support of the DB2 UDB.
򐂰 The Network Administrator supports and maintains the installed network
components.
򐂰 The System Administrator maintains and controls the Operating System.
򐂰 The SAP Basis Consultant or Technical Consultant is responsible for the SAP
related maintenance and support activities.
򐂰 The BW Administrator maintains the BW Environment.
The SAP BW System provides many predefined roles, which can be displayed
with the RSU2 transaction by using the /nrsu01 command.
Example 7-1 shows the description of the BW Administrator and BW Query User
roles.
Example 7-1 Description of selected roles

The BW Administrator Role:
The BW Administrator is responsible for customizing and maintaining the BW
systems. All the authorizations a user requires to execute the customizing
transactions and the maintenance transactions in a BW System, are
incorporated into this role.
The BW Query User:
This role contains all the authorizations a user requires to execute queries
and workbooks in the Workplace.
The DB administrator role provides the basic database functions by the menu
structure in the launchpad, as depicted in Figure 7-1. Depending on the company
size and the complexity of the system landscape, some of the administration
roles may be combined.
194 SAP BW and DB2

Figure 7-1 The DB administrator role and the assigned navigation options
These are the administration and maintenance tasks discussed in this chapter:
򐂰 DB2 UDB administration
򐂰 Periodic administration activities for the BW system
򐂰 DB2 UDB related maintenance tasks, such as:
– Backup and recovery
– Storage management
– Using runstats and reorg
򐂰 BW administration tasks
Chapter 7. Administration of SAP BW 195

7.2 DB2 UDB administration
SAP BW provides a complete set tasks for DB2 administration. Figure 7-2
shows, in the left pane of the graphic, the available configuration facilities and the
CLP (Command Line Processor) commands.
Figure 7-2 The DB2 UDB Database Administration panel
The configuration facilities available are for the following tasks and activities:
򐂰 Database manager
򐂰 Database
򐂰 Parameter changes
򐂰 Buffer pools
򐂰 Data classes predefined by SAP
򐂰 CLP
You can use these functions for changing names, objects, or parameters, and
also for monitoring. Figure 7-3 shows an example of a Buffer Pool Snapshot for
the Default Buffer Pool, by using the Command Line Processor to display the
bufferpools.
196 SAP BW and DB2

Figure 7-3 Buffer pool snapshot for the default BP

Figure 7-4 shows a list of all the buffer pools. Because the DB BufferPools have a
high impact on performance, you can compare, for example, the logical reads
and the physical reads to analyze the effectivity of the buffer pool usage.
Figure 7-4 The buffer pool 16K
By using the Database Administration Facility, you can analyze and create data
classes. The data classes are defined by SAP, and includes, for example, user
data classes such as:
򐂰 APPL0, APPL1, APPL2
򐂰 USER1
Also included are system data classes such as:

򐂰 CLUST (clustered tables)
򐂰 POOL (pooled tables)
򐂰 SDIC (dictionary objects)
198 SAP BW and DB2

Newly defined objects should be created according to the SAP recommended
naming convention. Figure 7-5 shows some of the data classes in a typical
implementation.
Figure 7-5 The data classes

7.3 Periodic activities
To maintain control in a complex systems environment, a proven operations
management procedure is very helpful. SAP provides this capability with the
SAP System Administration Assistant (SSAA) tool and step-by-step guidance for
the required periodic activities. The SSAA is started by entering the command
/nssaa in the command field. The SSAA screen, such as the one depicted in
Figure 7-6, will then be displayed.
Figure 7-6 The System Administration Assistant
You can then click the execute symbol (clock) and expand the nodes:
-> Running Your SAP System
--> BW1: Checklist for Operating the Production System
----> BW1: Daily Tasks
This will result in a list of tasks and activities like those depicted in Figure 7-7.
These are daily tasks that need to be performed for this day, as determined by
the SAP system.
200 SAP BW and DB2

Figure 7-7 The SSAA daily tasks
As the illustration in Figure 7-7 shows, there are icons that provide links to the
documentation (to the left of the clock icon) and activity status symbols. The red
activity symbols indicate that the task has not been started. When the task has
been performed, the indicator will turn green.
As you can see, the SSAA daily task list also lists the DB2 UDB and filesystem
maintenance tasks that are to be performed. We recommend that you use the
SAP System Administration Assistant as a standard procedure for monitoring
and performing the recommended activities. On request, the SSAA will display
the user and the time that the activity was started.
The SSAA also provides weekly, monthly, and unscheduled/occasional tasks to

be performed. The time periods are standard recommendations, so you should
adapt these recommendations to your enterprise operations requirements.
Figure 7-8 shows an example of the SSAA weekly and monthly tasks for DB2
UDB related administration. These are tasks such as performing offline backups
and changing the password for the database administrator.

Figure 7-8 The weekly, monthly, and occasional tasks
As shown in Figure 7-8, the periodic activities can be devided into two primary
groups:
1. Monitoring and maintenance of the SAP functions, which helps to provide
proactive systems management
2. DB2 UDB related maintenance and support functions
It is assumed that, as a prerequisite, monitoring the SAP functions will be a

selected administration task. There should also be a focus on the database
administration tasks to maintain good database health, to minimize system
downtime, and to improve, and maintain, performance.
7.3.1 Storage management

When the database objects are growing, additional space must be allocated.
DB2 UDB can use two types of storage. The tablespace can be either System
Managed Space (SMS) or Database Managed Space (DMS).
The SAP BW database objects are loaded into DMS Storage. For a DMS
tablespace, each container is either a fixed-size pre-allocated file or a physical
device such as a disk. The DB2 UDB Database Manager (DBM) controls the
storage. If database objects grow, the DBM allocates additional space at the
extent level.
202 SAP BW and DB2

Attention: The allocation of the new extent fails if there is no space available
in the tablespace container. To avoid this problem, it is necessary to
periodically monitor the storage and the tablespaces.
Figure 7-9 depicts the results of the performed transaction /nst06 and the
selection for the filesystem details. You can monitor if free space is available in
the filesystems. If the threshold level is reached, the system creates an alert,
which is visible in the alert monitor. You can start the alert monitor using the
transaction rz20.
Figure 7-9 Free space in filesystems

You can perform the storage management activities online, even if the
application and the database are running. To prevent system downtime, perform
the required extension of the storage objects in advance. After extending the
space, DB2 UDB starts to rebalance. That is, it distributes the data between the
container and extents. This takes some time, therefore schedule this task during
a period of low user and system activities.
7.3.2 Tablespace and container administration

With DB2 UDB, the data and index tablespaces are separated. To improve the
performance, we typically recommend that you even separate the data and index
tablespaces on different disks, and if possible access them using different
physical access paths.
During the installation procedure, SAP defines and creates the tablespaces.
Example 7-2 shows a partial example of the installation procedure, including
some of the primary attributes of the tablespace, such as these:
򐂰 A pagesize of 4 KB or 16 KB: DB2 UDB stores data in pages, which also
can have a size of 8 KB or 32 KB.
򐂰 An extentsize of 8,16 or 32: The extent defines the number of pages that are
written to a container before switching to the next extent. Typically the next
extent is allocated in another container. SAP typically defines the extent size,
which is between 4 and 64 pages.
򐂰 Managed by system: This is only for the temporary tablespaces. When it is
an SMS tablespace, each container is a directory in a filesystem.
򐂰 Managed by database: This is used for all other tablespaces.
Example 7-2 Create tablespace examples in the installation procedure

db2 create temporary tablespace PSAPTEMP in nodegroup IBMTEMPGROUP pagesize 4k
managed by system extentsize 32 prefetchsize 32 DROPPED TABLE RECOVERY OFF
db2 create temporary tablespace PSAPTEMP16 in nodegroup IBMTEMPGROUP pagesize

16k managed by system extentsize 16 prefetchsize 16 buffer pool BP_STD_16K
DROPPED TABLE RECOVERY OFF
db2 create tablespace BW1#STABD IN NODEGROUP SAPNODEGRP_BW1 PAGESIZE 4k managed

by database using (FILE '/db2/BW1/sapdata1/NODE0000/BW1#STABD.container000'
256000) ON NODE ( 0 ) extentsize 8 prefetchsize 8 DROPPED TABLE RECOVERY OFF
db2 create tablespace BW1#STABI IN NODEGROUP SAPNODEGRP_BW1 PAGESIZE 4k managed

by database using (FILE '/db2/BW1/sapdata2/NODE0000/BW1#STABI.container000'
179200) ON NODE ( 0 ) extentsize 8 prefetchsize 8 DROPPED TABLE RECOVERY OFF
204 SAP BW and DB2

Figure 7-10 depicts a tablespace configuration, and includes the following types
of information:
򐂰 The result of starting the DB6SPACE transaction
򐂰 Selecting the space and tablespace in the navigation area
򐂰 Sorting the percentage-used in descending order.
The right pane in Figure 7-10 shows that the temporary tablespaces (the first two
entries in the Tablespace column) are system managed (SMS) tablespaces.
Since they are system managed, the values for percentage-used are set to
100%. They can be extended as long as there is free space available in the
filesystem. All other tablespaces in the list shown are database managed (DMS),
and should be analyzed periodically.
Figure 7-10 Space: Tablespace Configuration, using the transaction DB6SPACE
After making a tablespace analysis, if required you can add space to a

tablespace by using DB6SPACE transaction. For example, you could select a
particular analyzed tablespace such as one shown in the Tablespace list in
Figure 7-10. After selecting the particular tablespace, you click on the change
button (not shown in the sample figure) to start the process.

Space can also be added by either of the following approaches:
򐂰 Adding another container
򐂰 Resizing all containers to the required sizes
Figure 7-11 depicts the facility used to add more space with containers. That can
be accomplished by entering the desired values and executing the changes. The
system automatically generates the alter tablepace SQL statement and
performs it. An example of this can be seen in the bottom portion of Figure 7-11.
Figure 7-11 Adding space
Important: When a new container is added, DB2 UDB rebalances the

allocated space. For extremely large tablespaces with many containers, the
rebalancing process can take some time. We recommend that you schedule
this maintenance activity during a period of low systems utilization.
If a particular BW table seen to be growing very fast, it can be separated from the
existing tablespace. In addition, you can assign it to another buffer pool to
minimize the response time and improve performance.
206 SAP BW and DB2

7.3.3 The optimizer and runstats
DB2 has a powerful cost-based optimizer to enable maximum performance. The
optimizer determines the best access strategy for changing or reading the data
residing in the database. The access strategy is based on such things as:
򐂰 Size of the table.
򐂰 Available indexes, and their selectivity. Selectivity, for example, may be
determined based on the number of different entries in the indexed column.
򐂰 Fields defined in the WHERE clause of the SQL statement.
򐂰 Database configuration.
The optimizer uses the statistics of the database objects, such as tables, views,
and indexes, to find he best access path. The statistics should be kept current to
enable the optimizer to pick the best path. The runstats utility collects the
statistics for the tables and indexes, and updates them in the DB2 catalog.
After the database server installation, the runstats utility will collect statistics on
the all tables in the database. Database activity should be monitored to be aware
of when, for example, large volumes of data have been inserted into, or deleted
from, the database, then the runstats utility should be used to refresh the
statistics. The BW System offers transactions and ABAP programs that provide
support for these types of maintenance requirements.
SAP provides a Two-Phase Strategy, to keep the database statistics current:

1. Phase one determines if the database objects need statistics. Those objects
needing statistics are flagged.
2. Phase two invokes the runstats and reorg utilities to run on the flagged
database objects.
The following is a list of SAP provided database administration functions to

enable updating of the statistics with the runstats utility.
򐂰 Start transaction DB13 with the command /ndb13. This invokes the Planning
Calendar that is used to schedule the administration activities, as depicted
later in Figure 7-17 on page 213. Here you are able to add and define new
activities by clicking the Add button.
򐂰 After clicking the Add button, the screen displayed in Figure 7-12 appears.
Now you can specify the required actions. As an example, you can select the
action Check Tables for Statistics Update. You may also choose to specify
the Action Parameters and recurrence (by selecting the Recurrence tab).
The actions performed are provided by the SAP product. Examples of those
actions are shown later in Figure 7-17 on page 213, in the Action Pad list.

򐂰 The activities specified can be executed immediately, or scheduled.
Figure 7-12 Check Tables for Statistics Update
As previously mentioned, the database objects that need statistics updated are
flagged. To see the flagged database objects, run either the transaction DB2 by
entering /ndb2, or transaction ST04 by entering /nst04, in the command field.
In the NetWeaver Web Application Server (WAS) 6.40, both transactions open an
identical screen.
Figure 7-13 shows the left pane of the DB2 and ST04 transaction screen. Select
the RUNSTATS Settings to get a list of flagged database objects.
208 SAP BW and DB2

Figure 7-13 Displaying the RUNSTATS Settings
Figure 7-14 shows a list of the BW tables that are flagged for RUNSTATS. That
screen also provides additional information, such as:
򐂰 The last runstats date and time
򐂰 The volatility of the table
򐂰 The table cardinality (the number of different values in the clustered
columns).
This valuable information is intended for use by the system administrators.

Figure 7-14 Tables flagged for runstats
By selecting a particular row in the displayed table, additional detailed

information about that database object will be provided. An example is provided
in Figure 7-15, and has information such as:
򐂰 Table name
򐂰 Associated indexes
򐂰 The runstats control information
򐂰 Information about the last reorg check
򐂰 Recommendations about how runstats should be scheduled, either
automatically or manually by user request.
210 SAP BW and DB2

Figure 7-15 Table details
To see the recommendations on scheduling runstats, you must first select the tab
RUNSTATS Control. An example of the information on that tab is shown in
Figure 7-16. It not only shows the type of Scheduling recommended, but also
shows such information as the Statistics Attributes, Table Analysis Method, and
Index Analysis Method.

Figure 7-16 The runstats details for a table
Using the SAP provided Planning Calendar (transaction DB13), you can
schedule the needed activities. In the example shown in Figure 7-17, you can
see that the following activities have been scheduled:
򐂰 The reorg check (Reorgck_All)
򐂰 The check for runstats (Stats_Check)
򐂰 The execution of the runstats utility on flagged objects (Run_DBSTATC).
We suggest that you develop and document an operations concept for your
production environment. There you would describe the scheduled activities,
including all of the necessary activities for DB2 UDB Health.
212 SAP BW and DB2

Figure 7-17 The Planning Calendar
If you elect to schedule the REORG and RUNSTATS of the Flagged Tables
activity manually, the screen depicted in Figure 7-18 will be displayed. You can
then select from the two options, to run manually:
򐂰 Select to run all manually by clicking the Select All button.
򐂰 Select one or more tables by clicking the icon in the leftmost column of the
desired row(s).

Figure 7-18 Use of runstats and reorg on flagged tables
Based on daily checklist or on demand activities, you can display the Database
Administrator (DBA) Action Log. Figure 7-19 shows an overview of the executed
jobs and indicates whether or not they have run sucessfully. You may also see
some of the runstats-related activities.
214 SAP BW and DB2

Figure 7-19 The DBA Action Log
7.3.4 Tablespace reorganization

How the stored data are physically distributed has a significant impact on the
performance of SAP BW. To maintain performance levels, this distribution of
data needs to be monitored, and, if necessary, reorganized. In this section we
discuss the options available for reorganizing the DB2 tablespaces.
Starting with testing and production, the following are examples of operations
that may affect the physical distribution of data:
򐂰 Deleting data may leave empty pages.
򐂰 Inserts of new data may be written to different physical storage elements.
򐂰 Updates to variable-length columns may result in its movement to a different
page and leave unused space in the table.
DB2 UDB provides commands and functions to gather information and analyze
the physical organization of the tables and indexes, such as the REORGCHK
command, which does the following calculations:
򐂰 It determines the used and free space.
򐂰 It analyzes the physical distribution of tables and indexes.
򐂰 It uses formulas to determine if reorganization (reorg) is necessary.

The details of the REORGCHK command are not described here, but can be found in
the DB2 UDB Administration Guide. The SAP BW system provides functions and
jobs to perform the reorg activities from the SAP SAPGUI, using the transactions
described in 7.3.3, “The optimizer and runstats” on page 207.
The DB2 UDB REORG function deletes the unused space and reorganizes the data
to be stored in contiguous pages. If the INDEX option is used, it places the index
data rows in the same sequence.
The SAP BW System provides the following jobs for REORGCHK and REORG:
򐂰 RUNSTATS and REORGCHK (DBSTATC)
򐂰 REORGCHK for all tables
򐂰 RUNSTATS and REORGCHK for all tables
򐂰 RUNSTATS and REORGCHK for a single table.
򐂰 Automatic REORG
򐂰 REORG and RUNSTATS for a single table
򐂰 REORG and RUNSTATS of flagged tables
򐂰 REORG of tables in tablespace(s)
We recommend that the Automatic REORG job be scheduled periodically. The

Automatic REORG job must always be scheduled after the REORGCHK for all tables
and before a RUNSTATS job.
The Automatic REORG job can be specified as shown in Figure 7-17 on page 213,
using the Action Pad. The job can then either be added to the Planning
Calendar, or manually started immediately.
7.4 Backup and recovery

In this section we discuss some of the features of DB2 UDB, relative to backup
and recovery. In particular, we describe the feature to suspend I/O write for split
mirror image created by ESS Copy Services, and explain how to use mirror
images.
Here are some examples of the topics to be discussed:

򐂰 Logging
򐂰 Backup feature
򐂰 Recovery feature
򐂰 Incremental backup and recovery
216 SAP BW and DB2

7.4.1 Defining a backup/recovery strategy and policy
You may use any number of backup features. However, you should decide on a
backup strategy considering how to recover the database. The appropriate
backup strategy will be designed to protect the company from losing data assets.
We recommend that you define, document, and test a policy for backup and
recovery based on the available hardware and the required service level.
You should first categorize your data according to the business dependencies.
The following is a list of example categories:
򐂰 Enterprise critical data, such as the BW database
򐂰 Infrastructure data, such as:
– SAP Kernel
– DB2 UDB code
– Operating system files
򐂰 Bootable backup to recreate the basic operating system if necessary.
In addition, we recommend that you consider how the runtime of backup and
recovery can be influenced. From the policy point of view, the focus must be on
the maximum available time for recovery. The following considerations apply for
both backup and restore operations:
򐂰 Use multiple I/O buffers and devices.
򐂰 Allocate at least twice as many buffers as devices being used.
򐂰 Do not overload the I/O device controller bandwidth.
򐂰 Use many buffers of smaller size, rather than a few large buffers.
򐂰 Tune the number and size of the buffers according to the system resources.
򐂰 Use the PARALLELISM option.
7.4.2 Managing the DB2 UDB logfiles

The database records every change to the rows in tables, and to each database
object. These logs, or log files, are used to recover from applications or system
errors.
The data will be manipulated in the DB2 buffer pool. The db2agent process
writes information about the updates, inserts, and deletes, in the bufferpools as
log records in the log buffer. The db2loggr process writes the contents of the log
buffer to the active (online) log file. This will be performed:
򐂰 After a commit or rollback.
򐂰 Every second.
򐂰 If the log buffer is full.
򐂰 If the page cleaner moves updated pages.

Figure 7-20 shows the steps in the process for logging database changes.
1 Log Buffer
Log Records
DB2 UDB 2
4K
DBMS Log files into log directory
Log_dir
16 K 3
Log files into archive

Log_archive
Buffer Pool
All Changes recorded Log Records are written Log Files are written to
1 Into Log buffer by the 2 to Log files by the 3 to Log archive.
db2agent process. db2loggr process.
Figure 7-20 The DB2 UDB logging process
When an active log file is filled with records, the DB2 logging user exit db2uext2
copies the log file into log_archive directory. The copied log file is called the
offline log. When all referenced pages have been written to disk, the online active
log file is deleted in the log_dir directory, but a copy of it remains as the offline
log in the log_archive directory. The archive-log consists only of committed
records and can be written to a secondary storage as well.
Important: Please ensure the safekeeping of the Archive Log files. In case of
recovery, the database manager may require the backed-up and archived
datafile. If the archive file is not available, recovery is not possible.
218 SAP BW and DB2

DB2 UDB provides several different logging functions, which are described here:
򐂰 Circular logging: By default, the log files are used in a circular fashion.
When the last log file is full and the first log has no active transaction, the first
log file is reused. With circular logging, you can only do offline database
backup. The database cannot be used while an offline backup is taking place.
Tablespace level backup is not supported. This type of backup is only used
for the version recovery. That is, recovering a database to the last backup
time. Log files are not applied for version recovery.
򐂰 Archive logging: The archive mode supports online backup and database
recovery using log files, and is called roll-forward recovery. The logging mode
can be changed from circular to archive by setting logretain or userexit to
on. When roll-forward recovery is enabled, log files are kept, and not reused,
so they can be applied when performing roll-forward recovery. You can
perform online database backup while users remain connected to the
database. You can also perform a tablespace backup either offline or online.
There are two type of log files:
– Active log files, which contain current transaction data needed to do
rollback during online transaction, or to do rollback or commit during crash
recovery.
– Archive log files, which contain committed data.
򐂰 Dual logging: This type of logging is not an alternative to circular or archive
logging, it provides a mirror of the Logfiles. DB2 UDB includes the dual
logging feature to prevent log failures, which could be caused by the
accidental deletion of corrupted active logs or log files at the hardware level.
Dual logging can be enabled as illustrated in Figure 7-21.
You can use transaction ST04 to define the path for the Mirrored Log. Then,
after a DB2 restart, DB2 writes automatically in the Mirrored Log as well. Of
course, you must define a logical volume and/or filesystem as a physical
basis for the Mirrored Log. It is recommended that you specify the Logpath for
the Mirrored Log on a separate disk.

Figure 7-21 DB2 UDB - defining dual logging using the ST04 transaction
7.4.3 Performing DB2 UDB backups

DB2 UDB has database level backup and recovery utilities. They are accessed
via the command line interface (CLI) or a graphical user interface (GUI), and they
record all the information of an executed backup and recovery event on the
recovery history file.
Using the CLI, only one backup command is used to back up the entire
database. The created backup file includes database system files, data files, log
files, and control information, as examples. Database recovery is also performed
by one restore command, or with the rollforward command. These integrated
features make it easy to manage database backup and recovery.
SAP BW provides additional administration functions for backup and recovery. In

this section we focus on the SAP BW provided functions and transactions.
The first backup should be performed after the installation of SAP BW, described
in the SAP NetWeaver Installation Guide. After installation you should implement
your developed and documented backup/recovery policy and strategy.
220 SAP BW and DB2

SAP BW provides the transaction DB13, which can be started with the command
/ndb13. Using the Planning Calendar, you can click the Add button to schedule
the necessary database backup activities. This is depicted in Figure 7-22. You
can select the backup mode to be either an online or offline backup.
Figure 7-22 Scheduling a database backup
In Figure 7-20 on page 218 we showed the following information:

򐂰 Available backup modes, such as online and offline backups
򐂰 Destination of the backup file
򐂰 Buffer related specifications
򐂰 Number of parallel processes
򐂰 Recurrence and periodic definitions for the selected backups.
Offline backup
The offline backup will be performed based on the Database Instance. Therefore
it involves stopping the database applications for the particular Database
Instance. When the backup is complete, the database and/or applications can be
restarted. During an offline backup, no dialog or background activities can run.
Therefore, you should schedule sufficient time to perform the SAP BW offline
backup so that it will not interfere with other required activities.
An offline backup creates a database image that is in a consistent state. No

database logs are required for data recovery.

Attention: Circular logging of a database only can be backed up using an
offline database backup.
The database shutdown can be executed from the CLI by executing the
command db2 deactivate database <SAPSID>. During shutdown, the DB2 I/O
servers write the buffer pools content to disk, and then stop the database
processes.
Restriction: If database activation was performed using the DB2 command

ACTIVATE, it can only be stopped with command DEACTIVATE.
Entering the command db2stop in the UNIX command line will stop the DB2
Instance. If applications are still running, the Database Instance cannot be
stopped. To check the status of the applications, enter the command db2 list
applications (as shown in the Example 7-3).
An emergency shutdown of DB2 can be performed by entering the command

db2stop force. All of the applications are disconnected, and running
transactions are stopped and rolled back. As a result, the database is in a
consistent state.
An offline backup can be started by entering the db2 backup database command.
This command should be run after all applications previously connected to the
database are disconnected. See Example 7-3.
Example 7-3 Offline backup in CLI
db2bi:bw1adm 2> db2 list applications
Auth Id Application Appl. Application Id DB # of

Name Handle Name Agents
-------- -------------- ---------- ------------------------------ ------------
SAPBW1 disp+work 50 G901265A.O46F.054879015954 BW1 1
SAPBW1 disp+work 49 *LOCAL.db2bw1.020619015908 BW1 1
SAPBW1 disp+work 37 *LOCAL.db2bw1.000CD9015853 BW1 1
SAPBW1 disp+work 36 *LOCAL.db2bw1.000CD9015852 BW1 1
SAPBW1 disp+work 35 *LOCAL.db2bw1.0F0CF9015815 BW1 1
SAPBW1 disp+work 30 *LOCAL.db2bw1.0D0A59015551 BW1 1
SAPBW1 disp+work 27 G901265A.O403.05D779015254 BW1 1
SAPBW1 disp+work 26 G901265A.O402.03D0F9015254 BW1 1
SAPBW1 disp+work 17 *LOCAL.db2bw1.0C02D9015213 BW1 3
SAPBW1 disp+work 16 *LOCAL.db2bw1.0C02D9015212 BW1 1
SAPBW1 disp+work 9 *LOCAL.db2bw1.0F0CF9015157 BW1 3
222 SAP BW and DB2

db2bi:bw1adm 2> db2 force application all
DB20000I The FORCE APPLICATION command completed successfully.
DB21024I This command is asynchronous and may not be effective immediately.
db2bi:bw1adm 2> db2 backup database BW1 to /sapmnt/BW/backup

Backup successful. The timestamp for this backup image is : 20040307092136
In the SAP BW environment, the Planning Calendar provides screens and

routines to start the offline backup. You can add a JOB to the Planning Calendar
by using the Add button, as shown later in Figure 7-25 on page 225.
The screen in Figure 7-23 shows how to define a full database offline backup to
/sapmn/BW1/backup, which is a 100 GB filesystem.
Figure 7-23 Defining an offline backup in DB13
While the offline backup is running, the job log reports the single steps, as
depicted in Figure 7-24. The job log shows that SAP automatically stops the
database to end all applications and transactions. Then the database is
restarted, and the offline backup begins to run. As the log shows, the full offline
backup ran 28 minutes to back up 73 GB using the selected definitions of:
򐂰 Eight parallel processes
򐂰 Eight buffers

Figure 7-24 The offline backup job log
Online backup
The second type of DB2 UDB backup is the online backup. It is performed by the
DB2 backup utility. It can run in parallel with ongoing activities of database
applications, such as R/3 work processes.
Because transactions are executed during the runtime of an online backup, the
created backup image cannot provide a consistent state of the database. In the
case of a restore of an online backup, all changes that occurred during the online
backup must be reapplied or rolled back based on the log files written during the
online backup. This is called a roll-forward operation.
SAP BW continues to operate during online backups, increasing both system

availability and maintaining high application server buffer quality.
DB2 UDB only performs online backups if the database is operating in

LOGRETENTION mode.
An online backup test was executed according the entries in Figure 7-22 on
page 221. We defined six parallel processes and scheduled the Online Backup
with the Planning Calendar, as shown in Figure 7-25. The job ran on Monday the
8th of March, at 17:00.
224 SAP BW and DB2

Figure 7-25 The result in the Planning Calendar
As depicted in Figure 7-25, the backup run was not successful. By clicking the
entry in the Planning Calendar, you can access the corresponding detailed job
log. It shows the ABAP program that was called and the specified parameter. In
addition, it shows the problem. The parameter, LOGRETAIN, was not set. In a
production environment, setting the parameter LOGRETAIN to on is mandatory.
After the Online Backup you should create a backup of the recovery log files as
well. Without the log files that were active during backup, you cannot recover the
database to a consistent state. You cannot take the log files backup right after
the database backup, because these log files are in an active state.
DB2 UDB provides the archive log command to close and archive active logs.
The database administrator can acquire a complete set of log files up to the point
in time when the command is executed. This command can be used only in the
archive logging mode. Example 7-4 demonstrates that you can execute this
command without a database connection.
Example 7-4 Archive active log
C:\PROGRA~1\SQLLIB\BIN>db2 archive log for database sample
DB20000I The ARCHIVE LOG command completed successfully.

After issuing the archive log command, you can back up the archive log files and
keep this backup with the database backup. These files can the be used for
restoring a database to a point in time when you took the online backup, even if
you were to lose all the archive logs in the production server.
Figure 7-26 The job log from an online backup
Tablespace backup
DB2 UDB also provides a tablespace level backup. It is supported when the
database is in archive logging mode. Tablespace backup involves backing up
the history file, system tablespace, and user tablespaces. You can take only one
tablespace, or several tablespaces together, in one backup file. If the size of one
backup file exceeds the operating system limit, the database will create another
backup file that is sequenced automatically.
From the recovery point of view, you should consider backing up all the related
tablespaces together. The relation to other tablespaces is based on primary and
secondary key relations, on referential integrity (RI), or on triggers.
226 SAP BW and DB2

The advantage of the tablespace backup is that it stores the tablespace layout
information automatically during backup. You do not have to change the backup
command when you add tablespace containers, but remember to back up active
log files after backing up tablespaces.
Because of the complexity of the SAP BW database, SAP does not recommend
a tablespace backup.
Important: SAP does not recommend isolated tablespace backup.

From the SAP point of view, the entire SAP Database is a single unit of
recovery. The backup must run on the complete Database Instance.
Checking the DB2 UDB backup files

Backup images are created at the target location that you have the option to
specify when you invoke the backup utility. This location can be a directory, a
device, a Tivoli Storage Manager (TSM) server, or another server.
The success of backups is diplayed in the SAP Planning Calendar and the
assigned job logs. In addition, you can verify the DB2 controlled backup
information using the db2 list history backup all for <SID> command
(BW1 was the SID in our installation).
DB2 UDB provides the db2ckbk command usable at the operating system level.
The db2ckbkp enables you to check whether a backup is recoverable — that is,
whether you can actually restore it. At least once, a typical backup should be
restored to test whether or not the backup and restore process itself is operating
correctly. There is no way to restore an unsuccessful, incomplete backup.
The db2ckbkp checks the integrity of the backup image and determines whether
or not it can be restored. Some, or all, parts of the backup can be checked. The
backup image must reside physically on the disk.
The basic SAP recommendations for backup

The SAP standard recommendation for the database backup cycle is as follows:
򐂰 The complete backup cycle includes 4 weeks.
򐂰 Perform an offline backup of the complete R/3 database <SAPSID> once a
week.
򐂰 Start daily full online backups of the Database Instance <SAPSID> (in our
case, BW1).
For an SAP BW System, you will need a large pool of tapes for the entire backup
cycle. SAP recommends having 30% more tapes than required. You can reuse
the backup tapes at the end of a backup cycle (after 28 days).

Perform additional backups after each database structure modification or a
system upgrade. Place these additional backups in long-term storage.
When an online log file (active log) is filled with log records, the database starts
the DB2 logging user exit. As a result, the log file is written to the log_archive
directory. In addition, the logging tables in the administration database
ADM<SAPSID> will be updated.
Important: Do not delete the offline log files from the log_archive directory
without performing a backup of them. For safety reasons, SAP recommends
that you back up two copies of each offline log file onto separate tapes.
Remember: An online backup is not usable without the log information that
was generated during the database backup.
If, in case of recovery, you need the all of the required offline log files, SAP
provides the BRARCHIVE program for DB2 UDB. You can use it to archive
offline log files to persistent storage media such as tape, or a backup server such
as IBM Tivoli Storage Manager or Legato.
BRARCHIVE retrieves the range of log files which are to be archived from the
administration database ADM<SAPSID>.
Additional backup options

This section discusses some additional backup options to consider.
Suspending the database for volume based backups

DB2 UDB provides the write suspend command to enable you to bring the
database into a consistent state. A database connection is required for issuing
the suspend command. See Figure 7-5.
Example 7-5 Write suspend
db2bi:bw1adm 27> db2 connect to BW1
Database Connection Information
Database server = DB2/AIX64 8.1.3

SQL authorization ID = BW1ADM
Local database alias = BW1
db2bi:bw1adm 24> db2 set write suspend for database

DB20000I The SET WRITE command completed successfully.
db2bi:bw1adm 6>
228 SAP BW and DB2

During the suspended period, tablespaces are in a write suspended state.
Writing to the database is not allowed, but the database remains online and
available for reads. You can see the state with list tablespaces command.
Example 7-6 shows only the last two selected tablespaces.
Example 7-6 Write suspended tablespaces
db2bi:bw1adm 6> db2 list tablespaces
Tablespaces for Current Database
.
.
Tablespace ID = 33
Name = BW1#ODSD
Type = Database managed space
Contents = Any data
State = 0x10000
Detailed explanation:
Write Suspended
Tablespace ID = 34
Name = BW1#ODSI
Contents = Any data
State = 0x10000
Write Suspended
db2bi:bw1adm 6>
You can use this write suspended status to create a Volume Based Backup using
the storage facilities such as:
򐂰 Snapshot or flashcopy with the IBM Enterprise Storage Server® (ESS)
򐂰 Concurrent copy
򐂰 EMC timefinder
Attention: Use the volume based backup and recovery functions only based
on a well developed, documented, and tested policy.
These kinds of volume based copies are established in a short time (minutes).
Updating or deleting transactions are suspended, and will proceed as soon as

the database is enabled again for writing, with the write resume command. Any
changes directed toward the data during the write suspend period are then
applied. See Example 7-7 for an example of the write resume command.

Example 7-7 Write resume
db2bi:bw1adm 25> db2 set write resume for database
DB20000I The SET WRITE command completed successfully.
db2bi:bw1adm 26> db2 connect reset

DB20000I The SQL command completed successfully.
db2bi:bw1adm 27>
This command can be used only for the database in the archive logging mode.
But the snapshot feature of storage vendors can still be used for circular logging
of a database copy with a short shutdown time of the database.
Control Center
The DB2 UDB package includes the Control Center. This GUI facility also
provides support during the DB2 administration activities. It is recommended that
you use the SAP provided DB2 administration facilities.
IBM Tivoli Storage Manager (TSM)

DB2 UDB provides an interface to the IBM Tivoli Storage Manager (TSM) server.
The TSM Server provides policy controlled automatic backup facilities for the
vital and infrastructure data. Some TSM functions are integrated into SAP BW.
For example, the SAP BW Planning Calendar provides the Archive Inactive Log
Files with TSM menu bar.
7.4.4 Database recovery

A database can unexpectedly become unusable due to causes such as
application errors or software and hardware failures. Recovery strategies are
required to eliminate the cause of the problem and return the database to a
usable state.
In this section, we describe methods of database recovery in a DB2 environment.

Restoring a database includes selecting a database image taken from a backup,
and applying all updates from the time the backup image was taken.
There are two primary ways of determining an appropriate image:

򐂰 By using the list history backup command in CLI
򐂰 By using the DB12 transaction (/ndb12)
230 SAP BW and DB2

Recovering the DB2 UDB database
In this section we discuss how to recover from various failure scenarios. We
present the backup history information, and start each recovery scenario from
there.
Recovery to the current state (crash recovery)

When a database crashes because of software failure, hardware failure, or user
mistake, the database is in an inconsistent state. Recovery is further complicated
if the failure happens while transactions are being executed. That means we not
only have to recover the database, but must apply transactions to bring it up to
current status.
After a database failure, the database manager (DBMS) automatically rolls back
any effects from incomplete transactions and any complete committed
transactions that were still in memory when the failure occurred. This will put the
database back to a consistent state.
If the database processes drop uncontrolled, because of environmental causes

such as losing power, hardware failure, or system failure, then after a system
restart, the database manager automatically recognizes the database state and
starts a crash recovery. Example 7-8 shows:
򐂰 The location of the db2diag.log
򐂰 An example of:
– Recognizing that crash recovery is needed
– Starting crash recovery
– Completing crash recovery
Example 7-8 Crash recovery recorded in the db2diag.log

-rw-r----- 1 db2bw1 dbbw1adm 5242684 Mar 11 10:28 db2eventlog.000.crash
-rw-r----- 1 db2bw1 dbbw1adm 5242684 Mar 11 10:34 db2eventlog.003
-rw-r----- 1 db2bw1 dbbw1adm 5242684 Mar 11 10:42 db2eventlog.000
-rw-rw-rw- 1 db2bw1 dbbw1adm 74980 Mar 11 10:42 db2bw1.nfy
-rw-r--r-- 1 db2bw1 dbbw1adm 636543 Mar 11 10:44 db2diag.log
db2bi:/db2/BW1/db2dump >more db2diag.log
ADM7513W Database manager has started.
2004-03-09-17.47.01.151092 Instance:db2bw1 Node:000

PID:1478750(db2agent (BW1) 0) TID:1 Appid:*LOCAL.db2bw1.030750014700
base sys utilities sqledint Probe:30
Crash Recovery is needed.


recovery manager sqlpresr Probe:410 Database:BW1
Crash recovery started. LowtranLSN 0000002206A9B1EC MinbuffLSN 00000022069B000C

Crash recovery completed. Next LSN is 0000002206A9D798
2004-03-09-17.48.21.938037 Instance:db2bwrecovery manager sqlpresr

Probe:3170 Database:BW1
Crash recovery completed. Next LSN is 0000002206A9D798
During recovery, the database manager uses an active log file and a log control
head file (sqlogctl.lfh). Keeping these two files safe is very important for the
database startup after a database failure. If the log control head file becomes
corrupted, there are two ways to recover. You could use the db2dart utility to
export data from containers directly, or you could contact your IBM service
representative for assistance.
If a tablespace is corrupted, but is necessary for crash recovery, the restart

operation succeeds in the archive logging mode. The corrupted tablespaces are
in the offline state. You should fix the damaged containers or restore the
tablespace with the roll-forward operation to enable use of that tablespace again.
If the database is in circular logging mode, the restart operation will fail because
a tablespace is damaged that is needed for recovery. The damaged tablespace
list is recorded in the db2diag.log file. You can restart the database again with
the following command:
db2 restart database database_alias drop pending tablespaces
(tablespace_name)
But you should drop this tablespace after the database is restarted. This
tablespace cannot be used again without a database restore.
Version recovery
Databases that are not enabled for archive logging are said to be
non-recoverable databases. Only version recovery can be performed. Version
recovery restores a previous version of the database using an image created by
an offline backup process. No log files are applied, and any transactions
committed after the backup are lost. All users must disconnect from the database
for version recovery.
If a database is in circular logging mode, you should consider a backup cycle.

More frequent backups will minimize the loss of data. Figure 7-27 shows that the
units of work already performed after the last backup will be lost.
232 SAP BW and DB2

Create BACKUP Units of Work Restore
Database Database Database
Create
BACKUP
Database
Image
Time
Figure 7-27 Recovery to the last backup time
When a database is corrupted, you can check the latest backup information
using the list history backup command and restore the database backup
using restore command.
Database roll-forward recovery

Recoverable databases are databases that are enabled for roll-forward recovery.
With recoverable databases, you can restore the database and apply the logs to
the point of failure. No transactions are lost.
Figure 7-28 shows the units of work performed after a last backup is reapplied.
The restored database is using n archived log files and 1 active log file. A
successful database restore puts the database in roll-forward pending state
when this backup was taken online. The rollforward command is used to
release the pending state.

ROLLFORWARD
Changes
in Logs
Units of Work Units of Work
BACKUP
Create BACKUP BACKUP
Database
Database Database Database
Update Update
n archived n archived
logs logs
1 active log 1 active log
Time
Figure 7-28 Recovering database to the point of failure
Tablespace roll-forward recovery

With recoverable databases, you have the option of recovering either the entire
database or only the tablespaces that need recovery. Tablespaces can be
recovered either offline or online. An image that was taken from either a previous
tablespace backup or a database backup can be used.
Figure 7-29 shows that a corrupted tablespace has been recovered from a
tablespace backup. After a tablespace roll-forward recovery, the recovered
tablespace is in backup pending state unless the restored tablespaces was rolled
forward to the end of logs. The tablespace is usable when you take a tablespace
backup.
The corrupted tablespaces are rolled forward to the point of failure. This puts the
tablespace backup in a not-pending state.
234 SAP BW and DB2

ROLLFORWARD
Changes in Logs
BACKUP Units of Work BACKUP Units of Work
Table Table
space(s) space(s)
Update Update
Media
Error
n archived n archived
logs logs
1 active log 1 active log
Figure 7-29 Recovering tablespace to the point of failure
Recovering the history file

The information for restoring or recovering a database is automatically recorded
in the history file. The history file is always backed up during a database backup
or a tablespace backup. You must recover the history file to know backup,
recovery, or load, information when the history file is corrupted or when entries
are accidentally deleted using the prune history command.
You can recover the history file from a database or a tablespace backup file, for
example, by using the following command:
db2 restore database sample history file from /sapmnt/BW1/backup
Incremental backup and recovery

DB2 UDB supports incremental backups at the database and tablespace level.
This is helpful to recover a database without performing frequent full database
backups or long log processing. Full database backups of especially large
databases, such as SAP BW, are not necessary when a small percentage of data
in the data warehouse changes. This will save tape or disk space.

An incremental backup contains only pages that have been updated since the
previous backup was taken. DB2 UDB provides two types of incremental backup:
򐂰 Incremental backup: This is a cumulative backup, with all the changes since
the last full database backup.
򐂰 Delta backup: This is a non-cumulative backup, with all the changes since
the most recent backup - which includes full, incremental, or delta backups.
The database configuration parameter, TRACKMOD, should be set to YES to

use the incremental backup feature.
DB2 UDB incremental recovery

To perform an incremental recovery, the following items are required:
򐂰 A full database backup
򐂰 The last incremental backup
򐂰 All delta backups after last incremental backup
򐂰 The log files.
The restore is done in the following order:

1. Delta backup restore
2. Full database restore
3. Cumulative backup restore
4. Delta backup restore again
5. Apply logs
In this situation, the restore command is used with the incremental option. The
last delta backup is restored two times during the incremental restore operation.
During the first restore, only the initial data is read from the images and the
complete image is read and processed only during the second restore.
You can also work using the automatic recovery function. The last image that
you want to restore should be specified in the automatic recovery command.
Each of the steps described above is performed automatically using database
history file. So keeping the history file is very important for the automatic
incremental recovery. If the history file is not able to be used, you should use a
manual incremental recovery.
For example, the command: db2 restore database BW1 incremental automatic
from /sapmnt/BW1/backup taken at 20040308154417 performs an automatic
incremental recovery.
Attention: You should use the incremental backup and recovery only if based
on a well developed, documented, and tested policy.
236 SAP BW and DB2

7.5 Authorization to administer SAP BW
To administer the BW environment, you need access to the BW monitor and
administration functions.
Statistics, in addition to the standard database and operating system objects, are
available for other BW objects such as:
򐂰 FACT tables
򐂰 InfoCubes
򐂰 Aggregates
For simplified access to the BW administration and monitoring transactions, it is

recommend that you assign roles in the transaction SU01. Figure 7-30 shows
selected roles, such as:
򐂰 BW administrator
򐂰 Source system administrator
򐂰 SAP IDoc (intermediate document) administrator to monitor the data coming
from other systems or flat files, and using IDocs.
Figure 7-30 SAP BW roles (selected)

Next we want to make sure that the technical names of transactions shown on
subsequent menus will be visible, by selecting that option on the technical
settings pull-down menu, as depicted here in Figure 7-31.
Figure 7-31 The SAP GUI technical settings
Because of the selected roles, after log-on, the SAP GUI provides the
transactions and lauchpad depicted in Figure 7-32.
The launchpad also shows the available options, such as:

򐂰 The business explorer related transactions
򐂰 InfoSet Query functions
򐂰 The BW administration environment,including the Administrator Workbench
򐂰 The IDoc monitoring facilities
238 SAP BW and DB2

Figure 7-32 The GUI Launchpad based on the defined roles
After selecting the BW Administrator Workbench, for example, you have

access to the modelling and monitoring functions as illustrated in Figure 7-33.
Selecting the Tools pull-down menu and the BW statistics submenu, you can
select the statistics for metadata, aggregates, and other additional BW objects.

Figure 7-33 The BW Administrator Workbench
SAP BW provides administration functions for loading data into the BW

database. A scheduler to maintain Infopackages supports you for data loading
activities. Figure 7-34 shows an example that selects data provided by a flat file.
There are other options as well, such as loading from client systems or other
SAP systems.
240 SAP BW and DB2

Figure 7-34 Define Data Source as a flat file
Of course you should go through all processing, data target, update, and
schedule specifications thoroughly. To specify the data targets, the SAP BW
system provides visualized graphics to guide you to the correct target.
The graphic shown in Figure 7-35 helps to define which objects are loadable
from flat file. In addition, you can select a sequential or parallel load.

Figure 7-35 Define the data target
Transactions that help in the administration

There are numerous helpful transactions available for BW administrators, as
shown in Table 7-1.
Table 7-1 Some BW administration transactions

Transaction Description
RSA1 Administrator Workbench
RSMO Monitor - Administrator Workbench
RSADMIN RSADMINA table maintenance
RSCUSTA Maintain BW Settings
RSCUSTA2 ODS Settings
RSPC Process Chain Maintenance
RSRT Query Monitor
RSRTRACE Configure trace tool
RSRV Analysis and Repair of BW objects
RSSM BW Authorizations
242 SAP BW and DB2

7.6 Archiving SAP BW data
Typically the volume of data in an SAP BW system grows very fast. To simplify
the administration of the InfoCubes and the ODS Objects, and to improve the
performance of the BW System, data archiving functions are provided.
Data archiving moves mass data from the database to an archive file or an
external archiving system. SAP BW provides archiving transactions and facilities
such as:
򐂰 Transactions
򐂰 Programs
򐂰 Prepared archiving objects
򐂰 Interfaces
These facilities are used to house BW data which is no longer required online,
but must be accessible later for legal or internal auditing.
Archiving objects describe the data structure, context, and dependencies of

business objects. Only prepared and specified archiving objects can be archived.
The Archive Development Kit (ADK) is used to prepare a runtime environment for
archiving, including converter and compress functions. The archived data must
be release and platform independent, which is guaranteed by the ADK.
In an BW environment, archiving enables you to archive InfoCubes and ODS

objects. You can access the BW archiving function in the object maintenance
menu. As can be seen in Figure 7-36, using the pull-down menu, Extras,
enables you to start the data archiving function.

Figure 7-36 Archive InfoCube
If no Archiving Object exists, the BW System creates an Archiving Object.

The following sequence of administration screens shows the required
information.
244 SAP BW and DB2

First the data must be selected as shown in Figure 7-37.
Figure 7-37 Define the Archiving Object: Select Data

Then the file structure must be defined, as in Figure 7-38. Here you can specify
the file size and the maximum number of data objects. The number of created
files depends on these definitions. For example, if you define a maximum
number of data objects of 5, and you are archiving 30 objects, then 6 files will be
created from the ADK.
Figure 7-38 Define the Archiving Object: Define the File Structure
246 SAP BW and DB2

Then you must specify the file name and the delete definitions, as shown in
Figure 7-39.
Figure 7-39 Define the Archiving Object: Specify the File Name
After the archiving object is defined, or selected if it exists, the archiving process
can be started. Archiving runs as a job in the background, therefore you need at
least two background workprocesses and the standard definitions for a job, such
as:
򐂰 The start time, immediately or at a specified time
򐂰 The start conditions
򐂰 The associated printer
Depending on the definitions, the archiving job creates one or more archiving
files, writes the archive objects into the created flat files, and deletes the archived
objects in the database.
Important: Start an archiving project to define, document, and test all the
single steps, as well as the complete environment.
Using the Archive Link Interface, you can archive the files directly in an archiving
system such as IBM Common Store.

248 SAP BW and DB2
8
Chapter 8. SAP BW performance

This chapter contains information on the subjects of performance tuning and
performance monitoring in a DB2 and SAP BW environment. We include an
approach to managing performance tuning and provide guidelines gathered from
our project as well as other performance related activities performed by
organizations within IBM. These guidelines are intended to help ensure that the
required performance can be achieved and maintained.

8.1 The approach
The approach to performance tuning used in this redbook project has two basic
parts:
򐂰 Health check: To check for and apply the IBM and SAP performance
recommendations, in an effort to optimize the platform configuration from the
beginning.
򐂰 Performance analysis and tuning: To monitor and analyze the system, and
optionally reconfigure the system, as required, to achieve the best possible
performance.
8.2 Health check

Before you begin to tune your SAP BW and IBM DB2 system, you should make
sure that you have set it up according to the IBM and SAP recommendations.
There are a number of SAP Notes that describe how to optimally configure your
system at the operating system, the database system, and the SAP BW level.
This chapter presents an overview to these notes and provides additional
performance related recommendations.
8.2.1 SAP Notes related to performance and system configuration

Table 8-1, Table 8-2, and Table 8-3 list the important SAP Notes related to
performance and systems configuration. The following areas are covered:
򐂰 Operating system and SAP kernel settings
򐂰 DB2 UDB ESE issues relevant in an SAP BW environment
򐂰 Notes related to SAP BW
Table 8-1 Notes related to OS and SAP kernel

Note Number Title Description
668602 SAP software on UNIX: SAP Software on UNIX: OS Dependencies. SAP Web AS
OS dependencies 6.40 6.40.
146528 Configuration of R/3 on Describes how to configure an R/3 System on a computer

hosts with a large with more than 2 GByte RAM. The 32-bit architecture used
amount of RAM involves several restrictions so that the existing main
memory often cannot be managed efficiently.
146289 Parameter The 64-Bit-Kernel for your SAP system has been
recommendations for implemented, and the SAP profile parameters must be
64-Bit SAP Kernel adjusted.
250 SAP BW and DB2

497427 32-bit-compatible UNIX The shared memory-based communication between 64-bit

shared memory and 32-bit software components does not work.
parameter
425207 SAP memory It is not clear which maximum values can be assigned in
management, current which kernel release to specific parameters for the SAP
parameter ranges memory management.
27617 Syslog Q0G, scratch Syslog message Q0G / request (type NOWP) cannot be
area too small. processed.
Table 8-2 Notes related to configuration of DB2 UDB ESE with SAP BW
374502 DB6: DB2 UDB ESE - Summarizes all notes about current performance problems
BW performance - related to DB2 UDB ESE on BW and APO.
overview of notes
370026 DB2 V7.2 parameter Describes best settings forDB2 V7 database and database
settings for R/3 4.x/ manager parameters.
6.10/ 6.20
584952 DB2 UDB ESE V8.1 Describes best settings for DB2 V8 database and database
standard parameter manager parameters.
settings
302429 DB6: Performance on Describes how to tune the DB2 database for BW2.0B,2.1C,
BW 2.0B, 2.1C, 3.0A and 3.0A.
546262 DB6: Administration & Describes how to administer and do performance tuning for
performance on SAP SAP BW, SAP SCM, and SQP SEM (release independent).
BW, SAP SCM, SAP
SEM
583604 DB6: Regular updates Describes how to update database statistics via the DBA
of database statistics of Planning Calender (DB13).
BW tables
101809 DB6: Supported Describes the supported combinations of database version

FixPaks for DB2 UDB and SAP Kernel Release.
for UNIX and Windows
603972 DB6: Installation V8.1 Describes how to install V8.1 Fixpaks.

FixPaks on UNIX
Chapter 8. SAP BW performance 251

147634 DB6: Hints and tricks for Describes how to create new DB2 tablespace with special
creating DB2 focus on performance aspects.
tablespaces
362325 DB6: Table conversion Describes how to use Report DB6CONV to move tables
with DB6CONV from one tablespace to another. DB6CONV also allows to
repartition tables as described in note 648432.
648432 DB6: New function Describes how to check and, if necessary, correct the
modules for hash partitioning keys for fact, ODS and PSA tables. This is
partitioning important if you want to add additional database partitions to
your system and redistribute your data. These checks are
also important after a heterogeneous system migration from
another database platform to DB2 UDB.
544274 FAQs: DB2/UDB 64-bit Information about usage of / migration to DB2/UDB 64-bit.
support
422467 DB6: Installation of a Explains prerequisites and installation of a 64-bit SAP

64-bit SAP System System on DB2 UDB ESE.
356828 DB6: Migrating to 64 bit Explains how to migrate a 32-bit SAP/DB2 UDB ESE system
for AIX and Solaris to 64 bit
156829 DB2-Explain with SQL statements should be examined for cost and efficiency.
db2exfmt
409127 DB6: DB2 UDB Dual DB2 UDB Dual Logging is supported with DB2 V7.1 FP3b
Logging and later.
454173 DB6: R3load migration How to accelerate a system copy or system migration of a
accelerated through CLI large database using R3load. The target database platform
LOAD is DB2 UDB for UNIX and Windows (here DB6).
486951 DB6: DB2 CLI trace For database problems, which were or are going to be
forwarded by SAP to the IBM support, it may be useful to
create a CLI trace of the problem situation.
541511 DB6: Performance An ABAP-OPEN SQL statement has a long runtime.

optimization for SQL st. Analysis of an SQL trace shows that the SQL statement
with IN lists executed on the database has an IN list. The OPEN SQL
statement that results in the SQL statement with an IN list
usually contains a 'FOR ALL ENTRIES' (FAE) construct or a
ranges table. This note describes options that you can use
to reduce the runtime of these statements.
72557 Logging in DB2 UDB Presentation of the logging behavior of the database.
systems
252 SAP BW and DB2

92495 Examination of lock The SQL error message SQL0911 occurs in the database.
situations (SQL0911) Another information deadlock (reason code 2) or lock
time-out (reason code 68). Explains how the cause of these
lock situations can be examined.
522550 DB6: Moving small Describes how to move small tables to another tablespace.
tables to other This may be necessary, for example, to eliminate LONG
tablespaces VARCHAR fields in database tables by moving them to
tablespaces with larger page sizes.
Table 8-3 Notes related to configuration of SAP BW

567745 Composite note BW 3.x Describes how to improve the performance of your BW 3.x
performance: System with regard to database-specific features and
DB-specific setting settings.
567746 Composite note BW 3.x This composite note deals with performance relevant topics
performance: Query & in the area of queries and Web Applications.
Web Applications
567747 Composite note BW 3.x This is a composite note deals with performance relevant
performance: Extraction topics in the area of extraction and loading.
& loading
192658 Setting basis Provides recommendations for setting basis parameters for
parameters for BW SAP BW. Only an optimal setting of these BW basis
Systems parameters guarantees an error-free running SAP BW
System and good overall system performance. The
recommendations for BW Systems deviate in certain
respects from the recommendations for R/3 Systems.
130691 Collective note for BW: This notes provides tips and tricks for all functional areas of
tips & tricks SAP BW.
130253 Notes on upload of Describes steps to make mass data upload into the BW
transaction data into the System as efficient as possible. By increasing number range
BW buffers, for example.
417307 Extractor package size: Provides recommendations on how to improve performance

Collective note for when extracting data from source systems.
applications
534630 Parallel processing of Provides information about parallel processing of the

Change Run change run. The paralleled version of the change run only
has performance benefits if aggregates from several
InfoCubes have to be adjusted in a change run.

8.2.2 How to keep DB2 database statistics current with SAP BW
Outdated database statistics are one of the main reasons for bad performance.
Transaction ST04 allows you to schedule jobs to update database statistics
regularly. We recommend the following setup:
򐂰 Job Runstat_all should be scheduled once a week, for example, on the
weekend. This will update statistics for all tables and might therefore take a
considerable amount of time to execute.
򐂰 Jobs Stats_Check and Run_DBSTATC should be scheduled every weekday,
especially if you load data on a daily basis. Job Stats_Check checks all
tables. If more than a certain percentage of a table has changed, the table is
flagged. Job Run_DBSTATC then updates statistics for all tables that are
flagged.
SAP BW on DB2 UDB ESE updates database statistics automatically during

certain operations, such as dataload and InfoPackage compression. There are a
number of configurable parameters that can be defined in table RSADMIN (see
Table 8-5 on page 256) to control the automatic update of statistics.
8.2.3 How to control DB2 log space consumption with SAP BW

Table 8-4 shows different SAP BW parameters that allow you to control the size
of a unit of work (UOW) for certain SAP BW operations. We recommend that you
keep units of work reasonably small to reduce the required amount of logspace.
However, units of work should not be too small either, because this can have a
negative impact on performance.
Table 8-4 SAP BW parameters that influence log space consumption of BW operations
SAP BW operation Parameter Description
Aggregate Build BLOCKSIZE Determines the number of records that are inserted in one
UOW. It is defined in table RSADMINC. Use transaction
SPRO to configure this parameter. If no value is defined, it
defaults to 100.000.000! We suggest a value between
1million and 10 million.
Changerun BLOCKSIZE Parameter BLOCKSIZE also determines the UOW size for
changerun. See details above.
Changerun DELTALIMIT Defines a threshold limit that determines how the changerun
is carried out. If the percentage of records that have to be
changed during the changerun is larger than DELTALIMT,
the aggregate will be completely rebuild. Otherwise the
records to be changed will be updated.
254 SAP BW and DB2

SAP BW operation Parameter Description
InfoPackage n. a. There is no parameter in SAP BW that allows you to

compression configure the UOW size for the InfoPackage compression.
The only way to reduce the required log space is to reduce
the size of the InfoPackages.
Dataload from file into IDOCPACKSIZE Determines the number of records that are inserted in one
PSA or InfoCube UOW. It is defined in table RSADMINC. Use transaction
SPRO to configure this parameter.
Dataload from SAP MAXSIZE Determines the amount of data (kilobytes) that is loaded into
R/3 Source System each data target in one UOW. The required log space for
into PSA and/or loading an InfoPackage is <MAXSIZE * MAXPROCS *
InfoCubes number of data targets>. Data targets can be PSA only, or
PSA and InfoCubes concurrently. MAXSIZE and
MAXPROCS are defined in table ROIDOCPRMS in the
source system.
Deletion of DB6_DELETE_ See Table 8-5 on page 256.
InfoPackages PIECEWISE
The following examples show a number of SAP BW requirements.
Example 8-1 lists the parameters used to calculate the logspace consumption
during the build of an aggregate table.
Example 8-1 Logspace consumption during aggregate build
We assume the following setup:

BLOCKSIZE:10.000.000
5 Aggregates concurrently
Record length of aggregate fact table: 200 Bytes
10.000.000 * 5 * 200 => 10 GB maximum log space required
Example 8-2 lists the parameters used to calculate the logspace consumption
during an SAP R/3 data load.
Example 8-2 Logspace consumption during dataload from R/3

We assume the following setup:
50 InfoPackages concurrently
MAXSIZE=1000
5 data packets concurrently per InfoPackage
PSA and data targets in parallel
1 PSA, 3 Data Targets
50 * 1000 KB * 5 * (1+3) => 1 GB maximum log space required

In the next section we describe a number of parameters recommended for use in
an SAP BW on DB2 UDB ESE implementation.
8.2.4 Recommended configuration parameters

This section presents the recommended configuration parameters when building
SAP BW on DB2 UDB ESE. Figure 8-5 describes parameters in RSADMIN that
are related to DB2 UDB ESE, and that have an impact on system performance.
The default values are shown and are the recommended values.
Table 8-5 RSADMIN parameters specific to DB2 UDB ESE
Parameter Name Description Possible Values Default
DB6_STATS_ON_EFACT Controls runstats on E fact ’YES’ ’30%’

table during InfoPackage ’NO’
compression. See Note ’x’ (positive integer)
593118. ’x%’ (positive integer)
DB6_STATS_ON_TMP_TABLES Controls runstats on ’YES’ ’YES’

temporary BW tables ’NO’
during query processing.
See Notes 622492 and
651691.
DB6_STATS_ON_IOBJ_TABLES Controls whether statistics ’YES’ ’NO’

are collected during ’NO’
InfoObject activation before
filling the X- or Y-table.
See Note 622138.
DB6_KEYCOLONLY_STATS Controls collection of ’YES’ ’YES’

statistics on key columns of ’NO’
InfoCube fact tables only
(BW 3.5, new DB2 UDB
V8.1 features)
DB6_SAMPLED_STATS Controls collection of ’0’ - ’100’ 100

sampled instead of
complete index statistics
(BW 3.5, new DB2 UDB
V8.1 features)
DB6_STATS_ON_DELETE If set to ’YES’ statistics are ’YES’ ’YES’

collected on F fact table ’NO’
during InfoPackage
deletion. See Note 621361.
256 SAP BW and DB2

Parameter Name Description Possible Values Default
DB6_DELETE_PIECEWISE Controls unit of work during ’YES’ ’YES’

InfoPackage deletion. If set ’NO’
to ’YES’ InfoPackages are
deleted in chunks of
100.000 records. See Note
597053.
SQL_VARIABLE Controls usage of literals 'LITERAL' 'LITERAL'

versus parameter markers 'HOST_VARIABLE'
in BW query processing.
See Note 542346.
In the next section we begin to address the topics of performance analysis and
tuning.
8.3 Performance tuning

There are a number of components that need to be tuned to get the optimal
performance in SAP BW. Examples are hardware, networks, SAP BW work
processes, SAP BW memory management, and database. The purpose of
tuning is to enable these components to interact smoothly so that none of them
becomes a bottleneck, with the result being achievement of optimal performance.
We mainly focus on basic SAP BW and database tuning concepts. For example,
what should be considered when setting up the system and how to monitor the
system and analyze performance problems.
8.3.1 General SAP BW tuning

Many of the recommendations in this section were taken from the following
referenced IBM materials:
򐂰 Getting Started With SAP R/3® and IBM® DB2® Universal Database, on
HP® Servers. This paper gives detailed guidelines on planning and reviewing
system memory configuration. It also references a few SAP OSS Notes that
also provide recommendations regarding R/3 memory management. The
paper describes a sample centralized configuration of the SAP R/3 Sales and
Distribution (SD) application, using IBM DB2 Universal Database V8.1 (DB2)
running on a Hewlett-Packard RP7400 server.

򐂰 SAP Business Warehouse implementation on DB2 UDB Sun Cluster. The
purpose of this paper is three-fold. First, it shows how scalable and easy BW
is to implement in a clustered environment with DB2 Universal Database
(DB2 UDB). Second, it gives best practices for running and optimizing SAP
BW using DB2 on a Sun cluster. Third, it shows what physical resources are
needed and help set expectations for system performance and diagnosis.
For more information on these materials, refer to “Other publications” on

page 371.
SAP memory
There are six memory areas which can be configured for an SAP R/3 Instance.
The following list is a brief explanation of each of them:
򐂰 R/3 buffer: This stores global data that can be accessed by all users, for
example, program code, tables, and field definitions.
򐂰 R/3 roll memory: This consists of two parts, local roll area and roll buffer.
Local roll area is the local memory of a work process which stores the initial
part of user context at the beginning of a transaction step. R/3 parameter
ztta/roll_first specifies the amount of context loaded to local roll area. When
the transaction step is complete, the context is moved to roll file which stores
the roll area on the hard disk. To reduce the access time, a buffer is provided
to buffer the data written into the roll file. This is roll buffer. It is the instance
level shared memory which saves user context during roll out.
򐂰 R/3 extended memory: This is the shared memory which stores the main
part of user context. It is the core of R/3 memory management system.
򐂰 R/3 heap memory: This provides an area for user context if it becomes too
large for the local roll area. It is dynamically allocated as needed and is
released as soon as a transaction is completed.
򐂰 R/3 paging memory: This stores temporary data exchanged between user
contexts.
򐂰 Local memory of R/3 work processes: This stores executable programs,
local data, R/3 cursor cache and so on.
When configuring R/3 memory, the goal is to ensure system stability as well as
performance. There are a few aspects that need to be considered when
optimizing R/3 memory, for example, available physical memory, swap space
and operating system limits. To be able to achieve optimal performance, physical
memory should be large enough for R/3, database and operating system. Swap
space must be sufficiently large to enable the creation of required memory areas.
A good rule of thumb is to set up swap space that is three times the amount of
physical memory available. A 32-bit architecture limits the address space that
can be used by R/3 work processes, while a 64-bit system is limited only by
installed physical memory.
258 SAP BW and DB2

Here are a few tips to consider when configuring SAP memory:
򐂰 Since the main part of user context data is stored in R/3 extended memory, it
is impossible for R/3 Instances to work efficiently without enough extended
memory. Generally about 70% of R/3 memory can be allocated to extended
memory.
򐂰 From R/3 Memory Configuration Monitor (ST02), the hit ratio of R/3 buffers
generally should be 98% or better.
򐂰 Ideally there should be no swaps (displacements) in the buffers of the R/3
system. Ensure there is at least 10% free space and 20% free directory
entries. Number of swaps, free space and directory entries can be monitored
by ST02.
򐂰 For optimal performance, if possible, instead of using roll file and paging file,
roll buffer and page buffer are preferred.
򐂰 Again for optimal performance, data volume initially using local roll area in a
user context switch should be kept to a minimum. To implement this,
ztta/roll_first should be set to 1. In this case, only the addresses used to
locate user contexts in extended memory are copied to local roll area.
򐂰 From the R/3 Work Process Monitor (SM50), if there is any process in PRIV
mode, it means either some users are consuming too much roll/extended
memory, or the available R/3 memory is not enough.
Number of work processes

In an R/3 system, proper configuration of work processes directly contributes to a
balanced workload distribution, which is critical to good system performance.
The optimal number of work processes depends on the demands of the R/3
system and the available system resources.
If too many work processes are configured for one application server, it is very
likely to cause contention for available system resources, such as CPU, R/3
dispatcher, R/3 program buffer and database. However, if the number of work
processes is too few, user requests will have to wait in the R/3 dispatcher queue.
Thus the purpose of tuning work processes is to ensure all R/3 system
components interact smoothly, neither being overused, nor being under used, so
that an optimal performance is achieved.
The proper configuration of the number of R/3 work processes relies on detailed
analysis of database request time, wait time of the dispatcher, roll time and R/3
buffer contention, etc. Generally the number of R/3 update processes should be
as small as possible while still being able to keep pace with the dialog processes.

The work load monitor (ST03) is very helpful on determining the number of work
processes. For example, the statistics report generated by ST03 shows the
database request time and wait time for both update and dialog processes. If
there is no obvious performance bottleneck on the database itself, but database
request time is still very high, then too many dialog and update processes may
have been configured. This causes many database connections to be
established, which can lead to increased contention and increased response
time. Another useful tool is DPMON which can monitor queue information for
each work process.
Number of instances
The number of R/3 Instances per server depends on hardware configuration as
well. Generally speaking, for more than four processors and 4 GB of main
memory, it is reasonable to install more than one R/3 Instance on the application
server.
If more physical memory is available but can’t be used because of limited

address space, a common solution is to install more instances. Another situation
benefiting from multiple instances is when there is heavy contention on R/3
system resources. The contention can be reduced if multiple R/3 Instances are
configured. However, this does not mean that it is a good idea to install a large
number of R/3 Instances on a single SAP server, since each instance adds
administration and monitoring overhead.
Number range buffering

Number range object buffering optimizes the assignment of new object
identifiers, for example, DIMIDs (dimension identifiers) and SIDs (surrogate
identifiers) during dataload. This increases throughput, provided that number
range buffering is implemented to avoid lock problems. Please check SAP Note
130253 in Table 8-3 on page 253 for details.
8.3.2 Tuning DB2 UDB ESE

Several areas need to be considered to obtain optimal database performance
during initial database setup and further administration. These include memory
management, transaction logging, I/O processes, concurrency control and
optimizer etc. This section describes some useful hints regarding data placement
and a few DB2 database parameters which play important roles in R/3
environment.
Database configuration hints

The following sections contain some hints to consider when configuring DB2 in
an SAP R/3 environment.
260 SAP BW and DB2

Where to put the data?
򐂰 As space permits, keep operating system files, paging space, database
tables, indexes, and especially the database log, separate from one another.
򐂰 The more that these items share disk devices and even controllers, the more
they can impact each other, which can lead to performance degradations.
Separating them also has the benefit of making it easier to localize I/O
problems if they occur.
򐂰 Place DB2 log volumes on the fastest available disks, since logger response
time has a major impact on overall transaction response time.
򐂰 Use RAID stripe sets to improve disk I/O performance. Experience shows that
a very good way to improve I/O performance is to group the disks together
and thereby spread the I/O across them. This applies to data and index
tablespaces, as well as transaction logs. A combination of RAID striping and
multiple tablespace containers helps spread the I/O load evenly across many
spindles, reducing I/O wait.
Default tablespace layout

To improve the performance of the BW system, you can partition the database
and distribute the tablespaces to these partitions. Figure 8-1 shows an example
of the distribution of specific tablespaces.
Partition 0 Partition 1 Partition n Base tablespaces and

Basis Standard BW Tablespaces:
:
Tablespaces - Non - Unicode:
:
4 KB page size,
buffer pool:
PSAPTEMP IBMDEFAULTBP
- Unicode:
<SAPSID>#DIMD, 16 KB page size,
<SAPSID>#DIMI buffer pool:
BP_STD_16K
<SAPSID>#ODSD, <SAPSID>#ODSI
BW tablespaces:
<SAPSID>#FACTD, <SAPSID>#FACTI - 16 KB page size,
- Using BP_BW_16K
PSAPTEMP16 buffer pool
NGRP_ODS_<SAPSID>
NGRP_DIM_<SAPSID>
NGRP_FACT_<SAPSID>
Figure 8-1 BW tablespace layout
For more details, please refer to the SAP Administration Guide: SAP BW 3.5
Administration Tasks in Multi-Partition Installations: IBM DB2 Universal Database
for UNIX and Windows.

How many containers for each tablespace?
These are some considerations:
򐂰 Generally, a few small containers perform better than a single large container.
For containers on large RAID stripe sets (8 drives or larger), a few containers
for a given tablespace on the stripe set is usually a good idea. Note that a
maximum of 255 containers per tablespace can be used.
򐂰 DB2 evenly distributes data and index pages over all containers defined for a
given tablespace. We recommend that all containers for a tablespace be
defined with the same number of pages. A good way to start is by defining
several containers of the same size and keeping them balanced by either
adding additional containers of the same size, or by extending all containers
simultaneously by the same amount.
򐂰 For containers larger than 2GB, the operating system must have large file
support enabled.
Raw versus file-based containers

By default, SAP BW installs with DMS instead of SMS tablespaces for
performance reasons. SMS is recommended for temporary tablespaces. DMS
tablespaces can be based on either raw device containers or file containers.
Typically, raw device containers yield higher I/O throughput than file containers,
since the additional layer of the file system buffer cache is avoided by raw
devices. So from a performance point of view, raw devices should generally be
preferred to files. On the other hand, there are situations where the file system
buffer cache can serve I/O requests that would otherwise have to go to disk. In
particular, tablespaces for long data (LONG VARCHAR or LOB data types)
should use file containers, since long data is not cached in the buffer pool.
An additional point in favor of DMS file tablespaces is that raw devices are
sometimes considered to be harder to handle from administration point of view.
In our test system, all tablespace containers were file-based.
Extend tablespaces as data grows

򐂰 If a DB2 tablespace is full, it either has to be enlarged, or some of its tables
moved to a new tablespace. Typically quite large tables are moved from the
filled tablespace to the newly created tablespace.
򐂰 If the tablespace has not yet reached its size limit and it can be enlarged, then
there are two approaches to adding space to the tablespace: Adding
additional containers of the same size, or extending the existing containers. In
the first case, you can add containers to a DMS tablespace using the begin
stripe set option which is a new feature in DB2 V8. In this way a rebalance
operation can be avoided. Space added is immediately available for use.
262 SAP BW and DB2

򐂰 Other new features regarding DMS operations in V8 include the ability to drop
a container from a tablespace, and reduce the size of existing containers.
Page size considerations

򐂰 The number of pages in a tablespace are limited to about 16 million pages.
Thus for tablespaces with the default page size of 4KB, the page size limit is
64GB. This limit goes up to 128GB, 256GB, or 512GB by increasing the page
size to 8KB, 16KB, or 32KB respectively.
򐂰 The use of larger page sizes is recommended for tablespaces that tend to be
accessed sequentially. For example, fact tablespaces. Smaller-sized pages
are recommended for random I/O workloads such as R/3 tablespaces.
򐂰 Note that the catalog tablespace (SYSCATSPACE) must use 4KB pages.
򐂰 If a tablespace is defined with larger page sizes, a new buffer pool with the
same page size must also be defined.
򐂰 There is a maximum of 255 rows per page, so tables with very small row sizes
should be placed in tablespaces with smaller-size pages, to avoid wasting
space. On the other hand, larger-sized rows require a page size which is at
least as large as one row wide, since rows cannot span pages.
򐂰 If a change in tablespace page size is required, use DB2 migration tools to
move the affected tables and their data to the new tablespace.
Major DB2 parameters

The following sections describe a number of DB2 parameters that play important
roles in SAP BW tuning. A good approach is to set up the initial values according
to the corresponding SAP Notes (see Table 8-2 on page 251, especially Notes
584952 and 546262). You can then use the DB2 and R/3 monitoring tools to
measure resource usage and activity, and retune the parameters accordingly.
Memory management
For details of DB2 structure and memory management, please see references 4
on page 371, and 5 on page 371, under Other Publications.The following list
contains a few DB2 database parameters relevant to memory management:
򐂰 BUFFPAGE / buffer pool size: Each tablespace is assigned to a buffer pool
that stores data pages in memory. The database configuration parameter,
BUFFPAGE, defines the size of the default buffer pool – IBMDEFAULTBP.
The basic rule is that indexes and data should stay in the buffer pool as much
as possible to avoid disk activity. But an excessively large buffer pool is not a
good use of memory since there are generally diminishing benefits once the
buffer pool becomes a significant fraction of the active data volume.

For SAP BW, multiple bufferpools may be considered. For example, you may
want to allocate separate bufferpools for InfoCubes and aggregates.
You can create the initial buffer pools according to the parameters
recommended in Table 8-6.
Table 8-6 Recommended initial buffer pool size

Buffer pool type Name Page size Number of pages
Dimension data IBMDEFAULTBP 4 KB 1.400

(non-unicode)
Aggregate data <user defined> 16 KB 7.500
Fact data BP_BW_16K 16 KB > 25.000
For more details, please check SAP Administration Guide: SAP BW 3.5
Administration Tasks in Multi-Partition Installations: IBM DB2 Universal
Database for UNIX and Windows.
– Creating new buffer pools: You can create buffer pools using DB2
interface or using BW interface (transaction DB6DBM). In our case we
describe how to do this in the DB2 level.
i. Log on into the system as db2<sid>.
ii. Open a DB2 command prompt window and issue the following the
commands:
create bufferpool <buffer_pool_name> database partition group
<partition_group_name> size n pagesize 16K
Example:
create bufferpool BP_AGGR_BW1 database partition group
NGRP_AGGR_BW1_4P size 7500 pagesize 16K
򐂰 SORTHEAP: This defines the quantity of memory pages to be used for sorts.
Each agent has a separate sort heap that is allocated as needed, as sorts are
performed. When sorts spill over from the sort heap to disk (generally an
indicator of a SORTHEAP that is too small), performance can degrade
significantly.
When increasing SORTHEAP size, check to see if the SHEAPTHRES
parameter also needs to be adjusted. This is the threshold for the total
amount of sort memory in the system. The value of SHEAPTHRES should be
larger than SORTHEAP times the average number of concurrent sorts.
Snapshot monitor can be used to monitor total sort heap allocated, total sorts,
active sorts, and number of overflow sorts.
264 SAP BW and DB2

򐂰 PCKCACHESZ: The package cache stores SQL statements and their access
plans, eliminating the need to recompile SQL statements on successive
executions. This can improve performance significantly when the same
statement is used multiple times, which is frequently the case with SAP BW.
Snapshot monitor output can also be used to monitor number of package
cache inserts, lookups, and overflows. If there are cache inserts or overflows
after the system is warmed up, the package cache may be too small for the
workload. Enlarging the package cache may improve performance.
Transaction logging
All transactional changes to data and index pages are written to the log, via the
log buffer. The log buffer contents are written to disk when a transaction commits,
the log buffer is full, or write-ahead logging is triggered.
򐂰 LOGBUFSZ: This specifies the size of the log buffer, and should be
increased if there is considerable read activity on the log disk due to
rollbacks. Ideally, the log pages read counter in the snapshot monitor should
be as close to zero as possible.
I/O parameters
The following list describes a number of I/O parameters.
򐂰 NUM_IOCLEANERS: This specifies the number of asynchronous page
cleaners for a database. These page cleaners write changed pages from the
buffer pool to disk before the space in the buffer pool is required by a
database agent, ensuring an adequate supply of clean pages.
This parameter should typically be set to a value between one and the
number of physical disks used for the database. Environments with high
update transaction rates or very large bufferpools may require more page
cleaners to be configured. However, too many I/O cleaners can impact the
performance negatively.
The value asynchronous pool data/index page writes should be as close as
possible to buffer pool data/index writes. If there are a significant number of
synchronous writes or dirty page steal cleaner triggers, then the value for
NUM_IOCLEANERS should be increased.
򐂰 NUM_IOSERVERS: This specifies the number of I/O servers (or prefetchers)
for a database. These bring database pages into the buffer pool before they
are required, for improved performance, by database agents.
Both page cleaners and prefetchers are taken from a shared pool and are not
exclusive to a particular buffer pool. The considerations for tuning page
cleaners and prefetchers setting are typically the same regardless of whether
or not a system has one buffer pool or multiple bufferpools.

Soft checkpoints
DB2 has the concept of soft checkpoints, where modified buffer pages are written
to disk by page cleaners when the buffer pool reaches a threshold amount of
modified pages. DB2 database parameters SOFTMAX and
CHNGPGS_THRESH have an impact on the frequency of checkpoints.
򐂰 SOFTMAX: This influences the number of logs that need to be recovered
following a failure, by triggering the page cleaners to ensure that modified
pages older than the specified recovery window are written to disk. A low
value of this parameter will encourage fast recovery from a system failure, by
causing more frequent checkpoints. However, this increase in page cleaning
activity can impact performance.
򐂰 CHNGPGS_THRESH: This specifies the percentage of changed pages at
which the asynchronous page cleaners will be triggered. Cleaning continues
until the fraction of modified pages drops below the threshold.
Locking
Maximizing system concurrency is very important. SAP BW uses the lowest
isolation level available with DB2, which is uncommitted read, to maximize
concurrency. The following DB2 parameters can influence system concurrency:
򐂰 LOCKLIST: There is one lock list per active database, containing the locks
held by all connected applications. LOCKLIST specifies the lock list memory
allocated. Once the list is full, performance can degrade due to lock
escalations and decreased concurrency. The database monitor reports lock
escalations, and also the high-water mark of the lock list (to avoid
over-allocating memory). If the high-water mark exceeds fifty percent of the
defined LOCKLIST size, consider increasing it. Note that on a 64-bit
database, each lock is 56 bytes, versus 36 bytes on a 32-bit database.
򐂰 MAXLOCKS: The MAXLOCKS parameter defines a percentage of the lock
list that each application can use before lock escalations occur. When setting
MAXLOCKS, you should consider the size of the lock list and number of
concurrent applications.
Optimizer
DB2 uses a very sophisticated cost-based optimizer. It estimates the execution
cost of each alternative data access plan by using statistics for tables and
indexes, and information regarding tablespace I/O characteristics. It then
chooses the plan with the smallest estimated execution cost. DB2 provides a
range of optimization classes from class 0, which uses a minimal amount of
optimization, to class 9, which uses all optimization techniques.
266 SAP BW and DB2

򐂰 DFT_QUERYOPT: The DFT_QUERYOPT parameter specifies the default
optimization class to be used by the optimizer. Class 5 is generally best for an
SAP BW environment. It has been designed to apply the most valuable query
transformations and other query optimization techniques in an efficient
manner, while keeping SQL compilation time short. Typically it gives the best
performance on a broad range of queries. Note that in addition to
DFT_QUERYOPT, the SAP Instance profile parameter dbs/db6/optlevel has
to be set to match the optimization class used by the SAP BW application.
You can influence the decisions that the optimizer makes by:
– Choosing appropriate optimization class
– Creating the correct indexes
– Keeping system catalog statistics up-to-date (see RUNSTATS below)
– Rebinding applications after updating statistics
– Creating more efficient SQL statements
– Setting optimal values for database configuration parameters
– Letting the system know about your hardware via parameters such as
CPUSPEED and TRANSFERRATE.
You can either use the SAP explain facility (via transaction ST04 or ST05),
visual explain, or db2exfmt to display and analyze the access plan chosen by
the optimizer.
򐂰 RUNSTATS: To ensure that the optimizer has accurate estimated costs of
different query access plans, it is very important to maintain up-to-date
statistics. RUNSTATS analyzes the contents of selected tables and updates
statistics in the system catalogs. Examples of the statistics include number of
pages and rows in the table, number of overflow pages, number of distinct
values for a column, and degree of clustering of an index. With missing or
out-of-date statistics, the optimizer cannot make the best access plan
decision for an SQL statement. Use RUNSTATS to collect statistics in the
following situations:
– When a table has been loaded with data, and the appropriate indexes
have been created.
– When a table has been reorganized with the reorg utility.
– When there have been extensive updates, deletions, and insertions, that
affect a table and its indexes. (Extensive, in this case, may mean that 10 to
20 percent of the table and index data has been affected.)
– Before binding application programs whose performance is critical.
– When comparison with previous statistics is desired. Running statistics on
a periodic basis enables the discovery of performance problems at an
early stage, or better yet, the avoidance of performance problems.

SAP BW allows you to schedule jobs for collection of statistics. For details, see
8.2.2, “How to keep DB2 database statistics current with SAP BW” on page 254.
Other DB2 tuning techniques

The following list describes other tuning techniques to be considered:
򐂰 Eliminating overflow records: If a row increases in size due to an UPDATE,
such that it no longer fits in its allocated space on the data page, it is moved to
another page and a reference to the new location is inserted into the original
page. This new copy of the row is called an overflow record. An extra page
read is required to access the overflow record therefore system performance
may be impacted.
Database snapshot output can be used to determine if there are any table
overflows. The reorg utility can then be used to reorganize the table and
reclaim space. Most databases that are not completely read-only will benefit
from a reorg on a periodic basis. A reorg is especially useful for databases
with frequent updates and deletions. To determine whether or not a reorg is
necessary, run REORGCHK. A REORG should normally be followed by a RUNSTATS.
The SAP DBA planning calendar (open via transaction ST04) allows you to
schedule jobs to do REORGCHK, REORG, and RUNSTATS automatically.
򐂰 Using VARCHAR instead of LONG VARCHAR: If possible, consider using
a larger page size and VARCHAR columns as opposed to LONG VARCHAR,
as the latter are not buffered in the DB2 buffer pool. VARCHARs are buffered,
and can be up to 32KB in length on a 32K page.
How to adjust DB2 UDB ESE parameters

When changing DB2 UDB ESE parameters, change only one parameter at a
time. Use db2_all to modify DB2 database parameters, and db2set to adjust
DB2 registry parameters.
8.4 Performance monitoring of SAP BW on DB2 UDB

First of all, SAP BW includes many transactions, monitors, and graphics, to
provide current statistical data for performance monitoring and analysis. One of
the best available descriptions of the needed activities and the displayed values
is given in the SAP Web Application Server (WAS) and BW Library. Figure 8-2
gives an overview of the available performance related topics, including the
transactions, methods to analyze the values provided, and suggestions.
268 SAP BW and DB2

Figure 8-2 The DB2 UDB Performance Section in the SAP WAS Library
We strongly recommend that you use the documentation to avoid ineffective
activities. If you do not have direct access to the SAP WAS and BW Library, you
will find the newest documentation provided on the SAP Service Marketplace at
http://service.sap.com. After logging on, you can access the information by
selecting HOME > Media Library. For example, you can access all the SAP
Online Documentation for SAP solutions, such as WAS, NetWeaver, and BW.
We recommend that you also report any performance and runtime problems as
soon as possible to your Enterprise SAP Competence Center or to SAP using
the Service Marketplace. SAP and IBM DB2 UDB provide excellent support to
help you resolve any runtime problems.
To perform runtime and performance analysis, and the follow-on SAP BW and
DB2 UDB administration activities, SAP provides a wide range of functions.
Table 8-7 shows selected transactions and the related activities.

Table 8-7 SAP BW transactions for runtime analysis
Task Transaction
DB2 UDB related activities

Performance Monitoring, Space Monitoring and Management, ST04
Backup & Recovery, Configuration, DBA Planning Calendar,
Alerts, Diagnostics
SQL Trace ST05
Alerts DB16, DB17
Configuration DB03
Space Management DB02
Table buffering (SAP Buffers) ST10
Backup&Recovery DB12
DBA Planning Calendar DB13
Diagnostics DB6COCKPIT
DBA Action Log DB24
WAS common activities

Workprocess snapshot analysis SM50, SM66
SAP Buffers, Memory and Storage ST02
Wokload, Response/Runtime analysis ST03
Operating System Monitor ST06, OS07
Statistical Records STAD
BW related common activities

Application monitor ST07
Upload monitor RSMO
Query Monitor RSRT
Query trace tool RSRTRACE

BW object health check RSRV
270 SAP BW and DB2

8.4.1 Performance bottlenecks
In an SAP BW system there is a high level of interdependency between any
system bottlenecks and long-running transactions or programs.
The cause of system bottlenecks could be:

򐂰 Lack of hardware resources, such as:
– CPU
– Real and virtual memory
– Disk- devices, caches, controller, and access paths, resulting in poor
Input/output operations (I/O waits)
򐂰 Poor configuration of:
– Memory
– SAP buffers
– Workprocess distribution
The cause of long running programs could be:

򐂰 Unnecessary functionality
򐂰 Inefficient implementation of technology, such as:
– Database table buffering
– Database indexes
– ABAP coding (inefficient SQL)
򐂰 lack of experience regarding the implementation
– Customizing
– Sub-optimal use of the SAP standard functionality
Figure 8-3 depicts a simplified view of how SAP systems access data. Involving
too many elements in the data access process can result in runtime and
performance problems. As examples:
1. The user or job will be assigned to a dialog or background workprocess.
First the SAP buffers, located in the application server virtual memory, are
checked to see if the needed data is loaded into the buffers. If the requested
data is available in the SAP buffers, this results in faster response times.
2. If the requested data is not residing in the SAP buffers, the workprocesses
access the data using the database interface from the database server. When
the data is prefetched in the DB2 Buffer, no I/O operation is necessary.
3. An I/O access to the disk results in a longer response time.

DB Request
Response Log Buffer
Log Records Log_dir
Buffer Pool
Processes
SAP BW DB2 UDB
4K
SAP 2
Application DBMS DB_Files
3
Work
1 16 K
SAP
Buffer
DB_Files
1 Data in SAP Buffer 2 Data in DB2 Bufferpools 3 Data on disk
Figure 8-3 Accessing data
The SAP BW system provides monitoring and workload statistics functions for all
single steps and areas of the different access types. The results of the monitors
is even kept for trend analysis and time-related comparisons as well.
8.4.2 Proactive monitoring

Figure 7-7 on page 201 depicted the recommended daily activities for SAP BW.
The very first task is CCMS System Monitoring, which starts the RZ20
transaction. Basically the CCMS System Monitor provides two views:
򐂰 Open alert view
򐂰 Current alert view
Also, it shows all of the available elements, such as:

1. SAP Application Server
2. Database DB2 UDB
3. Application modules
4. Communication facilities
5. SAP System Log
6. ABAP dumps
272 SAP BW and DB2

The alerts are presented in color for easy identification. As examples:
򐂰 White indicates that this element is not included in the statistics.
򐂰 Green indicates that this element is OK.
򐂰 Yellow indicates a warning message.
򐂰 Red indicates a failure or performance problem.
Typically the CCMS System Monitor gives very detailed information. As

examples, at the hardware and operating system level it indicates if:
򐂰 CPU is overutilized.
򐂰 Swapping rate is too high.
򐂰 Filesystem threshold is reached (meaning you must resize the filesystem).
Figure 8-4 shows that the CPU utilization related to the threshold, as a 15 minute
average value, is too high. Additionally, the CCMS System Monitor shows paging
and memory problems as well. Selecting the three elements — the CPU
utilization, in particular — the monitor lists seven alerts for further investigation.
Figure 8-4 Hardware and Operating System related alerts

In the database tree elements, shown in Figure 8-5, the monitor reports possible
future performance concerns. It lists the objects that either need their statistics
updated or need to be reorganized.
The tree elements, related to the database, provides an impression about the
provided statistics. In Figure 8-5, some of the higher level elements are
extracted, such as:
򐂰 DB2 UDB
򐂰 Performance
򐂰 the partitions 000 and 001
As the monitor indicates, partition 000 has lock and cleaner problems, and
partition 001 has DB2 buffer pool and cleaner problems. Clicking the associated
nodes, SAP BW starts an assigned method for analysis. This method can be, for
example, an analysis or even an predefined action.
Figure 8-5 The DB2 UDB tree elements
274 SAP BW and DB2

Another example is shown in Figure 8-6. It indicates that the TEMP tablespace
(TS), which is used for sorts, is too small. Because it is a system managed TS,
the filesytem must be increased.
Figure 8-6 SAPTEMP too small
Figure 8-7 shows the selected monitor tree for the BW environment. The BW
Monitor provides all of the information about the gathered alert statistics. For
example, it informs you about the state of:
򐂰 DB2 UDB (green)
򐂰 ALE communication and IDocs (green)
򐂰 the BW Process Chains (red)
The illustration shows that the failures will be propagated to the higher tree levels.
For example, the BW monitor is marked red because some of the PSA loads did
not run successfully.

Figure 8-7 The BW Monitor
By clicking the first entry that is marked red on the lowest level, the monitor
automatically performs the specified analysis method. In this example, it is an
action to display the Process Chain Maintenance Planning View for loading the
PSA. The result is visualized in Figure 8-8.
276 SAP BW and DB2

Figure 8-8 Visualized LOADPSA problem in RZ20
By selecting the red marked object 1990-3 in Figure 8-8, the monitor displays the
log of the PSA Load job for final analysis. Then after the analysis and correction
of the problem, you can resolve the alert.
8.4.3 Problem analysis and resolution

In proactive problem management you can avoid oncoming runtime problems by
initiating preventive activities. If a user or developer of the SAP BW system
reports a runtime problem, the analyze procedure starts on request.
SAP provides roadmaps for workload and performance problems in the

documentation and in training courses. Typically our recommendations are
based on these roadmaps. Additionally, we assume that the hardware sizing has
been checked and the result is acceptable.
First we give an overview of the available monitors, then we focus on the DB2
UDB transactions.

SAP BW common workload monitor activities
After recognizing a workload problem, you can analyze it with a procedure such
as the following example:
1. Are all transactions affected?
If NO, analyze the program and transaction.
If YES, go to 2.
2. Do workload problems exist on all application servers?
If NO, analyze the single server.
If YES, go to 3.
3. Start the analysis with the following transactions:
– Use SM50 for a single instance, or SM66 if more than one instance is
running. These two transactions are snapshots, so you have to refresh the
transaction using the refresh symbol. The transaction lists the
workprocesses, and their status and activities. Additionally, it shows the
accessed database objects that are in a hanging situation. Analyze the
Reason, Error, and Semaphore columns thoroughly. For an explanation of
the columns, place the curser in the column and press the F1 key.
Example 8-3 shows an extract of the semaphore definitions.
Example 8-3 The definition of semaphores (extract only)
Semaphore that the work process is waiting for:
Definition:
SAP number of the semaphore which blocks the work process:
7: PAGING semaphore
8: NO_BUFFER semaphore
9: STAT semaphore
16: DB_TBUFF semaphore
17: DB_SYNC semaphore
18: DB_TTAB semaphore
19: DB_SNTAB semaphore
20: DB_IREC semaphore
21: DB_FTAB semaphore
22: LOGFILE semaphore
23: REQ_QUEUE semaphore
24: DB_TBUFF_P semaphore
30: DB_CUA_BUFFER semaphore
278 SAP BW and DB2

– ST03 analyzes the workload. The system is measuring and collecting the
workload for the complete BW1 environment. All single elements of the
response time are provided as an average and as a percentage, such as:
• DB request time
• CPU time
• Wait time
• Processing time
• GUI time
For the analysis, the absolute values are important, as well as the relation
between the times — for example, the relationship between the DB time
and the full response time. See Figure 8-9. The DB time is too high if it is
greater than 40% of the value (response-time minus wait-time). For more
details, refer to the SAP Library.
Figure 8-9 The system workload
Figure 8-9 shows, in the left pane, Analysis Views that you can analyze, as
examples, for specified time periods, top DB accesses, or even a single
transaction performed using the Transaction Profile.
– ST02 helps to analyze the SAP buffering hit-rate and memory allocation.
In the Detail Analysis Menu you get additional information about the
virtual storage usage and allocation and the SAP Profile parameters.

– ST06 or OS07 informs you about the operating system related resources,
such as CPU utilization, paging, and IO-waits. Going to the Detail Analysis
Menu, you get information about disks, filesystems, top CPU processes,
the hardware configuration, and the OS-log.
After analysis, perform the necessary tuning activities and document the results.
SAP DB2 UDB related monitor activities

If you recognize a performance problem that you think is caused by the
database, further analysis can be started by using the transaction ST04. In SAP
BW 3.5, there is direct access to most of the DB2 UDB related transactions, such
as the DB2COCKPIT and DB2PERF.
Figure 8-10 shows, in the left pane, the available data categorized by database
elements: partitions, database, schemes, tablespaces, tables, applications, SQL
cache, lockwaits, and deadlocks. Additionally, you have access to the collected
history. The right pane lists the four partitions and the performance related
columns. By selecting one of the partitions shown in Figure 8-10, SAP will
provide more detailed data about that particular database partition.
Figure 8-10 Performance overview per partition
Table 8-8 gives a complete list of the performance data provided.
280 SAP BW and DB2

Table 8-8 ST04 performance values categorized by DB partitions
Column Description
Partition Number of the selected partition.
No. Buffer Pools Number of buffer pools used for a partition.
Total Size Buffer Pools In KB of all buffer pools used for a partition.
Data Logical Reads Number of buffer pool read accesses to data.
Index Logical Reads Number of buffer pool read accesses to index.
Data Physical Reads Number of disk read accesses to data.
Index Physical Reads Number of disk read accesses to index. This value
includes the number of synchronously read index
pages.
Avg. Phys. Read Time (ms Average read from disk to BP time in milliseconds.
Avg. Phys. Write Time (ms) Average write time from BP to disk in milliseconds.
Executed SQL Statements Number of executed SQL statements.
Package Cache Size Heap memory size using for static and dynamic SQL
statements.
Package Cache Quality (%) The hit ration for package or catalog cache. Should
be greater than 95%.
Figure 8-11 illustrates that you may select the available DB partition related
performance data since the last reset of the snapshot, or since the start of the
DBMS. As an option, in the right pane you can select the DB partition. This
snapshot gives performance related information such as:
򐂰 Cache usage and hit-rate
򐂰 Lock waits and lock escalations
򐂰 Number of logical and physical reads and writes
򐂰 DB logging values

Figure 8-11 Database partition 0000 snapshot
Figure 8-12 lists a table snapshot. It shows, for example, that some of the tables
have a lot of overflow access. This column provides the number of accesses
(reads and writes) to overflow rows of the table. The overflow rows indicate that
data fragmentation has occurred.
If this number is high, the transaction accessing this table will experience long
response times. This will be especially true if the table is not a read-only object. It
may be possible to improve performance by reorganizing the table. This can be
done by using the reorg utility, which cleans up the fragmentation.
282 SAP BW and DB2

Figure 8-12 Table overflow access
Analyzing the SQL Statements (SQL Cache)

The result of transaction analysis or data from the SQL trace ST05, the involved
SQL, and the used access path (index), provides data for tuning activities. For
example, it may indicate the need to create a new index.
However, we recommend that creation of an index should be performed only

after communication with the SAP Hotline or Support. The newly created index
might help the particular transaction just analyzed, but it could also impact the
response time for other programs and transactions. SAP will check the
dependencies on other objects and offer suggestions.
SAP BW guides the BW administrator through the performance analysis

transaction DB6PERF, which can also be used for analyzing SQL. When
DB6PERF is started, you can select the SQL Cache row in the navigation field
(left pane) by using a mouse-click. The transaction then opens the screen
depicted in Figure 8-13, which shows such things as:
򐂰 Number of executions
򐂰 Total time of executions in ms, and in %

Figure 8-13 The SQL Cache Snapshot screen
By selecting the second statement in the right pane, where the statements are
sorted according to the Total Execution Time, the SQL statement and the used
access plan will be explained as shown in Figure 8-14. The Estimated Costs
value is marked yellow, and the #key column is marked green.
284 SAP BW and DB2

Figure 8-14 The SQL statement and the used access plan
When you click the Collect button shown at the top of Figure 8-14, the BW
system collects all of the necessary data to analyze the SQL.
As depicted in Figure 8-15, you are asked to select the type of information
needed. Included are such things as:
򐂰 DB configuration values and level
򐂰 Tablespace configuration
򐂰 Table structure
򐂰 Statistics
򐂰 Explain
You can also display all values on the screen as well.

Figure 8-15 The selection criteria for downloading the needed information
All the values can also be displayed on the SAP GUI (SAP Graphical User
Interface) by selecting Display Download on Screen — see Figure 8-16.
Figure 8-16 Display the analyses result in SAP GUI
286 SAP BW and DB2

The system downloads all selected information into the specified directory as
shown in Figure 8-17.
Figure 8-17 The collected and downloaded information for the SQL Explain
The files include all of the detailed information including the database
configuration for the partitions. Using the download facility, SAP BW provides a
complete set of information related to a particular performance problem.
Additionally you might use the result to request remote support from SAP or IBM.
Example 8-4 shows an extract of a complete set of downloaded information

related to an SQL Cache Snapshot from our project system. To see the complete
set of information, refer to Appendix A, “SQL analysis with SAP BW” on
page 333.
Example 8-4 The content of the collected files (only an extract)
DB2LEVEL File
Database Server: db2bi

DB21085I Instance "db2bw1" uses "64" bits and DB2 code release "SQL08013"
with
level identifier "02040106".
Informational tokens are "DB2 v8.1.1.24", "s030728", "U488481", and FixPak
"3".
Product is installed at "/usr/opt/db2_08_01".
.
REGVAR File (registry)

[e] DB2CODEPAGE=819
.
.

DBMCFG File (database manager conguration)
Database Manager Configuration
Node type = Enterprise Server Edition with local and remote clients
Database manager configuration release level = 0x0a00
CPU speed (millisec/instruction) (CPUSPEED) = 5.235149e-07

Communications bandwidth (MB/sec) (COMM_BANDWIDTH) = 1.000000e+02
Max number of concurrently active databases (NUMDB) = 8

Data Links support (DATALINKS) = NO
Federated Database System Support (FEDERATED) = NO
.
.
TABLESPACE Configurations File
Tablespace ID = 0
Name = SYSCATSPACE
Contents = Any data
.
.
.
Missing Indexes
Checking the consistency between the ABAP Dictionary and the DB2 UDB
Catalog is provided by the SAP BW diagnostic functions. This is depicted in
Figure 8-18. The left pane shows the open diagnostic tree, and the right pane
lists the results of the consistency check.
This example shows that some rows have a green check mark indicating that
they are OK. But, there are eight secondary indexes listed as missing in the
database. Selecting the Info symbol in Figure 8-18 will produce an explanation of
the problem as provided by the system.
288 SAP BW and DB2

Figure 8-18 Missing Indexes
The system explanation for the missing indexes is shown in Figure 8-19.
Figure 8-19 Missing Indexes explanations

By selecting the Action symbol associated with the listed index, the system
provides the processing option as shown in Figure 8-20.
Figure 8-20 Create the indexes
Running the Utility for Database Indexes, depicted in Figure 8-20, will check the
consistency. The results, shown in Figure 8-21, indicate that there really is not a
missing indexes problem.
Figure 8-21 No missing indexes
290 SAP BW and DB2

BW application monitoring
With the Application Monitor for Database Accesses facility, SAP BW provides
the following options:
򐂰 SAP buffer statistics
򐂰 DB accesses
򐂰 DB memory statistics
򐂰 Response times
򐂰 Quantity structure of the BW application
򐂰 History
The Database Access Monitor is illustrated in Figure 8-22.
Figure 8-22 BW Database Access Monitor

The database accesses monitor lists an overview of the BW application groups,
which includes such examples as:
򐂰 BW archiving
򐂰 BW data import
򐂰 BW data transfer and update
򐂰 BW process chains
By selecting one of the BW application groups, SAP BW will provides information

about the single ABAP programs and the related database activities. As shown in
the illustration in Figure 8-23 on page 292, you can sort each single column
according to your requirements. In the depicted example, we sorted the DB
activity rows in decreasing order.
Figure 8-23 SAP BW Application related Database Accesses
Additionally, you can create 3D or 2D graphics for visualization or presentation

demands from most of the monitors.
For performance analysis activities, you will need to see the response times as
well. Similar to the Database Accesses Monitor, you can select the Application
Monitor Response Times. Then by looking at the details you will find the
programs with higher than expected response times.
Figure 8-24 and Figure 8-25 show the result of the application monitors for
Database Memory and SAP Buffering. Using these monitors, you are able to find
those instances where there is a lack of memory and those where there are
buffering problems related on the single ABAP application modules. Those
instances are listed on the bottom segment of each of the displays.
292 SAP BW and DB2

Figure 8-24 SAP BW database memory consumption
Figure 8-25 SAP BW buffering results

BW overall efficiency of the system
When the goal is to examine the overall efficiency of the BW system or to search
for queries that use excessive resources or those that have long database
request times, you can reach that goal by using SAP statistics in conjunction with
DB2 performance indicators.
Examine InfoCubes and queries using excessive dbms resources

InfoCube and query statistics contain averages for many queries, so there will be
problems that cannot be identified. Queries that need aggregates, and InfoCubes
or queries that would benefit from new indexes, may be found in this way.
Transaction ST03 has been enhanced to provide statistics on BW navigation

steps. You can use ST03 to review the BW performance statistics looking for
InfoCubes and queries with performance problems. In Figure 8-26 we switched
the ST03 to the Expert Mode. In the left pane the BW Workload and the
Aggregates Analysis Views is selected. The right pane shows the InfoCubes,
their share of session executions, and the aggregate detail values.
Figure 8-26 BW InfoCubes and aggregate details
294 SAP BW and DB2

In ST03 you can check for InfoCubes with large total or average DB time. Since
performance problems are generally related to the characteristics a specific
query uses to accesses the InfoCube and its aggregates, the query level
statistics give better hints for finding slow or inefficient queries.
Well-defined aggregates are generally the most effective performance-tuning

tool in a BW system. One of the most important steps in optimizing performance
at a system level is ensuring that the correct aggregates have been defined for the
InfoCubes and queries that are most commonly used.
SAP BW supports the BW consultant in proposing the aggregates. Using the

Administrator Workbench or the transaction RSA1, you can select the required
object as shown in the Figure 8-27. With the Administrator Workbench, we
selected an InfoCube. Then by using the right mouse key, the Maintenance
Function. This function provides a Propose pull-down menu where you can, after
creating the list of the proposed, optimize your aggregates.
Figure 8-27 Aggregate Propose Function

296 SAP BW and DB2
9
Chapter 9. Scaling out the database

This chapter describes how to scale out the database. Earlier, in 3.2.3, “Parallel
processing and partitioning” on page 55, we provided a general introduction
about DB2 scaling options. Scaling the database means to increase the
hardware capacity of the database system by adding processors, storage, or
servers.
Important: To be able to attach additional servers to your database system,

you must partition your database.
Adding servers requires a fast (gigabit) ethernet connection or switch between

the servers.
Next, we briefly explain some scaling steps we performed during this project:
򐂰 Re-partition the database from 1 to 4 partitions: Multiple partitions provide
several advantages when running on an SMP (symmetric multi-processor)
server. Different operations, such as SAP BW queries, table reorganization,
update statistics, and backup/restore, benefit from inter-partition parallelism
and realize improved performance.
򐂰 Attach additional servers to the database system: Then you can move
existing database partitions to those additional servers: The ability to add
servers to a database system, to increase SAP BW performance at the
database level, is a unique feature of DB2. Refer to 4.1.1, “Scalability” on
page 82 for more details.

9.1 Options for installing and scaling the database
In this section we describe some of the options for scaling the database. For
detailed steps that are required to install SAP BW with multiple database
partitions, refer to the SAP BW installation guide.
There are basically two options to partition your DB2 database:

򐂰 Install SAP BW with one database partition on one server and add partitions
(and optionally servers) later as they are required.
򐂰 Install SAP BW with multiple database partitions on one or multiple servers.
Installing the SAP BW system with only one database partition has the following
considerations:
򐂰 You are not taking advantage of inter-partition parallelism. If you are running
on an SMP (symmetric multi-processor) server, some single running
operations may not fully utilize all processors on the server.
򐂰 To attach additional servers later on, you have to add database partitions and
then redistribute PSA, ODS, and Fact tables over all the partitions.
Important: If you install SAP BW with DB2 on a symmetric multi-processor

(SMP) server, we recommend that you initially configure SAP BW with
multiple database partitions. This is also recommended if you plan to attach
additional servers to the database system later on.
Configuring multiple database partitions from the beginning avoids the task of
redistributing the data later on. And you can immediately take advantage of
inter-partition parallelism, which results in improved performance for many
database operations.
To redistribute data, SAP provides the tool db6conv. Instead of using the DB2
redistribute command, this tool uses the following command, insert into
select from not logged initially, to move PSA, ODS, and Fact tables
from non-partitioned to partitioned tablespaces and is therefore much faster.
After using the db6conv tool to redistribute tables, take a backup of the database,
because of the not logged initially option used.
If you initially start with multiple partitions and want to attach additional servers to
your database system, you can move partitions to the additional servers instead
of adding new partitions. This avoids the need of redistributing PSA, ODS, and
Fact data.
298 SAP BW and DB2

9.2 Scaling steps
In this section we discuss steps of scaling an implementation, by adding
database partitions and by adding servers. We describe the following
procedures:
1. How to alter the database from one to four partitions.
2. How to relocate database containers to a separate volume group on an
additional disk subsystem. This step is not required if both servers share the
same storage system, and if the containers of the database partitions to be
relocated to the additional server are on a separate volume group.
3. How to add a second server, and move two of the four partitions to this
server, without copying or redistributing any data.
Figure 9-1 shows the database system after partitioning the database. As you
can see, all data is on the same disk subsystem. ODS, PSA, InfoCube, and
aggregate fact tablespaces are distributed over all four partitions.
P-Series 650 A
VG 1 – RAID 5
<SID>#FACTD/I
<SID>#AGGRD/I
<SID>#ODSD/I
DIM
etc..
0 1 2 3
Database Partitions
Disk Subsystem
Figure 9-1 Four database partitions on one server (logical partitioning)
Chapter 9. Scaling out the database 299

Figure 9-2 shows the final setup. The database containers of the partitions
numbered 2 and 3 have been relocated to the second disk subsystem, and the
second server has been added to the database system.
p-Series 650 A p-Series 650 B
VG 1 – RAID 5 VG 2 – RAID 5
<SID>#FACTD/I <SID>#FACTD/I
<SID>#AGGRD/I <SID>#AGGRD/I
<SID>#ODSD/I <SID>#ODSD/I
DIM
etc..
0 1 2 3
Database Partitions Database Partitions
Disk Subsystems
Figure 9-2 Four database partitions on two servers
9.2.1 Partitioning the database

In this section we explain the steps performed to partition the database, and to
redistribute PSA, ODS, and Fact tablespaces.
For recommendations regarding the tablespace layout of a partitioned SAP BW

DB2 system, see Figure 4-6 on page 91 and the SAP guide SAP BW 3.5
Administration Tasks on IBM DB2 Universal Database for UNIX and Windows.
As a general rule, we recommend configuring one database partition for one to

four processors. See section 6.1, “Sizing SAP BW on DB2” on page 122 for more
details. If you plan to attach additional servers later on, and want to avoid
redistributing data, you should configure enough database partitions to account
for the additional servers you plan to attach.
300 SAP BW and DB2

Modifying the size of distributed buffer pools
Before adding new database partitions, you should reduce the size of those
bufferpools that will be distributed across all database partitions. Buffer pool
BP_STD_16K is assigned to InfoCube fact tablespaces. If these tablespaces are
distributed across multiple partitions, a separate buffer pool will be automatically
created for each of these partitions. For example, if you add three database
partitions to your existing partition (resulting in four partitions total) and your
current buffer pool size is 100,000 pages, then you should reduce the size of the
buffer pool to 25,000 pages. To do that, for example, you could use a command
such as:
alter bufferpool BP_STD_16K size 25000
Creating additional partitions on the same server

To create additional partitions on the same server, the following steps are
required on the database server:
1. Stop the application and database.
2. Check the port range, which is configured for DB2 in the file /etc/services
(entries DB2_db2<sid> and DB2_db2<sid>_END). You need to increase the
value of DB2_db2<sid>_END for each new partition that you want to create.
3. As user db2<sid> enter the following command :
db2start dbpartitionnum <new_partition_number> add dbpartitionnum
hostname <hostname_server> port <logical_port> without tablespaces
The following example shows the values used in this project:
db2start dbpartitionnum 1 add dbpartitionnum hostname db2bi port 1
without tablespaces
The system response for a successful operation should be as follows:
03-10-2004 15:46:10 2 0 SQL6075W The Start Database Manager operation
successfully added the node. The node is not active until all nodes are
stopped and started again.
SQL6033W Stop command processing was attempted on "1" node(s). "0"
node(s) were successfully stopped. "0" node(s) were already stopped.
"0" node(s) could not be stopped.
Tip: To check if the database partitions are created successfully, go to

directory /db2/<SID>/db2<sid>. By default, this directory contains o
subdirectory NODE0000 for partition 0. You should find there an additional
subdirectory for each partition that was added.
The new partitions will NOT be listed by the command db2 list
DBPARTITIONNUMS at this time, because there is no partition group that is
referencing this partition.

4. Stop the database.
5. Check the file db2nodes.cfg. For example, before adding partitions, the
db2nodes.cfg file looked as follows:
0 serverA 0
After adding another partition, the file should contain two entries as follows:
0 serverA 0
1 serverA 1
If the additional entry for the new database partition is not added
automatically (which was the case when we used the ksh shell), you have to
add it manually.
6. Start the database and verify that the new database partition starts correctly.
For example, after adding another partition we receive the following output
when executing db2start:
04-07-2004 15:24:30 0 0 SQL1063N DB2START processing was successful.
SQL1063N DB2START processing was successful.
7. Repeat steps 1 to 6 for each partition to be added to the database.
Attention: After creating new database partitions, verify that InsertBuffering

is activated. To activate it, add the following two lines to file
/db2/db2<sid>/sqllib/cfg/db2cli.ini:
[common]
InsertBuffering = 2
Updating database configuration for new DB partition

Each partition has its own database configuration parameters. For the new
partitions, all database configuration parameters are set with DB2 default values.
To update the database parameter in the additional partitions, you can create a
DB2 script that can be executed on each partition. To update the parameters of
database partition 2, for example, you can use the following script:
connect reset;
set client attach_node 2;
set client connect_node 2;
update db cfg for bw1 using SORTHEAP 16000;
update db cfg for bw1 using STMTHEAP 10000;
update db cfg for bw1 using APPLHEAPSZ 15000;
...
302 SAP BW and DB2

Important: You have to make sure the log path (and optionally, the mirror log
path) for the new partitions is correct. To define the log path for partition 2 for
example, use the following command:
db2_all "<<+2< db2 update db cfg for <DB_SID> using NEWLOGPATH

/db2/<SID>/log_dir/”
db2_all "<<+2< db2 update db cfg for <DB_SID> using MIRRORLOGPATH

/db2/<SID>/log_dir2/"
Adding new containers

For each new database partition you must add new containers to the system
temporary tablespaces. Here is the procedure:
1. Log on into the system as db2<sid>
2. Open DB2 command prompt windows and execute the following commands:
Assume that you have the default SMS temporary tablespaces PSAPTEMP
and PSAPTEMP16:
– alter tablespace PSAPTEMP add ('<tablespace_path_4K') on
dbpartitionnum (<partition_number>)
Example:
alter tablespace PSAPTEMP
add ('/db2/BW1/saptemp1/NODE0001/temp4') on dbpartitionnum (1)
– alter tablespace PSAPTEMP16 add ('<tablespace_path_16K') on
dbpartitionnum (<partition_number>)
Example:
alter tablespace PSAPTEMP16
add ('/db2/BW1/saptemp1/NODE0001/temp16') on dbpartitionnum
(1)
3. Repeat steps 1 and 2 for each database partition.
Creating new database partition groups

A database partition group determines the partitions on which a tablespace is
created. You should create a separate partition group for each tablespace you
want to distribute.
You can create a partition group using SAP BW with transaction DB6DBP.
In the following steps we use the DB2 command line processor:

1. Log on to the database system as user db2<sid>.
2. Enter the following commands :
– db2 “create database partition group <group_name> on
dbpartitionnums
(<partition_number>,<second_partition_number>,...)”
Example:
db2 “create database partition group NGRP_AGGR_BW1_4P on
dbpartitionnums (0,1,2,3)”
Creating new partitioned tablespaces

In this step you create a new partitioned tablespace for each existing
(non-partitioned) tablespace that you want to distribute over multiple partitions.
You can create a tablespace using SAP BW with transaction DB02. In the
following steps we use the DB2 command line processor:
1. Log on into the database system as user db2<sid>.
2. Open the DB2 command prompt and enter the following commands:
create tablespace <SID>#<tablespace_name>
in database partition group <partition_group>
pagesize <page_size> managed by database
using (file ‘<container_1>’ <container_size>)
on dbpartitionnum (<partition_number_1>)
using (file ‘<container_2>’ <container_size>)
on dbpartitionnum (<partition_number_2>)
...
using (file ‘<container_n>’ <container_size>)
on dbpartitionnum (<partition_number_n>)
extentsize <extentsize> prefetchsize <prefetchsize>
bufferpool <bufferpool>
Example:
create tablespace BW1#AGGRD_4P in database partition group NGRP_AGGR_BW1_4P
pagesize 16384 managed by database using
(file ‘/db2/BW1/sapdata1/NODE0000/BW1#AGGRD_4P.container000’ 128000) on
dbpartitionnum (0) using (file
‘/db2/BW1/sapdata1/NODE0001/BW1#AGGRD_4P.container001’ 128000) on
dbpartitionnum (3) extentsize 4 prefetchsize 4 bufferpool BP_STD_16K
304 SAP BW and DB2

3. Authorize user sap<sid> to use this tablespace:
grant use of tablespace <tablespace_name> to sap<sid> with grant
option
Example:
grant use of tablespace BW1#AGGRI_4P to sapbw1 with grant option
Figure 9-3 shows the new partitioned tablespace.
Figure 9-3 New partitioned tablespace
Creating new data classes for the new partitioned tablespaces

In SAP BW, a data class is used to identify a data tablespace and the
corresponding index tablespace. The data class is referenced in the data
dictionary and in the BW metadata.
It is necessary to create a new data class for each new partitioned tablespace
and to assign the corresponding SAP BW objects (PSA, ODS, InfoCubes, and
aggregates) to the new data class. Use the following procedure:
1. Log on into the SAP BW system.
2. Go to transaction ST04 -> Configuration -> Data Classes.
3. Click Add, and enter the information as shown in Figure 9-4.

Figure 9-4 Add new data classes
4. To assign the new data class to an aggregate for example, you need to go to
the transaction RSA1 -> Infoprovider, right-click on InfoCube and select the
option Maintain Aggregates.
5. Go to the menu Extras -> Change Data Class for Aggregates.
For the other objects (such as ODS and InfoCube) you can find the option to
change the Data Class if you edit (change) the object (such as ODS and
InfoCube) and go to the menu Extras -> maintain DB-storage parameters.
6. Repeat the steps 3 - 5 for all data classes that you want to assign. In our case
we create new data classes for fact, ODS, and aggregate tablespaces,
because these are the tablespaces that we want to copy to newly created
distributed tablespaces.
Re-distributing tables
We re-distribute the tables by copying them into the new tablespaces created on
multiple partitions. We use the SAP report DB6CONV to copy the tables. It
executes an SQL statement of the form INSERT INTO target SELECT FROM
source NOT LOGGED INITIALLY to copy the data of a particular table. Because of
the NOT LOGGED INITIALLY option, this method of re-distributing data works much
faster than the DB2 redistribute command. Because the SQL statements are not
logged, it is required to backup the database after the tables are copied.
Note: Please refer to SAP Note 362325 for downloading the latest version of
report DB6CONV.
The report DB6CONV normally converts/copies only single tables. The SAP
module RSDU_REPARTITION_PREPARE_DB6 allows you to schedule the
conversion of all tables that belong to a tablespace.
306 SAP BW and DB2

Here is the list of all steps to copy tables to the new distributed tablespaces:
1. Log on to the SAP BW system.
We start for example, with copying the aggregate tablespace. That tablespace
contains 10 aggregates as shown in Figure 9-5 on page 307.
Figure 9-5 Tables of aggregate tablespace that we want to redistribute
2. Go to transaction SE37 and (via Function Module -> Test -> Single Test)
execute the function module: RSDU_REPARTITION_PREPARE_DB6.
3. Enter the name of the source tablespace in the parameter I_TABLESPACE
and the name of target tablespace in the parameter I_TABLESPACE_NEW
and execute the function. See Figure 9-6, the initial screen.
Figure 9-6 Function module to schedule more than one table to convert.
4. Go to transaction SE38, enter the name of the report DB6CONV, and

execute. You will receive a report, as depicted in Figure 9-7.

Figure 9-7 Report DB6CONV
5. Select all entries, and click the button CONVERT NEW to start the
conversion.
If you select a table entry and click show/edit, you get more details about the
table to be converted, for example, the number of rows in the table.
6. After the conversion of a table is finished, its status changes to FINISHED.
7. Repeat steps 1 to 6 for all tablespaces, you want to distribute.
9.2.2 Relocating database containers

You can relocate database containers to a different server in two ways:
1. If all servers are connected to the same storage system, you can use the VG
export / import command. This requires that the database containers of the
different database partitions are located on different volume groups (VG).
If this is not the case, you have to relocate some of the database containers
to a different VG first. You can move the containers using the db2relocatedb
command.
If the database containers are located on their own filesystem, you can also
copy the filesystem or the associated logical volume to a different VG.
2. If all servers use local attached disks, you have to copy the containers to the
new server over the network.
308 SAP BW and DB2

In our case we wanted to move the containers of database partitions 2 and 3 to
the added server. Because we have all containers of the four database partitions
in the same VG, we need to move the containers of database partitions 2 and 3
into a different VG first. This is shown in Figure 9-8. The necessary steps are
described in “Relocating containers to a different VG on the same server” on
page 310.
p-Series 650 A
<SID>#AGGRD/I
db2realocatedb <SID>#AGGRD/I
DIM
etc..
0 1 2 3
Disk Subsystems (FasT 700)
Figure 9-8 Moving containers of partitions 2 and 3 from VG1 to VG2
We then export the corresponding VG on the first server and import the VG into
the second server as shown in Figure 9-9. The necessary steps are described in
9.2.3, “Moving database partitions to another server” on page 312.

p-Series 650 A p-Series 650 B
VG
export/import
<SID>#AGGRD/I <SID>#AGGRD/I
DIM
etc..
0 1 2 3
Disk Subsystems (FasT 700)
Figure 9-9 Database partitions on two different servers
Relocating containers to a different VG on the same server

This step is not required if you already use separate VGs for the database
containers of those partitions you want to move to the additional server.
To move a database container to a different directory, for example, from

sapdatax to sapadatay, you can use the command db2relocatedb.
In our case, we wanted to relocate the containers of database partition 2 and 3 to

a different VG. Therefore we relocate the following containers:
򐂰 Containers on partition 2 and 3 of Fact data tablespace
򐂰 Containers on partition 2 and 3 of Fact Index tablespace
򐂰 Containers on partition 2 and 3 of Aggregate data tablespace
򐂰 Containers on partition 2 and 3 of Aggregate Index tablespace
򐂰 Containers on partition 2 and 3 of PSA/ODS data tablespace
򐂰 Containers on partition 2 and 3 of PSA/ODS index tablespace
Before starting, make sure that there is a recent database backup, or take a new
backup of the database. The relocation requires the following steps for each
database partition for which you want to relocate the containers:
310 SAP BW and DB2

1. Create a new VG, a new LV inside the new VG, and a new file system
(sapdata) on the previously created LV. We will relocate the containers to this
filesystem. You can also create multiple filesystems for the different
tablespaces.
2. Mount the new filesystem and change the owner and permission of the
corresponding directory (same owner/permission as the existing sapdata
directories)
3. Stop SAP BW and the database.
4. Log on to the existing database server as user db2<sid>.
5. Create new directories on the new filesystem and adapt the permissions and
ownership according to the directory (container path) you want to copy:
For example:
mkdir /db2/BW1/sapdata10/NODE0002/
chown db2bw1:dbbw1adm /db2/BW1/sapdata10/NODE0002/
chmod 700 /db2/BW1/sapdata10/NODE0002/
6. Move the corresponding containers to the new directory.
For example (sapdata5 = VG1 and sapdata10 = VG2):
mv /db2/BW1/sapdata5/NODE0002/BW1#FACTD4P.container002
/db2/BW1/sapdata10/NODE0002/BW1#FACTD4P.container002
7. On the home directory of user db2<sid> (or any directory that has db2<sid>
permission) create a relocate config file for the database partition you want to
relocate.
Example: db2relocatedb_partition2.cfg:
DB_NAME=BW1
DB_PATH=/db2/BW1
INSTANCE=db2bw1
NODENUM=2
CONT_PATH=/db2/BW1/sapdata5/NODE0002/BW1#FACTD4P.container002,/db
2/BW1/sapdata10/NODE0002/BW1#FACTD4P.container002
CONT_PATH=/db2/BW1/sapdata4/NODE0002/BW1#ODSD4P.container002,/db2
/BW1/sapdata10/NODE0002/BW1#ODSD4P.container002
...
8. As user db2<sid> execute the command:
db2relocatedb -f <file_name>
Example :
db2relocatedb -f db2relocatedb_partition2.cfg

9. Start the database and check in the DB2 log file
(/db2/<SID>/db2dump/db2dialog.log) that no errors occurred.
Try to access the relocated tablespace to make sure that it is available.
10.Start SAP BW to check the new container path using transaction DB02 ->
Containers.
11.Repeat steps 1 to 11 for each database partition for which you want to
relocate the containers.
9.2.3 Moving database partitions to another server

Now we want to move database partitions 2 and 3 to the additional server. To do
this, the following steps are required:
1. Connect the new server to the disk subsystem.
2. Implement all AIX requirements that are described in 5.2.1, “Operating
system” on page 112.
3. Install the DB2 software and required FixPaks. The procedure is described in
6.5.1, “Installing the IBM DB2 Universal Database” on page 143.
4. Create the group db<sid>adm with the same GID (group ID) that you have on
the first server.
5. Create the user db2<sid> with the same UID (user ID) and the same
parameters that you have on the first server. Make sure that you are using the
same password for both servers.
6. The following file systems are required on the additional server:
a. NFS File Systems: These filesystems, listed in Table 9-1, exist on the first
server. You need to mount them as nfs filesystems on the additional server.
Table 9-1 Shared file systems

File System Description
/db2/db2<sid> DB2 Instance
/db2/<SID>/db2dump DB2 dialog files
/db2/<SID>/log_archive DB2 offline log files. If you have mirror for DB2 log files,
don’t forget to shared the mirror too.
Example :
/db2/BW1/log_archive
/db2/BW1/log_archive2 (mirror)
/db2/<SID>/log_retrieve DB2 archived log files during database roll forward.
312 SAP BW and DB2

b. Local File Systems: These filesystems, listed in Table 9-2, need to be
created on the additional server.
Table 9-2 Local file systems

File System Description
/db2/<SID>/log_dir DB2 online database log files. If you mirror the log files,
don’t forget to create the mirror file system.
Example :
/db2/BW1/log_dir
/db2/BW1/log_dir2 (mirror)
You can use the same size that you have in the first
server. At least 540 MB required.
/db2/<SID>/db2<sid> DB2 local directory. At least 40 MB per DB partition.
/db2/<SID>/saptemp1 SMS (System Managed Space) temporary tablespace

with the same size that you have in the first server. At
least 500 MB up to 40 GB.
Change the owner to db2<sid>, group db<sid>adm, and the permissions to

744 for the local file systems.
7. Stop SAP BW and the database on the first server
8. As user db2<sid> move the database directories of those partitions that you
want to relocate to the additional server. For example, to relocate partition 2
and 3, we move the following database directories to the additional server:
/db2/<SID>/db2<sid>/NODE0002
/db2/<SID>/db2<sid>/NODE0003
9. Adapting the environment for user db2<sid>:
a. Log on to the second server as user db2<sid>
b. Copy the following files from the user’s home directory on the first server
(serverA), to the home directory on the second server (serverB):
• .dbenv_serverA.sh to .dbenv_serverB.sh
• .dbsrc_serverA.sh to .dbsrc_serverB.sh
• .sapenv_serverA.sh to .sapenv_serverB.sh
• .dbenv_serverA.csh to .dbenv_serverB.csh
• .dbsrc_serverA.csh to .dbsrc_serverB.csh
• .sapenv_serverA.csh to .sapenv_serverB.csh
• .cshrc to .cshrc
• ..profile to .profile

10.Add to the /etc/service file on the second server the same DB2
communication ports that exist in the /etc/services file on the first server. For
example:
sapdb2BW1 5900/tcp # SAP DB2 Communication Port
DB2_db2bw1 5902/tcp # SAP DB2 EEE Communication Ports
DB2_db2bw1 5903/tcp # SAP DB2 EEE Communication Ports
DB2_db2bw1_END 5906/tcp # SAP DB2 EEE Communication Ports
11.Export / Import those VGs that include the containers of the partitions you
want to move.
In our case VG2 is still on the first server and includes the file systems below:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
lv_sapd10 jfs2 60 60 1 open/syncd /db2/BW1/sapdata10
These file systems store the containers that belong to partition 2 and 3.
Filesystem sapdata10 stores the following containers, for example:
./NODE0002:
BW1#AGGRD4P.container002
BW1#AGGRI4P.container002
./NODE0003:
BW1#AGGRD4P.container003
BW1#AGGRI4P.container003
We export VG2 from the first server to the second server with the following
steps:
a. As user root, perform the following steps on the first server:
i. Unmount the file systems that are in VG2.
ii. Deactivate the VG2 using smit vg -> Deactivate a Volume Group
iii. Export VG2 using smit vg -> Export a Volume Group.
b. As user root, perform the following steps on the second server:
i. Import VG2 using smit vg -> Import a Volume Group.
You can leave the Major number blank.
ii. Activate VG2 using smit vg -> Activate a Volume Group.
iii. Mount the file systems that are in VG2.
12.Copy temporary tablespace containers to the additional server for those
database partitions that you want to move.
314 SAP BW and DB2

As user db2<sid>, perform the following steps on the first server:
a. cd /db2/<SID>/saptemp1
b. rcp -r NODE0002 <server b>:/db2/<SID>/saptemp1
c. rcp -r NODE0003 <server b>:/db2/<SID>/saptemp1
Here is an example of the previous steps:
cd /db2/BW1/saptemp1
rcp -r NODE0002 banda:/db2/BW1/saptemp1
rcp -r NODE0003 banda:/db2/BW1/saptemp1
d. Verify the owner and the permissions on the destination server.
13.Modify the .rhosts file on both servers. The file is located in the home
directory of user db2<sid>. You need to include the additional server
(serverB) as shown in the following example:
serverA db2bw1
serverB db2bw1
14.Modify the db2nodes.cfg file according to Table 9-3. The file is located in the
shared directory /db2/db2bw1/sqllib.
For example, for database partition 2 and 3, we replace the hostname
serverA with serverB, modify the logical ports and the netname. The netname
specifies the hostname or the IP address of the high speed interconnect for
FCM communication.
Table 9-3 db2nodes.cfg file format

partition num hostname logical port netname
0 serverA 0 serverA_1GB
1 serverA 1 serverA_1GB
2 serverB 0 serverB_1GB
3 serverB 1 serverB_1GB
15.Check that you can reach each server from each other server via the remote
shell command (rsh), and ensure that you are not prompted for a password.
For example:
As user db2<sid>, logon to serverA.
Execute the following command: rsh serverB -l db2<sid> hostname
If you are prompted for a password, you might have to modify the file
/etc/hosts.equiv on serverB, to include client workstation serverA.

16.Test remote shell communication between the database servers to assure
that db2start will work correctly. To do this, execute the following command
on the first server as user db2<sid>:
rah date
This command sends the date command to each configured database server
(local or remote).
In our example we have 2 database servers (serverA and serverB). When
executing the above command, we receive the following output:
Wed Apr 7 11:06:59 DFT 2004
serverA: date completed ok
Wed Apr 7 11:06:59 DFT 2004

serverB: date completed ok
If you don’t receive a response from all configured database servers, you
have to setup the remote shell communication correctly, before you continue.
Make sure that all servers are in the same timezone and that the time
difference is less than a minute. We recommend the use of NTP (Network
time protocol) to synchronize all database servers.
17.Start the database with the db2start command. In our example the
command generates the following output:
SQL1063N DB2START processing was successful.
18.And now, the SAP BW system can be started.
9.3 Summary
In this chapter we have demonstrated how to scale out a database. We
described how to add partitions to a non-partitioned database, and showed how
to add a server to a single-server configuration and spread the database
partitions across both servers. These capabilities can provide you with the
scalability you need as your environment grows. This has demonstrated the
powerful capabilities of DB2 to scale in an SAP BW environment, and to handle
the continuing growth in database volume and number of users in business
intelligence implementations.
316 SAP BW and DB2

10
Chapter 10. Scalability factors of SAP

BW on DB2 UDB ESE
This chapter describes the scalability factors that are achieved for the most
performance critical SAP BW operations, when you scale your DB2 database
system. A scalability factor describes the increase in performance for a certain
operation when increasing the number of physical database servers in your
database system.
The ability to attach additional database servers to your database system is a

unique feature of DB2 UDB ESE. It supports the ever-growing needs of SAP
Business Information Warehouse. Chapter 4, “Building SAP BW on DB2” on
page 81, describes in detail the importance of scalability in an SAP BW
environment and the business impact for the customer.
DB2 is the leading database when it comes to scalability. Key to this unique
capability is support for parallelism and partitioning as described in 3.2.3,
“Parallel processing and partitioning” on page 55. When you are running with
multiple partitions on one or multiple database servers, DB2 supports parallel
processing across all database partitions. This is called inter-partition
parallelism. It provides maximum flexibility and results in maximum throughput
with your available processing power. This is extremely important as it enables
excellent response times for your users as you grow.

10.1 DB2 scalability studies
In the following sections we summarize the results of two White Papers, which
demonstrate DB2 scalability in the areas of SAP BW dataload and SAP BW
queries:
򐂰 Performance Study for SAP Business Information Warehouse on DB2
UDB EEE for Linux, UNIX and Windows:
This study investigates scalability factors for SAP BW queries and dataload
when scaling up from 1 to 2, and from 2 to 4, database servers. In all SAP BW
query tests, the total amount of fact data was identical. The tests were
performed with single running queries and concurrently running queries. The
data load tests investigate scalability factors for dataload from PSA into
InfoCubes, as this is the most performance critical (time consuming) part of
the dataload. The throughput (number of records loaded in a given
timeframe) is compared for the different hardware environments (1, 2, and 4
database servers).
򐂰 SAP Business Warehouse implementation on DB2 UDB Sun Cluster:
This study investigates scalability for all operations of the SAP BW staging
process, when scaling up from 1 to 2 database servers. The amount of data
for the two machine setup was double the amount for the one machine setup.
In particular, the following operations were investigated:
– Dataload from PSA into InfoCube
– Repair InfoCube indexes
– Rollup aggregates
– Dataload into ODS
– Activate ODS data
In 10.4, “Performance of partitioned and unpartitioned database” on page 330,

we compare the runtimes of certain operations on a single partition and on
multiple partitions using the same hardware (logical partitioning). Because we
used the same hardware for these tests, these are actually not scalability tests.
They were carried out to prove the advantage of partitioning your database to
make use of inter-partition parallelism
318 SAP BW and DB2

10.2 Performance study for SAP BW on DB2 UDB EEE
The “SAP BW/DB2 EEE/IBM SP Project” was carried out in 2002 to investigate
Scalability of SAP BW 2.1C on DB2 UDB EEE V7.2. The results also apply to
DB2 Version 8, on Linux, UNIX, and Windows. And because Version 8 now also
provides a catalog cache on each database partition, we would expect even
better scalability. The goal of the study was to answer the following questions:
򐂰 How does SAP BW performance increase when more servers are added to
your database system?
򐂰 How well does SAP BW on DB2 UDB EEE scale regarding query
performance and data load performance?
򐂰 How does a growing number of concurrent SAP BW queries affect
throughput?
The following BW functions have been investigated:

򐂰 Scalability of single-user short and long running SAP BW queries.
򐂰 Scalability of multiple concurrent short and long running SAP BW queries.
򐂰 Scalability of the data load into SAP BW.
10.2.1 Hardware environment

As shown in Figure 10-1, an IBM Scalable Parallel (SP) processor with four wide
nodes was used for the performance study.
SP Switch
SP Node 1 SP Node 2 SP Node 3 SP Node 4
Figure 10-1 Hardware configuration used for performance study
Chapter 10. Scalability factors of SAP BW on DB2 UDB ESE 319

Each node was equipped with:
򐂰 4 CPUs, 375 MHz Power 3-II
򐂰 8 GB RAM
򐂰 2 x 18.2 GB internal disks
򐂰 1 x SP Switch MX2
򐂰 300 MB/s bidirectional
򐂰 2 x Serial Storage Adapters (SSA)
The following storage was used:

򐂰 4 SSA towers (7133-D40) with 16 disks each
򐂰 Each disk with 9.1 GB capacity
򐂰 Disks RAID5 configured
For failover protection each SSA tower was connected to 2 SP nodes.
10.2.2 Scalability of single and multi-user SAP BW queries

Figure 10-2 on page 321 shows the environment that was used for the query
tests. Three different testcases were considered, each testcase with the same
total amount of fact data. The testcases were as follows:
1. Queries on InfoCube with fact data on SP node 1
2. Queries on InfoCube with fact data on SP node 1,2
3. Queries on InfoCube with fact data on SP node 1,2,3,4
This means that when going from testcase 1 to 2 the hardware (number of SP
nodes and SSA storage towers) was doubled and again doubled when going
from testcase 2 to 3.
For each testcase, both single running SAP BW queries and multiple concurrent
SAP BW queries were tested. For the single query tests, the user that executed
the queries was always connected to the first SAP BW Instance on the first SP
node.
For the concurrent query tests, a query driver was used, that simulated several
concurrent users. The users were connected evenly to each of the 4 configured
SAP BW Instances.
320 SAP BW and DB2

SAP BW Query Driver
BW BW BW BW BW BW BW BW BW BW BW BW BW BW BW BW
front front front front front front front front front front front front front front front front
WP WP WP WP WP WP WP WP WP WP WP WP WP WP WP WP
SAP BW Instance SAP BW Instance SAP BW Instance SAP BW Instance
Par 0 Par 1 Par 2 Par 3 Par 4 Par 5 Par 6 Par 7

DIM
Master
Fact table on
2xRAID5 drives
SP node 2 on 4 x RAID5 drives
Fact table
Fact table on 8 x RAID5 drives
Temporary Tablespace (8 x RAID5)
Logging (8 mirrored disks)
SP Node1: 4 CPUs SP Node2: 4 CPUs SP Node3: 4 CPUs SP Node4: 4 CPUs
Figure 10-2 Test environment for query tests
Results of single-user query tests

Table 10-1 shows the results of the single user query tests. The inclusion factor
defines the amount of fact data that must be accessed to calculate the query
result. An inclusion factor of 1, for example, means the complete fact table must
be read. The unit of runtime is seconds.
The first number in each cell is the runtime with empty bufferpools ad the second
number (in italics) is the runtime of the second execution of the query, that is,
with filled buffer pool. Queries with different complexity and different inclusion
factors were tested:
򐂰 Queries with high inclusion factor: That means weak restrictions, as with
example Queries 1 and 2. These queries resulted in a large amount of data
being selected from the InfoCube fact tables. Because the selected data did
not fit completely in the buffer pool, these queries always involved I/O
operations, also during the second execution.
򐂰 Queries with low inclusion factors: That means strong restrictions, as with
example queries 3 to 5. Because these queries selected less data, when they
were executed the second time the data was completely in the buffer pool and
no I/O operations (disk access) occurred.

Table 10-1 Results of single-user query tests
Query Inclusion 1 SP 2 SP 4 SP
Classification Factor Node Nodes Nodes
1) Multiple restrictions on 0.2 1,908 336 169

two large dimensions 1,808 195 82
2) Weak restrictions on two 0.028 35 17 12

dimensions 22 10 5
3) Restrictions on all 0.00004 290 147 75

dimensions and on 6 4 4
hierarchy
4) Restrictions on all 0.00004 15 7 4

dimensions 6 4 2
5) Strong restrictions on one 0.00036 0.670 0.480 0.477

large dimension 0.060 0.033 0.058
Three factors speed up query performance when increasing the number of

database machines (SP nodes):
򐂰 More CPUs: This results in more agents that concurrently work on a query.
򐂰 Increased I/O parallelism: Each SP node has its own locally attached
storage. If the number of SP nodes is doubled, the number of disks is also
doubled.
򐂰 Larger buffer pool: The total amount of buffer pool is doubled when doubling
the number of SP nodes.
Some numbers in the table need further explanation. Query 1 for example, is a
complex and long running query. It scales more than linear (performance
increase of factor 10 during second execution) when going from 1 to 2 SP nodes,
because of the larger buffer pool, which results in a higher buffer pool hit ratio.
The data that was selected by query 3 to 5 (cells with gray background) did
completely fit into the buffer pool. Therefore, the larger buffer pool did not have
any impact on the execution times of these queries.
Depending on the query structure, execution plans might be different when going
from 1 to 2 and 4 SP nodes. Therefore, some queries, such as query 3 in
Table 10-1, do not scale predictably.
Short running queries remain short running when going to multiple partitions, for
example, query 5.
322 SAP BW and DB2

Results of multi-user query tests
Figure 10-3 shows the scalability factors and throughput (queries per hour) of the
multi-user query tests. We did two tests with two types of queries:
Short-running queries: During this test, no I/O operations occurred, which

means that the selected data was completely in the buffer pool. The results are
shown in the left part of Figure 10-3. During this test, 26 queries were running
concurrently at all times, which resulted in 100% CPU utilization.
Long-running queries: The queries that were used in this test selected more
data and the data did not fit completely into the buffer pool. Therefore, I/O
operations occurred during the test. During this test, 16 queries were running
concurrently at all time, which resulted in 100% CPU utilization.
Linear Scalability
Measured Scalability
SAP BW Queries/hour SAP BW Queries /hour

15000 600
12500 500
10000 400
7500 300
5000 200
2500 100
0 0
1 2 3 4 1 2 3 4
Number of SP nodes Number of SP nodes
Scalability factors for short running Scalability factors for long running
queries: queries:
• From 1 to 2 database servers: 1.84 • From 1 to 2 database servers: 2.04
• From 1 to 4 database servers: 3.58 • From 1 to 4 database servers: 4.11
Figure 10-3 Results of multi-user query tests

10.2.3 Scalability of dataload from PSA into InfoCube
Figure 10-4 shows the test environment that was used for the query tests. Data
was loaded from the distributed PSA into distributed fact table of the InfoCube.
During the load, dimension identifiers must be read from the dimension tables,
new dimension identifiers must be created for new dimension entries, the transfer
rules are applied, and the data is finally inserted into the fact table.
Because the distributed PSA and fact tables use different partitioning keys,
some rows that are selected from PSA on one partition are potentially inserted
into the fact table on a different partition (see the cross arrows from PSA to fact
tables).
Scenario 1 Scenario 2 Scenario 3
SAP BW Instance SAP BW Instance SAP BW Instance SAP BW Instance

WP WP WP WP WP WP WP WP WP WP WP WP WP WP WP WP
DB Partition 0 DB Partition 1 DB Partition 2 DB Partition 3

DIM tables
Master Data
SAP R/3 tables
PSA table(1xRAID5)
Scenario
1
Fact table(1xRAID5)
SP node 2
PSA table on 2 x RAID5 drives
Scenario
2
PSA table on 4 x RAID5 drives
Scenario
3
SP Node1: 4 CPUs SP Node2: 4 CPUs SP Node3: 4 CPUs SP Node4: 4 CPUs
Figure 10-4 Test environment for dataload from PSA into InfoCube
Three different scenarios were tested:

򐂰 Scenario 1: PSA table and fact table stored on only one SP node. Four data
load jobs were started on this SP node1.
򐂰 Scenario 2: PSA table and fact table distributed across two SP nodes, that is,
two database partitions. A total of eight data load jobs were started, four on
each SP node.
324 SAP BW and DB2

򐂰 Scenario 3: PSA table and fact table distributed across four SP nodes, that
is, four database partitions. A total of sixteen data load jobs were started, four
on each SP node.
During the tests, 33% of the dataload time was spend for database processing.
The CPU utilization was 100% in the first scenario and about 95% in the second
and third scenario. A data package size (IDOC) of 100.000 was used for all tests.
The throughput, that is, the number of records loaded in a given timeframe was
compared for each scenario.
Figure 10-5 shows the result of the tests, that is, the increase of throughput when
going from one to two SP nodes and from two to four SP nodes.
Scalability relative to 1 SP node

4 Linear Scalability
Measured Scalability
3 Scalability factors for dataload

from PSA into InfoCube:
2 • From 1 to 2 database servers:
1.77
• From 1 to 4 database servers:
1 3.28
1 2 3 4
Number of SP nodes
Figure 10-5 Results of load test from PSA into InfoCube
10.2.4 Summary of scalability test results

In this section we summarize the results of our tests.
Single-user test
Here are the single-user test results:
򐂰 In general, the SAP BW query runtimes decrease with increasing number of
SP Nodes (machines).
򐂰 Long running queries scale at least linear.
򐂰 Short running queries remain short running in a multi-node environment.

Multi-user test
Here are the multi-user test results:
򐂰 SAP BW on DB2 UDB EEE scales nearly linear in a multi-user environment.
򐂰 Scalability factors, that is, performance increase when going from one to four
SP nodes:
– Long running queries: 3.58
– Short/medium running queries: 4.11
Data load test

Here are the data load test results:
򐂰 Data load scalability factor, that is, performance increase when going from
one to four SP nodes: 3.28
10.3 SAP Business Warehouse on DB2 UDB Sun

Cluster
The white paper “SAP Business Warehouse implementation on DB2 UDB Sun
Cluster” proves scalability of SAP BW and ease of implementation when
operated on DB2 UDB ESE in a clustered environment. Second, it gives best
practices for running and optimizing SAP BW with DB2 on a Sun cluster. Third, it
shows what physical resources are needed and helps set expectations for
system performance and diagnosis.
To help customers deal with the potential huge initial outlay of hardware, the
paper presents a cluster configuration. This helps the cost issue in two ways.
First, it involves using several smaller machines linked together which are
normally less expensive. Second, customers can start with a small system that
uses only one region, or business segment, and then add more machines in the
future as they expand the SAP BW coverage.
In the following sections we show the hardware and software setup that was
used for this paper, explain the scalability tests, and show the test results.
10.3.1 Hardware and software setup

The test configuration used for the white paper was a simple cluster that held the
DB2 database and SAP application servers. As shown in Figure 10-6, two Sun
Fire V480 machines (4 x 900 MHz processors per machine) were linked via
gigabit Ethernet. There were four Sun StorEdge T3's directly attached to each of
the machines. A Sun Blade 2000 was used to simulate users for the query
phase.
326 SAP BW and DB2

The latest currently released software version was used for each software
component. The operating system was Solaris 9, the database was DB2
Universal Database Enterprise Server Edition Version 8.1 with FixPak 2, and the
application server was BW 3.1 with support package 9.
The software setup used was a two-tier approach where the database and
application servers both resided on the same machine. This is simpler and more
efficient for a small setup since at some points the database server will need
more CPU and at other points the application servers need more CPU. Having
both reside on one system allows pooling of CPU resources, and also has a side
benefit of reducing network traffic between database server and application
server.
The total application server capacity was split across the two machines by having
one instance of the application server on each machine. One of them was the
Central Instance, but other than that, each was configured with similar settings.
SunStorEdge T3
LAN Network
Sun Fire V480
Gigabit
Interconnect
Ethernet
SunBlade 2000
Sun Fire V480
Figure 10-6 Hardware configuration
The database server was distributed across the two machines using the DB2
shared-nothing partitioned database feature. Four partitions were created per
machine to show the ability of this architecture to scale.

10.3.2 Description of tests
The tests performed were similar to the stages in the SAP BW 3.0 benchmark.
These included loading the data into an InfoCube table and an ODS (online data
storage) table.
The dimensions of the InfoCube had the following cardinalities:

򐂰 100000 products
򐂰 100000 customers
򐂰 9 divisions
򐂰 9 distribution channels
򐂰 x incoming orders / day in total 10 * 365 days = 3650
򐂰 100 version
򐂰 1000 sales organizations
򐂰 22 countries
򐂰 100 types
Important: To show how the system scales as a second machine is added,

the entire set of tests were performed on one machine as well as on the two
machine setup described above. The amount of data for the two machine
setup was double the amount for the one machine setup so that the ratio
data:CPU and data:memory stayed constant.
The total amount of data loaded in the fact table was 116.800.000 rows when
testing on one machine, and double the amount when testing on two machines.
The load phase consists of the following sub-phases:

1. Load data from PSA into InfoCube: Cleans and normalizes data and
inserts it into new table. SAP BW and DB2 both used about 50% of the CPU
during this phase and there was almost no idle CPU.
2. Repair secondary indexes on InfoCube: Recreates indexes after load. The
initial data load was done without any secondary indexes on the table.
Following the data load, the secondary indexes on the fact table needed to be
rebuilt. Recreating the indexes involves repeatedly scanning the fact table, so
the data tablespace and the temporary tablespace had a significant amount
of I/O. The CPU was not saturated at all the times and sometimes had to wait
for I/O. The CPU that was used was all on the database server, that is, no
CPU was used by the application server.
3. InfoCube runstats: Gathers statistics after load. The database needs to
gather statistics to decide how to best access that data. This is a simple and
fast operation. Collecting runstats is an almost completely CPU bound activity
that the database runs. Gathering statistics currently uses only a single CPU
per table so that it does not intrude into other database operations.
328 SAP BW and DB2

4. Rollup of aggregates: Recreates the aggregates on the InfoCube after the
load. In these tests, the aggregates were rebuilt from scratch, though SAP
BW does provide functionality to maintain these incrementally.
5. ODS load: Cleans data and inserts it into a new table (non-normalized). ODS
load is similar to the InfoCube load, but it does less processing and selects
less data from the master data tables since it does not need to maintain the
dimensions. The phase also selects data in chunks of size IDOC size and
inserts them into the ODS Activation Queue table.
6. ODS activation of data: Verifies that the data is consistent and makes ODS
data available for query reporting with Business Explorer (BEx). This step
compares the active records with those in the ODS Activation Queue,
identifies changes (inserts or updates) to existing data, writes those changes
to the ODS Change Log table, and updates the records in the ODS Active
table with data from the ODS Activation Queue table. There is a significant
amount of CPU processing per row and this is the most time consuming step
of the load.
10.3.3 Results of scalability tests

Figure 10-7 shows the scalability of the different load phases, that is the
performance increase, when going from one to two machines.
Scaling of different BW operations

load from PSA into cube
Number of rows loaded per hour
repair index
rollup aggregates
load into ODS
activate ODS
Number of Machines
Figure 10-7 Results of scalability tests
Several phases have almost perfect linear scaling:

򐂰 Load of InfoCube
򐂰 Load of ODS
򐂰 Index create

The data partitioning in DB2 is designed that each database partition manages
its own part of the data, which in theory enables perfect linear scalability for this
sort of operations. Other than the coordinator node, operations are, at worse,
equivalent to performing on n databases of size 1/n, where n is the number of
database partitions. In the best case, it can be optimized further so that it is
equivalent to performing the same operation on one database of size 1/n.
10.4 Performance of partitioned and unpartitioned

database
This chapter describes the result of tests that we carried out to compare the
performance on an unpartitioned database with the performance of a partitioned
database, on the same hardware. For both scenarios, we used a single IBM
pSeries 650 server. We tested the following cases:
򐂰 In the first case we configured a single database partition.
򐂰 In the second case we configured four database partitions and distributed
PSA, ODS, and InfoCube fact data over all four partitions.
The amount of processed data was identical in both cases. Table 10-2 shows the
operations tested. You can see that some operations perform much better on a
partitioned database — as examples, collecting runstats and doing InfoPackage
compression.
Table 10-2 Performance comparison between partitioned and unpartitioned database

Operation Runtime on Runtime on
1 database partition 4 database partitions
(1 p650) (1 p650)
Load 30 InfoPackages concurrently 1821 1810

to PSA
Collecting runstats on PSA 952 231

(distribution statistics)
Create InfoCube indexes 1937 1789
Rollup into aggregates 6787 6322

(one package)
InfoPackage compression (one 2344 1279

package, InfoCube and
aggregates)
330 SAP BW and DB2

In these tests, we did not define and test different SAP BW queries. In general,
complex queries such as in SAP BW will perform much better on an SMP
machine with multiple partitions (inter-partition) parallelism, than on an SMP
machine with just one partition. The reason is that a larger number of CPUs can
be utilized very efficiently with inter-partition parallelism.
Of course, if during a certain operation the system already has 100% CPU
utilization on an unpartitioned database, it is likely that it will not run faster on a
partitioned database. This was the case, for example, when loading 30
InfoPackages concurrently.

332 SAP BW and DB2
A
Appendix A. SQL analysis with SAP BW

In this appendix we describe how you can analyze SQL when using SAP BW.
SAP BW guides the BW administrator through the performance analysis

transaction DB6PERF, which is used for analyzing SQL.
When transaction DB6PERF is started, you can select the SQL Cache row in the
navigation field (left pane) by using a mouse-click. The transaction opens the
screen depicted in Figure A-1, which shows such statistics as:
򐂰 Number of executions.
򐂰 Total time of executions in ms, and in %

Figure A-1 The SQL Cache Snapshot screen
Selecting the second statement in the right pane where the statements are
sorted according to the Total Execution Time, the SQL Statement and the used
access plan will be explained as shown in Figure A-2. The Estimated Costs value
is marked yellow, and the #key columns is marked green.
334 SAP BW and DB2

Figure A-2 The SQL Statement and the used Access Plan
By clicking the Collect button shown at the top of Figure A-3, the BW system
collects all of the necessary data to analyze the SQL.
As depicted in Figure A-4, you are asked to select the type of information
needed, such as:
򐂰 DB configuration values and level
򐂰 Tablespace configuration
򐂰 Table structure
򐂰 Statistics
򐂰 Explanation
You can also display all values on the screen as well.
Appendix A. SQL analysis with SAP BW 335

Figure A-3 The selection criteria for downloading the needed information
All the values can also be displayed on the SAP GUI (SAP Graphical User
Interface) by selecting the Display Download on Screen — see Figure A-4.
Figure A-4 Display the Analysis Result in SAP GUI
336 SAP BW and DB2

The system download all selected information into the specified directory as
shown inFigure A-5 on page 337.
Figure A-5 The Collected and Downloaded Information for the SQL Explain.
The files include all of the detailed information including the database
configuration for the partitions.
Using the download facility, SAP BW provides a complete set of information

related to a particular performance problem. Additionally you might use the result
to request remote support from SAP or IBM.
Example A-1 on page 337 shows a complete set of downloaded information

related to an SQL Cache Snapshot from our project system.
Example: A-1 The content of the collected files
DB2LEVEL File

with
"3".
Application Server: db2bi

with
"3".

REGVAR File (registry)

[e] DB2CODEPAGE=819
[e] DB2COMM=TCPIP
[e] DB2COUNTRY=1
[e] DB2DBDFT=BW1
[i] DB2_INLIST_TO_NLJN=YES
[i] DB2_MINIMIZE_LISTPREFETCH=YES
[i] DB2_UPDATE_PART_KEY=ON
[i] DB2_REDUCED_OPTIMIZATION=4
[i] DB2_ANTIJOIN=ON
[i] DB2_HASH_JOIN=ON
[i] DB2MEMMAXFREE=2000000
[i] DB2ENVLIST=INSTHOME SAPSYSTEMNAME dbs_db6_schema DIR_LIBRARY LIBPATH
[i] DB2_RR_TO_RS=ON
[i] DB2_FORCE_FCM_BP=YES
[i] DB2COUNTRY=1
[i] DB2COMM=TCPIP
[i] DB2CODEPAGE=819
[g] DB2SYSTEM=db2bi
[g] DB2ADMINSERVER=dasusr1
Application Server: db2bi

[e] DB2CHKPTR=OFF
[e] DB2CODEPAGE=819
[e] DB2COMM=TCPIP
[e] DB2COUNTRY=1
[e] DB2DBDFT=BW1
[i] DB2_INLIST_TO_NLJN=YES
[i] DB2_MINIMIZE_LISTPREFETCH=YES
[i] DB2_UPDATE_PART_KEY=ON
[i] DB2_REDUCED_OPTIMIZATION=4
[i] DB2_ANTIJOIN=ON
[i] DB2_HASH_JOIN=ON
[i] DB2MEMMAXFREE=2000000
[i] DB2ENVLIST=INSTHOME SAPSYSTEMNAME dbs_db6_schema DIR_LIBRARY LIBPATH
[i] DB2_RR_TO_RS=ON
[i] DB2_FORCE_FCM_BP=YES
[i] DB2COUNTRY=1
[i] DB2COMM=TCPIP
[i] DB2CODEPAGE=819
[g] DB2SYSTEM=db2bi
[g] DB2ADMINSERVER=dasusr1
338 SAP BW and DB2

DBMCFG File (database manager conguration)
Database Manager Configuration
Node type = Enterprise Server Edition with local and remote clients
Database manager configuration release level = 0x0a00
CPU speed (millisec/instruction) (CPUSPEED) = 5.235149e-07

Communications bandwidth (MB/sec) (COMM_BANDWIDTH) = 1.000000e+02
Max number of concurrently active databases (NUMDB) = 8

Data Links support (DATALINKS) = NO
Federated Database System Support (FEDERATED) = NO
Transaction processor monitor name (TP_MON_NAME) =
Default charge-back account (DFT_ACCOUNT_STR) =
Java Development Kit installation path (JDK_PATH) = /usr/java13_64
Diagnostic error capture level (DIAGLEVEL) = 3

Notify Level (NOTIFYLEVEL) = 3
Diagnostic data directory path (DIAGPATH) = /db2/BW1/db2dump
Default database monitor switches

Bufferpool (DFT_MON_BUFPOOL) = ON
Lock (DFT_MON_LOCK) = ON
Sort (DFT_MON_SORT) = ON
Statement (DFT_MON_STMT) = ON
Table (DFT_MON_TABLE) = ON
Timestamp (DFT_MON_TIMESTAMP) = ON
Unit of work (DFT_MON_UOW) = ON
Monitor health of instance and databases (HEALTH_MON) = OFF
SYSADM group name (SYSADM_GROUP) = DBBW1ADM

SYSCTRL group name (SYSCTRL_GROUP) = DBBW1CTL
SYSMAINT group name (SYSMAINT_GROUP) = DBBW1MNT
Database manager authentication (AUTHENTICATION) = SERVER_ENCRYPT

Cataloging allowed without authority (CATALOG_NOAUTH) = NO
Trust all clients (TRUST_ALLCLNTS) = YES
Trusted client authentication (TRUST_CLNTAUTH) = CLIENT
Bypass federated authentication (FED_NOAUTH) = NO
Default database path (DFTDBPATH) = /db2/BW1
Database monitor heap size (4KB) (MON_HEAP_SZ) = 128

Java Virtual Machine heap size (4KB) (JAVA_HEAP_SZ) = 2048

Audit buffer size (4KB) (AUDIT_BUF_SZ) = 0
Size of instance shared memory (4KB) (INSTANCE_MEMORY) = AUTOMATIC
Backup buffer default size (4KB) (BACKBUFSZ) = 1024
Restore buffer default size (4KB) (RESTBUFSZ) = 1024
Sort heap threshold (4KB) (SHEAPTHRES) = 128000
Directory cache support (DIR_CACHE) = NO
Application support layer heap size (4KB) (ASLHEAPSZ) = 16

Max requester I/O block size (bytes) (RQRIOBLK) = 65000
Query heap size (4KB) (QUERY_HEAP_SZ) = 2000
DRDA services heap size (4KB) (DRDA_HEAP_SZ) = 128
Workload impact by throttled utilities(UTIL_IMPACT_LIM) = 100
Priority of agents (AGENTPRI) = SYSTEM

Max number of existing agents (MAXAGENTS) = 1024
Agent pool size (NUM_POOLAGENTS) = 100
Initial number of agents in pool (NUM_INITAGENTS) = 5
Max number of coordinating agents (MAX_COORDAGENTS) = 1024
Max no. of concurrent coordinating agents (MAXCAGENTS) = 1024
Max number of client connections (MAX_CONNECTIONS) = 1024
Keep fenced process (KEEPFENCED) = YES

Number of pooled fenced processes (FENCED_POOL) = MAX_COORDAGENTS
Initialize fenced process with JVM (INITFENCED_JVM) = NO
Initial number of fenced processes (NUM_INITFENCED) = 0
Index re-creation time (INDEXREC) = RESTART
Transaction manager database name (TM_DATABASE) = 1ST_CONN

Transaction resync interval (sec) (RESYNC_INTERVAL) = 180
SPM name (SPM_NAME) =

SPM log size (SPM_LOG_FILE_SZ) = 256
SPM resync agent limit (SPM_MAX_RESYNC) = 20
SPM log path (SPM_LOG_PATH) =
TCP/IP Service name (SVCENAME) = sapdb2BW1

Discovery mode (DISCOVER) = SEARCH
Discover server instance (DISCOVER_INST) = ENABLE
Maximum query degree of parallelism (MAX_QUERYDEGREE) = 4

Enable intra-partition parallelism (INTRA_PARALLEL) = YES
No. of int. communication buffers(4KB)(FCM_NUM_BUFFERS) = 4096

Node connection elapse time (sec) (CONN_ELAPSE) = 10
Max number of node connection retries (MAX_CONNRETRIES) = 5
340 SAP BW and DB2

Max time difference between nodes (min) (MAX_TIME_DIFF) = 60
db2start/db2stop timeout (min) (START_STOP_TIME) = 10
DBCFG File (database configuration files for BW1 and

all 4 database partitions)
Database Configuration for Database BW1
Database configuration release level = 0x0a00

Database release level = 0x0a00
Database territory = en_US

Database code page = 819
Database code set = ISO8859-1
Database country/region code = 1
Dynamic SQL Query management (DYN_QUERY_MGMT) = DISABLE
Discovery support for this database (DISCOVER_DB) = ENABLE
Default query optimization class (DFT_QUERYOPT) = 5

Degree of parallelism (DFT_DEGREE) = 1
Continue upon arithmetic exceptions (DFT_SQLMATHWARN) = NO
Default refresh age (DFT_REFRESH_AGE) = 0
Number of frequent values retained (NUM_FREQVALUES) = 10
Number of quantiles retained (NUM_QUANTILES) = 20
Backup pending = NO
Database is consistent = NO
Rollforward pending = NO
Restore pending = NO
Multi-page file allocation enabled = NO
Log retain for recovery status = NO

User exit for logging status = NO
Data Links Token Expiry Interval (sec) (DL_EXPINT) = 60

Data Links Write Token Init Expiry Intvl(DL_WT_IEXPINT) = 60
Data Links Number of Copies (DL_NUM_COPIES) = 1
Data Links Time after Drop (days) (DL_TIME_DROP) = 1
Data Links Token in Uppercase (DL_UPPER) = NO
Data Links Token Algorithm (DL_TOKEN) = MAC0

Database heap (4KB) (DBHEAP) = 25000
Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC
Catalog cache size (4KB) (CATALOGCACHE_SZ) = 2560
Log buffer size (4KB) (LOGBUFSZ) = 1024
Utilities heap size (4KB) (UTIL_HEAP_SZ) = 10000
Bufferpool size (pages) (BUFFPAGE) = 10000
Extended storage segments size (4KB) (ESTORE_SEG_SZ) = 16000
Number of extended storage segments (NUM_ESTORE_SEGS) = 0
Max storage for lock list (4KB) (LOCKLIST) = 80000
Max size of appl. group mem set (4KB) (APPGROUP_MEM_SZ) = 128000

Percent of mem for appl. group heap (GROUPHEAP_RATIO) = 25
Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = 1600
Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = (SHEAPTHRES)

Sort list heap (4KB) (SORTHEAP) = 16000
SQL statement heap (4KB) (STMTHEAP) = 10000
Default application heap (4KB) (APPLHEAPSZ) = 15000
Package cache size (4KB) (PCKCACHESZ) = 5120
Statistics heap size (4KB) (STAT_HEAP_SZ) = 4384
Interval for checking deadlock (ms) (DLCHKTIME) = 300000

Percent. of lock lists per application (MAXLOCKS) = 90
Lock timeout (sec) (LOCKTIMEOUT) = 3600
Changed pages threshold (CHNGPGS_THRESH) = 40

Number of asynchronous page cleaners (NUM_IOCLEANERS) = 6
Number of I/O servers (NUM_IOSERVERS) = 6
Index sort flag (INDEXSORT) = YES
Sequential detect flag (SEQDETECT) = YES
Default prefetch size (pages) (DFT_PREFETCH_SZ) = 32
Track modified pages (TRACKMOD) = ON
Default number of containers = 1

Default tablespace extentsize (pages) (DFT_EXTENT_SZ) = 2
Max number of active applications (MAXAPPLS) = AUTOMATIC

Average number of active applications (AVG_APPLS) = 16
Max DB files open per application (MAXFILOP) = 1950
Log file size (4KB) (LOGFILSIZ) = 16380

Number of primary log files (LOGPRIMARY) = 20
Number of secondary log files (LOGSECOND) = 40
Changed path to log files (NEWLOGPATH) =
Path to log files =
/db2/BW1/log_dir/NODE0000/
Overflow log path (OVERFLOWLOGPATH) =
342 SAP BW and DB2

Mirror log path (MIRRORLOGPATH) =
/db2/BW1/log_dir2/NODE0000/
First active log file =
Block log on disk full (BLK_LOG_DSK_FUL) = YES
Percent of max active log space by transaction(MAX_LOG) = 0
Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0
Group commit count (MINCOMMIT) = 1

Percent log file reclaimed before soft chckpt (SOFTMAX) = 300
Log retain for recovery enabled (LOGRETAIN) = OFF
User exit for logging enabled (USEREXIT) = OFF
Auto restart enabled (AUTORESTART) = ON

Index re-creation time (INDEXREC) = RESTART
Default number of loadrec sessions (DFT_LOADREC_SES) = 1
Number of database backups to retain (NUM_DB_BACKUPS) = 12
Recovery history retention (days) (REC_HIS_RETENTN) = 180
TSM management class (TSM_MGMTCLASS) =

TSM node name (TSM_NODENAME) =
TSM owner (TSM_OWNER) =
TSM password (TSM_PASSWORD) =
Attention: Other BW1 and partition configuration files would typically follow,
and have the type of information as in the above example. But, they have been
deleted to save space.
TABLESPACE Configurations File
Tablespace ID = 0
Name = SYSCATSPACE
Contents = Any data
State = 0x0000
Normal
Total pages = 166400
Useable pages = 166398
Used pages = 53448
Free pages = 112950
High water mark (pages) = 53448
Page size (bytes) = 4096
Extent size (pages) = 2
Prefetch size (pages) = 2
Number of containers = 1

Attention: There may be additional tablespaces that followed, and each
would have their statistics. But they have been deleted to save space here.
In a partitioned database server environment, only the tablespaces on the

current node are listed.
TABLE STRUCTURE File
-- This CLP file was created using DB2LOOK Version 8.1

-- Timestamp: Wed Mar 17 10:54:55 PST 2004
-- Database Name: BW1
-- Database Manager Version: DB2/AIX64 Version 8.1.3
-- Database Codepage: 819
-- Database Collating Sequence is: BINARY
CONNECT TO BW1;
---------------------------------
-- DDL statements for User Defined Functions
---------------------------------
CREATE FUNCTION "SAPBW1 "."DB6PMCF"

(
VARCHAR(255)
)
RETURNS TABLE
(
FS_NAME VARCHAR(200),
FREE_KB INTEGER,
USED_KB INTEGER,
TOTAL_KB INTEGER,
NUM_IUSED INTEGER,
PCT_IUSED SMALLINT
)
SPECIFIC SQL040218200033000
EXTERNAL NAME '/usr/sap/BW1/SYS/exe/run/db6pmudf!Db6pmcf'
LANGUAGE C
PARAMETER STYLE DB2SQL
VARIANT
FENCED NOT THREADSAFE
NOT NULL CALL
NO SQL
NO EXTERNAL ACTION
344 SAP BW and DB2

SCRATCHPAD
FINAL CALL
DISALLOW PARALLEL
NO DBINFO;
CREATE FUNCTION "SAPBW1 "."DB6PM_LST"

(
VARCHAR(255)
)
RETURNS TABLE
(
ARTIF_KEY INTEGER,
SYSOUT VARCHAR(255)
)
SPECIFIC SQL040218200032900
EXTERNAL NAME '/usr/sap/BW1/SYS/exe/run/db6pmudf!Db6pm_lst'
LANGUAGE C
PARAMETER STYLE DB2SQL
VARIANT
FENCED NOT THREADSAFE
NOT NULL CALL
NO SQL
NO EXTERNAL ACTION
SCRATCHPAD
FINAL CALL
DISALLOW PARALLEL
NO DBINFO;
------------------------------------------------
-- DDL Statements for table "SAPBW1 "."/BIC/DZSD_C011"
------------------------------------------------
CREATE TABLE "SAPBW1 "."/BIC/DZSD_C011" (

"DIMID" INTEGER NOT NULL WITH DEFAULT 0 ,
"SID_0SOLD_TO" INTEGER NOT NULL WITH DEFAULT 0 )
IN "BW1#DIMD" INDEX IN "BW1#DIMI" ;
-- DDL Statements for indexes on Table "SAPBW1 "."/BIC/DZSD_C011"
CREATE UNIQUE INDEX "SAPBW1 "."/BIC/DZSD_C011~0" ON "SAPBW1

"."/BIC/DZSD_C011"
("DIMID" ASC) ALLOW REVERSE SCANS;
-- DDL Statements for indexes on Table "SAPBW1 "."/BIC/DZSD_C011"
CREATE INDEX "SAPBW1 "."/BIC/DZSD_C011~010" ON "SAPBW1 "."/BIC/DZSD_C011"

("SID_0SOLD_TO" ASC) ALLOW REVERSE SCANS;
-- DDL Statements for primary key on Table "SAPBW1 "."/BIC/DZSD_C011"

ALTER TABLE "SAPBW1 "."/BIC/DZSD_C011"
ADD CONSTRAINT "/BIC/DZSD_C011~0" PRIMARY KEY
("DIMID");
COMMIT WORK;
CONNECT RESET;
TERMINATE;
STATISTICS File
-- This CLP file was created using DB2LOOK Version 8.1

-- Timestamp: Wed Mar 17 10:55:13 PST 2004
-- Database Name: BW1
-- Database Manager Version: DB2/AIX64 Version 8.1.3
-- Database Codepage: 819
-- Database Collating Sequence is: BINARY
CONNECT TO BW1;
---------------------------------------------
-- Mimic Tables, Columns, Indexes and Column Distribution
---------------------------------------------
-- Mimic table /BIC/DZSD_C011
RUNSTATS ON TABLE "SAPBW1 "."/BIC/DZSD_C011" WITH DISTRIBUTION ON COLUMNS (

DIMID NUM_FREQVALUES 0 NUM_QUANTILES 0,
SID_0SOLD_TO NUM_FREQVALUES 0 NUM_QUANTILES 0)
;
UPDATE SYSSTAT.INDEXES
SET NLEAF=-1,
NLEVELS=-1,
FIRSTKEYCARD=-1,
FIRST2KEYCARD=-1,
FIRST3KEYCARD=-1,
FIRST4KEYCARD=-1,
FULLKEYCARD=-1,
CLUSTERFACTOR=-1,
CLUSTERRATIO=-1,
SEQUENTIAL_PAGES=-1,
DENSITY=-1,
346 SAP BW and DB2

AVERAGE_SEQUENCE_GAP=-1,
AVERAGE_SEQUENCE_FETCH_GAP=-1,
AVERAGE_SEQUENCE_PAGES=-1,
AVERAGE_SEQUENCE_FETCH_PAGES=-1,
AVERAGE_RANDOM_PAGES=-1,
AVERAGE_RANDOM_FETCH_PAGES=-1,
NUMRIDS=-1,
NUMRIDS_DELETED=-1,
NUM_EMPTY_LEAFS=-1
WHERE TABNAME = '/BIC/DZSD_C011' AND TABSCHEMA = 'SAPBW1 ';
UPDATE SYSSTAT.COLUMNS
SET COLCARD=-1,
NUMNULLS=-1
UPDATE SYSSTAT.TABLES
SET CARD=0,
NPAGES=0,
FPAGES=1,
OVERFLOW=0,
ACTIVE_BLOCKS=0
SET COLCARD=0,
NUMNULLS=0,
SUB_COUNT=-1,
SUB_DELIM_LENGTH=-1,
AVGCOLLEN=4
WHERE COLNAME = 'DIMID' AND TABNAME = '/BIC/DZSD_C011' AND TABSCHEMA =
'SAPBW1 ';
SET COLCARD=0,
NUMNULLS=0,
SUB_COUNT=-1,
SUB_DELIM_LENGTH=-1,
AVGCOLLEN=4
WHERE COLNAME = 'SID_0SOLD_TO' AND TABNAME = '/BIC/DZSD_C011' AND TABSCHEMA
= 'SAPBW1 ';
COMMIT WORK;
UPDATE SYSSTAT.COLDIST
SET COLVALUE = NULL, VALCOUNT= -1
WHERE VALCOUNT <> -1 AND COLNAME = 'DIMID' AND TABNAME = '/BIC/DZSD_C011'
AND TABSCHEMA = 'SAPBW1 ';

COMMIT WORK;
UPDATE SYSSTAT.COLDIST
SET COLVALUE = NULL, VALCOUNT= -1
WHERE VALCOUNT <> -1 AND COLNAME = 'SID_0SOLD_TO' AND TABNAME =
'/BIC/DZSD_C011'
AND TABSCHEMA = 'SAPBW1 ';
COMMIT WORK;
SET NLEAF=0,
NLEVELS=1,
FIRSTKEYCARD=0,
FIRST2KEYCARD=-1,
FIRST3KEYCARD=-1,
FIRST4KEYCARD=-1,
FULLKEYCARD=0,
CLUSTERFACTOR=-1.000000,
CLUSTERRATIO=100,
SEQUENTIAL_PAGES=0,
DENSITY=0,
AVERAGE_SEQUENCE_GAP=0.000000,
AVERAGE_SEQUENCE_FETCH_GAP=-1.000000,
AVERAGE_SEQUENCE_PAGES=0.000000,
AVERAGE_SEQUENCE_FETCH_PAGES=-1.000000,
AVERAGE_RANDOM_PAGES=0.000000,
AVERAGE_RANDOM_FETCH_PAGES=-1.000000,
NUMRIDS=0,
NUMRIDS_DELETED=0,
NUM_EMPTY_LEAFS=0
WHERE COLNAMES = '+DIMID'
AND TABNAME = '/BIC/DZSD_C011' AND TABSCHEMA = 'SAPBW1 ';
SET NLEAF=0,
NLEVELS=1,
FIRSTKEYCARD=0,
FIRST2KEYCARD=-1,
FIRST3KEYCARD=-1,
FIRST4KEYCARD=-1,
FULLKEYCARD=0,
CLUSTERFACTOR=-1.000000,
CLUSTERRATIO=100,
SEQUENTIAL_PAGES=0,
DENSITY=0,
AVERAGE_SEQUENCE_GAP=0.000000,
AVERAGE_SEQUENCE_FETCH_GAP=-1.000000,
AVERAGE_SEQUENCE_PAGES=0.000000,
348 SAP BW and DB2

AVERAGE_SEQUENCE_FETCH_PAGES=-1.000000,
AVERAGE_RANDOM_PAGES=0.000000,
AVERAGE_RANDOM_FETCH_PAGES=-1.000000,
NUMRIDS=0,
NUMRIDS_DELETED=0,
NUM_EMPTY_LEAFS=0
WHERE INDNAME = '/BIC/DZSD_C011~010' AND INDSCHEMA = 'SAPBW1 '
AND TABNAME = '/BIC/DZSD_C011' AND TABSCHEMA = 'SAPBW1 ';
COMMIT WORK;
-- Mimic functions
UPDATE SYSSTAT.FUNCTIONS
SET ios_per_invoc= -1.0,
insts_per_invoc= -1.0,
ios_per_argbyte= -1.0,
insts_per_argbyte= -1.0,
percent_argbytes= -1,
initial_ios= -1.0,
initial_insts= -1.0,
cardinality= -1.0;
COMMIT WORK;
CONNECT RESET;
TERMINATE;
EXPLAIN File
Connecting to the Database.

DB2 Universal Database Version 8.1, 5622-044 (c) Copyright IBM Corp. 1991,
2002
Licensed Material - Program Property of IBM
IBM DATABASE 2 Explain Table Format Tool
******************** EXPLAIN INSTANCE ********************
DB2_VERSION: 08.01.3
SOURCE_NAME: SYSSH200
SOURCE_SCHEMA: NULLID
SOURCE_VERSION:
EXPLAIN_TIME: 2004-03-17-10.29.01.664445
EXPLAIN_REQUESTER: SAPBW1

Database Context:
----------------
Parallelism: Inter-Partition Parallelism
CPU Speed: 5.235149e-07
Comm Speed: 100
Bufferpool size: 13060
Sort Heap size: 16000
Database Heap size: 25000
Lock List size: 80000
Maximum Lock List: 90
Average Applications: 16
Locks Available: 5256000
Package Context:
---------------
SQL Type: Dynamic
Optimization Level: 5
Blocking: Block All Cursors
Isolation Level: Cursor Stability
---------------- STATEMENT 1 SECTION 65 ----------------

QUERYNO: 1719258354
QUERYTAG:
Statement Type: Select
Updatable: No
Deletable: No
Query Degree: 1
Original Statement:
------------------
SELECT "DIMID"
FROM "/BIC/DZSD_C011"
WHERE "SID_0SOLD_TO" = ? FETCH FIRST 1 ROWS ONLY
OPTIMIZE
FOR 1 ROWS
Optimized Statement:
-------------------
SELECT Q1.DIMID AS "DIMID"
FROM SAPBW1."/BIC/DZSD_C011" AS Q1
WHERE (Q1.SID_0SOLD_TO = :?)
Access Plan:
-----------
Total Cost: 0.0714158
Query Degree: 0
Rows
350 SAP BW and DB2

RETURN
( 1)
Cost
I/O
|
0
DTQ
( 2)
0.0714158
0
|
0
FETCH
( 3)
0.021395
0
/----+----\
0 0
IXSCAN TABLE: SAPBW1
( 4) /BIC/DZSD_C011
0.0209186
0
|
0
INDEX: SAPBW1
/BIC/DZSD_C011~0
1) RETURN: (Return Result)

Cumulative Total Cost: 0.0714158
Cumulative CPU Cost: 136416
Cumulative I/O Cost: 0
Cumulative Re-Total Cost: 0.00283065
Cumulative Re-CPU Cost: 5407
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 0.0714158
Cumulative Comm Cost: 1
Cumulative First Comm Cost: 0
Estimated Bufferpool Buffers: 1
Arguments:
---------
BLDLEVEL: (Build level)
DB2 v8.1.1.24 : s030728
ENVVAR : (Environment Variable)
DB2_INLIST_TO_NLJN = YES

DB2_MINIMIZE_LISTPREFETCH = YES
DB2_REDUCED_OPTIMIZATION = 4
Input Streams:
-------------
5) From Operator #2
Estimated number of rows: 0

Partition Map ID: -100
Partitioning: (COOR )
Coordinator Partition
Number of columns: 1
Subquery predicate ID: Not Applicable
Column Names:
------------
+Q2.DIMID
Partition Column Names:

----------------------
+NONE
2) TQ : (Table Queue)
Arguments:
---------
LISTENER: (Listener Table Queue type)
FALSE
TQMERGE : (Merging Table Queue flag)
FALSE
TQREAD : (Table Queue Read type)
READ AHEAD
TQSEND : (Table Queue Write type)
DIRECTED
UNIQUE : (Uniqueness required flag)
FALSE
Input Streams:
352 SAP BW and DB2

-------------
4) From Operator #3

Partition Map ID: 3
Partitioning: ( 0)
Single Node (# 0) Partition
Column Names:
------------
+Q1.$RID$+Q1.DIMID+Q1.SID_0SOLD_TO

----------------------
+NONE
Output Streams:
--------------
5) To Operator #1

Partition Map ID: -100
Partitioning: (COOR )
Coordinator Partition
Column Names:
------------
+Q2.DIMID

----------------------
+NONE
3) FETCH : (Fetch)

Arguments:
---------
MAXPAGES: (Maximum pages for prefetch)
ALL
ALL
PREFETCH: (Type of Prefetch)
NONE
ROWLOCK : (Row Lock intent)
NEXT KEY SHARE
TABLOCK : (Table Lock intent)
INTENT SHARE
Predicates:
----------
2) Sargable Predicate
Relational Operator: Equal (=)
Subquery Input Required: No
Filter Factor: 0.04
Predicate Text:
--------------
(Q1.SID_0SOLD_TO = :?)
Input Streams:
-------------
2) From Operator #4

Partition Map ID: 3
Partitioning: ( 0)
Column Names:
------------
+Q1.DIMID(A)+Q1.$RID$

----------------------
+NONE
3) From Object SAPBW1./BIC/DZSD_C011

Partition Map ID: 3
Partitioning: ( 0)
354 SAP BW and DB2

Column Names:
------------
+Q1.SID_0SOLD_TO

----------------------
+NONE
Output Streams:
--------------
4) To Operator #2

Partition Map ID: 3
Partitioning: ( 0)
Column Names:
------------
+Q1.$RID$+Q1.DIMID+Q1.SID_0SOLD_TO

----------------------
+NONE
4) IXSCAN: (Index Scan)

Arguments:
---------
ALL
PREFETCH: (Type of Prefetch)
NONE
ROWLOCK : (Row Lock intent)

NEXT KEY SHARE
SCANDIR : (Scan Direction)
FORWARD
TABLOCK : (Table Lock intent)
INTENT SHARE
Input Streams:
-------------
1) From Object SAPBW1./BIC/DZSD_C011~0

Partition Map ID: 3
Partitioning: ( 0)
Column Names:
------------

----------------------
+NONE
Output Streams:
--------------
2) To Operator #3

Partition Map ID: 3
Partitioning: ( 0)
Column Names:
------------

----------------------
+NONE
Objects Used in Access Plan:

---------------------------
Schema: SAPBW1
Name: /BIC/DZSD_C011~0
356 SAP BW and DB2

Type: Index
Time of creation: 2004-02-23-11.30.54.497783
Last statistics update: 2004-03-16-18.47.14.386674
Number of rows: 0
Width of rows: -1
Number of bufferpool pages: 1
Distinct row values: Yes
Tablespace name: BW1#DIMI
Tablespace overhead: 24.100000
Tablespace transfer rate: 0.900000
Source for statistics: Single Node
Prefetch page count: 16
Container extent page count: 16
Index clustering statistic: 100.000000
Index leaf pages: 0
Index tree levels: 1
Index full key cardinality: 0
Index first key cardinality: 0
Index first 2 keys cardinality: -1
Index sequential pages: 0
Index page density: 0
Index avg sequential pages: 0
Index avg gap between sequences:0
Index avg random pages: 0
Fetch avg sequential pages: -1
Fetch avg gap between sequences:-1
Fetch avg random pages: -1
Index RID count: 0
Index deleted RID count: 0
Index empty leaf pages: 0
Base Table Schema: SAPBW1
Base Table Name: /BIC/DZSD_C011
Columns in index:
DIMID
Schema: SAPBW1
Name: /BIC/DZSD_C011
Type: Table
Time of creation: 2004-02-23-11.30.54.422579
Last statistics update: 2004-03-16-18.47.14.386674
Number of rows: 0
Width of rows: 14
Number of bufferpool pages: 1
Distinct row values: No
Tablespace name: BW1#DIMD

Tablespace overhead: 24.100000
Tablespace transfer rate: 0.900000
Source for statistics: Single Node
Prefetch page count: 16
Container extent page count: 16
Table overflow record count: 0
Table Active Blocks: -1
358 SAP BW and DB2

Glossary
ABAP. Advanced Business Application Application Programming Interface. An

Programming. A fourth generation programming interface provided by a software product that
language developed by SAP. enables programs to request services.
Access Control List (ACL). The list of principals Asynchronous Messaging. A method of
that have explicit permission (to publish, to communication between programs in which a
subscribe to, and to request persistent delivery of a program places a message on a message queue,
publication message) against a topic in the topic then proceeds with its own processing without
tree. The ACL defines the implementation of waiting for a reply to its message.
topic-based security.
Attribute. A field in a dimension table/
Aggregate. Pre-calculated and pre-stored
summaries, kept in the data warehouse to improve Basis. A set of middleware programs and tools
query performance. A multidimensional summary from SAP that provides the underlying base that
table derived from InfoCube data for performance; enables applications to be seamlessly interoperable
can be stored in RDBMS or MS Analysis Services. and portable across operating systems and
database products.
Aggregation. An attribute level transformation that
reduces the level of detail of available data. For BEx. Business Explorer: the SAP query and
example, having a Total Quantity by Category of reporting tool for end users tightly coupled with BW
Items rather than the individual quantity of each item
in the category. BLOB. Binary Large Object, a block of bytes of data
(for example, the body of a message) that has no
Alert Monitor for BEX. A monitoring tool for discernible meaning, but is treated as one solid
displaying exceptions whose threshold values have entity that cannot be interpreted.
been exceeded or have not been reached.
Broker domain. A collection of brokers that share
AMI. See Application Messaging Interface. a common configuration, together with the single
Configuration Manager that controls them.
Application Link Enabling. Supports the creation
and operation of distributed applications. And, Characteristic. A business intelligence
application integration is achieved via synchronous dimension.
and asynchronous communication, not via a central
database. Provides business-controlled message Cluster. A group of records with similar
exchange with consistent data on loosely linked SAP characteristics. In WebSphere MQ, a group or two or
applications. more queue managers on one or more computers,
providing automatic interconnection, and allowing
Application Messaging Interface. The queues to be shared amongst them for load
programming interface provided by MQSeries® that balancing and redundancy
defines a high level interface to message queuing
services. Compensation. The ability of DB2 to process
SQL that is not supported by a data source on
the data from that data source.

Commit. An operation that applies all the changes Data Mart. An implementation of a data
made during the current unit of recovery or unit of warehouse, typically with a smaller and more tightly
work. After the operation is complete, a new unit of restricted scope - such as for a department or
recovery or unit of work begins. workgroup. It could be independent, or derived from
another data warehouse environment.
Composite Key. A key in a fact table that is the
concatenation of the foreign keys in the dimension Data Mining. A mode of data analysis that has a
tables. focus on the discovery of new information, such as
unknown facts, data relationships, or data patterns.
Configuration Manager. A component of
WebSphere MQ Integrator that acts as the interface Data Partition. A segment of a database that can
between the configuration repository and an existing be accessed and operated on independently even
set of brokers. though it is part of a larger data structure.
Configuration repository. Persistent storage for Data Refresh. A data loading technique where all
broker configuration and topology definition. the data in a database is completely replaced with a
new set of data.
Configuration. The collection of brokers, their
execution groups, the message flows and sets Data Warehouse. A specialized data environment
that are assigned to them, and the topics and developed, structured, and used specifically for
associated access control specifications. decision support and informational applications. It is
subject oriented rather than application oriented.
Connector. See Message processing node Data is integrated, non-volatile, and time variant.
connector.
Database Instance. A specific independent
Control Center. The graphical interface that implementation of a DBMS in a specific
provides facilities for defining, configuring, environment. For example, there might be an
deploying, and monitoring resources of the independent DB2 DBMS implementation on a Linux
WebSphere MQ Integrator network. server in Boston supporting the Eastern offices, and
another separate and independent DB2 DBMS on
Data Append. A data loading technique where the same Linux server supporting the western
new data is added to the database leaving the offices. They would represent two instances of DB2.
existing data unaltered.
Database Partition. Part of a database that
Data Cleansing. A process of data manipulation consists of its own data, indexes, configuration files,
and transformation to eliminate variations and and transaction logs.
inconsistencies in data content. This is typically to
improve the quality, consistency, and usability of the DataBlades. These are program modules that
data. provide extended capabilities for Informix
databases, and are tightly integrated with the DBMS.
Data Federation. The process of enabling data
from multiple heterogeneous data sources to appear DB Connect. Enables connection to several
as if it is contained in a single relational database. relational database systems and the transfer of data
Can also be referred to “distributed access”. from these database systems into the SAP Business
Information Warehouse.
Debugger. A facility on the Message Flows view in

the Control Center that enables message flows to be
visually debugged.
360 SAP BW and DB2

Deploy. Make operational the configuration and FACTS. A collection of measures, and the
topology of the broker domain. information to interpret those measures in a given
context.
Dimension. Data that further qualifies and/or
describes a measure, such as amounts or durations. Federated Server. Any DB2 server where the DB2
Information Integrator is installed.
Distributed Application In message queuing, a
set of application programs that can each be Federation. Providing a unified interface to diverse
connected to a different queue manager, but that data.
collectively constitute a single application.
Framework. In WebSphere MQ, a collection of
Distribution list A list of MQSeries queues to programming interfaces that allow customers or
which a message can be put using a single vendors to write programs that extend or replace
statement. certain functions provided in WebSphere MQ
products.
Drill-down. Iterative analysis, exploring facts at
more detailed levels of the dimension hierarchies. Gateway. A means to access a heterogeneous
data source. It can use native access or ODBC
Dynamic SQL. SQL that is interpreted during technology.
execution of the statement.
Grain. The fundamental lowest level of data
Element. A unit of data within a message that has represented in a dimensional fact table.
a business meaning.
InfoArea. A directory if InfoProviders used in the
Enqueue. To put a message on a queue. same business context; helps organize projects.
Enrichment. The creation of derived data. An InfoCube. Star schema; a fact table with several
attribute level transformation performed by some dimension tables; consists of key figures and
type of algorithm to create one or more new characteristics; often has an aggregate summary
(derived) attributes. table.
Event. A signal to the background processing InfoProvider. Generic term for objects, for which
system that a certain status has been reached in the queries are created and executed in SAP BW. There
SAP system. The background processing system are two types of InfoProvider; objects that contain
then starts all processes that were waiting for this physical data and objects that do not contain
event. physical data. Data targets, such as InfoCubes, ODS
objects, and InfoObjects (characteristics with
Event Queue. The queue onto which the queue attributes, texts, or hierarchies) belong to the first
manager puts an event message after it detects an type of InfoProvider, and InfoSets, RemoteCubes,
event. Each category of event (queue manager, SAP RemoteCubes, and MultiProviders belong to
performance, or channel event) has its own event the second type. InfoProviders are the objects or
queue. views that are relevant for reporting.
Execution group. A named grouping of message InfoSet. Describes data sources that are usually
flows that have been assigned to a broker. defined as joins between ODS objects and/or
InfoObjects (characteristics with master data).
Extenders. These are program modules that
provide extended capabilities for DB2, and are
tightly integrated with DB2.
Glossary 361
InfoSource. An intermediary supplying updates to Message flow. A directed graph that represents
InfoCubes and ODS; contains no data; a collection the set of activities performed on a message or event
of rules and objects. as it passes through a broker. A message flow
consists of a set of message processing nodes and
Input node. A message flow node that represents message processing connectors.
a source of messages for the message flow.
Message parser. A program that interprets the bit
Instance. A complete database environment stream of an incoming message and creates an
internal representation of the message in a tree
IVews. InfoObjects (master data) with properties, structure. A parser is also responsible to generate a
text, and hierarchies. bit stream for an outgoing message from the internal
representation.
Java Database Connectivity. An application
programming interface that has the same Message processing node connector. An entity
characteristics as ODBC but is specifically designed that connects the output terminal of one message
for use by Java database applications. processing node to the input terminal of another.
Java Development Kit. Software package used to Message processing node. A node in the
write, compile, debug and run Java applets and message flow, representing a well defined
applications. processing stage. A message processing node can
be one of several primitive types or it can represent
Java Message Service. An application a subflow.
programming interface that provides Java language
functions for handling messages. Message Queue Interface. The programming
interface provided by the WebSphere MQ queue
Java Runtime Environment. A subset of the Java managers. This programming interface allows
Development Kit that allows you to run Java applets application programs to access message queuing
and applications. services.
Listener. In WebSphere MQ distributed queuing, a Message queuing. A communication technique

program that detects incoming network requests that uses asynchronous messages for
and starts the associated channel. communication between software components.
Master data. Data that remains unchanged over a Message repository. A database holding
long period of time. (attributes, texts and hierarchies message template definitions.
-- similar to data warehouse dimensions).
Message set. A grouping of related messages.
Materialized Query Table. A table where the
results of a query are stored, for later reuse. Message type. The logical structure of the data
within a message.
Measure. A data item that measures the
performance or behavior of business processes. Meta Data. Typically called data (or information)
about data. It describes or defines data elements.
Message broker. A set of execution processes
hosting one or more message flows. MOLAP. Multi-dimensional OLAP. Can be called
MD-OLAP. It is OLAP that uses a multi-dimensional
Message domain. The value that determines how database as the underlying data structure.
the message is interpreted (parsed).
362 SAP BW and DB2

MultiCube. A pre-joined view of two or more cubes Open Database Connectivity. A standard
represented as an OLAP cube to the end user. application programming interface for accessing
data in both relational and non-relational database
MQSeries. A previous name for WebSphere MQ. management systems. Using this API, database
applications can access data stored in database
Multi-dimensional analysis. Analysis of data management systems on a variety of computers
along several dimensions. For example, analyzing even if each database management system uses a
revenue by product, store, and date. different data storage format and programming
interface. ODBC is based on the call level interface
MultiProvider. A special InfoProvider that (CLI) specification of the X/Open SQL Access
gathers data from various InfoProviders, and Group.
makes them available for reporting. A
MultiProvider does not contain any data itself, Open Hub. Enables distribution of data from an
the data comes exclusively from the associated SAP BW system for external uses.
InfoProviders. A MultiProvider can consist of
any combination of InfoProviders. Optimization. The capability to enable a process
to execute and perform in such a way as to maximize
NetWeaver. A comprehensive integration and performance, minimize resource utilization, and
application platform for SAP. minimize the process execution response time
delivered to the end user.
Nickname. An identifier that is used to
reference the object located at the data source Output node. A message processing node that
that you want to access. represents a point at which messages flow out of the
message flow.
Node. See Message processing node and Plug-in
node. Partition. Part of a database that consists of its
own data, indexes, configuration files, and
Node Group. Group of one or more database transaction logs.
partitions.
Pass-through. The act of passing the SQL for an
ODS. Operational data store: A relational table for operation directly to the data source without being
holding clean data to load into InfoCubes, and can changed by the federation server.
support some query activity.
Pivoting. Analysis operation where user takes a
OLAP. OnLine Analytical Processing. different viewpoint of the results. For example,
Multi-dimensional data analysis, performed in by changing the way the dimensions are
realtime. Not dependent on underlying data arranged.
schema.
Plug-in node. An extension to the broker, written
by a third-party developer, to provide a new
message processing node or message parser in
addition to those supplied with the product.
Point-to-point. Style of application messaging in

which the sending application knows the destination
of the message.
Glossary 363
Predefined message. A message with a structure Roll-up. Iterative analysis, exploring facts at a
that is defined before the message is created or higher level of summarization.
referenced.
SAP BW. Business Information Warehouse.
Process. An activity within or outside an SAP
system with a defined start and end time. SAPS. SAP unit of measure for computing
power.
Process Variant. Name of the process. A process
can have different variants. For example, in the Shared nothing. A data management architecture
loading process, the name of the InfoPackage where nothing is shared between processes. Each
represents the process variants. The user defines a process has its own processor, memory, and disk
process variant for the scheduling time. space.
Primary Key. Field in a database table that is Slice and Dice. Analysis across several
uniquely different for each record in the table. dimensions and across many categories of data
items. Typically to uncover business behavior
PSA. Persistent staging area: flat files that hold and rules.
extract data that has not yet been cleaned or
transformed. Static SQL. SQL that has been compiled prior to
execution. Typically provides best performance.
Pushdown. The act of optimizing a data operation
by pushing the SQL down to the lowest point in the Subflow. A sequence of message processing
federated architecture where that operation can be nodes that can be included within a message flow.
executed. More simply, a pushdown operation is one
that is executed at a remote server. Subject Area. A logical grouping of data by
categories, such as customers or items.
Queue Manager. A subsystem that provides
queuing services to applications. It provides an Synchronous Messaging. A method of
application programming interface so that communication between programs in which a
applications can access messages on the queues program places a message on a message queue
that are owned and managed by the queue and then waits for a reply before resuming its own
manager. processing.
Queue. A WebSphere MQ object. Applications can Thread. In WebSphere MQ, the lowest level of
put messages on, and get messages from, a queue. parallel execution available on an operating system
A queue is owned and managed by a queue platform.
manager. A local queue is a type of queue that can
contain a list of messages waiting to be processed. Type Mapping. The mapping of a specific data
Other types of queues cannot contain messages but source type to a DB2 UDB data type
are used to point to other queues.
Unit of Work. A recoverable sequence of
RemoteCube. An InfoCube whose transaction operations performed by an application between two
data is managed externally rather than in SAP points of consistency.
BW.
User Mapping. An association made between the
ROLAP. Relational OLAP. Multi-dimensional federated server user ID and password and the data
analysis using a multi-dimensional view of relational source (to be accessed) used ID and password.
data. A relational database is used as the underlying
data structure.
364 SAP BW and DB2

Virtual Database. A federation of multiple
heterogeneous relational databases.
Warehouse Catalog. A subsystem that stores and

manages all the system metadata.
WebSphere MQ. A family of IBM licensed

programs that provides message queuing services.
Workbook. Microsoft Excel workbook with

references to InfoProvider.
Wrapper. The means by which a data federation

engine interacts with heterogeneous sources of
data. Wrappers take the SQL that the federation
engine uses and maps it to the API of the data
source to be accessed. For example, they take DB2
SQL and transform it to the language understood by
the data source to be accessed.
xtree. A query-tree tool that allows you to monitor

the query plan execution of individual queries in a
graphical environment.
zero latency. This is a term applied to a process

where there are no delays as it goes from start to
completion.
Glossary 365
366 SAP BW and DB2
Abbreviations and acronyms
MM
ABAP Advanced Business CPU Central Processing Unit
Application Programming CSA Common Storage Area
ACS access control system DB Database
ADK Archive Development Kit DBA Database Administrator
AIX Advanced Interactive DB2 Database 2™
eXecutive from IBM
DB2 UDB DB2 Universal DataBase
ALE Application Link Enabling
DB2 II DB2 Information Integrator
AMI Application Messaging
Interface DBMS DataBase Management
System
API Application Programming
Interface DCE Distributed Computing
Environment
AQR automatic query re-write
DCM Dynamic Coserver
AR access register Management
ARM automatic restart manager DCOM Distributed Component
ART access register translation Object Model
ASCII American Standard Code for DDL Data Definition Language
Information Interchange DLL Dynamically Linked Library
AST Application Summary Table DIMID Dimension Identifier
BAPI Business Application DML Data Manipulation Language
Programming Interface
DRDA® Distributed Relational
BEx Business Explorer Database Architecture
BI Business Intelligence DSA Dynamic Scalable
BIW Business Information Architecture
Warehouse (SAP) DSN Data Source Name
BW Business Information DSS Decision Support System
Warehouse (SAP)
EAI Enterprise Application
BLOB Binary Large OBject Integration
CCMS Computing Center EBCDIC Extended Binary Coded
Management System Decimal Interchange Code
CLI Call Level Interface EDA Enterprise Data Architecture
CLOB Character Large OBject EDU Engine Dispatchable Unit
CLP Command Line Processor EGM Enterprise Gateway Manager
CORBA Common Object Request EJB Enterprise Java Beans
Broker Architecture
ER Enterprise Replication

ERP Enterprise Resource Planning JE Java Edition
ESE Enterprise Server Edition JMS Java Message Service
ETL Extract Transform and Load JRE Java Runtime Environment
FP FixPak JVM Java Virtual Machine
FTP File Transfer Protocol KB Kilobyte (1024 bytes)
Gb Giga bits LDAP Lightweight Directory Access
GB Giga Bytes Protocol
GUI Graphical User Interface LPAR Logical Partition
HDR High availability Data LV Logical Volume

Replication Mb Mega bits
HPL High Performance Loader MB Mega Bytes (1,048,576 bytes)
I/O Input/Output MDC Multidimensional Clustering
IBM International Business MQI Message Queuing Interface
Machines Corporation MQT Materialized Query Table
ID Identifier MPP Massively Parallel Processing
IDE Integrated Development MRM Message Repository Manager
Environment
NPI Non-Partitioning Index
IDS Informix Dynamic Server
ODBC Open DataBase Connectivity
II Information Integrator
ODS Operational Data Store
IMG Integrated Implementation
Guide (for SAP) OLAP OnLine Analytical Processing
IMS™ Information Management OLE Object Linking and
System Embedding
I/O input/output OLTP OnLine Transaction
Processing
ISAM Indexed Sequential Access
Method ORDBMS Object Relational DataBase
Management System
ISM Informix Storage Manager
OS Operating System
ISV Independent Software Vendor
PDS Partitioned Data Set
IT Information Technology
PIB Parallel Index Build
ITR Internal Throughput Rate
PSA Persistent Staging Area
ITSO International Technical
Support Organization RBA Relative Byte Address
IX Index RBW Red Brick™ Warehouse
J2EE Java 2 Platform Enterprise RDBMS Relational DataBase
Edition Management System
JAR Java Archive RID Record Identifier
JDBC Java DataBase Connectivity RR Repeatable Read
JDK Java Development Kit RS Read Stability
368 SAP BW and DB2

SAINT SAP Add-on Installation Tool
SAP Systems, Applications,
Products.
SDK Software Developers Kit
SAPS An SAP unit of measure for
computing power
SID Surrogate Identifier
SMIT Systems Management
Interface Tool
SMP Symmetric Multi Processing
SOA Service Oriented Architecture
SOAP Simple Object Access
Protocol
SPAM Support Package Manager
SPL Stored Procedure Language
SQL Structured Query
TMU Table Management Utility
TS Tablespace
UDB Universal DataBase
UDB Universal DataBase
UDF User Defined Function
UDR User Defined Routine
URL Uniform Resource Locator
VG Volume Group (Raid disk
terminology).
VLDB Very Large DataBase
VSAM Virtual Sequential Access
Method
VTI Virtual Table Interface
WSDL Web Services Definition
Language
WWW World Wide Web
XBSA X-Open Backup and Restore
APIs
XML eXtensible Markup Language
XPS Informix eXtended Parallel
Server
Abbreviations and acronyms 369

370 SAP BW and DB2
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks”
on page 372. Note that some of the documents referenced here may be available
in softcopy only.
򐂰 DB2 UDB/WebSphere Performance Tuning Guide, SG24-6417
򐂰 DB2 UDB Backup and Recovery with ESS Copy Services, SG24-6557
Other publications
The publications listed below are relevant as information sources. Information
from them may have been referenced, or used, in the development of this
redbook:
1. Getting Started with SAP R/3® AND IBM® DB2® Universal Database, on
HP® Servers, IBM Technical White Paper.
2. SAP Business Warehouse implementation on DB2 UDB Sun Cluster, IBM
Technical White Paper.
3. SAP R/3 performance optimization, ISBN:0321112350.
4. IBM DB2 Universal Database Administration Guide, Version 8.1, SC09-4821.
5. DB2 Universal Database Performance Tuning and Monitoring Workshop, IBM
Learning Services.
6. Performance Study for SAP Business Information Warehouse on DB2
Universal Database EEE for Linux, UNIX, and Windows, an IBM paper.
7. HACMP - Backbone Infrastructure Detailed Design, a technical IBM
document by Craig Wilson and Chris Hough.
8. Data Warehousing with mySAP Business Intelligence, and SAP Technical
Brief.

Online resources
These Web sites and URLs are also relevant as further information sources:
򐂰 SAP Business Intelligence Web site
http://www.sap.com/solutions/bi
򐂰 IBM Web site with SAP content
http://www.ibm.com/software/data/partners/ae1partners/sap/
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips,
draft publications and Additional materials, as well as order hardcopy Redbooks
or CD-ROMs, at this Web site:
ibm.com/redbooks
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services

ibm.com/services
372 SAP BW and DB2

Index
Change-run 35
A characteristics 28
ABAP 89–90, 132, 134–135, 142, 152, 181, 207,
cluster multi-processing 186
225, 271–272, 288, 292
Compression 36
engine 143
concurrency - see DB2 UDB ESE
Activation table 38
connection concentrator 77
Active table 38
container - see DB2 UDB ESE
Administrator Workbench 39
Cursor Stability 54
Data Access Monitor 40
Data Load Monitor 40
Meta Data Maintenance 40 D
Scheduler 40 Data Access Monitor 40
Advanced Business Application Programming - see Data Load Monitor 40
ABAP Data Mining 15
Aggregate 32, 91, 93, 119–120, 122, 329 data warehousing 7, 9, 22
also see InfoCube an overview 8
Alerting 15 database - see DB2 UDB ESE
Application Link Enabling 40 DataSource 23, 25, 37
DB2 UDB ESE 1, 43, 113
Administration Client 180
B architecture 45
BAPI 14, 40
backup
BEx Analyzer 39
offline backup 221
also see Business Explorer
online backup 224
BEx Browser
tablespace level 226
also see Business Explorer
backups 220
buffer pool - see DB2 UDB ESE
Bitmap Indexes 103
Business Application Programming Interface - see
buffer pool 45, 53, 90, 92
BAPI 40
Catalog Caching 70
Business Content 41
Circular logging 47
Business Explorer 24
COMMIT 96
BEx Analyzer 39
concurrency 53
BEx Browser 39
Configuration Advisor Wizard 67
Query Designer 39
container 50
Web Application Designer 39
Control Center 230
business intelligence 7
Cursor Stability - see Cursor Stability
Business Intelligence Suite 15
database 50
mySAP Business Intelligence 14
agents 56
technologies 15
configuration parameters 47
operations 56
C organization 50
Central Instance - see SAP Business Information partitioned 51, 58–59, 62, 64
Warehouse performance 70
Change log table 38 database management 50, 87

database objects 48 roll-forward recovery 47
DB2 agents 45 runstats 207
db2admin.log 66 enhancements 71
db2batch tool 66 scalability - see scalability 7
db2diag.log 66 shared-nothing configuration 59, 84
Design Advisor Wizard 66 Snapshot Monitor 66
dynamic bitmap indexes 85 SQL - see SQL statements
engine dispatchable units 45 Striping data 46
Event Monitor 66 system catalog tables 50
Explain Facility 66 table 50
FixPak levels 79 tablespace 50, 90–93
hash join - see hash join tools guidelines 69
Health Center 68 Trace Facility 66
Health Monitor 68 transaction table 78
High availability features 73 type-2 indexes 73
index reorganization 75 uncommitted data 53
insert buffering 96 Uncommitted Read - see Uncommitted Read
instance 49 Version 8 highlights 70
Internet architecture 44 XML Extender to DB2 44
inter-partition parallelism - see parallelism DB2 Universal Database Enterprise Server Edition -
intra-partition parallelism - see parallelism see DB2 UDB ESE
isolation levels 53 DBA Cockpit 85, 106
join methods - see join methods Audit Log 106
locking - see locking DBA planning calendar 107
lost updates 53 remote monitoring 106
massively parallel processing 59 Dialog Instances - see SAP Business Information
master table 78 Warehouse
Merge statement 78 dimension table 29, 93, 95
monitoring and tuning tools 65 distribution statistics 105
multi-dimensional clustering 71
non-repeatable reads 53
online buffer pool configuration 77
E
EarlyWatch 70
online drop container 76
ETL - see extraction, transformation, and loading
online index reorganization 76
extraction transformation and loading 15
online load 76
extraction, transformation, and loading 25
online parameter changes 77
optimizer 60, 101, 207
cost-based 48, 60, 207 F
Page cleaners 47 fact table 29, 91, 95
parallelism - see parallelism fault tolerance 186
partitioned database 45
partitioning - see partitioning
G
performance 85 Gateway Instance - see SAP Business Information
phantom read 54 Warehouse
Pre-fetching 46 GoingLife 70
query graph model 60 granularity 37
Read Stability - see Read Stability
Repeatable Read - see Repeatable Read
ROLLBACK 96
374 SAP BW and DB2

H Operational Data Store - see Operational Data
HACMP 185 Store <$nopagge 23
cascading resource groups 190 Persistent Staging Area - see Persistent Staging
Classic 185 Area
ES (Enhanced Scalability) 185 informational database 8
multi-partition database environment 189–190 InfoSource 22–23, 25
resource groups 189 instance - see DB2 UDB ESE
HACMP Clusters Instance - see SAP Business Information Ware-
components 187 house
Single Point of Control 189 Intermediate Documents 40
supports pSeries 187 intra-partition parallelism - see parallelism
supports symmetric multiprocessors 187 isolation levels 54
HACMP clusters 187 see DB2 UDB ESE
hash join 104
parallel execution. 105
J
performance benefits 105 Java 44
Health Center - see DB2 UDB ESE EJB - see Enterprise JavaBeans
Health Monitor - see DB2 UDB ESE Enterprise JavaBeans 44
hierarchy 26, 33, 35 Integrated Development Environment 143
high availability 185 J2EE Central Services. 143
cluster multi-processing 186 J2EE cluster 132
fault tolerance 186 J2EE Engine 143
HACMP 185 JDBC 44
HACMP Clusters 187 SAP J2EE Engine 132
redundant hardware 186 SAP Web Application Server 133
Web Application Server 143
I join methods 60, 103
IDocs - see Intermediate Documents Broadcast Join 63
inclusion factor 321 Collocated Join 64, 97
InfoCube 22, 24–25, 32, 34, 90–92, 114, 117, 328 Directed Join 63
Aggregate - see Aggregate
Characteristics - see characteristics
K
Key figures - see key figures key figures 28
InfoObject 22, 25
classes of metadata 22
See information model 22 L
templates 22 line item dimension 30
InfoPackage 36, 117 locking 53
InfoProvider 25 LPAR 130, 179
information model 22
business definitions 22 M
DataSource 23 massively parallel processing 59
elements 23 master data 23, 95, 98, 119
InfoCube - see InfoCube MPP - see massively parallel processing
InfoObject - see InfoObject Multidimensional models 22
InfoSource - see InfoSource MultiProvider 26
master data - see master data mySAP Business Suite 10–11
ODS - see Operational Data Store mySAP Enterprise Portal 14
Index 375
N Redbooks Web site 372
NetWeaver - see SAP NetWeaver Contact us xv
Remote Function Call 40
RemoteCube 26
O reorganization 75
ODS - see Operational Data Store
Repeatable Read 54
OLAP 15, 123
roll-up 34
OLAP Engine 39
online functions
buffer pool configuration 77 S
drop container 76 SAP Business Information Warehouse xi, 1
index reorganization 76 3-tier system environment 83
load 76 Additional Dialog Instance 179
parameter changes 77 administration - see SAP BW Administration
Operational Data Store 23, 36 Administrator Workbench 39, 239
ODS object 23, 25, 36 an overview 7
ODS tables 90–91 anticipated growth 17
optimizer - see DB2 UDB ESE anticipated growth of users 17
architecture 21
benchmark tools 123
P business content 41
parallel processing 55
Business Content Add-on 173
query 85
Business Explorer 24, 39
parallelism 48, 85
BW related definitions 172
database backup/restore 85
Central Instance 110, 132
inter-partition parallelism 59, 85, 91, 93, 95
client copy 169
intra-partition parallelism 56, 85, 100
component of business intelligence 14
partitioning 48, 51, 55, 58–59, 64, 90
components 114
distribute the workload 94
Central Instance 114
hash partitioning 52
Database Instance 114
logical partitioning 51, 94
Dialog Instance 114
multiple database partitions 94
Gateway Instance 114
partition map 52
concurrent queries 82
partitioning keys 52, 95
continous growth 82
physical partitioning 51
customer scenario 15
re-partitioning 116
data flow 24
Persistent Staging Area 23, 25, 90, 120
Database Instance 110, 132
pipeline processing 56
DB2 synergy 81
PSA - see Persistent Staging Area
deployed on DB2 81
Dialog Instances 132
Q Front-ends 132
Queries with hierarchies 101 Gateway Instance 132
Query Designer 39 information model - see information model
query graph model - see DB2 UDB ESE installation Notes 134, 138
maintenance window 82
Management Summary 2
R MultiCubes 123
RAID data storage 186
naming convention 199
Read Stability 54
OLAP engine 39
record-based indexes 72
376 SAP BW and DB2

positioning 10 Strategy and Policy 217
QuickSizer 122 Suspending the Database 228
SAP Patch Manager 175 System Administration Assistant (SSAA) tool
scalability - see scalability 18 200
SPAM (SAP Patch Manager) 175 system managed tablespaces 205
Staging Engine 39 tablespace analysis 205
System Administration Assistant 164 tablespace backup 226
volume of data 17 tablespace reorganization 215
SAP business solutions 11 Tablespaces 204
mySAP Financials 11 the launchpad 194
SAP BW Administration 193 time periods 201
242–243, 247 SAP BW on DB2
administration tasks 195 analyze query runtimes 123
archive logging 219 architecture 89
authorization 237 baseline system 131
Automatic REORG 216 Big Bang Approach 124
backup and recovery 216 Business Content Add-on 173
delta 236 BW General Settings 172
history file 235 BW related definitions 172
incremental 235 Central Instance 142, 148, 156
roll-forward recovery 233–234 Central Services 143
to current state 231 client copy 169
version recovery 232 component distribution 133
backup recommendation 227 container 161
basic roles 194 data staging 122
circular logging 219 Database Instance 143, 157
Command Line Processor 196 database name 140
configuration facilities 196 database partitions 123
Containers 204 DB2 installation 143
create data classes 198 DB2 Setup Launchpad 145
current statistics 207 DB2 UDB FixPaks 146
daily task list 201 DB2 UDB structure 131
database recovery 230 DBA Cockpit 85, 106
database shutdown 222 Dialog Instance 143
DB2 administration 196 distribution of data 130
DB2 emergency shutdown 222 FastT-700 Storage 138
DB2 UDB backups 220 Filesystems 138
db2agent process 217 filesystems 149
dual logging 219 Front-ends 143
log files 217 group definition 159
Logging 216 hardware requirements 122
maintenance tasks 195 hardware sizing 88
offline backup 221 Implementation Roadmap 125
REORG and RUNSTATS 213 installation CDs 142
roll-forward recovery 220 installation checklists 135
runstats Installation Guide CD 134
Control 211 installation Notes 134, 138
settings 208 installation parameters 153
Storage management 202 installation procedure 142
Index 377
instance distribution 132 data distribution 262
Logical Partitioning 130 DB2 configuration hints 260
logical partitions 123 DB2 parameters 263
Logical Volumes 138 DB2 UDB ESE 260
Log-on to the SAP System 164 DB2COCKPIT 280
number of processors 123 DB2PERF 280
Phased Implementation 124 distribute the tablespaces 261
physical database structure 160 extending tablespaces 262
post-installation activities 163 Health Check 250
production support 130 isolation level 266
QuickSizer 122 lock list 266
required documentation 138 MAXLOCKS parameter 266
Roll-Out Implementation 124 memory management 263
SAN Switches 138 Missing Indexes 288
SAP BW queries 122 number of containers 262
SAP Patch Manager 175 number of I/O servers 265
SAP system ID 140 number of R/3 instances 260
sapdata directories 160 number range buffering 260
SAPinst GUI 141 overflow records 268
SAPinstGUI 150 package cache 265
SAPS 123 page cleaners 265
sizing 122 page size considerations 263
sizing guide 122 partition the database 261
Starting the SAP System 164 performance monitoring 268
Stopping the SAP System 164 prefetchers 265
System Administration Assistant 164 Proactive monitoring 272
system landscape 131 SAP BW requirements 255
system planning 137 SAP memory 258
the value 82 SAP Notes 250
tight integration 86 soft checkpoints 266
value details 89 sort heap 264
value proposition 87 system bottlenecks 271
Volume Groups 138 systems configuration 250
Web Application Server 132 the approach 250
SAP BW Performance 249 too many processes 260
a few tips 259 transaction analysis 283
aggregate table 255 Transaction logging 265
analysis and tuning 250 tuning components 257
Analyzing the SQL Statements 283 unit of work size 254
Application Monitor 291 using VARCHAR 268
bufferpools 264 work processes 259
BW Monitor 275 SAP Exchange Infrastructure 14
catalog tablespace 263 SAP Master Data Management 14
common workload monitor 278 SAP Mobile Infrastructure 14
configuration parameters 256 SAP NetWeaver 10, 12, 82, 143
configuring R/3 memory 258 components 14
container types 262 Developer Studio 143
cost-based optimizer 266 Developer Workplace 143
current database statistics 254 Enterprise Services Architecture 12
378 SAP BW and DB2

Implementation Guide 172 Dynamic SQL 65, 100
mySAP Business Suite 13 remote SQL generation 63
SAPGUI 115 Static SQL 64
ValueASP 129 Structured Query Language 50
ValueSAP phases 125 Staging Engine 39
ValueSAP Roadmaps 124 star schema 29
Web-based platform 12 also see InfoCube
SAP Notes extended star schema 28–29
see SAP Business Information Warehouse Structured Query Language - see SQL statements
see SAP BW on DB2 surrogate identifiers 29
SAP QuickSizer 122 symmetric multiprocessor 45, 55, 57–59, 62, 84,
SAP R/3 10, 25, 90 116, 187, 297–298, 331
SAP Service Marketplace 115
SAP Web Application Server 14
scalability 7, 18, 82–84
T
table - see DB2 UDB ESE
DB2 approach 43
tablespace - see DB2 UDB ESE
definition 18
TCP/IP 40
performance impact 18
Tivoli Storage Manager 230
requirement 18
total cost of ownership 19, 82, 84, 87
scale the database 117
Transfer Structure 37
scaling 19
scalability factors 317
Data Load 326 U
inclusion factor 321 Uncommitted Read 54
increased I/O parallelism 322
larger buffer pool 322
V
parallelism 317 ValueSAP Roadmaps - see SAP NetWeaver
partitioning 317
scaling the database 297
add a server 299
additional partitions 301
additional servers 297
alter the database 299
modify bufferpools 301
new data classes 305
options to partition 298
re-distribute the tables 306
relocate containers 299
relocate database containers 308
re-partition 297
scaling steps 297
separate volume groups 310
tablespace layout 300
Servers
IBM FASt T700 Storage System 110
pSeries 630 110
pSeries 650 110, 330
SMP - see symmetric multiprocessor
SQL statements 64, 94
Index 379
380 SAP BW and DB2
Building and Scaling SAP Business Information Warehouse on DB2 UDB ESE
(0.5” spine)
0.475”<->0.875”
250 <-> 459 pages
Back cover ®
Building and Scaling

SAP Business Information
Warehouse on DB2 UDB ESE
DB2 enables best SAP is a leading ERP vendor, with a large install base. A key
scalability, and high element in their product set is the SAP Business Information INTERNATIONAL
performance for SAP Warehouse (BW). The primary objective of this IBM Redbook TECHNICAL
BW is to provide guidelines to help you implement your SAP SUPPORT
Business Information Warehouse on DB2 UDB ESE. ORGANIZATION
DB2 data partitioning Two major considerations when building a business
and parallelism - key information warehouse are scalability and performance. In
this book, we have demonstrated the wide range of scalability
advantages BUILDING TECHNICAL
of BW when implemented on DB2, while maintaining the
INFORMATION BASED ON
performance requirements that are so critical. The parallelism PRACTICAL EXPERIENCE
Configuration and data partitioning capabilities of DB2 Universal Database
examples to start ESE, enables a robust, highly scalable, and high performance
with and grow business information warehouse. IBM Redbooks are developed by
For a common understanding, we first discuss the concepts the IBM International Technical
Support Organization. Experts
of data warehousing and then describe the SAP architecture from IBM, Customers and
and robust component capabilities of the SAP business Partners from around the world
information warehouse. To help in your implementation, we create timely technical
provide guidelines for how to configure SAP BW when it is information based on realistic
built on DB2. scenarios. Specific
recommendations are provided
We also describe and discuss the key capabilities and to help you implement IT
parameters to help you get the best from DB2. Key topics solutions more effectively in
such as sizing, partitioning, performance tuning, and systems your environment.
administration, are discussed to assist in the implementation
and maintenance of your system. This redbook will help
enable you to more quickly and easily implement a robust SAP For more information:
BW on DB2 UDB ESE. ibm.com/redbooks
SG24-7094-00 ISBN 0738490253

Redbook Building and Scaling SAP Business Information Warehouses On DB2 UDB ESE sg247094 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Redbook Building and Scaling SAP Business Information Warehouses On DB2 UDB ESE sg247094 PDF

Uploaded by

Copyright:

Available Formats

Front cover

Building and Scaling

DB2 data partitioning and

Building and Scaling SAP Business Information

First Edition (June 2004)

© Copyright International Business Machines Corporation 2004. All rights reserved.

Chapter 1. SAP Business Information Warehouse (BW) . . . . . . . . . . . . . . . 7

Chapter 2. SAP BW technical overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 3. DB2 UDB ESE technical overview. . . . . . . . . . . . . . . . . . . . . . . 43

© Copyright IBM Corp. 2004. All rights reserved. iii

Chapter 4. Building SAP BW on DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Chapter 5. Project test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

iv SAP BW and DB2

Chapter 6. Implementing SAP BW on DB2 . . . . . . . . . . . . . . . . . . . . . . . . 121

Chapter 7. Administration of SAP BW. . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Chapter 9. Scaling out the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Chapter 10. Scalability factors of SAP BW on DB2 UDB ESE. . . . . . . . . 317

Appendix A. SQL analysis with SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . 333

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

vi SAP BW and DB2

© Copyright IBM Corp. 2004. All rights reserved. ix

AIX® HACMP™ Redbooks™

The following terms are trademarks of other companies:

x SAP BW and DB2

SAP Business Information Warehouse with DB2® Universal Database™ (UDB)

We have a particular focus on scalability. Scaling up your system means to

SAP acknowledgement: We want to express our appreciation to SAP AG

There is a significant amount of information in this redbook, with which you

© Copyright IBM Corp. 2004. All rights reserved. xi

The following are brief biographical descriptions of the team members:

Chuck Ballard is a Project Leader at the International Technical Support

xii SAP BW and DB2

Rodrigo A. Schiavon is an SAP consultant and works in the outsourcing area at

David Bellion is a technical director at Oserve Ltd., an IBM Business Partner in

From IBM locations worldwide:

From SAP AG, in Walldorf, Germany:

From the ITSO, San Jose Center:

Become a published author

xiv SAP BW and DB2

We want our Redbooks™ to be as helpful as possible. Send us your comments

The purpose of this redbook is to demonstrate the processes of implementing

© Copyright IBM Corp. 2004. All rights reserved. 1

DB2 UDB ESE is currently the only SAP-certified parallel database

2 SAP BW and DB2

The operation of SAP BW includes administration, monitoring, and tuning.

Leading performance with DB2

The benchmark was executed on IBM eServer™ xSeries® 455 (eight

Structure of the redbook

4 SAP BW and DB2

Appendix A includes technical information to help in the analysis of your DB2

Chapter 1. SAP Business Information

In the fast-moving business environment of today, there is an increasing need for

Rapid growth is also being experienced in many enterprises, in terms of data,

To satisfy those requirements, an intense demand has been generated for

© Copyright IBM Corp. 2004. All rights reserved. 7

1.1.1 Informational databases

The data in an enterprise is typically oriented to the particular business

8 SAP BW and DB2

1.1.2 Data warehousing

Data warehousing was originally developed to satisfy strategic decision making,

A simplistic view of data warehousing is the collection of business related

To meet the requirements for data warehousing and scalable database