REALIZING EXCEPTIONAL DATABASE RELIABILITY WITH SAP HANA®

Database reliability is essential to help your company meet customers’ needs and remain digitally connected to your business network. That’s why the SAP HANA database offers the built-in high availability and disaster recovery features needed to support enterprise readiness in a cost-effective way.

As a result, the database is designed to preserve data and prevents business disruption from unpredictable events. It also helps you gain greater ROI without slowing down core business processes.

With the database reliability features of SAP HANA, you can:

• Enhance the resiliency of your business-critical systems.
• Use hardware reserved for failover to support operational reporting capacity and advanced analytics, enabling innovative new insights.
• Support new memory capacity that shrinks recovery times.
• Transparently route analytic workloads from the SAP Fiori® user experience in SAP S/4HANA® to secondary systems. The use of implicit database connections can redirect read-intensive workloads to secondary systems. This will help improving business efficiency and performance with the SAP HANA active/active read-enabled option.
• Support global operations efficiently using a “follow-the-sun” approach that switches primary and secondary systems to streamline workflow across time zones in a SAP HANA system replication topology.

 

BACKING UP AND RECOVERING DATA WITH SAP HANA

The fundamental concept of database reliability is to beable to back up and recover data to prevent it from being lost in case of system downtime (see the sidebar for a discussion of key backup and recovery concepts). SAP HANA uses in-memory technology to enhance data availability, but it also fully persists any transaction that changes the data – such as row insertions, deletions, and updates – so it can resume operations after a power outage  without loss of data.

SAP HANA persists two types of data to storage: transaction redo logs and data changes in the form of savepoints. Figure 1 shows the savepoints,  which are saved to local storage, and the additional backups, which are saved to backup storage. Local recovery from a crash uses the latest savepoint and then replays the last logs to recover the database without any data loss.

Figure 1: Local Persistence and Backups

 

Also, this solution supports three backup options: full backups, delta backups, and log backups. Recovery is executed in this order:
1. Database loads from the last full data backup
2. Data changed since the last full backup (differential backup) or data changed since the last data backup (incremental backup)
3. Log backups of transactions, in which changes are applied
4. Log entries of all transactions kept in the online log volume of SAP HANA, applied until the latest committed status before power loss

 

It also offers resumable recoveries to shorten the time required for a failed recovery attempt. This feature reuses milestones during recovery execution as a safety measure.

You can configure an SAP HANA client with information about multiple hosts, including the standby host, so that it continues to function even in the event of a failover. If a connection is lost once a host is no longer available, the client reconnects to one of the hosts in the list. SAP HANA will issue a connection error only if none of the hosts are available.

 

MITIGATING THE RISK OF SYSTEM FAILURE WITH HIGH AVAILABILITY

To protect your database from any single point of failure, you need to deploy multiple levels of redundancy.  In essence, the following HA features help you avoid outages:

• Hardware redundancy to avoid component failure – such as redundant and hot-swappable power supply units, fans, and network interface cards.
• Network redundancy to avoid network failure – This features duplicate network equipment and connectivity to avoid network failures. Routers can be configured with the Hot Standby Router Protocol for automatic failover.
• Power redundancy to avoid power failure – This includes uninterrupted power supplies, backup power generators, redundant cooling systems, and multisourced providers of network connectivity and electricity.
• HA hardware cluster to protect against hardware failure – This offers redundant hardware in a clustered system.

 

Basically in an HA configuration, an active secondary system can replace the primary system when system failure is detected. This approach must consider integration issues, such as how to handle connections from database clients configured to reach the primary system when you need to divert those connections to the secondary system after a takeover.

After a system takeover, SAP HANA uses IP redirection and domain name system (DNS) redirection to remap virtual IP addresses. When possible, IP redirection is preferred because it offers lower latency.

Figure 2: IP Redirection

Particularly for end-to-end client reconnection support, IP redirection uniformly and simply handles the complete recovery of both SQL and HTTP clients – with short recovery times and without special client-side configuration.

The principle of IP redirection is to define an additional “logical” host name with its separate logical IP address  10.68.104.51. It then maps this address to the media access control address of the original host in the primary system by binding it to one of the host’s interfaces.