SAP HANA System Replication

1. What is SAP HANA system replication?

SAP HANA system replication provides the possibility to copy and continuously synchronize a SAP HANA database to a secondary location in the same or another data center. Usually system replication is used to support high availabilty and disaster recovery.
It must not be mixed up with the SAP HANA LT Replication Server (SLT) described in SAP Note2014562.

2. Where do I find further information related to SAP HANA system replication?

The how-to guide How to perform System Replication for SAP HANA contains a lot of information and references to further documents that can help to implement and use system replication.
SAP Note 2165547 provides further information about backup and recovery in SAP HANA system replication environments.

3. Which indications exist for problems with the SAP HANA system replication?

The following SAP HANA alerts indicate problems in the SAP HANA system replication area:

Alert Name SAP Note  Description
21 internal event 1977252 Identifies internal database events.
78 Connection between systems in system replication setup Identifies closed connections between the primary system and a secondary system. If connections are closed, the primary system is no longer being replicated.
79 Configuration consistency of systems in system replication setup Identifies configuration parameters that do not have the same value on the primary system and a secondary system. Most configuration parameters should have the same value on both systems because the secondary system has to take over in the event of a disaster.

SQL: “HANA_Configuration_MiniChecks” (SAP Notes 1969700, 1999993) returns a potentially critical issue (C = ‘X’) for one of the following individual checks:

Check ID Details
1810 Services with replication error
1811 Services with unknown replication state
1813 Replication connection closed (last day)
1815 Current log shipping delay (s)
1816 Filling level of async shipping buffer (%)
1820 Parameter deviations primary vs. secondary site
1830 Age of oldest replication snapshot (h)

4. Which modes of SAP HANA system replication are available?

The following SAP HANA system replication modes exist:

Mode Details  Behaviour when secondary system is not available
Synchronous Primary system waits until secondary system has received data and persisted it to disk. Primary system waits until

global.ini -> [system_replication] -> logshipping_timeout

is exceeded (default: 30 s) and then proceeds without replicating data.

Synchronous in-memory Primary system waits until secondary system has received data. Primary system waits until

global.ini -> [system_replication] -> logshipping_timeout

is exceeded (default: 30 s) and then proceeds without replicating data.

Synchronous full sync (SPS 08 and higher) Primary system waits until secondary system has received data and persisted it to disk. Primary system is blocked until secondary system becomes available.
Asynchronous Primary system doesn’t have to wait for secondary system. Primary system proceeds without replicating data.

5. Can SAP HANA system replication be used for system copies?

The normal reason for SAP HANA system replication is high availability and disaster recovery, but it can also be used for system copies. Once the initial synchronization has happened the replication side can be used as copy system by executing a takeover. It is much quicker to establish the system copy based on an existing replication than doing the same with traditional approaches like backup and restore. If the SAP HANA database has to be renamed for the system copy, the hdbrename tool can be used.
Be aware that the number of working hosts on the copied system needs to be identical to the original number of working hosts (standby hosts can vary).

6. How can I determine details related to SAP HANA system replication?

System replication information can be found in monitoring view M_SERVICE_REPLICATION.
The following SQL statements are available in SAP Note 1969700 in order to evaluate system replication related details:

SQL statement Details
SQL: “HANA_Replication_SystemReplication_Bandwidth” Calculates the used network bandwidth between primary and replication side
SQL: “HANA_Replication_SystemReplication_KeyFigures_Current_CommandGenerator” Can be used to show current key figures in terms of bandwidth and throughput, manual maintenance of reference values required
SQL: “HANA_Replication_SystemReplication_Overview” Provides a general overview of system replication information (configuration, activity details)
SQL: “HANA_Replication_SystemReplication_ParameterDeviations” Checks for SAP HANA parameters which deviate between primary and replication side
SQL: “HANA_Replication_SystemReplication_Status” System replication status of individual services

7. Is it possible to initialize a replicated system based on backup / restore?

Currently it is only possible to initialize the replication side based on an snapshot that is created via full data shipping from primary side. An initialization via backup and restore is not possible.

8. What are the basic requirements for the SAP HANA system replication network connection regarding throughput and latency?

For system replication it is important that the network throughput (or bandwidth) and the latency (or roundtrip time) are sufficient to fulfill the requirements. SAP Note 1100926 provides further details about these KPIs.
Further details are discussed in the whitepaper for Network Recommendations for SAP HANA System Replication available at Network Recommendations for SAP HANA System Replication.
As of SPS 09 you can compress data before sending it across the network (see “Is it possible to compress data before sending it to the secondary site?” below). This will reduce the network bandwidth requirements.
Due to the need of data transfer in addition to the log transfer the bandwidth requirements of SAP HANA can be higher than expected. SAP plans to provide the “Continuous Log Replay” feature in SPS 11 to reduce the bandwidth requirements.

