Analysis of Oracle remote replication and disaster disaster recovery schemes

"Guide" This article describes the current major technologies and solutions for remote replication and disaster recovery of Oracle databases.

Currently, there are several technologies or solutions for remote replication and disaster tolerance for Oracle databases:

(1) Disaster-tolerant replication scheme based on storage layer

The replication mechanism for this technology is replicated through a SAN based storage LAN replication is done for each IO, the amount of data replicated is large, and the system can replicate the data synchronously or asynchronously. It has great advantages for systems with large data volume (daily log volume above 60G), but for host, Operating system, database version, and other requirements are consistent, and the requirements of the network environment is relatively high.

The target system does not need to have a host, as long as there is a storage device can be, if the target system is readable, need additional configuration and equipment, more trouble.

(2) Disaster-tolerant replication scheme based on logical volume

The mechanism of this technique is replicated through a TCP/IP based network environment, where the operating system process captures the changes of logical volumes. Its characteristics and storage device replication scheme is similar, can choose synchronous or asynchronous two ways, the host software and hardware environment of the consistency requirements are relatively high, the application of large amount of data has advantages. The target system needs to create a third party mirror if it is to be readable. Personally, this technology and the above mentioned storage-based replication technology is more suitable for large data systems, or application system disaster recovery replication.

(3) Logical Copy method based on Oracle redo log

In this way there are mainly Third-party software, as well as Oracle's own Dataguard in logical Standby. At present, foreign countries have a lot of relatively mature products and successful cases, domestic also have similar products, but in the product maturity and success cases with foreign countries still have a certain gap.

The principle of this kind of product is basically same, its work process can be divided into the following several processes:

Use an independent process other than Oracle to capture the information of redo log file, translate it into SQL statements, transfer it over the network to the target database, and execute the same SQL on the target database. You can also capture the contents of an archive log if the process is not up to Oracle log switching. Also some products in the source to the transaction unit, when a transaction is completed, and then transfer it to the target side. All products are typically replicated in a table, while supporting most of the DDL replication (primarily in the oracle9i environment).

The technical characteristics and advantages of this technology are mainly as follows:

The target-side database has always been an accessible database, guaranteed transactional consistency at both ends of the database, and because it is captured with processes other than Oracle and has a lower priority than the Oracle process, the performance impact on the source system database is small, based on its implementation principles and the use of multiple queue files, The replication environment can provide fault tolerance for network failures, database failures, host failures, and because such software replicates only SQL statements or transactions, he can fully support replication of heterogeneous environments, hardware models, Oracle versions, operating system types, versions, and so on.

This approach can also support a variety of replication methods, such as data collection, distribution, peer-to-peer replication, or multi-layer test replication.

Because the content of the transmission is only a part of the Redolog or archive log, the use of network resources is very small, can achieve remote replication between different cities.

There are many advantages to the Redolog based logical replication product, but there are some drawbacks compared to the other scenarios mentioned above:

When the throughput of the database is too large, there will be a large delay, when the daily amount of the database reaches 60G or greater, the feasibility of this scheme is fulfilled; the implementation process may have some downtime for synchronizing and configuring the data, and when the replication environment is established, Some modifications to the database structure need to be carried out in accordance with the prescribed operating procedures, with a certain cost of maintenance.

However, the current development of such products, the above problems, in most of the latest version of the product has been greatly improved.