SAP Business Information Warehouse on the as 400 System

SG24-5200-00

International Technical Support Organization

http://www.redbooks.ibm.com

SAP Business Information Warehouseon the AS/400 System

Aco Vidovic, Manfred Engelbart, Kelly Murphy

SAP Business Information Warehouseon the AS/400 System

August 1999

SG24-5200-00

International Technical Support Organization

© Copyright International Business Machines Corporation 1999. All rights reserved.Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

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 OrganizationDept. JLU Building 107-23605 Highway 52NRochester, Minnesota 55901-7829

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.

Before using this information and the product it supports, be sure to read the general information inAppendix C, “Special notices” on page 103.

Take Note!

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ixThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 BW environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Chapter 2. Installation and set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Installing the BW Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 Objects created during the BW installation . . . . . . . . . . . . . . . . . 13

2.3 System landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.1 Multiple BW systems on one AS/400 system . . . . . . . . . . . . . . . 142.3.2 OS/400 Logical Partitioning (LPAR) . . . . . . . . . . . . . . . . . . . . . . 182.3.3 System landscape examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 3. Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1 BW system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Journal receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Saving the entire AS/400 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 4. Loading the BW with data . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1 Loading the AS/400 legacy application data . . . . . . . . . . . . . . . . . . . . 29

4.1.1 File interface — An example. . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.2 Business application programming interface . . . . . . . . . . . . . . . . 43

4.2 Loading the SAP R/3 data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Chapter 5. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1 Performance monitoring tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1.1 AS/400 system tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.1.2 BW tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 Tuning techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3 BW and OS/400 parallel processing . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3.1 Symmetric Multiprocessing (SMP) . . . . . . . . . . . . . . . . . . . . . . . 505.4 Analysis of BW performance behavior . . . . . . . . . . . . . . . . . . . . . . . . 59

© Copyright IBM Corp. 1999 iii

5.4.1 Loading the BW with data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.4.2 Long-running query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.4.3 BW system administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Chapter 6. Sizing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.1 CPU requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.2 Memory requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.3 Disk space and disk arms requirements . . . . . . . . . . . . . . . . . . . . . . . 886.4 Additional considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107D.1 International Technical Support Organization publications. . . . . . . . . . . 107D.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107D.3 Other sources of information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

How to get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109IBM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32. Loading BW installation files to the AS/400 system. . . . . . . . . . . . . . . . . . . 93. R/3 installation menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104. Unpacking the patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115. Change the installation files directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126. WRKSYSSTS — Allocating memory pool size . . . . . . . . . . . . . . . . . . . . . 157. WRKSHRPOOL — Memory pool priority. . . . . . . . . . . . . . . . . . . . . . . . . . 168. STOPSAP — Stop R/3 system with ENDSBS option . . . . . . . . . . . . . . . . 179. Landscape 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910. Landscape 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1911. Landscape 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2012. Landscape 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013. Save R/3 System (SAVR3SYS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2414. SBMJOB — Start SAVDLTRCV command . . . . . . . . . . . . . . . . . . . . . . . . 2615. WRKACTJOB — SAVDLTRCV command . . . . . . . . . . . . . . . . . . . . . . . . 2716. Source database design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3117. SOCUBE data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3418. SOCUBE data model expanded view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3519. SOCUBE tables — Partial view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3620. Source table conversion forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3721. CPYF from form 1 to form 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3822. Sample SQL — Convert form 2 into form 3 . . . . . . . . . . . . . . . . . . . . . . . . 3923. CRTPF — Create intermediate table (form 4) . . . . . . . . . . . . . . . . . . . . . . 4024. CPYF — Copy table to a single-column form . . . . . . . . . . . . . . . . . . . . . . 4025. CPYTOSTMF — Copy table into a flat file. . . . . . . . . . . . . . . . . . . . . . . . . 4126. Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4327. N-way processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4928. SMP processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4929. Go LICPGM —> Display installed licensed programs . . . . . . . . . . . . . . . . 5030. ST03 — BW query performance analysis without SMP. . . . . . . . . . . . . . . 5231. WRKACTJOB — CPU utilization of BW query without SMP . . . . . . . . . . . 5332. WRKSYSVAL — Change system value QQRYDEGREE . . . . . . . . . . . . . 5433. WRKACTJOB — CPU utilization of BW query with SMP . . . . . . . . . . . . . 5534. Transaction ST03 — BW query performance analysis with SMP . . . . . . . 5635. CHGQRYA — Change query attribute of a job . . . . . . . . . . . . . . . . . . . . . 5836. ST03 — BW fact table data loading with indexes attached . . . . . . . . . . . . 6037. WRKACTJOB — Data loading with indexes . . . . . . . . . . . . . . . . . . . . . . . 6138. WRKDSKSTS — Disk status during data loading . . . . . . . . . . . . . . . . . . . 6239. Delete InfoCube indexes before data loading . . . . . . . . . . . . . . . . . . . . . . 6340. BW fact table data loading without indexes attached . . . . . . . . . . . . . . . . 64

v

41. SAP parallel load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6642. DB2 Symmetric Multiprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6643. WRKACTJOB — Parallel load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6744. WRKDSKSTS — Disk arm utilization during parallel load . . . . . . . . . . . . . 6845. RSA1 — InfoCube Customer data model . . . . . . . . . . . . . . . . . . . . . . . . . 6946. SAP Business Explorer Analyzer —> Define query. . . . . . . . . . . . . . . . . . 7047. Starting the 0SD_C01_Q013 query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7148. Query result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7249. WRKACTJOB — BW query running with SMP enabled . . . . . . . . . . . . . . 7350. ST03 — BW query transaction analysis, SMP enabled. . . . . . . . . . . . . . . 7451. ST05 — SQL trace overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7552. ST05 — Explain SQL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7653. ST05 — Explain SQL statement —> Expand subtree . . . . . . . . . . . . . . . . 7754. SQL SYSTABLES — Assign short/alternate table names. . . . . . . . . . . . . 7955. DSPFFD — Map field names with alternate field names. . . . . . . . . . . . . . 8056. SE11 — Create permanent index for BW database . . . . . . . . . . . . . . . . . 8157. ST03 — Query monitoring with permanent index for table /BI00285. . . . . 8258. ST05 — SQL trace overview with permanent index available . . . . . . . . . . 8359. ST05 — Explain SQL statement, index available . . . . . . . . . . . . . . . . . . . 84

vi SAP Business Information Warehouse on the AS/400 System

Tables

1. OS/400 terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22. Libraries created during the installation of BW . . . . . . . . . . . . . . . . . . . . . 133. Backup activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234. Table Trans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315. Table Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326. Table Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327. OLTP versus OLAP workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458. Effect of performance improvement techniques in BW . . . . . . . . . . . . . . . 489. Query runtime comparison with and without SMP. . . . . . . . . . . . . . . . . . . 5610. Runtime comparison — Data loading of fact table. . . . . . . . . . . . . . . . . . . 6411. Data loading test results summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6512. Tables in the InfoCube Customer — Test data . . . . . . . . . . . . . . . . . . . . . 7113. Field names with their alternate field names . . . . . . . . . . . . . . . . . . . . . . . 8014. Query 0SD_C01_Q013 runtime comparison . . . . . . . . . . . . . . . . . . . . . . . 8515. Table Trans1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9116. Table Transch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9217. Flat file Part.csv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9318. Flat file Cust.csv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9319. 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 theAS/400 system. It takes a close look at the tasks and functions that arespecific for the AS/400 environment, rather than the BW generic task. Thisredbook is designed to assist AS/400 technical specialists and SAP Basisconsultants 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 onlinetransactional processing (OLTP) system that runs a company’s day-to-daybusiness (requires that you already understand BW administrator tasksrelated 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 performancetopics)

• Preliminary sizing recommendations based on tests and SAPrecommendations

The team that wrote this redbook

This redbook was produced by a team of specialists from around the worldworking at the International Technical Support Organization Rochester.

Aco Vidovic is an Advisory International Technical Support Specialist at theInternational Technical Support Organization, Rochester Center. He is amember of the ERP team, where he is responsible for SAP. He has nine yearsof experience in AS/400 technical support, sales, and marketing. Beforejoining the ITSO, he worked in the IBM Central Europe and Russia MidrangeSystems Marketing team.

Kelly Murphy is a Senior I/T Specialist with IBM Global Services inRochester, Minnesota. She has worked at IBM for 18 years. Kelly’s list ofprojects includes, among others, implementation of a data warehouse in anSAP 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 BasisConsultant in IBM Germany. He belongs to the ERP Solution Sales team inthe central region. Manfred has 11 years of experience in the AS/400 fieldand has worked at IBM for 24 years. He also co-authored the ITSO redbookSAP R/3 implementation for AS/400, SG24-4672.

Thanks to the following people for their invaluable contributions to this project:

Barbara BallardGeorge BartaDave HubkaDan MoravecRon SchmerbauchIBM Rochester, SAP Port

Nitin RautIBM Rochester, Technology Solutions Center

Amy AndersonIBM Rochester, Teraplex Center

Bryan TousleyIBM Rochester, Partners in Development

Daniel ToftIBM Rochester, Performance

Raymond BillsIBM Rochester, Integrated File Systems

Jarek MiszczykGottfried SchimunekInternational 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 yourcomments about this or other redbooks in one of the following ways:

• Fax the evaluation form found in “ITSO Redbook evaluation” on page 117to 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: [email protected]

xi

xii SAP Business Information Warehouse on the AS/400 System

Chapter 1. Introduction

SAP Business Information Warehouse (BW) is a data warehouse solutiontailored to SAP R/3. It is a separate application (an add-on) that isindependent from SAP R/3 and has its own release and shipment cycle. SAPR/3 belongs to the category of online transaction processing (OLTP)applications that are used to run day-to-day business. BW is an onlineanalytical processing (OLAP) application that is used to support businessdecisions by providing information analysis and reporting capabilities. Thisdocument covers BW release 1.2B, which is based on SAP R/3 release 4.5Btechnology.

1.1 BW environment

BW consists of several components that are used for data collection, datause, and data maintenance. These components include:

• Business Information Warehouse Server with OLAP processor andStaging Engine

• Meta data (data about data) repository that documents the datawarehouse environment

• Business Explorer, a graphical user interface (GUI), hosted by MicrosoftExcel or Lotus 1-2-3, that provides analyzing and viewing functions forend-users

• Automated data extraction and data loading routines

• Administrator Workbench, a GUI-based tool that is used for BWimplementation, maintenance, customizing, scheduling, and monitoring

• Business application programming interface (BAPI) that provides links toexternal 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 SAPR/3 kernel)

• BW application code written in advanced business applicationprogramming (ABAP)

• BW database that contains all user data and system data

PC workstations run BW frontend software (SAPGUI) that providespresentation 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 theBusiness Explorer that is installed on their PC, in addition to the SAPfront-end. When end-users want to access BW data, they run a query fromthe Business Explorer. Business Explorer invokes a creation of a temporaryABAP program on the AS/400 server, which finds the requested data andsends 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 inflat files (also called stream files) in the Integrated File System (IFS). Therelational database consists of two-dimensional files that are in SQLterminology called tables. Tables are made up of columns and rows. Indexesand views are built upon the tables to provide users with quick access todata. 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

In this document, we mostly use the SQL terminology.

BW terminologyIn addition to DB2 data structures, BW organizes data in its own datastructures.

The basic building blocks of BW are called characteristics and key figures.The generic term for characteristics and key figures is InfoObjects. When youcreate the data warehouse on your BW system, you start by creating yourInfoObjects.

SQL terms Native OS/400 terms

Table Physical file

Column Field

Row Record

Index Access path or logical file (depends oncontext)

View Logical file

SQL collection Library

2 SAP Business Information Warehouse on the AS/400 System

Characteristics are the elements of a company’s business, for examplecompany code, product, material, customer group, fiscal year, period, orregion. They are stored in tables called dimension tables.

Key figures are values or quantities in a company’s business, such as salesrevenue, fixed costs, sales quantity, or the number of employees. They arestored in tables called fact tables.

