Instance Recovery

I mentioned in an earlier post that LSN and SCN are greatly used in the instance recovery. As the matter of fact the whole instance recovery is done through these two. Suppose you were working in the database and before you can update the changes the power supply failed. But you have committed the transactions. When you give the command of commit the LGWR writes in the redo log files. As you know that when a check point occurs the DBWR writes and information of LSN and SCN is stored in the control files and in data file’s header. Next time when instance starts up the SMON process checks the LSN number and SCN number in the redo logs and in the control files. If they are the same then the data is consistent and there is no need of recovery. In case of a system failure the SCN number in the redo logs will be greater then the SCN number in the control files. The SMON process will see the difference in the entries and will restore the data for those entries. Suppose when you last saved the data your LSN was 23 and your SCN was 60. At LSN of 23 and SCN of 100 you committed the data but did not saved the data. The LSN and SCN in the control files will be 23 and 60 respectively because this was when you last saved the data. But the LSN and SCN number in the redo logs will be 23 and 100 respectively because this was when you last committed the data. SMON will see that there is difference of 40 entries; means that data of last 40 entries needs to be saved. So it recovers the data and stores it on data files. The whole process is going on background. Users will be allowed to continue their work. In this way oracle ensures that up till every commit or check point your data will be not lost whether you have saved it or not.