Oracle remote replication and Remote Disaster Recovery Solution Analysis

Currently, the following technologies or solutions are available for remote replication and Disaster Tolerance of oracle databases:

(1) Disaster recovery replication solution based on the storage layer

The replication mechanism of this technology is based on the SAN-based storage LAN for replication for each IO, the copied data volume is relatively large; the system can implement synchronous or asynchronous data replication. it has great advantages for systems with large data volumes (with a daily log volume of more than 60 GB), but the requirements for hosts, operating systems, and database versions are consistent, the requirements for the network environment are relatively high.

The target system does not need a host, as long as there is a storage device. If the target system needs to be readable, additional configurations and devices are required, which is troublesome.

(2) logical volume-based disaster recovery replication Solution

The mechanism of this technology is to replicate the network environment based on TCP/IP, and the operating system process captures the changes in the logical volume for replication. Its features are similar to the replication solution based on storage devices. You can also choose synchronous or asynchronous modes to ensure high consistency of the host's software and hardware environments, it is advantageous for applications with large data volumes. If the target system is readable, a third-party image must be created. I personally think that this technology is more suitable for systems with large data volumes or disaster recovery replication of application systems than the storage-based replication technology mentioned above.

(3) oracle redo log-based logical Replication

This method mainly involves third-party software and the logical Standby in oracle's own volume uard. At present, there are already many mature products and success stories in foreign countries, and there are similar products in China, but there is still a gap with foreign countries in terms of product maturity and success stories.

The principles of such products are basically the same. The working process can be divided into the following processes:

Use independent processes outside of oracle to capture redo log file information, translate it into SQL statements, and then transmit it to the target database through the network, and execute the same SQL statement in the target database. If the process cannot catch up with oracle log switching, you can also capture the content in the archived logs. Some products take transactions as the unit at the source end. After a transaction is completed, it is transmitted to the target end. All products generally copy data in tables and support most DDL replication (mainly in the oracle9i environment ).

The technical features and advantages of this technology are as follows:

The target database is always a database that can be accessed; transaction consistency between databases at both ends can be ensured; because the process outside oracle is used for capturing and its priority is lower than that of the oracle process, therefore, it has little impact on the performance of the Source System database. Based on its implementation principle and the use of multiple queue files, the replication environment can provide Fault Tolerance capabilities for network failures, database failures, and host failures; because such software only copies SQL statements or transactions, it can fully support replication in heterogeneous environments, hardware models, oracle versions, operating system types, versions, and so on.

This method also supports multiple replication methods, such as data centralization, distribution, peer replication, or multi-layer test replication.

Because the transmitted content is only part of the redolog or archive log, it occupies a small amount of network resources and can be remotely copied between different cities.

Redolog-based logical replication products have many advantages, but compared with other solutions mentioned above, there are also some disadvantages:

When the throughput of the database is too large, there will actually be a large delay. When the daily volume of the database reaches 60 GB or larger, the feasibility of this solution is poor. The implementation process may have some downtime, data Synchronization and configuration activation. After the replication environment is established, some modifications to the database structure need to be performed according to the prescribed operation procedures, with a certain maintenance cost.

However, these products are developing rapidly. The above problems have been greatly improved in the latest versions of most products.

(