A fact table contains all of the key figures at the lowest level of detail. Adimension table contains characteristics that are required both in reportingand in the analysis of the key figures. Characteristics are grouped into adimension table based on a business content logic. Dimension tables areindependent of one another. Only the fact table connects dimension tablesthrough key figures.

The largest organizational unit is an InfoCube. You can think of an InfoCubeas a data mart. It is a subset of a data warehouse designed to fit the needs ofa specific group of users. An InfoCube is used to answer specific end-user’squeries and to provide information for specific analysis. It consists of anumber of relational tables that are put together in a star schema. There isalso a large fact table in the center that is surrounded by several dimensiontables.

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

Figure 1. BW tables relationships

Dimension tables are linked to the fact table using surrogate keys. Asurrogate key (Dim ID) is used as a unique key with each dimension table.The master data table and the dimension table are linked by systemgenerated identifications called Set IDs that are stored in SID (Set ID) tables.

Dim ID Cost

1 10.50

2 100.00

3 5.00

DimID

SIDPart

1 1

2 2

3 3

Part SIDName

111111 1

222222 2

333333 3

Part PartName

111111 1

222222 2

333333 3

Fact table Dimensiontable SIDtable Masterdatatable

Introduction 3

The master data table contains attributes of characteristics, while thedimension table contains the characteristics themselves. The dimension tablewith 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 (inthis document we call it DB2). DB2 is a Relational Database ManagementSystem (RDBMS) that is a part of the Operating System/400. Since it is a partof the system, DB2 fully utilizes all the AS/400 features. Compared to otherRDBMS products on the market, DB2 brings to BW users a number of uniquefeatures, 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 bepartitioned. For this reason, there is no distinction between primary andsecondary 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 OptimizerThe optimizer is the OS/400 Query component that makes key decisions forgood database performance. It identifies the methods that can be used toimplement the query and selects the most efficient method at query runtime.The optimizer selects an optimal access method for the given query bycalculating an implementation cost that is based on the current state of thedatabase. This makes it different from rule-based optimizers that access thedata, based on pre-defined rules, which must be updated manually by thedatabase administrator.

Possible data access methods that the optimizer may choose are:

• Non-keyed access methods: Table scan, parallel table scan, parallelpre-fetch, parallel table pre-load, skip sequential with dynamic bitmap, andparallel skip sequential

• Keyed access methods: Key positioning and parallel key positioning,dynamic bitmaps (index ANDing or ORing), key selection and parallel keyselection, 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 accessthe requested data. This access plan is built during the optimization, whenthe query is run for the first time. The optimizer estimates the query accesscost 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 theaccess methods as well. Depending on the estimated costs, the optimizermay use any of the available methods to access the requested data. Weshow you an example of how you can observe and partly influence theoptimizer’s decisions in 5.4.2.2, “Query performance analysis” on page 72.

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

• 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 BWup and running. It lists the tasks and provide some hints on how to approachthe installation of BW on the AS/400 server. Since this chapter does notdescribe every installation step in detail, it should serve as a reference ratherthan a detailed installation guide. For a detailed description of the installationand setup tasks, please refer to the BW installation guide (scheduled to bepublished 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 followingprerequisites:

• Hardware

– Server: AS/400 server with PowerPC technology. Chapter 6, “Sizingconsiderations” on page 87, provides preliminary sizing guidelines.

– Workstation: A PC with a minimum of 48 MB of main memory onWindows 95, 64 MB on Windows NT, and 1 GB disk space. To workcomfortably with BW, we recommend that you double the memory size.

• Software

– Server:

• OS/400 V4R4 with TCP/IP installed. It is technically possible to runBW on OS/400 V4R3. However, we do not recommend it since it isnot supported by IBM and SAP.

• AS/400 PTFs listed in IBM APAR number II11832 (for V4R4) ornumber II11296 (for V4R3).

• SAP Business Information Warehouse release 1.2B installation CDswith documentation.

• BW patches specified in SAP OSS note 0149750.

• OS/400 optional, chargeable feature "DB2 SymmetricMultiprocessing 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/400is very helpful.

2.2 Installation

First, install the BW front-end to the administrator’s PC from the installationCD. BW front-end installation is described in detail in the brochure FrontendInstallation (Mat. No. 5100 3943). Install all program temporary fixes (PTFs)on the AS/400 system as recommended in IBM Information APAR for yourOS/400 release. You can get this APAR in AS/400 APAR database on theInternet 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/IPconnection configured between the PC and the AS/400 server. Thisinstallation is performed from the SAP front-end.

• Directly on the AS/400 system: This installation is performed from anAS/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 thenecessary changes in AS/400 system settings as described in the SAPBW Installation Guide.

2. Insert the installation CD into the AS/400 CD-ROM drive. Load theinstallation objects using the Load and Run (LODRUN) command asshown in Figure 2 on page 9.


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

This command creates library R3SETUP on your AS/400 system andadds it to your library list. When loading is finished, you get the R/3Installation menu on your screen.

3. Select option 1 to copy the installation files from the CD to the AS/400system (Figure 3 on page 10).

Command Entry RCHASR7DRequest level: 4

Previous commands and messages:

(No previous commands or messages)

BottomType command, press Enter.===> lodrun *opt dir('/os400/as400/install')

F3=Exit F4=Prompt F9=Retrieve F10=Include detailed messagesF11=Displayfull F12=Cancel F13=InformationAssistant F24=Morekeys

Installation and set up 9

Figure 3. R/3 installation menu

Press Enter. Then, you are prompted for the SAP System ID (SID) thatyou want to install. After doing so, the directory /tmp/<sid> where theinstallation files will be copied is created. <sid> is the SID that youspecified.

4. Install the BW central instance with a database by selecting option 2 onthe R/3 Installation menu. Then, specify the installation file name or filenames in case you are installing a three-tier environment. If you areinstalling a two-tier environment, specify the file CENDBBW.R3S. If you areinstalling a three-tier environment, specify the file CENTRAL.R3S and thenthe file DBBW.R3S. This task may take several hours.

5. Install all BW patches specified in SAP OSS note 0149750. Downloadthe patches to your PC in one of two ways:

• From the SAPNet Internet home page at http://sapnet.sap.comYou need to have a user ID provided by SAP to logon to SAPNet.

• From the SAP service system by logging on to SAP system CSSfrom 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

R3SETUP R/3 InstallationSystem: RCHASR7D

Select one of the following:

1. Copy Installation Files from CD2. Install R/3 Systems and Instances3. Work with SAP license information4. Change the location of the /usr/sap/trans directory5. Load RFC SDK library6. Load CPI-C SDK library

8. Display R/3 System configuration9. Create R/3 System objects10. Delete R/3 System objects11. Create R/3 Instance objects12. Delete R/3 Instance objects

Selection or command===> 1

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


example) as long as you transfer the patches in binary format. Thepatches are in compressed files with the file extension CAR.

b. On the AS/400 screen, change your current directory to a directorythat contains compressed patches by using the command:

cd '/usr/sap/trans'

c. Decompress (unpack) the patches using the SAP command CAR asshown in Figure 4.

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 PatchManager (SPAM). Make sure you are logged on to client 000 with auser that is authorized to apply patches (for example, user DDIC).Start SPAM with SAP transaction /nspam. Follow the regularprocedure for applying the SAP R/3 patches. Always apply only onepatch at a time. Applying the patches may take several hours.

6. Make a BW client copy, since none of the SAP supplied clients canwork 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 theAS/400 system.

Work with Object Links

Directory . . . . : /usr/sap/trans

Type options, press Enter.3=Copy 4=Remove 5=Next level 7=Rename 8=Display attributes11=Change current directory ...

Opt Object link Type Attribute Textsapnames DIRtmp DIREPS DIRKW12b03.CAR STMFKW12A02.CAR STMFKW12B01.CAR STMFKW12B02.CAR STMFKW12B04.CAR STMFKW12B05.CAR STMF

BottomParameters or command===> r3setup/car '-xvf /usr/sap/trans/KW12B01.CAR'F3=Exit F4=Prompt F5=Refresh F9=Retrieve F12=Cancel F17=Position toF22=Display entire field F23=More options


2.2.1 Installing the BW ExtractorYou start using BW by loading the data warehouse with operational data fromyour source system. If the source system runs SAP R/3, use the BW featureExtractor 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 SAPcentral 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 withthe software) for details on how to prepare and perform the installation of theExtractor. Note these tasks:

1. When loading the Extractor files from the installation CD to the AS/400disk, use the following command:

LODRUN *OPT DIR('/40B_INST/OS400/AS400')

The DIR parameter specifies the directory name where the installationfiles are located. The first three characters in the directory name reflectthe R/3 release on the database server. In this example, the databaseserver 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 inFigure 5.

Figure 5. Change the installation files directory

3. Proceed according to installation instructions. When you are prompted forthe Server Operation mode, select Scroll.

Change Current Directory (CD)

Type choices, press Enter.

Directory . . . . . . . . . . . '/QOPT/CD51005919/40B_INST/OS400/AS400'

BottomF3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this displayF24=More keys


2.2.2 Objects created during the BW installationThe installation and setup procedures create several libraries that you canrecognize 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

In addition to the libraries, the following directory trees are created in theintegrated file system (IFS):

• /usr/sap/• /sapmnt/

These IFS directories contain documents that are not stored in the BWdatabase, for example, spooled files or transports.

Library name Content Number ofobjects

Initial sizein MB

R3<SID><xxxxx>1 SQL packages (several libraries) 927 181

R3<SID>DATA BW database with tables, views,indexes, journal, programsources, and compiled modules

4949 2488

R3<SID>JRN Journal receivers 1 1.3

R3<SID>400 Work management objects(subsystem descriptions,classes...)

6 82

R3400 Global objects (output queues,data queues, user spaces...)

17 64

R3<REL>OPT2 SAP kernel with executable code 450 327

R3WRKxx SAP instance specific objects, forexample user spaces

0 0

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.


2.3 System landscape

The SAP recommended BW landscape consists of three BW systems:

• Test system (also called Development system or Sandbox) for testing andapplication 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 systemIf you decide to install more than one SAP BW or R/3 system on a singleAS/400 system (we will call it a machine), you have several options to isolateone 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) withdedicated I/O processors and a system bus.

• Use OS/400 logical partitioning.

When using multiple SAP systems on one machine, you also have toconsider potential performance impacts of one system on the other. EachSAP system requires resources to run (CPU, disk, main memory). Certainoperations can cause heavy loads in one or more resource type.

2.3.1.1 MemoryEach SAP BW or R/3 system runs in its own OS/400 subsystem. EachOS/400 subsystem runs in the OS/400 memory pool. The SAP systemtypically 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 (sharedmemory pool) or to run in separate memory pools. If they are sharing amemory pool, they are contending equally for the same resources. An SAPsystem that runs in a separate memory pool does not have other systemscontending for its memory. Therefore, it will perform better, providing that thesize of its memory pool is large enough.

The size of the memory pool can be either fixed or dynamically adjusted bythe AS/400 system. This is defined by the system value PerformanceAdjustment (QPFRADJ). If QPFRADJ is set to the value "0", and SAP


systems use separate memory pools, you can allocate a specific amount ofmemory to each memory pool. The allocated memory is not available tosubsystems that run outside that memory pool. The memory pool sizes arestatic. You can set memory pool sizes using the OS/400 command Work withSystem Status (WRKSYSSTS) as shown in Figure 6.

Figure 6. WRKSYSSTS — Allocating memory pool size

If the system value QPFRADJ is set to the value "2", OS/400 performsautomated dynamic performance tuning, which includes periodicaladjustments of memory pools sizes. This dynamic tuning checks the pagingrates and adjusts memory pool sizes to reduce paging. For example, ifmemory pool X has a lot of paging, and pool Y has little paging, OS/400 willmove some memory from pool Y to pool X. In case there are several poolsthat need more memory, the memory is allocated to the pool with a higherpriority as defined in the memory pool description. Use the OS/400 commandWork with Shared Pools (WRKSHRPOOL) to set priorities on the memory pools asshown in Figure 7 on page 16.

