As a result of SAP Business Suite’s migration to SAP HANA,  solutions such as SAP ERP, SAP CRM, and SAP SCM are transferred into a completely new dimension of in-memory processing. The SAP HANA in-memory processing platform provided in proven transactional systems, such as SAP ERP, increases system performance multiple times.

SAP HANA eliminates the limitations of the relational database RDBMS by combining the features of a transactional database and an analytical one. The performance, which is increased multiple times and ensures acceleration of up to even a thousand times, allows for reports to be sent directly from the SAP transactional system, without harming transactions which are performed concurrently. SAP HANA in the SAP Business Suite systems enables real-time processing to be used where so far tasks have been carried out “in the background” for performance reasons.

Projects involving migration from the SAP Business Suite  to SAP HANA are still pioneering undertakings. During the migration of SAP solutions to the HANA platform BCC (now All for One Poland) uses its previous experience from similar projects of migration to various hardware and system platforms.

Before you begin

The HANA platform – although it has been present in the SAP offer for three years and is very promising – is just getting started in business. The solution is still being developed and the first migration projects are taking place under the supervision of SAP consultants. Their role is to provide recommendations and experiences regarding the approach to planning the work and versions of the tools to be used during the upgrade and migration of systems.

For the purposes of systems migration to HANA, SAP also provides a free-of-charge service that facilitates the identification of support areas and influence on the improvement of performance of the system which has already been installed on the HANA platform. The service is called the Business Scenario Recommendation for Suite on HANA and involves the analysis of an appropriately prepared statement of the use and performance of transactions executed in the customer’s system. A properly prepared report on the ST03N transaction is submitted to SAP specialists, who after analyzing the content provide information about the transactions and areas that will be improved after migration.

Due to these innovative solutions, we recommend a thorough analysis of the scope of the work and available documentation provided by the system manufacturer prior to starting a migration project. During an analysis of the scope of activities it is necessary to verify at the beginning:

  • versions of components used in the system,
  • differences in the functioning of systems for target versions of components,
  • technical tools used for upgrade and migration,
  • available technical and system documentation,
  • current system configuration and relevant reports on the system’s operation.

The entire undertaking is conducted in accordance with SAP standards (the Go Forward methodology by All for One Poland based on ASAP) and best practices developed by the Project Management Institute, which imposes high standards of conduct and ensures higher security and enhances the chances of the project being successful. This means, mainly, a thorough analysis of the scope of the identified tasks of the participants and people involved, project risks, the implementation time and plan, the budget and applicable quality requirements.

Migration to SAP HANA – the devil is not so scary

SAP HANA (High Performance Analytic Appliance) is a technology based on in-memory data processing. From a technical point of view, it is primarily a very fast database that, as a platform, is ideal for SAP ERP or BW systems.

The project of system migration to a HANA database is not a complicated project if we prepare properly for it. It can be divided into four stages:

  • preparation,
  • migration,
  • steps after migration,
  • optimization.

Preparation

The preparation process should begin with determining what hardware will be needed to migrate to the HANA database. The hardware for HANA is delivered by certified SAP partners, such as: Dell, Fujitsu, HP, IBM, Cisco, in the form of ready-to-use servers (SAP HANA Appliance) including installed HANA software.

The hardware sizing involves the determination of the amount of RAM needed for the HANA database. The other parameters (CPU, disks, etc.) are appropriately selected depending on the amount of memory held by the HANA platform, and do not need to be specified. Certified platforms are published on the SAP Web pages: http://service.sap.com/pam.

Depending on the type of migrated system (ERP or BW), we use the following reports prepared by SAP for hardware sizing:

  • BW: /SDF/HANA_BW_SIZING – a report available in the ST-PI component (upgrading the component to the latest version is recommended),
  • ERP: ZNEWHDB_SIZE – this report should be created in the system according to SAP Note 1872170.

If for ERP systems it is not possible to create the report ZNEWHDB_SIZE in the system, we can try to evaluate the required amount of RAM according to the following formula (SAP Note 1793345):

