SIZING

AND

PERFORMANCE

Sizing
ASAP FOR BW ACCELERATOR
SAP BUSINESS INFORMATION WAREHOUSE

How to size hardware of a BW system

Version 2.0 June 2000

2000 SAP AG

SIZING

AND

PERFORMANCE

Table of Contents
ASAP for BW Accelerator............................................................................................................................1

1 INTRODUCTION..................................................................................................1 2 SIZING..................................................................................................................1
2.1 R/3 System.................................................................................................................................................1 2.2 Remarks.....................................................................................................................................................2 2.2.1 Main Memory Considerations.............................................................................................................2 2.2.2 Front-end PC Requirements................................................................................................................3 2.2.3 Disk Space Requirements....................................................................................................................3 2.3 Network traffic..........................................................................................................................................7 2.3.1 Transfer Rates from R/3 OLTP to BW...............................................................................................7 2.3.2 Line Capacity Considerations.............................................................................................................7

3 MORE INFORMATION........................................................................................8

2000 SAP AG

SIZING

AND

PERFORMANCE

1 Introduction
This document describes how to estimate hardware resources that are necessary to run a particular workload on a BW System, providing guidelines for the definition of hardware requirements like main memory, disk space and CPU. Generally, it is much more difficult to estimate the sizing requirements of a BW system than an R/3 system. The reason is that user behavior is more difficult to project than with the R/3 system, as BW provides great flexibility in order to meet the varied reporting needs of an organization. With this in mind, the goal of this document is to present general guidelines that can help in determining hardware requirements for a BW system. It is always encouraged to work directly with hardware vendors to receive further assistance in sizing a BW system. Software Version Supported This document was written for BW version 2.0B, but it should apply to all versions of BW.

2 Sizing
Necessary resources for achieving a particular throughput and response times depend on several factors such as e.g. database, operating system, number of users, amount of online/background operations, load profile. The recommendations provided in this document, regarding estimation of hardware requirements of BW systems, are assumptions based on empirical data gathered from existing installations. The values always refer to a minimum configuration and should be increased in cases of doubt.

2.1

R/3 System

When connecting a BW system to an R/3 system it has only a minor net impact on the hardware sizing of the R/3 system. The reason for this is that the presence of a BW system alleviates much of the load that reporting typically places on the R/3 system. On the other hand data extraction can require significant R/3 system resources. Categories of sizes have been developed for the hardware sizing for a BW System. They correspond to T-shirt sizes.

1999 SAP AG

SIZING

AND

PERFORMANCE

BW Category (T-Shirt size)

Configuration DB + App-server on one server DB + App-server on one Server DB -, App-server on one or several servers dependant on the hardware configuration DB- + App-server on several servers dependent on the hardware configuration One DB instance, multiple Appservers

Hardware >= 1 GB of RAM, >=2CPUs, DB 30 50GB >= 1.5 GB of RAM, 2 4 CPUs DB 50 100GB >= 2 GB of RAM, 2 4 CPUs for DB- and Appserver DB 100 200 GB

No. of concurrent users 1 10 10 20 20 50

XS S M

>=2 GB of RAM, DB instance >=6 CPUs, App-server >=2CPUs, >= 2 GB of RAM DB 200 1000 GB

50 100

XL

>=4 GB of RAM, DB instance >=8 CPUs, App-server >=2CPUs, >= 2 GB of RAM >1000 GB

> 100

2.2
2.2.1

Remarks
Main Memory Considerations

The number of users working in the system forms the basis for estimating the main memory and processor requirements of the database and application servers. Different definitions of user are available: Concurrent users Logged-on users Active users Named users.

The recommendations below refer to concurrent users The term concurrent users refers to several users actively working on the system at the same time and thus competing for resources. As a general rule, 8 logged on medium users corresponds to one concurrent user, and 4 logged on high users corresponds to one concurrent user.The user categories are defined as follows: Low user: accesses the BW System from time to time, is typically a user seeking information occasionally Medium user: accesses the BW System regularly and continuously, is typically a user seeking information using predefined reports High user: works intensively with the BW System, the power user who runs ad hoc queries. 1999 SAP AG 2

SIZING

AND

PERFORMANCE

As a general rule, significant memory should be allocated to BW application servers as this memory is important in supporting user loads. 2.2.2 Front-end PC Requirements

The following assumptions for main memory apply: Approximately 100 lines per report SAPGUI 4.6D and BW front-end software (Business Explorer Analyzer) installed When using the Business Explorer Analyzer, data traffic to the users front-end PC is 3-5 times higher than when using the standard SAPGUI 4.6D

