orkungedik/SAP-basis-dataset huggingface dataset:
## 8.5.2  Encryption of the Connection
The system replication connections for data, redo log, and metadata of the nameserver are secured with SSL by systemPKI without the need to switch on SSL for the internal communication.
All system replication connections are specified only by the setting
[system\_replication\_communication]/enable\_ssl . This simplifies security settings for system replication.
##  Note
Before upgrading SAP HANA from a previous version to HANA 2.0 SPS02 or higher using near zero downtime upgrade (NZDU), see SAP Note 2494079: Near-Zero-Downtime-Upgrade to HANA 2 SPS02 or above when internal communication SSL is used .
SAP HANA System Replication supports secure network communication (SSL) for data and log shipping to the secondary system. The following settings can be configured in the global.ini file:
```
global.ini/[system_replication_communication] Parameter: enable_ssl Values: off:     ssl is disabled for source and target replication channels (default) on:      ssl is enabled for source and target replication channels source:  ssl is enabled as source replication channel only target:  ssl is enabled as target replication channel only
```
In this context, the 4xx06 port was added in system replication communication covering encrypted metadata communication of the nameserver. The following ports are available:
| TCP Port      | Service      | Used For                                               |
|---------------|--------------|--------------------------------------------------------|
| 4xx01         | nameserver   | Log and data shipping (System DB)                      |
| 4xx02         | nameserver   | Metadata communication (System DB) - unencrypted       |
| 4xx06         | nameserver   | Metadata communication (System DB) - encrypted via SSL |
| 4xx40 - 4xx97 | indexserver  | Log and data shipping (tenant DBs)                     |
| 4xx40 - 4xx97 | scriptserver | Log and data shipping (optional, tenant DBs)           |
| 4xx40 - 4xx97 | docstore     | Log and data shipping (optional, tenant DBs)           |
## Related Information
Security Aspects for SAP HANA System Replication [page 251]
SAP Note 2494079
## 8.5.3  Monitoring the Network Connection
You can monitor the network connection using alerts or the HDB console.
The connection between the primary and the secondary system must be available for replication. If this is not the case for a certain time, the redo log cannot be shipped to the secondary system, the log segments start piling up on the primary, and the secondary system is not ready for takeover. For more information, see Log Retention .
The alert 78 (System Replication Connection Closed) is visible in the SAP HANA cockpit, the SAP HANA studio, and in the system view M\_EVENTS to ensure that the primary system stays operational at all times, even if the connection is occasionally lost.
Additionally, the replication connection can be checked using the HDB console: hdbcons -p &lt;PID of replicating service&gt; "replication info" . The PID (process ID) of the replicating service can be obtained by using HDB proc as &lt;sid&gt; adm. For example: hdbcons -p 12345 "replication info"
The output delivers Log Connection information for the connection used by the provided service. It also shows errors, if the connection cannot be resolved properly:
```
… Log Connection - ptr : 0x00007fdb6e8e3410 - channel : NetworkChannel FD 158 [0x00007fdb6f1bbc90] {refCnt=3, idx=1} 10.68.91.226/3 0103_tcp->10.68.92.13/49537_tcp Connected,[r---] ...
```
To check, if the configured connection is actually used, use the OS command: lsof -n -p &lt;indexserverpid&gt; .
For a detailed analysis of the network connection used for system replication, see Troubleshoot System Replication and SAP Note 2081065: Troubleshooting SAP HANA Network .
## Related Information
```
Log Retention [page 20] SAP HANA System Replication Alerts [page 153] Troubleshoot System Replication [page 209] SAP Note 2081065
```
## 8.6 Copy or Move Tenants Within System Replication
You can copy or move a tenant in a SAP HANA tenant database system into or out of a primary system running in a system replication configuration.
There are three tenant copy or move scenarios that are applicable in a primary system:
## Copy or move a tenant into a primary system
A tenant database is copied or moved into the primary system of a system replication configuration.
The copied or moved tenant starts replicating after the FINALIZE command was executed.
## Copy or move a tenant from the primary system to a tenant database system (≠ secondary)
A tenant database is copied or moved out of the primary system into a target tenant database different from the secondary.
The copied or moved tenant arrives in the target tenant database system and is runnable after the FINALIZE command was executed.
## Copy or move a tenant within the primary system
A tenant database is copied or moved within the primary system of a system replication.
The 'cloned' tenant is created in the primary system and the replication starts after the FINALIZE command was executed.
## Related Information
Copying and Moving Tenant Databases SAP HANA System Replication with Tenant Databases [page 83]
## 8.7 Copying a System using System Replication
SAP HANA system replication can be used to create a copy of an SAP HANA database in a quick and simple way.
You can register another SAP HANA database in one of the two system replication scenarios:
- As a secondary for a standalone SAP HANA database
- As a tier 3 secondary in a tier 2 system replication landscape
System Replication Scenarios
| Original Setup              | Source Database   | Target Database   |
|-----------------------------|-------------------|-------------------|
| Standalone SAP HANADatabase | Primary           | Secondary         |
| Tier 2 System Replication   | Tier 2 Secondary  | Tier 3 Secondary  |
After the replication is active and in sync, a takeover to the newly added tier makes the standalone SAP HANA database runnable with identical data as the source database.
## 8.7.1  Copy a System using System Replication
You can use SAP HANA system replication to create a copy of an SAP HANA database.
## Prerequisites
- You need an SAP HANA database called source database, which is to be copied.
- You need a separate (virtual) host or more (virtual) hosts for the database copy called target database.
## Procedure
1. Install an SAP HANA database of the same or a higher revision as the target database on the separate (virtual) host or on the (virtual) hosts.
2. Prepare the source database for replication using hdbnsutil -sr\_enable [--name=&lt;siteName&gt;]
3. Register the target database either as a secondary or tier 3 secondary depending on your original setup using hdbnsutil -sr\_register --remoteHost=&lt;primary master host&gt; -remoteInstance=&lt;primary instance id&gt; --replicationMode=[sync|syncmem|async] -name=&lt;sitename&gt; --operationMode=[delta\_datashipping|logreplay]
If the parameter is given, the operation mode is set. The default operation mode is logreplay.
4. Start the newly registered target database.
5. When the system replication is active and in sync, perform a takeover on the target database.
6. After the takeover is done, the target database is running as a copy of the source database.
7. To avoid confusion with the source databases, rename the &lt;SID&gt; and change the instance number using the tool hdblcm.
## 8.8 Updating SAP HANA Systems with SAP HANA System Replication
You can update your SAP HANA systems running in a SAP HANA system replication.
If for some reason you have to stop and restart the primary or the secondary, once the systems are available they will automatically try to get in sync again. There are no manual steps necessary.
If the system is running with logreplay or logreplay\_readaccess , see Resync Optimization to prevent your system from running full or having to do a full data shipping. This can happen when the time during which the primary could not replicate gets too long. An optimized resync with delta data or log shipping can be achieved avoiding a full data shipping, depending on the the time the upgrade is taking and the settings of the logshipping\_max\_retention\_size and datashipping\_snapshot\_max\_retention\_time parameters.
You must update your SAP HANA systems running in a system replication setup by updating the secondary system first and then updating the primary system. For more information, see Update an SAP HANA System Running in a System Replication Setup .
The secondary system can run with a higher software version than the primary system. For more information, see Use SAP HANA System Replication for Near Zero Downtime Upgrades .
##  Note
System Replication with SAP HANA 2.0 requires authentication for data and log shipping channels. The authentication is done using the certificates in the system PKI SSFS store. Thus, there is an additional manual setup step required to exchange certificates in the system PKI SSFS store between the primary and the secondary system when upgrading from SAP HANA 1.0 to SAP HANA 2.0. For more information, see SAP Note 2369981 .
Hardware can also be exchanged with a minimal downtime using SAP HANA system replication. For more information, see SAP Note 1984882: Using HANA system replication for Hardware Exchange with Minimum Downtime .
## Related Information
Resync Optimization [page 19]
Configure a User Under the SRTAKEOVER Key [page 201]
Update SAP HANA Systems Running in a System Replication Setup [page 197]
Use SAP HANA System Replication for Near Zero Downtime Upgrades [page 199]
Use Multitarget System Replication for Near Zero Downtime Upgrades [page 203]
<!-- image -->
SAP Note 2369981
SAP Note 1984882
## 8.8.1  Update SAP HANA Systems Running in a System Replication Setup
You can update your SAP HANA system with active system replication by updating the secondary and the primary system one after the other.
## Prerequisites
System replication is configured and active between two SAP HANA systems.
## Context
You must update your SAP HANA system running in a system replication setup by updating the secondary system first and then updating the primary system.
##  Remember
For system replication setups it is required that the secondary system has the same version as the primary system or a higher version. As such, the secondary system must always be updated before the primary system.
##  Note
Updating one system after the other results in some downtime. If you want to update your system with reduced downtime, see Use SAP HANA System Replication for Near Zero Downtime Upgrades .
It is possible to reduce the time required to perform an update. For more information, see Prepare an Update for Flexible System Downtime .
## Procedure
1. Upgrade the SAP HANA server software and all installed components on the secondary system.
From your installation directory execute as root or as &lt;sid&gt;adm :
```
./hdblcm --action=update
```
2. With the secondary system online, use the SAP HANA lifecycle management tools to upgrade all the other components to the same revision as the server software.
3. Verify that system replication is active and that all services are in sync.
You can check that the REPLICATION\_STATUS column in M\_SERVICE\_REPLICATION has the value ACTIVE for all services.
4. Upgrade the SAP HANA server software and all installed components on the primary system.
From your installation directory, execute as root or as &lt;sid&gt;adm :
```
./hdblcm --action=update
```
5. With the secondary system online, use the SAP HANA lifecycle management tools to upgrade all other components to the same revision as the server software.
6. Verify that system replication is active and that all services are in sync.
## Related Information
Use SAP HANA System Replication for Near Zero Downtime Upgrades [page 199]
Prepare an Update for Flexible System Downtime
SAP Note 2407186
SAP Note 2599514
## 8.8.2.1 Configure a User Under the SRTAKEOVER Key
In preparation for maintenance tasks, you must configure a user in the local userstore under the SRTAKEOVER key.
## Context
The SRTAKEOVER user requires the necessary privileges to import the repository content of the new version of the software during the takeover process.
## Procedure
1. As &lt;sid&gt;adm configure a user in the local userstore under the SRTAKEOVER key. Use a public host name to access the corresponding SQL port of the System DB ( &lt;SystemDBsqlport&gt; ). Execute this command on the primary and secondary systems:
hdbuserstore SET SRTAKEOVER &lt;publichostname&gt;:&lt;SystemDBsqlport&gt; &lt;myrepouser&gt; &lt;myrepouser\_password&gt;
##  Note
This configuration step should be performed only in the system database, not in every single tenant.
2. Create a &lt;myrepouser&gt; user with the necessary privileges to import the repository content as follows:
```
CREATE USER MY_REPO_IMPORT_USER PASSWORD MyRepoUserPW123; GRANT EXECUTE ON SYS.REPOSITORY_REST TO MY_REPO_IMPORT_USER; GRANT REPO.READ ON ".REPO_PACKAGE_ROOT" TO MY_REPO_IMPORT_USER; GRANT REPO.IMPORT TO MY_REPO_IMPORT_USER; GRANT SELECT ON _SYS_REPO.DELIVERY_UNITS TO MY_REPO_IMPORT_USER; GRANT REPO.ACTIVATE_IMPORTED_OBJECTS ON ".REPO_PACKAGE_ROOT" TO MY_REPO_IMPORT_USER;
```
For example, for public host name "mypublichost" and system number "00", "MY\_REPO\_IMPORT\_USER", and "MyRepoUserPW123" :
```
hdbuserstore SET SRTAKEOVER mypublichost:30013 MY_REPO_IMPORT_USER MyRepoUserPW123
```
The host name has to be the public host name of the host on which the command is executed and the port is the SQL port number of the system database.
For more information, see the Secure User Store (hdbuserstore) section in the SAP HANA Security Guide .
##  Note
In a scale-out configuration, the command has to be executed on all hosts. If the password for the repository import user is changed, the password saved in the userstore also has to be changed.
## Related Information
Use SAP HANA System Replication for Near Zero Downtime Upgrades [page 199] Secure User Store (hdbuserstore)
## 8.8.2.2 Use Multitarget System Replication for Near Zero Downtime Upgrades
You can upgrade your SAP HANA systems running in a multitarget system replication setup.
## Prerequisites
Multitarget system replication is configured and active between identical SAP HANA systems.
## Context
We are using the following setup to exemplify the procedure:
##  Example
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.
In this setup:
- The primary system is the production system.
- The secondary system located in the same data center as the primary system will become the production system after the upgrade. Further secondary systems are located in a remote data center.
- There is no replication error.
## Procedure
1. Upgrade secondary system B in data center 1 and secondary system D in data center 2.
<!-- image -->
2. Register secondary system D in data center 2 to secondary system B in data center 1.
<!-- image -->
3. Upgrade secondary system C in data center 2. Then, register secondary system C to secondary system D in data center 2.
<!-- image -->
4. Take over on secondary system B in data center 1.
After takeover, secondary system B will be the new primary system.
<!-- image -->
5. Upgrade and register the previous primary system A to the new primary system B in data center 1.
<!-- image -->
## Related Information
SAP HANA Multitarget System Replication [page 142]
## 9 Troubleshoot System Replication
Learn how to analyze, avoid, and solve problems related to system replication.
## Which problems can I avoid or solve related to system replication?
This chapter provides information about:
- Solving I/O performance problems related to system replication
- Determining the underlying cause for replication performance problems and solving them
- Solving configuration problems during the initial SAP HANA system replication setup
- Solving sporadic network interruptions causing problems in the SAP HANA system replication mechanism
- Avoiding log full situations and recovering from them
- Solving communication problems when they occur between the replication sites
Furthermore, the chapter also provides information on how to conduct a network stress test with NIPING and gives you an overview of all SAP HANA alerts.
## Where can I find more information?
The following SAP Notes are relevant for troubleshooting system replication:
SAP Notes
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
<!-- image -->
|   SAP Note | Title                                                                                          |
|------------|------------------------------------------------------------------------------------------------|
|    1930979 | Alert: Sync/Async Read Ratio                                                                   |
|    1969700 | Collection of SQL Statements forSAPHANA                                                        |
|    1999880 | FAQ: SAP HANASystem Replication                                                                |
|    2166157 | Error: 'failed to open channel ! reason: connection refused' when setting up Disaster Recovery |
|    2083715 | Analyzing log volume full situations                                                           |
|    1227116 | Creating network traces                                                                        |
|    1679938 | Log Volume is full                                                                             |
|     500235 | Network Diagnosis with NIPING                                                                  |
## Related Information
I/O Related Root Causes and Solutions [page 210]
Analyzing I/O Throughput and Latency [page 212] Savepoint Performance [page 214] Replication Performance Problems [page 216] Setup and Initial Configuration Problems [page 221] Intermittent Connectivity Problems [page 225] LogReplay: Managing the Size of the Log File [page 227] SAP HANA System Replication Communication Problems [page 230] Stress Test with NIPING [page 231]
Reference: Alerts [page 232]
## 9.4 Intermittent Connectivity Problems
This section discusses the mitigation strategies for sporadic network interruptions causing problems in the SAP HANA System Replication mechanism.
A common intermittent error is that the log buffer is not shipped in a timely fashion from the primary to the secondary site.
## Log Shipping Timeout
## Possible Root Cause 1: Log Area Is Full on the Secondary Site
If the System Replication Mode is set to SYNC - full sync , the commits on primary are halted as nothing can be written to the log area on secondary site any longer. On the secondary site, the trace files contain the following error:
<!-- image -->
To quickly mitigate the situation, you can disable the 'full sync' option by running the following command:
```
>hdbnsutil -sr_fullsync --disable
```
Afterwards, the log area on the secondary site needs to be analyzed with regard to why the log segments are not freed up. This is usually caused by an erroneous log backup mechanism.
For further details refer to the following SAP Notes:
SAP Note 2083715 - Analyzing log volume full situations
SAP Note 1679938 - Log Volume is full
## Possible Root Cause 2: Sporadic Communication Issues on the Network Layer
For more information about how to deal with communication problems between the primary and the secondary site, see SAP HANA System Replication Communication Problems .
## Related Information
```
SAP Note 2083715 SAP Note 1679938 SAP HANA System Replication Communication Problems [page 230]
```
## 9.6 SAP HANA System Replication Communication Problems
Problems during initial setup of the system replication can be caused by incorrect configuration, incorrect hostname resolution or wrong definition of the network to be used for the communication between the replication sites.
## Context
System replication environments depend on network bandwidth and stability. In case communication problems occur between the replication sites (for example, between SITE A and SITE B), the first indication of a faulty system replication setup will arise.
## Procedure
1. Check the nameserver tracefiles.
The starting point for the troubleshooting activity are the nameserver tracefiles. The most common errors found are:
<!-- image -->
Further errors received from the remote side:
```
 Sample Code Generic stream error: getsockopt, Event=EPOLLERR - , rc=104: Connection reset by peer Generic stream error: getsockopt, Event=EPOLLERR - , rc=110: Connection timed out
```
It is important to understand that if those errors suddenly occur in a working system replication environment, they are often indicators of problems on the network layer. From an SAP HANA perspective, there is nothing that could be toggled, as it requires further analysis by a network expert. The investigation, in this case, needs to focus on the TCP traffic by recording a tcpdump in order to get a rough understanding how TCP retransmissions, out-of-order packets or lost packets are contributing to the overall network traffic. How a tcpdump is recorded is described in SAP Note 1227116 - Creating network
traces . As these errors are not generated by the SAP HANA server, please consider consulting your inhouse network experts or your hardware vendor before engaging with SAP Product Support.
2. Set the parameter sr\_dataaccess to debug.
In the DB Administration area of the SAP HANA cockpit open the Configuration of System Properties monitor. In the [trace] section of the indexserver.ini file set the parameter sr\_dataaccess = debug . This parameter enables a more detailed trace of the components involved in the system replication mechanisms. For more information about how to change parameters, see Memory Information from Logs and Traces .
## Related Information
<!-- image -->
SAP Note 1227116 Memory Information from Logs and Traces
## 9.7 Stress Test with NIPING
The SAP NIPING tool is a powerful tool which can be used to perform specific network stability tests.
## Prerequisites
You must have OS level access to the SAP HANA host and the client host.
## Procedure
Read SAP Note 500235 - Network Diagnosis with NIPING .
A stress test with SAP's NIPING tool may be performed in order to confirm the high network latency (or bandwidth exhaustion).
## Related Information
<!-- image -->
## 10 Security Aspects for SAP HANA System Replication
Learn about the secure operation and configuration of SAP HANA system replication.
## Which security aspects are addressed in this guide?
Communication between sites in a system replication scenario is always authenticated. In addition, it is possible to secure internal network communication between primary and secondary systems using TLS/SSL. You can learn how to configure TLS/SSL on communication channels between primary and secondary systems using the system public key infrastructure (PKI).
To integrate SAP HANA securely into your network environment, several general recommendations apply. Learn how to protect the channels used in a system replication scenario.
## Where can I find more information?
The following SAP Notes are relevant for a full understanding of the concepts described in this chapter:
<!-- image -->
<!-- image -->
<!-- image -->
|   SAP Notes SAP Note | Title                                                                                                                |
|----------------------|----------------------------------------------------------------------------------------------------------------------|
|              2175672 | Migration steps from manual SSL configuration for internal communication to automatic configuration using system PKI |
|              2356851 | SAP HANADynamic Tiering Support for SAP HANASystem Replication                                                       |
|              2447994 | SAP HANADynamic Tiering Support for SAP HANASystem Replication                                                       |
## Related Information
Secure Internal Communication [page 252]
Secure Internal Communication Between Sites in System Replication Scenarios [page 256]
Legacy Configuration of Secure Internal Communication [page 257]
Configure Secure Communication (TLS/SSL) Between Primary and Secondary Sites [page 259]
Communication Channels [page 261]
Network Security [page 263]
Internal Application Encryption Service [page 266]
## 10.5  Communication Channels
The network communication channels used by SAP HANA can be categorized into those used for database clients connecting to SAP HANA and those used for internal database communication. SAP recommends using encrypted communication channels where possible.
The following is an overview of the network communication channels used by SAP HANA.
To support the different SAP HANA scenarios and set-ups, SAP HANA has different types of network communication channels:
- Channels used for external access to SAP HANA functionality by end-user clients, administration clients, application servers, and for data provisioning through SQL or HTTP
- Channels used for SAP HANA internal communication within the database, between hosts in multiple-host systems, and between systems in system-replication scenarios
##  Note
SAP HANA internal communication has sometimes been unofficially referred to as TREXNet communication. However, the term TREXNet is not valid in the context of SAP HANA.
The connections between SAP HANA and external components and applications come under these categories:
- Connections for administrative purposes
- Connections for data provisioning
- Connections from database clients that access the SQL/MDX interface of the SAP HANA database
- Connections from HTTP/S clients
- Outbound connections
You can see an example of what these connections look like in the figure below. Network connections are depicted by dotted arrows. The direction of each arrow indicates which component is the initiator and which component is the listener. Administrative access to and from SAP HANA is depicted by the green dashed arrows. Port numbers are shown with a black background. The "xx" in the port numbers stands for the number of your SAP HANA instance.
The figure below shows all the network channels used by SAP HANA. For the purposes of illustration, a singlehost installation with two tenant databases is depicted. However, the connections shown apply equally to a distributed scenario.
<!-- image -->
## Connections Between SAP HANA and External Components
##  Note
Some components depicted in the figure are supported on Intel-based hardware platforms only (for example, SAP HANA Streaming Analytics). Refer to the Product Availability Matrix (PAM).
In addition, the different components of SAP HANA, as well as the hosts in a distributed scenario, communicate with each other over internal SAP HANA connections. These connections are also used in system replication scenarios for communication between a primary site and secondary site(s) to ensure high availability in the event of a data center failure.
The following figure shows an example of a distributed SAP HANA system with two active hosts and an extra standby host, both fully replicated to a secondary site to provide full disaster recovery support.
## SAP HANA Internal Connections
<!-- image -->
## Related Information
Securing Data Communication Network Administration
<!-- image -->
Product Availability Matrix
## 10.7 Internal Application Encryption Service
The internal encryption service is used internally by applications requiring data encryption.
##  Note
In the SAP HANA 1.0 documentation, the internal application encryption service was referred to as the internal data encryption service.
The internal application encryption service is used in the following contexts:
- Secure internal credential store
This service stores credentials required by SAP HANA for outbound connections. It is used, for example, when data is retrieved from remote data sources using SAP HANA smart data access. It is also used during HTTP destination calls from SAP HANA XS classic applications.
For more information, see the section on the secure internal credential store.
- Application data requiring encryption
Application developers can maintain values in the SAP HANA secure store for SAP HANA XS advanced applications or define secure stores using the SAP HANA XS classic $.security.Store API. For more information, see:
- SAP HANA XS advanced: Maintain Values in the SAP HANA Secure Store in the SAP HANA Developer Guide for SAP HANA XS Advanced Model
- SAP HANA XS classic: Using the Server-Side JavaScript APIs in the SAP HANA Developer Guide (For SAP HANA Studio) and Class:Store in the SAP HANA XS JavaScript API Reference .
- Private key store
This service stores the private keys of the SAP HANA server required for secure client-server communication, if the relevant personal security environment (PSE) is stored in the database. PSEs stored in the database are called certificate collections.
For more information, see the section on SSL configuration on the SAP HANA server and certificate management in SAP HANA.
Every consumer of the service has its own system-internal application encryption key. These keys are generated as follows:
- The application key for the internal credential store is generated randomly during the first startup.
- Application keys for XS secure stores are created at the same time as the XS secure store.
- The application key for the private key store is created when the first private key is set for a certificate collection.
Application encryption keys are encrypted with the application encryption service root key.
SAP HANA generates unique root keys on installation or database creation. However, if you received SAP HANA from a hardware or hosting partner, we recommend that you change the root key of the internal application encryption service to ensure it is not known outside your organization. We recommend that you do this immediately after system installation or handover from your hardware or hosting partner.
##  Note
In a system-replication configuration, change root keys in the primary system only. New keys will be propagated to all secondary systems. The secondary systems must be running and replicating.
The system database and all tenant database have their own individual application encryption service root key.
## Related Information
Secure Internal Credential Store Certificate Management in SAP HANA Maintain Values in the SAP HANA Secure Store Using the Server-Side JavaScript APIs
Class: Store
## 11 SQL and System View Reference
Use this chapter to find the system views relevant for system replication.
## Related Information
M\_SERVICE\_REPLICATION System View [page 269]
M\_SYSTEM\_REPLICATION System View [page 274]
M\_SYSTEM\_AVAILABILITY System View [page 276]
M\_SYSTEM\_REPLICATION\_MVCC\_HISTORY System View [page 278]
M\_SYSTEM\_REPLICATION\_TAKEOVER\_HISTORY System View [page 279]
M\_SYSTEM\_REPLICATION\_TIMETRAVEL System View
M\_LOG\_SEGMENTS System View [page 281]
M\_SNAPSHOTS System View [page 284]
## 11.4 M\_SYSTEM\_REPLICATION\_MVCC\_HISTORY System View
Displays the global multi-version concurrency control (MVCC) timestamp history in the secondary site for system replication. The global MVCC timestamp of the secondary site is updated after a chunk of logs from the primary site is replayed on the secondary site.
## Structure
| Column name                     | Data type   | Description                                                                      |
|---------------------------------|-------------|----------------------------------------------------------------------------------|
| GLOBAL_MVCC_TIMESTAMP           | BIGINT      | Specifies the global MVCCtimestamp                                               |
| SECONDARY_SITE_TIME             | TIMESTAMP   | Specifies the global MVCCtimestamp updated time of the secondary site            |
| PRIMARY_SITE_TIME               | TIMESTAMP   | Specifies the global MVCCupdated time of the primary site                        |
| SECONDARY_SITE_UPDATE_DURA­ TION | BIGINT      | Specifies the global MVCCupdate dura­ tion of the secondary site in millisec­ onds |