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.
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:
|
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 |
|