Under these conditions, a good rule of thumb for front-end PC requirements is a minimum of 128 MB. The front-end response time is heavily influenced by the processors speed, however, adequate RAM may be the most important factor in assuring adequate response time on the front-end. A BW front-end PC should be at least a Pentium 300 MHz with a graphics card with at least 2 MB memory. A smaller configuration can be used but leads to a higher response time. The front-end PC requirements for web reporting are significantly less but there are no official recommendations, yet. 2.2.3 Disk Space Requirements

Disk space requirements depend heavily on the design of InfoCubes and data distribution. The following hints on estimating disk space do not account for possibly sparse tables or compression the database might use. There is a sizing tool available for InfoCubes and master data tables that helps you perform what is described below. 2.2.3.1 Disk Space

The Business Information Warehouse software including the development workbench requires approximately 7 gigabytes of disk space. The required disk space for data depends on: Number of InfoCubes Number of key figures and dimensions per InfoCube Volume of data loaded Number of aggregates Amount of master data Number and size of flat files used for data load, residing on application servers The number and size of PSA and ODS tables Indexes Estimating an InfoCube

2.2.3.2

When estimating the size of an InfoCube one must consider the potential size of fact table and dimension tables. However, the size of the fact table is the most important, since in most cases it will be 80-90% of the total storage requirement for the InfoCube. When estimating the fact table size consider the effect of compression depending on how many records with identical dimension keys will be loaded. The amount of data stored in the PSA and ODS has a significant impact on the disk space required. If data is stored in the PSA beyond a simply temporary basis, it is possible that more than 50% of total disk space will be allocated for this purpose. 2.2.3.2.1 Dimension Tables 1999 SAP AG 3

SIZING

AND

PERFORMANCE

Identify all dimension tables for this InfoCube. The size and number of records need to be estimated for a dimension table record. The size of one record can be calculated by summing the number of characteristics in the dimension table at 4 bytes each. Also, add four bytes for the key of the dimension table. Estimate the number of records in the dimension table. Adjust the expected number of records in the dimension table by expected growth. Multiply the adjusted record count by the expected size of the dimension table record to obtain the estimated size of the dimension table. Assume that the dimension table indexes will take up as much space as the dimension table itself.

2.2.3.2.2 Fact Tables Count the number of key figures the table will contain, assuming a quantity key figure requires 8 bytes, a currency key figure requires 9 bytes, and other numeric fields require 4 bytes. Every dimension table requires a foreign key in the fact table, so add 4 bytes for each key. Dont the three standard dimensions. Estimate the number of records in the fact table. Adjust the expected number of records in the fact table by expected growth. Multiply the adjusted record count by the expected size of the fact table record to obtain the estimated size of the fact table. Assume that the fact table indexes will take up as much space as the fact table itself. This is more index space than is usually required in most OLTP systems. In the fact table, many of the columns will be foreign keys with pointers to dimension tables. Each of them will have an index. Add an additional 150% for temporary table space and aggregate tables. An aggregate contains both new dimension and data tables. A rule of thumb is that all the aggregates will be the size of the fact table. Master DataTables

2.2.3.3

Master data can also require considerable disk space. Perform the following steps to estimate the size of each master table: For each field in the master data table, add the estimated field size. Use the following assumptions for each field:
Column Type Currency Quantity Numeric Character Length 4 4 4 Domain length

Sum the length of each column in the table to calculate the expected size of a record in the master table. Estimate the number of records in the table. Adjust the expected number of records in the table by expected growth. Multiply the adjusted record count times the expected size of the table record to obtain the estimated size of the table.

1999 SAP AG

SIZING

AND

PERFORMANCE

Assume that the indexes will take as much space as the fact table itself. Add an additional 50% for temporary table space and other contingencies. PSA tables

2.2.3.4

The record length of a PSA table can be estimated by adding the domain lengths of all the fields of the respective InfoSource. Add 45 bytes for request-id and other fields being added by the system. Multiplying the record length by the number of records being held in the PSA table will give you an estimate on disk space needed per PSA table. Data in PSA might be deleted regularly depending on your scenario (e.g. use ODS for permanent storage). Estimate the number of records accordingly. 2.2.3.5 ODS tables

