Scribd
Upload
37 views1 page

2661878___HANA_System_Replication_log_replay_setting_recommendations_for_large_systems_v13

SAP Note 2661878 provides recommendations for configuring log replay settings in HANA System Replication to address issues with replay backlog in large systems. It suggests increasing specific configuration parameters to enhance log replay throughput, while also noting the associated increase in memory consumption. The document emphasizes a step-wise approach to adjusting these parameters to optimize performance without wasting memory resources.

Uploaded by

Mohammad Rezazadeh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
37 views1 page

2661878___HANA_System_Replication_log_replay_setting_recommendations_for_large_systems_v13

SAP Note 2661878 provides recommendations for configuring log replay settings in HANA System Replication to address issues with replay backlog in large systems. It suggests increasing specific configuration parameters to enhance log replay throughput, while also noting the associated increase in memory consumption. The document emphasizes a step-wise approach to adjusting these parameters to optimize performance without wasting memory resources.

Uploaded by

Mohammad Rezazadeh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

SAP Note

2661878 - HANA System Replication log replay setting recommendations for large systems
Component: HAN-DB-HA (SAP HANA > SAP HANA Database > SAP HANA High Availability (System Replication, DR, etc.)), Version: 13, Released On: 06.05.2024

Symptom
Log replay on secondary site is unable to catch up with the redo log generation on primary site and therefore the replay backlog increases.
When looking at the current callstacks on secondary site, frequently only single recovery queues are active and log replay is not utilizing multiple recovery queues.

Other Terms
System Replication, Logreplay, Replay Backlog

Reason and Prerequisites


System replication secondary sites are doing log replay in replay steps. In general log replay is done in parallel by using multiple recovery queues, but at replay step boundaries, the recovery queues are synchronized. If the replay step size is small, then there are many synchronization points,
which can result in less parallel replay activity and therefore increased overall log replay runtime.
If a high replay backlog exists can be checked on primary site in the monitoring view M_SERVICE_REPLICATION by looking at the columns REPLAY_BACKLOG_SIZE and REPLAY_BACKLOG_TIME.

Solution
If there is a high amount of redo log generated, then the replay step size can be enlarged by setting the following configuration parameters on a System Replication secondary site,
which can result in a better overall log replay throughput:
indexserver.ini/[system_replication]/logshipping_replay_push_persistent_segment_count = 64 (default: 20 each 64 MB -> 1280 MB cache size)
indexserver.ini/[system_replication]/logshipping_replay_logbuffer_cache_size = 21474836480 (default: 4294967296 Bytes = 4 GB cache size)
indexserver.ini/[pitrestart]/replay_step_size = 1073741824 (default: 2097152 log positions á 64 Bytes -> 128 MB, no memory consumption here)
The parameter replay_step_size is only relevant for continuous log replay in HANA 1 SP11 and SP12. Starting with HANA 2 the parameter is only evaluated for log replay, that is done as part of the takeover.
The replay step size is limited by the amount of redo log, that can be cached in memory. Therefore, the cache memory settings have to be increased on secondary site.
In addition the replay step size itself has to be set to a higer value, but this does not consume additional memory.
A disadvantage of increasing the configuration parameters logshipping_replay_push_persistent_segment_count and logshipping_replay_logbuffer_cache_size is higher memory consumption on secondary site while the system is replicating.
So with the parameter changes above, the memory consumption on secondary site increases per indexserver by:
persistent segments: 64 x 64 MB - 1280 MB = 2816 MB
logbuffer cache size: 20 GB - 4 GB = 16 GB
So in summary around 19 GB more memory per indexserver is needed by this configuration.
For very large scale systems with extremely high load, the parameters could be increased even further, eg to the following settings:
indexserver.ini/[system_replication]/logshipping_replay_push_persistent_segment_count = 256
indexserver.ini/[system_replication]/logshipping_replay_logbuffer_cache_size = 51539607552
indexserver.ini/[pitrestart]/replay_step_size = 1073741824
This means overall around 61 GB more memory consumption per indexserver compared to the default configuration.
In order not to waste memory resources, it is recommended to use a step-wise approach and increase the parameter values step by step to higher values in multiple iterations until the right configuration is found.

This document is referenced by


SAP Note/KBA Component Title

2732928 How to deal with Alert "Service on <hostname>:<service port number> has increased log replay backlog"

1999993 HAN-DB-MON How-To: Interpreting SAP HANA Mini Check Results

1999880 HAN-DB-HA FAQ: SAP HANA System Replication

You might also like