Skip to Content
Author's profile photo Denys van Kempen
Denys van Kempen
May 15, 2017 5 minute read

SAP HANA 2.0 SPS 01 What’s New: High Availability – by the SAP HANA Academy

Introduction

In the upcoming weeks, we will be posting new videos to the SAP HANA Academy to show new features and functionality introduced with SAP HANA 2.0 Support Package Stack (SPS) 01.

The topic of this blog is high availability.

For the previous version of this blog, see SAP HANA 2.0 SPS 00 What’s New: High Availability – by the SAP HANA Academy

For the full SAP HANA 2.0 SPS 01 blog list, see: What’s New with SAP HANA 2.0 SPS 01 – by the SAP HANA Academy

 

Tutorial Video

 

What’s New?

New System Replication Operation Mode: Active/active (read-enabled)

Active/active (read-enabled) system replication (logreplay_readaccess operation mode) was introduced with SAP HANA 2.0 SPS 00 and I already discussed the feature in my blog SAP HANA 2.0 SPS 00 What’s New: High Availability – by the SAP HANA Academy.

However, as the two new high availability features for the SPS 01 release do not bring a lot of material to the table, I will take the opportunity to discuss the new operation mode in more detail. For the two new HA features, a new system parameter and a new system replication API hook, see below.

Technically, logreplay_readaccess is very similar to the logreplay operation mode as both use continuous log shipping and redo log replay on the secondary system. In other words, if you have implemented system replication using either the command line utility hdbnsutil, the SAP HANA studio, or the new SAP HANA cockpit, configuring for logreplay_readaccess is no different. There is no new skillset required.

The big difference, however, is that logreplay_readaccess allows for active client connections.

Big deal?

Yes.

Previously, SAP HANA system replication required two identical systems to be up and running with only one system actively used. Double the $$ for hardware and licenses (SUSE Linux Enterprise Server & SAP HANA). Pay 2 get 1.

In return, as part of the deal, you get no data loss and near-zero downtime for both planned and unplanned events, for both regular maintenance and for unexpected incidents to full-blown disasters. The tough questions to answer were: how much is your data worth? Can you afford to loose some of it? How long can you be offline in times of trouble?

The good news is that with the new logreplay_readaccess operation mode, also known as active/active (read-enabled), the stage for these questions has changed. Of course, the investment is still there but this time the return is much bigger (ROI). With a read-enabled secondary site, you can offload a lot of the heavy-duty, number-crunching, analytical OLAP-type queries from the primary production site. As a result, performance is improved on both sides. The primary site can handle more transactions (throughput) and the secondary site can return faster results (response times). Not only is your system highly available and setup for disaster recovery (HA/DR), but also can it deliver increased performance.

As a reminder, system replication occurs in real-time. Transactions only commit on tier 1 if tier 2 has at least acknowledged the reception of the log buffer (replication mode = synchronous in-memory) or has persisted the buffer to the redo log on disk/storage (synchronous). So, whether you query the primary site or the secondary, you get the same result. It is the same system. The operation mode logreplay_readaccess is not supported in replication mode asynchronous (nor would that be sensible).

 

 

The small print? It does not happen automagically. There is no mechanism, at least not yet, that detects a long-running, resource-hungry, read-only OLAP query to dispatch it to the secondary site. You need to either establish a direct connection to the secondary database (supported by all client APIs: ODBC, JDBC, etc.) or include a HINT in the SELECT statement to point to the secondary system.

SELECT C1, C2 FROM T1 WHERE C3 = '<constant value>' 
WITH HINT(RESULT_LAG('hana_sr'))

 

 

See Connecting Using Active/Active (Read Enabled) and Hint-Based Statement Routing for Active/Active (Read Enabled).

 

New System Replication System Parameter

When system replication is enabled for the first time, initialisation may take a while. Basically, the time it takes to copy the production database over the network to the secondary site. Of course, there are ways to speed up this process by restoring a system snapshot or backup to the secondary site but you may still have a considerable amount of data that needs to be copied.

To decrease the time required for this phase, SAP HANA 2.0 SPS 01 introduces the new system replication system parameter: datashipping_parallel_channels.

With this parameter you can define the number of network channels to be used for datashipping, both full and delta. With more channels available, more data can be transferred faster over the network. This assumes that there is enough data to be pushed in the first place (think GB’s), that the primary server can deliver the data fast enough, and that the network still have enough bandwidth to accommodate more data transfers.

 

New System Replication HA/DR Provider

To enable the automation of additional tasks during the host auto-failover and system replication takeover process, SAP HANA system replication includes a Python-based API for the nameserver process. For example, to first stop the development system on the secondary site just before takeover. We refer to these as “hooks” or, more elegantly, HA/DR providers.

New in SAP HANA 2.0 SPS 01 is the srServiceStateChanged() provider. This hook enables you to  monitor state changes of the SAP HANA service.

There is a sample HADR provider Python script file included with in path /usr/sap/<SID>/HDB##/exe/python_support/hdb_ha_dr/HADRDummy.py

    def srServiceStateChanged(self, parameters, **kwargs):
        self.tracer.debug("enter srServiceStateChanged hook; %s" 
        % locals())

        # Access to parameters dictionary
        hostname = parameters['hostname']
        service = parameters['service_name']
        port = parameters['service_port']
        status = parameters['service_status']
        timestamp = parameters['timestamp']

        self.tracer.info("leave srServiceStateChanged hook")
        return 0

 

Playlist

On the SAP HANA Academy, there is a full playlist covering all aspects of system replication:

 

Documentation

For more information see:

SAP Help Portal

 

SAP Notes

 

White Paper

 

SAP HANA Blogs

 

Thank you for watching

The SAP HANA Academy provides free online video tutorials for the developers, consultants, partners and customers of SAP HANA.

Topics range from practical how-to instructions on administration, data loading and modeling, and integration with other SAP solutions, to more conceptual projects to help build out new solutions using mobile applications or predictive analysis.

For the full library, see SAP HANA Academy Library – by the SAP HANA Academy.

For the full list of blogs, see Blog Posts – by the SAP HANA Academy.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      How is the (read) load distribution between both HANAs done, if neither dedicated connections to the secondary HANA nor hints within the SQL-statements are used? e.g. round robin or per CPU load.

      I would like to have DB connections only to the primary HANA (to avoid development effort in the applications) but using the compute power of both.

      Author's profile photo Denys van Kempen
      Denys van Kempen
      Blog Post Author

      Hi Daniel,

      There is no load-balancing mechanism. The (configuration of the) application controles which read statements are executed where.

      Regards,

      Denys / SAP HANA Academy

      Subscribe to our YouTube Channel
      Join us on LinkedIn
      Follow us on Twitter
      Github code samples
      FacebookGoogle+