Work with System Status RCHASR7D07/26/99 17:00:19

% CPU used . . . . . . . : 2.8 Auxiliary storage:Elapsed time . . . . . . : 04:55:37 System ASP . . . . . . : 134.4 GJobs in system . . . . . : 2950 % system ASP used . . : 75.0605% addresses used: Total . . . . . . . . : 163.7 GPermanent . . . . . . : .033 Current unprotect used : 2399 MTemporary . . . . . . : 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 Pages1 102768 67084 +++++ .0 .0 .7 .82 880476 1484 187 .0 .1 .6 3.53 10484 0 6 .0 .0 .0 .04 54848 20 61 .0 .0 .4 .6

BottomCommand===>F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=RestartF11=Display transition data F12=Cancel F24=More keys


Figure 7. WRKSHRPOOL — Memory pool priority

The WRKSHRPOOL command is also used to protect the SAP system thatruns in the lower priority pool from losing so much memory that it can nolonger function. This is defined by setting the minimum percentage of totalmemory for a pool (Figure 7).

When ending the BW, consider ending the OS/400 subsystem as well. Thisreleases the memory allocated to that subsystem. If only BW is in thememory pool, then you should also end the subsystem. You can do this usingthe STOPSAP command with the parameter "End subsystem" set to *YES (thedefault 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.

Work with Shared PoolsSystem: 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 textF12=Cancel

Set the most performance-critical BW system (for example, productionsystem) to run in the *BASE pool and other systems in shared memorypools. Set the paging option of all memory pools in which SAP systems arerunning 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 orlower.

Recommendation


Figure 8. STOPSAP — Stop R/3 system with ENDSBS option

2.3.1.2 CPUProcessors are not allocated to OS/400 subsystems or SAP systems. Theyare always shared across all jobs running on the same AS/400 system (or alogical partition as described in the next section). However, CPU priority andtime slices can be managed at the subsystem level. This way you can alwaysallocate 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 andbatch BW processes in one BW system are running at different priorities.

2.3.1.3 DiskAuxiliary storage pools (ASPs) can be used to separate disk resources fordifferent SAP systems. You may assign a separate ASP to each SAP system.These ASPs can be grouped on their own IOP for further granularity. Aseparate ASP will protect users of SAP system X, for example, fromperformance impact of high disk arm activity produced by users of SAPsystem Y. However, this approach is generally not recommended. Anincreased number of ASPs reduces the number of disk arms in each ASP,which will, in most customer situations, reduce the performance of all SAPsystems.

Stop R/3 System (STOPSAP)


SAP system ID . . . . . . . . . *ENV Character value, *ENVR/3 instance . . . . . . . . . . *ENV Character value, *ENV, *ALLR/3 instance hostname . . . . . *LOCAL Character value, *LOCAL, *ALLWait for instance to end . . . . *YES *NO, *YESMaximum wait time (seconds) . . 120 10-999999End subsystem . . . . . . . . . *YES *NO, *YES



2.3.2 OS/400 Logical Partitioning (LPAR)In all examples mentioned in previous section, all SAP systems run in asingle copy of the Operating System/400. They also share the same CPU (orCPUs on N-way machine) with all other users of the machine. Sometimes thisis not a feasible environment, especially when you:

• Want to run BW systems on different releases of operating system (forexample, 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 ofthe operating system (even with different releases) on a single AS/400machine. LPAR divides an AS/400 machine into two or more logicalpartitions. A logical partition is a virtually independent system with its ownCPU (or CPUs), main memory, system bus (or buses), I/O processors, disks,a copy of OS/400, and all application software. The maximum number oflogical partitions on one machine is equal to number of available CPUs.Please refer to the redbook Slicing the AS/400 with Logical Partitioning: AHow to Guide, SG24-5439, for more information on LPAR.

2.3.3 System landscape examplesWith or without using LPAR, the BW landscape may be integrated with SAPR/3 (or another OLTP system) on the same AS/400 machine. Consider thefollowing examples:

• The BW test system and Integration system run on one machine (orLPAR). The production system runs on a second machine (or LPAR) asshown in Figure 9 on page 19.

Use one ASP for all SAP systems and another ASP for journal receivers.

Recommendation


Figure 9. Landscape 1

• SAP R/3 and BW both run on the same machine. The R/3 productionsystem runs in one LPAR, and the BW production system runs in a secondLPAR. The rationale behind this scenario is improved performance ofloading the BW with R/3 data (Figure 10).


• SAP R/3 system runs in one LPAR. BW test system and BW integrationsystem both run in a second LPAR. BW production system runs on asecond machine or a third LPAR on the same machine as shown in Figure11 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 asecond LPAR. The BW production system runs on a second machine (or athird 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 sameLPAR. The decision criteria depends on the amount of workload in eachsystem, performance requirements, backup and recovery policy, systemmanagement tasks, and costs among others. Please refer to sizing guidelinesin Chapter 6, “Sizing considerations” on page 87, for more information onsizing.


Chapter 3. Backup and recovery

Immediately after the BW is in production, there should be a backup andrecovery policy in place. While workstations have to be backed up onlyoccasionally (after all workstation software is installed or upgraded), most ofthe backup activities are done on the server side. Objects that should bebacked up include the database library that holds BW data and the programsource 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

3.1 BW system

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

What to backup When How

BW system with database,configuration, and accesspaths

Daily CommandSAVR3SYS

BW journal receivers inlibrary R3<SID>JRN

Continuously CommandsSAVDLTRCV andSAVDLTRCVE

Entire AS/400 system After:- installing and upgrading OS/400- installing AS/400 PTFs- installing and upgrading BW- installing BW patches

Menu SAVE,option 21.


Figure 13. Save R/3 System (SAVR3SYS)

Use the SAVR3SYS command when there are no active users on the system, forexample, 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 theSAVR3SYS 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 BWjournal receivers and backs them up after they are detached from the BWjournal. The AS/400 system detaches the BW journal receiver when itreaches a certain size. This is defined at the creation of the BW journal(QSQJRN in library R3<SID>DATA) with the attribute "Manage receivers" andthe attribute "Receiver size options". When the old receiver is detached, thesystem automatically creates a new receiver, attaches it to the journal, andsends a message to the message queue that you need to create for thispurpose. The SAVDLTRCV command gets a message that the journalreceiver was detached and saves the old receiver.

Save R/3 System (SAVR3SYS)


System ID . . . . . . . . . . . > BWA Character valueDevice . . . . . . . . . . . . . /QSYS.LIB/TAP01.DEVDPrompt save commands . . . . . . *NO *YES, *NOR/3 status during save . . . . . *DSCDB *DSCDB, *RUN, *ENDIFS files to save:Path name . . . . . . . . . . *SPTH

Include or omit . . . . . . . *INCLUDE, *OMIT+ for more values

Save R/3 database . . . . . . . *YES *YES, *NOSave R/3 configuration . . . . . > *YES *YES, *NOSave R/3 SQL packages . . . . . > *YES *YES, *NOSave reference date . . . . . . *ALL Date, *ALL, *LASTSAVESave reference time . . . . . . *ALL Time, *ALL, *LASTSAVEExpiration date . . . . . . . . *PERM Date, *PERMSave active wait time . . . . . 1200 Number, *NOMAX

More...F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this displayF24=More keys


The following sequence of events occurs:

1. Download the SAVDLTRCV save file from the SAPSERVx using the sameprocedure as for downloading SAP patches. The save file is located in thedirectory /general/R3server/patches/COMMON/OS400.

2. Create the SAVDLTRCV and SAVDLTRCVE commands, which are storedin the save file. Please refer to SAP OSS note 82079 for information onhow to create these two commands.

3. Make sure that the BW journal receivers are managed by the AS/400system. Use the Work with Journal Attributes (WRKJRNA) command to checkif the attribute "Manage receivers" is set to *SYSTEM. If it is not, thenchange 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/400Grant 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 ChangeJournal (CHGJRN) command:

CHGJRN (R3BWADATA/QSQJRN) MSGQ(R3BWA400/SAVDLTRCV)

7. Submit a batch job that will start the SAVDLTRCV command by using theSubmit Job (SBMJOB) command as shown in Figure 14 on page 26.

Backup and recovery 25

Figure 14. SBMJOB — Start SAVDLTRCV command

After the job is submitted, the SAVDLTRCV command will be active all thetime waiting for a message as shown in Figure 15 on page 27.

Submit Job (SBMJOB)


Command to run . . . . . . . . . > SAVDLTRCV MSGQ(R3BWA400/SAVDLTRCV) DEV(TAP01)

...Job name . . . . . . . . . . . . SAVDLTRCV Name, *JOBDJob description . . . . . . . . *USRPRF Name, *USRPRFLibrary . . . . . . . . . . . Name, *LIBL, *CURLIB

Job queue . . . . . . . . . . . *JOBD Name, *JOBDLibrary . . . . . . . . . . . Name, *LIBL, *CURLIB

Job priority (on JOBQ) . . . . . *JOBD 1-9, *JOBDOutput priority (on OUTQ) . . . *JOBD 1-9, *JOBDPrint device . . . . . . . . . . *CURRENT Name, *CURRENT, *USRPRF...

More...F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=CancelF13=How to use this display F24=More keys


Figure 15. WRKACTJOB — SAVDLTRCV command

The SAVDLTRCV should only be stopped during the execution of theSAVR3SYS command. You can stop it by running the SAVDLTRCVE commandbefore 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, fora description on how to save the entire AS/400 system.

Work with Active Jobs TSCSAP0207/21/99 14:17:10

CPU %: 1.1 Elapsed time: 00:00:02 Active jobs: 164

Type options, press Enter.2=Change 3=Hold 4=End 5=Work with 6=Release 7=Display message8=Work with spooled files 13=Disconnect ...

Opt Subsystem/Job User Type CPU % Function StatusQBATCH QSYS SBS .0 DEQWSAVDLTRCV BWAOFR BCH .0 CMD-SAVDLTRCV MSGW

QCMN QSYS SBS .0 DEQWQCTL QSYS SBS .0 DEQWQSYSSCD QPGMR BCH .0 PGM-QEZSCNEP EVTW

QINTER QSYS SBS .0 DEQWQPADEV0026 H41OFR INT .9 CMD-WRKACTJOB RUN

QSERVER QSYS SBS .0 DEQWQPWFSERVSD QUSER BCH .0 SELW

More...Parameters or command===>F3=Exit F5=Refresh F7=Find F10=Restart statisticsF11=Display elapsed data F12=Cancel F23=More options F24=More keys

Backup and recovery 27

Chapter 4. Loading the BW with data

This chapter describes two methods of loading a BW InfoCube withoperational data from an OLTP system. The method you choose depends onwhether your OLTP system is SAP R/3. If your OLTP system is SAP R/3, usethe method described in 4.2, “Loading the SAP R/3 data” on page 44. In anyother 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 datainto the Staging Engine in a flat file format. The flat file can be either in ASCIIor Microsoft Excel (CSV) format. The file interface requires manualmaintenance of meta data in BW. Therefore, SAP recommends that you usethis interface only in cases where the source data is already defined in a fileformat or when a quick solution is desired. We provide an example of usingthe file interface in the following section.

The BAPI interface allows the importing of transaction data, master data, andmeta data from the source system in an automated, repeatable way thatallows 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 exampleIn this section, we show an example of how to transfer the operational datafrom an AS/400 legacy application into the BW InfoCube using the fileinterface. In a real-life environment, this is a long process that requirescareful planning. It is documented in many data warehousing books. Ourexample 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 understandseveral 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 bedone 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 theInfoCube

• 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, andnavigation attributes

3. Prepare the source data for loading into BW. This includes:

• Changing and adding some columns in source tables to suit thebusiness analysis purposes of the InfoCube.

• Converting the source tables into the ASCII or CSV format. In ourexample, 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 tablesThis section describes the source data in our example. Figure 16 on page 31shows the design of the source system database. This database containssales data about customers and parts. For the sake of simplicity, not allcolumns are shown in Figure 16 on page 31.


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 aboutparts and customers. Its structure is shown in Table 4.

Table 4. Table Trans

Field Datatype

Fieldlength

Description Defaultvalue

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

Trans

Part Key

Quantity

Cost

Customer Key

Order Date

Currency

Part

Part Key

Part Name

Customer

Address

Customer key

Country

Region

Customer name

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

Table 6. Table Customer

All default values for both master tables are none.

4.1.1.2 Design of the InfoCubeThis section describes data structures defined in the InfoCube. BW includespre-defined structures that must be activated before they can be used.However, we chose to define our own InfoObjects, InfoCubes, andInfoSources. The InfoCube in this example is designed to help answerquestions 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 thetotal revenue?

After we determine the purpose that this InfoCube will serve, we design andcreate the InfoCube named SOCUBE with the following structure:

• InfoObjects defined as characteristics:

– Part number– Customer number– Date– Currency

Field Data type Field length Column heading

PARTKEY BINARY 9,0 Part number

PART CHAR 32 Part name

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


– 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 dataand has a part name attribute.

• Dimension Customer contains the date and customer number. Thecustomer 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 whenanalyzing date-related information.

• Dimension Unit contains currency.

• Country and Region are defined as our navigation attributes. This meansthat 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 theSAP transaction RSA1. Figure 18 on page 35 presents an expanded view ofthe 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. Forsimplicity sake, this figure includes only dimensions customer and part, whiledimensions time and unit are not shown. The time and unit dimensions alsohave a dimension table, SID table, and master data table. The relationshipsof the time and unit dimensions to the fact table and to each other are thesame as those depicted for the customer and part dimensions.


Figure 19. SOCUBE tables — Partial view

4.1.1.3 Preparing the source tablesThe BW Staging Engine accepts only ASCII or CSV files as input in dataloading. Therefore, the AS/400 DB2 tables need to be converted into theappropriate format before loading. We show two different ways to convert thetables and prepare them for loading:

• Manual preparation using AS/400 commands• Preparation with an RPG program

Manual preparation of source tablesManual preparation of each source table is done in four steps using CLcommands. During these steps, each table is converted into threeintermediate tables with different forms, before finally converted into a CSVfile.

Key_SOCUBEP

ORDQTY

ORDCOST

Key_SOCUBET

Key_SOCUBEU

Key_SOCUBE1

Key_SOCUBE2

Fact TableFile:/BIC/FSOCUBEShort:/BIC0059

DIMID

SID_PARTNO

Part DimensionFile:/BIC/DSOCUBE2Short:/BIC0057

DIMID

SID_CUNO

Customer DimensionFile:/BIC/DSOCUBE1Short:/BIC0055

SID_0DATE

CUNO

SID

Customer SID TableFilename:/BIC/SCUNOShort Name:/BIC0036

CHCKFL

DATAFL

INCFL

PARTNO

SID

Part SIDTableFilenm:/BIC/SPARTNOShort Name:/BIC0044

CHCKFL

DATAFL

INCFL

CUNO

OBJVERS

Customer MasterFilenm:/BIC/MCUNOShort Name:/BIC0035

CHANGED

CUSTNM

COUNTRY

REGION

ADDRESS

PARTNO

OBJVERS

Part Master TableFilenm:/BIC/MPARTNOShort Name:/BIC0043

CHANGED

PARTNM


Figure 20 shows all the intermediate forms of the table Trans. It starts with theoriginal table (form 1) and ends with the last intermediate table (form 4) thatwill be converted into a CSV file.

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 linedescribes the column type.

Quantity Cost Customer Order date Currency

Char Ch Char Ch Char Ch Char Ch Char Ch Char

Sep Sep Sep Sep SepPart

Form3:

PartQuantity Cost Customer Order date Currency

Sep Sep Sep Sep Sep

Character

Form4:

PartQuantity Cost Customer Order date Currency

Int Ch Dec Ch Char Ch Char Ch Date Ch Char

Sep Sep Sep Sep Sep

Form 2:

Form 1:Quantity Cost Customer Order date CurrencyPart

Int Dec Char Char Date Char


The preparation steps are shown here:

1. Source table Trans (with form 1 in Figure 20 on page 37) is copied into anew table Trans1 (form 2). Trans1 differs from Trans in these ways:

• New columns are added in Trans1 to provide drill-down possibilities forBW 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 *DROPoptions (Figure 21), is used to copy the table from Form 1 into Form 2.

Figure 21. CPYF from form 1 to form 2

2. All columns that are not of character type are converted into charactertype.

Table Transch (form 3) is created with all columns type character. Thedescription of Transch is in Table 16 on page 92.

Then, an SQL INSERT command (Figure 22 on page 39) is used with theCHAR and SUBSTR functions to copy the data from form 2 to form 3. Youcan run the SQL INSERT command from the SQL Utility screen that youget after running the OS/400 command SQL Utility (SQLUTIL). SQLUTIL

Copy File (CPYF)


From file . . . . . . . . . . . > TRANS NameLibrary . . . . . . . . . . . > LEGACY Name, *LIBL, *CURLIB

To file . . . . . . . . . . . . > TRANS1 Name, *PRINTLibrary . . . . . . . . . . . > LEGACY Name, *LIBL, *CURLIB

From member . . . . . . . . . . *FIRST Name, generic*, *FIRST, *ALLTo member or label . . . . . . . *FIRST Name, *FIRST, *FROMMBRReplace or add records . . . . . > *REPLACE *NONE, *ADD, *REPLACE...Create file . . . . . . . . . . *NO *NO, *YESPrint format . . . . . . . . . . *CHAR *CHAR, *HEX

Additional Parameters

Record format field mapping . . > *MAP *NONE, *NOCHK, *CVTSRC...> *DROP

BottomF3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=CancelF13=How to use this display F24=More keys


is a part of a tools set "AS/400 Tools for the Integrated File System" thatcan 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.

Figure 22. Sample SQL — Convert form 2 into form 3

Navigation attributes and master data that is associated with SID tablesmust be converted to upper-case characters. This is done using the SQLUPPER 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, andlength of 82 (long enough to hold all the columns of Transch). The CreatePhysical File (CRTPF) command is used to create this table (Figure 23 onpage 40). Then, the CPYF command with the *NOCHK parameter is usedto copy the data from form 3 to form 4 (Figure 24 on page 40).

INSERT INTO LEGACY/TRANSCH(CUSTKEY, LIM1, COST, LIM2, QUANTITY,LIM3, PARTKEY, LIM4, CURRENCY, LIM5, ORDERDATE, LIM6, ORDERDATE1,LIM7, CALMON, LIM8, QUARTER, LIM9, YEARFLD, LIM10)SELECTchar(custkey), lim1, char(supplycost), lim2, char(quantity), lim3,char(partkey), lim4, currency, lim5, orderdate, lim6, orderdat1,lim7, calmon, lim8, quarter, lim9, yearfld, lim10FROM legacy/trans1


Figure 23. CRTPF — Create intermediate table (form 4)

Figure 24. CPYF — Copy table to a single-column form

The table is converted into the flat file.

Create Physical File (CRTPF)


File . . . . . . . . . . . . . . charfile NameLibrary . . . . . . . . . . . legacy Name, *CURLIB

Source file . . . . . . . . . . QDDSSRC NameLibrary . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB

Source member . . . . . . . . . *FILE Name, *FILERecord length, if no DDS . . . . 82 NumberGeneration severity level . . . 20 0-30Flagging severity level . . . . 0 0-30File type . . . . . . . . . . . *DATA *DATA, *SRCMember, if desired . . . . . . . *FILE Name, *FILE, *NONEText 'description' . . . . . . . *SRCMBRTXT


Copy File (CPYF)


From file . . . . . . . . . . . > TRANSCH NameLibrary . . . . . . . . . . . > LEGACY Name, *LIBL, *CURLIB

To file . . . . . . . . . . . . > CHARFILE Name, *PRINTLibrary . . . . . . . . . . . > LEGACY Name, *LIBL, *CURLIB

From member . . . . . . . . . . *FIRST Name, generic*, *FIRST, *ALLTo member or label . . . . . . . *FIRST Name, *FIRST, *FROMMBRReplace or add records . . . . . > *ADD *NONE, *ADD, *REPLACE...Create file . . . . . . . . . . *NO *NO, *YESPrint format . . . . . . . . . . *CHAR *CHAR, *HEX

Additional Parameters

Record format field mapping . . > *NOCHK *NONE, *NOCHK, *CVTSRC...



The Copy To Stream File (CPYTOSTMF) command in Figure 25 is used tocopy the data from the single-column table Charfile (Form 4) into the flatfile in CSV format.

Figure 25. CPYTOSTMF — Copy table into a flat file

After repeating these three steps for all three source tables, we get three flatfiles (PART.CSV, CUST.CSV, and TRANS.CSV.) that serve as the input for theBW data loading function.

Preparation of source tables with a programIf you will often load your InfoCube from the same source tables, werecommend 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. Thisprogram does all the steps described in “Manual preparation of source tables”on page 36. File names and structures from our examples are coded in thisprogram.

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, *REPLACEData conversion options . . . . *AUTO *AUTO, *TBL, *NONEDatabase file CCSID . . . . . . *FILE 1-65533, *FILEStream file code page . . . . . *STMF 1-32767, *STMF, *PCASCII...



4.1.1.4 Loading the InfoCube with dataLoading the InfoCube with file interface includes loading master data andtransaction data tables. The following sequence defines the loading steps ata high level. For detailed information, please refer to the related BWdocumentation.

1. The meta data is maintained manually in BW. The Maintain Meta Datadialogue 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 theInfoSource Maintain communication structure. The communicationstructure is a staging area for the data after the transfer rules are appliedand before the InfoCube is loaded.

3. To establish and activate the transfer rules, use the InfoSource MaintainTransfer rules. Transfer rules are applied to the data as it is loaded intothe communication structure.

4. Define and activate update rules with the InfoCube Maintain Update Rulesoption. The update rules are applied to the data as it is moved from thecommunication structure to the InfoCube.

5. Define the name of the flat file that will be loaded from the source systemto BW. Use the SAP transaction RSA1—> Infosource —> MaintainInfoPackage Scheduler. Select the ExternData tab as shown in Figure26 on page 43. This is where you spell out the name of the flat file to beloaded. 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 Scheduletab.


Figure 26. Scheduler

For a detailed explanation of the communication and transfer structures,update and transfer rules, please refer to the SAP documents LoadingInfoSource Data via Flat Files and Staging BAPIs for the SAP BusinessInformation Warehouse, which are available on SAPNet.

4.1.2 Business application programming interfaceBW provides an open interface to the BW Staging Engine with businessapplication programming interfaces (BAPIs). The big advantage of BAPIsover the file interface is that they allow the exchange of meta data betweenthe 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 masterdata.

The BAPIs are provided for use for BW customers and third-party toolproviders. They can use the BAPIs and connect their meta data sourcesystem and their extract engines to BW.


You can find more information about BAPIs in the following documentsavailable 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 systemis by using BW Extractor. With this method, the BW sends a request for datato the Extractor who gets data from the SAP R/3 database and sends it toBW. A CD with Extractor installation program is included in a set of BWinstallation CDs.

BW contains pre-defined InfoObjects, InfoCubes, and InfoSources. Extractorloads the SAP R/3 data into these pre-defined structures. These pre-definedstructures 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 onloading SAP R/3 data into BW.


Chapter 5. Performance

This chapter describes how to analyze and improve the performance of BWrunning on an AS/400 system. The redbook SAP R/3 Implementation forAS/400, SG24-4672, extensively covers performance topics related to theSAP R/3 applications on the AS/400 system. Most of the recommendations inthat redbook also apply to BW. However, in analyzing BW performance, keepin mind that the performance behavior of an OLTP application, such as SAPR/3, is much different from the behavior of a business intelligence applicationusing OLAP, such as BW (see Chapter 1, “Introduction” on page 1).

OLTP systems work with operational data stored in a highly normalizedrelational database, designed for day-to-day business operations. OLTPend-users handle thousands or millions of transactions per day and updateoperational data frequently. OLTP end-users have a relatively short thinktime, use simple transactions that update single records, and expect shortsystem 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 thinktimes and often use long-running queries with longer system response times(sometimes minutes or even hours). Queries analyze and summarize datathat is stored in a data warehouse (sometimes called information warehouse,business information warehouse, data mart, InfoCube and so on). This datawarehouse is loaded with operational data on a regular basis. It is organizedin 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 inTable 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


Due to these differences, the performance behavior of BW is different fromthe behavior of SAP R/3. This chapter analyzes the performance of threetypical BW workloads:

• Loading a BW InfoCube with operational data from an OLTP system

• Long-running BW query

• Administration — BW administrator’s work with InfoCubes, InfoObjectsand InfoSources

Simulating different scenarios, we ran the above three workloads in a testenvironment, monitored the performance, and looked at the characteristics ofBW transactions. Then, we searched for primary bottlenecks and possibilitiesfor performance improvements.

5.1 Performance monitoring tools

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

5.1.1 AS/400 system toolsUse the following OS/400 commands for a snapshot analysis of BWperformance on the system level:

• Work with Active Jobs (WRKACTJOB) to monitor CPU usage of the SAPwork processes.

• Work with Disk Status (WRKDSKSTS) to monitor I/O utilization.

• Work with System Status (WRKSYSSTS) to monitor memory page faults.

System response time Short Long

Orientation Rows, columns(two-dimensional)

Arrays (multidimensional)

Data level Detail Aggregate

Requirements Well defined in advance Usually ad-hoc

Structure Static Flexible

OLTP OLAP


For more information on above two commands please refer to 6.4, "AS/400System Monitoring" in the redbook SAP R/3 Implementation for AS/400,SG24-4672.

5.1.2 BW toolsUse the following SAP tools for analyzing BW performance on the applicationlevel:

• ST03 to get response times and resource usage information (summarizedas 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 beingused, and how frequently and who is currently using the system. It canhelp you answer these questions: Are there queries whose runtime is overthe time allowed? Are batch jobs and printing executed in times of lesswork? How does the data flow through the data warehouse?

For more information about BW Statistics, please refer to the SAPdocument SAP BW Statistics, ASAP for BW Accelerator, DocumentVersion 1.0, which is available on SAPNet.

For more information about the SAP R/3 monitoring, please refer "7.1 SAPR/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 theperformance of BW system:

• OS/400 parallel processing. Most BW end-users gain performancebenefits by using this feature described in an example in 5.3, “BW andOS/400 parallel processing” on page 48.

• BW parallel load function for mass data loading. This is described in5.4.1.2, “SAP parallel load” on page 65.

• BW Index delete function improves performance of data loading. It isdescribed in 5.4.1.1, “Performance impact of indexes” on page 59.

Performance 47

• Creation of permanent indexes. Use it in situations where the sametemporary 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/400system 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

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 andwrite 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 tohandle more than one job at a time. Each processor handles at least onejob, but one job is never handled by more than one processor (Figure 27on page 49).

Technique Bringsimprovements to

Possible trade-off

AS/400 SymmetricMultiprocessing

Database queries,index build, rebuildand maintenance

Needs additionalsystem resources

BW parallel load Mass data loading

BW "Index delete"function

Data loading of facttables

Decreasesperformance of deltaupdate

Create permanentindexes

Long-runningqueries

Decreasesperformance of dataloading

LPAR Data loading Adds some overhead toprimary LPAR


Figure 27. N-way processing

In Figure 27, eight CPUs work on several jobs at one time without anyspecial programming.

• SMP (Symmetric Multi-Processing): This is the ability of amultiprocessor system to take one job, divide it up into tasks, and havemore 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 automaticallydivides the job into tasks.

Performance 49

• MPP (Massively Parallel Processing): This is also called shared nothingparallelism. With MPP, several separate systems (nodes) are hookedtogether using high-speed communications, such as OptiConnect. They alsouse a database that can treat all the nodes as a single database image. MPPis the main method of parallelism on UNIX systems, where many 1-way to4-way nodes with relatively small amounts of attached DASD are connectedto create a large system. MPP is available on the AS/400 system throughDB2 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 SymmetricMultiprocessing 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 textshown in bold in Figure 29.

Figure 29. Go LICPGM —> Display installed licensed programs

The use of the SMP is managed by the database query optimizer.

Display Installed Licensed ProgramsSystem: AS0023

Licensed InstalledProgram Status Description5769SS1 *COMPATIBLE OS/400 - Extended NLS Support5769SS1 *COMPATIBLE OS/400 - ObjectConnect5769SS1 *COMPATIBLE OS/400 - OptiConnect5769SS1 *COMPATIBLE OS/400 - Lotus Notes Enhanced Integration5769SS1 *COMPATIBLE OS/400 - DB2 Symmetric Multiprocessing5769SS1 *COMPATIBLE OS/400 - DB2 Multisystem5769SS1 *COMPATIBLE OS/400 - AS/400 Integration for NT5769SS1 *COMPATIBLE OS/400 - QShell Interpreter5769SS1 *COMPATIBLE OS/400 - Domain Name System5716CL1 *COMPATIBLE ADTS Client Server for AS/400 - OS/25716CL1 *COMPATIBLE CoOperative Development Environment5763CL2 *COMPATIBLE ADTS Client Server for AS/400 - Windows5763CL2 *COMPATIBLE CoOperative Development Environment5763CL2 *COMPATIBLE VisualAge RPG for Windows

More...Press Enter to continue.

F3=Exit F11=Display release F12=Cancel F19=Display trademarks


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 levelThis section shows, by an example, to what extent the SMP can improve BWperformance of a particular workload and how you can observe its effects. Wetested the impact of the SMP by running a BW query on a fact table with 26million records and four dimensions around it. The hardware system was anAS/400e Model S20 with four CPUs and OS/400 V4R3. There were no otherusers on the system.

First, we ran the query without the SMP enabled. Figure 30 on page 52 showsthe run-time results of the SAP work process (for example, AS/400 job) thatran this query.

SMP will use additional memory and disk space and produce someoverhead to CPU. For this reason, we recommend that you closely monitorits usage and adjust the settings as your environment changes.

Important

Performance 51

Figure 30. ST03 — BW query performance analysis without SMP

The query was a long-running one with a half hour (1825 seconds) responsetime. The WRKACTJOB command (Figure 31 on page 53) shows a snapshotof the job that ran this query.


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 therewere 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 asingle job on a 4-way system without the SMP can use up to 25% of CPUtime (100% utilization of one out of four available CPUs), our job really used70% 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).

Work with Active Jobs AS002305/21/99 00:22:57



Opt Subsystem/Job User Type CPU % Function StatusDISP CLD20 BCI 17.5 RUNQPADEV000E BBALLARD INT .4 CMD-WRKACTJOB RUNSCPF QSYS SYS .0 EVTWSAPOSCOL QA415 BCI .0 SIGWR3RMTDB R3SERVER ASJ .0 PGM-QBFCLISTEN SELWR3_20 QSYS SBS .0 DEQWR3_15 QSYS SBS .0 DEQWR3_QA4_15 QA415 BCH .0 PGM-SAPSTART EVTWR3_CLD_20 CLD20 BCH .0 PGM-SAPSTART EVTW


Performance 53

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 useI/O parallel processing for queries. SMP is not allowed.

• *OPTIMIZE: The optimizer can choose to use any number of tasks foreither I/O parallel processing or SMP to process the query or database fileindex build, rebuild, or maintenance. The use of parallel processing andthe 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 inwhich 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 activememory in the memory pool can be used to process the query or databasefile index build, rebuild, or maintenance.

Change System Value

System value . . . . . : QQRYDEGREEDescription . . . . . : Parallel processing degree

Type choice, press Enter.

Degree of parallelismallowed . . . . . . *MAX *NONE

*IO*OPTIMIZE*MAX

F3=Exit F5=Refresh F12=Cancel


Any change to this system value becomes the default value for all jobs on thesystem. 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 (comparethis to 17.5% without SMP).

Figure 33. WRKACTJOB — CPU utilization of BW query with SMP

Again, we ran the transaction ST03 (Figure 34 on page 56) to summarizeperformance data of the SAP work process that ran the query and comparedit with the previous results.

Work with Active Jobs AS002305/21/99 01:22:15



Opt Subsystem/Job User Type CPU % Function StatusDISP CLD20 BCI 50.1 RUNDISP QA415 BCI .2 DEQWQPADEV000E BBALLARD INT .1 CMD-WRKACTJOB RUNSCPF QSYS SYS .0 EVTWSAPOSCOL QA415 BCI .0 SIGWR3RMTDB R3SERVER ASJ .0 PGM-QBFCLISTEN SELWR3_20 QSYS SBS .0 DEQWR3_15 QSYS SBS .0 DEQWR3_QA4_15 QA415 BCH .0 PGM-SAPSTART EVTW


Performance 55

Figure 34. Transaction ST03 — BW query performance analysis with SMP

Table 9 shows comparisons of the query runtimes with and without SMPenabled.

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 thesnapshots were done at different stages. However, they show a general picture.


SummaryUsing the SMP in this test, we noticed significant performance improvements.The magnitude of performance improvements in a particular customerenvironment depends several factors, including the type of workload and thenumber of users in the first place. SMP can improve the performance of jobsthat run BW queries, or build, rebuild, or maintain database indexes. As a ruleof thumb, consider setting the QQRYDEGREE system value in the followingmanner:

• *MAX when there are less than four active users.

• *NONE when there are more than ten active users. The AS/400 system isalready highly efficient at managing that workload without SMP.

• Experiment with values in other cases to find out the best match for yourparticular environment.

In 5.4.1, “Loading the BW with data” on page 59, and 5.4.2, “Long-runningquery” on page 68, we examine some of the conditions under which the SMPcan bring performance improvements.

5.3.1.2 Using SMP on a job levelParallel processing can also be controlled on the OS/400 job level with the CLcommand CHGQRYA, using the "Parallel processing degree" parameter(Figure 35 on page 58). With this parameter, you can specify the parallelprocessing degree of a single job in a similar manner as with theQQRYDEGREE system value on a system level. In addition, you can definethe number of tasks that can be used by this job when running queries orindex build, rebuild, or maintenance.

Performance 57

Figure 35. CHGQRYA — Change query attribute of a job

The "Number of tasks" parameter specifies the number of tasks that will run agiven query, index build, or maintenance in parallel. If you specify the numberof tasks as two, then only two CPUs process the job, while other CPUs (ifthey exist) are idle. We recommend that you specify a number of tasks that isless than the number of all CPUs on the system. This prevents a single jobfrom monopolizing the entire system by using all available CPUs. Forexample, on an 8-way system, restrict the SMP to use only two CPUs per jobby specifying the Number of tasks as two. This will allow up to four jobs to runqueries in parallel without affecting one another. Each of the four jobs will usetwo CPUs.

Before changing the parameters of a job with CHGQRYA, you need to knowthe name of this job. This may be difficult in cases when there is more thanone BW job on the system, since you cannot influence the SAP dispatcher’sdecisions. For this reason, we recommend that you change the CHGQRYAparameters for all DISP jobs of an SAP instance in the same manner. You cando this either manually or by a CL program that analyzes and changes theparallel processing degree for all DISP jobs of the SAP instance. Keep inmind that sometimes BW may restart its work processes automatically. If thishappens, then all attributes of the job will be reset to default. Therefore, theCL program that changes query attributes must be run again.

Change Query Attributes (CHGQRYA)


Job name . . . . . . . . . . . . * Name, *User . . . . . . . . . . . . . NameNumber . . . . . . . . . . . . 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



5.4 Analysis of BW performance behavior

This section analyzes BW performance behavior in three different testworkloads:

• Loading the BW with data• Long-running query• Administration

Evaluations of real customer data and BW benchmarks will be published assoon as they are available.

All tests were done on an AS/400e Model S30, processor feature #2260 witheight CPUs, 4 GB main of memory, 28 x 4.19 GB disks drives, and OS/400V4R3.

5.4.1 Loading the BW with dataThis section examines two techniques that may bring significant performanceimprovements 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 BWand the source system on the same AS/400 machine and using LPARs asshown in Figure 10 on page 19.

The examples in this section show runtime results of loading the InfoCubeSOCUBE described in Chapter 4, “Loading the BW with data” on page 29.

5.4.1.1 Performance impact of indexesMaintaining indexes on a fact table produces system overhead anddecreases the performance of data loading. As an example, we show thedata 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 facttable were deleted before the data load and recreated afterwards. This isdone by a BW function, Delete InfoCube indexes, which can be enabled ordisabled during data loading. Enabling this function decreases the dataloading runtime.

This example was done on OS/400 V4R3 using Binary Radix Tree type ofindexes. Encoded vector indexes (EVI) that are available for SAP users inV4R4 bring additional performance improvements.

Performance 59

Data loading with indexesFirst the fact table is loaded with 100,029 rows and all indexes attached. Thisdata loading consists of two main tasks:

• Reading data sequentially from one flat file and inserting this data intorows 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 (1417sec.), and DB request time (509 sec.). The total CPU time of this data loadingwas 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. TheSMP feature is enabled. However, SMP is only used to maintain indexes andis not used for data inserting.


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-waymachine, 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 withDisk Status (WRKDSKSTS) command. The results are shown in Figure 38 onpage 62.




Opt Subsystem/Job User Type CPU % Function StatusDISP BWA61 BCI 11.7 RUNQIJSSCD QIJS BCH 3.2 PGM-QIJSCMON DEQADISP BWA61 BCI 1.5 RUNDISP BWA61 BCI .5 DEQWQPADEV000K ENGEL INT .1 CMD-WRKACTJOB RUNSCPF QSYS SYS .0 EVTWSAPOSCOL BWA61 BCI .0 SIGWR3RMTDB R3SERVER BCH .0 PGM-QBFCLISTEN SELWR3_61 QSYS SBS .0 DEQW


Performance 61

Figure 38. WRKDSKSTS — Disk status during data loading

With none of the disk arms busy more than 1%, there were no I/O bottlenecksduring this test.

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

Work with Disk Status TSCSAP0305/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 12 6607 3670 47.3 1.0 21.1 .2 .7 27.4 18.8 13 6607 3670 47.3 1.0 23.1 .2 .7 25.0 22.4 14 6607 3670 47.3 1.0 15.4 .2 .7 17.9 14.7 05 6607 3670 47.3 2.5 25.9 .3 2.1 9.6 28.9 06 6607 3670 47.3 .7 19.7 .1 .5 27.3 17.6 07 6607 3670 47.3 .8 25.2 .2 .5 30.0 23.2 08 6607 3670 47.3 1.4 20.0 .2 1.2 25.6 18.7 09 6607 3670 47.3 .6 21.5 .1 .5 26.6 19.7 010 6607 3670 47.3 1.3 29.4 .1 1.2 29.0 29.4 011 6607 3670 47.3 .8 27.6 .2 .5 30.1 26.1 112 6607 3670 47.3 .7 26.9 .2 .5 30.9 24.9 013 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 39. Delete InfoCube indexes before data loading

You do not need to know names of the index files to perform this action. BWknows which indexes are built on the fact table. However, sometimes youneed to know the names of indexes that are attached to your tables (see theexample in 5.4.2.2, “Query performance analysis” on page 72). You can findthe names either with SAP transaction SE11 (ABAP Dictionary) or the OS/400command Display Database Relation (DSPDBR). To find out which indexesare 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 ofdata 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 withindexes (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

The performance behavior of master data tables load looks similar to facttable data loading, shown in Figure 36 on page 60. There is a similar ratiobetween processing time, CPU time, and DB request time.

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


In our tests, all data loading jobs were CPU bound. Table 11 summarizes theruntime results for the data loading of all three tables.

Table 11. Data loading test results summary

Use the "Delete InfoCube indexes" function on a fact table whenever the timeneeded to recreate indexes after the data load is shorter than the timeneeded to maintain indexes during the data loading. This may not be true inthe case of a delta update where you add records to the fact table, whichalready contains many records. In this case, the time needed to recreateindexes may be longer.

5.4.1.2 SAP parallel loadIn a case of mass data loading, the performance can be improved by usingthe SAP parallel data load function. There is a difference between the SAPparallel 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 useseveral CPUs at a time (Figure 42 on page 66).

Type of data Infosource

Number ofrecords

Runtimewith indexes

Runtimewithoutindexes1

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.

When the delta update includes 10% or more of the table, delete theindexes, run the update, and then recreate the indexes. Every customershould run their own tests of this procedure. The results can vary widelybased on the type of update and the complexity and number of indexes.

Rule of thumb

Performance 65

Figure 41. SAP parallel load

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/400DISP jobs) running the parallel load of our fact table. The SMP feature wasalso enabled.

SAP BW Work Processes

DISP (active)

AS/400 Processor Tasks

Processor 1

Processor 2

Processor 3

Processor 4

DISP (active)

DISP (active)

DISP (active)

SAP BW Work Processes

DISP 1 (active)

DISP 2 (wait)

DISP 3 (wait)

DISP 4 (wait)

AS/400 Processor Tasks

Processor 1

Processor 2

Processor 3

Processor 4


Figure 43. WRKACTJOB — Parallel load

Since this data loading job is primarily processed in a serial manner, we donot benefit much from the SMP feature in this case. All four work processesthat run parallel data loads primarily consume CPU-cycles of only one CPU ata time. For this reason, they cannot achieve more than 12.5% CPU utilizationeach and 50% altogether.

Using the WRKDSKSTS command to find out possible I/O bottlenecks duringthe parallel load, again we did not find any I/O bottlenecks. The disk armutilization in our example (Figure 44 on page 68) was similar to thenon-parallel load shown in Figure 38 on page 62.




Opt Subsystem/Job User Type CPU % Function StatusDISP BWA61 BCI 12.0 RUNDISP BWA61 BCI 12.0 RUNDISP BWA61 BCI 11.9 RUNDISP BWA61 BCI 11.9 RUNQIJSSCD QIJS BCH 2.8 PGM-QIJSCMON DEQAQPADEV000D ENGEL INT .7 CMD-WRKACTJOB RUNSCPF QSYS SYS .0 EVTWSAPOSCOL BWA61 BCI .0 SIGWR3RMTDB R3SERVER BCH .0 PGM-QBFCLISTEN SELW


To achive maximum performance of a data loading job, use the parallelload with as many SAP work processes as there are CPUs on the BWsystem.

Recommendation

Performance 67

Figure 44. WRKDSKSTS — Disk arm utilization during parallel load

5.4.2 Long-running queryThere are three techniques that can improve the performance of long-runningqueries:

• Defining aggregates

• Adding permanent indexes to InfoCube tables (described in detail later inthis section)

• Using the AS/400 SMP as already described in 5.3, “BW and OS/400parallel processing” on page 48

This section shows how to analyze and improve query run-time performancethrough the example of using a typical BW query.

5.4.2.1 Description of the sample queryThis query ran in a test environment on OS/400 V4R3. The OS/400 V4R4 willbring additional performance improvements to the query run-time with theintroduction of encoded vector index (EVI) support. This support will beavailable for BW production environments.

The query used in this example is based on the InfoCube Customer, which isdelivered by the SAP to run BW benchmarks. This InfoCube contains a part

Work with Disk Status TSCSAP0305/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 02 6607 3670 82.8 1.9 22.3 .1 1.7 26.9 21.9 13 6607 3670 82.7 1.9 18.3 .3 1.6 29.9 15.9 24 6607 3670 82.6 2.4 35.6 .4 2.0 11.7 40.3 45 6607 3670 82.8 1.1 30.6 .3 .7 10.1 41.5 26 6607 3670 82.6 .5 11.9 .0 .5 10.1 12.0 07 6607 3670 82.6 .8 25.4 .0 .8 13.8 26.4 18 6607 3670 82.7 6.7 9.2 5.7 1.0 4.2 36.4 39 6607 3670 82.6 1.0 42.6 .0 .9 22.6 44.4 110 6607 3670 82.8 1.6 26.7 .0 1.5 20.0 27.1 111 6607 3670 82.7 1.8 12.2 .0 1.8 22.6 12.0 112 6607 3670 82.6 1.4 20.1 .3 1.0 6.7 24.3 013 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


of all BW benchmark data. As shown in Figure 45, InfoCube Customerconsists 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 costof invoiced sales. They are grouped by sold-to-party and filtered byfiscal-year-variant. The design of this query named 0SD_C01_Q013 is shownon 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 theamount of records stored in these tables.


Table 12. Tables in the InfoCube Customer — Test data

As specified in "Free Characteristics" of this query’s definition, you arerequested to specify additional selections before the query runs (Figure 47).The result of this query is presented by the SAP Business Explorer Analyzerin Figure 48 on page 72.

Figure 47. Starting the 0SD_C01_Q013 query

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

Performance 71

Figure 48. Query result

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


Figure 49. WRKACTJOB — BW query running with SMP enabled

The transaction ST03 (Figure 50 on page 74) summarizes performancebehavior of the work process that ran the query.




Opt Subsystem/Job User Type CPU % Function StatusDISP BWA61 BCI 44.1 IDX-"/BI00285" RUNDISP BWA61 BCI 5.8 RUNQIJSSCD QIJS BCH 1.3 PGM-QIJSCMON DEQWQPADEV000D ENGEL INT .7 CMD-WRKACTJOB RUNDISP BWA61 BCI .2 DEQWSCPF QSYS SYS .0 EVTWSAPOSCOL BWA61 BCI .0 SIGWR3RMTDB R3SERVER BCH .0 PGM-QBFCLISTEN SELWR3_61 QSYS SBS .0 DEQW


Performance 73

Figure 50. ST03 — BW query transaction analysis, SMP enabled

The largest part of the response time (121 sec.) is the processing time (118sec.). Only 2.5 sec. was used for DB request time. The CPU time is largerthan 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 ABAPSQL trace (SAP transaction ST05) while the query is running. Trace analysisof ST05 (Figure 51 on page 75) shows SQL statements processed by thequery 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 isobvious that, in this case, the biggest potential for performance improvementis in optimizing the SQL OPEN function. To analyze SQL functions, click onthe 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 filesand selected many columns. On this window, we click on the Expand Subtreebutton for more details on how the SQL SELECT statement was processed.The Database Performance Explain window appears, which is partly shown inFigure 53 on page 77.


Figure 53. ST05 — Explain SQL statement —> Expand subtree

On the Database Performance: Explain window, some of the information youcan see includes:

• The access path that was selected. In this case, the database optimizerdecided that the best access method is to build a temporary access path(for example, temporary index). This path includes the key fieldsKEY_000001, KEY_000003, KEY_000004, KEY_000006, andKEY_000008 for table "/BI00285", which is the fact table.

• The number of records from which the index was created (4,930,954 inthis case).

• The amount of time the index creation took (more than 148 sec.).

In conclusion, avoiding the temporary index creation may bring significantperformance improvement. This is possible when creating a permanent index

Performance 77

before starting the query. When the query runs unchanged next time, theoptimizer will again select the same access method, find out that the indexalready exists, and use the existing index instead of creating a temporaryone.

To create an index with SAP Data Dictionary, you must know the alternatenames (long names and short names) of the table and fields.

The table short name is depicted in the Explain SQL function (Figure 53 onpage 77). In this example, the table short name is "/BI00285". To find out thetable long name, use the OS/400 command SQLUTIL. Then, press the Enterkey, and specify the parameters as shown here:

SELECT SYSTEM_TABLE_NAME, TABLE_NAME FROMR3BWADATA/SYSTABLESWHERE NAME LIKE '/BI0%'

After pressing the Enter key, we get the list of all tables and search for theknown short name to find out the fact table’s alternate name. As shown inFigure 54 on page 79, the table alternate name in this example is/BI0/F0SD_CO01.

You can create a permanent index with any native OS/400 tool. However,we strongly recommend that you create it inside the SAP environment. Inthis case, the index will be known in the SAP Data Dictionary. The indexwill always be considered during system upgrades and other importantsystem tasks such as deleting or recreating indexes during data loading.

Recommendation


Figure 54. SQL SYSTABLES — Assign short/alternate table names

Next, we find out the alternate field names. We use the OS/400 Display FileField Description (DSPFFD) command as shown here:

DSPFFD FILE(R3BWADATA/"/BI00285")

Pressing the Page down key brings the second screen with field names andtheir alternate field names (Figure 55 on page 80).

Display ReportQuery . . . . .: QGPTOOLS/SQLUTIL Width . . .: 369Form . . . . .: *SYSDFT Column . .: 1Control . . . .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

Performance 79

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

After this step, you have all information needed to create a permanent indexthat the optimizer will use instead of a temporary one. Use the SAPtransaction SE11 (Figure 56 on page 81) to create this index.

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

Data Field Buffer Buffer Field ColumnField Type Length Length Position Usage HeadingKEY_000001 BINARY 9 0 4 1 Both KEY_0SD_C01PAlternative name . . . . . . . . . . . . : KEY_0SD_C01PDefault value . . . . . . . . . . . . . . :

0KEY_000002 BINARY 9 0 4 5 Both KEY_0SD_C01TAlternative name . . . . . . . . . . . . : KEY_0SD_C01TDefault value . . . . . . . . . . . . . . :

0KEY_000003 BINARY 9 0 4 9 Both KEY_0SD_C01UAlternative name . . . . . . . . . . . . : KEY_0SD_C01UDefault value . . . . . . . . . . . . . . :

0KEY_000004 BINARY 9 0 4 13 Both KEY_0SD_C011Alternative name . . . . . . . . . . . . : KEY_0SD_C011Default value . . . . . . . . . . . . . . :

0KEY_000005 BINARY 9 0 4 17 Both KEY_0SD_C012

More...F3=Exit F12=Cancel F19=Left F20=Right F24=More keys


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 page80. After we created this permanent index, we ran our query again. The ST03monitor result shown in Figure 57 on page 82 summarizes the performancedata 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) explainsthis improvement.


Figure 58. ST05 — SQL trace overview with permanent index available

The performance improvement was achieved on behalf of a shorter executiontime of the SQL OPEN function. In our example, this time was reduced from148 sec. when the optimizer used a temporary index. The time was reducedto 1.1 sec. when the permanent index was used. By clicking Explain SQLfunction, we get details of this improvement, which is shown in Figure 59 onpage 84.

Performance 83

Figure 59. ST05 — Explain SQL statement, index available

Instead of creating a temporary index for about 4.9 millions records, theoptimizer now decided to use the existing permanent index/BI0/F0SD_C01+090 that we created.

Performance improvements of such magnitudes can be expected when thesystem does not have to build the access plan. When an index is deleted andrecreated again (for example, during data load without indexes), the accessplan 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 andrecreated it immediately, before we ran the query. This forced the optimizer torebuild 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 SQLOPEN).

Table 14. Query 0SD_C01_Q013 runtime comparison

SummaryQuery performance may be significantly improved by using a permanentindex. However, this index will deteriorate the performance of InfoCube dataloading. Compare the advantage of improved query performance against thedisadvantage of increased data loading time. If the disadvantage is bigger,use a temporary index with SMP enabled.

5.4.3 BW system administrationBW administration means predominantly working with InfoObjects,InfoCubes, and InfoSources. It is done with the SAP transaction RSA1. In ourtests, the performance behavior of some typical administrator’s transactionswas similar to the SAP R/3. For hints on how to tune the administrator’sworkload, please refer to redbook SAP R/3 Implementation for AS/400,SG24-4672.

Temporary index Permanent indexand access planrebuild

Permanent index,no access planrebuild

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.

Performance 85

Chapter 6. Sizing considerations

This section describes some considerations on how to size an AS/400 systemthat runs BW. The considerations are based on recommendations publishedby the SAP in the document Performance and Sizing, ASAP for SAP BWAccelerator, Document Version 1.1, available on SAPNet. They are alsoderived from the first test results described in Chapter 5, “Performance” onpage 45.

At the time this redbook was published, there was no sizing data available,based on benchmarks or production environments. As such, all conclusionsin this section are preliminary. For BW sizing guidelines, please contact theInternational SAP IBM Competence Center (ISICC) by e-mail at this address:[email protected]

6.1 CPU requirements

BW queries, as well as data loads that we ran in our tests, used long-runningtransactions with high CPU usage. These transactions significantly influenceperformance behavior of other transactions that run at the same time andcompete for the same CPU. Therefore, we highly recommend that you have asystem 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 requirementsdepend heavily on the amount of data that is read during the execution of areport. As a minimum requirement, we recommend that you follow thesesizing 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 requirementM(AP) Main memory requirement for the application serverM(DB) Main memory requirement for the database server


N Total amount of active usersN(AP) Total amount of active users assigned to an application server

For detailed information, please refer to the SAP R/3 sizing documentationpublished by ISICC.

6.3 Disk space and disk arms requirements

Disk space requirements can be determined by following the rules publishedby the SAP in the document in the appendix "Disk Storage Sizing", inPerformance 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 diskarms, use disk arm recommendations published in the IBM White PaperAS/400 Disk Arm Requirements Based on Processor Model Performance.This white paper provides recommendations for each AS/400 CPU level. Youcan 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 andSizing, ASAP for SAP BW Accelerator, Document Version 1.0, which isavailable on SAPNet.

6.5 BW system configuration examples

This section offers some recommendations for AS/400 two-tier configurationsin different BW environments. Recommendations are based on the followingassumptions:

• 65% of named users are active users.

• Eight active medium users or four active high users are valued as oneconcurrent user.

• 20% of all active users are high users, and 80% of them are mediumusers. A medium user accesses the BW system regularly and


continuously. The user typically uses predefined and optimized reports. Ahigh 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, BWperformance heavily depends on which techniques you use to optimize yourrun-time environment and how you combine them in an optimal manner. Inaddition, it is important to find the optimal data model for your InfoCubesduring the design phase of BW implementation.

We recommend that you start the implementation project with a system thatprovides enough CPU power to simulate the future production environmentwith a reasonable amount of test users. After the optimization phase of theimplementation 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, “Fileinterface — An example” on page 29.

Table 15. Table Trans1

Field Data Type Fieldlength

Column headings Defaultvalue

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 Fieldlength

Column headings Defaultvalue

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

Table 18. Flat file Cust.csv

Table 19. Flat file Trans.csv

Data description Characters

Part number 6

Delimiter 1

Part Name 25

Delimiter 1


Customer Number 6

Delimiter 1

Customer Name 25

Delimiter 1

Country 25

Delimiter 1

Region 25

Delimiter 1

Address 25

Delimiter 1


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 — Anexample” 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 flagsD 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 -1Dread PR 10I 0 EXTPROC('read')* file descriptor returned from open()D 10I 0 VALUE* data receivedD * VALUE* number of bytes to readD 10U 0 VALUE********************************************************************** (from member UNISTD, file H, library QSYSINC)** stream file (flat file) write definition********************************************************************** value returned = number of bytes actually written, or -1Dwrite PR 10I 0 EXTPROC('write')* file descriptor returned from open()D 10I 0 VALUE* data to be writtenD * VALUE* number of bytes to writeD 10U 0 VALUE*****************************************************************

********************************************************************** (from member UNISTD, file H, library QSYSINC)** stream file (flat file) Close definition;******************************************************************* value returned = 0 (OK), or -1Dclose PR 10I 0 EXTPROC('close')* file descriptor returned from open()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 150ADBufP 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 6d i s 10I 0d chdate s 10

d ptrec dsd pb_partkey 6d pb_sep 1 inz(';')d pb_part 25d pb_sep2 1 inz(';')d pb_hexend 2 inz(X'0D25')

d curec dsd cu_custkey 6d cu_sep 1 inz(';')d cu_address 32d cu_sep2 1 inz(';')d cu_country 25d cu_sep3 1 inz(';')d cu_customer 25d cu_sep4 1 inz(';')d cu_region 25d cu_sep5 1 inz(';')d cu_hexend 2 inz(X'0D25')

d trrec dsd tb_quantity 11d tb_sep 1 inz(';')d tb_cost 15d tb_sep2 1 inz(';')d tb_partkey 6d tb_sep3 1 inz(';')d tb_custkey 6d tb_sep4 1 inz(';')d tb_date 8d tb_sep5 1 inz(';')d tb_cur 3d tb_sep6 1 inz(';')d tb_calday 8d tb_sep7 1 inz(';')d tb_calmon 6d tb_sep8 1 inz(';')


d tb_calqtr 5d tb_sep9 1 inz(';')d tb_calyr 4d tb_sep10 1 inz(';')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) + ZeroBinC Z-ADD O_CREAT oflagC ADD O_RDWR oflagC ADD O_CODEPAGE oflagC EVAL FileDescr=open(FileNamP:oflag:omode:cp)

