The Day after Hana Going Live

For many, the switch to Hana and S/4 is an enormous change, because not only the database changes, but also the underlying operating system. The previous operation and thus the operations manual must be fundamentally revised.

This is where a topic begins that many people often neglect in their projects, since many administrators also lack a practical connection to the new environment, which means that some pitfalls are only uncovered during implementation.

In most cases, concepts do not yet exist for the work packages system provisioning under Linux, system copies with Hana, monitoring, the transport system for Hana objects, authorizations, cyclical maintenance or for the verification and validation of new Hana revisions.

Especially the maintenance effort should not be underestimated, because many components have interdependencies that did not have to be considered before.

In addition to the well-known restrictions regarding storage, servers and operating systems, there are also other limitations. As a result, many teams (server, operating system, databases, SAP Basis) have to coordinate even more than before.

To produce as few downtimes as possible, it is advisable to synchronize the maintenance cycles of the components. Suse has already integrated this very successfully in the "Suse Linux Enterprise Server for SAP Applications" with the extended support for the product.

Here, for example, the maintenance end of Hana 2 SPS01 was coupled with SLES for SAP 12 SP1. Next, SLES for SAP 12 SP2 will run out of maintenance in April 2019 and Hana 2 SPS02.

During such maintenance, the question of technical verification and functional validation always arises. Most key users have hardly any capacity for testing in addition to project work and normal operations. This is where the "Capture & Replay" feature, which is free of charge - i.e. already priced into the Hana license - comes into play.

With this you can replay the workload, which was generated by SQL statements, 1:1 on another system. So if your productive ERP system has 2000 users, you can replay all transactions within a defined time. The only requirements are a backup of the productive system and a record of such a time period.

This backup is imported to another system, for example the quality assurance system (QAS). Here you can then map several iterations of changes (patch of Hana/Linux, parameter changes) and compare the results with each run, for example, whether the queries were faster or slower or whether there was even an error.

With this procedure you can relieve the key users and even perform a load test with productive data including 2000 users or more. The system does not have to be "disposed of" at the end, but can be brought back into the landscape as QAS with the rework of the system copy. It therefore makes a lot of sense to link such maintenance work to the existing planning of the system copies.

What can "Capture & Replay" not do? It is not possible to test an SAP kernel swap or release upgrade.

Conclusion

Due to the complexity and dependencies of the Hana system components, it is precisely this that cries out for partial automation of the tests. Due to the increasing requirements, decreasing number of maintenance windows and the crisp release cycles, an optimization of the maintenance process is more than just desired.

Combine this with near zero downtime maintenance (Hana System Replication + DBSL Suspend) and a rolling kernel switch (RKS), and you could also perform maintenance during the week with almost no impact on the end user.