Sap Business Information Warehouse On The As 400 System

SAP Business Information Warehouse
on the AS/400 System
Aco Vidovic, Manfred Engelbart, Kelly Murphy
International Technical Support Organization
http://www.redbooks.ibm.com
SG24-5200-00
SG24-5200-00
International Technical Support Organization
SAP Business Information Warehouse

on the AS/400 System
August 1999
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix C, “Special notices” on page 103.
First Edition (August 1999)
This edition applies to SAP Business Warehouse Release 1.2B for use with the OS/400.
Comments may be addressed to:

IBM Corporation, International Technical Support Organization
Dept. JLU Building 107-2
3605 Highway 52N
Rochester, Minnesota 55901-7829
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1999. All rights reserved.

Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1. Introduction . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .1
1.1 BW environment . . . . . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .1
1.2 Terminology . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .2
1.3 Database . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .4
Chapter 2. Installation and set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
2.2.1 Installing the BW Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Objects created during the BW installation . . . . . . . . . . . . . . . . . 13
2.3 System landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Multiple BW systems on one AS/400 system . . . . . . . . . . . . . . . 14
2.3.2 OS/400 Logical Partitioning (LPAR) . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3 System landscape examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 3. Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 BW system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Journal receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Saving the entire AS/400 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 4. Loading the BW with data . . . . . . . . . . . . . . .. . . . . .. . . . . 29

4.1 Loading the AS/400 legacy application data . . . . . . . . .. . . . . .. . . . . 29
4.1.1 File interface — An example . . . . . . . . . . . . . . . . .. . . . . .. . . . . 29
4.1.2 Business application programming interface . . . . .. . . . . .. . . . . 43
4.2 Loading the SAP R/3 data . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . 44
Chapter 5. Performance . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 45
5.1 Performance monitoring tools . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 46
5.1.1 AS/400 system tools . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 46
5.1.2 BW tools. . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 47
5.2 Tuning techniques . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 47
5.3 BW and OS/400 parallel processing . . . .. . . . . .. . . . .. . . . . .. . . . . 48
5.3.1 Symmetric Multiprocessing (SMP) .. . . . . .. . . . .. . . . . .. . . . . 50
5.4 Analysis of BW performance behavior . .. . . . . .. . . . .. . . . . .. . . . . 59
© Copyright IBM Corp. 1999 iii

5.4.1 Loading the BW with data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.2 Long-running query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4.3 BW system administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Chapter 6. Sizing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.1 CPU requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2 Memory requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.3 Disk space and disk arms requirements . . . . . . . . . . . . . . . . . . . . . . . 88
6.4 Additional considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.5 BW system configuration examples . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Appendix A. Files used in the example of InfoCube data loading . . . . 91
Appendix B. RPG ILE preparation program . . . . . . . . . . . . . . . . . . . . . . . 95
Appendix C. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Appendix D. Related publications . . . . . . . . . . . . . . . . . . . . . . . ...... . 107

D.1 International Technical Support Organization publications. . . . ...... . 107
D.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... . 107
D.3 Other sources of information . . . . . . . . . . . . . . . . . . . . . . . . . . ...... . 108
How to get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

IBM Redbook Fax Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
List of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
ITSO Redbook evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
iv SAP Business Information Warehouse on the AS/400 System

