Brief Analysis of Oracle data instance recovery
When the database crashes suddenly, such as a sudden power failure or hardware failure, the dirty data blocks in the buffer cache are not written into the data file, and the instance crashes, the running transaction is also suddenly interrupted. At this time, the transaction is out of the intermediate state, neither commit nor rollback. At this time, the data file is inconsistent.
When the instance is started after the fault is fixed, the Oracle SMON process will execute instance recovery and check the stop scn number in the control file (SCN has four types: 1: System SCN 2: data File SCN 3: Start SCN No. 4: Terminate SCN No.) When the database is running normally, the terminate SCN No. is always empty. When the database is shut down normally, a full checkpoint is performed, and update the SCN number. When the instance crashes and Oracle has not had time to update the ending SCN number, the ending SCN number is blank. When the SMON process checks that the ending SCN number is empty, the database is not shut down normally, so the instance recovery starts.
When the instance is restored by SMOIN, it searches for the checkpoint position in the control file and searches for this position in the online Log File Based on the checkpoint location found in the control file, redo entries are applied from this position. Reproduce the status of the point in time when the instance crashes. This process is called rollback. After the rollback is completed, the database cache contains committed and uncommitted dirty data blocks. After the SMON process instance is restored and the database is opened, the uncommitted data is rolled back.