S/4 Hana and SAP Adaptive Server Enterprise

Companies that have been using homogeneous databases from vendors such as Oracle or IBM for their SAP systems up to now face double licensing and maintenance costs for their databases when they introduce Hana or SAP Business Suite 4 Hana (S/4 Hana): on the one hand for Hana, and on the other hand for those of the other vendors.

The license for ASE is already included in the Hana Runtime Edition for Applications and SAP BW (REAB) - an alternative database for the remaining legacy systems is delivered free of charge, so to speak. This database is particularly valued in the financial sector due to its stability and has been in use for decades in some cases.

In addition, SAP's roadmap is clear for it - in contrast to MaxDB, for example - and it has very good compression, which leads to a comparatively low space requirement. A switch is therefore an obvious choice. But when migrating to ASE, there are a few stumbling blocks to be aware of.

Pros and cons migration to ASE

As our experience from over 100 migrations and the operation of more than 70 customer systems shows, the costs of migrating to ASE are usually amortized quite quickly due to the permanently lower licensing and maintenance costs.

In addition, SAP's licensing model does not place any obstacles in the way of virtualizing the database. Further advantages are the purchase of application and database from a single source as well as significant advantages in terms of space requirements, for example, compared to MaxDB, which, unlike ASE, does not support data compression.

In addition, no time-consuming reorganizations are necessary as with Oracle. The embedded administration is done via the common DBA Cockpit, with which most administrators are familiar.

This is usually countered by mandatory investments in the IT infrastructure, since ASE requires significantly more CPU resources on the hardware side. As practice shows, in some cases several hundred percent more computing power is required.

In addition, the database cannot empty its log during the full backup, so special attention must be paid to the design of the backup.

Overall, however, the advantages of ASE outweigh the disadvantages for most companies - especially with regard to permanent total costs.

Conception: Experience is in demand

Due to the specific hardware requirements, despite the well-documented migration instructions, it is important to involve experienced specialists in the early stages of planning and to adhere strictly to the recommendations published by SAP - for example, when dimensioning the caches.

Special attention should also be paid to the design of the backup concept. For snapshot-based backups, this should ideally be based on "prepare database mode".

It is preferable to "quiesce mode", since the latter only puts the database into read-only mode. To enable point-in-time recovery, care must be taken in the design to ensure that logs can be recovered independently.

Since the database cannot empty its logs during a full backup, the backup runtime is a critical factor: as long as the backup is running, the changes are written to the logs.

If the backup takes too long, the logs will overflow. It is therefore advisable to make backups at times of low load and to adequately dimension the log area. Additionally, fill level controlled log backups can be set up.

The monitoring parameters should also be strictly adapted to the SAP-specific requirements. If these requirements are met, ASE enables very fast and, from experience, problem-free backups.

Administration sticking points

Administrators familiar with SAP can manage and monitor ASE via the familiar DBA Cockpit. Typical for the database, however, are very frequent changes in the SAP notes regarding the individual parameters.

It should be emphasized that about 95 percent of the ASE parameters can be changed online. This even applies to the memory to be used (max_memory) and the CPU resources (syb_default_pool). This feature makes it possible - especially in interaction with virtualization - to dynamically adapt the resources to the growing demand.

As is also known from virtualization, a restart is required for the reduction of resources - however, this can usually be placed in a scheduled maintenance window.

The frequency of patches is also comparatively high with ASE, which on the one hand means a certain amount of effort when applying them, but also means that bug fixes are usually quite fast and new features are available quickly.

In the event that the SAP systems or the DBA Cockpit fail, the usual administration tools for ASE are also missing. Then the database can only be managed purely via iSQL.

This can present difficulties, especially for smaller IT departments without employees with the appropriate iSQL skills.

Conclusion

All in all, ASE provides companies with a database that - not least because of the favorable licensing situation in combination with S/4 Hana - is a sensible alternative to the parallel operation of Hana and third-party databases.

If a few steps are followed (see box), experience shows that nothing stands in the way of migration to ASE. It is irrelevant whether the operation is taken over by the company itself or by a service provider.

ASE Migration: Classic Procedure

• License consulting and ROI calculation
• Architecture consulting: infrastructure and determination of release dependencies
• If required: Release upgrade to at least SAP Netwea- ver 7.0 (EHP 2), SAP ECC (EHP 5), SAP CRM (EHP 1) and SAP SRM (EHP 1) respectively.
• Technical migration
• In case of in-house operation: Training of administrators - especially if no iSQL knowledge is available