(This insight has been co-authored by Cal Loudon and Nicholas Chang)
As we all know, SAP HANA is a cutting-edge technology that is continually evolving by way of incremental, non-disruptive innovation and improvements. When discussing system patching, customers often pose the question, “Why should I update my HANA revision to the latest Support Pack Stacks (SPS) when I don’t intend to make use of the new features and improvements?” It’s a great question, but there are many reasons to update outside of the new features packed into each SPS, so let’s explore those reasons and discuss why N-1 is not applicable to HANA.
The N-1 update strategy is where a system is patched to the second most recent level that SAP has released. This strategy is commonly utilised in SAP Software Component patching exercises of old and is still heavily used today. It is thought to be a risk averse tactic to avoid undiscovered bugs in latest versions, relying instead on the older version where any bugs should have been addressed. This is a mind-set we need to rid ourselves of.
Continuous improvement and optimisation on HANA behind the scenes
With each new SPS, SAP updates and optimises code within HANA in the background – the specific details of which are not made publicly available. While an updated ‘What’s New SAP HANA Platform Release Notes’ document and an overall release SAP Note (2298750 for SPS12) are put out with each SPS, they do not go into the granular elements of those changes which go on behind the scenes, but offer huge benefits to the HANA system.
To find out about these details, such as the improvements to heap memory optimisation, the delta merge algorithm, the execution plan and engine and many more; one needs to delve deep into one of the many SAP notes published with each revision. In an ideal world, SAP would compile and share the list of these types of improvements which would help convince clients and stakeholders alike that upgrading to the latest version comes with significant advantages. Until that day comes however, let’s take a look at some examples of these kind of improvements which have been made available with recent revisions:
- Since SAP HANA SPS 09 it’s been possible to configure primary keys and unique indexes as INVERTED HASH indexes. These have an underlying hash-based data representation which typically result in a significantly reduced (upwards of 30%) memory footprint (1999997 - FAQ: SAP HANA Memory).
- Row store indexes only exist in memory and are recreated during start-up, as of SAP HANA SPS 11 users can log onto the database before this recreation step is completed. Prior to this revision, users needed to wait until all indexes had been created. (2160391 - FAQ: SAP HANA Indexes).
- Also new with SPS 11 is the view cache. This allows for the results of SQL views, Calculation views and CDS views to be cached. This enables faster data retrieval and means we do not need to suffer the system costs associated with processes such as searching and aggregating data (2336344 - FAQ: SAP HANA View Cache).
- A raft of enhancements have been incorporated into the recent release of SPS 12 including the ability to execute optimised Hashed Disjunctive Joins (2000002 - FAQ: SAP HANA SQL Optimization), utilise calculation view hints (2142945 - FAQ: SAP HANA Hints) and identify IndexHandle waits with the hdbcons functionality (1999998 - FAQ: SAP HANA Lock Analysis). With these new developments we can augment system and query performance, optimise memory consumption and perform greater in-depth analysis over issues.
- In newer revisions, memory allocation of some ‘heap areas’ are also optimised and memory leakages have been addressed which reduces overall memory usage (1999997 - FAQ: SAP HANA Memory).
Better overall system stability and performance
With bug fixes and performance improvements, such as those mentioned above, being regularly released to the public with newer revisions, our systems subsequently receive better overall stability and performance. Likewise the chance of system crashes and performance degradation also dramatically reduces.
Difficult patching and lengthy downtimes a thing of the past
Patching HANA is a pretty straight forward process. Obviously, as with all manner of things it’s going to be far less error prone if you follow the instructions (Ikea says hi). There exists commands, graphic user interfaces and web interfaces to allow you to upgrade HANA via the method you feel most comfortable.
System downtimes are also significantly reduced when compared to SAP Software Component patching. To further shorten this downtime and minimise business impact, SAP also offers SAP HANA Zero Downtime maintenance capabilities for HANA revision updates. Plus, if you’re not looking to make use of any new application functionality, you can even skip business acceptance testing and only conduct technical regression tests.
If you’re within a project phase, I’d always recommend implementing the very latest SAP HANA SPS (and so would SAP) to make the most of the incremental, but non-disruptive, innovations made by SAP.
Within a Production environment operating in BAU, I’d endorse customers to upgrade to the HANA revision in line with the Datacentre Service Point (DSP) during an available maintenance window to utilise the latest and greatest performance optimisations and bug fixes. DSP version 122 for SAP HANA SPS 12 was only recently announced by SAP, so that’s what I’d recommend too.
So with that in mind, if you’ve been umming and ahhhing as to if now is the time to take the plunge and upgrade, I’d ask you the question: “Why wait?”