RAM = DB size (uncompressed, “well-maintained”) / 2 + 20%.

The resulting value should be further increased, taking into account the future expansion of databases.

You should also remember that:

  • the hardware for HANA is used only for databases – application servers are installed on separate servers (or virtual machines),
  • for development and test systems, SAP supports the use of virtualization (VMware) or running several databases on one HANA server,
  • for production systems, only physical hardware is used (virtualization is not supported by SAP),
  • BW systems can be scaled on many HANA servers,
  • at the moment there is no possibility of scaling the ERP system database on multiple HANA servers HANA – we must use the scaling within a single server (a relevant amount of RAM),
  • the HANA platform allows you to maintain high availability through the use of a standby server for both BW and ERP systems.

The next stepof preparationshould be to checkto see that our systemmeets therequirements of the HANA platform. In addition, it is also recommended to perform additional activities to better prepare for the migration:

  • dual-stack systems (ABAP+JAVA) – it is necessary to separate ABAP and JAVA:

– only ABAP systems migrate to the SAP HANA platform,

– JAVA is not supported on the SAP HANA platform,

  • Unicode – SAP HANA supports only Unicode systems; for non-Unicode systems, it is necessary convert to Unicode,
  • 64bit – only a 64-bit operating system
  • compatibility of additional components usedin the system – it is necessary to check to see that additional software components (add-ons) in useare compatible with EHP7 (note 1820906),
  • Going Live OS/DB Migration Check service – for production systems, it is necessary to inform SAP of the intention to migrate systems to a new platform, and to order asession in order to check the production system (1 session prior to migration, 2 after migration), after which we will receive a report with recommendations,
  • Maintenance Optimizer (Solution Manager) – the Solution Manager system with a working Maintenance Optimizer functionalityis necessary to generate a list of required components and configuration information (xml files) that we use when updating the system:

– at least Solution Manager 7.0 EHP1 SP 23,

– recommended Solution Manager 7.1 SP 05 or higher,

  • system archiving and cleaning – it is recommended to consider reducing the database by archiving or cleaning redundant data (note706478), because the size of the database translates into hardware resources required for HANA (RAM),
  • user programs (Z*, Y*) – migration to the SAP HANA platform may require the adjustment of your own code:

– adjustments resulting from a migration to Unicode,

– adjustments resulting from the use of the HANA functionality (may also be made after the migration).

Migration

The process ofthe SAP system database migration to the SAP HANA platformis not significantly different from the migration between other platforms (in SAP, this type of project is known as an OS/DB migration). Thus, in BCC we apply proven methodologies and tools that we have used successfully multiple times with many customers during the system migrations between different databases.

Simplifying somewhat, the migration process consists in the exportof a source database and the import of content thus obtained to a target database (in our case HANA).

As with other databases, when migrating to the HANA platform, we can also use solutions such as a parallel import and export using the TCP/IP connection. In some cases, this will allow us to shorten the time required for migration.

Migration of the SAP ABAP system to a new platform (OS/DB migration)

The migration process for most SAP systems will have to be performed in two stages:

  1. Updating the system to the version required by SA PHANA,
  2. Migration of the database to the HANA platform.

In the case of BW systems, we need to update the system to version 7.3 SP5 or higher; only then can the proper migration be started.

Migration of a SAP BW system to a HANA platform

In the case of ERP systems, we have to update the system to ERP 6.0 EHP 7 or EHP 6 for HANA, however we recommend using the latest available EHP (currently EHP7).

Migration of a SAP ERP system to a HANA platform

In the latest version of SUM 1.0  SP9, it is possible to perform an update and migration in a single step to a limited extent. This function is called DMO (Database Migration Option) and can be an interesting alternative for systems operating 24 hours a day to reduce system unavailability.

DMO (Database Migration Option) – migration and update in a single step

Steps after migration

