Understanding of roll-forward and rollback for Oracle instance Recovery

Some of the understanding of Oracle instance recovery, has been a misunderstanding, today by looking at relevant information and discussion with students, found their own mistakes, the results are as follows:

Instance recovery: When the database is not properly shut down (power off or Shu abort, etc.), when you start the database, the database-related process automatically perform instance recovery without human intervention.

When do I need an instance recovery

Under shutdown normal or shutdown immediate, the so-called clean shutdown,checkpoint is automatically triggered and the SCN record is written back. When checkpoint occurs, the SCN is written to four places:

Three places in control file:

1. SYSTEM CHECKPOINT SCN

2. DataFile Checkpoint SCN

3. Stop SCN: Is the time when instance conformance is closed, update

One within the DataFile header:

1. Start SCN

In the normal open state of the database, the SYSTEM CHECKPOINT scn,datafile CHECKPOINT SCN and the data file header of this three SCN of the start SCN are consistent, and the stop is stored in control file The SCN reverts to a null value.

When Clean shutdown

When clean shutdown, checkpoint will proceed, and at this time the datafile stop SCN and the control file in the start SCN will be the same, wait until the Open database, Oracle check datafile header in the start The SCN is the same as the SCN of the DataFile in control file, and if the same, then check if the start SCN and the stop SCN are the same, and if the same, the database will open normally, otherwise it will need recovery.

When the database is turned on, the stop SCN stored in control file reverts to the null value, which indicates that datafile is open in normal mode.

Non-normal shutdown

If the shutdown (shutdown abort) is not normal, then the Mount database finds that the stop SCN is not equal to the SCN in the other location, but is equal to NULL, which means that Oracle did not checkpoint at shutdown. The next boot must be crash recovery (instance recovery).

Note One thing:

1. When starting the database, if the stop SCN = NULL is found, the crash recovery is required;

2. When starting the database, if it is found that the start SCN with the datafile header is not equal to the datafile SCN stored in controlfile, media recovery

The specific process of instance recovery

When the database suddenly crashes, and there is no time to flush the dirty chunks in the buffer cache into the data file, and the transaction that is running when the instance crashes is suddenly interrupted, the transaction is in the middle State, that is, neither committed nor rolled back. The contents of the data file cannot reflect the state of the instance when it crashes. This closed database is inconsistent.

The next time the instance is launched, Oracle will automatically perform an instance recovery by the Smon process. When the instance starts, the Smon process checks the end SCN number of each online, read-write data file that is recorded in the control file.

During normal operation of the database, the end SCN number is always null, and when the database shuts down gracefully, a full checkpoint is made and the checkpoint SCN number is updated, so it is possible to determine whether an instance recovery is required by the end SCN number as null.

When the field is not updated by Oracle before it crashes, the field is still null. When the Smon process discovers that the field is empty, it knows that the instance did not shut down properly last, so the Smon process begins the instance recovery.

When the Smon process does an instance recovery, the checkpoint location is obtained from the control file. As a result, the Smon process goes to the online log file, finds the checkpoint location, and then starts from the checkpoint location and applies all the redo entries to restore the state of the instance crash at that point in the buffer cache. This process is called roll forward, after the roll-forward, buffer cache has been committed in the crash has not been written to the data file of the dirty data block, but also the transaction was abruptly terminated, resulting in neither committed nor rollback of the dirty data block.

Roll forward once finished, the Smon process immediately opens the database. However, at this point the database also contains those dirty blocks in the middle state that are neither committed nor rolled back, and the dirty blocks cannot exist in the database because they are not committed and must be rolled back. After the database is opened, the Smon process is rolled back in the background.

Sometimes, when a database is opened, the Smon process does not have time to roll back these intermediate state chunks, and a user process makes a request to read the blocks. At this point, the server process is responsible for rolling back the blocks before they are returned to the user, and the contents of the data blocks are returned to the user after the rollback is complete.

Why the instance recovery of a database is a roll back and rollback

The rollback segment actually exists in the form of a rollback table space, and since it is a tablespace, there must be a corresponding data file, and there will be an image block in the buffer cache, which is the same as the data file for the other table spaces.

When a DML operation occurs, both build redo (redo Entry for the DML operation itself) also generates undo (for rolling back the DML operation, recorded in the Undo Tablespace), but since the undo information is also stored using the rollback table space, Then the undo information for the DML operation (the undo block in the corresponding buffer cache generation) will first generate its corresponding REDO information (undo block ' s REDO Entry) and write to log buffer.

The reason for this is because the block in the buffer cache for the undo tablespace may also be lost due to a database failure, in order to ensure a smooth rollback at the next boot, you must first use the Redo log to restore the Undo segment (in effect, the buffer The dirty data block in the cache is then written to the undo segment by Checkpoint, and the undo information is used for rollback after the database open to achieve consistency.

After the undo block's REDO Entry is generated, the REDO Entry of the DML statement is turned, and the block in buffer cache is modified, and the block becomes a dirty block at the same time.

In fact, simply saying that redo's role is to record all database changes, including the undo tablespace.

Summary

The most important point of the day I know that the so-called roll forward, is the application of redo to restore the buffer cache data, the buffer cache to revert to the state before crash, so at this time in the buffer cache has been committed has not written to the data file of the dirty data block, There is also a sudden termination of the transaction, resulting in neither commit nor rollback of the dirty data block (that is, no commit, but DBWR has changed the change to the underlying disk), there is a control file also has an end SCN, Used to record the SCN of the database file header when the database shuts down normally, and whether the SCN is null to determine the need or not to recover the instance.

This article is from the "Linux Oracle MariaDB" blog, so be sure to keep this source http://wangergui.blog.51cto.com/8504247/1932114

Understanding of roll-forward and rollback for Oracle instance Recovery