The record length of an ODS table for new and active data can be estimated by adding the domain lengths of all characteristics of the ODS objects plus the space needed for key figures (see 2.2.3.2.2). (After activation of data the table for new data is empty, so the space needed for new data can in most cases be neglected.) For the change log table add 45 bytes for request-id and other fields being added by the system. Multiplying the record length by the number of records being held in the ODS table will give you an estimate on disk space needed per ODS table. The number of records of the change log table depends on the average number of updates and the delta type used for the ODS object. Up to three records are stored in the change log for every update of one record in the active data (Before and/or After and/or Reverse Image or Additive Delta). 2.2.3.6 Limitations

There are no limits to the number of InfoObjects, number of InfoCubes, or the number of reports per InfoCube. The system administrator can create 13 dimension tables in addition to the dimensions for time, Packet ID, and measure of unit for each InfoCube. Number of characteristics in all dimension tables: Each of the dimension tables can have 248 InfoObjects, computed by 255 6 (no access to these fields) 1 (Dimension ID) to obtain 248. For performance reasons we recommend a maximum of 16 InfoObjects per dimension. Number of key figures (facts): A fact table can have up to 233 key figures, computed by 255 6 (no access to these fields) 16 (dimensions) to obtain 233. These numbers are given by the DBMS and cannot be influenced by the BW System. 2.2.3.7 Re-Estimation

After making an estimate, you should verify it by loading a small amount of data, such as a few thousand records and then analyzing the space used to confirm the original estimate. You should also analyze the input sources to determine the number of records from each source system. If RAID (Redundant Array of Inexpensive Disks) is utilized, adjust the overall estimate accordingly. For example, when using RAID 1 (disk mirroring), you should double your estimate. RAID 5 is generally recommended for BW data, as it results in improved read performance for queries.

1999 SAP AG

SIZING

AND

PERFORMANCE

Estimates on disk space should be checked frequently. Data Warehouse requirements can change over time and can be dramatically changed by apparently minor modifications. Therefore, the impact on data storage requirements should be considered for every change. Also, reviews need to be performed periodically, such as every three to six months, in order to ensure that current growth estimates are correct. 2.2.3.8 Simplified estimation of disk space

A simplified estimation of disk space for the fact table can be obtained by using the following formula: (n + 3) x 4 bytes + (22 bytes x m) n m = number of dimensions = number of key figures

1999 SAP AG

SIZING

AND

PERFORMANCE

Number of key figures Number of dimensions 1 2 3 4 5 6 7 8 9 10 11 12 13 5 126 bytes 130 134 138 142 146 150 154 158 162 166 170 174 + 30% per dimension + 100% for aggregates + 100% for indexes and to multiply * no. of records per period * no. of periods 10 236 240 244 248 252 256 260 264 268 272 276 280 284 15 346 350 354 358 362 366 370 374 378 382 386 390 394 20 456 460 464 468 472 476 480 484 488 492 496 500 504 25 566 570 574 578 582 586 590 594 598 602 606 610 614 30 676 680 684 688 692 696 700 704 708 712 716 720 724 50 1116 1120 1124 1128 1132 1136 1140 1144 1148 1152 1156 1160 1164 100 2216 2220 2224 2228 2232 2236 2240 2244 2248 2252 2256 2260 2264

To the obtained results you have to add

2.3 Network traffic

When connecting an R/3 OLTP system to a BW System, a minimum transfer rate of 10 megabits per second is recommended if weekly updates into BW are planned. When dealing with several transfers per day, it is recommended that the transfer rate should me more than 10 megabits per second. However, the appropriate transfer rate depends on volume and frequency of loading processes. Whenever possible, the BW system and the OLTP system it extracts data from should reside on the same subnet. Best results for extraction/load are usually observed when Fast Ethernet or FDDI connections are used. 2.3.2 Line Capacity Considerations

The presentation server response time is depending on the network capacity. A BW presentation server produces significantly more network traffic than an R/3 GUI (about 10-20 times as much). 1999 SAP AG 7

SIZING

AND

PERFORMANCE

The connection of the presentation front-end to the application server can be established using a local area network (LAN) or a wide area network (WAN). All the different network types such as Ethernet, token ring, FDDI and ATM can be used. We do not recommend using dial-up lines with a capacity less than 28,800 bits per second. The connection of the database server to the application server should be established by using a local area network. Ethernet or FDDI are recommended as network types.

3 More information
This document describes sizing considerations for a BW system. There are many general guidelines provided, and often only minimum recommendations are given. BW sizing information is continually evolving and will likely change in the future. Please check the SAPnet front-end (OSS) notes regularly for detailed and up to date information. It should be noted that network requirements for BW are currently being studied and the results will be published in SAPnet front-end notes. There is one collective note 184905, Collective Note Performance 2.0 containing links to all notes on BW sizing and performance issues.

1999 SAP AG