C EVAL FileCus=%TRIM(FileCus) + ZeroBinC Z-ADD O_CREAT oflagC ADD O_RDWR oflagC ADD O_CODEPAGE oflagC EVAL FileCusD=open(FileCusP:oflag:omode:cp)

C EVAL FileTrn=%TRIM(FileTrn) + ZeroBinC Z-ADD O_CREAT oflagC ADD O_RDWR oflagC ADD O_CODEPAGE oflagC 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 7099c dow *in99=*offc move p_partkey stringc eval i=1c dow %subst(string:i:1)='0'c and i<7c eval %subst(string:i:1)=' 'c eval i=i+1c enddoc eval pb_partkey=%trim(string)c lo:up xlate p_part pb_partc eval buf=ptrecC EVAL RC=write(FileDescr: BufP: 35)c read pt 7099c 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 7099c dow *in99=*offc eval tb_quantity=%trim(%editc(t_quantity:'A'))c eval tb_cost=%trim(%editc(t_supplycost:'A'))c move t_orderdate chdatec eval %subst(tb_date:1:4)=%subst(chdate:1:4)c eval %subst(tb_date:5:2)=%subst(chdate:6:2)c eval %subst(tb_date:7:2)=%subst(chdate:9:2)c eval tb_calday=tb_datec 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_calyrc if %subst(tb_date:5:2)='01' orc %subst(tb_date:5:2)='02' orc %subst(tb_date:5:2)='03'c eval %subst(tb_calqtr:5:1)='1'c endifc if %subst(tb_date:5:2)='04' orc %subst(tb_date:5:2)='05' orc %subst(tb_date:5:2)='06'c eval %subst(tb_calqtr:5:1)='2'c endifc if %subst(tb_date:5:2)='07' orc %subst(tb_date:5:2)='08' orc %subst(tb_date:5:2)='09'c eval %subst(tb_calqtr:5:1)='3'c endifc if %subst(tb_date:5:2)='10' orc %subst(tb_date:5:2)='11' orc %subst(tb_date:5:2)='12'c eval %subst(tb_calqtr:5:1)='4'c endifc lo:up xlate t_currency tb_cur

