Oracle 11g replicuard Concept

The concept of oracle 11g distributed uard was discussed a few days ago. Which of the following types of oracle 11g distributed uard are: Physical standby and logical standby2, I did not expect that after reading the oracle 11g online documentation today, I found that three types of standby have been uploaded to oracle 11G. Of course, I 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. It was done as early as the HDR of informix 7. It seems that, relatively speaking, oracle's functions in this area are also lagging behind. At the same time, I found that each type of database actually exists because of its advanced technology uniqueness, informix is able to survive in the fate of the forthcoming elimination environment until now, and the original factory was intended to give up, This is even more illustrated by the commitment of IBM to continue its development after all, with the continued persistence of its users, next we will continue to look at the three types of gdata guard in oracle 11 and the common application. Www.2cto.com Standby databases are classified into three types: Physical Standby, logical Standby, and snapshot standby 1. physical Standby www.2cto.com physical Standby and Primary databases have physical copies of blocks 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 the read write mode. After the operation, the Flashback Database feature is used to restore the status before read write, so as to continue to receive and apply the REDO sent by the Primary end. 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. 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. For example, you may need to debug some data temporarily, but it is not convenient to operate in the official database, then you can temporarily set the Standby database to READ and WRITE mode. After the operation, the database will flash back to the status before the operation. (After the flash, Data Guard will automatically synchronize Data without the need to recreate the physical Standby, however, if the flash back is not enabled in another direction, the status before read write will not be returned ). Physical Standby 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). Therefore, 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 different from that of 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 also has the following features: (1) effectively utilizes the hardware resources of the Standby 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 turned on when it is synchronized with Primary, which enables the logical Standby database to be used for both data protection and report operations, this frees the primary database from report and query tasks and saves 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. Redo data received through snapshot standby is not applied until any local update operation is abandoned for the first time and is converted to a physical standby database. 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.