orkungedik/SAP-basis-dataset huggingface dataset:
## 4.1.1  Perform a Takeover with the SAP HANA Cockpit
You can perform a takeover on your secondary system using the SAP HANA cockpit.
## Prerequisites
- It is recommended to stop the primary system before starting a takeover.
##  Note
If you are performing a takeover as part of a planned downtime, you should first make sure that the primary system has been fully stopped before performing a takeover to the secondary system.
- The secondary system must be fully initialized.
- You need the operating system user to perform a takeover with the SAP HANA cockpit. For more information, see Operating System User &lt;sid&gt;adm and Connect to a Resource using Database Credentials .
- The takeover command can be executed both when the secondary system is offline or online.
## Procedure
1. On the Overview page of the secondary system meant to perform the takeover, choose the System Replication tile.
The System Replication tile opens displaying the System Replication Overview .
2. Choose Take Over on the top right.
3. To start the takeover, click Ok in the Takeover dialog.
You can also start a takeover with handshake by choosing to fully synchronize the secondary system. For more information about the takeover with handshake, see Takeover with Handshake .
4. Stop the primary system from the Overall Database Status .
## Related Information
Connect to a Resource using Database Credentials Operating System User sidadm Takeover with Handshake [page 99]
## 4.1.1.1 Example: Perform a Takeover with the SAP HANA Cockpit
Learn how to perform a takeover with the SAP HANA cockpit.
## Prerequisites
You need the operating system user to perform a takeover with the SAP HANA cockpit. For more information, see Operating System User &lt;sid&gt;adm and Connect to a Resource using Database Credentials .
## Context
This examples shows how to perform a takeover from the primary system Site A (Host Id2131) to the secondary system Site B2 (Host Id2132).
For a planned takeover (for example, within the process of a near zero downtime upgrade) stop the primary system (Site A) from the Overall Database Status tile.
<!-- image -->
On the Manage Services page, you should see that the primary system (Site A) was stopped.
<!-- image -->
## Procedure
1. Choose the system replication tile on the secondary system's (Site B2) overview page.
<!-- image -->
The System Replication Overview opens.
2. Choose Take Over on the top right.
<!-- image -->
You can also choose to start a takeover with handshake. For more information, see Takeover with Handshake .
After the takeover is finished, this system is not functioning as a secondary system anymore. It becomes the new primary.
## 4.1.2  Perform a Takeover with hdbnsutil
You can perform a takeover on your secondary system with the hdbnsutil command line tool.
## Prerequisites
You can check this in M\_SERVICE\_REPLICATION or in the SAP HANA studio Administration Console Landscape System Replication . The secondary system is ready for takeover if all services display
- The secondary system must be fully initialized. REPLICATION\_STATUS ACTIVE .
- The takeover command can be executed both when the secondary system is offline or online.
##  Note
If you are performing a takeover as part of a planned downtime, you should first make sure that the primary system has been fully stopped before performing a takeover to the secondary system.
## Procedure
As &lt;sid&gt; adm enter the following command on the secondary system to enable the secondary system to take over and become the primary system:
```
cd /usr/sap/<sid>/HDB<instancenr>/exe ./hdbnsutil -sr_takeover [--comment="Your Comment"]
```
Use the --comment to add a reason for the takeover (for example, to distinguish between a planned or unplanned takeover). This comment is displayed in the M\_SYSTEM\_REPLICATION\_TAKEOVER\_HISTORY monitoring view in the COMMENTS column.
If the system is offline, the takeover is actually carried out when the system is started again.
## Related Information
Stop a System
```
Monitoring SAP HANA Systems During Stop and Start M_SERVICE_REPLICATION System View [page 269] M_SYSTEM_REPLICATION_TAKEOVER_HISTORY System View [page 279]
```
## 4.1.3  Perform a Takeover with the SAP HANA Studio
You can perform a takeover on your secondary system using the SAP HANA studio.
## Prerequisites
- The secondary system must be fully initialized.
- The takeover command can be executed both when the secondary system is offline or online.
- You are logged on to the secondary system as the operating system user (user &lt;sid&gt;adm) or can enter these credentials when prompted.
##  Note
If you are performing a takeover as part of a planned downtime, you should first make sure that the primary system has been fully stopped before performing a takeover to the secondary system.
## Procedure
1. In the Systems view, right-click the secondary system and choose Configuration and Monitoring Configure System Replication .
2. Choose Perform Takeover from the actions list.
3. Enter the required system information and choose Next .
4. Review the information and choose Finish .
## Results
The secondary system is now the production system. If the system is already running, it comes out of recovery mode and becomes fully operational immediately: it replays the last transaction logs and starts to accept queries. If the system is offline, it takes over production operation when you start it.
## 4.1.5  Invisible Takeover and Restart
During an invisible takeover or a restart, the session's state needs to be recovered and restored to the new primary system.
During a standard takeover you switch your active system from the current primary system to the secondary system. After a standard takeover, the primary system loses all connections to the client. Moreover, the secondary system is not aware of the previous connections, which existed between the client and the primary system. This is different in an invisible takeover.
You can perform an invisible takeover to achieve an automatic recovery of your sessions after takeover to your new primary system. For dedicated client applications this takeover will be invisible. Differently from a standard takeover, an invisible takeover ensures that the client reconnects to the primary system and the sessions are restored to the secondary system.
This seamless recovery is possible also when restarting the system (for example, after a system crashes).
The session's state needs to be recovered and restored to the new primary system in an invisible takeover scenario or to the new system in a restart scenario. The cross-layer between the session and the client library makes the seamless recovery possible. This cross-layer feature called transparent session recovery recovers the current session's state and the physical connection.
##  Note
The transparent session recovery is supported by SQLDBC for SAP HANA 2.0.
Use the graphic below to better understand this process in an invisible takeover or a restart scenario after the active system crashed:
<!-- image -->
## Configuration
The enable\_session\_recovery parameter in the session section of the ini file controls the session recovery. The default value is true recovering all session variables and restoring the client connections from the primary system to the secondary system. This parameter is configurable online, but the changes can be applied only to the connections established after making the changes.
## Limitations
- Sessions which have created or updated a global temporary table with any DDL or DML commands won't be recovered. However, sessions which have created a local temporary table will be recovered without the table recovery.
- Ongoing write transaction will be rolled back with an error and the session can be recovered when an application restarts the failed transaction with no explicit reconnect trial from the application
- Almost all session variables from the current session context are recovered.
- When a response for a request is not successfully sent from the client to the server, the session is not recovered. However, sessions are still recovered when a SQL command is not sent from the client to the server.
## 4.1.6  Takeover with Handshake
The takeover with handshake ensures that all the sent redo log is written to disk on the secondary system.
During a planned takeover, it is important to ensure that no data gets lost (all primary updates must be available on the secondary system) and the former primary system is isolated to avoid a split-brain situation with multiple active primary systems.
The takeover with handshake is ideal for a safe planned takeover while the primary is still running. All new writing transactions on the primary system are suspended and the takeover is only executed when all redo log is available on the secondary system. When performing a takeover with handshake, it is not needed to check the replication status or to stop the old primary before the takeover.
In a nutshell, a takeover with handshake avoids:
- Data loss, because the log is available on the secondary system before the takeover is triggered.
- Split-brain situations, because the former primary will be suspended.
##  Note
The takeover with handshake will only be performed if the two previously mentioned conditions are guaranteed. Otherwise, the takeover will be aborted and the primary resumed.
Trigger a takeover with handshake using hdbnsutil -sr\_takeover --suspendPrimary on the secondary system.
If a primary service cannot be accessed or a service replication is not active or in sync, the takeover will be aborted and reported as an error. In this case, there is no impact on the system and the replication remains as it was. The suspended primary can be unblocked using the -sr\_register hdnsutil command.
##  Note
The following limitations apply:
- It is supported only on the second tier.
- It is not supported with Dynamic Tiering services.
## Related Information
Use SAP HANA System Replication for Near Zero Downtime Upgrades [page 199]
## 4.2 Failback
The failback process is the name for the task of registering the former primary system as a new secondary when it becomes available again.
After a takeover has been carried out, the roles between primary and secondary can be switched over. In the case of a failback, the former primary has to be registered as the secondary with the now active primary system. The roles are switched compared to the original setup.
This is the same procedure as for setting up a normal secondary described in Configuring SAP HANA System Replication . However, in this scenario when the new secondary is registered with the new primary, it checks if a delta shipping is possible to resync the two sites rather than carrying out a full data shipping. If a delta shipping is possible, it only ships the delta, which significantly reduces the initialization time during registration of the new secondary. When the new secondary starts, it checks first if there is a local snapshot available from the time when the system was the primary system. If a snapshot is available, the system then checks if it is compatible with the new primary. When both checks are positive, the new secondary can be initialized with a delta replica from the new primary.
You can perform a failback using the following tools:
- ●
- SAP HANA cockpit For more information, see Perform a Failback with the SAP HANA Cockpit .
- hdbnsutil For more information, see Perform a Failback with hdbnsutil .
- SAP HANA studio For more information, see Perform a Failback with the SAP HANA Studio
## Related Information
Perform a Failback with the SAP HANA Cockpit [page 101] Example: Perform a Failback with the SAP HANA Cockpit [page 102] Perform a Failback with the SAP HANA Studio [page 104] Perform a Failback with hdbnsutil [page 105] Virtual IP Address Handling [page 125]
.
## 4.2.1  Perform a Failback with the SAP HANA Cockpit
To perform a failback in the SAP HANA cockpit, register the former primary system as secondary to the current primary.
## Prerequisites
- You need the operating system user to perform a failback with the SAP HANA cockpit. For more information, see Operating System User &lt;sid&gt;adm and Connect to a Resource using Database Credentials .
- The former primary system is not running.
- The current primary system is running.
## Context
In the SAP HANA cockpit you can perform a failback either from the current primary system or from the former primary system (this is the future secondary). The configuration steps are the same as described in Configure System Replication from the Primary System or Configure System Replication from the Primary and the Secondary System .
This procedure describes how to register the former primary as a new secondary. Use the System Replication card on the System Overview page of the former stopped primary to register this system as a new secondary.
## Procedure
1. Register the secondary system as follows:
- a. On the System Overview page of the former primary system, choose the System Replication tile. The System Replication page opens.
- b. Choose Register as Secondary on the top right.
The Register Secondary System page opens.
- c. On the Register Secondary System page enter the logical name used to represent the secondary system.
- d. Select a replication mode. For more information on the available replication modes, see Replication Modes for SAP HANA System Replication .
- e. Select an operation mode. For more information on the available operation modes, see Operation Modes for SAP HANA System Replication .
- f. Enter the host of the source system.
##  Note
If you are operating a distributed system on multiple hosts, enter the name of the host on which the master name server is running.
- g. Check Start Secondary after Registration .
2. Review the configured information and choose Configure on the bottom right.
## Results
The original primary system is now registered as the secondary system with the current primary system (that is, the original secondary system). The secondary system is getting in sync again with the primary system. As such, it is attempting to avoid a full data shipping.
Verify that the secondary system replication status is All services are active and in sync .
## Related Information
Perform a Failback with the SAP HANA Cockpit [page 101]
Configure SAP HANA System Replication from the Primary and the Secondary Systems [page 45]
Replication Modes for SAP HANA System Replication [page 12]
Operation Modes for SAP HANA System Replication [page 14]
Connect to a Resource using Database Credentials
Operating System User sidadm
## 4.2.1.1 Example: Perform a Failback with the SAP HANA Cockpit
Learn how to perform a failback with the SAP HANA cockpit.
## Prerequisites
You need the operating system user to perform a failback with the SAP HANA cockpit. For more information, see Operating System User &lt;sid&gt;adm and Connect to a Resource using Database Credentials .
## Context
This example shows how to perform a failback by registering the former primary (Site A) as a secondary system to the new primary (Site B2).
## Procedure
1. Choose the system replication tile of the stopped primary system (Site A) and choose Register as Secondary on the overview page.
<!-- image -->
This will register the primary system (Site A) as a secondary system.
2. On the configuration page, add the name of the former primary system (Site A), the replication and operation modes, as well as the master host name of the former secondary system (Id2132). Finally, choose Configure .
The configuration can look like this:
<!-- image -->
After the configuration is completed, the roles switch: the former primary (Site A) runs as a secondary system to the new primary (Site B2). This new primary (Site B2) is the former secondary system. You can verify the switch on the overview page.
<!-- image -->
## 4.2.2  Perform a Failback with the SAP HANA Studio
You can perform a failback using the SAP HANA studio.
## Prerequisites
- You are logged on to both systems as the operating system user (user &lt;sid&gt;adm) or are able to enter these credentials when prompted.
- The former primary system is not running.
- The current primary system is running.
## Context
To fail back, you must attach your former primary system as new secondary system to the current primary system.
## Procedure
1. Register the former primary system as the new secondary system as follows:
- a. In the Systems view, right-click the primary system and choose Configuration and Monitoring
Configure System Replication . The Configure System Replication dialog opens.
##  Note
You can also access the Configure System Replication dialog from the Landscape System Replication tab.
- b. Choose Register Secondary System and then Next .
- c. Enter the required system information and the logical name used to represent the 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.
- d. Specify the log replication mode. For more information on the available replication modes, see Replication Modes for SAP HANA System Replication .
- e. Specify the operation mode. For more information on the available operation modes, see Operation Modes for SAP HANA System Replication .
- f. Review the configured information and choose Finish .
- g. If necessary, start the former primary system.
##  Note
The former primary system is started automatically unless you deselected the corresponding option during configuration.
The former primary system is now registered as the secondary system with the current primary system (that is, the former secondary system). As the data that is already available in the former primary system cannot be reused, a complete initialization is carried out. This means that a full data replication takes place until the former primary system is fully in sync.
2. Verify that the secondary system replication status is All services are active and in sync . You can see this status in the Administration editor on the Overview tab.
## Results
The former primary system and the former secondary system switched their roles.
## Related Information
Configuring SAP HANA System Replication [page 38]
Replication Modes for SAP HANA System Replication [page 12] Operation Modes for SAP HANA System Replication [page 14]
## 4.2.3  Perform a Failback with hdbnsutil
You can perform a failback using the hdbnsutil command line tool.
## Prerequisites
- You need the operating system user to perform a failback. For more information, see Operating System User &lt;sid&gt;adm .
- The former primary system is not running.
- The current primary system is running.
## Context
This is the same procedure as is used for setting up a normal secondary described in Configure SAP HANA System Replication with hdbnsutil . T o fail back, attach your original primary system as new secondary system to the current primary system. .
## Procedure
When the former primary is available again and offline, it can be registered as the new secondary:
```
hdbnsutil -sr_register --remoteHost=<new primary hostname> --remoteInstance=<instance number> --replicationMode=<sync/syncmem/async> --operationMode=<delta_datashipping|logreplay|logreplay_readaccess> --name=<siteName>
```
## Related Information
Operating System User sidadm Configure SAP HANA System Replication with hdbnsutil [page 51]
## 5 SAP HANA System Replication: Secondary Time Travel
Learn how to quickly access again data, which was deleted in the original system.
Secondary time travel allows you to start the secondary system or the log replay at a previous point in time.
## Related Information
Secondary Time Travel [page 107]
Execute Secondary Time Travel [page 108] Execute Secondary Time Travel While Replication Continues [page 109] Configuration Parameters [page 110] Monitoring Secondary Time Travel [page 112]
## 5.1 Secondary Time Travel
You can start the secondary system or the log replay at a previous point in time.
Secondary time travel can be used:
- To quickly access again data, which was deleted in the original system. For more information, see Execute Secondary Time Travel .
- To intentionally keep the secondary system's log replay delayed. This can be used to read older data from the secondary system, while the secondary keeps replicating. For more information, see Execute Secondary Time Travel While Replication Continues .
To prepare the secondary system for time travel, snapshots are kept on the secondary system for a defined time travel period. These snapshots can be used later to start the system at an older point in time. Additional log will be retained on the secondary system starting from the oldest time travel snapshot. After opening the old snapshot, the additional log has to be replayed to reach the requested point in time.
##  Note
You can use secondary time travel only with the operation modes logreplay or
. Configuring the SYNC replication mode with the full sync option, does not lead logreplay\_readaccess to a freeze of the primary system upon secondary time travel.
To prepare the system for time travel, the global.ini/[system\_replication]/
timetravel\_max\_retention\_time parameter must be configured on the secondary system. This parameter defines the time period to which the secondary system can be brought back in the past. Optionally,
the global.ini/[system\_replication]/timetravel\_snapshot\_creation\_interval parameter can be adapted to adjust the secondary's snapshot creation. After setting these parameters, the secondary starts retaining log and keeping created snapshots.
## Related Information
Execute Secondary Time Travel [page 108]
```
Configuration Parameters [page 110] Execute Secondary Time Travel While Replication Continues [page 109] Monitoring Secondary Time Travel [page 112]
```
## 5.2 Execute Secondary Time Travel
You can start the secondary system in online mode at a previous point in time to access again data, which was deleted in the original system.
## Prerequisites
- Set the requiered parameters to define the point in time to which the secondary system can be brought back in the past. For a full list of available parameters for secondary time travel, see Configuration Parameters .
##  Note
Set the parameters carefully to avoid log full or disk full situations. For time travel to work, log and snapshots are kept online in the data area. Because of this, log and data will grow on the secondary system when time travel is turned on. The system workload determines how much data is needed.
- Use the logreplay or the logreplay\_readaccess operation mode in your system replication setup.
## Procedure
1. Stop the secondary system.
2. Execute hdbnsutil -sr\_timetravel --startTime=&lt;startTime&gt; [--callTakeoverHooks=on| off] [--comment="Your Comment"]
For startTime use the following format specified in UTC: dd.mm.yyyy - hh.mm.ss
You can specify if takeover hooks should be called. If the timetravel\_call\_takeover\_hooks parameter is not explicitly specified, takeover hooks won't be called. For more information on takeover hooks, see Implementing a HA/DR Provider .
Use the --comment to add a reason for the time travel. This comment is displayed in the M\_SYSTEM\_REPLICATION\_TAKEOVER\_HISTORY monitoring view in the COMMENTS column.
3. Start the secondary system.
The secondary system will enter in online mode at the specified point in time during restart. After restart, the other services read the requested point in time and open their persistence using this information. If the requested point in time cannot be reached, then time travel will be aborted. A check ensures that there are time travel snapshots older than the start time for each service.
## Related Information
Configuration Parameters [page 110] M\_SYSTEM\_REPLICATION\_TAKEOVER\_HISTORY System View [page 279] Implementing a HA/DR Provider
## 5.3 Execute Secondary Time Travel While Replication Continues
You can start the log replay at a previous point in time to read older data from the secondary system, while the secondary keeps replicating.
## Prerequisites
- Set the required parameters to define the point in time to which the secondary system can be brought back in the past. For a full list of available parameters for secondary time travel, see Configuration Parameters .
##  Note
Set the parameters carefully to avoid log full or disk full situations. For time travel to work, log and snapshots are kept online in the data area. Because of this, log and data will grow on the secondary system when time travel is turned on. The system workload determines how much data is needed.
- Use the logreplay or logreplay\_readaccess operation modes.
## Procedure
1. Stop the secondary system.
2. Execute hdbnsutil -sr\_timetravel --startTime=&lt;startTime&gt; --startMode=replicate
For startTime use the following format specified in UTC: dd.mm.yyyy - hh.mm.ss
3. Start the secondary system.
After the system has started, the persistence has been opened on the specified point in time, it is replicating log, and log replay is not running.
4. Optional: Trigger the log replay manually with hdbnsutil -sr\_recoveruntil {--endTime=&lt;timestamp&gt;|max} [--nowait]
For &lt;timestamp&gt; use the following format specified in UTC: dd.mm.yyyy - hh.mm.ss
Use max to trigger the log replay up to the newest possible point in time. In this case, the target timestamp is automatically determined by checking the valid time travel range for each service.
Use --nowait to specify if the command should be executed asynchronously.
5. Optional: Stop the manual replay mode by setting the timetravel\_logreplay\_mode parameter back to auto or using hdbnsutil -sr\_replaymode --mode={auto|manual}
## Related Information
Configuration Parameters [page 110]
## 5.5 Monitoring Secondary Time Travel
You can monitor the retaining log and the created snapshots.
To monitor secondary time travel, the secondary system must be online. The current time travel range cannot be determined, when the secondary is offline.
You can determine the valid range for which time travel can be executed in two ways:
- Using hdbnsutil -sr\_timetravel --printRange This command provides a range for each service in which time travel can be executed:
- Using SQL on the primary system via the \_SYS\_DATABASES\_SR\_SITE\_&lt;sitename&gt;.M\_SYSTEM\_REPLICATION\_TIMETRAVEL secondary proxy view.
| Value      | Description                                                                                                                                                                                                                                                                                                                                                                  |
|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| START_TIME | Contains the oldest possible point in time for which timetravel can be executed. As time travel is done for all services, the intersection of all ranges have to be checked to make sure, all services can reach the specified timestamp.                                                                                                                                    |
| END_TIME   | Contains the last possible point in time for which timetravel can be executed. For slave services, this timestamp can be some time back without being outdated, if there was no more activity on this slave for some time. To ignore the slave volumes, only the lines for transaction master can be considered. Those are marked as MASTER in the COORDINA­ TOR_TYPE column. |
The start time or the log position of the system can be monitored using M\_SYSTEM\_REPLICATION\_TAKEOVER\_HISTORY.
## 6 SAP HANA System Replication with Active/Active (Read Enabled)
Active/Active (read enabled) enables SAP HANA system replication to support read access on the secondary system.
## What can I learn about Active/Active (Read Enabled) in this section?
After checking all the necessary prerequisites, learn how to configure and monitor an Active/Active (read enabled) system replication. This chapter also provides information about memory management, virtual IP address handling, and authentication methods.
## Where can I find more information?
The following SAP Notes are relevant for Active/Active (Read Enabled):
SAP Notes
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
|   SAP Note | Title                                                            |
|------------|------------------------------------------------------------------|
|    2447994 | SAP HANADynamic Tiering Support for SAP HANASystem Replication   |
|    1681092 | Multiple SAP HANADBMSs(SIDs) on one SAP HANAsystem               |
|    2116157 | FAQ: SAP HANAConsistency Checks and Corruptions                  |
|    2391079 | Access restrictions in Active/Active (read enabled) system setup |
## Related Information
Active/Active (Read Enabled) System Replication [page 114]
Generic Conditions for Active/Active (Read Enabled) [page 116]
Connection Types [page 119]
Configuring an Active/Active (Read Enabled) System Replication [page 117]
Memory Management [page 124]
Virtual IP Address Handling [page 125]
Authentication Methods [page 126]
Monitoring Active/Active (Read Enabled) [page 127]
## 6.1 Active/Active (Read Enabled) System Replication
Active/Active (read enabled) enables SAP HANA system replication to support read access on the secondary system and is supported by all client APIs.
## Active/Active (Read Enabled)
Active/Active (read enabled) reduces the load on the primary system but does not double the capacity; it simply extends read capabilities. In an Active/Active (read enabled) system replication configuration, the SQL ports on the secondary system are open for read access. This makes it possible to use the secondary system for read-intense tasks and to have a better balance of workloads improving the overall performance of the SAP HANA database.
##  Note
In case of an outage, all functions concentrate on the secondary system. Because of this, the sizing of the secondary system is important to ensure the right performance in disaster scenarios.
Active/Active (read enabled) is integrated into the SAP HANA system replication solution and gets activated with the operation mode logreplay\_readaccess . This operation mode provides fast takeovers, reduced need for bandwidth in continuous operation, and support for replication modes such as SYNC (with or without the full sync option), SYNCMEM, and ASYNC. The redo log replay runs asynchronously to the primary operations.
##  Note
To use the logreplay\_readaccess operation mode, the primary and the secondary systems must have the same SAP HANA version. For this reason, read-only access to the secondary system is not possible during a rolling upgrade until both versions are the same again.
The following graphic focuses on the Active/Active (read enabled) configuration. The primary system is fully active and supports reading and writing, while the secondary system is enabled for read queries.For a detailed illustration of the general system replication processes, see Introduction .
<!-- image -->
In a multitier setup, read access on the secondary is only supported for tier 2. In a 3-tier system using Active/ Active (read enabled), the logreplay\_readaccess mode is required between the primary and the active secondary systems, while the logreplay mode is required between the other (tier 2 and tier 3) secondary systems. In a multitarget setup, multiple secondary systems with logreplay\_readaccess are supported.
## License Management
In an Active/Active (read enabled) configuration, the secondary system is operated automatically with the license key of the primary system. Changes of the license key are done on the primary system and replicated to the secondary system. For more information, see Managing SAP HANA Licenses .
## Related Information
## Introduction [page 9]
Configuring SAP HANA System Replication
Operation Modes for SAP HANA System Replication [page 14] Client Support for Active/Active (Read Enabled) SAP HANA SQL Reference Managing SAP HANA Licenses https:/ /www.youtube.com/embed/ZRtVkuLuLuM SAP Note 2391079
## 6.2 Generic Conditions for Active/Active (Read Enabled)
When using the secondary system for read access, several aspects need to be considered.
## Points to Consider
- The processors in the primary and secondary systems must be both either Intel-based or IBM Powerbased with the same byte ordering. A platform mixture is not supported.
- The secondary system allows read access if the primary system runs the same SAP HANA version. A different version leads to prohibiting the read access until the same software version is used.
- The redo log replay runs as an asynchronous process on the secondary system. The secondary system provides statement level snapshot isolation with potentially delayed view on the data and no minimum delay guarantee.
- The secondary system gets its own virtual IP addresses or host names representing the secondary function.
- The query execution in the secondary system is rejected if it needs background migrations requiring redo log writes (e.g. L2-Delta migration).
##  Recommendation
Perform the migration in the primary system (for example, load table) and wait until it is replicated and replayed in the secondary system.
- Internal processes for operations like ColumnStore delta merges take place on the secondary system.
- DML execution on an Active/Active (read enabled) secondary system is possible for row store no-logging retention tables and global temporary tables. Their Explain Plan is also available on the secondary system. For more information, see Data Manipulation Statements .
## Limitations
- Active/Active (read enabled) is supported in a multitier SAP HANA replication system. However, read access is limited to tier 2. The logreplay operation mode is required between tier 2 and the further tier level and no read access connections can be opened to the further tier level.
- If Active/Active (read enabled) is used with Dynamic Tiering services, there is no read access to Dynamic Tiering data on the secondary system.
- The export of tables is possible with CSV as target. However, binary exports on the secondary system are not supported.
- The use of workload classes is not supported on the secondary system.
## Support for Multiple SAP HANA Databases
It is possible to use the read-enabled secondary system for other SAP HANA systems such as development or QA environments. In this case the following sizing conditions apply:
- The secondary hardware must offer the same CPU and memory capacities as those offered by the primary system plus the resources for the additional system.
- After a takeover, the system must be capable of handling both the primary's writing load and the secondary's reporting load.
For more information about this scenario, see also SAP Note 1681092 Multiple SAP HANA DBMSs (SIDs) on one SAP HANA system .
## Related Information
<!-- image -->
<!-- image -->
Data Manipulation Statements
SAP Note 1681092
SAP Note 2447994
## 6.3 Configuring an Active/Active (Read Enabled) System Replication
Active/Active (read enabled) is integrated into the SAP HANA system replication solution and gets activated with the operation mode logreplay\_readaccess .
To configure an Active/Active (read enabled) system replication, follow the procedure described for configuring system replication and select the operation mode logreplay\_readaccess .
For more information about checking the Active/Active (read enabled) configuration, see Check the Active/ Active (Read Enabled) Configuration .
## Related Information
## Configuration Parameters [page 118]
## 6.3.1  Configuration Parameters
Several parameters are available for configuring Active/Active (read enabled).
| Parameter:   | operation_mode                                                                                                                                                                                                                                                                                                                                                                                      |
|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Values:      | logreplay_readaccess                                                                                                                                                                                                                                                                                                                                                                                |
| System:      | Secondary                                                                                                                                                                                                                                                                                                                                                                                           |
| Description: | System Replication uses an initial data shipping to initialize the secondary system. After that, only log ship­ ping is done and the log buffers received by the secondary system are being replayed there. Savepoints are executed individually for each service. Column table merges are executed on the secondary system. Addi­ tionally, read access via SQL is provided to the secondary system. |
Relevant for Active/Active (read enabled) are also logshipping\_max\_retention\_size Replication Configuration Parameters .
## Related Information
SAP HANA System Replication Configuration Parameters [page 62]
## 6.3.2  Checking the Active/Active (Read Enabled) Configuration
You can check if your system replication is configured as an Active/Active (read enabled) system.
## SAP HANA Cockpit
On the System Replication tile on the primary system, the logreplay\_readaccess operation mode indicates that your system is an Active/Active (read enabled) system. Additionally, an enabled secondary read access informs you that the SQL ports are open for reading on the Active/Active (read enabled) secondary system.
enable\_log\_retention and . For more information about these parameters, see SAP HANA System
On the system overview page of the secondary system, the Mode: read-only indicates that your system is an Active/Active (read enabled) system. Additionally, the Delay in ms is shown on top indicating how far behind is the consistent view on the data of this secondary system compared to the current data of the primary system.
For examples and more information, see System Replication Tile and Example: Monitoring SAP HANA System Replication with SAP HANA Cockpit .
## SAP HANA Studio
On the primary system, select M\_SYSTEM\_REPLICATION from the monitoring view. To find out if your system is an Active/Active (read enabled) system, verify the columns OPERATION\_MODE and SECONDARY\_READ\_ACCESS\_STATUS .
## Command Line
As &lt;sid&gt;adm run one of the following commands and then look for the operation mode logreplay\_readaccess :
```
python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py -sapcontrol=1 | grep OPERATION_MODE service/ld4144/30207/OPERATION_MODE=logreplay_readaccess service/ld4144/30201/OPERATION_MODE=logreplay_readaccess service/ld4144/30203/OPERATION_MODE=logreplay_readaccess
```
or
```
hdbnsutil -sr_state | grep "operation mode" operation mode: logreplay_readaccess
```
## Related Information
System Replication Tile [page 40]
Example: Monitoring SAP HANA System Replication with the SAP HANA Cockpit [page 177]
## 6.4 Connection Types
Connecting to an Active/Active (read enabled) system allows you to take advantage of a secondary system for better overall performance.
There are two ways to access the read-enabled secondary system::
- Opening an explicit connection to the secondary system
- Executing a SQL statement on the primary system which is redirected to the secondary system according to a hint
## Explicit read-only connection to the secondary system
The application opens an explicit connection to the secondary system. There is no session property sharing.
The following graphic illustrates an explicit read-only connection to the secondary system:
<!-- image -->
## Implicit hint-based statement routing
The application connects directly to the primary system. On this connection, SQL statements with system replication­specific hints are prepared and executed. They are then automatically routed to and executed by the secondary system. For more information about hints, see the SAP HANA SQL and System Views Reference Guide .
##  Note
Hint-based statement routing is supported by SAP HANA ODBC, SQLDBC, ADO.Net, JDBC drivers for SAP HANA 2.0 and the SAP HANA Node.js.
The SAP HANA client opens an additional connection to the secondary system according to the host information returned by the primary system.
This connection type unfolds as follows:
1. The SAP HANA client sends the statement-prepare with hint to the primary system.
2. The primary system decides where to execute the statement and returns the result to the SAP HANA client.
3. The SAP HANA client sends the statement execution call to the secondary system. The session property changes are handed over to the secondary system via the SAP HANA client. If the secondary system cannot execute the statement, it returns an error and the SAP HANA client sends the statement to the primary system.
The following graphic illustrates an implicit hint-based statement routing:
<!-- image -->
For more information about hint-based statement routing, see Hint-Based Routing for Active/Active (Read Enabled) .
To cancel long-running sessions on a read enabled secondary system, use: ALTER SYSTEM CANCEL SESSION .
## Limitations:
- The SAP HANA client has an open working connection to the primary system.
- Hint-based statement routing is not supported for CALL procedures.
- Temporary tables are not supported.
- Hint-based statement routing is not supported for write transactions.
## Related Information
SAP HANA SQL and System Views Reference
Client Requirements For A Takeover [page 122] Hint-Based Statement Routing for Active/Active (Read Enabled) [page 123] Client Support for Active/Active (Read Enabled)
## 6.4.1  Client Requirements For A Takeover
Configure the client connection so that the client connects to the correct system after failover occurs.
Failover is when a secondary system takes over from a primary system that is offline. Use the following configuration to ensure that the client connects to the correct system when a failover occurs.
- If you are using connection distribution, then you must use the siteType connection property to specify whether the connection is made to the PRIMARY or SECONDARY system. The siteType connection property is required because connection distribution adds server locations from cached topology, which may be out of date because it contains data from before the takeover occurred.
- If you are not using connection distribution, then specify one or more virtual IP addresses (if available) that always point to the desired type of system. For example, if you are connecting to the primary system, then these virtual IP addresses must map to the new primary system (the old secondary system that took over as the primary system) after a failover so that the client can reliably connect to the correct system.
- If you are not using connection distribution and there are no virtual IP addresses, then you must use the siteType connection property to specify whether the connection is made to the PRIMARY or SECONDARY system. To reliably connect both before and after a failover, you must specify one or more locations for both systems (the system that was initially the primary and the system that was initially the secondary). For example, to connect to the current primary system using an ODBC-style connection string, use siteType=PRIMARY;serverNode=&lt;site1host&gt;:&lt;port&gt;,&lt;site2host&gt;:&lt;port&gt; , where &lt;site1host&gt; : &lt;port&gt; is a location for the site that was initially the primary system, and &lt;site2host&gt; : &lt;port&gt; is a location for the site that was initially the secondary system.
Failure to follow these guidelines can result in connecting to the wrong system after a failover (for example, connecting to the secondary system instead of the primary system).
## Related Information
Client Connection Recovery After Takeover [page 92] Virtual IP Address Handling [page 125]
## 6.4.2  Hint-Based Statement Routing for Active/Active (Read Enabled)
Connections to a primary system can use hint-based statement routing statement execution to a secondary system on a per-statement basis. This reduces the load on the primary system and increases overall performance.
To indicate that a statement should be hint-based routed to the secondary system, add the hint text WITH HINT(RESULT\_LAG('hana\_sr')) to the end of the SQL SELECT statement. For example:
```
SELECT C1, C2 FROM T1 WHERE C3 = 'constant value' WITH HINT(RESULT_LAG('hana_sr'))
```
Queries that are executed directly (not prepared) are not hint-based routed even if they contain a hint. To take advantage of hint-based statement routing, there must be separate prepare and execute operations at the SQLDBC or JDBC level. In some cases, applications or interfaces that use SQLDBC or JDBC (such as SAP HANA Studio, SAP HANA Cockpit, ABAP, or PyDBAPI) can perform a separate prepare and execute without the user's knowledge.
## Routing Conditions
In the following cases, the execution transparently falls back to the primary system, even if the statement contains a hint to route to the secondary system:
- The connection's isolation level is set to repeatable read or serializable.
- Connection to the secondary system is not possible (for example, there is a secondary system outage, a networking issue, and so on).
- The connection currently has a write transaction (uncommitted insert, update, or delete) in progress.
- The query references temporary tables.
If the routed connection is dropped while fetching from a hint-routed query result set, an error may be returned to the application.
##  Note
Hint-based statement routing is only applied to SELECT statements.
## Fallback Routing
In the following cases, a statement that has been routed to the secondary system gets re-routed to the primary system:
- The hint contains a maximum delay time parameter and the secondary system is delayed by more than that amount.
- The secondary system is near its maximum memory usage.
- The statement prepared in the primary system does not detect any access to the Dynamic Tiering data, but the statement execution in the secondary system requires Dynamic Tiering data.
## Timeout
If the previous hint-based routed statement execution falls back to the primary system due to a connection or communication error, then future hint-based statement routing does not attempt to re-connect to the secondary system for several seconds. This avoids the performance cost of retrying the connection to the secondary system frequently when it is likely to fail.
In this case, the time between reconnection attempts to the secondary system is between five seconds and five minutes from the last reconnection attempt. The time between reconnection attempts automatically increases if reconnection attempts continue to fail.
In a multitier system replication system, hint-based statement routing always routes from the primary to the secondary system.
## Related Information
HINT Details Connection Types [page 119]