c move t_partkey stringc eval i=1c dow %subst(string:i:1)='0'c and i<7c eval %subst(string:i:1)=' 'c eval i=i+1c enddoc eval tb_partkey=%trim(string)

c move t_custkey stringc eval i=1c dow %subst(string:i:1)='0'c and i<7c eval %subst(string:i:1)=' 'c eval i=i+1c enddoc eval tb_custkey=%trim(string)

c eval buf=trrecC 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 7099c enddo

c read cust 7099c dow *in99=*offc move c_custkey stringc eval i=1c dow %subst(string:i:1)='0'c and i<7c eval %subst(string:i:1)=' 'c eval i=i+1c enddoc eval cu_custkey=%trim(string)c lo:up xlate c_country cu_countryc lo:up xlate c_region cu_regionc lo:up xlate c_customer cu_customerc lo:up xlate c_address cu_addressc eval buf=curecC EVAL RC=write(FileCusD: BufP: 120)c read cust 7099c 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 SAPBasis consultants in the implementation of the SAP Business InformationWarehouse on the AS/400 system. The information in this publication is notintended as the specification of any programming interfaces that are providedby SAP or IBM. Contact SAP for more information about what publicationsare considered to be product documentation.

References in this publication to IBM products, programs or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM product, program, or service is notintended to state or imply that only IBM's product, program, or service may beused. Any functionally equivalent program that does not infringe any of IBM'sintellectual property rights may be used instead of the IBM product, programor service.

