While progressively forming its SAP HANA strategy, SAP continues to deliver new technical features and capabilities for the in-memory computing platform. This article contains a brief introduction to the latest innovations in SAP HANA support package stack 10 (SPS10).
SAP HANA follows a six-month innovation cycle: The latest SAP HANA support package stack, which has been on the market for a couple of months now, contains some important new features.
1. Support for the IBM Power Platform
In the past, SAP HANA only ran on Intel CPUs, that is, processors from Intel. Now, for the first time, it runs on the IBM Power Systems processors as well. By adding support for a second major database server platform, SAP is not only addressing a key group of customers that run their servers on IBM processors, but it is also helping IBM Power platform customers make the decision to opt for SAP HANA.
“These are loyal, committed customers,” explains Ralf Czekalla, an SAP HANA product management expert. “That’s why it was important for us to activate this platform.”
The initial step will be to make SAP Business Warehouse (SAP BW) available on the IBM Power platform. Other products and scenarios will be released in subsequent months. The aim, says Czekalla, is to achieve feature-equivalence in terms of SAP HANA between the IBM platform and the Intel platform, which has been supported for longer.
2. Enhancements in Workload Management
It is now possible to create workload profiles to give preference to certain types of processes over others. Thus, in an SAP Business Suite system, transactional processes can have higher priority than analytical processes. In ERP and other transactional systems particularly, it is vital that transaction response times are not slowed down by OLAP queries running concurrently. The appropriate priorities can now be configured in the system.
3. Enhancements for Multitenant Database Container Systems
SAP HANA no longer only supports a single logical database in a database system ‒ but multiple isolated databases too. Along with a slew of other benefits, this makes it possible to split administrative tasks more efficiently between the system level and the database level. SAP HANA SPS09 already supported file-based backup and recovery.
In SAP HANA SPS10, the Backint for SAP HANA interface has been added, allowing SAP HANA to be connected to third-party backup tools. Further improvements have also been made in cross-database access between multitenant database containers. This will benefit customers who want to run two applications in the same database system. In a multitenant database container SAP HANA system, multiple applications can run on separate tenant databases.
4. Improvements in Data Backup
SAP HANA now supports both incremental and differential backup. This means that it is no longer always necessary to perform a full backup of data that changes infrequently. In the past, there was no option but to back up the entire data set. “Not including free areas, of course,” adds Czekalla.
5. SAP HANA Dynamic Tiering
In dynamic tiering, the customer introduces a disk-based data store into an SAP HANA system so that lower-priority data no longer has to be stored and processed in memory. Differentiating between data of higher and lower priority in this way allows a much larger volume of data to be stored in the SAP HANA system than before. Higher-priority (“hot”) data resides and is processed in memory; lower-priority (“warm”) resides on disks – resulting in longer latency times and lower performance. As a component of SAP HANA, dynamic tiering gives customers greater flexibility in their use of hardware.
In SAP HANA, all processes are optimized such that all the relevant data is processed entirely in the main memory. A disk-based database uses different strategies, such as caching, to achieve acceptable performance levels with a comparatively small main memory. In dynamic tiering, selected sections of the data set are moved to the hard disk, where conventional disk-based algorithms are used. This eliminates the need to pull warm data into the SAP HANA main memory for processing. Another benefit of dynamic tiering is that it uses the same columnar storage paradigm as in-memory technology.
A key driver of dynamic tiering is cost, because it is much cheaper to store data on the hard disk than in the main memory.
“On an in-memory platform, hardware investments are strongly coupled to data growth; in a disk-based system, that correlation is much less evident,” explains SAP HANA specialist Richard Bremer. “SAP HANA dynamic tiering delivers the best of both worlds by combining the benefits of both in-memory platforms and disk-based systems.”
6. Mission-Critical Functions
With SAP’s cluster failover solution, SAP HANA system replication, the entire system ‒ including hardware and software ‒ is replicated in separate installations, typically in the same and/or in different data centers in chains of up to three tiers or data centers (see graphic). If the primary system fails, the secondary or shadow system takes over.
SAP HANA system replication was introduced in SAP HANA SPS05 almost three years ago and has been enhanced in each subsequent support package stack. The most significant improvement in SAP HANA SPS09 and SPS10 are optimized takeover times. One of the mechanisms used to achieve these is to move key initialization processes to the background when a takeover is executed to allow significantly higher database availability.
One customer reported a reduction in its takeover times from 15 down to two minutes. Of course, takeover times are influenced by many different factors and are highly case-specific.
“On average, though, it’s realistically possible to cut the takeover time by 50 percent – provided that the customer has applied the improvements in SAP HANA SPS09 and SPS10,” says SAP HANA expert Czekalla. “It really is important for customers to reduce their takeover times, not just with a view to dealing effectively with disaster recovery, but also for achieving (near-) zero downtime upgrades.”
In this case, all the components, including the database software, are upgraded on the shadow system in preparation. This makes it possible to apply SAP HANA revisions from the same or from other support package stacks.
So, when an application or business operations switch from an active to a shadow system, that system is up to date. “It’s a very practical approach,” says Czekalla, and one that is made possible by the option in SAP HANA System Replication to support the replication of different ‒ including newer ‒ versions of running data streams. The takeover process can even be optimized or disguised for the ABAP application.
The technology behind all this is the “connectivity suspend” feature that has been available in several recent SAP HANA support package stacks, but whose impact has not always been fully recognized. Ideally, users don’t even notice that hardware and software versions have changed.
Preview: What’s Next?
Hot Standby for SAP HANA System Replication
Planned enhancements to SAP HANA System Replication include changing the process of updating data to the secondary system to enable takeover times of well under a minute. This will require almost no changes on the administrative side apart from entering a new “on/off switch” (parameter value) for this option.
As well as accelerating takeover, the plan is to further reduce the volume of data needing to be transferred between the coupled systems by a factor of between five and 10. This will be of significant value to many customers, particularly those whose data centers are located at long distances from each other and who operate in less developed regions, because the volume of data to be transferred (and, thus, the data throughput required) will be greatly reduced.
Active/Active Operation of SAP HANA System Replication
Following on from the previous step, future plans for SAP System Replication envisage allowing read access to the secondary system. The data in the applications running in the coupled SAP HANA instances will be replicated to the second data center so that the applications can send read queries to the second data center too.
However, change operations will continue to be executed on the data in the first data center only. Currently, the general trend is to return operational reporting to the actual SAP Business Suite application system after migration to SAP HANA and to fully realize the potential of SAP HANA in the original data.
The planned active/active option could automatically split transactional OLTP and analytical OLAP functions in a single logical instance between primary and secondary SAP HANA hardware that is coupled together through the Hot Standby for SAP HANA System Replication feature.
A Single Table for Warm and Hot Data
Currently, hot and warm data resides in separate tables; either in conventional SAP HANA in-memory tables or “extended tables” made possible by dynamic tiering. A table contains either “hot” or “warm” data ‒ not both. In the future, it will be possible to store hot and warm data in a single table. In addition, the data lifecycle manager (DLM) tool from the SAP HANA data warehousing foundation will help with pulling extended tables from SAP HANA in-memory tables, scheduling data movement, and creating structures in the database that enable read access to hot and warm data without additional effort.
To find out more about SAP HANA SPS10, watch the SAP Academy video:
Learn more about the technical innovations in SAP HANA SPS10 here.
Top image via Shutterstock.