Sizing SAP BW
As with any traditional data warehouse project, deploying a large-scale data warehouse solution is a complex and iterative process. However, when it comes to SAP BW sizing, you must size the networking resource needed among SAP BW, SAP R/3, and the end user. You must also account for the additional hardware resources needed to implement multi-tiered architecture and the impact of SAP R/3 for SAP BW data extracts.
The Sizing Process
Because SAP BW is a new environment and very few customers use SAP BW as a global data warehouse in production to date, sizing information is hard to find from SAP BW customers and hardware vendors. SAP, however, provides basic sizing guidelines to its customers for SAP BW configurations. As with the SAP R/3 OLTP sizing benchmark, SAP has developed a benchmark for SAP BW 1.2B based on a typical sales and distribution data warehouse. Thus far, only IBM has published official results. On February 15, 2000, at the SAP BW Congress in San Francisco, California, IBM announced the first official benchmark for SAP BW for DB2 conducted at IBM Competency Center in Walldorf, Germany. The full benchmark report is available at IBM's Web site at http://www4.ibm.com/software/data/db2/benchmarks/013100.html. SAP BW benchmarks are under way at Compaq, Hewlett-Packard, and Sun. Visit their Web sites for SAP BW benchmarks on their platforms.
SAP BW Benchmark
The SAP BW performance benchmark is a standard software-testing module from SAP. Functioning as a data generator, user simulator, and test platform, this module generated a sample Sales and Distribution (SD) database representing the order-processing activity of a large-scale business with the following profile:
-
50,000 products
-
10,000 customers
-
5 divisions
-
5 distribution channels
-
40,000 orders per day (almost 15,000,000 orders per year)
In this environment, it is assumed that approximately 70 percent of the products are sold by 20 percent of the distribution channels and that 80 percent of the products are sold to 20 percent of the customers. The average order return rate is 2 percent.
The SAP BW benchmark kit consists of a data generator, a query simulator, an InfoCube, InfoSources, and an InfoPackage group to load all generated references and transaction data into SAP BW. Figure 16-12 shows the SAP BW benchmark configuration.
Figure 16-12: SAP BW Benchmark Environment.
The data generator generates a series of order data files to load data in SAP BW. The size of the file is based on the memory of the SAP BW Database Server, such as 2 GB or 4 GB. Each file represents one month of activity over a two-year span and totals approximately 800 MB (approximately 2,400,000 rows) in size. For benchmarking testing purposes, two full years of transaction data (12 files) needs to be uploaded into SAP BW totaling approximately 20 GB (or approximately 29,000,000 rows in the fact table).
This benchmark comprises three key measurements: load phase, realignment run, and user queries. Data is loaded in ODS, then ODS to InfoCube, and Expected query response time. Visit IBM's or SAP's Web sites at http://www-4.ibm.com/software/data/db2/benchmarks/013100.html and http://www.sap.com/bw, respectively, for details about the IBM SAP BW benchmark.
Sizing SAP BW Components
The following factors are key in sizing an SAP BW system and determining the expected processor, memory, and storage requirements. To estimate hardware size, you should know the approximate database size, the average number of concurrent users, and the overall query mix. Note that how you configure these components and distribute the data across shared storage provides the basis for ensuring optimal system performance.
System Landscape and Migration Path
SAP recommends the following three-phase rollout strategy that includes pilot/development, test, and production systems, known collectively as the SAP BW system landscape:
-
Pilot/Development System. This system is used to pilot and develop new components and add-on tools as well as perform ongoing customization for SAP BW. Only developers will have access to both the development and test systems.
-
Test System. The test system is where performance and verification tests are run against new software prior to rollout onto the production system. This system may also be used to test the behavior of new versions of base components, such as operating system and device driver updates.
-
Production System. The production system is the live SAP BW implementation that contains the operational business data to which users have access.
-
SAP R/3 OLTP system. The typical SAP R/3 OLTP system landscape consists of three system environments, as listed above-pilot/development, test, and production. However, in the SAP BW system landscape, you also need to include dedicated SAP R/3 OLTP instances at each stage of the SAP BW path to production cycle. I recommend a small SAP R/3 OLTP instance for a development environment, but make sure that your TEST SAP R/3 OLTP instance reflects the current production SAP R/3 OLTP instance. Here you want to make sure that all SAP BW objects (Queries, InfoCubes, Aggregates, ODS) can scale to meet end-user requirements.
The actual system landscape and migration path you choose to follow depends heavily on the needs of your business as well as the overall size and complexity of your SAP BW implementation. The information provided here highlights the areas to consider in sizing your pilot SAP BW environment.
Database Size
Estimating database size involves calculating the size of incoming data sources and how that maps into individual data objects in SAP BW. These data objects are ODS, InfoCubes, IDOCs, and the SAP BW BASIC environment.
Moreover, you need to size additional storage requirements in the sourcing SAP R/3 OLTP instances to process and manage data for SAP BW.
The disk storage requirements for an SAP BW system depend heavily on the design of the InfoCube as well as the overall distribution of data. According to the guidelines published by SAP, the amount of disk storage required is based on the following factors:
-
Number and size of InfoCubes
-
Number and size of ODS tables
-
Volume of data to be loaded
-
Amount of master data
-
Number of aggregates
-
Indexes
Projecting the total amount of storage required involves the following:
-
Calculate the total size (in GB) of all InfoCubes. Note that, in general, InfoCubes should not exceed 100 GB. SAP has published detailed instructions for estimating the size of an InfoCube in SAP BW Sizing and Performance ASAP Accelerator. Exact size of an InfoCube is very hard to calculate; however, the SAP BW Sizing and Performance ASAP Accelerator defines a simplified calculation for estimating the disk space required for an InfoCube as follows:
-
f = (nd + 3) x 4 bytes + (22 bytes x nk) = required disk space in bytes
-
add
-
InfoCube = f x (nd x 0.30 + 2) x nr x np
-
where
-
Suppose you have an InfoCube with four dimensions, two key figures, and you load 10,000 records every day. The estimated InfoCube disk space utilization after one month, 30 days, will be:
| Disk space | = [(4 + 3) x 4 + (22 x 2)] x [( 4 x 0.30 + 2 ) ] x 10000 x 30 |
| = 69120000 bytes or 69.12 MB |
-
Add 5 GB for BW software (including the SAP BW Administrator Workbench). Add 150 percent for temporary table space and storage.
-
The final total represents the total amount of storage projected for BW. Note that if you are using a RAID 1 or 0+1 disk array, you should double this estimate.
| Note | At the time of this writing, all SAP BW ASAP methodology papers, guidelines, or sizing information is very much focused on the SAP BW 1.2B environment limited to InfoCubes. With ODS implementation in SAP BW 2.0 and new master data architecture, as well as BDS integration, the size of the SAP BW database and the database/application server characteristics will require additional resources. SAP is in the process of updating the sizing and other methodology papers and hopes they will be available at the time of SAP BW 2.0B GA. |
Processors
The number of processors in an SAP BW server system directly relates to the time it takes to load data. By default, the SAP BW data load process is a serial process (with worker threads) that executes on a single processor. To optimize load times and reduce latency, each process must be partitioned into a series of sub-processes and distributed across as many processors as are available. Therefore, the more available processors you have, the greater number of parallel sub-processes, resulting in faster data load time.
SAP recommends a minimum of two processors per system, regardless of the hardware platform. However, for the most efficient load balancing, SAP suggests a minimum of two to four processors for each SAP database and application server.
Memory
Most analytical applications are resource intense and consume high system resources such as memory and CPU cycles. The more data you can load in memory, the faster the query response will be. Note in Table 16-1 that both SAP BW database and application servers require more memory than SAP R/3 OLTP instances.
| Server Type | Memory |
|---|---|
| Application | 300 MB + 10 MB/Concurrent User |
| Database | 500 MB + 2 MB/Concurrent User |
| Central Instance (one server with both Database and Application servers) | 2048 MB |
Disk I/O Subsystem
Due to large data volumes during data load and query time, the mass storage I/O subsystem plays a major role in all data warehouse operations. Due to insufficient bandwidth of I/O subsystems, you may find that the I/O subsystem is the most common roadblock to efficient performance. In contrast to the SAP R/3 OLTP system, it is impossible to tweak memory configurations adequately to avoid accessing the mass storage entirely. As a result, tuning efforts are largely focused on making disk I/O bandwidth as large as possible.
Large bandwidth is achieved by spreading the database across a large number of array controllers and SCSI buses. Therefore, it is important to estimate the number of controllers required. The number of I/O controllers is derived from the estimated bandwidth required by the workload (typically, 10 MB/s for each CPU). For example, a system with eight CPUs should have enough I/O controllers to support 80 MB/s bandwidth.
Network Configuration
SAP BW software is based on the standard R/3 kernel, and, as a result, similar network requirements apply. However, due to frequent large data set movements between SAP R/3 OLTP and SAP BW instances, you must make sure that the SAP R/3 OLTP instances and SAP BW instances share high-speed network links, usually 100 MB.
Client Workstation
SAP recommends that an SAP BW client workstation for running the SAPGUI (BEX Explorer) be any Intel-based 350 MHz PC with a minimum of either 64 MB (for Windows NT 4.0, Windows 2000, or Windows 98 systems) or 48 MB (for Windows 95 systems). However, based on experience, at least 128 MB memory on client workstations with fast graphic adapter cards will provide you with reasonable performance.
| Note | After you make an initial estimate, SAP recommends that you verify the estimate by loading a small amount of data and analyzing the actual amount of storage used. Also, disk space should be checked frequently because usage changes over time. |
Team-Fly |
EAN: 2147483647
Pages: 174