Innovating and Maintaining SAP HANA with SPS and Revisions

John Appleby

Posted by John Appleby on December 12, 2013

Global Head Of DDM/HANA COEs

More by this author

Every two weeks, there is a new minor revision of SAP HANA, and every 6 months there is a new major revision (Service Pack). In addition, SAP HANA SP7 brings Maintenance Revisions, and I’m going to talk about these in this blog.

Critics of HANA say that this is because HANA is buggy and unstable and so it is necessary to patch every fortnight. In fact, the bi-weekly revisions of HANA are a deliberate strategy called Vishal Sikka.

“Fundamental delivery of value, without compromises”

– There is only one code-line for HANA, not lots of hot-fix patches. This means there is only one product to test.

– You can upgrade from any revision to any newer revision, making maintenance very straightforward

– Innovations are dropped in revisions in a non-disruptive way

– Bug fixes and performance improvements come regularly

– Every bug every found is included into continuous regression testing

How do we approach patching during the project lifecycle?

This is simple – always patch to the latest HANA Revision. I always wait 1-2 days in case there was a serious issue with a revision, but then I always upgrade to the latest Revision that is available, when a development lifecycle is in place. This always provides the most stable, performant environment with the best features.

How does this change for a productive system?

During the test cycles of a project, I lock down the HANA Revision to a revision that I’m happy with. At this point, we only then patch the environment if there is a critical error. Otherwise, we leave the revision static until the next development cycle, when we promote the latest revision once more.

What do SAP HANA SP7 Maintenance Revisions bring?

The last revision of SAP HANA SP6 was Revision 69. After this, if you want to upgrade to fix a critical error, in the past, you had to upgrade to SAP HANA SP7 Revision 70. Whilst this is the principle of Timeless Software, there are times when you may not want all the innovations in SAP HANA Rev.70. You might just want that one thing fixed.

And for this reason, SAP HANA Rev.69.1 has now been released. During the lifecycle of SAP HANA SP7, there will be Maintenance Revisions of SAP HANA SP6 Rev.69, with critical and security fixes only, and no innovation. This allows customers who want to minimize change and regression testing but receive critical fixes.

The below diagram is roughly the timeline that will take pace for SAP HANA SP06, SP07 and SP08. The numbers may not be exactly matching how it turns out, and there may not always be a maintenance revision matching a SP7 revision, but you get the idea.

Revision 69
Revision 69.1 Revision 70
Revision 69.2 Revision 71
Revision 69.3 Revision 72
Revision 69.4 Revision 73
Revision 69.5 Revision 74
Revision 69.6 Revision 75
Revision 69.7 Revision 76
Revision 69.8 Revision 77
Revision 69.8 Revision 78
Revision 69.9 Revision 79
End of Life Revision 79.1 Revision 80

Note that it appears it is not possible to upgrade from Revision 69.1 to Revision 70, but only to Revision 71. If you choose to take the Maintenance Release, you must always wait for a newer version of SP7 to be released, should you wish to upgrade to the latest Support Package.

Final Words

The SAP HANA Revision strategy, in my opinion, provides a simple, easy to understand and flexible patching strategy which customers can use to their advantage, however they want it. Unlike databases I’ve worked with in the past, there are no individual patches, parameters that need setting and upgrading is a 5 minute, straightforward process with very low risk.

I hope this helps you define your patch and update strategy for HANA. Appreciate any feedback.

VN:F [1.9.22_1171]
Average User Rating
Rating: 4.5/5 (2 votes cast)
Innovating and Maintaining SAP HANA with SPS and Revisions, 4.5 out of 5 based on 2 ratings