Principle of instance recovery

The principle of instance recovery when the database suddenly crashes, it is not time to refresh the dirty data blocks in the buffer cache to the data file, at the same time, when a transaction is suddenly interrupted when the instance crashes, the transaction is in the intermediate state, that is, neither commit nor rollback. At this time, the content in the data file cannot reflect the status of the instance crash. In this way, the closed database is inconsistent. The next time you start an instance, Oracle will be automatically restored by the SMON process. When the instance starts, the SMON process checks the end scn number of each online and readable data file recorded in the control file. When the database is running normally, the end scn number is always blank. When the database is shut down normally, a full checkpoint is executed and the checkpoint SCN number is updated. However, if Oracle does not have time to update this field during crash, this field is still blank. When the SMON process finds that this field is null, it is known that the instance was not properly closed last time, so the SMON process starts to recover the instance. When the SMON process recovers an instance, it obtains the checkpoint position from the control file. Therefore, the SMON process goes to the online log file, finds the position of the checkpoint, and applies all redo entries from the position of the checkpoint, in this way, the status at the time when the instance crashes is restored in the buffer cache. This process is called roll-forward. After the roll-forward is completed, the buffer cache contains both dirty data blocks that have been committed and not written to the data file at the time of crash, and the transaction is suddenly terminated, as a result, no dirty data blocks are committed and not rolled back. Once the rollback is completed, the SMON process immediately opens the database. However, the database also contains dirty blocks in the intermediate state that are neither committed nor rolled back. Such dirty blocks cannot exist in the database, because they are not submitted, they must be rolled back. After the database is opened, the SMON process rolls back in the background. Sometimes, after the database is opened, the SMON process does not have time to roll back the data blocks in the intermediate state, and a user process sends a request to read the data blocks. At this time, before the server process returns these blocks to the user, the server process is responsible for rollback. After the rollback is completed, the data block content is returned to the user. Www.2cto.com Oracle provides the initialization parameter fast_start_mttr_target, which allows us to specify the maximum time it takes to restore the instance (this time only includes the time when the database is rolled forward and opened, not the time when the database is rolled back ), this parameter is in seconds. For example, if we set this parameter to 30, it indicates that if an instance crashes, the database will be rolled up to 30 seconds at the next restart and the database will be opened. During database operation, the approximate number of redo records corresponding to 30 seconds will be estimated based on the time, which determines the checkpoint location, as shown in.
The red vertical line in the figure is the position of the checkpoint. The time spent on all redo records after applying the checkpoint position in Oracle is the time specified by fast_start_mttr_target. That is to say, the dirty blocks corresponding to the redo record after the checkpoint position will be left on the checkpoint queue instead of being written into the data file by DBWn. Therefore, the larger the parameter, the more redo records will be applied, and the more dirty blocks remain in the checkpoint queue, the less frequent DBWn writes, the less I/O is occupied, the faster the I/O of the query statement of the foreground user will be responded. However, the longer the instance recovers. The smaller the parameter, the less redo records that need to be applied, and the less dirty blocks that are left in the checkpoint queue, the more frequently DBWn writes dirty blocks, therefore, the more I/O is occupied, the I/O of the query statement of the foreground user cannot be quickly responded. However, the instance recovery time is shorter. Author Li Zhiqiang