Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Participant
SAP HANA System Replication is a reliable high availability and disaster recovery solution that provides continuous synchronization of a HANA database to a secondary location either in the same data center or remote site.

System Replication is a standard SAP HANA feature. In this method, all data is replicated to the secondary site and data is pre-loaded into memory on the secondary site which helps to reduce the recovery time objective (RTO) significantly. So in case of a failover, the secondary site will be able to take over without even performing a HANA DB (re)start and will work as primary DB straightaway.

Once the system replication is configured properly, each HANA internal process (nameserver, indexserver etc) connects to its counterpart on the secondary site, and all logged changes in the primary location are replicated to secondary site continuously through persisted redo logs. While system replication is running, the secondary site is on standby mode with data already pre-loaded into memory, and ready to take over. Please note that, in this scenario secondary site does not accept any requests or make any changes on DB.

Figure 1: SAP HANA System Replication Overview

Network requirements

Network requirements are usually overlooked when it comes to System Replication but it is very important to have a good network and bandwidth in place, especially for remote disaster recovery site. Because the data is continuously replicated to the secondary site, network bandwidth and latency should be sufficient to fulfil requirements. To estimate the network requirements, you need to know the size of data and log that are generated during your daily workload so you can make an informed decision.

You can use HANA_Replication_SystemReplication_Status.sql attached to SAP Note 1969700 - SQL Statement Collection for SAP HANA. On the primary system, simply choose System Information tab and right-click in the “Name” column and choose Import SQL Statements, choose attached to that note, and you will get complete set of useful SQL statements.

Figure 2: Bandwidth script for System Replication

Running this script by default will give you default the results based on snapshot time:

Figure 3: Default bandwidth results based on Snapshot time

In the SQL statement, change the TIME_AGGREGATE_BY value so that the results are displayed per 'DAY'; so just replace TS900 with DAY as you can see below:

Figure 4: Updating the bandwidth script

And execute the script with newly updated DAY value:

Figure 5: Bandwidth results per day

As you see above, you will have details in terms of data and log size, log percentage and bandwidths. Note that this is not an actively used system so the values would be quite different than an active HANA system.

Now, you know your SAP HANA bandwidth and can determine your network requirements especially for remote site with system replication in place.

What if I need to reduce network bandwidth?

There are two methods basically; first you can compress the data (as of SPS09) before sending and secondly use continuous logreplay feature (as of SPS11) to reduce the network bandwidth requirements.

For data and log compression, you just need to set “enable_data_compression” and “enable_log_compression” parameters true in global.ini, note the default value for these parameters is false:

Figure 6: Data compression parameters to reduce bandwidth

Continuous logreplay was introduced with SPS11 and it is another useful feature helps to reduce the bandwidth requirements. With this operation mode, the delta data shipping (which was available before) is not required anymore – only the initial full data shipping is performed and the continuous shipping of redo log continues afterwards. The amount of data that needs to be transferred to the secondary site is reduced dramatically (because no delta data shipping is required anymore). There is much less traffic on the network between the participating sites when running in operation mode logreplay.

Figure 7: Operation mode logreplay: Initial full data and redo log shipped to secondary.

System Replication is a comprehensive subject and I have decided to separate it to several articles each focused on specific areas. I am planning to cover system replication modes, operation modes, failover decision making process, key benefits and trade-offs, configuration steps, fine tuning HANA parameters for system replication and finally a summary for available options.

For a proper system replication solution, it would be better to ensure all the requirements are met, and that's why today I started mainly with network requirements. This will take some time but hopefully I will be able to help you to make better informed decisions for your SAP HANA high availability and disaster recovery solutions.

Have any questions about SAP HANA System Replication? Leave a comment below.

References and further reading:

How To Perform System Replication for SAP HANA

Automate your SAP HANA System Replication Failover (SUSE)

SAP Note 2165547 - FAQ: SAP HANA Database Backup & Recovery in an SAP HANA System Replication Landsc...

SAP Note 1999880 - FAQ: SAP HANA System Replication

SAP Note 1969700 - SQL Statement Collection for SAP HANA

Network Required for SAP HANA System Replication

If you liked this post, you might like these relevant posts:

SAP HANA High Availability and Disaster Recovery Series #1

SAP HANA HA and DR Series #2: Redundancy and Fault Recovery Support

SAP HANA HA and DR Series #3: Host Auto-Failover

SAP HANA HA and DR Series #4: Storage Replication

Choosing the right HANA Database Architecture

Feel free to share.

Labels in this area