SAP BW/4HANA and BW on HANA

2.1 Sizing

In recent years, we have been involved in the sizing of many BW on HANA systems. By far the most common case is the migration of an existing BW system to SAP HANA, referred to as the brownfield approach. The greenfield approach, in which a new BW is considered only on an SAP HANA system is less frequent. The transfer of a non-SAP data warehouse (DWH) to a BW system is rare, and we therefore address this approach only very briefly.

It is important to make sure that you size the database server for SAP HANA correctly because many mistakes can be made at this point. To help you avoid this, Marc Bernard, Product Manager SAP EDW, has written a very good blog detailing the most common errors made when sizing a BW on HANA system.

2.1.1 Sizing when migrating an existing BW system

When migrating existing BW systems to SAP HANA, we strongly recommend that you use the ABAP sizing report for the database sizing. This report guarantees more accurate results and it is independent of the database compression. It can also incorporate the concept of non-active data, extended tables (for details on both topics, see Section 4.1), as well as future growth. SAP Note 2296290 and the attachments to that note describe in great detail how to run the report and what the functions of the individual parameters are.

The sizing report is called /SDF/HANA_BW_SIZING and is delivered from Service plug-in ST-PI 2008_1_7xx SP8 or ST-PI 740 SP01. The minimum prerequisite for the report is NetWeaver BW 7.0 SP1. For BW 3.5 systems, there is a separate report (SAP Note 2021372).

You can use different parameters for the report, which means that you have good control over the required resources and thus the load on the system. The report also saves you a lot of work by, for example, considering influences such as the conversion to unicode and any potential compression of the source database automatically. You can also run the report just for certain subareas of the system if you are planning to migrate only part of your system.

We recommend that you run the report and specify growth values based on your experience from previous years. This will give you a better overview of the hardware requirement for the coming years. Experience shows that the usual values for annual organic growth are between 10% and 30%. We also recommend that you activate consideration of non-active data.

With regard to the precision level, Low is sufficient to give meaningful results. It is only for small systems with databases of less than 500 GB that we recommend you set this level to High.

As already mentioned, SAP Note 2296290 contains very good documentation with an example. It gives a detailed description of all input parameters, how the tool works, and the results. Therefore, we will not provide any further explanations or an example at this point. We will restrict ourselves to typical questions or important information that we often receive despite using the detailed sizing report.

With regard to sizing, one aspect that is often forgotten is that every server has an operating system with a certain main memory requirement. 10% of the first 64 GB and 3% of the remaining main memory is reserved for the operating system. Furthermore, 50 GB must be reserved for services and caches for each server node. This results in the values shown in Table 2.1 for the different server sizes currently available. The sizing report takes these values into account fully automatically.

Table 2.1: Available main memory for different server sizes

Scale-out configurations for BW systems have at least three computer nodes. As a minimum, we strongly recommend two worker nodes for one master node. For more information about scale-out, see Section 2.4.2 on Scalability. Additional details about the sizing of the master node and the optimum number of scale-out nodes can be found in SAP Notes 1855041 and 1702409.

A useful side effect of the sizing report is that it provides information about the volume of data in certain objects. In the case of very large row stores, change logs, or PSA tables, you can quickly see whether a system is well-maintained. For more on the topic of housekeeping, see Section 2.2.7.

2.1.2 Sizing a new BW on HANA

When you are sizing a new system for BW on HANA, you should use the Quick Sizer (http://service.sap.com/quicksizer). There is a special version of the Quick Sizer for SAP HANA-based systems (http://service.sap.com/hanaqs). The tool will help you not only to determine the correct size for the database server but also the correct dimensions for the application server where necessary. SAP provides very good and detailed information and videos on this topic and therefore we will not provide any further explanations here.

Sizing a non-BW data warehouse for BW on HANA

Let us assume you have an existing data warehouse that is not based on BW technology. You want to convert this system into a BW on HANA. There are two options for the sizing:

1.   Quick Sizer (see the previous section)

2.   Manual sizing

2.1.3 System measurement

Figure 2.1: System measurement

Because there are now more than a thousand live BW systems on HANA, the number of requests for system measurement and information about how to perform such measurement is rising. In SAP HANA Studio, customers can generate a measurement report at any time. This report records the size of the maximum main memory used by the database in the last twelve months. The following PDF document on SAP Service Marketplace provides very good information on this topic for customers.