Afterthe migration has been completed and the system has been launched on the HANA platform, it is necessary to customize the system itself and the related environment. Therefore, the following actions should be planned:

  • standard technical steps after the migration (as with other platforms),
  • technical integration steps – checking the communication with other systems,
  • integration of infrastructure – adjustment of backups, update of system information in Solution Manager, update of SLD, monitoring, etc.,
  • applicationtests–testingof the implementedbusiness processes – the very process ofmigration to the HANA platform does not introduce any changes to the business layerof the system, however the necessary update of the system (e.g. EHP7 installation) requirestesting,
  • Going Live OS/DB Migration Check Service – the second session of the system check after the migration – recommendations from the report should be implemented in the system.

Optimization

Exploiting the potential of SAP HANA depends largely on the way in which we process data. In the case of the HANA database the processing should be shifted towards the database. This means that we should perform as many operations as possible at the database level and reduce the processing in the application layer.

Data processing on a traditional platform and a platform with the HANA database

As soon as the system is already up and running on a new platform, it is time to begin its optimization. Although immediately after the migration many transactions and reports will run faster than on the previous platform, it is worth examiningin more detail what is happening in the system.

Here are two basic steps that we should follow to exploit the potential of the SAP HANA database:

  • To start the acceleration for selected transactions/reports – for some transactions, SAP prepared “special" modifications that can be incorporated in the SFW5 transaction similarly to the way in which business functionsare activated. Activation changes the method of executing aspecific transaction/report for possible use of the HANA database. Activation is reversible, i.e. you canturn it off if you find that you want to cancel the acceleration.
  • To optimize your own code so that it uses the quickin-memory processing, which means the need to adjust the way in which our programs process data:

– adjustment of SQL queries,

– adjustment of the data storage method – use of column tables,

– use of views,

– application of stored procedures.

In the process ofanalysis and optimization,the systemtools that have been available for a long time will be helpful. They include:

  • SAP Workload: Business Transaction Analysis – tr. STAD,
  • Performance Analysis – tr. ST05,
  • Code Inspector – tr. SCI,
  • DBA Cockpit – tr. DBACOCKPIT,
  • Workload monitor – tr. ST03N.

We can also use a new tool, ABAP SQL Monitor (transactions SQML, SQMA, SQMD), available in systems based on NetWeaver 7.4 SP3 or in the systems with the ST-PI component in the version 2008_1_700 SP8.

This tool allows you to collect information about database queries with in the whole system, even covering a long period of time, for example, a few weeks. Furthermore, it extends the capabilities of analysis of SQL queries provided by the transaction ST05 or DBACOCKPIT with the ability to easily link a query with a transaction or report from which it was called up, for example.

SAP HANA as a database for SAP ERP – experiences from the project

Our experience so far shows that HANA is a great alternative tot he classic database and has huge potential not only as a database. Recent experience gained during the migration project being implemented now for one of our customers shows that running the ERP system on the HANA platform delivers tangible performance benefits after migration, and further optimization can multiply them.

The table below presents a comparison of several sample financial transactions executed in a system with a “classic" database (before migration) and in a system with the HANA database (immediately after migration, without any optimization). Transactions were run with the same set of data and parameters. The results show a significant increase in performance, which is clearly visible to all system users.

Comparison of the duration of several sample financial transactions in a system with a “classic" database (before migration) and in a system with the HANA database (with no optimization)

It should also be noted that a significant increase in performance did not apply to all the transactions and programs. Some system operations run just as they did before the migration and they will require further optimization.

After the migration of one of the customer’s systems we wanted to see how much potentiallay in the SAP HANA platform. To this end, we made a simple database query that sums the values ​​of one of the columns of a table with over 90 million records:

SELECT SUM (WTGBTR) FROM COEP

  • execution time in a system with a classic database: 395,656 ms,
  • execution timein a system with the HANA database: 78 ms.

The performance increased around 5000 times!

The results that we received convinced us that in-memory processing and other mechanisms implemented in SAP HANA, such as column-based data storage, enable an achievement of acceleration that would be impossible or unimaginably expensive in a classicdisk-based database.