Knowledge about the structure of data guard

Previously, I tried to configure the logic and physical standby structure of the Oracle instance and perform some role exchange operations. However, I did not pay attention to the part of RMAN commands I learned yesterday, the archivel gap still exists in standby dB in maximum protection mode. As a result, the Standby experiment environment created earlier is completely suspended, primary dB also stops automatically. I had to change primary dB to maximum performance mode in nomount mode, and set log_archive_dest_state_n, which controls standby redo log transmission, to defer to start primary dB. Now, in addition to rebuilding standby, there are no other ways to make up for it. It seems that the understanding of data guard is still stuck in the image-based operations, and MI has a basic understanding of its principles. So I started from the basics.

First, the main principle of data guard is that primary dB transfers the redo logs generated by all operations to standby dB, which is applied by standby dB. To generate a consistent standby dB. There are two types of sync and async in data guard. The following describes the two types of working methods to further understand their principles.

Is the flowchart of The Sync Mode.
1. When the user issues the commit command, a redo record (also called redo entry) will be generated and put into the redo buffer in SGA. The background process lgwr will read this redo record, write it into the online redo log file. And wait for confirmation from the LNS process.
2. The lNS (log network server) process also reads redo record from redo log buffer and transmits it to standby DB through Oracle Net Services. The RFS background process on the standby dB writes the received redo record to the standby database.
3. When RFS determines that all redo records are written to the disk, it sends a confirmation message to the LNS of primary dB. After lgwr receives the confirmation message forwarded by LNS, it returns the message of successful commit to the user.

Next, let's look at async: similar to sync, but lgwr on the primary dB does not have to wait for the LNS to confirm the information, and LNS can read the redo record in the online redo log. For async, you can use the compression method to transmit redo record to save bandwidth, but this will increase the CPU utilization. In addition, if lNS encounters an online switch when reading the records in the online redo log, it may cause archivelog gap of standby. Non-synchronous records of LNs may also cause data loss while improving performance.

Oracle Data guard has its own automatic processing method for gap processing of redo logs. Log File gap mainly occurs when transactions are committed on the primary dB. At the same time, lNS may fail to be synchronized in time due to network or standby dB problems. In this case, primary dB continues to run, uses redo logs cyclically, and archives it. Data Guard uses an arch process on primary dB to continuously Ping standby dB. When it can communicate with standby dB, the arch Ping process queries the control file of standby through RFS, obtain the SCN for the last log synchronization to determine which archive log to start synchronization and fill in the gap. When this step is completed, it will automatically oversync to the current log file. The specific flowchart is as follows:

 

For physical standby, the redo record received by the application is in the following way:

Redo apply maintains a standby database and uses precise physical blocks to back up primary dB. The RFS process receives the redo record from the primary dB and writes it to the standby redo log (which will be referred to as SRL later ). Redo apply reads the redo record in SRL into the memory and restores the session by media Recovery Coordinator (mrp0) management, IANG combines redo with the same SCN (mostly in the RAC environment) and analyzes the redo ing to different apply processes. Different apply processes read the mapped data blocks and write them into the changed data blocks. Redo apply automatically sets the apply process with the same number of CPUs.

For the logical standby that uses SQL apply, the specific use of redo is as follows:

SQL apply uses the logical standby process to coordinate the changes in the corresponding redo log. The SQL apply process reads SRL, converts it to logical record changes, establishes SQL transactions, and applies these SQL statements to standby dB. Compared with redo apply, SQL apply consumes more resources such as CPU, Io, and memory.