* Separation of secondary system from primary system
The secondary system is normally located at a remote site, since otherwise it too may be affected by whatever damages the primary system. The two servers must be connected by a TCP/IP network connection.
* Secondary is exact physical copy of primary database
It is essential that the secondary database is an exact copy: the physical layout of the secondary database must therefore be identical to the primary database (that is. same disk configuration, same directory structures and filenames). If this is not the case, you can not successfully perform the restore on the secondary server (see below, "Setting up Data Replication").
* Data-replication buffers store data to be replicated
These buffers (the same size as the logical-log buffers) are used to store logical log data from transactions that are then sent to the secondary server. When used with the R/3 System, the updates are passed synchronously to the secondary server. This avoids uncommitted or partially-committed transactions on the secondary server if the primary server fails.
* Secondary can operate as read-only server
An added benefit of HDR is that the secondary database server can function as a read-only database server for certain clients, so improving performance by allowing distribution of the overall system workload. Since the secondary server operates in "logical-recovery" mode, it can not accept updates.
* Stress tests indicate no substantial performance decrease
Data replication in an SAP environment does not normally have a significant impact on performance, as indicated by stress tests carried out to measure this.
ความคิดเห็นที่ 1
