Transaction serializability

This means that any concurrent transactions committed to the primary database can always be replicated in the secondary database (the replica). The resulting physical database (that is, the part updated by the transactions) is identical to the primary physical database.

Log-based replication schemes tend to guarantee transaction serializability whereas statement-based replication schemes tend not to. Oracle symmetric replication offers row-level and procedural-level replication (row-level replication guarantees transaction serializability while procedural level replication does not). If you use a product that does not guarantee serializability, you must either serialize dependent concurrent updates at the application level or be able to live with a replicated database that can potentially differ from the primary database.

Transaction loss

Transaction loss means that, if the primary database shuts down for some unexpected reason, transactions that have been committed to the primary database might not be propagated to the replica, resulting in replication inconsistency. The problem is because the primary database usually keeps a queue of transactions (or redo logs) that, if the database fails, can no longer be propagated. If the database becomes available later without damage, it might then be possible to replicate such transactions.

Asynchronous replication schemes can suffer transaction loss in the case of database failure, while synchronous replication schemes by definition guarantee no transaction loss.

Schema- or table-level and database-level replication

Table-level replication requires significant extra effort in that you must define the list of tables, either whole tables or subsets (horizontal or vertical), to be replicated.

The following perform replication at the schema or table level:

The following perform replication at the database level (listed in alphabetical order of the database):

Blob handling

Oracle symmetric replication and SQL Server either do not handle blobs (long fields) or have strict limitations on how they are handled. However, the Oracle standby database feature, the SAP MaxDB standby and hot standby features, and Replicated Standby Database for DB2 for z/OS have no restrictions on blob handling.

Maintain complete, hot standby database

To maintain a complete, hot standby database means that, if the primary database fails, the SAP system can switch to the standby database and continue to function without any disruption or loss of replication consistency. This guarantees that all transactions committed to the primary database are propagated to the replica and no committed transactions are lost.

Currently only SAP MaxDB hot standby and Geographically Dispersed Parallel Sysplex for DB2 for z/OS can be used for this purpose. With asynchronous replication you risk the loss of committed transactions.

It is often sufficient to have a standby database (loss of some transactions is acceptable) rather than a hot standby. If you only require a standby database, you could consider any of the log-based replication schemes (Oracle standby database, SQL Server replication, Replicated Standby Database for DB2 for Linux, UNIX, and Windows). Oracle symmetric replication cannot be used to maintain a standby database, since they are designed to replicate only part of the data.

Standby databases are commonly used as an alternative to recovery or as a disaster recovery site.

Data replication for distributed databases

Data replication can be used to maintain one or more databases at remote sites. In such a scenario, each remote site has its own SAP instance running against the database. The main function of these remote sites is to read data propagated from the primary site. For example, a big, multisite corporation might install such replicated databases at its remote manufacturing facilities to read product information without having to access the central database. Such applications must be able to tolerate certain delays that might occur when data is replicated.

To be used as a distributed database, the replication product must allow at least read access to the replica. Oracle symmetric replication should only be used to replicate parts of the data.

It is best to set up these remote sites as read-only sites and updates should be made against the primary database. Some replication products might not allow updates to the replicated data, while other products support multisite updates, including propagation of changes to all participating sites. For ease of use, updates at the remote site should only be allowed so as to support remote read applications and must not be propagated back to the primary database.

The use of this type of replication should be transparent to the SAP system.

Data replication for report jobs

In an environment where most of the batch jobs are report jobs, it might be desirable to run these jobs at a replicated site to reduce the load at the primary site. The assumption here, of course, is that these jobs can tolerate data that is slightly less up-to-date than the data at the primary site.

This use is similar to the previous item, Data replication for distributed databases.

Data replication as a software alternative to disk mirroring

Disk mirroring is usually done at the disk or hardware partition level. Using data replication, a more flexible solution can be achieved because data can be replicated at the database level or even at the table level.