Hana Replication Service Test

This test auto-discovers the secondary servers that are communicating with the target database server and for each secondary server, this test reports the amount of data that needs to be currently replicated. This test also throws light on the time taken for completing the replication and the time that elapsed since the last delta replication /last full replication were initiated on each secondary server. In addition, the difference in log position and savepoint log position between each primary server and the secondary server is reported. Using this test, administrators can determine the secondary server that is up to-date with the primary server and on which the replication is completed successfully.

Target of the test : A SAP HANA Database Server

Agent deploying the test : A remote agent

Outputs of the test : One set of results for each Primary server:Secondary server combination communicating with the target SAP HANA database server being monitored.

Configurable parameters for the test
Parameter Description

Test period

How often should the test be executed

Host

The host for which the test is to be configured.

Port

The port number at which the specified Host listens to. By default, this will be 30015.

User

In order to monitor a SAP HANA database server, a special database user account with Monitoring privileges has to be created in every SAP HANA database instance that requires monitoring. The syntax of the script that is used for user creation is discussed in How to Monitor SAP HANA Database Server Using eG Enterprise?.

The name of such a user has to be specified here.

Password

Enter the password of the specified User.

Confirm Password

Confirm the password by retyping it here.

IsPassive

If the value chosen for this parameter is Yes, then the SAP HANA database server under consideration is a passive server in a SAP HANA cluster. No alerts will be generated if the server is not running. Measures will be reported as “Not applicable” by the agent if the server is not up.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Current replication backlog size

Indicates the amount of data that needs to be currently replicated to this secondary server.

MB

A high value for this measure indicates that the secondary server is not up to-date with the data available in the primary server. This may lead to data loss if the primary server goes down abruptly.

Compare the value of this measure across the secondary servers to figure out the secondary server that needs to be updated with the maximum amount of data.

The detailed diagnosis of this measure lists the active status of the secondary server, the connect time of the secondary server, the reconnect count of the secondary server, failover count of the secondary server, the async buffer full count, the backlog size, the maximum backlog size, the backlog time and maximum backlog time.

Current replication backlog time

Indicates the time taken to transfer the data that needs to be replicated to this secondary server.

Seconds

A high value for this measure is a cause of concern. This may indicate that the secondary server is not up to-date with the data available in the primary server.

Compare the value of this measure across the secondary servers to figure out the server that takes too much of backlog time for data replication.

Time since last delta replica shipped

Indicates the time elapsed since the last delta replication was initiated on this secondary server.

Seconds

The detailed diagnosis of this measure lists the active status of the secondary server, the connect time of the secondary server, the reconnect count of the secondary server, the shipped delta replica count, the shipped last delta replica size, the shipped last delta replica start time and the shipped last delta replica end time.

Time since last full replica shipped

Indicates the time elapsed since the last full replication was initiated on this secondary server.

Seconds

The detailed diagnosis of this measure lists the active status of the secondary server, the connect time of the secondary server, the reconnect count of the secondary server, the last full replica size shipped, the last full replica shipped start time and the last full replica shipped end time.

A full set of the data created as HANA in-place snapshot on the disk of the primary is initially sent when system replication is set up.

Lagging in shipped log position count

Indicates the difference between the current log position of the primary server and the log position of this secondary server.

Number

The log position is determined as the position from which logs must be read during restart.

The detailed diagnosis of this measure lists the active status of the secondary server, the connect time of the secondary server, the reconnect count of the secondary server, the last log position, the last log position time, the shipped log position and the shipped log position time.

Lagging in shipped log position time

Indicates the difference detected in the current log position time of the primary server and the log position time of this secondary server.

Seconds

 

Lagging in savepoint log position count

Indicates the difference between the savepoint log position of the primary server and this secondary server.

Number

SAP HANA persists in-memory data by using savepoints. Each SAP HANA service has its own separate savepoints. During a savepoint operation, SAP HANA database flushes all changed data from memory to the data volumes. The data belonging to a savepoint represents a consistent state of the data on disk and remains so until the next savepoint operation has completed. Redo log entries are written to the log volumes for all changes to persistent data. In the event of a database restart (for example, after a crash), the data from the last completed savepoint can be read from the data volumes, and the redo log entries written to the log volumes since the last savepoint can be replayed. Savepoints are also triggered automatically by a number of other operations such as data backup, and database shutdown and restart.

The detiailed diagnosis of this measure lists the active status of the secondary server, the connect time of the secondary server, the reconnect count of the secondary server, the last savepoint log position, the last savepoint start time, the shipped savepoint log position and the shipped savepoint start time.

Lagging in savepoint log position time

Indicates the difference in the savepoint log position time between the primary server and this secondary server.

Seconds