Information in this book was developed in conjunction with use of theequipment specified, and is limited in application to those specific hardwareand software products and levels.

IBM may have patents or pending patent applications covering subject matterin this document. The furnishing of this document does not give you anylicense to these patents. You can send license inquiries, in writing, to the IBMDirector of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood,NY 10594 USA.

Licensees of this program who wish to have information about it for thepurpose of enabling: (i) the exchange of information between independentlycreated programs and other programs (including this one) and (ii) the mutualuse of the information which has been exchanged, should contact IBMCorporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.

Such information may be available, subject to appropriate terms andconditions, including in some cases, payment of a fee.

The information contained in this document has not been submitted to anyformal IBM test and is distributed AS IS. The information about non-IBM("vendor") products in this manual has been supplied by the vendor and IBMassumes no responsibility for its accuracy or completeness. The use of thisinformation or the implementation of any of these techniques is a customerresponsibility and depends on the customer's ability to evaluate and integratethem into the customer's operational environment. While each item may havebeen 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 environmentsdo so at their own risk.

Any pointers in this publication to external Web sites are provided forconvenience only and do not in any manner serve as an endorsement ofthese Web sites.

Any performance data contained in this document was determined in acontrolled environment, and therefore, the results that may be obtained inother operating environments may vary significantly. Users of this documentshould verify the applicable data for their specific environment.

