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 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 SQLStatements.zip 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:
If you liked this post, you might like these relevant posts:
Feel free to share.