9. Can problems with system replication impact the performance on the primary system?

In the following scenarios the performance of the primary system is impacted by system replication:

Scenario Replication mode Details
Connection to secondary system not working synchronous full sync Change operations and COMMITs on the primary system have to wait permanently until a connection to the secondary system is established again.
Connection to secondary system not working synchronous
synchronous in-memory
Change operations and COMMITs on the primary system have to wait until a connection to the secondary system is established again or the timeout configured with the following parameter is reached:

global.ini -> [system_replication] -> logshipping_timeout = <seconds>
Inadequate network connection in terms of latency and throughput synchronous
synchronous full sync
synchronous in-memory
Change operations and COMMITs are slowed down because the network communication is within the critical path and they can only proceed after the changes were successfully processed on secondary site.
Slow disk I/O while processing logs on secondary system synchronous
synchronous full sync
Change operations and COMMITs are slowed down because persisting the log information on secondary site is within the critical path.
Asynchronous log shipping buffer full asynchronous Per default change operations and COMMITs on the primary system wait until space in the asynchronous log shipping buffer is again available. If you don’t accept these waits, you can set the following parameter to ‘false’:

global.ini -> [system_replication] -> logshipping_async_wait_on_buffer_full = false

In this case SAP HANA will temporarily close the system replication to the secondary system and try to re-establish the connection after the time defined with the following parameter:

global.ini -> [system_replication] -> reconnect_time_interval = <seconds>

In order to reduce the risk of buffer full situations, you can adjust the size of the asynchronous log shipping buffer using the following parameter:

global.ini -> [system_replication] -> logshipping_async_buffer_size = <size_in_byte>

In case of issues you can use SQL: “HANA_Replication_SystemReplication_KeyFigures_Current_CommandGenerator” and double-check the key figures. AVG_SHIP_TIME_MS should typically not be higher than a few milli seconds and the SHIP_RATE_MB_PER_S should be significantly above 10 MB / s. If you see worse values, you have to check both the network and the secondary system and eliminate issues and bottlenecks.

10. Is it possible to take backups on the secondary side?

No, currently you can only take data and log backups on the primary side.
If automatic log backup is enabled, after takeover to the secondary side the log backups will automatically be written there.

 

12. In which situations does a SAP HANA system replication takeover make sense?

See SAP Note 2063657 that describes what aspects should be considered before performing a takeover. It is important to follow these steps, because otherwise a takeover can even make everything worse (e.g. data loss).

13. Can multiple SAP HANA databases be replicated to the same target?

It is not possible to replicate different source SAP HANA databases into the same target SAP HANA database.
You can replicate different source SAP HANA databases into different target SAP HANA databases on the same target host. Make sure that the restrictions of SAP Note 1681092 are considered. This includes that all other SAP HANA databases have to be stopped on replication side as soon as one SAP HANA database takes over the productive role for a primary system.

15. Is it supported to set up a replication scenario between systems with a different SAP HANA patch level?

It is allowed to use different SAP HANA patch levels in a replication scenario as long as the patch level of the replicated system is not lower than the patch level of the primary system. It is also allowed that the replicated system is on a higher SPS level than the primary system. This possibility can be used for near zero-downtime upgrades in replicated environments. For more information see the near zero downtime upgrade section in How to Perform System Replication for SAP HANA.

16. What has to be considered when upgrading SAP HANA in system replication environments?

You can stop both the primary and secondary database, then upgrade both databases and then restart both systems. If you want to minimize downtime, you can proceed according to the near zero downtime upgrade section in How to Perform System Replication for SAP HANA and at first patch the replicated system and then the primary system.

17. What has to be considered in terms of SAP HANA parameter settings in replicated scenarios?

In general you should make sure that SAP HANA parameters are set identical on primary and replication side whenever possible. Deviations can result in unexpected behavior during or after a failover. You can check SAP HANA alert 21 (<= SPS 08) or 79 (>= SPS 09) or use SQL: “HANA_Replication_ParameterDeviations” (SAP Note 1969700) in order to check for parameters that are set differently on primary and replication side.
Sometimes different parameter settings are necessary on the primary and the secondary site, e.g. if additional non-productive systems are running on the secondary site. Then the table reload must be turned off and the global allocation limit must be set to a minimum value to make sure that the memory allocation of the replicated database remains on a low level. See SAP Note 2127458 for more information regarding table reload.
In the SAP HANA Admin guide the “parameter checker” is documented, which generates the alerts. It can be manually adjusted to exclude ranges of parameters from these checks. See the section “Monitoring INI File Parameter Changes” in How to Perform System Replication for SAP HANA for more details.

18. Is it possible to perform a takeover even if the secondary database is down?

Yes, a takeover can be performed even if the secondary database is down. In order to make it available, it of course has to be started.

Leave a Reply