The following document contains examples of data and reports used in dailybusiness operations. To illustrate them as completely as possible, theexamples contain the names of individuals, companies, brands, andproducts. All of these names are fictitious and any similarity to the names andaddresses used by an actual business enterprise is entirely coincidental.

Reference to PTF numbers that have not been released through the normaldistribution process does not imply general availability. The purpose ofincluding these reference numbers is to alert IBM customers to specificinformation relative to the implementation of the PTF when it becomesavailable to each customer according to the normal IBM PTF distributionprocess.

The following terms are trademarks of the International Business MachinesCorporation in the United States and/or other countries:

The following terms are trademarks of other companies:

C-bus is a trademark of Corollary, Inc. in the United States and/or othercountries.

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

AS/400 ATCT DB2IBM Information WarehouseNetfinity Operating System/400OS/2 OS/400RS/6000 SPSystem/390 VisualAgeXT 400


Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States and/or other countries.

PC Direct is a trademark of Ziff Communications Company in the UnitedStates and/or other countries and is used by IBM Corporation under license.

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of IntelCorporation in the United States and/or other countries.

UNIX is a registered trademark in the United States and/or other countrieslicensed exclusively through X/Open Company Limited.

SET and the SET logo are trademarks owned by SET Secure ElectronicTransaction LLC.

