Data Volume Management on SAP HANA

Managing the size of the SAP environment is an important aspect of using the system in virtually every company. For administrators and developers, it generates maintenance and development challenges. Users are faced with the problem of an excessive response time of the system and excessive duration of subsequent operations. For the company’s executives, large volumes of data stored on disks and servers mean additional expenditure on the maintenance of the integrated system.

Managing the size of systems is important in each moment of their life cycle. An increasing volume of data and the growth of the database from tens to hundreds of gigabytes and values counted in terabytes always translate into rising costs. With a significant data growth, costs no longer increase linearly, but exponentially.

Disk arrays with the required performance, servers with sufficient computing power, backup systems that enable the system to be recovered within the time acceptable to the business are the requirements that entail specific amounts.

A differentiator – and at the same time the largest advantage of the SAP HANA platform – is the use of the benefits of the development of the technology that allows you to perform all operations in memory. Servers with 1 TB of memory or more were beyond imagination just a few years ago. They are available today (for SAP HANA, SAP recommends certified SAP HANA Appliance servers, with a capacity of over 1 TB), but their cost is still beyond the reach of many companies.

Time for cleaning

However, this does not mean that the companies in which the current size of the database generates the costs of infrastructure for HANA that exceed their budgets, should say goodbye to the idea of increasing the processing speed and performance of SAP systems offered by SAP HANA. This only means that it’s time for cleaning.

After a few years of running the business in the SAP system, its size is usually much bigger. Some of the older data are no longer used, some are used occasionally (the reason may be e.g. legal requirements related to the provision of data to such institutions as the Social Security Institution or tax authorities). There is also a high potential for downsizing in technical tables of the system.

The archiving mechanisms available in the SAP system and the deletion of unnecessary data allow you to recover significant disk space and to reduce the size of the database several times. The archived data are still available in the SAP system, however they do not burden the database on a daily basis, but are stored in external archives.

Archiving and then removing unnecessary technical data, along with their reorganization are the essence of Data Volume Management projects that BCC (now All for One Poland) carries out for its customers and recommends as the first step to all companies that are considering switching to the HANA platform. A DVM project should be complemented with a cyclic review of systems to maintain the sizing at a reasonable level and not to allow an uncontrolled growth of the database.

Be fit, verify costs

Storing only those data that are essential for the business will enable companies to use HANA at an acceptable cost level. Why? One of the reasons may be the data that are stored in columns in the database and that must be loaded entirely into memory in the case of the HANA database. As you can guess, the more data, the longer the time of loading and reading. Also, it takes longer, for example, to start a database and, as a result, a system.

Of course, new technological solutions meet these needs. For example, FusionIO cards, SSDs in certified SAP HANA Appliance servers or properly prepared disk arrays in SAP HANA Tailored Datacenter Integration (TDI) solutions allow you to quickly read multiple gigabytes of data. However, in each solution every single gigabyte generates costs.

The aforementioned column store tables include those that can take a lot of memory (e.g.> 500 GB), and as a result, it takes a long time to load them. Some are only needed in small part, while other will remain unused and unnecessary. Here, particular attention should be paid to the technical tables that may contain data that are not used in business operations and that can be archived or simply deleted.

Sizing reports, i.e. /SDF/HDB_SIZING (ZNEWHDB_SIZE), provided by SAP, are very helpful and even mandatory in the preparation for the migration of SAP systems to the HANA platform.

Sizing reports

A system 5 times smaller

Let’s use an example here. Above we present sections of results of a sizing report for the SAP ERP system where no archiving of IDOC messages has been carried out. The need to verify the messages varies greatly depending on the system, a type of the company’s operations and business, however there is a rule that IDOC messages should be archived regularly. This keeps the size of EDID4 and EDIDS tables within reasonable value ranges.

In the situation illustrated by sections of reports, redundant data have resulted in the anticipated memory requirement of approximately 1.4 TB. Of course, this value can be provided by both SAP HANA Appliance as well as by SAP HANA TDI. However, in this case, the necessary costs have no justification.

After organizing, analyzing and archiving messages carried out by BCC (now All for One Poland) as part of the DVM service, it turned out that a virtual machine in SAP HANA TDI with 256 GB of memory would be sufficient.

For a single system, we received the estimated usage of memory of 1428 GB (prior to the analysis and optimization) and only 266 GB (after the DVM project). The difference is more than 5-fold!

In this particular case, the SAP environment landscape was made up of three systems: development, test and production one. Thus, to simplify the calculation, a system that has not been covered by Data Volume Management, shows an infrastructure requirement that is more than 15 times larger than the requirement of the system that has undergone this process. The costs of purchasing and then maintaining the infrastructure are also correspondingly higher.

After performing DVM services, the system uses 5 times less memory

DVM – a necessary migration step

Not all systems can be so spectacularly downsized, but it is not an overstatement to say that all of them contain redundant things. The analysis of the data stored in column tables as well as archiving of redundant data are a must.

The experience of BCC (now All for One Poland) in migrations of SAP systems to new hardware platforms, including SAP HANA, and regular SAP maintenance and administration services that we provide to our customers confirm that the above example is not isolated.

Therefore, the analysis of the size of the SAP system database and performing the work in the field of Data Volume Management are the steps that we always recommend to our customers before migrating systems to SAP HANA, and even before planning the budget for such a project.

You should also be aware of the fact that possible consequences of ignoring the analysis and reorganization are not only excessive costs of the hardware and its maintenance. A significant prolongation of the time required to perform the migration process can even make it impossible to be completed within the time window acceptable by the business.

We all pay for redundant information: administrators in the daily struggle with performance and scalability of systems; developers – with a software code to minimize the number of data read; users – with additional check boxes so as not to pick up e.g. this one searched invoice from the ocean of created invoices; and executives – with bills for the maintenance and management of the infrastructure. Keeping the sizes of system databases at reasonable (read: as low as possible) levels is in everyone’s interest.