Oracle Redo Complexity--oracle Core technology reading notes three

I. Overview

We know that in Oracle, every modification of a piece of data produces a redo (that is, redo, which records the modified content). The goal is to back up the modified data to facilitate future re-work. Now there is a problem. Whenever data is modified in Oracle, Redo is generated, and these redo are stored in a buffer called redo log. If more than one reply at the same time to modify the data, to redo the log buffer to write to the content, there is a problem of competition for the same area of memory. There is a competition, there is overhead, this article about how Oracle minimizes this overhead.

Two. Overview of issues

Oracle continually modifies data to generate redo logs continuously. Oracle writes these logs to the redo log buffer (a single area of memory), and then calls the LGWR process to write the logs to an online log file on disk (typically three, a 50M look). After an online log file is full, switch to another log file. If Oracle turns on archive mode, when the log file is toggled, a copy of the log file, called the archive log file, is saved to one place (perhaps another server to prevent accidental occurrence, facilitate instance recovery or media recovery). It seems like everything is perfect. Writing logs to the redo log buffer, if the concurrency is large, and every reply modifies a lot of data, then the competition for redo log buffers is fierce. It is likely that the CPU will spend a lot of time on the latch spin (that is, CPU time, but the CPU is not doing anything).

three. Solution

Issue 1: A session constantly modifies data and needs to constantly write to redo buffer (redo log buffer), that is, to continuously acquire redo allocation latch (a lock that protects the redo log buffer, controlling concurrency). Very much affects efficiency, especially when high concurrency, you don't necessarily get to lock.

Is it possible to generate all the redo first and then get a redo allocation latch lock? The answer is yes, after Oracle in 10g, a private redo is provided, that is, to allocate a proprietary redo buffer for each thing, you first generate all the redo logs here. When the transaction commits, get a redo allocation latch lock, and copy the contents of the private redo into the public redo buffer.

Extension Problem 2: If the data is constantly modified, the undo data block will be generated, and the change of undo block will also generate redo buffer. And these must be paired with the redo buffer describing the data change, and must be written to the redo log file at the same time. The reasons are as follows: When a dirty block is written to the disk data block, it is necessary to write the redo record corresponding to the redo record that describes this data change and the undo data block that records the old data of this data to the disk redo log file. Otherwise, the consistency of the data is not guaranteed. Prior to the introduction of private redo, Oracle will describe the undo block before the data block changes as a general block of data, the undo block is changed, and the redo is generated, and output to the redo log file. The previous mechanism has the following problems: If another session needs to find the old data in the undo block, but the undo block has been flushed out to disk, then it needs to be transferred to the disk and there is some I/o overhead. Also, after the introduction of private redo, it is not guaranteed that redo and undo, which describe a data change, will flush output to the redo log file together.

To this end, Oracle introduces a mechanism called the IMU, which is also a private memory area for a transaction in the memory area, specifically for storing redo records that describe the change of the undo data block. If a transaction modifies 10 data, it generates 10 undo data, resulting in 10 redo records describing undo changes, stored in the IMU. In addition, 10 redo records that describe the change in the data itself are stored in the private redo. A total of 20 redo records, if the transaction commits, the 20 redo records will be merged into one, from the IMU and private redo copied to the common redo buffer. Of course, if the transaction has not yet been committed, but the DBWN process needs to flush 3 of its dirty data to disk, it will fetch the three records from the IMU and private redo for the redo records, a total of 6, merged into one, and then copied to the common redo buffer, The output is then flushed to disk. Until redo refreshes the output to disk successfully, DBWN can output dirty data to disk.

To do this, if we modify a lot of data in one transaction, the approximate operation of Oracle is as follows:

1. Obtain a pair of private memory structures (that is, private redo: Used to store changes in the description block and IMU: used to store changes that describe the corresponding undo data block), open the transaction

2. Modify the data to mark each affected block (to indicate "own private memory Structure"), but not to really change the data.

3. Write each restore change vector (that is, describe undo data changes) to the IMU pool.

4. Write each redo change vector (that is, a description of the data block change) to the private redo area.

5. Combine the vectors of these two memory structures into a redo record.

6. Copy the redo change record to the redo log buffer (that is, the public redo buffer) and change the data block. (So, as I wrote above, the transaction is not over yet, it is not possible for the DBWN process to write dirty data to disk, because, finally, the data block is changed)

Oracle Redo Complexity--oracle Core technology reading notes three