orkungedik/SAP-basis-dataset huggingface dataset:
## 6.5 Memory Management
Several parameters can be used to set the memory limit for read accesses on the secondary system.
The total statement memory is limited to 50 % of the global allocation limit, because 50% of the storage is reserved for log replay. Log replay should not fail because of memory limitations.
Use the parameters below to set the memory limit for read accesses on the secondary system:
| Parame­ ter:   | sr_total_statement_memory_limit                                                                                     |
|---------------|---------------------------------------------------------------------------------------------------------------------|
| Type:         | int (GB)                                                                                                            |
| Default:      | (empty)                                                                                                             |
| Section       | memorymanager                                                                                                       |
| Descrip­ tion: | Memory limit in GB: ● (empty): 50%of global allocation limit ● 0: disable the feature ● N: set the value as a limit |
| Parame­ ter:   | sr_enable_tracking                                                                                                  |
| Type:         | bool                                                                                                                |
| Default:      | on                                                                                                                  |
| Section       | resource_tracking                                                                                                   |
| Descrip­ tion: | Main switch for resource tracking used on the system replication secondary system.                                  |
| Parame­ ter:   | sr_memory_tracking                                                                                                  |
| Type:         | bool                                                                                                                |
| Default:      | on                                                                                                                  |
| Section       | resource_tracking                                                                                                   |
| Descrip­ tion: | Enables or disables memory tracking on the secondary system.                                                        |
## 6.6 Virtual IP Address Handling
In an Active/Active (read enabled) configuration, a second virtual IP address for the read access on the secondary system is needed.
Since in an Active/Active (read enabled) configuration both systems are open for SQL access, a second virtual IP address for read access on the secondary system is needed.
During takeover you can keep the virtual IP address of the secondary system. This virtual IP address will be used for read access until a reconnect occurs. The former virtual IP address of the primary system is also rebound to access the former secondary system, which is the now active system. In this situation, two virtual IP addresses are available for accessing the former secondary system after takeover. For more information, see Client Connection Recovery After Takeover .
##  Note
Make sure that the now active system is capable to handle the workload of the former primary system and the read-access secondary system.
During failback the system replication systems switch their roles and the virtual IP addresses switch their locations too.
## Related Information
Client Connection Recovery After Takeover [page 92] Connecting Using Active/Active (Read Enabled) Failback [page 100]
## 6.7 Authentication Methods
There are several authentication methods supported for an Active/Active (read enabled) system replication.
The following authentication methods are supported for the primary system:
- Basic (User Name/Password)
- Kerberos
- SAML
- Session Cookies
The secondary system delegates the authentication phase to the primary system using the existing communication channel from the secondary system to the primary system. Remote authentication tickets or credentials are sent over the data centers.
## 6.8 Monitoring Active/Active (Read Enabled)
You can monitor the Active/Active (read enabled) solution using proxy views or the SAP HANA Cockpit.
## Proxy views
The embedded statistics server runs in the primary system and collects data from the secondary system providing them in the corresponding proxy schema. For more information, see Monitoring Secondary Systems .
## SAP HANA Cockpit
The monitoring functionality in the SAP HANA cockpit supports access to the read-enabled system. Additionally, it provides information about the delay of the currently available consistent view. For more information, see Monitoring SAP HANA System Replication with the SAP HANA Cockpit .
## Related Information
Monitoring Secondary Systems [page 155] Monitoring SAP HANA System Replication with the SAP HANA Cockpit [page 175]
## 7 SAP HANA System Replication Setups
Learn how to configure a multitier or a multitarget system replication.
## Which setups are available for system replication?
Besides the standard setup, in which a primary system ships all the data to the secondary system, you can also configure a multitier or a multitarget system replication.
In a multititer system replication, a tier 2 system replication setup can be used as the source for adding further tiers in a chain. The primary system is always on tier 1. The replication source for the tier 2 secondary system is the primary system, while the replication source for the tier 3 secondary system is the tier 2 secondary. For more information, see SAP HANA Multitier System Replication .
In a multitarget system replication, the primary system can replicate data changes to more than one secondary system. For more information, see SAP HANA Multitarget System Replication .
## Related Information
SAP HANA Multitier System Replication [page 128]
Configuring SAP HANA Multitier System Replication [page 129] Performing a Takeover and a Failback in SAP HANA Multitier System Replication [page 139] SAP HANA Multitarget System Replication [page 142] Example: Configure a SAP HANA Multitarget System Replication [page 144] Disaster Recovery Scenarios for Multitarget System Replication [page 145]
## 7.1 SAP HANA Multitier System Replication
To offer higher levels of availability, you can link multiple systems in a SAP HANA multitier system replication landscape.
You can configure system replication to support geo-clustering, that is multitier system replication between a primary data center and other geographically remote data centers to form a single highly available system.
## Related Information
## 7.1.1  Configuring SAP HANA Multitier System Replication
With multitier system replication, a tier 2 system replication setup can be used as the source for replication in a chained setup of primary system, tier 2 secondary system, and tier 3 secondary system.
After configuring a basic system replication scenario, you must add a third system to provide another level of redundancy. In a multitier setup, the primary system is always on tier 1, a tier 2 secondary has a primary system as its replication source, and a tier 3 secondary has the tier 2 secondary as its replication source.
The operation mode must be the same for all systems. However, if logreplay\_readaccess is used between tier 1 and tier 2, as an exception from this rule only the logreplay operation mode can be used between tier 2 and tier 3. Furthermore, it is not possible to combine the logreplay and delta\_datashipping operation modes.
Multitier system replication supports various replication mode combinations. For more information, see Supported Replication Modes Between Systems .
You can configure multitier system replication using the following tools:
- SAP HANA cockpit For more information, see Example: Configure SAP HANA Multitier System Replication with the SAP HANA Cockpit .
- SAP HANA studio
For more information, see Example: Configure SAP HANA Multitier System Replication with the SAP HANA Studio .
- hdbnsutil For more information, see Example: Configure SAP HANA Multitier System Replication with hdbnsutil .
## Related Information
Supported Replication Modes Between Systems [page 130]
Example: Configure SAP HANA Multitier System Replication with SAP HANA Cockpit [page 133]
Example: Configure SAP HANA Multitier System Replication with hdbnsutil [page 136]
Example: Configure SAP HANA Multitier System Replication with SAP HANA Studio [page 138]
Operation Modes for SAP HANA System Replication [page 14]
## 7.1.1.2 Example: Configure SAP HANA Multitier System Replication with SAP HANA Cockpit
Learn how to configure a multitier system replication landscape with the SAP HANA cockpit from the primary system.
## Prerequisites
- You have considered all the general prerequisities needed to configure system replication. For more information, see General Prerequisites for Configuring SAP HANA System Replication .
- All three systems A,B, and C are registered in the SAP HANA cockpit.
## Procedure
1. On the Resource Directory page, choose Site A or the SAP HANA system that will be the primary system.
2. On the System Overview page, choose the system replication tile.
3. Choose Configure System Replication on the top right to configure system replication.
4. Enter the required information on the System Replication Configuration page.
<!-- image -->
<!-- image -->
<!-- image -->
5. Choose Add 3 tier system and enter the requiered information for the tier 3 secondary system.
6. Choose Configure on the bottom right.
On the system replication overview, you should now see the tier 3 configuration.
<!-- image -->
## Related Information
General Prerequisites for Configuring SAP HANA System Replication [page 35]
Supported Replication Modes Between Systems [page 130]
Operation Modes for SAP HANA System Replication [page 14]
Example: Configure SAP HANA System Replication with the SAP HANA Cockpit [page 47]
## 7.1.1.3 Example: Configure SAP HANA Multitier System Replication with hdbnsutil
Learn how to configure SAP HANA multitier system replication with the hdbnsutil command line.
## Prerequisites
- You have considered all the general prerequisities needed to configure system replication. For more information, see General Prerequisites for Configuring SAP HANA System Replication .
- You have installed and configured three identical, independently operational SAP HANA systems - a primary system, a tier 2 secondary system, and a tier 3 secondary system.
## Context
The following steps show how to configure such a system. In this scenario there are three SAP HANA systems: A, B, and C, named SiteA, SiteB, and SiteC. Furthermore, in this scenario multitier system replication supports a tier 2 secondary with sync replication mode and a tier 3 secondary with async replication mode. The operation mode is logreplay .
## Procedure
1. [A] Start the SAP HANA database.
2. [A] Create a data backup or storage snapshot. In multiple-container systems, the system database and all tenant databases must be backed up.
3. [A] Enable system replication and give the system a logical name. As &lt;sid&gt; adm:
4. Stop the tier 2 secondary.
```
cd /usr/sap/<sid>/HDB<instancenr>/exe ./hdbnsutil -sr_enable --name=SiteA
```
As &lt;sid&gt; adm run the SAPControl program to shut down the system:
/usr/sap/hostctrl/exe/sapcontrol -nr &lt;instance\_number&gt; -function StopSystem HDB
5. [B] On the stopped tier 2 secondary, register site B with Site A as &lt;sid&gt;adm:
6. [B] Start the tier 2 secondary system.
```
hdbnsutil -sr_register --replicationMode=sync --operationMode=logreplay -name=SiteB
```
```
--remoteInstance=<instId> --remoteHost=<hostname_of_A>
```
As &lt;sid&gt; adm run the SAPControl program to start the system:
/usr/sap/hostctrl/exe/sapcontrol sapcontrol -nr &lt;system number&gt; -function StartSystem HDB
7. [B] Enable this site as the source for a tier 3 secondary system:
As &lt;sid&gt; adm on the tier 2 secondary run hdbnsutil -sr\_enable
8. [C] Stop the tier 3 secondary system.
As &lt;sid&gt; adm run the SAPControl program to shut down the system:
/usr/sap/hostctrl/exe/sapcontrol -nr &lt;instance\_number&gt; -function StopSystem HDB
9. [C] On the stopped system, register siteC as a tier 3 secondary system as &lt;sid&gt;adm:
10. [C] Start the SAP HANA database on the tier 3 secondary.
```
hdbnsutil -sr_register --replicationMode=async --operationMode=logreplay -name=SiteC --remoteInstance=<instId> --remoteHost=<hostname_of_B>
```
As &lt;sid&gt; adm run the SAPControl program to start the system:
/usr/sap/hostctrl/exe/sapcontrol sapcontrol -nr &lt;system number&gt; -function StartSystem HDB
11. Check the replication status with systemReplicationStatus.py on command line or in the M\_SERVICE\_REPLICATION system view.
## Related Information
General Prerequisites for Configuring SAP HANA System Replication [page 35]
Supported Replication Modes Between Systems [page 130] Operation Modes for SAP HANA System Replication [page 14]
## 7.1.1.4 Example: Configure SAP HANA Multitier System Replication with SAP HANA Studio
You can configure SAP HANA multitier system replication using the SAP HANA studio.
## Prerequisites
- You have considered all the general prerequisities needed to set up system replication. For more information, see General Prerequisites for Configuring SAP HANA System Replication .
- You have added the systems in the SAP HANA studio.
- You have verified that the log\_mode parameter in the persistence section of the global.ini file is set to normal for the systems.
- You can do this in the Administration editor ( Configuration tab) of the SAP HANA studio.
- You have stopped the tier 3 secondary system.
## Context
The following example describes how to add a tier 3 secondary with a synchronously running tier 2 system replication.
## Procedure
1. Enable system replication on the tier 2 secondary, which has to be online, as follows:
- a. In the Systems view right click the tier 2 secondary system, choose Configuration and Monitoring
3. Configure System Replication The Configure System Replication dialog opens. The Enable System Replication option is selected by
4. default. The site name is already known from the topology metadata.
- b. Choose Next .
- c. Review the configured information and choose Finish .
2. Register the tier 3 secondary system as follows:
- a. You have installed and configured three identical, independently operationalStop the tier 3 secondary system if it is still running. Right-click the tier 3 secondary system and choose Configuration and Monitoring Stop System
- b. In the Systems view, right-click the tier 3 secondary system and choose Configuration and Monitoring Configure System Replication . The Configure System Replication dialog opens.
- c. Choose Register Secondary System and then Next .
- d. Enter the required system information and the logical name used to represent the tier 3 secondary system.
##  Note
If you are operating a distributed system on multiple hosts, you enter the name of the host on which the master name server is running.
- e. Specify the replication mode and enter the tier 2 secondary system's host name.
For more information, see Supported Replication Modes Between Systems .
- f. Review the configured information and choose Finish .
## Results
The secondary system is automatically started and the replication process to the tier 3 secondary then starts automatically.
## Related Information
General Prerequisites for Configuring SAP HANA System Replication [page 35]
Supported Replication Modes Between Systems [page 130]
## 7.1.2  Performing a Takeover and a Failback in SAP HANA Multitier System Replication
You can perform a takeover and a failback also in a SAP HANA multitier system replication.
If the primary system fails, you can perform a takeover to the tier 2 secondary system.
Once your failed system is operational again, you can attach it as a tier 3 secondary system or you can restore the original multitier system replication configuration. To learn how to perform these steps with the hdbnsutil command line, see Attach the Original Primary System as a New Tier 3 Secondary System and Restore the Original SAP HANA Multitier System Replication Configuration .
## Related Information
Example: Attach the Original Primary System as a New Tier 3 Secondary System [page 140]
Example: Restore the Original SAP HANA Multitier System Replication Configuration [page 141]
## 7.1.2.1 Example: Attach the Original Primary System as a New Tier 3 Secondary System
Once your failed system is operational again, you can attach it as a tier 3 secondary system.
## Context
The steps below show how to set up multitier system replication again after a takeover. In these scenarios there are three SAP HANA systems A, B and C, named SiteA, SiteB, and SiteC. Furthermore, in this scenario multitier system replication supports a tier 2 secondary with sync replication mode and a tier 3 secondary with async replication mode.
## Procedure
SiteA failed, SiteB has taken over and now you attach SiteA as the tier 3 secondary.
1. [C] Change the replication mode of the new tier 2 secondary:
```
cd /usr/sap/<sid>/HDB<instance_number>/exe ./hdbnsutil -sr_changemode --replicationMode=sync
```
Multitier system replication supports various replication mode combinations. For more information, see Supported Replication Modes between Sites .
2. [C] Enable SiteC as the replication source:
3. [A] Make sure that the SAP HANA database is stopped. This should be the case as a takeover was already carried out otherwise you can stop it with the following command:
4. [A] Register SiteA as a new tier 3 secondary.
5. [A] Start the SAP HANA database
6. [B] Check in M\_SERVICE\_REPLICATION that sync system replication is ACTIVE from SiteB to SiteC and that async replication is ACTIVE from SiteC to SiteA.
```
hdbnsutil -sr_enable
```
```
/usr/sap/hostctrl/exe/sapcontrol -no <instance_number> -function StopSystem HDB
```
```
hdbnsutil -sr_register --replicationMode=async --name=SiteA -remoteInstance=<instId> --remoteHost=<hostname_of_C>
```
```
/usr/sap/hostctrl/exe/sapcontrol -no <instance_number> -function StartSystem HDB
```
## Related Information
Supported Replication Modes Between Systems [page 130]
## 7.1.2.2 Example: Restore the Original SAP HANA Multitier System Replication Configuration
Once your failed system is operational again, you can restore the original SAP HANA multitier system replication configuration.
## Context
The steps below show how to set up multitier system replication again after a takeover. In these scenarios there are three SAP HANA systems A, B and C, named SiteA, SiteB, and SiteC. Furthermore, in this scenario multitier system replication supports a tier 2 secondary with sync replication mode and a tier 3 secondary with async replication mode.
## Procedure
You want to restore the original multitier setup:
1. [C] Stop the SAP HANA database
2. [C] Unregister SiteC from SiteB:
3. [A] Stop the SAP HANA database
```
/usr/sap/hostctrl/exe/sapcontrol -no <instance_number> -function StopSystem HDB
```
```
hdbnsutil -sr_unregister
```
/usr/sap/hostctrl/exe/sapcontrol -no &lt;instance\_number&gt; -function StopSystem HDB
4. [A] Register as secondary:
5. [A] Start the SAP HANA database
6. [B] Check in M\_SERVICE\_REPLICATION that sync system replication is ACTIVE from SiteB to SiteA.
```
hdbnsutil -sr_register --replicationMode=sync --name=SiteA -remoteInstance=<instId> --remoteHost=<hostname_of_B>
```
```
/usr/sap/hostctrl/exe/sapcontrol -no <instance_number> -function StartSystem HDB
```
7. [A] SiteA takes over as the primary system:
8. [B] Stop the SAP HANA database
```
hdbnsutil -sr_takeover
```
/usr/sap/hostctrl/exe/sapcontrol -no &lt;instance\_number&gt; -function StopSystem HDB
9. [A] Enable system replication:
10. [B] Register SiteB as the tier 2 secondary of SiteA.
11. [B] Start the SAP HANA database
```
hdbnsutil -sr_enable --name=SiteA
```
```
hdbnsutil -sr_register --replicationMode=sync --name=SiteB -remoteInstance=<instId> --remoteHost=<hostname_of_A>
```
/usr/sap/hostctrl/exe/sapcontrol -no &lt;instance\_number&gt; -function StartSystem HDB
12. [B] Enable SiteB as a replication source system:
13. [C] Register SiteC as a tier 3 secondary in the multitier system replication scenario:
14. [C] Start the SAP HANA database
```
hdbnsutil -sr_enable
```
```
hdbnsutil -sr_register --replicationMode=async --name=SiteC -remoteInstance=<instId> --remoteHost=<hostname_of_B>
```
/usr/sap/hostctrl/exe/sapcontrol -no &lt;instance\_number&gt; -function StartSystem HDB
15. [B] Check in M\_SERVICE\_REPLICATION that sync replication is ACTIVE from SiteA to SiteB and that async replication is ACTIVE from SiteB to SiteC.
## 7.2 SAP HANA Multitarget System Replication
In a multitarget system replication, the primary system can replicate data changes to more than one secondary system.
Multitarget system replication brings advantages for several use cases:
- Update scenarios
- Rearrangements of system replication multitier chains
- Reaching higher availability (before stopping existing structures, new structures can be build and established)
The graphic shows a possible setup for multitarget system replication.
Primary system A in data center 1 replicates data changes to secondary system B in the same data center. Primary system A also replicates data changes to secondary system C in data center 2. Secondary system C is a source system for a further secondary system D located in the same data center with system C.
<!-- image -->
To understand how to handle in different disaster recovery scenarios, see Disaster Recovery Scenarios for Multitarget System Replication . In a multitarget system replication, the secondary systems can be configured to automatically re-register to a new source system when the original source system unavailable.
In a multitarget system replication setup, you can configure multiple secondaries as Active/Active (read enabled). Only one of these secondaries can be accessed via hint-based statement routing; the others must be accessed via direct connection. For more information on Active/Active (read enabled), see Active/Active (Read Enabled) .
## Related Information
Example: Configure a SAP HANA Multitarget System Replication [page 144] Operation Modes for SAP HANA System Replication [page 14] Disaster Recovery Scenarios for Multitarget System Replication [page 145] Full Sync Option for SAP HANA System Replication [page 58] Log Retention [page 20] Log Retention and Multitarget System Replication [page 25] Configure Secure Communication (TLS/SSL) Between Primary and Secondary Sites [page 259] Use Multitarget System Replication for Near Zero Downtime Upgrades [page 203] Active/Active (Read Enabled)
## 7.2.1  Example: Configure a SAP HANA Multitarget System Replication
You can configure a multitarget system replication in which a primary system replicates data changes to more than one secondary system.
## Context
In this example, primary system A in data center 1 replicates data changes to secondary system B in the same data center. Primary system A also replicates data changes to secondary system C in data center 2. Secondary system C is a source system for a further secondary system D located in the same data center with system C.
## Procedure
1. On primary system A in data center 1:
- a. Create backups.
- b. Enable system replication.
2. On the local secondary system B in data center 1:
- a. Stop the system.
- b. Register it to A.
- c. Start the system.
3. On the remote secondary system C in data center 2:
- a. Stop the system.
- b. Register it to A.
- c. Start the system.
4. On the remote secondary system D in data center 2:
- a. Stop the system.
- b. Register it to C.
- c. Start the system.
## 7.2.2  Disaster Recovery Scenarios for Multitarget System Replication
Several solutions are available when the systems involved in a multitarget system replication configuration fail.
We are using the setup described in Multitarget System Replication to exemplify the procedure. In this setup, primary system A replicates data changes to secondary system B located in the same data center. Primary system A also replicates data changes to the secondary system C located in data center 2. Secondary system C is a source system for a further secondary system D located in the same data center with system C.
## Failure on Primary System A
<!-- image -->
When primary system A fails, proceed as follows:
1. Take over on secondary system B in data center 1.
2. Register secondary system C in data center 2 to the new primary system B in data center 1. Then, register secondary system D in data center 2 to secondary system C.
3. After the failure on the previous primary system A is solved, register it to the new primary system B in data center 1.
Alternatively, you can set the global.ini/[system\_replication]/
register\_secondaries\_on\_takeover paramater to true and take over on secondary system B in data
center 1. As a result, secondary system C in data center 2 will register automatically to the new primary system B in data center, while secondary system D in data center 2 will register automatically to secondary system C. After the failure on the previous primary system A is solved, register it to the new primary system B in data center 1.
## Failure of Data Center 1
<!-- image -->
When all the systems in data center 1 fail, proceed as follows:
1. Take over on secondary system C in data center 2.
2. After the failure on the previous primary system is solved, register system A to the new primary system C in data center 2.
3. Register secondary system B as tier 3 to system A in data center 1.
For more information about takeover and failback, see Performing a Takeover and Performing a Failback .
## Related Information
Performing a Takeover Performing a Failback Full Sync Option for SAP HANA System Replication [page 58] Log Retention [page 20]
## 8 SAP HANA System Replication: Operation and Maintenance
Learn how to monitor SAP HANA system replication.
## How can I monitor system replication?
There are multiple ways to monitor system replication and to verify if the primary and secondary systems are in sync and are running correctly:
- Alerts on the primary and secondary systems warn you of potential problems.
- To ensure rapid takeover in the event of planned or unplanned downtime, you can check the status of the replication between the primary and the secondary system.
- You can monitor system replication using the SAP HANA cockpit, the SAP HANA studio, the hdbnsutil command line tool, or SQL queries.
This chapter also includes information about the network connection, how to copy or move tenants in a system replication configuration, or how to use SAP HANA system replication to update your SAP HANA systems.
## Where can I find more information?
The following SAP Notes are relevant for a full understanding of the concepts described in this chapter:
SAP Notes
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
|   SAP Note | Title                                                                                                   |
|------------|---------------------------------------------------------------------------------------------------------|
|    1917938 | Migration of the statistics server for Revision 74 or higher                                            |
|    2369981 | Required configuration steps for authentication with HANASystem Replica­ tion                            |
|    2300936 | Host Auto-Failover &System Replication Setup with SAP HANAextended application services, advanced model |
|    1999880 | FAQ: SAP HANASystem Replication                                                                         |
|    1969700 | SQL Statement Collection forSAPHANA                                                                     |
|    2494079 | Near-Zero-Downtime-Upgrade to HANA2SPS02or above when internal communicationSSL is used                 |
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
|   SAP Note | Title                                                                         |
|------------|-------------------------------------------------------------------------------|
|    2081065 | Troubleshooting SAP HANANetwork                                               |
|    1984882 | Using HANASystem Replication for Hardware Exchange with minimum/zero Downtime |
|    1984882 | How-To Guides &Whitepapers For SAP HANAHigh Availability                      |
|    2386973 | Near Zero Downtime Upgrades for HANADatabase 3-tier System Replica­ tion       |
## Related Information
SAP HANA System Replication Details [page 148]
Alerts [page 152]
Checking the SAP HANA System Replication Status [page 159]
Monitoring System Replication [page 175]
System Replication Network Connection [page 187]
Copy or Move Tenants Within System Replication [page 194]
Copying a System using System Replication [page 195]
Updating SAP HANA Systems with SAP HANA System Replication [page 196]
SAP HANA SQL and System Views Reference
## 8.2 Alerts
Alerts on the primary and secondary systems warn you of potential problems.
For an overview of the alerts issued by the primary system, see SAP HANA System Replication Alerts .
On the system overview page of SAP HANA cockpit, choose Show All on the Alerts tile to see all alerts. Alerts occurring on the secondary system are reported on the primary system. In the SAP HANA cockpit, they are displayed as alerts and associated with the host where they occurred.
## Description
Current replication backlog in microseconds. This is time dif­
ference between time of the last sent log buffer and the cur­
rent log buffer.
Even in replication modes sync/syncmem this column can have a value different from 0, because log buffers are still in
the send queue (max number of these buffers is the number of log buffers configured on primary site).
Max replication backlog in microseconds (max value of
BACKLOG\_TIME since system startup).
This is an example of an alert in the SAP HANA cockpit which occured on the secondary system (ld4127) and is reported on the primary system (ld4126):
<!-- image -->
In the SAP HANA studio, you can choose the Alerts tab to see all generated alerts.
If you want to receive an e-mail when an alert condition for all or specific checks is fulfilled, follow the steps described in Configure E-Mail Notifications for Alerts for SAP HANA studio or Set Up E-mail Notification for SAP HANA cockpit.
An alerting for the secondary systems was also established with the introduction of the so-called proxy views. Alerts occurring on the secondary hosts are shown on the primary system as alerts and associated with the host where they occurred. For more information, see Monitoring Secondary Systems .
## Related Information
SAP HANA System Replication Alerts [page 153]
Monitoring Secondary Systems [page 155] Configure E-Mail Notifications for Alerts Set Up E-Mail Notification Proxy Schemas and Views [page 156] Monitoring and Replicating INI File Parameter Changes [page 158]
## 8.2.2  Monitoring Secondary Systems
Remote SQL access on the primary system allows monitoring and reporting of the secondary system statistics.
There is a possibility to monitor the secondary system through proxy schemas and views. Proxy schemas and views are provided on the primary system. They extract the corresponding information from the monitoring views on the secondary system. The retrieval of statistics is unaffected by the replication or operation mode and is available for a two system replication setup as well as for multitier landscapes.
A new schema is created on the primary system for each registered secondary system. This schema follows the naming convention \_SYS\_SR\_SITE\_&lt;siteName&gt;, where &lt;siteName&gt; is the case-sensitive name given at the registration time of the secondary system. This schema contains a selected subset of monitoring views (for example, M\_VOLUME\_IO\_TOTAL\_STATISTICS), which proxies the statistics from the secondary system. These proxy views have the same column definitions as the equivalently named public synonyms already available for the primary system. When a secondary system is unregistered, the corresponding schema will be dropped.
##  Note
If system replication is configured as an Active/Active (read enabled) system with the logreplay\_readaccess operation mode, then more data is available from the secondary system in the
\_SYS\_SR\_SITE\_&lt;siteName&gt; proxy schema and more monitoring views of the secondary system can be accessed using virtual tables.
Based on these views and tables available in the proxy schema, the statistics server is able to generate alerts on the secondary systems of a system replication landscape. Alerts issued by the secondary systems are displayed in the Alerts tile of the SAP HANA cockpit.
SYS\_DATABASES\_SR\_SITE &lt;secondary\_site\_name&gt; is a second proxy schema containing proxy views, which can be queried to get information from the corresponding view in the SYS\_DATABASES schema on the secondary system. These proxy views simplify the monitoring of secondary systems from the primary system.
## Limitations
- Monitoring view access is only possible if the primary and secondary systems run with exactly the same software version.
- When such a proxy view is queried and the secondary system is not started, no results are shown without the report of an SQL error.
- Querying against multitenant landscapes is limited to single tenant databases or the system database, meaning there are no views unifying all tenants on the system database similar to the SYS\_DATABSES schema.
## Related Information
Alert Details
Proxy Schemas and Views [page 156]
## 8.2.2.1 Proxy Schemas and Views
You can monitor the secondary system through proxy schemas and views.
To see the proxy views of the secondary system's monitoring views, you can use the SAP HANA cockpit. On the system overview page of the primary system, choose Execute SQL to open the SAP HANA Database Explorer.
Then open the primary's catalog and go to the corresponding schema. This is a schema example:
<!-- image -->
To see the virtual tables available in the proxy schema of the secondary system, open the proxy schema for the primary system in the SAP HANA Database Explorer for the primary system and choose Tables . A long list of accessible monitoring views from the secondary will be available.
<!-- image -->
Any of these proxy views or virtual tables can be accessed using SQL from the primary system by providing the correct secondary's schema name. For example:
<!-- image -->
## 8.3 Checking the SAP HANA System Replication Status
To ensure rapid takeover in the event of planned or unplanned downtime, you can monitor the status of replication between the primary system and the secondary system.
There are several ways to gather information about the overall status of the sites and of the system replication:
- With the landscapeHostConfiguration.py script This script provides information only about the state of one SAP HANA database. A returned error state
(for example, return code 1) could indicate that a takeover to the secondary should be considered.
- With the systemReplicationStatus.py script This script shows whether the secondary systems are in sync or not. This provides more confidence if a takeover is justified.
- With the getTakeoverRecommendation script This script shows the takeover recommendation based on the current system state.
##  Recommendation
Rather than calling both landscapeHostConfiguration.py and systemReplicationStatus.py manually and calculate the required action based on return codes, you can use the getTakeoverRecommendation.py script.
- With HDB console Using the HDB console you can check the system replication status on all hosts and for all services.
- With predefined SQL statements
## Related Information
Checking the Status with landscapeHostConfiguration.py [page 160]
```
Checking the Status with systemReplicationStatus.py [page 163] Checking the Status with getTakeoverRecommendation.py [page 165] Example: Checking the Status on the Primary and Secondary Systems [page 166] Checking the Status with the HDB Console [page 170] Checking the Status with Predefined SQL Statements [page 172] Monitoring Status and Resource Usage of System Components
```
## 8.3.2  Checking the Status with systemReplicationStatus.py
Check the status of system replication using the systemReplicationStatus.py script.
systemReplicationStatus.py shows whether the secondary systems are in sync or not. This provides more confidence if a takeover is justified. If system replication was never in sync or is outdated, unexpected loss of data might occur.
Check the overall status of the system replication using as &lt;sid&gt;adm user the systemReplicationStatus.py script located in $DIR\_INSTANCE/../exe/python\_support .
```
<sid>adm># python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py | Host | Service Name | Site Name | Secondary | ... | Replication |... | | | | Host | | Status | | ------ | ---------------- | --------- | --------- | ----- | ----------- |---| ld7805 | indexserver | WALLDORF | ld8475 | ... | ACTIVE | | ld8513 | statisticsserver | WALLDORF | ld8476 | | ACTIVE | | ld8513 | xsengine | WALLDORF | ld8476 | | ACTIVE | | ld8513 | nameserver | WALLDORF | ld8476 | | ACTIVE | | ld8513 | indexserver | WALLDORF | ld8476 | | ACTIVE | | ld8559 | indexserver | WALLDORF | NOT MAPPED | | | status system replication site "2": ACTIVE status system replication site "3": ACTIVE overall system replication status: ACTIVE Local System Replication State ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mode: PRIMARY site id: 1
```
## site name: WALLDORF
The return codes of the script are:
|   Return code | Description                                                                                                                                     |
|---------------|-------------------------------------------------------------------------------------------------------------------------------------------------|
|            10 | No System Replication                                                                                                                           |
|            11 | Error Error occurred on the connection. Additional details on the error can be found in REPLICATION_STA­ TUS_DETAILS.                            |
|            12 | Unknown The secondary system did not connect to primary since last restart of the primary system.                                               |
|            13 | Initializing Initial data transfer is in progress. In this state, the secondary is not usable at all.                                           |
|            14 | Syncing The secondary system is syncing again (for example, after a temporary connection loss or restart of the secondary).                     |
|            15 | Active Initialization or sync with the primary is complete and the secondary is continuously replicating. No data loss will occur in SYNC mode. |
Use the following state-transition graphic to understand the return codes of the script.
<!-- image -->
## Related Information
Monitoring and Replicating INI File Parameter Changes [page 158]
M\_SERVICE\_REPLICATION System View [page 269] Example: Checking the Status on the Primary and Secondary Systems [page 166] SAP HANA SQL and System Views Reference
## 8.3.3  Checking the Status with getTakeoverRecommendation.py
Check the status of system replication using the getTakeoverRecommendation.py script.
The getTakeoverRecommendation script shows the takeover recommendation based on the current system state. However, when the primary system faces any error situation, the system replication status cannot be determined anymore. Thus, the previous state should be saved and compared with the current state.
The script provides the following recommendations as takeover status based on the results of the other two scripts landscapeHostConfiguration.py and systemReplicationStatus.py . It also provides an overall status and a return code to match the overall host status.
| landscapeHostConfigura­ tion   | systemReplicationStatus                           | Takeover Status   | Reason for the takeover rec­ ommendation                |
|-------------------------------|---------------------------------------------------|-------------------|--------------------------------------------------------|
| Error/Fatal/Warning           | NoHsr/Error/ Unknown/Initi­ alizing/Syncing/Active | Required          | Primary system has errors                              |
| OK/Info/Ignore                | NoHsr/Error/ Unknown/Initi­ alizing/Syncing        | Cannot decide     | Unknown system replication status                      |
| OK/Info/Ignore                | Active                                            | Possible          | Primary system is up and system replication is in sync |
This is a sample implementation of a python script that uses getTakeoverRecommendation to act as a minimalistic cluster manager.
Use the --sapcontrol=1 parameter, if you require a reliable and parsable output.
```
import time import subprocess from getTakeoverRecommendation import TakeoverDecision def main(): wasInSync = False while True: recommendation = subprocess.call(["python","getTakeoverRecommendation.py","--sapcontrol=1"]) if not wasInSync and recommendation is TakeoverDecision.Required: print "Primary defect & no sync => NO TAKEOVER" if wasInSync and recommendation is TakeoverDecision.Required: print "Primary defect & sync => TAKEOVER" nowInSync = recommendation is TakeoverDecision.Possible wasInSync = nowInSync
```
The output depends on the previous state with the result of the current call of getTakeoverRecommendation . If no sync state is reached, a takeover is not advised. But once the systems are in sync, the next error of the primary system will suggest a takeover. Any subsequent negative return value will reset the sync state as it is no longer ensured that the replicated data is current.
## Related Information
Example: Checking the Status on the Primary and Secondary Systems [page 166]
## 8.3.6  Checking the Status with Predefined SQL Statements
Use predefined SQL statements to check the system replication status.
Predefined SQL statements are attached to the SAP Note 1969700 . Y ou can copy and execute the statements contained in the text files in the SAP HANA Database Explorer or the SAP HANA studio:
<!-- image -->
<!-- image -->
In the SAP HANA studio, go for the primary system to the System Information tab and right-click Name Import SQL Statements :
<!-- image -->
Import the SQL statements downloaded from the SAP Note and right-click on the statements, then choose
.
<!-- image -->
<!-- image -->
This will open information about system replication and the replication state for each service:
<!-- image -->
In a synchronous replication, it is interesting to compare Local log buffer write throughput (MB/s) with Log buffer shipping throughput (MB/s) . If these values differ too much, they could indicate network problems or a problem with the I/O on the secondary system.
For more information about how to interpret check results, see SAP Note 1999993 .
## 8.4 Monitoring System Replication
You can monitor system replication using different tools.
- SAP HANA cockpit
For more information, see Monitoring System Replication with the SAP HANA Cockpit and Example: Monitoring System Replication with the SAP HANA Cockpit .
- SAP HANA studio For more information, see Monitoring System Replication with the SAP HANA Studio .
- hdbnsutil
For more information, see Monitoring System Replication with hdbnsutil .
- SQL query For more information, see Monitoring System Replication with SQL query .
## Related Information
Monitoring SAP HANA System Replication with the SAP HANA Cockpit [page 175]
Example: Monitoring SAP HANA System Replication with the SAP HANA Cockpit [page 177]
Monitoring SAP HANA System Replication with the SAP HANA Studio [page 185]
Monitoring SAP HANA System Replication with hdbnsutil [page 183]
Monitoring SAP HANA System Replication with SQL query [page 186]
## 8.4.3  Monitoring SAP HANA System Replication with the SAP HANA Studio
You can monitor SAP HANA system replication using the SAP HANA studio.
You can monitor system replication in the administration editor of the primary system as follows:
- The general status is displayed on the Overview tab.
This should be All services are active and in sync .
- Detailed information is available on the Landscape System Replication tab. Here you can see the system replication status. For all services, the REPLICATION\_STATUS should be ACTIVE. Detailed information about shipped sizes and shipping times are also available. Since the secondary instance does not accept SQL connections while data replication is active, basic information about the secondary system is also shown. For more information about the meaning of the individual fields, see the M\_SERVICE\_REPLICATION system view. For more information on the system replication status, see Checking the System Replication Status .
## Related Information
Checking the SAP HANA System Replication Status [page 159] M\_SERVICE\_REPLICATION System View [page 269]
## 8.4.4  Monitoring SAP HANA System Replication with SQL query
Use SQL to directly get system replication specific information from the system views.
The M\_SYSTEM\_REPLICATION view provides general system replication relevant information about the whole system. For example, it gives information on the used replication mode, operation mode, and as which tier a system is configured.
<!-- image -->
The M\_SERVICE\_REPLICATION system view is another possibility to get system replication information. The contents of the M\_SERVICE\_REPLICATION view are collected by the statistics server every hour. Therefore, the history of the data and log replication can be viewed in the table.
<!-- image -->
## Related Information
M\_SERVICE\_REPLICATION System View [page 269] M\_SYSTEM\_REPLICATION System View [page 274] SAP HANA SQL and System Views Reference
## 8.5 System Replication Network Connection
The replication in a configured system replication uses either a public or a separate network channel between the involved data centers.
Learn in this section how to configure and monitor the system replication network connection. For detailed information about network speed chekcs with SAP HANA cockpit, see Example: Monitoring SAP HANA System Replication with the SAP HANA Cockpit .
For more information about security aspects, see also Security Aspects for SAP HANA System Replication .
For information about the distance between the data centers, network throughput, as well as data and log compression, see Network Recommendations .
## Related Information
Secure Configuration of the Network Connection [page 188]
Encryption of the Connection [page 191] Monitoring the Network Connection [page 192] Monitoring the Network Latency [page 192] Example: Monitoring SAP HANA System Replication with the SAP HANA Cockpit [page 177] Security Aspects for SAP HANA System Replication [page 251] Network Recommendations [page 27]