Professional Documents
Culture Documents
http://www.redbooks.ibm.com
SG24-5200-00
SG24-5200-00
August 1999
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix C, “Special notices” on page 103.
This edition applies to SAP Business Warehouse Release 1.2B for use with the OS/400.
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1. Introduction . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .1
1.1 BW environment . . . . . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .1
1.2 Terminology . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .2
1.3 Database . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . . .4
Chapter 5. Performance . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 45
5.1 Performance monitoring tools . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 46
5.1.1 AS/400 system tools . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 46
5.1.2 BW tools. . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 47
5.2 Tuning techniques . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 47
5.3 BW and OS/400 parallel processing . . . .. . . . . .. . . . .. . . . . .. . . . . 48
5.3.1 Symmetric Multiprocessing (SMP) .. . . . . .. . . . .. . . . . .. . . . . 50
5.4 Analysis of BW performance behavior . .. . . . . .. . . . .. . . . . .. . . . . 59
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
1. BW tables relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Loading BW installation files to the AS/400 system. . . . . . . . . . . . . . . . . . . 9
3. R/3 installation menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Unpacking the patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Change the installation files directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. WRKSYSSTS — Allocating memory pool size . . . . . . . . . . . . . . . . . . . . . 15
7. WRKSHRPOOL — Memory pool priority. . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. STOPSAP — Stop R/3 system with ENDSBS option . . . . . . . . . . . . . . . . 17
9. Landscape 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Landscape 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Landscape 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Landscape 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Save R/3 System (SAVR3SYS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14. SBMJOB — Start SAVDLTRCV command . . . . . . . . . . . . . . . . . . . . . . . . 26
15. WRKACTJOB — SAVDLTRCV command . . . . . . . . . . . . . . . . . . . . . . . . 27
16. Source database design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
17. SOCUBE data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
18. SOCUBE data model expanded view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
19. SOCUBE tables — Partial view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
20. Source table conversion forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
21. CPYF from form 1 to form 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
22. Sample SQL — Convert form 2 into form 3 . . . . . . . . . . . . . . . . . . . . . . . . 39
23. CRTPF — Create intermediate table (form 4) . . . . . . . . . . . . . . . . . . . . . . 40
24. CPYF — Copy table to a single-column form . . . . . . . . . . . . . . . . . . . . . . 40
25. CPYTOSTMF — Copy table into a flat file. . . . . . . . . . . . . . . . . . . . . . . . . 41
26. Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
27. N-way processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
28. SMP processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
29. Go LICPGM —> Display installed licensed programs . . . . . . . . . . . . . . . . 50
30. ST03 — BW query performance analysis without SMP. . . . . . . . . . . . . . . 52
31. WRKACTJOB — CPU utilization of BW query without SMP . . . . . . . . . . . 53
32. WRKSYSVAL — Change system value QQRYDEGREE . . . . . . . . . . . . . 54
33. WRKACTJOB — CPU utilization of BW query with SMP . . . . . . . . . . . . . 55
34. Transaction ST03 — BW query performance analysis with SMP . . . . . . . 56
35. CHGQRYA — Change query attribute of a job . . . . . . . . . . . . . . . . . . . . . 58
36. ST03 — BW fact table data loading with indexes attached . . . . . . . . . . . . 60
37. WRKACTJOB — Data loading with indexes . . . . . . . . . . . . . . . . . . . . . . . 61
38. WRKDSKSTS — Disk status during data loading . . . . . . . . . . . . . . . . . . . 62
39. Delete InfoCube indexes before data loading . . . . . . . . . . . . . . . . . . . . . . 63
40. BW fact table data loading without indexes attached . . . . . . . . . . . . . . . . 64
v
41. SAP parallel load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
42. DB2 Symmetric Multiprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
43. WRKACTJOB — Parallel load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
44. WRKDSKSTS — Disk arm utilization during parallel load . . . . . . . . . . . . . 68
45. RSA1 — InfoCube Customer data model . . . . . . . . . . . . . . . . . . . . . . . . . 69
46. SAP Business Explorer Analyzer —> Define query. . . . . . . . . . . . . . . . . . 70
47. Starting the 0SD_C01_Q013 query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
48. Query result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
49. WRKACTJOB — BW query running with SMP enabled . . . . . . . . . . . . . . 73
50. ST03 — BW query transaction analysis, SMP enabled . . . . . . . . . . . . . . . 74
51. ST05 — SQL trace overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
52. ST05 — Explain SQL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
53. ST05 — Explain SQL statement —> Expand subtree . . . . . . . . . . . . . . . . 77
54. SQL SYSTABLES — Assign short/alternate table names. . . . . . . . . . . . . 79
55. DSPFFD — Map field names with alternate field names. . . . . . . . . . . . . . 80
56. SE11 — Create permanent index for BW database . . . . . . . . . . . . . . . . . 81
57. ST03 — Query monitoring with permanent index for table /BI00285. . . . . 82
58. ST05 — SQL trace overview with permanent index available . . . . . . . . . . 83
59. ST05 — Explain SQL statement, index available . . . . . . . . . . . . . . . . . . . 84
1. OS/400 terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Libraries created during the installation of BW . . . . . . . . . . . . . . . . . . . . . 13
3. Backup activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Table Trans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. Table Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Table Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. OLTP versus OLAP workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8. Effect of performance improvement techniques in BW . . . . . . . . . . . . . . . 48
9. Query runtime comparison with and without SMP . . . . . . . . . . . . . . . . . . . 56
10. Runtime comparison — Data loading of fact table. . . . . . . . . . . . . . . . . . . 64
11. Data loading test results summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
12. Tables in the InfoCube Customer — Test data . . . . . . . . . . . . . . . . . . . . . 71
13. Field names with their alternate field names . . . . . . . . . . . . . . . . . . . . . . . 80
14. Query 0SD_C01_Q013 runtime comparison . . . . . . . . . . . . . . . . . . . . . . . 85
15. Table Trans1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
16. Table Transch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
17. Flat file Part.csv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
18. Flat file Cust.csv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
19. Flat file Trans.csv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
vii
viii SAP Business Information Warehouse on the AS/400 System
Preface
This redbook explores the SAP Business Information Warehouse (BW) on the
AS/400 system. It takes a close look at the tasks and functions that are
specific for the AS/400 environment, rather than the BW generic task. This
redbook is designed to assist AS/400 technical specialists and SAP Basis
consultants in implementing this technology.
As you read this redbook, you uncover valuable information that includes:
• Terminology and an overview of BW and AS/400 features
• The BW setup
• Recommendations for backup and recovery procedures
• Examples on how to load the BW with operational data from an online
transactional processing (OLTP) system that runs a company’s day-to-day
business (requires that you already understand BW administrator tasks
related to the creation of a data warehouse in BW)
• Hints on how to improve the performance of the AS/400 BW system
(assumes that you are fairly skilled in SAP R/3-AS/400 performance
topics)
• Preliminary sizing recommendations based on tests and SAP
recommendations
Thanks to the following people for their invaluable contributions to this project:
Barbara Ballard
George Barta
Dave Hubka
Dan Moravec
Ron Schmerbauch
IBM Rochester, SAP Port
Nitin Raut
IBM Rochester, Technology Solutions Center
Amy Anderson
IBM Rochester, Teraplex Center
Bryan Tousley
IBM Rochester, Partners in Development
Daniel Toft
IBM Rochester, Performance
Raymond Bills
IBM Rochester, Integrated File Systems
Jarek Miszczyk
Gottfried Schimunek
International Technical Support Organization, Rochester Center
xi
xii SAP Business Information Warehouse on the AS/400 System
Chapter 1. Introduction
1.1 BW environment
BW consists of several components that are used for data collection, data
use, and data maintenance. These components include:
• Business Information Warehouse Server with OLAP processor and
Staging Engine
• Meta data (data about data) repository that documents the data
warehouse environment
• Business Explorer, a graphical user interface (GUI), hosted by Microsoft
Excel or Lotus 1-2-3, that provides analyzing and viewing functions for
end-users
• Automated data extraction and data loading routines
• Administrator Workbench, a GUI-based tool that is used for BW
implementation, maintenance, customizing, scheduling, and monitoring
• Business application programming interface (BAPI) that provides links to
external tools for data extraction, data loading, and data analysis
1.2 Terminology
AS/400 end-users store and access their data in a relational database and in
flat files (also called stream files) in the Integrated File System (IFS). The
relational database consists of two-dimensional files that are in SQL
terminology called tables. Tables are made up of columns and rows. Indexes
and views are built upon the tables to provide users with quick access to
data. Tables, indexes, and views are grouped in an SQL collection.
Column Field
Row Record
BW terminology
In addition to DB2 data structures, BW organizes data in its own data
structures.
The basic building blocks of BW are called characteristics and key figures.
The generic term for characteristics and key figures is InfoObjects. When you
create the data warehouse on your BW system, you start by creating your
InfoObjects.
A fact table contains all of the key figures at the lowest level of detail. A
dimension table contains characteristics that are required both in reporting
and in the analysis of the key figures. Characteristics are grouped into a
dimension table based on a business content logic. Dimension tables are
independent of one another. Only the fact table connects dimension tables
through key figures.
Dimension tables are linked to the fact table using surrogate keys. A
surrogate key (Dim ID) is used as a unique key with each dimension table.
The master data table and the dimension table are linked by system
generated identifications called Set IDs that are stored in SID (Set ID) tables.
Introduction 3
The master data table contains attributes of characteristics, while the
dimension table contains the characteristics themselves. The dimension table
with its associated SID table and its master data table form a dimension.
1.3 Database
The BW database is running on IBM DB2 Universal Database for AS/400 (in
this document we call it DB2). DB2 is a Relational Database Management
System (RDBMS) that is a part of the Operating System/400. Since it is a part
of the system, DB2 fully utilizes all the AS/400 features. Compared to other
RDBMS products on the market, DB2 brings to BW users a number of unique
features, such as:
• DB2 is free-of-charge.
• It is automatically installed with OS/400.
• It does not require a database administrator to manage it.
• Because it uses the OS/400 single level storage, it does not have to be
partitioned. For this reason, there is no distinction between primary and
secondary indexes in DB2, as in some other RDBMS systems.
• Usage of the OS/400 Query Optimizer. This is a cost-based optimizer,
which is described in the following section.
Possible data access methods that the optimizer may choose are:
• Non-keyed access methods: Table scan, parallel table scan, parallel
pre-fetch, parallel table pre-load, skip sequential with dynamic bitmap, and
parallel skip sequential
• Keyed access methods: Key positioning and parallel key positioning,
dynamic bitmaps (index ANDing or ORing), key selection and parallel key
selection, index from index, index only access, and parallel index preload
• Joining, grouping, ordering: Nested loop join, hash join, index grouping,
hash grouping index ordering, and sort
Since the data access costs dynamically change, the optimizer changes the
access methods as well. Depending on the estimated costs, the optimizer
may use any of the available methods to access the requested data. We
show you an example of how you can observe and partly influence the
optimizer’s decisions in 5.4.2.2, “Query performance analysis” on page 72.
Introduction 5
6 SAP Business Information Warehouse on the AS/400 System
Chapter 2. Installation and set up
This chapter describes the installation and setup tasks needed to have BW
up and running. It lists the tasks and provide some hints on how to approach
the installation of BW on the AS/400 server. Since this chapter does not
describe every installation step in detail, it should serve as a reference rather
than a detailed installation guide. For a detailed description of the installation
and setup tasks, please refer to the BW installation guide (scheduled to be
published in summer 1999) and in SAP OSS notes.
2.1 Prerequisites
To successfully set up BW on the AS/400 system, you need to have following
prerequisites:
• Hardware
– Server: AS/400 server with PowerPC technology. Chapter 6, “Sizing
considerations” on page 87, provides preliminary sizing guidelines.
– Workstation: A PC with a minimum of 48 MB of main memory on
Windows 95, 64 MB on Windows NT, and 1 GB disk space. To work
comfortably with BW, we recommend that you double the memory size.
• Software
– Server:
• OS/400 V4R4 with TCP/IP installed. It is technically possible to run
BW on OS/400 V4R3. However, we do not recommend it since it is
not supported by IBM and SAP.
• AS/400 PTFs listed in IBM APAR number II11832 (for V4R4) or
number II11296 (for V4R3).
• SAP Business Information Warehouse release 1.2B installation CDs
with documentation.
• BW patches specified in SAP OSS note 0149750.
• OS/400 optional, chargeable feature "DB2 Symmetric
Multiprocessing for OS/400" is highly recommended.
In addition, a good knowledge of the SAP R/3 basic technology and OS/400
is very helpful.
2.2 Installation
First, install the BW front-end to the administrator’s PC from the installation
CD. BW front-end installation is described in detail in the brochure Frontend
Installation (Mat. No. 5100 3943). Install all program temporary fixes (PTFs)
on the AS/400 system as recommended in IBM Information APAR for your
OS/400 release. You can get this APAR in AS/400 APAR database on the
Internet at: http://www.as400.ibm.com/service/bms/support.htm
Bottom
Type command, press Enter.
===> lodrun *opt dir('/os400/as400/install')
Selection or command
===> 1
Press Enter. Then, you are prompted for the SAP System ID (SID) that
you want to install. After doing so, the directory /tmp/<sid> where the
installation files will be copied is created. <sid> is the SID that you
specified.
4. Install the BW central instance with a database by selecting option 2 on
the R/3 Installation menu. Then, specify the installation file name or file
names in case you are installing a three-tier environment. If you are
installing a two-tier environment, specify the file CENDBBW.R3S. If you are
installing a three-tier environment, specify the file CENTRAL.R3S and then
the file DBBW.R3S. This task may take several hours.
5. Install all BW patches specified in SAP OSS note 0149750. Download
the patches to your PC in one of two ways:
• From the SAPNet Internet home page at http://sapnet.sap.com
You need to have a user ID provided by SAP to logon to SAPNet.
• From the SAP service system by logging on to SAP system CSS
from the SAP front-end.
To install the BW patches, complete these steps:
a. Transfer patches from your PC to the AS/400 server in the directory
/usr/sap/trans. You can use any file transfer method (FTP, for
Directory . . . . : /usr/sap/trans
Directory . . . . . . . . . . . '/QOPT/CD51005919/40B_INST/OS400/AS400'
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Notes:
1
<SID> is System ID. < xxxxx> is a combination of characters and numbers. For
example, a library name can be R3BWAA1980.
2
<REL> is R/3 kernel release.
In addition to the libraries, the following directory trees are created in the
integrated file system (IFS):
• /usr/sap/
• /sapmnt/
These IFS directories contain documents that are not stored in the BW
database, for example, spooled files or transports.
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.
When using multiple SAP systems on one machine, you also have to
consider potential performance impacts of one system on the other. Each
SAP system requires resources to run (CPU, disk, main memory). Certain
operations can cause heavy loads in one or more resource type.
2.3.1.1 Memory
Each SAP BW or R/3 system runs in its own OS/400 subsystem. Each
OS/400 subsystem runs in the OS/400 memory pool. The SAP system
typically runs in the *BASE memory pool, since it is usually the largest pool.
Multiple SAP systems can be set to all run in the same memory pool (shared
memory pool) or to run in separate memory pools. If they are sharing a
memory pool, they are contending equally for the same resources. An SAP
system that runs in a separate memory pool does not have other systems
contending for its memory. Therefore, it will perform better, providing that the
size of its memory pool is large enough.
The size of the memory pool can be either fixed or dynamically adjusted by
the AS/400 system. This is defined by the system value Performance
Adjustment (QPFRADJ). If QPFRADJ is set to the value "0", and SAP
Bottom
Command
===>
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Restart
F11=Display transition data F12=Cancel F24=More keys
If the system value QPFRADJ is set to the value "2", OS/400 performs
automated dynamic performance tuning, which includes periodical
adjustments of memory pools sizes. This dynamic tuning checks the paging
rates and adjusts memory pool sizes to reduce paging. For example, if
memory pool X has a lot of paging, and pool Y has little paging, OS/400 will
move some memory from pool Y to pool X. In case there are several pools
that need more memory, the memory is allocated to the pool with a higher
priority as defined in the memory pool description. Use the OS/400 command
Work with Shared Pools ( WRKSHRPOOL) to set priorities on the memory pools as
shown in Figure 7 on page 16.
The WRKSHRPOOL command is also used to protect the SAP system that
runs in the lower priority pool from losing so much memory that it can no
longer function. This is defined by setting the minimum percentage of total
memory for a pool (Figure 7).
Recommendation
Set the most performance-critical BW system (for example, production
system) to run in the *BASE pool and other systems in shared memory
pools. Set the paging option of all memory pools in which SAP systems are
running to *CALC. Set the system value QPFRADJ to 2. Set the priority of
*BASE pool to 1 and the priority of other pools with SAP systems to 2 or
lower.
When ending the BW, consider ending the OS/400 subsystem as well. This
releases the memory allocated to that subsystem. If only BW is in the
memory pool, then you should also end the subsystem. You can do this using
the STOPSAP command with the parameter "End subsystem" set to *YES (the
default value is *NO) and the parameter "Wait for instance to end" set to
*YES. Figure 8 on page 17 shows an example of the STOPSAP command.
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
2.3.1.2 CPU
Processors are not allocated to OS/400 subsystems or SAP systems. They
are always shared across all jobs running on the same AS/400 system (or a
logical partition as described in the next section). However, CPU priority and
time slices can be managed at the subsystem level. This way you can always
allocate to the most important SAP system (for example, production system)
quicker access to the CPU and larger portion of the CPU time. In addition,
you can also manage them within the SAP system so that interactive and
batch BW processes in one BW system are running at different priorities.
2.3.1.3 Disk
Auxiliary storage pools (ASPs) can be used to separate disk resources for
different SAP systems. You may assign a separate ASP to each SAP system.
These ASPs can be grouped on their own IOP for further granularity. A
separate ASP will protect users of SAP system X, for example, from
performance impact of high disk arm activity produced by users of SAP
system Y. However, this approach is generally not recommended. An
increased number of ASPs reduces the number of disk arms in each ASP,
which will, in most customer situations, reduce the performance of all SAP
systems.
In such cases, the AS/400 feature Logical Partitioning (LPAR) may help.
LPAR overcomes these limitations by allowing you to install several copies of
the operating system (even with different releases) on a single AS/400
machine. LPAR divides an AS/400 machine into two or more logical
partitions. A logical partition is a virtually independent system with its own
CPU (or CPUs), main memory, system bus (or buses), I/O processors, disks,
a copy of OS/400, and all application software. The maximum number of
logical partitions on one machine is equal to number of available CPUs.
Please refer to the redbook Slicing the AS/400 with Logical Partitioning: A
How to Guide, SG24-5439, for more information on LPAR.
• SAP R/3 and BW both run on the same machine. The R/3 production
system runs in one LPAR, and the BW production system runs in a second
LPAR. The rationale behind this scenario is improved performance of
loading the BW with R/3 data (Figure 10).
• SAP R/3 system runs in one LPAR. BW test system and BW integration
system both run in a second LPAR. BW production system runs on a
second machine or a third LPAR on the same machine as shown in Figure
11 on page 20.
• The plain BW test system and BW integration system run in one LPAR.
The SAP R/3 test system and the SAP R/3 integration system both run in a
second LPAR. The BW production system runs on a second machine (or a
third LPAR) as shown in Figure 12.
3.1 BW system
The BW system can be backed up with the OS/400 command Save R/3
System (SAVR3SYS). With this command, you may save the entire BW
system (except of the SAP kernel library) or only a part of it, depending on
how you specify the parameters of this command. Figure 13 on page 24
shows how to save a BW system with a BW database, configurations
(libraries R3400 and R3<SID>400), and SQL packages.
Use the SAVR3SYS command when there are no active users on the system, for
example, at night after the BW is reloaded with data from an OLTP system.
Please refer to the SAP OSS note 86305 for information on how to obtain the
SAVR3SYS command.
...
Job name . . . . . . . . . . . . SAVDLTRCV Name, *JOBD
Job description . . . . . . . . *USRPRF Name, *USRPRF
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Job queue . . . . . . . . . . . *JOBD Name, *JOBD
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Job priority (on JOBQ) . . . . . *JOBD 1-9, *JOBD
Output priority (on OUTQ) . . . *JOBD 1-9, *JOBD
Print device . . . . . . . . . . *CURRENT Name, *CURRENT, *USRPRF...
More...
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
After the job is submitted, the SAVDLTRCV command will be active all the
time waiting for a message as shown in Figure 15 on page 27.
The file interface handles the importing of transaction data and master data
into the Staging Engine in a flat file format. The flat file can be either in ASCII
or Microsoft Excel (CSV) format. The file interface requires manual
maintenance of meta data in BW. Therefore, SAP recommends that you use
this interface only in cases where the source data is already defined in a file
format or when a quick solution is desired. We provide an example of using
the file interface in the following section.
The BAPI interface allows the importing of transaction data, master data, and
meta data from the source system in an automated, repeatable way that
allows dynamic selections. See the description of the BAPI interface in 4.1.2,
“Business application programming interface” on page 43.
The source database consists of three tables: one transaction data table
(Trans) and two master data tables (Part and Customer).
The transaction data table contains quantity, cost, and time information about
parts and customers. Its structure is shown in Table 4.
Table 4. Table Trans
After we determine the purpose that this InfoCube will serve, we design and
create the InfoCube named SOCUBE with the following structure:
• InfoObjects defined as characteristics:
– Part number
– Customer number
– Date
– Currency
DATAFL DATAFL
Customer Master
INCFL Filenm:/BIC/MCUNO INCFL
Short Name:/BIC0035 Part Master Table
Filenm:/BIC/MPARTNO
Short Name:/BIC0043
CUNO
OBJVERS
PARTNO
CHANGED OBJVERS
CUSTNM CHANGED
COUNTRY PARTNM
REGION
ADDRESS
Character
The first line of text for each form in Figure 20 describes the column name.
The second line graphically represents columns in a row. The third line
describes the column type.
Additional Parameters
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
2. All columns that are not of character type are converted into character
type.
Table Transch (form 3) is created with all columns type character. The
description of Transch is in Table 16 on page 92.
Then, an SQL INSERT command (Figure 22 on page 39) is used with the
CHAR and SUBSTR functions to copy the data from form 2 to form 3. You
can run the SQL INSERT command from the SQL Utility screen that you
get after running the OS/400 command SQL Utility (SQLUTIL). SQLUTIL
Navigation attributes and master data that is associated with SID tables
must be converted to upper-case characters. This is done using the SQL
UPPER function.
3. The number of all columns in a row is reduced from six to one.
Table Charfile (form 4) is created with a single column, type character, and
length of 82 (long enough to hold all the columns of Transch). The Create
Physical File (CRTPF) command is used to create this table (Figure 23 on
page 40). Then, the CPYF command with the *NOCHK parameter is used
to copy the data from form 3 to form 4 (Figure 24 on page 40).
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Additional Parameters
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
After repeating these three steps for all three source tables, we get three flat
files (PART.CSV, CUST.CSV, and TRANS.CSV.) that serve as the input for the
BW data loading function.
The BAPIs are provided for use for BW customers and third-party tool
providers. They can use the BAPIs and connect their meta data source
system and their extract engines to BW.
The differences between the OLTP and OLAP workload are summarized in
Table 7.
Table 7. OLTP versus OLAP workload
OLTP OLAP
5.1.2 BW tools
Use the following SAP tools for analyzing BW performance on the application
level:
• ST03 to get response times and resource usage information (summarized
as well as for single transactions).
• ST05 to trace the execution of SQL statements in SAP transactions.
• RSA1 to obtain SAP statistical records.
• BW Statistics to find out which queries, InfoCubes, InfoSources,
InfoObjects, source systems, aggregates and so on are currently being
used, and how frequently and who is currently using the system. It can
help you answer these questions: Are there queries whose runtime is over
the time allowed? Are batch jobs and printing executed in times of less
work? How does the data flow through the data warehouse?
For more information about BW Statistics, please refer to the SAP
document SAP BW Statistics, ASAP for BW Accelerator, Document
Version 1.0, which is available on SAPNet.
For more information about the SAP R/3 monitoring, please refer "7.1 SAP
R/3 Monitoring" in the redbook SAP R/3 Implementation for AS/400,
SG24-4672.
Performance 47
• Creation of permanent indexes. Use it in situations where the same
temporary indexes are often built by the system as described in 5.4.2.2,
“Query performance analysis” on page 72.
• LPAR. Putting the BW and the source OLTP system on one AS/400
system into different LPARs will improve performance of BW data loading.
An example is shown in Figure 10 on page 19.
In Figure 27, eight CPUs work on several jobs at one time without any
special programming.
• SMP (Symmetric Multi-Processing): This is the ability of a
multiprocessor system to take one job, divide it up into tasks, and have
more than one processor work on that one job simultaneously (Figure 28).
Each processor gets to work on one or more tasks.
In Figure 28, all eight CPUs work on one job. The system automatically
divides the job into tasks.
Performance 49
• MPP (Massively Parallel Processing): This is also called shared nothing
parallelism. With MPP, several separate systems (nodes) are hooked
together using high-speed communications, such as OptiConnect. They also
use a database that can treat all the nodes as a single database image. MPP
is the main method of parallelism on UNIX systems, where many 1-way to
4-way nodes with relatively small amounts of attached DASD are connected
to create a large system. MPP is available on the AS/400 system through
DB2 Multisystem.
SMP can only be used if the OS/400 optional feature "DB2 Symmetric
Multiprocessing for OS/400 (SMP)" is installed. To check if SMP is installed,
go to the OS/400 menu LICPGM. Select option 10 and search for the text
shown in bold in Figure 29.
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
First, we ran the query without the SMP enabled. Figure 30 on page 52 shows
the run-time results of the SAP work process (for example, AS/400 job) that
ran this query.
Performance 51
Figure 30. ST03 — BW query performance analysis without SMP
The query was a long-running one with a half hour (1825 seconds) response
time. The WRKACTJOB command (Figure 31 on page 53) shows a snapshot
of the job that ran this query.
Job DISP that ran our query used only 17.5% of CPU time, even though there
were no other users on the system. This is understandable considering that,
without the SMP, such a job is processed by only one CPU at a time. Since a
single job on a 4-way system without the SMP can use up to 25% of CPU
time (100% utilization of one out of four available CPUs), our job really used
70% of available CPU time. The three remaining CPUs remained idle.
Performance 53
Change System Value
Degree of parallelism
allowed . . . . . . *MAX *NONE
*IO
*OPTIMIZE
*MAX
With SMP enabled, we ran the query again. The WRKACTJOB screen
(Figure 33) shows that the same job now used 50.1% of CPU time (compare
this to 17.5% without SMP).
Performance 55
Figure 34. Transaction ST03 — BW query performance analysis with SMP
Table 9 shows comparisons of the query runtimes with and without SMP
enabled.
Table 9. Query runtime comparison with and without SMP
In 5.4.1, “Loading the BW with data” on page 59, and 5.4.2, “Long-running
query” on page 68, we examine some of the conditions under which the SMP
can bring performance improvements.
Performance 57
Change Query Attributes (CHGQRYA)
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
The "Number of tasks" parameter specifies the number of tasks that will run a
given query, index build, or maintenance in parallel. If you specify the number
of tasks as two, then only two CPUs process the job, while other CPUs (if
they exist) are idle. We recommend that you specify a number of tasks that is
less than the number of all CPUs on the system. This prevents a single job
from monopolizing the entire system by using all available CPUs. For
example, on an 8-way system, restrict the SMP to use only two CPUs per job
by specifying the Number of tasks as two. This will allow up to four jobs to run
queries in parallel without affecting one another. Each of the four jobs will use
two CPUs.
Before changing the parameters of a job with CHGQRYA, you need to know
the name of this job. This may be difficult in cases when there is more than
one BW job on the system, since you cannot influence the SAP dispatcher’s
decisions. For this reason, we recommend that you change the CHGQRYA
parameters for all DISP jobs of an SAP instance in the same manner. You can
do this either manually or by a CL program that analyzes and changes the
parallel processing degree for all DISP jobs of the SAP instance. Keep in
mind that sometimes BW may restart its work processes automatically. If this
happens, then all attributes of the job will be reset to default. Therefore, the
CL program that changes query attributes must be run again.
All tests were done on an AS/400e Model S30, processor feature #2260 with
eight CPUs, 4 GB main of memory, 28 x 4.19 GB disks drives, and OS/400
V4R3.
In addition, you can improve the data loading performance by putting the BW
and the source system on the same AS/400 machine and using LPARs as
shown in Figure 10 on page 19.
The examples in this section show runtime results of loading the InfoCube
SOCUBE described in Chapter 4, “Loading the BW with data” on page 29.
This example was done on OS/400 V4R3 using Binary Radix Tree type of
indexes. Encoded vector indexes (EVI) that are available for SAP users in
V4R4 bring additional performance improvements.
Performance 59
Data loading with indexes
First the fact table is loaded with 100,029 rows and all indexes attached. This
data loading consists of two main tasks:
• Reading data sequentially from one flat file and inserting this data into
rows in fact table /BIC0059.
• Maintaining all depending indexes while loading the data.
Figure 36. ST03 — BW fact table data loading with indexes attached
We closely look at the response time (1974 sec.), the processing time (1417
sec.), and DB request time (509 sec.). The total CPU time of this data loading
was 1847 sec., which is approximately 93.5% of the total response time.
Figure 37 on page 61 shows a snapshot taken during the data loading. The
SMP feature is enabled. However, SMP is only used to maintain indexes and
is not used for data inserting.
Our data loading is processed by the first DISP job shown in Figure 37.
During the snapshot, this job utilized 11.7% of CPU time. On an 8-way
machine, a single and serially processed job can use up to 12.5% of CPU
(100% divided by 8).
To find out possible I/O bottlenecks of this job, we used the OS/400 Work with
Disk Status (WRKDSKSTS) command. The results are shown in Figure 38 on
page 62.
Performance 61
Work with Disk Status TSCSAP03
05/21/99 13:50:12
Elapsed time: 00:01:51
With none of the disk arms busy more than 1%, there were no I/O bottlenecks
during this test.
You do not need to know names of the index files to perform this action. BW
knows which indexes are built on the fact table. However, sometimes you
need to know the names of indexes that are attached to your tables (see the
example in 5.4.2.2, “Query performance analysis” on page 72). You can find
the names either with SAP transaction SE11 (ABAP Dictionary) or the OS/400
command Display Database Relation (DSPDBR). To find out which indexes
are attached to our fact table /BIC0059, we typed:
DSPDBR FILE(*LIBL/"/BIC0059")
Figure 40 on page 64 shows the performance results of the data loading with
"Delete InfoCube indexes" function enabled. All indexes based on fact table
/BIC0059 were deleted by BW before the start and recreated after the end of
data loading.
Performance 63
Figure 40. BW fact table data loading without indexes attached
A comparison of the results in Figure 40 with the results of the data load with
indexes (Figure 36 on page 60) shows significant runtime improvements.
Table 10 summarizes the performance comparison of the two data loads.
Table 10. Runtime comparison — Data loading of fact table
The performance behavior of master data tables load looks similar to fact
table data loading, shown in Figure 36 on page 60. There is a similar ratio
between processing time, CPU time, and DB request time.
Use the "Delete InfoCube indexes" function on a fact table whenever the time
needed to recreate indexes after the data load is shorter than the time
needed to maintain indexes during the data loading. This may not be true in
the case of a delta update where you add records to the fact table, which
already contains many records. In this case, the time needed to recreate
indexes may be longer.
Rule of thumb
When the delta update includes 10% or more of the table, delete the
indexes, run the update, and then recreate the indexes. Every customer
should run their own tests of this procedure. The results can vary widely
based on the type of update and the complexity and number of indexes.
Performance 65
SAP BW Work Processes AS/400 Processor Tasks
Recommendation
To achive maximum performance of a data loading job, use the parallel
load with as many SAP work processes as there are CPUs on the BW
system.
Using the WRKDSKSTS command to find out possible I/O bottlenecks during
the parallel load, again we did not find any I/O bottlenecks. The disk arm
utilization in our example (Figure 44 on page 68) was similar to the
non-parallel load shown in Figure 38 on page 62.
Performance 67
Work with Disk Status TSCSAP03
05/25/99 18:45:03
Elapsed time: 00:04:37
This section shows how to analyze and improve query run-time performance
through the example of using a typical BW query.
The query used in this example is based on the InfoCube Customer, which is
delivered by the SAP to run BW benchmarks. This InfoCube contains a part
Performance 69
The query fetches the invoiced quantity, netvalue of invoiced sales, and cost
of invoiced sales. They are grouped by sold-to-party and filtered by
fiscal-year-variant. The design of this query named 0SD_C01_Q013 is shown
on the SAP Business Explorer Analyzer "Define query" window in Figure 46.
Table 12 on page 71 shows which tables are joined to run this query and the
amount of records stored in these tables.
Performance 71
Figure 48. Query result
Performance 73
Figure 50. ST03 — BW query transaction analysis, SMP enabled
The largest part of the response time (121 sec.) is the processing time (118
sec.). Only 2.5 sec. was used for DB request time. The CPU time is larger
than the total response time (536 sec. versus 118 sec.) due to the SMP
(multiple CPUs were processing this job).
The SQL OPEN function (at time stamp 17:13:35) took more than 105 sec.
(89% of the total processing time) to process the SELECT statement. It is
obvious that, in this case, the biggest potential for performance improvement
is in optimizing the SQL OPEN function. To analyze SQL functions, click on
the Explain SQL button to get the Database Performance: Explain window
(Figure 52 on page 76).
Performance 75
Figure 52. ST05 — Explain SQL statement
We can see that, in our query, the SQL SELECT statement joined eleven files
and selected many columns. On this window, we click on the Expand Subtree
button for more details on how the SQL SELECT statement was processed.
The Database Performance Explain window appears, which is partly shown in
Figure 53 on page 77.
Performance 77
before starting the query. When the query runs unchanged next time, the
optimizer will again select the same access method, find out that the index
already exists, and use the existing index instead of creating a temporary
one.
Recommendation
You can create a permanent index with any native OS/400 tool. However,
we strongly recommend that you create it inside the SAP environment. In
this case, the index will be known in the SAP Data Dictionary. The index
will always be considered during system upgrades and other important
system tasks such as deleting or recreating indexes during data loading.
To create an index with SAP Data Dictionary, you must know the alternate
names (long names and short names) of the table and fields.
The table short name is depicted in the Explain SQL function (Figure 53 on
page 77). In this example, the table short name is "/BI00285". To find out the
table long name, use the OS/400 command SQLUTIL. Then, press the Enter
key, and specify the parameters as shown here:
SELECT SYSTEM_TABLE_NAME, TABLE_NAME FROM
R3BWADATA/SYSTABLES
WHERE NAME LIKE '/BI0%'
After pressing the Enter key, we get the list of all tables and search for the
known short name to find out the fact table’s alternate name. As shown in
Figure 54 on page 79, the table alternate name in this example is
/BI0/F0SD_CO01.
Next, we find out the alternate field names. We use the OS/400 Display File
Field Description (DSPFFD) command as shown here:
DSPFFD FILE(R3BWADATA/"/BI00285")
Pressing the Page down key brings the second screen with field names and
their alternate field names (Figure 55 on page 80).
Performance 79
Data Field Buffer Buffer Field Column
Field Type Length Length Position Usage Heading
KEY_000001 BINARY 9 0 4 1 Both KEY_0SD_C01P
Alternative name . . . . . . . . . . . . : KEY_0SD_C01P
Default value . . . . . . . . . . . . . . :
0
KEY_000002 BINARY 9 0 4 5 Both KEY_0SD_C01T
Alternative name . . . . . . . . . . . . : KEY_0SD_C01T
Default value . . . . . . . . . . . . . . :
0
KEY_000003 BINARY 9 0 4 9 Both KEY_0SD_C01U
Alternative name . . . . . . . . . . . . : KEY_0SD_C01U
Default value . . . . . . . . . . . . . . :
0
KEY_000004 BINARY 9 0 4 13 Both KEY_0SD_C011
Alternative name . . . . . . . . . . . . : KEY_0SD_C011
Default value . . . . . . . . . . . . . . :
0
KEY_000005 BINARY 9 0 4 17 Both KEY_0SD_C012
More...
F3=Exit F12=Cancel F19=Left F20=Right F24=More keys
Figure 55. DSPFFD — Map field names with alternate field names
KEY_000001 KEY_0SD_C01P
KEY_000003 KEY_0SD_C01U
KEY_000004 KEY_0SD_C011
KEY_000006 KEY_0SD_C013
KEY_000008 KEY_0SD_C015
After this step, you have all information needed to create a permanent index
that the optimizer will use instead of a temporary one. Use the SAP
transaction SE11 (Figure 56 on page 81) to create this index.
As shown in Figure 56, we created index ID=090 for the fact table
/BI0/F0SD_C01 with the alternate field names as listed in Table 13 on page
80. After we created this permanent index, we ran our query again. The ST03
monitor result shown in Figure 57 on page 82 summarizes the performance
data of this second run.
Performance 81
Figure 57. ST03 — Query monitoring with permanent index for table /BI00285
In comparison with the first run, shown in Figure 50 on page 74, all key times
(response time, processing time, and CPU time) were reduced significantly.
The ABAP SQL Trace (transaction ST05 in Figure 58 on page 83) explains
this improvement.
Performance 83
Figure 59. ST05 — Explain SQL statement, index available
Instead of creating a temporary index for about 4.9 millions records, the
optimizer now decided to use the existing permanent index
/BI0/F0SD_C01+090 that we created.
We ran our query for the third time. This time, we deleted the index and
recreated it immediately, before we ran the query. This forced the optimizer to
rebuild the access plan.
Performance results of all three runs are summarized in Table 14 on page 85.
It compares runtimes monitored by the transaction ST03 (for response time,
Summary
Query performance may be significantly improved by using a permanent
index. However, this index will deteriorate the performance of InfoCube data
loading. Compare the advantage of improved query performance against the
disadvantage of increased data loading time. If the disadvantage is bigger,
use a temporary index with SMP enabled.
Performance 85
86 SAP Business Information Warehouse on the AS/400 System
Chapter 6. Sizing considerations
At the time this redbook was published, there was no sizing data available,
based on benchmarks or production environments. As such, all conclusions
in this section are preliminary. For BW sizing guidelines, please contact the
International SAP IBM Competence Center (ISICC) by e-mail at this address:
infoserv@de.ibm.com
For detailed information, please refer to the SAP R/3 sizing documentation
published by ISICC.
For more information, please refer to the SAP publication Performance and
Sizing, ASAP for SAP BW Accelerator, Document Version 1.0, which is
available on SAPNet.
We recommend that you start the implementation project with a system that
provides enough CPU power to simulate the future production environment
with a reasonable amount of test users. After the optimization phase of the
implementation project is finished, you can decide the final configuration.
Sizing considerations 89
90 SAP Business Information Warehouse on the AS/400 System
Appendix A. Files used in the example of InfoCube data loading
This appendix contains descriptions of the tables and files used in 4.1.1, “File
interface — An example” on page 29.
Table 15. Table Trans1
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
Customer Number 6
Delimiter 1
Delimiter 1
Currency 3
Delimiter 1
Calendar Day 10
Delimiter 1
Quarter 5
Delimiter 1
Year 4
Delimiter 1
This appendix contains the RPG code used in 4.1.1, “File interface — An
example” on page 29.
* *PROGRAM DESCRIPTION
*----------------------
*
* This program reads 3 DB2/400 files and creates a stream file
* version of each. ';' separators are added between fields in the
* stream files. Character fields are made all upper case. Decimal,
* integer and date fields are converted to character.
* Logic should be added to check return codes.
*
*LICENSE AND DISCLAIMER
* ----------------------
* This material contains IBM copyrighted sample programming
* source code. IBM grants you a nonexclusive license to use,
* execute, display, reproduce, distribute and prepare derivative
* works of this sample code. The sample code has not been
* thoroughly tested under all conditions. IBM, therefore, does
* not warrant or guarantee its reliability, serviceablity, or
* function. All sample code contained herein is provided to you
* "AS IS." ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
* NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILLITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE HEREBY DISCLAIMED.
*
* COPYRIGHT
* ---------
* (C) COPYRIGHT IBM CORP. 1997, 1998
* ALL RIGHTS RESERVED.
* US GOVERNMENT USERS RESTRICTED RIGHTS -
* USE, DUPLICATION OR DISCLOSURE RESTRICTED
* BY GSA ADP SCHEDULE CONTRACT WITH IBM CORP.
* LICENSED MATERIAL - PROPERTY OF IBM
* * ----------------------
* * Compile Instructions:
* * CRTMOD and then CRTPGM
* *****************************************************************
* F I L E D E S C R I P T I O N S P E C I F I C A T I O N *
**********************************************************************
*
fpart if e k disk rename(part:pt)
f prefix(p_)
fcustomer if e k disk rename(customer:cust)
f prefix(c_)
ftrans if e k disk rename(trans:tr)
f prefix(t_)
*******************************************************************
*
* START OF WHAT SHOULD BE IN A RPG INCLUDE FILE
*
******************************************************************
*****************************************************************
********************************************************************
*
* (from member UNISTD, file H, library QSYSINC)
*
* stream file (flat file) Close definition;
*
*****************************************************************
* value returned = 0 (OK), or -1
Dclose 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
*********************************************************************
* 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')
d ptrec ds
d pb_partkey 6
d pb_sep 1 inz(';')
d pb_part 25
d pb_sep2 1 inz(';')
d pb_hexend 2 inz(X'0D25')
d curec ds
d cu_custkey 6
d cu_sep 1 inz(';')
d cu_address 32
d cu_sep2 1 inz(';')
d cu_country 25
d cu_sep3 1 inz(';')
d cu_customer 25
d cu_sep4 1 inz(';')
d cu_region 25
d cu_sep5 1 inz(';')
d cu_hexend 2 inz(X'0D25')
d trrec ds
d tb_quantity 11
d tb_sep 1 inz(';')
d tb_cost 15
d tb_sep2 1 inz(';')
d tb_partkey 6
d tb_sep3 1 inz(';')
d tb_custkey 6
d tb_sep4 1 inz(';')
d tb_date 8
d tb_sep5 1 inz(';')
d tb_cur 3
d tb_sep6 1 inz(';')
d tb_calday 8
d tb_sep7 1 inz(';')
d tb_calmon 6
d tb_sep8 1 inz(';')
*
****************************************************************
* MAIN *
****************************************************************
* Use the open API to create the file, specifying that the data
* to be stored in it will be in codepage (ccsid) 437 (or whateve
* you change it to above in the CP field).
*
*****************************************************************
*
C EVAL FileNam=%TRIM(FileNam) + ZeroBin
C Z-ADD O_CREAT oflag
C ADD O_RDWR oflag
C ADD O_CODEPAGE oflag
C EVAL FileDescr=open(FileNamP:oflag:omode:cp)
*******************************************************************
* Read thru the DB2/400 part file. Convert partkey from integer to
* character. Change the leading zeros to blanks and then trim
* the blanks. Put the part name (part) in upper case.
* Write the record to the stream file.
*****************************************************************
*
c read pt 7099
c dow *in99=*off
c move p_partkey string
c eval i=1
c dow %subst(string:i:1)='0'
c and i<7
c eval %subst(string:i:1)=' '
c eval i=i+1
c enddo
c eval pb_partkey=%trim(string)
c lo:up xlate p_part pb_part
c eval buf=ptrec
C EVAL RC=write(FileDescr: BufP: 35)
c read pt 7099
c enddo
*******************************************************************
* Read through the DB/2 400 trans table. Convert integer, decimal
c eval buf=trrec
C EVAL RC=write(FileTrnD: BufP: 84)
c seton lr
*****************************************************************
* END MAIN
*****************************************************************
IBM may have patents or pending patent applications covering subject matter
in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to the IBM
Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood,
NY 10594 USA.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact IBM
Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The information about non-IBM
("vendor") products in this manual has been supplied by the vendor and IBM
assumes no responsibility for its accuracy or completeness. The use of this
information or the implementation of any of these techniques is a customer
responsibility and depends on the customer's ability to evaluate and integrate
them into the customer's operational environment. While each item may have
been reviewed by IBM for accuracy in a specific situation, there is no
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of
these Web sites.
The following document contains examples of data and reports used in daily
business operations. To illustrate them as completely as possible, the
examples contain the names of individuals, companies, brands, and
products. All of these names are fictitious and any similarity to the names and
addresses used by an actual business enterprise is entirely coincidental.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes
available to each customer according to the normal IBM PTF distribution
process.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other
countries.
SET and the SET logo are trademarks owned by SET Secure Electronic
Transaction LLC.
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
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
This section explains how both customers and IBM employees can find out about ITSO redbooks,
redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
• Redbooks Web Site http://www.redbooks.ibm.com/
Search for, view, download, or order hardcopy/CD-ROM redbooks from the redbooks Web site. Also
read redpieces and download additional materials (code samples or diskette/CD-ROM images) from
this redbooks site.
Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a few
chapters will be published this way. The intent is to get the information out much quicker than the
formal publishing process allows.
• E-mail Orders
Send orders by e-mail including information from the redbooks fax order form to:
e-mail address
In United States usib6fpl@ibmmail.com
Outside North America Contact information is in the “How to Order” section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl/
• Telephone Orders
United States (toll free) 1-800-879-2755
Canada (toll free) 1-800-IBM-4YOU
Outside North America Country coordinator phone number is in the “How to Order”
section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl/
• Fax Orders
United States (toll free) 1-800-445-9269
Canada 1-403-267-4455
Outside North America Fax phone number is in the “How to Order” section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl/
This information was current at the time of publication, but is continually subject to change. The latest
information may be found at the redbooks Web site.
Company
Address
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
access plan. Plan generated by the OS/400 two types of data: key figures and
Query Optimizer of how to access the data in characteristics.
the tables being queried. InfoObject. Generic term for characteristics and
Business Explorer. SAP BW reporting tool. key figures.
S
Save and Delete Receivers (SAVDLTRCV) com-
mand 24
Save R/3 System (SAVR3SYS) command 23
SE11 80
SQL
analyze SQL functions 75
explain SQL function 75
SQL Utility (SQLUTIL) 38
trace 74
ST03 47, 60, 81
ST05 47, 74
Stop Save and Delete Receivers (SAVDLTRCVE)
command 24
Submit Job (SBMJOB) 25
Symmetric Multiprocessing (SMP) 50
system value
Parallel Processing Degree (QQRYDEGREE)
51, 54, 57
Performance Adjustment (QPFRADJ) 14
T
tuning techniques 47
W
Work with Journal Attributes (WRKJRNA) command
25
Work with Shared Pools (WRKSHRPOOL) com-
mand 15
Work with System Status (WRKSYSSTS) command
15
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this
questionnaire and return it using one of the following methods:
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Fax this form to: USA International Access Code + 1 914 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Was this redbook published in time for your needs? Yes___ No___