Oralce 11g Data guard

A few days ago, we discussed a question about the Oracle 11g Data guard. I only thought of physical standby and logical standby2. I did not expect that I found out after reading the Oracle 11g online documentation today, three types of standby have been divided into the actual uploads of Oracle 11G. Of course, I have heard that Oracle 11g supports the feature called active standby, after careful research, it is found that the application can be restored in read-only mode, so that the slave database can be used for some report functions in many designs, reduce the load and performance problems caused by the query of the master database. Of course, this function is actually not a new technology, as early as Informix
7. HDR is achieved. It seems that the functions of Oracle are also relatively lagging behind. At the same time, I found that each database actually exists because of its unique advanced technology, informix is able to survive in the fate of the forthcoming elimination environment until now, and the original factory was intended to give up, but with the user's continued insistence, IBM eventually had to compromise, this is even more explained by the commitment to continue development. Next we will continue to look at the three types of Oracle 11 gdata guard and the common application.

Typical dataguard Configuration Principle

Standby databases are classified into three types: Physical standby, logical standby, and snapshot standby.

1. Physical standby

Physical standby and Primary databases have physical copies of block and block-level master databases with the same architecture as the master database on the physical database disk. DG maintains the physical standby database through the redo application. When physical standby does not perform redo application operations, you can open the physical standby database in read only mode. If flashback area is specified in the database, it can even be temporarily set to read write mode. After the operation, the flashback database feature restores the status before read write to continue receiving

Redo and apply it. Physical standby Maintains consistency with the primary database through the redo application. The so-called redo application actually uses the restoration mechanism of Oracle to apply redo data in the archive file (or standby redologs file. The Restoration Operation is a block-to-block application. If you are performing operations on the redo application, the Oracle database cannot be opened.

The physical standby application function is enhanced in Oracle 11g version. in Oracle 11g version, physical standby can continue to receive and apply the redo data generated by the primaru database in open read only mode, this greatly improves the application of physical standby databases.

Read Write mode is enabled. If it is enabled in Read Write mode, the Standby database suspends receiving redo data from the primary database and temporarily loses the disaster protection function. Of course, opening in Read Write mode is not useless. If you may need to debug some data temporarily, but it is not convenient to operate in the official database, you can temporarily change the standby Database

Set it to read write mode. After the operation, the database will flash back to the status before the operation (after the flash back, data guard will automatically synchronize and do not need to re-build the physical standby, but if

In another direction, if flash back is not enabled, the status before read write is not returned ).

Physical standby has the following features:

(1) Disaster recovery and high availability. Physical standby provides a sound and efficient disaster recovery and high availability solution. Easier management of switchover/failover role conversion and shorter planned or unplanned downtime.

(2) data protection. Using a physical standby database, DG ensures that data is not lost even in the face of unpredictable disasters. As mentioned above, physical standby is based on block-to-block replication, so it has nothing to do with objects and statements. What is available on the primary database and what is available on the physical standby database.

(3) share the pressure on the primary database. By transferring backup tasks and query-only requests to the physical standby database, you can effectively save the CPU and I/O resources of the primary database.

(4) improve performance. The redo application technology used by physical standby uses the underlying recovery mechanism, which can bypass the SQL-level code layer and thus achieve the highest efficiency.

2. Logical standby

Logical standby must also be created through the primary database (or its backup, or its replication database, such as physical standby), so it is similar to the physical standby database at the beginning of creation. However, because logical standby applies redo data through SQL applications, the physical file structure of logical standby and even the logical structure of data can be inconsistent with primary.

Unlike physical standby, logical standby is normally enabled in Read Write mode. You can access the logical standby database at any time, that is, logical standby executes SQL applications in the open state. It also has advantages and disadvantages. Due to the characteristics of SQL applications, logical standby imposes operational restrictions on some data types and some DDL/DML statements. You can view unsupported data types in the dba_logstdby_unsupported view. If this data type is used, the database cannot be completely consistent.

The read/write of logical standby enables it to be used as a report system, which reduces the pressure on the system.

In addition to the features similar to disaster recovery, high availability, and data protection mentioned in physical standby, logical standby has the following features:

(1) make effective use of the hardware resources of the slave machine. In addition to disaster recovery, the logical standby database can also be used for other business needs. For example, you can create additional indexes and materialized views in the standby database to improve query performance and meet specific business needs. You can also create a new schema (This schema does not exist on the primary database ), then execute DDL or DML operations that are not suitable for execution on the primary database in These schemas.

(2) share the pressure on the primary database. The logical standby database can still be enabled when it is synchronized with primary, which enables the logical standby database to be used for data protection at the same time.

And report operations to free the primary database from report and query tasks, saving valuable CPU and I/O resources.

(3) smooth upgrade. You can use logical standby to perform operations such as cross-version upgrade and database patching. It should be said that there is a lot of space for the application, but the risk is very small (if you have enough technical strength. In addition, although physical standby can also implement some upgrade operations, I am afraid it will not work if it is cross-platform, so this item is not listed as a feature of physical standby ), I personally think this is a feasible online smooth and rolling upgrade method, if your application supports creating logical standby.

3. snapshot standby

A snapshot standby database is a fully updatable standby database, just like a physical or logical standby database. A snapshot standby database receives and archives redo data from the master database. However, unlike physical standby or logical standby databases, the redo data it receives is applied. The redo data received through the snapshot standby is not applied until it is converted to a physical standby database after giving up any local update operation for the first time.

Snapshot standby is used in scenarios where a temporary snapshot of the physical standby can be updated. Note that because redo data is only received by the snapshot standby database but not applied, until it is converted into a physical standby database, the fault recovery time from a master database is proportional to the amount of data in the redo data to be applied.