Oracle internal recovery principle (redo log)

Source: Internet
Author: User
The most basic operation of a database is to modify data blocks in an atomic manner. When a foreground process wants to modify one or more data blocks, it must first obtain

The most basic operation of a database is to modify data blocks in an atomic manner. When a foreground process wants to modify one or more data blocks, it must first obtain

The redo log describes all changes to the data block. This section describes the operations performed when a database is opened and logs are written.

Series of articles: Oracle internal recovery principles? Where = nkey & keyword = 19824

3.1 atomic Modification

The most basic operation of a database is to modify data blocks in an atomic manner. When a front-end process wants to modify one or more data blocks, it must first obtain the access permission for a row in the cache containing the block in the data buffer. Then construct the Change vector. Allocate space in the redo log buffer to save redo records. The redo buffer is located in SGA. The LGWR Process regularly writes redo records in the redo log buffer to the redo log file to release space. When the redo log is full, LGWR will switch the log. Note that when space is allocated in the redo log buffer, space is also allocated in the redo log file. After the space of the redo log buffer is allocated, the foreground process is responsible for building the redo record before modifying the data blocks in the data buffer. Then, when the redo record in the redo log buffer is written to the redo file, the Database Change is completed. Recovery ensures that all changes recorded in the redo log are applied to the data file (unless they are not completely restored ).

3.2 log writing priority

Log writing is a buffer execution protocol used to coordinate the order of writing dirty data to data files and writing redo log records to redo log files. According to the log writing Priority Protocol, before the DBWR process writes dirty data to the data file, the LGWR process must first write the corresponding redo log records to the redo log file.

Note that the log writing priority protocol is independent from the log writing protocol when submitting (see 3.3 ).

At the same time, note that the log writing Priority Protocol is only applicable to writing dirty data in the data buffer zone to the data file. It is not applicable to direct path writing (such as caused by direct path reading ).

The log writing priority protocol ensures that no change in the data file is not recorded in the redo log file and does not hesitate to fail.

The log writing Priority Protocol also ensures that all data blocks are written to the disk only when the redo log is written and the rollback is ensured. If the submission fails, all modifications can be rolled back. Here, the redo information is actually the redo information of the rollback segment.

The write Priority Protocol plays a major role in ensuring the atomicity of transactions at the Database Transaction layer.

3.3 transaction submission

When a transaction is committed, an SCN is allocated and a redo log record containing the SCN commit is created. When all the redo records of the firm (including the redo records corresponding to the commit) are written to the redo log file on the disk, the commit process ends. Therefore, commit forces the log to refresh to the disk-at least until the redo record of commit, which is generally called log-force-at-commit.

Recovery is designed to be like this. When the transaction commit, you only need to refresh the redo record to the redo log, instead of refreshing all the dirty data modified by the transaction, in order to ensure transaction persistence even if the transaction fails. This is generally referred to as no-datablock-force-at-commit.

3.4 thread checkpoint event

When a thread checkpoint event occurs, the dirty data protected by the redo record whose SCN is less than the specified value will be refreshed to the data file. After completion, the thread checkpoint structure in the control file will be updated.

When a thread checkpoint event starts, it first obtains an SCN and initializes a checkpoint structure. All the dirty data in the data buffer of the instance is marked as a checkpoint. DBWR writes the dirty data of these identifiers to the data file in stages. When all dirty data is written to the data file, the SCN In the checkpoint structure is updated to the obtained SCN, and then the checkpoint record of the thread in the control file is updated with the checkpoint.

A thread checkpoint event may or will not push the database checkpoint. When there is only one open thread, the new thread checkpoint is also a new database checkpoint. If there are multiple open threads and the current thread is the online thread of the database checkpoint, the checkpoint event of the current thread will promote the database checkpoint. Because the new checkpoint SCN is recently allocated, it is likely to be larger than the checkpoint SCN of other open threads, and the database checkpoint SCN will be pushed to the new smallest thread checkpoint SCN. However, if the original checkpoint of the current thread is not a database checkpoint, the checkpoint event of the thread will not promote the database checkpoint.

When the database checkpoint is promoted, the checkpoint count of each data file header also increases. In addition, as long as each data file is not in a hot backup or does not have a higher checkpoint SCN (such as a newly added data file or a newly recovered data file ), the checkpoints in the data file header are pushed forward to the same as those in the new database. The data file header is written to the disk. At the same time, the checkpoint SCN recorded in the data file in the control file will also be updated to the new database checkpoint SCN.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.