Other company, product, and service names may be trademarks or servicemarks of others.

Special notices 105

Appendix D. Related publications

The publications listed in this section are considered particularly suitable for amore 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 ITSORedbooks” 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 BusinessIntelligence, 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-ROMsbutton at http://www.redbooks.ibm.com/ for information about all the CD-ROMsoffered, updates and formats.

CD-ROM Title Collection KitNumber

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. Alsoread redpieces and download additional materials (code samples or diskette/CD-ROM images) fromthis redbooks site.

Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a fewchapters will be published this way. The intent is to get the information out much quicker than theformal publishing process allows.

• E-mail Orders

Send orders by e-mail including information from the redbooks fax order form to:

• Telephone Orders

• Fax Orders

This information was current at the time of publication, but is continually subject to change. The latestinformation may be found at the redbooks Web site.

In United StatesOutside North America

e-mail [email protected] information is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl/

United States (toll free)Canada (toll free)Outside North America

1-800-879-27551-800-IBM-4YOUCountry coordinator phone number is in the “How to Order”section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl/

United States (toll free)CanadaOutside North America

1-800-445-92691-403-267-4455Fax phone number is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl/

IBM employees may register for information on workshops, residencies, and redbooks by accessingthe 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 developedand written by the ITSO technical professionals; click the Additional Materials button. Employeesmay access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Intranet for Employees


IBM Redbook Fax Order Form

Please send me the following:

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card notavailable in all countries. Signature mandatory for credit card payment.

Title Order Number Quantity

First name Last name

Company

Address

City Postal code

Telephone number Telefax number VAT number

Invoice to customer number

Country

Credit card number

Credit card expiration date SignatureCard issued to


Glossary

access plan. Plan generated by the OS/400Query Optimizer of how to access the data inthe tables being queried.

Business Explorer. SAP BW reporting tool.

characteristic. An element of a business suchas: company code, product, material, or fiscalyear. Also an element of a dimension.

data loading. A process of loading data fromsource systems into the BW InfoCube.

data extraction. Pulling the data out of itssource system (or systems) and putting it into awarehouse-usable form.

database table. See table.

data warehouse. A database that containssummarized data created from transactionaldata found in the OLTP system.

database. A means of data storage.

delta update. A type of database update.Refreshes only data changed since the lastextraction. See also full update.

dimension. Grouping characteristics thatbelong together from a content point of view. Forexample, a customer dimension may contain thecustomer number, the customer group, and thelevels of customer hierarchy.

drill down. A technique that allows you toexplore the detailed data that was used increating a summary level data. In BW, this isone of the navigation techniques.

fact table. A table that contains all key figures(facts) of the InfoCube. It is the central table inthe star schema.

flat file. A file that contains text. It is used toload information into the data warehouse. It canbe comma-delimited, fixed-width or variablewidth.

full update. A type of database update.Replaces all data. See also delta update.

InfoCube. A multidimensional central datacontainer for queries and evaluations. Contains

© Copyright IBM Corp. 1999

two types of data: key figures andcharacteristics.

InfoObject. Generic term for characteristics andkey figures.

InfoPackage. A description of data that shouldbe requested from a source system.

informational data. Data created fromoperational data, stored in a format that makeseasier business analysis. Analysis can be in theform of decision support (queries), reportgeneration, Executive Information Systems, orstatistical analysis.

InfoSource. A quantity of InfoObjects groupedtogether from a business point of view. It cancontain either transaction data or master data.

key figure. Values or quantities such asrevenue, costs, number of employees.

legacy system. A system that has been inplace for a significant period of time. Serves asa source system for a data warehouse.

master data. Data that remains unchangedover a long period time, for example, customernames and addresses.

meta data. Data about data. Meta datadescribes format, origin, history, and otheraspects of data.

multidimensional database. A specializeddatabase that is designed to enable thequerying and viewing of large volumes of databased on predefined dimensions such asgeography, customer, and product.

multidimensional table. See multidimensionaldatabase.

navigation. Analysis of the InfoCube bydisplaying different views of the data of a query.

navigation attributes. Attributes that allow youto present different views of the data.

N-way system. A system with two or moreCPUs.

111

OLAP. Online analytical processing (OLAP) is atype of processing used to analyze summarizedonline transaction processing (OLTP) data. OLAPallows multidimensional views and analysis ofthat data for decision support processes.

OLTP. Online transaction processing (OLTP) is atype of processing of operational data.

operational data. Data that is used to run acompany’s business. It is stored, retrieved, andupdated by an OLTP system.

query. A selection of InfoObjects (characteristicsand key figures) for the analysis of the data in anInfoCube.

schema. The logical and physical definition ofdata elements, for example, a star schema.

source system. Every system that is available inthe Business Warehouse for the data extraction.

staging engine. Implements data mapping anddata transformation during the data loadingprocess. It extracts data from a source system.

star schema. A data structure that combines facttables and dimension tables in a way thatprovides easy and efficient access to data.

SQL. Structured Query Language (SQL) is alanguage developed by IBM that provides accessto relational database.

table. An array of data in a table form. It consistsof columns (data values of the same type) androws (data records). Each record can beidentified uniquely by one or several fields.

table index. Index used to accelerate dataselection from a table. It is similar to a copy of thetable reduced to certain fields only and alwayssorted.

temporary index. Index built "on the fly" by theOS/400 Query Optimizer. It does not exist afterthe query is ended.

think time. The time that the end-user spendsbetween two key-presses.

transaction data. Operational data provided byan OLTP system.


List of abbreviations

ABAP advanced businessapplication programming

APAR authorized problemanalysis report

ASP auxiliary storage pool

BAPI business applicationprogramming interface

BW SAP Business InformationWarehouse

GUI graphical user interface

EVI encoded vector index

IBM International BusinessMachines Corporation

ISICC International SAP IBMCompetence Center

ITSO International TechnicalSupport Organization

LPAR logical partitioning

OLAP on-line analyticalprocessing

OLTP on-line transactionprocessing

PTF program temporary fix

SPAM SAP Patch Manager

RDBMS relational databasemanagement system

SQL structured query language

113

Index

Aauxiliary storage pools (ASPs) 14, 17

Bbackup and recovery 23Business Application Programming Interface (BAPI)

Data BAPI 43Meta Data BAPI 43

business application programming interface (BAPI)1, 43Business Information Warehouse

Administrator Workbench 1Business Explorer 1characteristics 2components 1configuration examples 88database 1Delete InfoCube indexes function 59Dim ID 3Extractor 12, 44front-end 1InfoCube 3InfoObjects 2installation 7kernel 1key figures 2meta data repository 1prerequisites 7SAPGUI 1SID table 3sizing 87Statistics 47system administration 85system administrator 2system landscape 14

CChange Journal (CHGJRN) command 25Change Query Attributes (CHGQRYA) command51, 57Copy File (CPYF) command 38Copy To Stream File (CPYTOSTMF) command 41Create Physical File (CRTPF) command 39


Ddata access methods 4DB2 4dimension 3, 4Display Database Relation (DSPDBR) command63Display File Field Description (DSPFFD) command79

Ffact table 3

GGrant Object Authority (GRTOBJAUT) command25

Iindex

deleting index 59permanent index 68

InfoCube design 32International SAP IBM Competence Center (ISICC)87

LLoad and Run (LODRUN) command 8Logical Partitioning (LPAR) 14, 18

Mmaster data table 4memory pools 14

Pparallel load 65parallel processing 48

Qquery

long-running query 68optimizer 4performance analysis 72

115

RRSA1 33, 42, 47, 62, 85

SSave and Delete Receivers (SAVDLTRCV) com-mand 24Save R/3 System (SAVR3SYS) command 23SE11 80SQL

analyze SQL functions 75explain SQL function 75SQL Utility (SQLUTIL) 38trace 74

ST03 47, 60, 81ST05 47, 74Stop Save and Delete Receivers (SAVDLTRCVE)command 24Submit Job (SBMJOB) 25Symmetric Multiprocessing (SMP) 50system value

Parallel Processing Degree (QQRYDEGREE)51, 54, 57Performance Adjustment (QPFRADJ) 14

Ttuning techniques 47

WWork with Journal Attributes (WRKJRNA)command25Work with Shared Pools (WRKSHRPOOL) com-mand 15Work with System Status (WRKSYSSTS)command15



ITSO Redbook evaluation

SAP Business Information Warehouse on the AS/400 SystemSG24-5200-00

Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete thisquestionnaire 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 [email protected]

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!)

Printed in the U.S.A.

SG24-5200-00

SAP

Business

Information

Warehouse

onthe

AS

/400System

SG

24-5200-00

SAP Business Information Warehouse on the as 400 System

Documents

Transcript of SAP Business Information Warehouse on the as 400 System