SAP Hana - the patch monster

If you look at the patch cycles of the market-relevant databases and consequently the Hana competition, an interesting picture emerges on a monthly basis. The manufacturers of other databases also make mistakes ("withdrawn releases"), so that the planned release cycles cannot be adhered to as planned.

SAP cannot be assumed to be planned, but the past confirms the number of withdrawn releases. No other of these DBs has such a high clock rate.

Optimistically, one can say, "Hana development is progressing rapidly." However, most observers and users conclude that there have been too many errors in the past that cannot be attributed to new functions.

According to SAP, only bugs are fixed in the so-called maintenance revisions and no new features are activated. If the number of such maintenance versions increases, the poor quality of the software becomes apparent.

This is particularly evident with SPS12. This has also been confirmed by some customers and the SAP representatives have understood and accepted this point of criticism. Since the last revisions (clearly from 122.09), the errors have decreased enormously.

In the graphic, which was created from more than 400 of the official SAP notes, you can clearly see how many errors are contained in a Hana revision and, much more dramatically, that for around 35 percent of them no workaround is available or offered!

Depending on the weighting of the bug, it is then necessary to switch to the next higher revision. Many customers complain about precisely this behavior, as they run from one bug to the next. This means an enormous internal administration and testing effort.

The time aspect is a huge problem, especially for the larger companies, which normally only go live with one or two releases a year. Here, however, one must differentiate between planned (new features, performance improvements, end of support or dependencies on the SAP release) and unplanned maintenance (stability problems, incorrect results, consistency problems, faulty functionalities).

On average, it takes between at least three and usually six weeks to run all regression, backup, recovery and cluster tests for a new database version, without any preparation and tuning effort.

However, when the next Hana revision is released after just four to five weeks, it is impossible to get out of this test spiral. SAP now provides a new function via "Capture and Replay" (as of SPS12) that minimizes and optimizes the testing effort.

You no longer need explicit test/key users to test the new release functionally and with only a low load, but you can map 1:1 the workload from the productive system on a test system.

30 minutes for the release change?

In the Hana environment, SAP often advertises a maintenance effort of only 30 minutes for a release upgrade. However, they fail to mention that this is only a purely technical procedure.

This does not include the necessary and sufficient preparatory work, tests, consistency checks or even the checking of dependencies, because these take up by far the most time.

To check the latter, SAP unfortunately does not provide customers with a reasonable toolset. This means that for each release change, several hundred references must be checked to see whether the function is in use and whether this applies to the database version that will be used in the future.

There is no search, filtering or categorization of the Hana SAP notes at this stage. In the end, it complicates the administrator's work and thus prolongs the testing effort for possible workarounds and bugs that may yet be included in the new targeted version.

The SAP employees present were unable to provide an answer as to whether such a tool would be delivered by SAP in the future. This point of criticism was also taken up, but could not be fully clarified until now.

QPCM has developed a possible solution with the iHAL (intelligent Hana Assurance List) independently of SAP, so that the days of searching, checking and weighting Hana notes do not mean so much effort.

By entering the source and target release, the administrator can use iHAL to determine and then weigh how many bugs are associated with which feature and, based on the weighting, evaluate whether it makes sense to deploy a workaround or better wait for one of the upcoming revisions.

This Hana check tool will be available on www.qpcm.de in the future. (In case of interest or detailed evaluation contact via mail with jens.gleichmann@qpcm.de).

Not every bug leads to an update

The majority of the Hana errors published by SAP are of a serious nature, which may very well affect the stability of the Hana database as well as the consistency of the data. This means that every update should be carefully considered and checked before the update is technically applied.

The graphic provides an overview of the distribution of the categories and the associated number of Hana bugs. The key statement of SAP's impulse contribution is important: "Not every bug must necessarily lead to an update!"

You should therefore weigh up whether the affected feature and its impact endanger the operation, stability and integrity of the overall system. Only with this knowledge can you answer the question "When is the right time for an update/upgrade" with a clear conscience.

But as of today, it is precisely this transparency that is missing for customers and users. Under these circumstances, the question that almost all IT managers and administrators discuss inevitably arises: Is Hana already "mission critical ready"?

Due to these very short release cycles as well as the associated high effort and the amount of nevertheless still open bugs compared to other databases, the Hana database deserves the title "The Patch Monster", which is already known among many customers.

The event was very constructive for both manufacturers and customers, and SAP openly addressed the criticism. The software giant from Walldorf has already reacted to this in recent weeks and significantly stabilized the Hana revisions.

This event laid the foundation for the DSAG working group "Hana in Operations" at the end of June, which was requested by many customers.