Figures
1. BW tables relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Loading BW installation files to the AS/400 system. . . . . . . . . . . . . . . . . . . 9
3. R/3 installation menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Unpacking the patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Change the installation files directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. WRKSYSSTS — Allocating memory pool size . . . . . . . . . . . . . . . . . . . . . 15
7. WRKSHRPOOL — Memory pool priority. . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. STOPSAP — Stop R/3 system with ENDSBS option . . . . . . . . . . . . . . . . 17
9. Landscape 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Landscape 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Landscape 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Landscape 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Save R/3 System (SAVR3SYS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14. SBMJOB — Start SAVDLTRCV command . . . . . . . . . . . . . . . . . . . . . . . . 26
15. WRKACTJOB — SAVDLTRCV command . . . . . . . . . . . . . . . . . . . . . . . . 27
16. Source database design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
17. SOCUBE data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
18. SOCUBE data model expanded view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
19. SOCUBE tables — Partial view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
20. Source table conversion forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
21. CPYF from form 1 to form 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
22. Sample SQL — Convert form 2 into form 3 . . . . . . . . . . . . . . . . . . . . . . . . 39
23. CRTPF — Create intermediate table (form 4) . . . . . . . . . . . . . . . . . . . . . . 40
24. CPYF — Copy table to a single-column form . . . . . . . . . . . . . . . . . . . . . . 40
25. CPYTOSTMF — Copy table into a flat file. . . . . . . . . . . . . . . . . . . . . . . . . 41
26. Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
27. N-way processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
28. SMP processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
29. Go LICPGM —> Display installed licensed programs . . . . . . . . . . . . . . . . 50
30. ST03 — BW query performance analysis without SMP. . . . . . . . . . . . . . . 52
31. WRKACTJOB — CPU utilization of BW query without SMP . . . . . . . . . . . 53
32. WRKSYSVAL — Change system value QQRYDEGREE . . . . . . . . . . . . . 54
33. WRKACTJOB — CPU utilization of BW query with SMP . . . . . . . . . . . . . 55
34. Transaction ST03 — BW query performance analysis with SMP . . . . . . . 56
35. CHGQRYA — Change query attribute of a job . . . . . . . . . . . . . . . . . . . . . 58
36. ST03 — BW fact table data loading with indexes attached . . . . . . . . . . . . 60
37. WRKACTJOB — Data loading with indexes . . . . . . . . . . . . . . . . . . . . . . . 61
38. WRKDSKSTS — Disk status during data loading . . . . . . . . . . . . . . . . . . . 62
39. Delete InfoCube indexes before data loading . . . . . . . . . . . . . . . . . . . . . . 63
40. BW fact table data loading without indexes attached . . . . . . . . . . . . . . . . 64
v
41. SAP parallel load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
42. DB2 Symmetric Multiprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
43. WRKACTJOB — Parallel load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
44. WRKDSKSTS — Disk arm utilization during parallel load . . . . . . . . . . . . . 68
45. RSA1 — InfoCube Customer data model . . . . . . . . . . . . . . . . . . . . . . . . . 69
46. SAP Business Explorer Analyzer —> Define query. . . . . . . . . . . . . . . . . . 70
47. Starting the 0SD_C01_Q013 query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
48. Query result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
49. WRKACTJOB — BW query running with SMP enabled . . . . . . . . . . . . . . 73
50. ST03 — BW query transaction analysis, SMP enabled . . . . . . . . . . . . . . . 74
51. ST05 — SQL trace overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
52. ST05 — Explain SQL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
53. ST05 — Explain SQL statement —> Expand subtree . . . . . . . . . . . . . . . . 77
54. SQL SYSTABLES — Assign short/alternate table names. . . . . . . . . . . . . 79
55. DSPFFD — Map field names with alternate field names. . . . . . . . . . . . . . 80
56. SE11 — Create permanent index for BW database . . . . . . . . . . . . . . . . . 81
57. ST03 — Query monitoring with permanent index for table /BI00285. . . . . 82
58. ST05 — SQL trace overview with permanent index available . . . . . . . . . . 83
59. ST05 — Explain SQL statement, index available . . . . . . . . . . . . . . . . . . . 84
vi SAP Business Information Warehouse on the AS/400 System

Tables
1. OS/400 terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Libraries created during the installation of BW . . . . . . . . . . . . . . . . . . . . . 13
3. Backup activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Table Trans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. Table Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Table Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. OLTP versus OLAP workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8. Effect of performance improvement techniques in BW . . . . . . . . . . . . . . . 48
9. Query runtime comparison with and without SMP . . . . . . . . . . . . . . . . . . . 56
10. Runtime comparison — Data loading of fact table. . . . . . . . . . . . . . . . . . . 64
11. Data loading test results summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
12. Tables in the InfoCube Customer — Test data . . . . . . . . . . . . . . . . . . . . . 71
13. Field names with their alternate field names . . . . . . . . . . . . . . . . . . . . . . . 80
14. Query 0SD_C01_Q013 runtime comparison . . . . . . . . . . . . . . . . . . . . . . . 85
15. Table Trans1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
16. Table Transch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
17. Flat file Part.csv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
18. Flat file Cust.csv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
19. Flat file Trans.csv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
vii
viii SAP Business Information Warehouse on the AS/400 System
Preface
This redbook explores the SAP Business Information Warehouse (BW) on the
AS/400 system. It takes a close look at the tasks and functions that are
specific for the AS/400 environment, rather than the BW generic task. This
redbook is designed to assist AS/400 technical specialists and SAP Basis
consultants in implementing this technology.
As you read this redbook, you uncover valuable information that includes:
• Terminology and an overview of BW and AS/400 features
• The BW setup
• Recommendations for backup and recovery procedures
• Examples on how to load the BW with operational data from an online
transactional processing (OLTP) system that runs a company’s day-to-day
business (requires that you already understand BW administrator tasks
related to the creation of a data warehouse in BW)
• Hints on how to improve the performance of the AS/400 BW system
(assumes that you are fairly skilled in SAP R/3-AS/400 performance
topics)
• Preliminary sizing recommendations based on tests and SAP
recommendations
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization Rochester.
Aco Vidovic is an Advisory International Technical Support Specialist at the

International Technical Support Organization, Rochester Center. He is a
member of the ERP team, where he is responsible for SAP. He has nine years
of experience in AS/400 technical support, sales, and marketing. Before
joining the ITSO, he worked in the IBM Central Europe and Russia Midrange
Systems Marketing team.
Kelly Murphy is a Senior I/T Specialist with IBM Global Services in

Rochester, Minnesota. She has worked at IBM for 18 years. Kelly’s list of
projects includes, among others, implementation of a data warehouse in an
SAP R/3 customer environment. Her areas of expertise include DB2/400,
AS/400 ILE RPG, and C.
© Copyright IBM Corp. 1999 ix

Manfred Engelbart is a Solution Engineer and SAP Certified Basis
Consultant in IBM Germany. He belongs to the ERP Solution Sales team in
the central region. Manfred has 11 years of experience in the AS/400 field
and has worked at IBM for 24 years. He also co-authored the ITSO redbook
SAP R/3 implementation for AS/400, SG24-4672.
Thanks to the following people for their invaluable contributions to this project:
Barbara Ballard
George Barta
Dave Hubka
Dan Moravec
Ron Schmerbauch
IBM Rochester, SAP Port
Nitin Raut
IBM Rochester, Technology Solutions Center
Amy Anderson
IBM Rochester, Teraplex Center
Bryan Tousley
IBM Rochester, Partners in Development
Daniel Toft
IBM Rochester, Performance
Raymond Bills
IBM Rochester, Integrated File Systems
Jarek Miszczyk
Gottfried Schimunek
International Technical Support Organization, Rochester Center
x SAP Business Information Warehouse on the AS/400 System

Comments welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your

comments about this or other redbooks in one of the following ways:
• Fax the evaluation form found in “ITSO Redbook evaluation” on page 117
to the fax number shown on the form.
• Use the online evaluation form found at: http://www.redbooks.ibm.com
• Send your comments in an Internet note to: redbook@us.ibm.com
xi
xii SAP Business Information Warehouse on the AS/400 System
Chapter 1. Introduction
SAP Business Information Warehouse (BW) is a data warehouse solution

tailored to SAP R/3. It is a separate application (an add-on) that is
independent from SAP R/3 and has its own release and shipment cycle. SAP
R/3 belongs to the category of online transaction processing (OLTP)
applications that are used to run day-to-day business. BW is an online
analytical processing (OLAP) application that is used to support business
decisions by providing information analysis and reporting capabilities. This
document covers BW release 1.2B, which is based on SAP R/3 release 4.5B
technology.
1.1 BW environment
BW consists of several components that are used for data collection, data
use, and data maintenance. These components include:
• Business Information Warehouse Server with OLAP processor and
Staging Engine
• Meta data (data about data) repository that documents the data
warehouse environment
• Business Explorer, a graphical user interface (GUI), hosted by Microsoft
Excel or Lotus 1-2-3, that provides analyzing and viewing functions for
end-users
• Automated data extraction and data loading routines
• Administrator Workbench, a GUI-based tool that is used for BW
implementation, maintenance, customizing, scheduling, and monitoring
• Business application programming interface (BAPI) that provides links to
external tools for data extraction, data loading, and data analysis
BW system in the AS/400 environment runs on AS/400 server (or servers)

and PC workstations. The AS/400 server runs:
• BW kernel (executable code written in C, which is the same as the SAP
R/3 kernel)
• BW application code written in advanced business application
programming (ABAP)
• BW database that contains all user data and system data
PC workstations run BW frontend software (SAPGUI) that provides

presentation services for BW system administrators and end-users.
© Copyright IBM Corp. 1999 1

The system administrator manages BW by using Administrator Workbench,
which is a part of the SAP front-end. End-users access BW data through the
Business Explorer that is installed on their PC, in addition to the SAP
front-end. When end-users want to access BW data, they run a query from
the Business Explorer. Business Explorer invokes a creation of a temporary
ABAP program on the AS/400 server, which finds the requested data and
sends it back to the end-user’s workstation display.
1.2 Terminology
AS/400 end-users store and access their data in a relational database and in
flat files (also called stream files) in the Integrated File System (IFS). The
relational database consists of two-dimensional files that are in SQL
terminology called tables. Tables are made up of columns and rows. Indexes
and views are built upon the tables to provide users with quick access to
data. Tables, indexes, and views are grouped in an SQL collection.
Native OS/400 terminology uses different names as shown in Table 1.

Table 1. OS/400 terminology
SQL terms Native OS/400 terms
Table Physical file
Column Field
Row Record
Index Access path or logical file (depends on

context)
View Logical file
SQL collection Library
In this document, we mostly use the SQL terminology.
BW terminology
In addition to DB2 data structures, BW organizes data in its own data
structures.
The basic building blocks of BW are called characteristics and key figures.
The generic term for characteristics and key figures is InfoObjects. When you
create the data warehouse on your BW system, you start by creating your
InfoObjects.
2 SAP Business Information Warehouse on the AS/400 System

Characteristics are the elements of a company’s business, for example
company code, product, material, customer group, fiscal year, period, or
region. They are stored in tables called dimension tables.
Key figures are values or quantities in a company’s business, such as sales

revenue, fixed costs, sales quantity, or the number of employees. They are
stored in tables called fact tables.
A fact table contains all of the key figures at the lowest level of detail. A
dimension table contains characteristics that are required both in reporting
and in the analysis of the key figures. Characteristics are grouped into a
dimension table based on a business content logic. Dimension tables are
independent of one another. Only the fact table connects dimension tables
through key figures.
The largest organizational unit is an InfoCube. You can think of an InfoCube

as a data mart. It is a subset of a data warehouse designed to fit the needs of
a specific group of users. An InfoCube is used to answer specific end-user’s
queries and to provide information for specific analysis. It consists of a
number of relational tables that are put together in a star schema. There is
also a large fact table in the center that is surrounded by several dimension
tables.
Figure 1 shows how tables are linked together in BW InfoCube.
Fact table Dimensiontable SIDtable Masterdatatable

Dim ID Cost Dim SID Part SID Part Part
ID Part Name Name
1 10.50 1 1 111111 1 111111 1

2 100.00 2 2 222222 2 222222 2
3 5.00 3 3 333333 3 333333 3
Figure 1. BW tables relationships
Dimension tables are linked to the fact table using surrogate keys. A
surrogate key (Dim ID) is used as a unique key with each dimension table.
The master data table and the dimension table are linked by system
generated identifications called Set IDs that are stored in SID (Set ID) tables.
Introduction 3
The master data table contains attributes of characteristics, while the
dimension table contains the characteristics themselves. The dimension table
with its associated SID table and its master data table form a dimension.
1.3 Database
The BW database is running on IBM DB2 Universal Database for AS/400 (in
this document we call it DB2). DB2 is a Relational Database Management
System (RDBMS) that is a part of the Operating System/400. Since it is a part
of the system, DB2 fully utilizes all the AS/400 features. Compared to other
RDBMS products on the market, DB2 brings to BW users a number of unique
features, such as:
• DB2 is free-of-charge.
• It is automatically installed with OS/400.
• It does not require a database administrator to manage it.
• Because it uses the OS/400 single level storage, it does not have to be
partitioned. For this reason, there is no distinction between primary and
secondary indexes in DB2, as in some other RDBMS systems.
• Usage of the OS/400 Query Optimizer. This is a cost-based optimizer,
which is described in the following section.
OS/400 Query Optimizer

The optimizer is the OS/400 Query component that makes key decisions for
good database performance. It identifies the methods that can be used to
implement the query and selects the most efficient method at query runtime.
The optimizer selects an optimal access method for the given query by
calculating an implementation cost that is based on the current state of the
database. This makes it different from rule-based optimizers that access the
data, based on pre-defined rules, which must be updated manually by the
database administrator.
Possible data access methods that the optimizer may choose are:
• Non-keyed access methods: Table scan, parallel table scan, parallel
pre-fetch, parallel table pre-load, skip sequential with dynamic bitmap, and
parallel skip sequential
• Keyed access methods: Key positioning and parallel key positioning,
dynamic bitmaps (index ANDing or ORing), key selection and parallel key
selection, index from index, index only access, and parallel index preload
• Joining, grouping, ordering: Nested loop join, hash join, index grouping,
hash grouping index ordering, and sort

For every query, the optimizer maintains an optimized plan of how to access
the requested data. This access plan is built during the optimization, when
the query is run for the first time. The optimizer estimates the query access
cost based on the following costs:
• Start-up cost
• Cost associated with the given optimization method
• Cost of any index creations
• Cost of the expected number of page faults to read the rows
• Cost of processing the expected number of rows
Since the data access costs dynamically change, the optimizer changes the
access methods as well. Depending on the estimated costs, the optimizer
may use any of the available methods to access the requested data. We
show you an example of how you can observe and partly influence the
optimizer’s decisions in 5.4.2.2, “Query performance analysis” on page 72.
For more information on AS/400 data access methods, refer to these

publications:
• DB2 for AS/400 SQL Programming, SC41-5611
• Data Warehousing Solutions on the AS/400, SG24-4872
Introduction 5
Chapter 2. Installation and set up
This chapter describes the installation and setup tasks needed to have BW
up and running. It lists the tasks and provide some hints on how to approach
the installation of BW on the AS/400 server. Since this chapter does not
describe every installation step in detail, it should serve as a reference rather
than a detailed installation guide. For a detailed description of the installation
and setup tasks, please refer to the BW installation guide (scheduled to be
published in summer 1999) and in SAP OSS notes.
The installation procedure of BW is similar to the installation of SAP R/3.

Please refer to the ITSO redbook SAP R/3 Implementation for AS/400,
SG24-4672, for more information on SAP R/3 installation.
2.1 Prerequisites
To successfully set up BW on the AS/400 system, you need to have following
prerequisites:
• Hardware
– Server: AS/400 server with PowerPC technology. Chapter 6, “Sizing
considerations” on page 87, provides preliminary sizing guidelines.
– Workstation: A PC with a minimum of 48 MB of main memory on
Windows 95, 64 MB on Windows NT, and 1 GB disk space. To work
comfortably with BW, we recommend that you double the memory size.
• Software
– Server:
• OS/400 V4R4 with TCP/IP installed. It is technically possible to run
BW on OS/400 V4R3. However, we do not recommend it since it is
not supported by IBM and SAP.
• AS/400 PTFs listed in IBM APAR number II11832 (for V4R4) or
number II11296 (for V4R3).
• SAP Business Information Warehouse release 1.2B installation CDs
with documentation.
• BW patches specified in SAP OSS note 0149750.
• OS/400 optional, chargeable feature "DB2 Symmetric
Multiprocessing for OS/400" is highly recommended.

– Workstation:
• Windows 95 or Windows NT installed
• BW front-end installation CD that comes with BW
• Microsoft Excel or Lotus 1-2-3 installed
In addition, a good knowledge of the SAP R/3 basic technology and OS/400
is very helpful.
2.2 Installation
First, install the BW front-end to the administrator’s PC from the installation
CD. BW front-end installation is described in detail in the brochure Frontend
Installation (Mat. No. 5100 3943). Install all program temporary fixes (PTFs)
on the AS/400 system as recommended in IBM Information APAR for your
OS/400 release. You can get this APAR in AS/400 APAR database on the
Internet at: http://www.as400.ibm.com/service/bms/support.htm
You can install BW to AS/400 system in one of two ways:

• From a PC attached to the AS/400 server: There has to be a TCP/IP
connection configured between the PC and the AS/400 server. This
installation is performed from the SAP front-end.
• Directly on the AS/400 system: This installation is performed from an
AS/400 display. To install BW, follow these steps from the AS/400 display:
1. Sign on to AS/400 system with user profile QSECOFR. Perform the
necessary changes in AS/400 system settings as described in the SAP
BW Installation Guide.
2. Insert the installation CD into the AS/400 CD-ROM drive. Load the
installation objects using the Load and Run ( LODRUN) command as
shown in Figure 2 on page 9.

Command Entry RCHASR7D
Request level: 4
Previous commands and messages:
(No previous commands or messages)
Bottom
Type command, press Enter.
===> lodrun *opt dir('/os400/as400/install')
F3=Exit F4=Prompt F9=Retrieve F10=Include detailed messages

F11=Displayfull F12=Cancel F13=InformationAssistant F24=More keys
Figure 2. Loading BW installation files to the AS/400 system
This command creates library R3SETUP on your AS/400 system and

adds it to your library list. When loading is finished, you get the R/3
Installation menu on your screen.
3. Select option 1 to copy the installation files from the CD to the AS/400
system (Figure 3 on page 10).
Installation and set up 9

R3SETUP R/3 Installation
System: RCHASR7D
Select one of the following:
1. Copy Installation Files from CD

2. Install R/3 Systems and Instances
3. Work with SAP license information
4. Change the location of the /usr/sap/trans directory
5. Load RFC SDK library
6. Load CPI-C SDK library
8. Display R/3 System configuration

9. Create R/3 System objects
10. Delete R/3 System objects
11. Create R/3 Instance objects
12. Delete R/3 Instance objects
Selection or command
===> 1
F3=Exit F4=Prompt F9=Retrieve F12=Cancel
Figure 3. R/3 installation menu
Press Enter. Then, you are prompted for the SAP System ID (SID) that
you want to install. After doing so, the directory /tmp/<sid> where the
installation files will be copied is created. <sid> is the SID that you
specified.
4. Install the BW central instance with a database by selecting option 2 on
the R/3 Installation menu. Then, specify the installation file name or file
names in case you are installing a three-tier environment. If you are
installing a two-tier environment, specify the file CENDBBW.R3S. If you are
installing a three-tier environment, specify the file CENTRAL.R3S and then
the file DBBW.R3S. This task may take several hours.
5. Install all BW patches specified in SAP OSS note 0149750. Download
the patches to your PC in one of two ways:
• From the SAPNet Internet home page at http://sapnet.sap.com
You need to have a user ID provided by SAP to logon to SAPNet.
• From the SAP service system by logging on to SAP system CSS
from the SAP front-end.
To install the BW patches, complete these steps:
a. Transfer patches from your PC to the AS/400 server in the directory
/usr/sap/trans. You can use any file transfer method (FTP, for

example) as long as you transfer the patches in binary format. The
patches are in compressed files with the file extension CAR.
b. On the AS/400 screen, change your current directory to a directory
that contains compressed patches by using the command:
cd '/usr/sap/trans'
c. Decompress (unpack) the patches using the SAP command CAR as
shown in Figure 4.
Work with Object Links
Directory . . . . : /usr/sap/trans
Type options, press Enter.

3=Copy 4=Remove 5=Next level 7=Rename 8=Display attributes
11=Change current directory ...
Opt Object link Type Attribute Text

sapnames DIR
tmp DIR
EPS DIR
KW12b03.CAR STMF
KW12A02.CAR STMF
KW12B01.CAR STMF
KW12B02.CAR STMF
KW12B04.CAR STMF
KW12B05.CAR STMF
Bottom
Parameters or command
===> r3setup/car '-xvf /usr/sap/trans/KW12B01.CAR'
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F12=Cancel F17=Position to
F22=Display entire field F23=More options
Figure 4. Unpacking the patches
In this example, KW12B01.CAR is one of the patches.

d. Apply the patches from the SAP front-end using the SAP Patch
Manager (SPAM). Make sure you are logged on to client 000 with a
user that is authorized to apply patches (for example, user DDIC).
Start SPAM with SAP transaction /nspam. Follow the regular
procedure for applying the SAP R/3 patches. Always apply only one
patch at a time. Applying the patches may take several hours.
6. Make a BW client copy, since none of the SAP supplied clients can
work with BW. Please refer to SAP OSS note AS/400: Client Copy,
0049023, for a detailed description on how to make a client copy on the
AS/400 system.

2.2.1 Installing the BW Extractor
You start using BW by loading the data warehouse with operational data from
your source system. If the source system runs SAP R/3, use the BW feature
Extractor for data loading (see 4.2, “Loading the SAP R/3 data” on page 44).
In this case, you need to start the installation of the Extractor on the SAP
central instance. The Extractor is provided on one of the BW installation CDs.
Please refer to the R/3 Add-On Installation and Upgrade Guide (comes with
the software) for details on how to prepare and perform the installation of the
Extractor. Note these tasks:
1. When loading the Extractor files from the installation CD to the AS/400
disk, use the following command:
LODRUN *OPT DIR('/40B_INST/OS400/AS400')
The DIR parameter specifies the directory name where the installation
files are located. The first three characters in the directory name reflect
the R/3 release on the database server. In this example, the database
server is on R/3 release 4.0B. Therefore, the directory name is 40B_INST.
2. On the next screen, you are prompted to change the current directory.
Change it to a directory that contains the installation files as shown in
Figure 5.
Change Current Directory (CD)
Type choices, press Enter.
Directory . . . . . . . . . . . '/QOPT/CD51005919/40B_INST/OS400/AS400'
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Figure 5. Change the installation files directory
3. Proceed according to installation instructions. When you are prompted for

the Server Operation mode, select Scroll.

2.2.2 Objects created during the BW installation
The installation and setup procedures create several libraries that you can
recognize by the characters R3 in the first two positions of a library name.
Table 2 provides a list of these libraries with the number of objects and size.
Table 2. Libraries created during the installation of BW
Library name Content Number of Initial size

objects in MB
R3<SID><xxxxx>1 SQL packages (several libraries) 927 181
R3<SID>DATA BW database with tables, views, 4949 2488

indexes, journal, program
sources, and compiled modules
R3<SID>JRN Journal receivers 1 1.3
R3<SID>400 Work management objects 6 82

(subsystem descriptions,
classes...)
R3400 Global objects (output queues, 17 64

data queues, user spaces...)
R3<REL>OPT2 SAP kernel with executable code 450 327
R3WRKxx SAP instance specific objects, for 0 0

example user spaces
R3SYS Library for QSYS objects 2 0.1
R3SETUP Objects required for installation 83 82
Total 6435 3144
Notes:
1
<SID> is System ID. < xxxxx> is a combination of characters and numbers. For
example, a library name can be R3BWAA1980.
2
<REL> is R/3 kernel release.
In addition to the libraries, the following directory trees are created in the
integrated file system (IFS):
• /usr/sap/
• /sapmnt/
These IFS directories contain documents that are not stored in the BW
database, for example, spooled files or transports.

2.3 System landscape
The SAP recommended BW landscape consists of three BW systems:
• Test system (also called Development system or Sandbox) for testing and
application development
• Integration system for integration of Test system with Production system
(also called Consolidation system or Quality Assurance system)
• Production system
You can run two (or even all three) BW systems on one AS/400 machine. Or,
you may decide to install each BW system on a separate machine.
2.3.1 Multiple BW systems on one AS/400 system

If you decide to install more than one SAP BW or R/3 system on a single
AS/400 system (we will call it a machine), you have several options to isolate
one SAP system from other SAP systems and other AS/400 applications:
• Allocate separate memory space using memory pools.
• Allocate separate disk space using auxiliary storage pools (ASPs) with
dedicated I/O processors and a system bus.
• Use OS/400 logical partitioning.
When using multiple SAP systems on one machine, you also have to
consider potential performance impacts of one system on the other. Each
SAP system requires resources to run (CPU, disk, main memory). Certain
operations can cause heavy loads in one or more resource type.
2.3.1.1 Memory
Each SAP BW or R/3 system runs in its own OS/400 subsystem. Each
OS/400 subsystem runs in the OS/400 memory pool. The SAP system
typically runs in the *BASE memory pool, since it is usually the largest pool.
Multiple SAP systems can be set to all run in the same memory pool (shared
memory pool) or to run in separate memory pools. If they are sharing a
memory pool, they are contending equally for the same resources. An SAP
system that runs in a separate memory pool does not have other systems
contending for its memory. Therefore, it will perform better, providing that the
size of its memory pool is large enough.
The size of the memory pool can be either fixed or dynamically adjusted by
the AS/400 system. This is defined by the system value Performance
Adjustment (QPFRADJ). If QPFRADJ is set to the value "0", and SAP

systems use separate memory pools, you can allocate a specific amount of
memory to each memory pool. The allocated memory is not available to
subsystems that run outside that memory pool. The memory pool sizes are
static. You can set memory pool sizes using the OS/400 command Work with
System Status (WRKSYSSTS) as shown in Figure 6.
Work with System Status RCHASR7D

07/26/99 17:00:19
% CPU used . . . . . . . : 2.8 Auxiliary storage:
Elapsed time . . . . . . : 04:55:37 System ASP . . . . . . : 134.4 G
Jobs in system . . . . . : 2950 % system ASP used . . : 75.0605
% addresses used: Total . . . . . . . . : 163.7 G
Permanent . . . . . . : .033 Current unprotect used : 2399 M
Temporary . . . . . . : 1.245 Maximum unprotect . . : 2631 M
Type changes (if allowed), press Enter.
System Pool Reserved Max -----DB----- ---Non-DB---

Pool Size (K) Size (K) Active Fault Pages Fault Pages
1 102768 67084 +++++ .0 .0 .7 .8
2 880476 1484 187 .0 .1 .6 3.5
3 10484 0 6 .0 .0 .0 .0
4 54848 20 61 .0 .0 .4 .6
Bottom
Command
===>
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Restart
F11=Display transition data F12=Cancel F24=More keys
Figure 6. WRKSYSSTS — Allocating memory pool size
If the system value QPFRADJ is set to the value "2", OS/400 performs
automated dynamic performance tuning, which includes periodical
adjustments of memory pools sizes. This dynamic tuning checks the paging
rates and adjusts memory pool sizes to reduce paging. For example, if
memory pool X has a lot of paging, and pool Y has little paging, OS/400 will
move some memory from pool Y to pool X. In case there are several pools
that need more memory, the memory is allocated to the pool with a higher
priority as defined in the memory pool description. Use the OS/400 command
Work with Shared Pools ( WRKSHRPOOL) to set priorities on the memory pools as

Work with Shared Pools
System: RCHASR7D
Main storage size (K) . : 1048576
Type changes (if allowed), press Enter.
-----Size %----- -----Faults/Second------

Pool Priority Minimum Maximum Minimum Thread Maximum
*MACHINE 1 9.04 100 10.00 .00 10.00
*BASE 1 4.99 100 10.00 2.00 100
*INTERACT 2 10.00 100 5.00 .50 200
*SPOOL 2 1.00 100 5.00 1.00 100
*SHRPOOL1 2 1.00 100 10.00 2.00 100
*SHRPOOL2 2 1.00 100 10.00 2.00 100
*SHRPOOL3 2 1.00 100 10.00 2.00 100
*SHRPOOL4 2 1.00 100 10.00 2.00 100
*SHRPOOL5 2 1.00 100 10.00 2.00 100
*SHRPOOL6 2 1.00 100 10.00 2.00 100
More...
Command
===>
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F11=Display text
F12=Cancel
Figure 7. WRKSHRPOOL — Memory pool priority
The WRKSHRPOOL command is also used to protect the SAP system that
runs in the lower priority pool from losing so much memory that it can no
longer function. This is defined by setting the minimum percentage of total
memory for a pool (Figure 7).
Recommendation
Set the most performance-critical BW system (for example, production
system) to run in the *BASE pool and other systems in shared memory
pools. Set the paging option of all memory pools in which SAP systems are
running to *CALC. Set the system value QPFRADJ to 2. Set the priority of
*BASE pool to 1 and the priority of other pools with SAP systems to 2 or
lower.
When ending the BW, consider ending the OS/400 subsystem as well. This
releases the memory allocated to that subsystem. If only BW is in the
memory pool, then you should also end the subsystem. You can do this using
the STOPSAP command with the parameter "End subsystem" set to *YES (the
default value is *NO) and the parameter "Wait for instance to end" set to
*YES. Figure 8 on page 17 shows an example of the STOPSAP command.

Stop R/3 System (STOPSAP)
SAP system ID . . . . . . . . . *ENV Character value, *ENV

R/3 instance . . . . . . . . . . *ENV Character value, *ENV, *ALL
R/3 instance hostname . . . . . *LOCAL Character value, *LOCAL, *ALL
Wait for instance to end . . . . *YES *NO, *YES
Maximum wait time (seconds) . . 120 10-999999
End subsystem . . . . . . . . . *YES *NO, *YES
Bottom
F24=More keys
Figure 8. STOPSAP — Stop R/3 system with ENDSBS option
2.3.1.2 CPU
Processors are not allocated to OS/400 subsystems or SAP systems. They
are always shared across all jobs running on the same AS/400 system (or a
logical partition as described in the next section). However, CPU priority and
time slices can be managed at the subsystem level. This way you can always
allocate to the most important SAP system (for example, production system)
quicker access to the CPU and larger portion of the CPU time. In addition,
you can also manage them within the SAP system so that interactive and
batch BW processes in one BW system are running at different priorities.
2.3.1.3 Disk
Auxiliary storage pools (ASPs) can be used to separate disk resources for
different SAP systems. You may assign a separate ASP to each SAP system.
These ASPs can be grouped on their own IOP for further granularity. A
separate ASP will protect users of SAP system X, for example, from
performance impact of high disk arm activity produced by users of SAP
system Y. However, this approach is generally not recommended. An
increased number of ASPs reduces the number of disk arms in each ASP,
which will, in most customer situations, reduce the performance of all SAP
systems.

Recommendation
Use one ASP for all SAP systems and another ASP for journal receivers.
2.3.2 OS/400 Logical Partitioning (LPAR)

In all examples mentioned in previous section, all SAP systems run in a
single copy of the Operating System/400. They also share the same CPU (or
CPUs on N-way machine) with all other users of the machine. Sometimes this
is not a feasible environment, especially when you:
• Want to run BW systems on different releases of operating system (for
example, for testing purposes)
• Need to have BW systems with different system settings (for example,
different time zones, languages, and so on)
• Need dedicated CPU power for each BW system to get high performance
• Have high availability demands
• Have high security demands
In such cases, the AS/400 feature Logical Partitioning (LPAR) may help.
LPAR overcomes these limitations by allowing you to install several copies of
the operating system (even with different releases) on a single AS/400
machine. LPAR divides an AS/400 machine into two or more logical
partitions. A logical partition is a virtually independent system with its own
CPU (or CPUs), main memory, system bus (or buses), I/O processors, disks,
a copy of OS/400, and all application software. The maximum number of
logical partitions on one machine is equal to number of available CPUs.
Please refer to the redbook Slicing the AS/400 with Logical Partitioning: A
How to Guide, SG24-5439, for more information on LPAR.
2.3.3 System landscape examples

With or without using LPAR, the BW landscape may be integrated with SAP
R/3 (or another OLTP system) on the same AS/400 machine. Consider the
following examples:
• The BW test system and Integration system run on one machine (or
LPAR). The production system runs on a second machine (or LPAR) as

Figure 9. Landscape 1
• SAP R/3 and BW both run on the same machine. The R/3 production
system runs in one LPAR, and the BW production system runs in a second
LPAR. The rationale behind this scenario is improved performance of
loading the BW with R/3 data (Figure 10).
• SAP R/3 system runs in one LPAR. BW test system and BW integration
system both run in a second LPAR. BW production system runs on a
second machine or a third LPAR on the same machine as shown in Figure
11 on page 20.

• The plain BW test system and BW integration system run in one LPAR.
The SAP R/3 test system and the SAP R/3 integration system both run in a
second LPAR. The BW production system runs on a second machine (or a
third LPAR) as shown in Figure 12.

In a similar way, you may decide to choose other combinations. However,
make sure that the BW and the R/3 production systems are never in the same
LPAR. The decision criteria depends on the amount of workload in each
system, performance requirements, backup and recovery policy, system
management tasks, and costs among others. Please refer to sizing guidelines
in Chapter 6, “Sizing considerations” on page 87, for more information on
sizing.

Chapter 3. Backup and recovery
Immediately after the BW is in production, there should be a backup and

recovery policy in place. While workstations have to be backed up only
occasionally (after all workstation software is installed or upgraded), most of
the backup activities are done on the server side. Objects that should be
backed up include the database library that holds BW data and the program
source code, sequential objects in IFS, journal receivers, and SQL packages.
An example of a backup policy is summarized in Table 3.
Table 3. Backup activities
What to backup When How
BW system with database, Daily Command

configuration, and access SAVR3SYS
paths
BW journal receivers in Continuously Commands

library R3<SID>JRN SAVDLTRCV and
SAVDLTRCVE
Entire AS/400 system After: Menu SAVE,

- installing and upgrading OS/400 option 21.
- installing AS/400 PTFs
- installing and upgrading BW
- installing BW patches
3.1 BW system
The BW system can be backed up with the OS/400 command Save R/3
System (SAVR3SYS). With this command, you may save the entire BW
system (except of the SAP kernel library) or only a part of it, depending on
how you specify the parameters of this command. Figure 13 on page 24
shows how to save a BW system with a BW database, configurations
(libraries R3400 and R3<SID>400), and SQL packages.

Save R/3 System (SAVR3SYS)
System ID . . . . . . . . . . . > BWA Character value

Device . . . . . . . . . . . . . /QSYS.LIB/TAP01.DEVD
Prompt save commands . . . . . . *NO *YES, *NO
R/3 status during save . . . . . *DSCDB *DSCDB, *RUN, *END
IFS files to save:
Path name . . . . . . . . . . *SPTH
Include or omit . . . . . . . *INCLUDE, *OMIT

+ for more values
Save R/3 database . . . . . . . *YES *YES, *NO
Save R/3 configuration . . . . . > *YES *YES, *NO
Save R/3 SQL packages . . . . . > *YES *YES, *NO
Save reference date . . . . . . *ALL Date, *ALL, *LASTSAVE
Save reference time . . . . . . *ALL Time, *ALL, *LASTSAVE
Expiration date . . . . . . . . *PERM Date, *PERM
Save active wait time . . . . . 1200 Number, *NOMAX
More...
F24=More keys
Figure 13. Save R/3 System (SAVR3SYS)
Use the SAVR3SYS command when there are no active users on the system, for
example, at night after the BW is reloaded with data from an OLTP system.
Please refer to the SAP OSS note 86305 for information on how to obtain the
SAVR3SYS command.
3.2 Journal receivers

BW journal receivers can be saved by using two OS/400 commands:
• Save and Delete Receivers (SAVDLTRCV) command
• Stop Save and Delete Receivers (SAVDLTRCVE) command
The SAVDLTRCV command continuously monitors the status of the BW

journal receivers and backs them up after they are detached from the BW
journal. The AS/400 system detaches the BW journal receiver when it
reaches a certain size. This is defined at the creation of the BW journal
(QSQJRN in library R3<SID>DATA) with the attribute "Manage receivers" and
the attribute "Receiver size options". When the old receiver is detached, the
system automatically creates a new receiver, attaches it to the journal, and
sends a message to the message queue that you need to create for this
purpose. The SAVDLTRCV command gets a message that the journal
receiver was detached and saves the old receiver.

The following sequence of events occurs:
1. Download the SAVDLTRCV save file from the SAPSERVx using the same
procedure as for downloading SAP patches. The save file is located in the
directory /general/R3server/patches/COMMON/OS400.
2. Create the SAVDLTRCV and SAVDLTRCVE commands, which are stored
in the save file. Please refer to SAP OSS note 82079 for information on
how to create these two commands.
3. Make sure that the BW journal receivers are managed by the AS/400
system. Use the Work with Journal Attributes ( WRKJRNA) command to check
if the attribute "Manage receivers" is set to *SYSTEM. If it is not, then
change it using the Change Journal ( CHGJRN) command.
WRKJRNA JRN(R3BWA400/QSQJRN)
BWA in the library name R3BWA400 indicates the SAP system ID.
4. Create the message queue for the SAVDLTRCV command:
CRTMSGQ MSGQ(R3BWA400/SAVDLTRCV)
5. Grant user R3OWNER authority to this message queue using the AS/400
Grant Object Authority ( GRTOBJAUT) command:
GRTOBJAUTOBJ(R3BWA400/SAVDLTRCV)OBJTYPE(*MSGQ)USER(R3OWNER)AUT(*ALL)
6. Associate the new message queue with the BW journal by using Change
Journal (CHGJRN) command:
CHGJRN (R3BWADATA/QSQJRN) MSGQ(R3BWA400/SAVDLTRCV)
7. Submit a batch job that will start the SAVDLTRCV command by using the
Submit Job ( SBMJOB) command as shown in Figure 14 on page 26.
Backup and recovery 25

Submit Job (SBMJOB)
Command to run . . . . . . . . . > SAVDLTRCV MSGQ(R3BWA400/SAVDLTRCV) DEV(TAP

01)
...
Job name . . . . . . . . . . . . SAVDLTRCV Name, *JOBD
Job description . . . . . . . . *USRPRF Name, *USRPRF
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Job queue . . . . . . . . . . . *JOBD Name, *JOBD
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Job priority (on JOBQ) . . . . . *JOBD 1-9, *JOBD
Output priority (on OUTQ) . . . *JOBD 1-9, *JOBD
Print device . . . . . . . . . . *CURRENT Name, *CURRENT, *USRPRF...
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Figure 14. SBMJOB — Start SAVDLTRCV command
After the job is submitted, the SAVDLTRCV command will be active all the
time waiting for a message as shown in Figure 15 on page 27.

Work with Active Jobs TSCSAP02
07/21/99 14:17:10
CPU %: 1.1 Elapsed time: 00:00:02 Active jobs: 164

2=Change 3=Hold 4=End 5=Work with 6=Release 7=Display message
8=Work with spooled files 13=Disconnect ...
Opt Subsystem/Job User Type CPU % Function Status

QBATCH QSYS SBS .0 DEQW
SAVDLTRCV BWAOFR BCH .0 CMD-SAVDLTRCV MSGW
QCMN QSYS SBS .0 DEQW
QCTL QSYS SBS .0 DEQW
QSYSSCD QPGMR BCH .0 PGM-QEZSCNEP EVTW
QINTER QSYS SBS .0 DEQW
QPADEV0026 H41OFR INT .9 CMD-WRKACTJOB RUN
QSERVER QSYS SBS .0 DEQW
QPWFSERVSD QUSER BCH .0 SELW
More...
===>
F3=Exit F5=Refresh F7=Find F10=Restart statistics
F11=Display elapsed data F12=Cancel F23=More options F24=More keys
Figure 15. WRKACTJOB — SAVDLTRCV command
The SAVDLTRCV should only be stopped during the execution of the

SAVR3SYS command. You can stop it by running the SAVDLTRCVE command
before you run the SAVR3SYS command:
SAVDLTRCVE MSGQ(R3BWA400/SAVDLTRCV)
After SAVR3SYS is completed, start the SAVDLTRCV job again.
3.3 Saving the entire AS/400 system

Please refer to redbook SAP R/3 Implementation for AS/400, SG24-4672, for
a description on how to save the entire AS/400 system.
Backup and recovery 27

Chapter 4. Loading the BW with data
This chapter describes two methods of loading a BW InfoCube with

operational data from an OLTP system. The method you choose depends on
whether your OLTP system is SAP R/3. If your OLTP system is SAP R/3, use
the method described in 4.2, “Loading the SAP R/3 data” on page 44. In any
other case, consider using the method described in the following section.
4.1 Loading the AS/400 legacy application data

BW provides two interfaces that used to load InfoCubes with non-SAP data:
• File interface
• Business application programming interface (BAPI)
The file interface handles the importing of transaction data and master data
into the Staging Engine in a flat file format. The flat file can be either in ASCII
or Microsoft Excel (CSV) format. The file interface requires manual
maintenance of meta data in BW. Therefore, SAP recommends that you use
this interface only in cases where the source data is already defined in a file
format or when a quick solution is desired. We provide an example of using
the file interface in the following section.
The BAPI interface allows the importing of transaction data, master data, and
meta data from the source system in an automated, repeatable way that
allows dynamic selections. See the description of the BAPI interface in 4.1.2,
“Business application programming interface” on page 43.
4.1.1 File interface — An example

In this section, we show an example of how to transfer the operational data
from an AS/400 legacy application into the BW InfoCube using the file
interface. In a real-life environment, this is a long process that requires
careful planning. It is documented in many data warehousing books. Our
example is deliberately simple to give a clear view of the thought process,
which consists of these steps:
1. Identify tables on the source system that belong to the legacy application.
To maximize the usage of the data warehouse, we need to understand
several elements about the operational data first:
• Where and in what format it is stored
• The information it contains

• The business value of this information for data warehouse users
• The kind of modifications it needs and how these modifications will be
done before the data is transferred into the BW
2. Design and create an InfoCube (or InfoCubes) on the target system.
Before creating an InfoCube, decide:
• The purpose that this InfoCube will serve
• The type of information that the end-users will request from the
InfoCube
• The criteria for data grouping, summarizing, drill down, and so on
• The data that will be in the master and transaction tables, fact tables,
and dimension tables
• The data that will be defined as characteristics, key figures, and
navigation attributes
3. Prepare the source data for loading into BW. This includes:
• Changing and adding some columns in source tables to suit the
business analysis purposes of the InfoCube.
• Converting the source tables into the ASCII or CSV format. In our
example, we converted them into the CSV format.
4. Load the InfoCube with data from the source tables.
Note: Steps one and two are done synchronously.
4.1.1.1 Identifying the source tables

This section describes the source data in our example. Figure 16 on page 31
shows the design of the source system database. This database contains
sales data about customers and parts. For the sake of simplicity, not all
columns are shown in Figure 16 on page 31.

Trans
Customer Key Customer

Part Key
Customer key
Part Order Date
Customer name
Quantity Country
Part Key
Cost Region
Part Name
Currency Address
Figure 16. Source database design
The source database consists of three tables: one transaction data table
(Trans) and two master data tables (Part and Customer).
The transaction data table contains quantity, cost, and time information about
parts and customers. Its structure is shown in Table 4.
Table 4. Table Trans
Field Data Field Description Default

type length value
ORDERKEY PACKED 16,0 Order number None
QUANTITY PACKED 15,2 Quantity None
SUPPLYCOST PACKED 15,2 Cost None
PARTKEY BINARY 9,0 Part number None
CUSTKEY BINARY 9,0 Customer number None
ORDERDATE DATE *ISO 10 Order date None
UNITS CHAR 2 Units EA
CURRENCY CHAR 3 Currency USD
Loading the BW with data 31

The master data tables contain descriptive information about parts (Table 5)
and customers (Table 6).
Table 5. Table Part
Field Data type Field length Column heading
PARTKEY BINARY 9,0 Part number
PART CHAR 32 Part name
Table 6. Table Customer
Field Data type Field length Column heading
CUSTKEY BINARY 9,0 Customer number
CUSTOMER CHAR 25 Customer name
COUNTRY CHAR 25 Country
REGION CHAR 25 Region
ADDRESS CHAR 32 Address
All default values for both master tables are none.
4.1.1.2 Design of the InfoCube

This section describes data structures defined in the InfoCube. BW includes
pre-defined structures that must be activated before they can be used.
However, we chose to define our own InfoObjects, InfoCubes, and
InfoSources. The InfoCube in this example is designed to help answer
questions such as:
• What are the sales trends by region?
• What parts are in greatest demand?
• Who are the best customers based on the number of parts sold and the
total revenue?
After we determine the purpose that this InfoCube will serve, we design and
create the InfoCube named SOCUBE with the following structure:
• InfoObjects defined as characteristics:
– Part number
– Customer number
– Date
– Currency

– Part name
– Customer name
– Country
– Region
– Address
• InfoObjects defined as key figures:
– Order cost
– Order quantity
• Five dimensions: part, customer, time, unit and data packet.
• Dimension Part contains the part number, which is defined as master data
and has a part name attribute.
• Dimension Customer contains the date and customer number. The
customer number is defined as master data. Customer name, country,
region, and address are assigned to customer master data.
• Dimension Time contains the BW pre-defined objects of calendar day,
calendar month, calendar quarter, and calendar year. We use them when
analyzing date-related information.
• Dimension Unit contains currency.
• Country and Region are defined as our navigation attributes. This means
that the drill-down function of the queries can operate on these two fields.
Figure 17 on page 34 presents a data model of SOCUBE created using the

SAP transaction RSA1. Figure 18 on page 35 presents an expanded view of
the Part and Customer dimensions.

Figure 17. SOCUBE data model

Figure 18. SOCUBE data model expanded view
Figure 19 on page 36 shows the table relationships of the SOCUBE. For

simplicity sake, this figure includes only dimensions customer and part, while
dimensions time and unit are not shown. The time and unit dimensions also
have a dimension table, SID table, and master data table. The relationships
of the time and unit dimensions to the fact table and to each other are the
same as those depicted for the customer and part dimensions.

Fact Table
Customer Dimension Part Dimension
File:/BIC/FSOCUBE
File:/BIC/DSOCUBE1 Short:/BIC0059 File:/BIC/DSOCUBE2
Short:/BIC0055 Short:/BIC0057
DIMID Key_SOCUBEP DIMID

Key_SOCUBET SID_PARTNO
SID_CUNO
SID_0DATE Key_SOCUBEU
Key_SOCUBE1 Part SID Table
Customer SID Table
Filename:/BIC/SCUNO
Filenm:/BIC/SPARTNO
Key_SOCUBE2
Short Name:/BIC0036
Short Name:/BIC0044
ORDCOST
PARTNO
CUNO ORDQTY SID
SID
CHCKFL CHCKFL
DATAFL DATAFL
Customer Master
INCFL Filenm:/BIC/MCUNO INCFL
Short Name:/BIC0035 Part Master Table
Filenm:/BIC/MPARTNO
Short Name:/BIC0043
CUNO
OBJVERS
PARTNO
CHANGED OBJVERS
CUSTNM CHANGED
COUNTRY PARTNM
REGION
ADDRESS
Figure 19. SOCUBE tables — Partial view
4.1.1.3 Preparing the source tables

The BW Staging Engine accepts only ASCII or CSV files as input in data
loading. Therefore, the AS/400 DB2 tables need to be converted into the
appropriate format before loading. We show two different ways to convert the
tables and prepare them for loading:
• Manual preparation using AS/400 commands
• Preparation with an RPG program
Manual preparation of source tables

Manual preparation of each source table is done in four steps using CL
commands. During these steps, each table is converted into three
intermediate tables with different forms, before finally converted into a CSV
file.

Figure 20 shows all the intermediate forms of the table Trans. It starts with the
original table (form 1) and ends with the last intermediate table (form 4) that
will be converted into a CSV file.
Quantity Cost Part Customer Order date Currency

Form 1:
Int Dec Char Char Date Char

Sep Sep Sep Sep Sep
Form 2:
Int Ch Dec Ch Char Ch Char Ch Date Ch Char

Sep Sep Sep Sep Sep
Form 3:
Char Ch Char Ch Char Ch Char Ch Char Ch Char
Sep Sep Sep Sep Sep

Form 4:
Character
Figure 20. Source table conversion forms
The first line of text for each form in Figure 20 describes the column name.
The second line graphically represents columns in a row. The third line
describes the column type.

The preparation steps are shown here:
1. Source table Trans (with form 1 in Figure 20 on page 37) is copied into a
new table Trans1 (form 2). Trans1 differs from Trans in these ways:
• New columns are added in Trans1 to provide drill-down possibilities for
BW queries.
• A separator column is added between each column.
First, the table Trans1 is created with structure shown in Appendix 15,
“Table Trans1” on page 91. The separator column has a value of ’;’.
Then, the CL command Copy File (CPYF), with the *MAP and *DROP
options (Figure 21), is used to copy the table from Form 1 into Form 2.
Copy File (CPYF)
From file . . . . . . . . . . . > TRANS Name

Library . . . . . . . . . . . > LEGACY Name, *LIBL, *CURLIB
To file . . . . . . . . . . . . > TRANS1 Name, *PRINT
From member . . . . . . . . . . *FIRST Name, generic*, *FIRST, *ALL
To member or label . . . . . . . *FIRST Name, *FIRST, *FROMMBR
Replace or add records . . . . . > *REPLACE *NONE, *ADD, *REPLACE...
Create file . . . . . . . . . . *NO *NO, *YES
Print format . . . . . . . . . . *CHAR *CHAR, *HEX
Additional Parameters
Record format field mapping . . > *MAP *NONE, *NOCHK, *CVTSRC...

> *DROP
Bottom
Figure 21. CPYF from form 1 to form 2
2. All columns that are not of character type are converted into character
type.
Table Transch (form 3) is created with all columns type character. The
description of Transch is in Table 16 on page 92.
Then, an SQL INSERT command (Figure 22 on page 39) is used with the
CHAR and SUBSTR functions to copy the data from form 2 to form 3. You
can run the SQL INSERT command from the SQL Utility screen that you
get after running the OS/400 command SQL Utility (SQLUTIL). SQLUTIL

is a part of a tools set "AS/400 Tools for the Integrated File System" that
can be downloaded from Internet at:
http://www.as400.ibm.com/service/bms/ifstools-d.html
You can also get QGPTOOLS by ordering PTF number SF55871.
INSERT INTO LEGACY/TRANSCH

(CUSTKEY, LIM1, COST, LIM2, QUANTITY,
LIM3, PARTKEY, LIM4, CURRENCY, LIM5, ORDERDATE, LIM6, ORDERDATE1,
LIM7, CALMON, LIM8, QUARTER, LIM9, YEARFLD, LIM10)
SELECT
char(custkey), lim1, char(supplycost), lim2, char(quantity), lim3,
char(partkey), lim4, currency, lim5, orderdate, lim6, orderdat1,
lim7, calmon, lim8, quarter, lim9, yearfld, lim10
FROM legacy/trans1
Figure 22. Sample SQL — Convert form 2 into form 3
Navigation attributes and master data that is associated with SID tables
must be converted to upper-case characters. This is done using the SQL
UPPER function.
3. The number of all columns in a row is reduced from six to one.
Table Charfile (form 4) is created with a single column, type character, and
length of 82 (long enough to hold all the columns of Transch). The Create
Physical File (CRTPF) command is used to create this table (Figure 23 on
page 40). Then, the CPYF command with the *NOCHK parameter is used
to copy the data from form 3 to form 4 (Figure 24 on page 40).

Create Physical File (CRTPF)
File . . . . . . . . . . . . . . charfile Name

Library . . . . . . . . . . . legacy Name, *CURLIB
Source file . . . . . . . . . . QDDSSRC Name
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
Source member . . . . . . . . . *FILE Name, *FILE
Record length, if no DDS . . . . 82 Number
Generation severity level . . . 20 0-30
Flagging severity level . . . . 0 0-30
File type . . . . . . . . . . . *DATA *DATA, *SRC
Member, if desired . . . . . . . *FILE Name, *FILE, *NONE
Text 'description' . . . . . . . *SRCMBRTXT
Bottom
Figure 23. CRTPF — Create intermediate table (form 4)
Copy File (CPYF)
From file . . . . . . . . . . . > TRANSCH Name

To file . . . . . . . . . . . . > CHARFILE Name, *PRINT
From member . . . . . . . . . . *FIRST Name, generic*, *FIRST, *ALL
To member or label . . . . . . . *FIRST Name, *FIRST, *FROMMBR
Replace or add records . . . . . > *ADD *NONE, *ADD, *REPLACE...
Create file . . . . . . . . . . *NO *NO, *YES
Print format . . . . . . . . . . *CHAR *CHAR, *HEX
Additional Parameters
Record format field mapping . . > *NOCHK *NONE, *NOCHK, *CVTSRC...
Bottom
Figure 24. CPYF — Copy table to a single-column form
The table is converted into the flat file.

The Copy To Stream File (CPYTOSTMF) command in Figure 25 is used to
copy the data from the single-column table Charfile (Form 4) into the flat
file in CSV format.
Copy To Stream File (CPYTOSTMF)
From database file member . . . > 'qsys.lib/legacy.lib/charfile.file/charfile.

mbr'
To stream file . . . . . . . . . > 'bw/trans.csv'
Stream file option . . . . . . . > *replace *NONE, *ADD, *REPLACE

Data conversion options . . . . *AUTO *AUTO, *TBL, *NONE
Database file CCSID . . . . . . *FILE 1-65533, *FILE
Stream file code page . . . . . *STMF 1-32767, *STMF, *PCASCII...
Bottom
F24=More keys
Figure 25. CPYTOSTMF — Copy table into a flat file
After repeating these three steps for all three source tables, we get three flat
files (PART.CSV, CUST.CSV, and TRANS.CSV.) that serve as the input for the
BW data loading function.
Preparation of source tables with a program

If you will often load your InfoCube from the same source tables, we
recommend that you prepare the source tables for loading with a program,
instead of doing this manually. In Appendix B, “RPG ILE preparation program”
on page 95, we provide an RPG code sample of such a program. This
program does all the steps described in “Manual preparation of source tables”
on page 36. File names and structures from our examples are coded in this
program.

4.1.1.4 Loading the InfoCube with data
Loading the InfoCube with file interface includes loading master data and
transaction data tables. The following sequence defines the loading steps at
a high level. For detailed information, please refer to the related BW
documentation.
1. The meta data is maintained manually in BW. The Maintain Meta Data
dialogue of the InfoSource is used to define the order of the InfoObjects,
which must correspond to the columns in the data files.
2. The communication structure is created and activated using the
InfoSource Maintain communication structure. The communication
structure is a staging area for the data after the transfer rules are applied
and before the InfoCube is loaded.
3. To establish and activate the transfer rules, use the InfoSource Maintain
Transfer rules. Transfer rules are applied to the data as it is loaded into
the communication structure.
4. Define and activate update rules with the InfoCube Maintain Update Rules
option. The update rules are applied to the data as it is moved from the
communication structure to the InfoCube.
5. Define the name of the flat file that will be loaded from the source system
to BW. Use the SAP transaction RSA1—> Infosource —> Maintain
InfoPackage Scheduler. Select the ExternData tab as shown in Figure
26 on page 43. This is where you spell out the name of the flat file to be
loaded. You also specify whether it is an ASCII or CSV file. In our example,
we load a CSV file.
6. To actually start the load, you need to use the transaction RSA1 —>
InfoSource —> Maintain InfoPackage Scheduler. Select the Schedule
tab.

Figure 26. Scheduler
For a detailed explanation of the communication and transfer structures,

update and transfer rules, please refer to the SAP documents Loading
InfoSource Data via Flat Files and Staging BAPIs for the SAP Business
Information Warehouse, which are available on SAPNet.
4.1.2 Business application programming interface

BW provides an open interface to the BW Staging Engine with business
application programming interfaces (BAPIs). The big advantage of BAPIs
over the file interface is that they allow the exchange of meta data between
the source system and the BW. There are two types of BAPIs:
• Meta Data BAPIs: These are methods used to load meta data into BW.
• Data BAPIs: These methods are used to load transaction data and master
data.
The BAPIs are provided for use for BW customers and third-party tool
providers. They can use the BAPIs and connect their meta data source
system and their extract engines to BW.

You can find more information about BAPIs in the following documents
available in the Open BAPI network at the SAP Web site at:
http://www.sap.com
• Staging BAPIs for the SAP Business Information Warehouse
• BAPI Introduction and Overview
• BAPI Programming
• Release Notes 4.0
• BAPI Java Class Library
• BAPI C++ Class Library
4.2 Loading the SAP R/3 data

The recommended method of loading BW with data from an SAP R/3 system
is by using BW Extractor. With this method, the BW sends a request for data
to the Extractor who gets data from the SAP R/3 database and sends it to
BW. A CD with Extractor installation program is included in a set of BW
installation CDs.
BW contains pre-defined InfoObjects, InfoCubes, and InfoSources. Extractor

loads the SAP R/3 data into these pre-defined structures. These pre-defined
structures must be activated in BW before loading. Using BW transactions,
you first upload meta data, then master data, and transaction data.
Please refer to the BW documentation for more detailed information on

loading SAP R/3 data into BW.

Chapter 5. Performance
This chapter describes how to analyze and improve the performance of BW

running on an AS/400 system. The redbook SAP R/3 Implementation for
AS/400, SG24-4672, extensively covers performance topics related to the
SAP R/3 applications on the AS/400 system. Most of the recommendations in
that redbook also apply to BW. However, in analyzing BW performance, keep
in mind that the performance behavior of an OLTP application, such as SAP
R/3, is much different from the behavior of a business intelligence application
using OLAP, such as BW (see Chapter 1, “Introduction” on page 1).
OLTP systems work with operational data stored in a highly normalized

relational database, designed for day-to-day business operations. OLTP
end-users handle thousands or millions of transactions per day and update
operational data frequently. OLTP end-users have a relatively short think
time, use simple transactions that update single records, and expect short
system response times that are ideally lower than one second.
OLAP systems work with informational data, which is summarized,

denormalized operational data. OLAP end-users typically work with long think
times and often use long-running queries with longer system response times
(sometimes minutes or even hours). Queries analyze and summarize data
that is stored in a data warehouse (sometimes called information warehouse,
business information warehouse, data mart, InfoCube and so on). This data
warehouse is loaded with operational data on a regular basis. It is organized
in structures that are optimized for data analysis, reporting, and exploration.
OLAP end users rarely update the data warehouse.
The differences between the OLTP and OLAP workload are summarized in
Table 7.
Table 7. OLTP versus OLAP workload
OLTP OLAP
Main business purpose Day-to-day operations Data analysis, reporting
Transactions Simple Complex
Data update Frequent, single records Seldom, many records
End-user think time Short Long

OLTP OLAP
System response time Short Long
Orientation Rows, columns Arrays (multidimensional)

(two-dimensional)
Data level Detail Aggregate
Requirements Well defined in advance Usually ad-hoc
Structure Static Flexible
Due to these differences, the performance behavior of BW is different from

the behavior of SAP R/3. This chapter analyzes the performance of three
typical BW workloads:
• Loading a BW InfoCube with operational data from an OLTP system
• Long-running BW query
• Administration — BW administrator’s work with InfoCubes, InfoObjects
and InfoSources
Simulating different scenarios, we ran the above three workloads in a test

environment, monitored the performance, and looked at the characteristics of
BW transactions. Then, we searched for primary bottlenecks and possibilities
for performance improvements.
5.1 Performance monitoring tools

The BW system includes a database that is optimized for BW and a kernel
that is identical to the SAP R/3 kernel. BW and the SAP R/3 use the same
basis infrastructure for executing the SAP jobs. This includes SAP profiles,
instances and work processes among others. For BW performance
monitoring, the same tools can be used as for SAP R/3 monitoring.
5.1.1 AS/400 system tools

Use the following OS/400 commands for a snapshot analysis of BW
performance on the system level:
• Work with Active Jobs (WRKACTJOB) to monitor CPU usage of the SAP
work processes.
• Work with Disk Status (WRKDSKSTS) to monitor I/O utilization.
• Work with System Status (WRKSYSSTS) to monitor memory page faults.

For more information on above two commands please refer to 6.4, "AS/400
System Monitoring" in the redbook SAP R/3 Implementation for AS/400,
SG24-4672.
5.1.2 BW tools
Use the following SAP tools for analyzing BW performance on the application
level:
• ST03 to get response times and resource usage information (summarized
as well as for single transactions).
• ST05 to trace the execution of SQL statements in SAP transactions.
• RSA1 to obtain SAP statistical records.
• BW Statistics to find out which queries, InfoCubes, InfoSources,
InfoObjects, source systems, aggregates and so on are currently being
used, and how frequently and who is currently using the system. It can
help you answer these questions: Are there queries whose runtime is over
the time allowed? Are batch jobs and printing executed in times of less
work? How does the data flow through the data warehouse?
For more information about BW Statistics, please refer to the SAP
document SAP BW Statistics, ASAP for BW Accelerator, Document
Version 1.0, which is available on SAPNet.
For more information about the SAP R/3 monitoring, please refer "7.1 SAP
R/3 Monitoring" in the redbook SAP R/3 Implementation for AS/400,
SG24-4672.
5.2 Tuning techniques

We recommend that you use the following techniques for tuning the
performance of BW system:
• OS/400 parallel processing. Most BW end-users gain performance
benefits by using this feature described in an example in 5.3, “BW and
OS/400 parallel processing” on page 48.
• BW parallel load function for mass data loading. This is described in
5.4.1.2, “SAP parallel load” on page 65.
• BW Index delete function improves performance of data loading. It is
described in 5.4.1.1, “Performance impact of indexes” on page 59.
Performance 47
• Creation of permanent indexes. Use it in situations where the same
temporary indexes are often built by the system as described in 5.4.2.2,
“Query performance analysis” on page 72.
• LPAR. Putting the BW and the source OLTP system on one AS/400
system into different LPARs will improve performance of BW data loading.
An example is shown in Figure 10 on page 19.
Table 8 summarizes the usage of these techniques.

Table 8. Effect of performance improvement techniques in BW
Technique Brings Possible trade-off

improvements to
AS/400 Symmetric Database queries, Needs additional

Multiprocessing index build, rebuild system resources
and maintenance
BW parallel load Mass data loading
BW "Index delete" Data loading of fact Decreases

function tables performance of delta
update
Create permanent Long-running Decreases

indexes queries performance of data
loading
LPAR Data loading Adds some overhead to

primary LPAR
5.3 BW and OS/400 parallel processing

The OS/400 provides several types of parallel processing:
• Parallel I/O: This is the ability of the AS/400 I/O subsystem to read and
write data from all disk arms in parallel. It is automatic with the system.
You cannot turn it off, nor would you want to turn it off.
• N-way processing: This is the ability of a multiprocessor system to
handle more than one job at a time. Each processor handles at least one
job, but one job is never handled by more than one processor (Figure 27
on page 49).

Figure 27. N-way processing
In Figure 27, eight CPUs work on several jobs at one time without any
special programming.
• SMP (Symmetric Multi-Processing): This is the ability of a
multiprocessor system to take one job, divide it up into tasks, and have
more than one processor work on that one job simultaneously (Figure 28).
Each processor gets to work on one or more tasks.
Figure 28. SMP processing
In Figure 28, all eight CPUs work on one job. The system automatically
divides the job into tasks.
Performance 49
• MPP (Massively Parallel Processing): This is also called shared nothing
parallelism. With MPP, several separate systems (nodes) are hooked
together using high-speed communications, such as OptiConnect. They also
use a database that can treat all the nodes as a single database image. MPP
is the main method of parallelism on UNIX systems, where many 1-way to
4-way nodes with relatively small amounts of attached DASD are connected
to create a large system. MPP is available on the AS/400 system through
DB2 Multisystem.
5.3.1 Symmetric Multiprocessing (SMP)

SMP may significantly improve the performance of BW jobs that:
• Perform long-running queries
• Build, rebuild or maintain indexes
SMP can only be used if the OS/400 optional feature "DB2 Symmetric
Multiprocessing for OS/400 (SMP)" is installed. To check if SMP is installed,
go to the OS/400 menu LICPGM. Select option 10 and search for the text
shown in bold in Figure 29.
Display Installed Licensed Programs

System: AS0023
Licensed Installed
Program Status Description
5769SS1 *COMPATIBLE OS/400 - Extended NLS Support
5769SS1 *COMPATIBLE OS/400 - ObjectConnect
5769SS1 *COMPATIBLE OS/400 - OptiConnect
5769SS1 *COMPATIBLE OS/400 - Lotus Notes Enhanced Integration
5769SS1 *COMPATIBLE OS/400 - DB2 Symmetric Multiprocessing
5769SS1 *COMPATIBLE OS/400 - DB2 Multisystem
5769SS1 *COMPATIBLE OS/400 - AS/400 Integration for NT
5769SS1 *COMPATIBLE OS/400 - QShell Interpreter
5769SS1 *COMPATIBLE OS/400 - Domain Name System
5716CL1 *COMPATIBLE ADTS Client Server for AS/400 - OS/2
5716CL1 *COMPATIBLE CoOperative Development Environment
5763CL2 *COMPATIBLE ADTS Client Server for AS/400 - Windows
5763CL2 *COMPATIBLE CoOperative Development Environment
5763CL2 *COMPATIBLE VisualAge RPG for Windows
More...
Press Enter to continue.
F3=Exit F11=Display release F12=Cancel F19=Display trademarks
Figure 29. Go LICPGM —> Display installed licensed programs
The use of the SMP is managed by the database query optimizer.

Important
SMP will use additional memory and disk space and produce some
overhead to CPU. For this reason, we recommend that you closely monitor
its usage and adjust the settings as your environment changes.
Once the SMP is installed, you can control its usage on two levels:
• On a system level through the Parallel Processing Degree
(QQRYDEGREE) system value
• On a job level by the CL command Change Query Attributes (CHGQRYA),
with the "Parallel processing degree" parameter
5.3.1.1 Using SMP on a system level

This section shows, by an example, to what extent the SMP can improve BW
performance of a particular workload and how you can observe its effects. We
tested the impact of the SMP by running a BW query on a fact table with 26
million records and four dimensions around it. The hardware system was an
AS/400e Model S20 with four CPUs and OS/400 V4R3. There were no other
users on the system.
First, we ran the query without the SMP enabled. Figure 30 on page 52 shows
the run-time results of the SAP work process (for example, AS/400 job) that
ran this query.
Performance 51
Figure 30. ST03 — BW query performance analysis without SMP
The query was a long-running one with a half hour (1825 seconds) response
time. The WRKACTJOB command (Figure 31 on page 53) shows a snapshot
of the job that ran this query.

Work with Active Jobs AS0023
05/21/99 00:22:57


DISP CLD20 BCI 17.5 RUN
QPADEV000E BBALLARD INT .4 CMD-WRKACTJOB RUN
SCPF QSYS SYS .0 EVTW
SAPOSCOL QA415 BCI .0 SIGW
R3RMTDB R3SERVER ASJ .0 PGM-QBFCLISTEN SELW
R3_20 QSYS SBS .0 DEQW
R3_QA4_15 QA415 BCH .0 PGM-SAPSTART EVTW
R3_CLD_20 CLD20 BCH .0 PGM-SAPSTART EVTW
More...
===>
Figure 31. WRKACTJOB — CPU utilization of BW query without SMP
Job DISP that ran our query used only 17.5% of CPU time, even though there
were no other users on the system. This is understandable considering that,
without the SMP, such a job is processed by only one CPU at a time. Since a
single job on a 4-way system without the SMP can use up to 25% of CPU
time (100% utilization of one out of four available CPUs), our job really used
70% of available CPU time. The three remaining CPUs remained idle.
Then, we enabled the SMP by changing the system value QQRYDEGREE to

*MAX (Figure 32 on page 54).
Performance 53
Change System Value
System value . . . . . : QQRYDEGREE

Description . . . . . : Parallel processing degree
Type choice, press Enter.
Degree of parallelism
allowed . . . . . . *MAX *NONE
*IO
*OPTIMIZE
*MAX
F3=Exit F5=Refresh F12=Cancel
Figure 32. WRKSYSVAL — Change system value QQRYDEGREE
Possible values of the QQRYDEGREE system value are:

• *NONE: No parallel processing is allowed. This is the default value.
• *IO: Any number of tasks may be used when the optimizer chooses to use
I/O parallel processing for queries. SMP is not allowed.
• *OPTIMIZE: The optimizer can choose to use any number of tasks for
either I/O parallel processing or SMP to process the query or database file
index build, rebuild, or maintenance. The use of parallel processing and
the number of tasks is determined with respect to:
– The number of processors available in the system
– A job's share of the active memory available in the memory pool in
which the job is run
– Whether the expected elapsed time for the query or index build,
rebuild, or maintenance is limited by CPU processing or I/O resources
• *MAX: Similar to *OPTIMIZE, except the optimizer assumes that all active
memory in the memory pool can be used to process the query or database
file index build, rebuild, or maintenance.

Any change to this system value becomes the default value for all jobs on the
system. In addition, you can set this value only for a particular job or jobs.
This is described in 5.3.1.2, “Using SMP on a job level” on page 57.
With SMP enabled, we ran the query again. The WRKACTJOB screen
(Figure 33) shows that the same job now used 50.1% of CPU time (compare
this to 17.5% without SMP).
Work with Active Jobs AS0023

05/21/99 01:22:15


DISP CLD20 BCI 50.1 RUN
DISP QA415 BCI .2 DEQW
QPADEV000E BBALLARD INT .1 CMD-WRKACTJOB RUN
SAPOSCOL QA415 BCI .0 SIGW
R3RMTDB R3SERVER ASJ .0 PGM-QBFCLISTEN SELW
R3_QA4_15 QA415 BCH .0 PGM-SAPSTART EVTW
More...
===>
Figure 33. WRKACTJOB — CPU utilization of BW query with SMP
Again, we ran the transaction ST03 (Figure 34 on page 56) to summarize

performance data of the SAP work process that ran the query and compared
it with the previous results.
Performance 55
Figure 34. Transaction ST03 — BW query performance analysis with SMP
Table 9 shows comparisons of the query runtimes with and without SMP
enabled.
Table 9. Query runtime comparison with and without SMP
No SMP With SMP
Response time 1825 sec. 559 sec.
Processing time 1713 sec. 462 sec.
DB request time 109 sec. 93 sec.
CPU utilization1 17.5% 50.1%

1
The two CPU utilization numbers are not directly comparable since the
snapshots were done at different stages. However, they show a general picture.

Summary
Using the SMP in this test, we noticed significant performance improvements.
The magnitude of performance improvements in a particular customer
environment depends several factors, including the type of workload and the
number of users in the first place. SMP can improve the performance of jobs
that run BW queries, or build, rebuild, or maintain database indexes. As a rule
of thumb, consider setting the QQRYDEGREE system value in the following
manner:
• *MAX when there are less than four active users.
• *NONE when there are more than ten active users. The AS/400 system is
already highly efficient at managing that workload without SMP.
• Experiment with values in other cases to find out the best match for your
particular environment.
In 5.4.1, “Loading the BW with data” on page 59, and 5.4.2, “Long-running
query” on page 68, we examine some of the conditions under which the SMP
can bring performance improvements.
5.3.1.2 Using SMP on a job level

Parallel processing can also be controlled on the OS/400 job level with the CL
command CHGQRYA, using the "Parallel processing degree" parameter
(Figure 35 on page 58). With this parameter, you can specify the parallel
processing degree of a single job in a similar manner as with the
QQRYDEGREE system value on a system level. In addition, you can define
the number of tasks that can be used by this job when running queries or
index build, rebuild, or maintenance.
Performance 57
Change Query Attributes (CHGQRYA)
Job name . . . . . . . . . . . . * Name, *

User . . . . . . . . . . . . . Name
Number . . . . . . . . . . . . 000000-999999
Query processing time limit . . *SYSVAL 0-2147352578 seconds, *SAME...
Parallel processing degree:
Processing option . . . . . . *SYSVAL *SAME, *NONE, *IO...
Number of tasks . . . . . . . 2-9999
Asynchronous job usage . . . . . *LOCAL *SAME, *DIST, *LOCAL, *ANY...
Apply CHGQRYA to remote . . . . *YES *SAME, *YES, *NO
Bottom
F24=More keys
Figure 35. CHGQRYA — Change query attribute of a job
The "Number of tasks" parameter specifies the number of tasks that will run a
given query, index build, or maintenance in parallel. If you specify the number
of tasks as two, then only two CPUs process the job, while other CPUs (if
they exist) are idle. We recommend that you specify a number of tasks that is
less than the number of all CPUs on the system. This prevents a single job
from monopolizing the entire system by using all available CPUs. For
example, on an 8-way system, restrict the SMP to use only two CPUs per job
by specifying the Number of tasks as two. This will allow up to four jobs to run
queries in parallel without affecting one another. Each of the four jobs will use
two CPUs.
Before changing the parameters of a job with CHGQRYA, you need to know
the name of this job. This may be difficult in cases when there is more than
one BW job on the system, since you cannot influence the SAP dispatcher’s
decisions. For this reason, we recommend that you change the CHGQRYA
parameters for all DISP jobs of an SAP instance in the same manner. You can
do this either manually or by a CL program that analyzes and changes the
parallel processing degree for all DISP jobs of the SAP instance. Keep in
mind that sometimes BW may restart its work processes automatically. If this
happens, then all attributes of the job will be reset to default. Therefore, the
CL program that changes query attributes must be run again.

5.4 Analysis of BW performance behavior
This section analyzes BW performance behavior in three different test
workloads:
• Loading the BW with data
• Long-running query
• Administration
Evaluations of real customer data and BW benchmarks will be published as

soon as they are available.
All tests were done on an AS/400e Model S30, processor feature #2260 with
eight CPUs, 4 GB main of memory, 28 x 4.19 GB disks drives, and OS/400
V4R3.
5.4.1 Loading the BW with data

This section examines two techniques that may bring significant performance
improvements to a data loading job:
• Deleting indexes on a fact table
• SAP parallel load
In addition, you can improve the data loading performance by putting the BW
and the source system on the same AS/400 machine and using LPARs as
The examples in this section show runtime results of loading the InfoCube
SOCUBE described in Chapter 4, “Loading the BW with data” on page 29.
5.4.1.1 Performance impact of indexes

Maintaining indexes on a fact table produces system overhead and
decreases the performance of data loading. As an example, we show the
data loading of the SOCUBE fact table in two different ways:
• With all indexes being maintained during the data load.
• Without indexes. In this case, the indexes for dimension fields of the fact
table were deleted before the data load and recreated afterwards. This is
done by a BW function, Delete InfoCube indexes, which can be enabled or
disabled during data loading. Enabling this function decreases the data
loading runtime.
This example was done on OS/400 V4R3 using Binary Radix Tree type of
indexes. Encoded vector indexes (EVI) that are available for SAP users in
V4R4 bring additional performance improvements.
Performance 59
Data loading with indexes
First the fact table is loaded with 100,029 rows and all indexes attached. This
data loading consists of two main tasks:
• Reading data sequentially from one flat file and inserting this data into
rows in fact table /BIC0059.
• Maintaining all depending indexes while loading the data.
Figure 36 shows an analysis of this process with SAP transaction ST03.
Figure 36. ST03 — BW fact table data loading with indexes attached
We closely look at the response time (1974 sec.), the processing time (1417
sec.), and DB request time (509 sec.). The total CPU time of this data loading
was 1847 sec., which is approximately 93.5% of the total response time.
Figure 37 on page 61 shows a snapshot taken during the data loading. The
SMP feature is enabled. However, SMP is only used to maintain indexes and
is not used for data inserting.

05/21/99 13:37:33


DISP BWA61 BCI 11.7 RUN
QIJSSCD QIJS BCH 3.2 PGM-QIJSCMON DEQA
DISP BWA61 BCI .5 DEQW
QPADEV000K ENGEL INT .1 CMD-WRKACTJOB RUN
SAPOSCOL BWA61 BCI .0 SIGW
R3RMTDB R3SERVER BCH .0 PGM-QBFCLISTEN SELW
More...
===>
Figure 37. WRKACTJOB — Data loading with indexes
Our data loading is processed by the first DISP job shown in Figure 37.
During the snapshot, this job utilized 11.7% of CPU time. On an 8-way
machine, a single and serially processed job can use up to 12.5% of CPU
(100% divided by 8).
To find out possible I/O bottlenecks of this job, we used the OS/400 Work with
Disk Status (WRKDSKSTS) command. The results are shown in Figure 38 on
page 62.
Performance 61
Work with Disk Status TSCSAP03
05/21/99 13:50:12
Elapsed time: 00:01:51
Size % I/O Request Read Write Read Write %

Unit Type (M) Used Rqs Size (K) Rqs Rqs (K) (K) Busy
1 6607 3670 47.3 .9 20.8 .0 .8 4.0 21.7 1
2 6607 3670 47.3 1.0 21.1 .2 .7 27.4 18.8 1
3 6607 3670 47.3 1.0 23.1 .2 .7 25.0 22.4 1
4 6607 3670 47.3 1.0 15.4 .2 .7 17.9 14.7 0
5 6607 3670 47.3 2.5 25.9 .3 2.1 9.6 28.9 0
6 6607 3670 47.3 .7 19.7 .1 .5 27.3 17.6 0
7 6607 3670 47.3 .8 25.2 .2 .5 30.0 23.2 0
8 6607 3670 47.3 1.4 20.0 .2 1.2 25.6 18.7 0
9 6607 3670 47.3 .6 21.5 .1 .5 26.6 19.7 0
10 6607 3670 47.3 1.3 29.4 .1 1.2 29.0 29.4 0
11 6607 3670 47.3 .8 27.6 .2 .5 30.1 26.1 1
12 6607 3670 47.3 .7 26.9 .2 .5 30.9 24.9 0
13 6607 3670 47.3 .8 26.7 .2 .6 30.9 25.2 0
More...
Command
===>
F3=Exit F5=Refresh F12=Cancel F24=More keys
Figure 38. WRKDSKSTS — Disk status during data loading
With none of the disk arms busy more than 1%, there were no I/O bottlenecks
during this test.
Data loading without indexes

On the second time, the fact table is loaded without indexes. We instructed
BW to delete the indexes prior to data loading. This is done by switching on
the SAP function "Delete InfoCube indexes before each data loading and
then recreate". Select RSA1 —> InfoCube —> InfoCube Performance to
access this function and enable it (Figure 39 on page 63).

Figure 39. Delete InfoCube indexes before data loading
You do not need to know names of the index files to perform this action. BW
knows which indexes are built on the fact table. However, sometimes you
need to know the names of indexes that are attached to your tables (see the
example in 5.4.2.2, “Query performance analysis” on page 72). You can find
the names either with SAP transaction SE11 (ABAP Dictionary) or the OS/400
command Display Database Relation (DSPDBR). To find out which indexes
are attached to our fact table /BIC0059, we typed:
DSPDBR FILE(*LIBL/"/BIC0059")
Figure 40 on page 64 shows the performance results of the data loading with
"Delete InfoCube indexes" function enabled. All indexes based on fact table
/BIC0059 were deleted by BW before the start and recreated after the end of
data loading.
Performance 63
Figure 40. BW fact table data loading without indexes attached
A comparison of the results in Figure 40 with the results of the data load with
indexes (Figure 36 on page 60) shows significant runtime improvements.
Table 10 summarizes the performance comparison of the two data loads.
Table 10. Runtime comparison — Data loading of fact table
With indexes Without indexes
Response time 1974 sec. 1050 sec.
Processing time 1417 sec. 880 sec.
DB Request time 539 sec. 153 sec.
CPU time 1848 980
The performance behavior of master data tables load looks similar to fact
table data loading, shown in Figure 36 on page 60. There is a similar ratio
between processing time, CPU time, and DB request time.

In our tests, all data loading jobs were CPU bound. Table 11 summarizes the
runtime results for the data loading of all three tables.
Table 11. Data loading test results summary
Type of data Info Number of Runtime Runtime

source records with indexes without
indexes1
Fact 100.029 32.54 Min. 17.27 Min.
Master Part 20.000 2.21 Min. n.a.
Master Customer 2.500 0.31 Min. n.a.

1
This run-time includes index rebuild.
Use the "Delete InfoCube indexes" function on a fact table whenever the time
needed to recreate indexes after the data load is shorter than the time
needed to maintain indexes during the data loading. This may not be true in
the case of a delta update where you add records to the fact table, which
already contains many records. In this case, the time needed to recreate
indexes may be longer.
Rule of thumb
When the delta update includes 10% or more of the table, delete the
indexes, run the update, and then recreate the indexes. Every customer
should run their own tests of this procedure. The results can vary widely
based on the type of update and the complexity and number of indexes.
5.4.1.2 SAP parallel load

In a case of mass data loading, the performance can be improved by using
the SAP parallel data load function. There is a difference between the SAP
parallel load and AS/400 Symmetric Multiprocessing:
• The SAP parallel load enables several SAP work processes (for example,
AS/400 jobs) to run in parallel, while each of them uses only one CPU
(Figure 41 on page 66).
• The DB2 SMP feature allows one SAP work process (AS/400 job) to use
several CPUs at a time (Figure 42 on page 66).
Performance 65
SAP BW Work Processes AS/400 Processor Tasks
DISP (active) Processor 1
Figure 41. SAP parallel load
SAP BW Work Processes AS/400 Processor Tasks
DISP 1 (active) Processor 1
DISP 2 (wait) Processor 2
Figure 42. DB2 Symmetric Multiprocessing
To use the SAP parallel load, complete the following steps:

1. Split the file with source data into separate input files for data loading.
2. Create different Info Packages for an Info Source.
3. Assign the input files as ExternData files to the InfoPackages.
4. Run data loading jobs in parallel using the InfoPackage scheduler.
Figure 43 on page 67 shows a snapshot of four SAP work processes (AS/400

DISP jobs) running the parallel load of our fact table. The SMP feature was
also enabled.

05/25/99 18:42:32


QIJSSCD QIJS BCH 2.8 PGM-QIJSCMON DEQA
QPADEV000D ENGEL INT .7 CMD-WRKACTJOB RUN
More...
===>
Figure 43. WRKACTJOB — Parallel load
Since this data loading job is primarily processed in a serial manner, we do

not benefit much from the SMP feature in this case. All four work processes
that run parallel data loads primarily consume CPU-cycles of only one CPU at
a time. For this reason, they cannot achieve more than 12.5% CPU utilization
each and 50% altogether.
Recommendation
To achive maximum performance of a data loading job, use the parallel
load with as many SAP work processes as there are CPUs on the BW
system.
Using the WRKDSKSTS command to find out possible I/O bottlenecks during
the parallel load, again we did not find any I/O bottlenecks. The disk arm
utilization in our example (Figure 44 on page 68) was similar to the
non-parallel load shown in Figure 38 on page 62.
Performance 67
Work with Disk Status TSCSAP03
05/25/99 18:45:03
Elapsed time: 00:04:37
Size % I/O Request Read Write Read Write %

Unit Type (M) Used Rqs Size (K) Rqs Rqs (K) (K) Busy
1 6607 3670 82.7 .5 14.9 .0 .5 14.1 15.0 0
2 6607 3670 82.8 1.9 22.3 .1 1.7 26.9 21.9 1
3 6607 3670 82.7 1.9 18.3 .3 1.6 29.9 15.9 2
4 6607 3670 82.6 2.4 35.6 .4 2.0 11.7 40.3 4
5 6607 3670 82.8 1.1 30.6 .3 .7 10.1 41.5 2
6 6607 3670 82.6 .5 11.9 .0 .5 10.1 12.0 0
7 6607 3670 82.6 .8 25.4 .0 .8 13.8 26.4 1
8 6607 3670 82.7 6.7 9.2 5.7 1.0 4.2 36.4 3
9 6607 3670 82.6 1.0 42.6 .0 .9 22.6 44.4 1
10 6607 3670 82.8 1.6 26.7 .0 1.5 20.0 27.1 1
11 6607 3670 82.7 1.8 12.2 .0 1.8 22.6 12.0 1
12 6607 3670 82.6 1.4 20.1 .3 1.0 6.7 24.3 0
13 6607 3670 82.6 1.0 27.1 .1 .8 12.5 29.7 1
More...
Command
===>
F3=Exit F5=Refresh F12=Cancel F24=More keys
Figure 44. WRKDSKSTS — Disk arm utilization during parallel load
5.4.2 Long-running query

There are three techniques that can improve the performance of long-running
queries:
• Defining aggregates
• Adding permanent indexes to InfoCube tables (described in detail later in
this section)
• Using the AS/400 SMP as already described in 5.3, “BW and OS/400
parallel processing” on page 48
This section shows how to analyze and improve query run-time performance
through the example of using a typical BW query.
5.4.2.1 Description of the sample query

This query ran in a test environment on OS/400 V4R3. The OS/400 V4R4 will
bring additional performance improvements to the query run-time with the
introduction of encoded vector index (EVI) support. This support will be
available for BW production environments.
The query used in this example is based on the InfoCube Customer, which is
delivered by the SAP to run BW benchmarks. This InfoCube contains a part

of all BW benchmark data. As shown in Figure 45, InfoCube Customer
consists of one fact table and eight dimension tables:
• Customer
• Material
• Sales area data
• Version
• Value type
• Time
• Data packet
• Unit of measure
Figure 45. RSA1 — InfoCube Customer data model
Performance 69
The query fetches the invoiced quantity, netvalue of invoiced sales, and cost
of invoiced sales. They are grouped by sold-to-party and filtered by
fiscal-year-variant. The design of this query named 0SD_C01_Q013 is shown
on the SAP Business Explorer Analyzer "Define query" window in Figure 46.
Figure 46. SAP Business Explorer Analyzer —> Define query
Table 12 on page 71 shows which tables are joined to run this query and the
amount of records stored in these tables.

Table 12. Tables in the InfoCube Customer — Test data
Table name Number of records
Fact Table 4,350,955
Dimension table Customer 10,001
Dimension table Material 43,665
Dimension table Sales area data 251
Dimension table Version 2
Dimension table Value type 2
Dimension table Time 112
Dimension table Data packet 6
Dimension table Unit of measure 2
SID table Customer 10,001
SID table Material 43,662
SID table Distribution Channel 6
SID table Division 6
SID table Sales Org 11
As specified in "Free Characteristics" of this query’s definition, you are

requested to specify additional selections before the query runs (Figure 47).
The result of this query is presented by the SAP Business Explorer Analyzer
in Figure 48 on page 72.
Figure 47. Starting the 0SD_C01_Q013 query
Performance 71
Figure 48. Query result
5.4.2.2 Query performance analysis

The query is running with SMP enabled. The WRKACTJOB display (Figure 49
on page 73) shows the query executed by the first DISP job. At the time this
window was captured, the system was building an index as indicated by the
function IDX-"/BIC00285". Since SMP is enabled, this is done with several
CPUs in parallel.

05/27/99 17:14:21


DISP BWA61 BCI 44.1 IDX-"/BI00285" RUN
QIJSSCD QIJS BCH 1.3 PGM-QIJSCMON DEQW
QPADEV000D ENGEL INT .7 CMD-WRKACTJOB RUN
DISP BWA61 BCI .2 DEQW
More...
===>
Figure 49. WRKACTJOB — BW query running with SMP enabled
The transaction ST03 (Figure 50 on page 74) summarizes performance

behavior of the work process that ran the query.
Performance 73
Figure 50. ST03 — BW query transaction analysis, SMP enabled
The largest part of the response time (121 sec.) is the processing time (118
sec.). Only 2.5 sec. was used for DB request time. The CPU time is larger
than the total response time (536 sec. versus 118 sec.) due to the SMP
(multiple CPUs were processing this job).
We further analyze the performance of this query by switching on the ABAP

SQL trace (SAP transaction ST05) while the query is running. Trace analysis
of ST05 (Figure 51 on page 75) shows SQL statements processed by the
query and their execution times.

Figure 51. ST05 — SQL trace overview
The SQL OPEN function (at time stamp 17:13:35) took more than 105 sec.
(89% of the total processing time) to process the SELECT statement. It is
obvious that, in this case, the biggest potential for performance improvement
is in optimizing the SQL OPEN function. To analyze SQL functions, click on
the Explain SQL button to get the Database Performance: Explain window
(Figure 52 on page 76).
Performance 75
Figure 52. ST05 — Explain SQL statement
We can see that, in our query, the SQL SELECT statement joined eleven files
and selected many columns. On this window, we click on the Expand Subtree
button for more details on how the SQL SELECT statement was processed.
The Database Performance Explain window appears, which is partly shown in
Figure 53 on page 77.

Figure 53. ST05 — Explain SQL statement —> Expand subtree
On the Database Performance: Explain window, some of the information you

can see includes:
• The access path that was selected. In this case, the database optimizer
decided that the best access method is to build a temporary access path
(for example, temporary index). This path includes the key fields
KEY_000001, KEY_000003, KEY_000004, KEY_000006, and
KEY_000008 for table "/BI00285", which is the fact table.
• The number of records from which the index was created (4,930,954 in
this case).
• The amount of time the index creation took (more than 148 sec.).
In conclusion, avoiding the temporary index creation may bring significant

performance improvement. This is possible when creating a permanent index
Performance 77
before starting the query. When the query runs unchanged next time, the
optimizer will again select the same access method, find out that the index
already exists, and use the existing index instead of creating a temporary
one.
Recommendation
You can create a permanent index with any native OS/400 tool. However,
we strongly recommend that you create it inside the SAP environment. In
this case, the index will be known in the SAP Data Dictionary. The index
will always be considered during system upgrades and other important
system tasks such as deleting or recreating indexes during data loading.
To create an index with SAP Data Dictionary, you must know the alternate
names (long names and short names) of the table and fields.
The table short name is depicted in the Explain SQL function (Figure 53 on
page 77). In this example, the table short name is "/BI00285". To find out the
table long name, use the OS/400 command SQLUTIL. Then, press the Enter
key, and specify the parameters as shown here:
SELECT SYSTEM_TABLE_NAME, TABLE_NAME FROM
R3BWADATA/SYSTABLES
WHERE NAME LIKE '/BI0%'
After pressing the Enter key, we get the list of all tables and search for the
known short name to find out the fact table’s alternate name. As shown in
Figure 54 on page 79, the table alternate name in this example is
/BI0/F0SD_CO01.

Display Report
Query . . . . .: QGPTOOLS/SQLUTIL Width . . .: 369
Form . . . . .: *SYSDFT Column . .: 1
Control . . . .
Line ....+....1....+....2....+....3....+....4....+....5....+....6....+....7..
SYSTEM_TABLE_NAME TABLE_NAME
"/BI01790" /BI0/F0D_DECU
"/BI00285" /BI0/F0SD_C01
"/BI00390" /BI0/HABCPROCESS
"/BI00392" /BI0/HACCOUNT
"/BI00394" /BI0/HACTTYPE
"/BI00396" /BI0/HCOORDER
"/BI00398" /BI0/HCOSTCENTER
"/BI00400" /BI0/HCOSTELMNT
"/BI00402" /BI0/HCS_GROUP
"/BI00404" /BI0/HCS_ITEM
"/BI00406" /BI0/HCUST_SALES
"/BI00051" /BI0/HCUSTOMER
"/BI00294" /BI0/HD_MATERIAL
"/BI00296" /BI0/HD_MTLGROUP
"/BI00298" /BI0/HD_SALE_ORG
"/BI00300" /BI0/HD_SOLD_TO
More...
F3=Exit F12=Cancel F19=Left F20=Right F21=Split
Figure 54. SQL SYSTABLES — Assign short/alternate table names
Next, we find out the alternate field names. We use the OS/400 Display File
Field Description (DSPFFD) command as shown here:
DSPFFD FILE(R3BWADATA/"/BI00285")
Pressing the Page down key brings the second screen with field names and
their alternate field names (Figure 55 on page 80).
Performance 79
Data Field Buffer Buffer Field Column
Field Type Length Length Position Usage Heading
KEY_000001 BINARY 9 0 4 1 Both KEY_0SD_C01P
Alternative name . . . . . . . . . . . . : KEY_0SD_C01P
Default value . . . . . . . . . . . . . . :
0
KEY_000002 BINARY 9 0 4 5 Both KEY_0SD_C01T
Alternative name . . . . . . . . . . . . : KEY_0SD_C01T
Default value . . . . . . . . . . . . . . :
0
KEY_000003 BINARY 9 0 4 9 Both KEY_0SD_C01U
Alternative name . . . . . . . . . . . . : KEY_0SD_C01U
Default value . . . . . . . . . . . . . . :
0
KEY_000004 BINARY 9 0 4 13 Both KEY_0SD_C011
Alternative name . . . . . . . . . . . . : KEY_0SD_C011
Default value . . . . . . . . . . . . . . :
0
KEY_000005 BINARY 9 0 4 17 Both KEY_0SD_C012
More...
F3=Exit F12=Cancel F19=Left F20=Right F24=More keys
Figure 55. DSPFFD — Map field names with alternate field names
Table 13 summarizes the alternate field names of this example.

Table 13. Field names with their alternate field names
Field name Alternate field name
KEY_000001 KEY_0SD_C01P
KEY_000003 KEY_0SD_C01U
KEY_000004 KEY_0SD_C011
KEY_000006 KEY_0SD_C013
KEY_000008 KEY_0SD_C015
After this step, you have all information needed to create a permanent index
that the optimizer will use instead of a temporary one. Use the SAP
transaction SE11 (Figure 56 on page 81) to create this index.

Figure 56. SE11 — Create permanent index for BW database
As shown in Figure 56, we created index ID=090 for the fact table
/BI0/F0SD_C01 with the alternate field names as listed in Table 13 on page
80. After we created this permanent index, we ran our query again. The ST03
monitor result shown in Figure 57 on page 82 summarizes the performance
data of this second run.
Performance 81
Figure 57. ST03 — Query monitoring with permanent index for table /BI00285
In comparison with the first run, shown in Figure 50 on page 74, all key times
(response time, processing time, and CPU time) were reduced significantly.
The ABAP SQL Trace (transaction ST05 in Figure 58 on page 83) explains
this improvement.

Figure 58. ST05 — SQL trace overview with permanent index available
The performance improvement was achieved on behalf of a shorter execution

time of the SQL OPEN function. In our example, this time was reduced from
148 sec. when the optimizer used a temporary index. The time was reduced
to 1.1 sec. when the permanent index was used. By clicking Explain SQL
function, we get details of this improvement, which is shown in Figure 59 on
page 84.
Performance 83
Figure 59. ST05 — Explain SQL statement, index available
Instead of creating a temporary index for about 4.9 millions records, the
optimizer now decided to use the existing permanent index
/BI0/F0SD_C01+090 that we created.
Performance improvements of such magnitudes can be expected when the

system does not have to build the access plan. When an index is deleted and
recreated again (for example, during data load without indexes), the access
plan will be rebuilt the next time that the same query is started.
We ran our query for the third time. This time, we deleted the index and
recreated it immediately, before we ran the query. This forced the optimizer to
rebuild the access plan.
Performance results of all three runs are summarized in Table 14 on page 85.
It compares runtimes monitored by the transaction ST03 (for response time,

processing time, CPU time, DB request time) and transaction ST05 (for SQL
OPEN).
Table 14. Query 0SD_C01_Q013 runtime comparison
Temporary index Permanent index Permanent index,

and access plan no access plan
rebuild rebuild
Response time 121.177 ms. 22.498 ms. 5.955 ms
Processing time 118.356 ms. 20.906 ms. 4.062 ms.
CPU time 536.687 ms. 7.111 ms 4.852 ms.
DB request time 2.589 ms 1.388 ms. 1.148 ms.
SQL open 105.145 ms. 17.924 ms. 1.150 ms.
Summary
Query performance may be significantly improved by using a permanent
index. However, this index will deteriorate the performance of InfoCube data
loading. Compare the advantage of improved query performance against the
disadvantage of increased data loading time. If the disadvantage is bigger,
use a temporary index with SMP enabled.
5.4.3 BW system administration

BW administration means predominantly working with InfoObjects,
InfoCubes, and InfoSources. It is done with the SAP transaction RSA1. In our
tests, the performance behavior of some typical administrator’s transactions
was similar to the SAP R/3. For hints on how to tune the administrator’s
workload, please refer to redbook SAP R/3 Implementation for AS/400,
SG24-4672.
Performance 85
Chapter 6. Sizing considerations
This section describes some considerations on how to size an AS/400 system

that runs BW. The considerations are based on recommendations published
by the SAP in the document Performance and Sizing, ASAP for SAP BW
Accelerator, Document Version 1.1, available on SAPNet. They are also
derived from the first test results described in Chapter 5, “Performance” on
page 45.
At the time this redbook was published, there was no sizing data available,
based on benchmarks or production environments. As such, all conclusions
in this section are preliminary. For BW sizing guidelines, please contact the
International SAP IBM Competence Center (ISICC) by e-mail at this address:
infoserv@de.ibm.com
6.1 CPU requirements

BW queries, as well as data loads that we ran in our tests, used long-running
transactions with high CPU usage. These transactions significantly influence
performance behavior of other transactions that run at the same time and
compete for the same CPU. Therefore, we highly recommend that you have a
system with a sufficient number of CPUs to avoid the CPU bottlenecks.
One-way AS/400 systems should not be considered as a BW platform.
6.2 Memory requirements

As mentioned in the SAP sizing documentation for BW, memory requirements
depend heavily on the amount of data that is read during the execution of a
report. As a minimum requirement, we recommend that you follow these
sizing guidelines for the SAP R/3 4.5 provided by ISICC:
• Client/Server Systems (3-tier)
– M(DB) = (768 MB + 5 MB*N) * 1.2
– M(AP) = (768 MB + 5 MB*N(AP)) * 1.2
• Central Systems (2-tier)
– M = (768 MB + 13 MB*N) * 1.2
Where:
M Main memory requirement
M(AP) Main memory requirement for the application server
M(DB) Main memory requirement for the database server

N Total amount of active users
N(AP) Total amount of active users assigned to an application server
For detailed information, please refer to the SAP R/3 sizing documentation
published by ISICC.
6.3 Disk space and disk arms requirements

Disk space requirements can be determined by following the rules published
by the SAP in the document in the appendix "Disk Storage Sizing", in
Performance and Sizing, ASAP for BW Accelerator, Document Version 1.0,
which is available on SAPNet.
To avoid performance bottlenecks caused by an insufficient number of disk

arms, use disk arm recommendations published in the IBM White Paper
AS/400 Disk Arm Requirements Based on Processor Model Performance.
This white paper provides recommendations for each AS/400 CPU level. You
can find this document on the Web at:
http://www.as400.ibm.com/developer/performance/dasdmenu.html
6.4 Additional considerations

Additional sizing considerations include:
• Front-end PC requirements
• Network traffic and
• Calculating line capacity
For more information, please refer to the SAP publication Performance and
Sizing, ASAP for SAP BW Accelerator, Document Version 1.0, which is
available on SAPNet.
6.5 BW system configuration examples

This section offers some recommendations for AS/400 two-tier configurations
in different BW environments. Recommendations are based on the following
assumptions:
• 65% of named users are active users.
• Eight active medium users or four active high users are valued as one
concurrent user.
• 20% of all active users are high users, and 80% of them are medium
users. A medium user accesses the BW system regularly and

continuously. The user typically uses predefined and optimized reports. A
high user works intensively with the BW system and runs ad hoc queries.
Here are three configuration examples:

• Small test system for 25 named users (SAP size XS)
AS/400 Model 720, #2063 (2-way), 1.5 GB memory, 40 GB (10 x 4.19)
disk, RAID-5.
• Production system for 50 named users (SAP size S)
AS/400 Model 730, #2066 (2-way), 2 GB memory, 80 GB (20 x 4.19) disks,
RAID-5.
• Production system for 100 named users (SAP size L)
AS/400 Model 730, #2067 (4-way), 3 GB memory, 120 GB (30 x 4.19)
disks, RAID-5.
As described in 5.4, “Analysis of BW performance behavior” on page 59, BW

performance heavily depends on which techniques you use to optimize your
run-time environment and how you combine them in an optimal manner. In
addition, it is important to find the optimal data model for your InfoCubes
during the design phase of BW implementation.
We recommend that you start the implementation project with a system that
provides enough CPU power to simulate the future production environment
with a reasonable amount of test users. After the optimization phase of the
implementation project is finished, you can decide the final configuration.
Sizing considerations 89
Appendix A. Files used in the example of InfoCube data loading
This appendix contains descriptions of the tables and files used in 4.1.1, “File
interface — An example” on page 29.
Table 15. Table Trans1
Field Data Type Field Column headings Default

length value
CUSTKEY BINARY 9,0 Customer number None
LIM1 CHAR 1 Separator ’;’
SUPPLYCOST PACKED 15,2 Cost None
QUANTITY PACKED 15,2 Quantity None
PARTKEY BINARY 9,0 Part number None
CURRENCY CHAR 3 Currency ’USD’
ORDERDATE DATE *ISO 10 Date None
ORDERDAT1 DATE *ISO 10 Date ’1999-01-11’
CALMON CHAR 6 Month ’199901’
QUARTER CHAR 5 Quarter ’19991’
YEARFLD CHAR 4 Year ’1999’

Table 16. Table Transch
Field Data type Field Column headings Default

length value
CUSTKEY CHAR 6 Customer number None
COST CHAR 15 Cost None
QUANTITY CHAR 11 Quantity None
PARTKEY CHAR 6 Part number None
CURRENCY CHAR 3 Currency None
ORDERDATE CHAR 8 Date None
ORDERDATE1 CHAR 8 Date None
CALMON CHAR 6 Month None
QUARTER CHAR 5 Quarter None
YEARFLD CHAR 4 Year None

Table 17. Flat file Part.csv
Data description Characters
Part number 6
Delimiter 1
Part Name 25
Delimiter 1
Table 18. Flat file Cust.csv
Customer Number 6
Delimiter 1
Customer Name 25
Delimiter 1
Country 25
Delimiter 1
Region 25
Delimiter 1
Address 25
Delimiter 1
Table 19. Flat file Trans.csv
Order quantity 11
Delimiter 1
Order Cost 16
Delimiter 1
Part Number 6
Delimiter 1
Files used in the example of InfoCube data loading 93

Customer Number 6
Delimiter 1
Sales Order Date 10
Delimiter 1
Currency 3
Delimiter 1
Calendar Day 10
Delimiter 1
Quarter 5
Delimiter 1
Year 4
Delimiter 1

Appendix B. RPG ILE preparation program
This appendix contains the RPG code used in 4.1.1, “File interface — An
example” on page 29.
* *PROGRAM DESCRIPTION
*----------------------
*
* This program reads 3 DB2/400 files and creates a stream file
* version of each. ';' separators are added between fields in the
* stream files. Character fields are made all upper case. Decimal,
* integer and date fields are converted to character.
* Logic should be added to check return codes.
*
*LICENSE AND DISCLAIMER
* ----------------------
* This material contains IBM copyrighted sample programming
* source code. IBM grants you a nonexclusive license to use,
* execute, display, reproduce, distribute and prepare derivative
* works of this sample code. The sample code has not been
* thoroughly tested under all conditions. IBM, therefore, does
* not warrant or guarantee its reliability, serviceablity, or
* function. All sample code contained herein is provided to you
* "AS IS." ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
* NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILLITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE HEREBY DISCLAIMED.
*
* COPYRIGHT
* ---------
* (C) COPYRIGHT IBM CORP. 1997, 1998
* ALL RIGHTS RESERVED.
* US GOVERNMENT USERS RESTRICTED RIGHTS -
* USE, DUPLICATION OR DISCLOSURE RESTRICTED
* BY GSA ADP SCHEDULE CONTRACT WITH IBM CORP.
* LICENSED MATERIAL - PROPERTY OF IBM
* * ----------------------
* * Compile Instructions:
* * CRTMOD and then CRTPGM
* *****************************************************************
* F I L E D E S C R I P T I O N S P E C I F I C A T I O N *
**********************************************************************
*
fpart if e k disk rename(part:pt)
f prefix(p_)
fcustomer if e k disk rename(customer:cust)
f prefix(c_)
ftrans if e k disk rename(trans:tr)
f prefix(t_)
*******************************************************************
*
* START OF WHAT SHOULD BE IN A RPG INCLUDE FILE
*
******************************************************************
*****************************************************************

*
* (from member FCNTL, file H, library QSYSINC)
* stream file (flat file) Open definition
*
*****************************************************************
* value returned = file descriptor (OK), -1 (error)
Dopen PR 10I 0 EXTPROC('open')
* path to be opened.
D * VALUE
* Open flags
D 10I 0 VALUE
*(OPTIONAL) mode (describes access rights to the file)
D 10U 0 VALUE OPTIONS(*NOPASS)
* (OPTIONAL) codepage (specified for ascii data)
D 10U 0 VALUE OPTIONS(*NOPASS)
********************************************************************
*****************************************************************
*
* (from member UNISTD, file H, library QSYSINC)
*
* stream file (flat file) Read definition
*
*****************************************************************
* value returned = number of bytes actually read, or -1
Dread PR 10I 0 EXTPROC('read')
* file descriptor returned from open()
D 10I 0 VALUE
* data received
D * VALUE
* number of bytes to read
D 10U 0 VALUE
********************************************************************
*
*
* stream file (flat file) write definition
*
*
*******************************************************************
* value returned = number of bytes actually written, or -1
Dwrite PR 10I 0 EXTPROC('write')
D 10I 0 VALUE
* data to be written
D * VALUE
* number of bytes to write
D 10U 0 VALUE
*****************************************************************
********************************************************************
*
*
* stream file (flat file) Close definition;
*
*****************************************************************
* value returned = 0 (OK), or -1
Dclose PR 10I 0 EXTPROC('close')
D 10I 0 VALUE

*****************************************************************
*****************************************************************
* The stream files will be created in the bw directory
*****************************************************************
DFileNam S 50A INZ('/bw/part.csv')
DFileNamP S * INZ(%ADDR(FileNam))
DFileDescr S 10I 0
DFileCus S 50A INZ('/bw/cust.csv')

DFileCusP S * INZ(%ADDR(FileCus))
DFileCusD S 10I 0
DFileTrn S 50A INZ('/bw/trans.csv')

DFileTrnP S * INZ(%ADDR(FileTrn))
DFileTrnD S 10I 0
*
******************************************************************
* The following comments explain how the various numeric fields
* were assigned for the open API. The values mentioned here are
* from the FCNTL member of the H file in the QCLE library.
******************************************************************
* The following are for the 'oflag' parameter:
*
* define O_CREAT 0x0000008 /* Create the file if not there
* define O_TRUNC 0x0000040 /* Clear file if it is there
* define O_WRONLY 0x0000002 /* Open for writing only
* define O_TEXTDATA 0x1000000 /* Translate ebcidic/ascii
* define O_CODEPAGE 0x0800000 /* Create file in ascii ccsid
*
******************************************************************
DO_CREAT S 10I 0 INZ(8)
DO_RDWR S 10I 0 INZ(4)
DO_TEXTDATA S 10I 0 INZ(16777216)
DO_CODEPAGE S 10I 0 INZ(8388608)
Doflag S 10I 0 INZ(0)
*
*********************************************************************
* The mode parameter for the open API is set to give access to
* all users. 0x01B6 = rw-w-w-data rights
******************************************************************
Domode S 10U 0 INZ(438)
*
******************************************************************
* cp is used to set the code page (CCSID) of the IFS file to be
* a common US English ASCII. Others code be substituted as
* desired.
******************************************************************
* ASCII (ccsid 437 = 0x1B5)
Dcp S 10U 0 INZ(819)
*
********************************************************************
* The following fields are used to help fo the string
* formatting and writing...
*****************************************************************
*
DZeroBin S 50A INZ(*ALLX'00')
DNLZero S 2A INZ(X'1500')
RPG ILE preparation program 97

*
*****************************************************************
* Buf is the place where we build our string that will go into t
* ascii file for us. It needs to be big enough to hold all of
* the data for one record of output (including formatting).
*****************************************************************
*
DBuf S 150A
DBufP S * INZ(%ADDR(Buf))
DBufLen S 10U 0 INZ(150)
*
**********************************************************************
* DATA STRUCTURES
**********************************************************************
*
DRC s 10I 0
*
d up C 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
d lo C 'abcdefghijklmnopqrstuvwxyz'
d string s 6
d i s 10I 0
d chdate s 10
d ptrec ds
d pb_partkey 6
d pb_sep 1 inz(';')
d pb_part 25
d pb_sep2 1 inz(';')
d pb_hexend 2 inz(X'0D25')
d curec ds
d cu_custkey 6
d cu_sep 1 inz(';')
d cu_address 32
d cu_sep2 1 inz(';')
d cu_country 25
d cu_customer 25
d cu_region 25
d cu_hexend 2 inz(X'0D25')
d trrec ds
d tb_quantity 11
d tb_sep 1 inz(';')
d tb_cost 15
d tb_sep2 1 inz(';')
d tb_partkey 6
d tb_custkey 6
d tb_date 8
d tb_cur 3
d tb_calday 8
d tb_calmon 6

d tb_calqtr 5
d tb_calyr 4
d tb_hexend 2 inz(X'0D25')
*
****************************************************************
* MAIN *
****************************************************************
* Use the open API to create the file, specifying that the data
* to be stored in it will be in codepage (ccsid) 437 (or whateve
* you change it to above in the CP field).
*
*****************************************************************
*
C EVAL FileNam=%TRIM(FileNam) + ZeroBin
C Z-ADD O_CREAT oflag
C ADD O_RDWR oflag
C ADD O_CODEPAGE oflag
C EVAL FileDescr=open(FileNamP:oflag:omode:cp)
C EVAL FileCus=%TRIM(FileCus) + ZeroBin

C ADD O_RDWR oflag
C EVAL FileCusD=open(FileCusP:oflag:omode:cp)
C EVAL FileTrn=%TRIM(FileTrn) + ZeroBin

C ADD O_RDWR oflag
C EVAL FileTrnD=open(FileTrnP:oflag:omode:cp)
*****************************************************************
*******************************************************************
* Read thru the DB2/400 part file. Convert partkey from integer to
* character. Change the leading zeros to blanks and then trim
* the blanks. Put the part name (part) in upper case.
* Write the record to the stream file.
*****************************************************************
*
c read pt 7099
c dow *in99=*off
c move p_partkey string
c eval i=1
c dow %subst(string:i:1)='0'
c and i<7
c eval %subst(string:i:1)=' '
c eval i=i+1
c enddo
c eval pb_partkey=%trim(string)
c lo:up xlate p_part pb_part
c eval buf=ptrec
C EVAL RC=write(FileDescr: BufP: 35)
c read pt 7099
c enddo
*******************************************************************
* Read through the DB/2 400 trans table. Convert integer, decimal

* and date fields to character. Use the date field to get month
* quarter and year values for the stream file. Convert both
* partkey and custkey as we did partkey above. Write streamfile.
*****************************************************************
c read tr 7099
c dow *in99=*off
c eval tb_quantity=%trim(%editc(t_quantity:'A'))
c eval tb_cost=%trim(%editc(t_supplycost:'A'))
c move t_orderdate chdate
c eval %subst(tb_date:1:4)=%subst(chdate:1:4)
c eval tb_calday=tb_date
c eval tb_calmon=%subst(tb_date:1:6)
c eval tb_calyr =%subst(tb_date:1:4)
c eval tb_calqtr=%subst(tb_date:1:4)
c eval %subst(tb_calqtr:1:4)=tb_calyr
c if %subst(tb_date:5:2)='01' or
c %subst(tb_date:5:2)='02' or
c %subst(tb_date:5:2)='03'
c eval %subst(tb_calqtr:5:1)='1'
c endif
c endif
c endif
c endif
c lo:up xlate t_currency tb_cur
c move t_partkey string

c eval i=1
c and i<7
c eval i=i+1
c enddo
c eval tb_partkey=%trim(string)
c move t_custkey string

c eval i=1
c and i<7
c eval i=i+1
c enddo
c eval tb_custkey=%trim(string)
c eval buf=trrec
C EVAL RC=write(FileTrnD: BufP: 84)

*******************************************************************
* Read thru the DB2/400 customer file. Convert custkey from int to
* character. Change the leading zeros to blanks and then trim
* the blanks. Put all the other character fields into upper case.
* Write the record to the stream file.
*****************************************************************
c read tr 7099
c enddo
c read cust 7099

c dow *in99=*off
c move c_custkey string
c eval i=1
c and i<7
c eval i=i+1
c enddo
c eval cu_custkey=%trim(string)
c lo:up xlate c_country cu_country
c lo:up xlate c_region cu_region
c lo:up xlate c_customer cu_customer
c lo:up xlate c_address cu_address
c eval buf=curec
C EVAL RC=write(FileCusD: BufP: 120)
c read cust 7099
c enddo
********************************************************************
*
* Use the close API to close the IFS file.
*
*****************************************************************
C EVAL RC=close(FileDescr)
C EVAL RC=close(FileCusD )
C EVAL RC=close(FileTrnD )
c seton lr
*****************************************************************
* END MAIN
*****************************************************************

Appendix C. Special notices
This publication is intended to help AS/400 technical specialists and SAP

Basis consultants in the implementation of the SAP Business Information
Warehouse on the AS/400 system. The information in this publication is not
intended as the specification of any programming interfaces that are provided
by SAP or IBM. Contact SAP for more information about what publications
are considered to be product documentation.
References in this publication to IBM products, programs or services do not

imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not
intended to state or imply that only IBM's product, program, or service may be
used. Any functionally equivalent program that does not infringe any of IBM's
intellectual property rights may be used instead of the IBM product, program
or service.
Information in this book was developed in conjunction with use of the

equipment specified, and is limited in application to those specific hardware
and software products and levels.
IBM may have patents or pending patent applications covering subject matter
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 the IBM
Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood,
NY 10594 USA.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact IBM
Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and

conditions, including in some cases, payment of a fee.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The information about non-IBM
("vendor") products in this manual has been supplied by the vendor and IBM
assumes no responsibility for its accuracy or completeness. The use of this
information or the implementation of any of these techniques is a customer
responsibility and depends on the customer's ability to evaluate and integrate
them into the customer's operational environment. While each item may have
been reviewed by IBM for accuracy in a specific situation, there is no

guarantee that the same or similar results will be obtained elsewhere.
Customers attempting to adapt these techniques to their own environments
do so at their own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of
these Web sites.
Any performance data contained in this document was determined in a

controlled environment, and therefore, the results that may be obtained in
other operating environments may vary significantly. Users of this document
should verify the applicable data for their specific environment.
The following document contains examples of data and reports used in daily
business operations. To illustrate them as completely as possible, the
examples contain 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.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes
available to each customer according to the normal IBM PTF distribution
process.
The following terms are trademarks of the International Business Machines

Corporation in the United States and/or other countries:
AS/400 AT
CT DB2
IBM  Information Warehouse
Netfinity Operating System/400
OS/2 OS/400
RS/6000 SP
System/390 VisualAge
XT 400
The following terms are trademarks of other companies:
C-bus is a trademark of Corollary, Inc. in the United States and/or other

countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other
countries.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United

States and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel

Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and/or other countries

licensed exclusively through X/Open Company Limited.
SET and the SET logo are trademarks owned by SET Secure Electronic
Transaction LLC.
Other company, product, and service names may be trademarks or service

marks of others.
Special notices 105

Appendix D. Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
D.1 International Technical Support Organization publications

For information on ordering these ITSO publications see “How to get ITSO
Redbooks” on page 109.
• SAP R/3 Implementation for AS/400, SG24-4672
• DB2/400: Mastering Data Warehousing Functions, SG24-5184
• Data Warehousing Solutions on the AS/400, SG24-4872
• From Multiplatform Operational Data to Data Warehousing and Business
Intelligence, SG24-5174
• Slicing the AS/400 with Logical Partitioning: A How to Guide, SG24-5439
D.2 Redbooks on CD-ROMs

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs
offered, updates and formats.
CD-ROM Title Collection Kit
Number
System/390 Redbooks Collection SK2T-2177
Networking and Systems Management Redbooks Collection SK2T-6022
Transaction Processing and Data Management Redbooks Collection SK2T-8038
Lotus Redbooks Collection SK2T-8039
Tivoli Redbooks Collection SK2T-8044
AS/400 Redbooks Collection SK2T-2849
Netfinity Hardware and Software Redbooks Collection SK2T-8046
RS/6000 Redbooks Collection (BkMgr) SK2T-8040
RS/6000 Redbooks Collection (PDF Format) SK2T-8043
Application Development Redbooks Collection SK2T-8037

D.3 Other sources of information
IBM publications
• DB2 for AS/400 SQL Programming, SC41-5611
• AS400e Backup and Recovery, SC41-5304
• AS400e Work Management, SC41-5306
• AS/400 Security - Basic, SC41-5301
• AS/400 System Operation, SC41-4203
• AS/400e TCP/IP Configuration and Reference, SC41-5420
• AS/400e CL Programming, SC41-5721
Internet sites
• AS/400 home page: http://www.as400.ibm.com
• SAP home page: http://www.sap.com
• SAP Business Information Warehouse:
http://www.sap.com/products/bw/index.htm
• AS/400 Business Intelligence home page:
http://www.as400.ibm.com/sftsol/bihome.htm
• AS/400e Information Center: http://www.as400.ibm.com/infocenter
• AS/400 Technology Solution Center - ERP:
http://www.as400.ibm.com/service/bms/support.htm
• AS/400 Performance: http://ca-web/perform/perfmenu.htm
• AS/400 Teraplex Integration Center:
http://www.as400.ibm.com/developer/bi/teraplex/index.html
• AS/400 Online Library:
http://as400bks.rochester.ibm.com/bookmgr/home.htm
• IBM Solution developer: http://w3.rchland.ibm.com/projects/
• The Data Warehousing Institute: http://www.dw-institute.com
• Guide to OLAP terminology:
http://www.cnit.nsu.ru/~buka/dict/dic_olap.htm
• Neil Raden: Modeling the Data Warehouse:
http://netmar.com/mall/shops/nraden/iw0196_1.htm

How to get ITSO Redbooks
This section explains how both customers and IBM employees can find out about ITSO redbooks,
redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
• Redbooks Web Site http://www.redbooks.ibm.com/
Search for, view, download, or order hardcopy/CD-ROM redbooks from the redbooks Web site. Also
read redpieces and download additional materials (code samples or diskette/CD-ROM images) from
this redbooks site.
Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a few
chapters will be published this way. The intent is to get the information out much quicker than the
formal publishing process allows.
• E-mail Orders
Send orders by e-mail including information from the redbooks fax order form to:
e-mail address
In United States usib6fpl@ibmmail.com
Outside North America Contact information is in the “How to Order” section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl/
• Telephone Orders
United States (toll free) 1-800-879-2755
Canada (toll free) 1-800-IBM-4YOU
Outside North America Country coordinator phone number is in the “How to Order”
section at this site:
• Fax Orders
United States (toll free) 1-800-445-9269
Canada 1-403-267-4455
Outside North America Fax phone number is in the “How to Order” section at this site:
This information was current at the time of publication, but is continually subject to change. The latest
information may be found at the redbooks Web site.
IBM Intranet for Employees

IBM employees may register for information on workshops, residencies, and redbooks by accessing
the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button.
Look in the Materials repository for workshops, presentations, papers, and Web pages developed
and written by the ITSO technical professionals; click the Additional Materials button. Employees
may access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Redbook Fax Order Form
Please send me the following:

Title Order Number Quantity
First name Last name
Company
Address
City Postal code Country
Telephone number Telefax number VAT number
Invoice to customer number
Credit card number
Credit card expiration date Card issued to Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.

Glossary
access plan. Plan generated by the OS/400 two types of data: key figures and
Query Optimizer of how to access the data in characteristics.
the tables being queried. InfoObject. Generic term for characteristics and
Business Explorer. SAP BW reporting tool. key figures.
characteristic. An element of a business such InfoPackage. A description of data that should

as: company code, product, material, or fiscal be requested from a source system.
year. Also an element of a dimension. informational data. Data created from
data loading. A process of loading data from operational data, stored in a format that makes
source systems into the BW InfoCube. easier business analysis. Analysis can be in the
form of decision support (queries), report
data extraction. Pulling the data out of its generation, Executive Information Systems, or
source system (or systems) and putting it into a statistical analysis.
warehouse-usable form.
InfoSource. A quantity of InfoObjects grouped
database table. See table. together from a business point of view. It can
data warehouse. A database that contains contain either transaction data or master data.
summarized data created from transactional key figure. Values or quantities such as
data found in the OLTP system. revenue, costs, number of employees.
database. A means of data storage. legacy system. A system that has been in
delta update. A type of database update. place for a significant period of time. Serves as
Refreshes only data changed since the last a source system for a data warehouse.
extraction. See also full update. master data. Data that remains unchanged
dimension. Grouping characteristics that over a long period time, for example, customer
belong together from a content point of view. For names and addresses.
example, a customer dimension may contain the meta data. Data about data. Meta data
customer number, the customer group, and the describes format, origin, history, and other
levels of customer hierarchy. aspects of data.
drill down. A technique that allows you to multidimensional database. A specialized
explore the detailed data that was used in database that is designed to enable the
creating a summary level data. In BW, this is querying and viewing of large volumes of data
one of the navigation techniques. based on predefined dimensions such as
fact table. A table that contains all key figures geography, customer, and product.
(facts) of the InfoCube. It is the central table in multidimensional table. See multidimensional
the star schema. database.
flat file. A file that contains text. It is used to navigation. Analysis of the InfoCube by
load information into the data warehouse. It can displaying different views of the data of a query.
be comma-delimited, fixed-width or variable
width. navigation attributes. Attributes that allow you
to present different views of the data.
full update. A type of database update.
Replaces all data. See also delta update. N-way system. A system with two or more
CPUs.
InfoCube. A multidimensional central data
container for queries and evaluations. Contains

OLAP. Online analytical processing (OLAP) is a
type of processing used to analyze summarized
online transaction processing (OLTP) data. OLAP
allows multidimensional views and analysis of
that data for decision support processes.
OLTP. Online transaction processing (OLTP) is a
type of processing of operational data.
operational data. Data that is used to run a
company’s business. It is stored, retrieved, and
updated by an OLTP system.
query. A selection of InfoObjects (characteristics
and key figures) for the analysis of the data in an
InfoCube.
schema. The logical and physical definition of
data elements, for example, a star schema.
source system. Every system that is available in
the Business Warehouse for the data extraction.
staging engine. Implements data mapping and
data transformation during the data loading
process. It extracts data from a source system.
star schema. A data structure that combines fact
tables and dimension tables in a way that
provides easy and efficient access to data.
SQL. Structured Query Language (SQL) is a
language developed by IBM that provides access
to relational database.
table. An array of data in a table form. It consists
of columns (data values of the same type) and
rows (data records). Each record can be
identified uniquely by one or several fields.
table index. Index used to accelerate data
selection from a table. It is similar to a copy of the
table reduced to certain fields only and always
sorted.
temporary index. Index built "on the fly" by the
OS/400 Query Optimizer. It does not exist after
the query is ended.
think time. The time that the end-user spends
between two key-presses.
transaction data. Operational data provided by
an OLTP system.

List of abbreviations
ABAP advanced business

application programming
APAR authorized problem
analysis report
ASP auxiliary storage pool
BAPI business application
programming interface
BW SAP Business Information
Warehouse
GUI graphical user interface
EVI encoded vector index
IBM International Business
Machines Corporation
ISICC International SAP IBM
Competence Center
ITSO International Technical
Support Organization
LPAR logical partitioning
OLAP on-line analytical
processing
OLTP on-line transaction
processing
PTF program temporary fix
SPAM SAP Patch Manager
RDBMS relational database
management system
SQL structured query language

Index
D
data access methods 4
A
auxiliary storage pools (ASPs) 14, 17 DB2 4
dimension 3, 4
Display Database Relation (DSPDBR) command
B 63
backup and recovery 23 Display File Field Description (DSPFFD) command
Business Application Programming Interface (BAPI) 79
Data BAPI 43
Meta Data BAPI 43
business application programming interface (BAPI) F
1, 43 fact table 3
Business Information Warehouse
Administrator Workbench 1 G
Business Explorer 1 Grant Object Authority (GRTOBJAUT) command
characteristics 2 25
components 1
configuration examples 88
database 1 I
index
Delete InfoCube indexes function 59
deleting index 59
Dim ID 3
permanent index 68
Extractor 12, 44
InfoCube design 32
front-end 1
International SAP IBM Competence Center (ISICC)
InfoCube 3
87
InfoObjects 2
installation 7
kernel 1 L
key figures 2 Load and Run (LODRUN) command 8
meta data repository 1 Logical Partitioning (LPAR) 14 , 18
prerequisites 7
SAPGUI 1
SID table 3
M
master data table 4
sizing 87
memory pools 14
Statistics 47
system administration 85
system administrator 2 P
system landscape 14 parallel load 65
parallel processing 48
C
Change Journal (CHGJRN) command 25 Q
Change Query Attributes (CHGQRYA) command query
51, 57 long-running query 68
Copy File (CPYF) command 38 optimizer 4
Copy To Stream File (CPYTOSTMF) command 41 performance analysis 72
Create Physical File (CRTPF) command 39

R
RSA1 33, 42, 47, 62, 85
S
Save and Delete Receivers (SAVDLTRCV) com-
mand 24
Save R/3 System (SAVR3SYS) command 23
SE11 80
SQL
analyze SQL functions 75
explain SQL function 75
SQL Utility (SQLUTIL) 38
trace 74
ST03 47, 60, 81
ST05 47, 74
Stop Save and Delete Receivers (SAVDLTRCVE)
command 24
Submit Job (SBMJOB) 25
Symmetric Multiprocessing (SMP) 50
system value
Parallel Processing Degree (QQRYDEGREE)
51, 54, 57
Performance Adjustment (QPFRADJ) 14
T
tuning techniques 47
W
Work with Journal Attributes (WRKJRNA) command
25
Work with Shared Pools (WRKSHRPOOL) com-
mand 15
Work with System Status (WRKSYSSTS) command
15

ITSO Redbook evaluation
SAP Business Information Warehouse on the AS/400 System
SG24-5200-00
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this
questionnaire and return it using one of the following methods:
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Fax this form to: USA International Access Code + 1 914 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Which of the following best describes you?

_ Customer _ Business Partner _ Solution Developer _ IBM employee
_ None of the above
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction __________
Please answer the following questions:
Was this redbook published in time for your needs? Yes___ No___
If no, please explain:
What other redbooks would you like to see published?
Comments/Suggestions: (THANK YOU FOR YOUR FEEDBACK!)

SAP Business Information Warehouse on the AS/400 System SG24-5200-00
Printed in the U.S.A.
SG24-5200-00

Sap Business Information Warehouse On The As 400 System

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sap Business Information Warehouse On The As 400 System

Enviado por

Direitos autorais:

Formatos disponíveis

SAP Business Information Warehouse

on the AS/400 System

Aco Vidovic, Manfred Engelbart, Kelly Murphy

International Technical Support Organization

International Technical Support Organization

SAP Business Information Warehouse

First Edition (August 1999)

Comments may be addressed to:

© Copyright International Business Machines Corporation 1999. All rights reserved.

Chapter 2. Installation and set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Chapter 3. Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 4. Loading the BW with data . . . . . . . . . . . . . . .. . . . . .. . . . . 29

© Copyright IBM Corp. 1999 iii

Chapter 6. Sizing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Appendix A. Files used in the example of InfoCube data loading . . . . 91

Appendix B. RPG ILE preparation program . . . . . . . . . . . . . . . . . . . . . . . 95

Appendix C. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Appendix D. Related publications . . . . . . . . . . . . . . . . . . . . . . . ...... . 107

How to get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

List of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

ITSO Redbook evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

iv SAP Business Information Warehouse on the AS/400 System

vi SAP Business Information Warehouse on the AS/400 System

The team that wrote this redbook

Aco Vidovic is an Advisory International Technical Support Specialist at the

Kelly Murphy is a Senior I/T Specialist with IBM Global Services in

© Copyright IBM Corp. 1999 ix

x SAP Business Information Warehouse on the AS/400 System

We want our redbooks to be as helpful as possible. Please send us your

SAP Business Information Warehouse (BW) is a data warehouse solution

BW system in the AS/400 environment runs on AS/400 server (or servers)

PC workstations run BW frontend software (SAPGUI) that provides

© Copyright IBM Corp. 1999 1

Native OS/400 terminology uses different names as shown in Table 1.

SQL terms Native OS/400 terms

Table Physical file

Index Access path or logical file (depends on

View Logical file

SQL collection Library

In this document, we mostly use the SQL terminology.

2 SAP Business Information Warehouse on the AS/400 System

Key figures are values or quantities in a company’s business, such as sales

The largest organizational unit is an InfoCube. You can think of an InfoCube

Figure 1 shows how tables are linked together in BW InfoCube.

Fact table Dimensiontable SIDtable Masterdatatable

1 10.50 1 1 111111 1 111111 1

Figure 1. BW tables relationships

OS/400 Query Optimizer

4 SAP Business Information Warehouse on the AS/400 System

For more information on AS/400 data access methods, refer to these

The installation procedure of BW is similar to the installation of SAP R/3.

© Copyright IBM Corp. 1999 7

You can install BW to AS/400 system in one of two ways:

8 SAP Business Information Warehouse on the AS/400 System

(No previous commands or messages)

F3=Exit F4=Prompt F9=Retrieve F10=Include detailed messages

Figure 2. Loading BW installation files to the AS/400 system

This command creates library R3SETUP on your AS/400 system and

Installation and set up 9

1. Copy Installation Files from CD

8. Display R/3 System configuration

F3=Exit F4=Prompt F9=Retrieve F12=Cancel

SAP system ID . . . . . . . . . ENV Character value, ENV

Include or omit . . . . . . . INCLUDE, OMIT