Hi Tom
I was wondering if you have time to clarify some of my concepts when it comes to the internals of Oracle Architecture. I will give it a try to explain what I think the oracle system does internally and some of my explanation will be incorrect and hopefully you will help me there.
¿ log writer background process writes sequentially into the redo log files
¿ After successfully writing to the redo log file a success commit signal is send back to the user process.
¿ It is my understanding than another background process (DBWn) then tries to write the actual data into the database data files (asynchronously)

Let¿s say if the above understanding of what happens at a very high level is correct, then
What happens if?
¿ The system crashes before DBWn gets an opportunity to write into the database files, how is the recovery done. Let¿s say I have all the back ups with me cold or hot all that. Is this what will happen
o The system will have to apply the redo log files in a rolling forward fashion and then somehow signal the DBWn to write the committed data back into the database data files. ¿ can you confirm that.
o Let¿s say that the redo log file was written into after the last check point but before the DBWn got an opportunity to write to data files. Is it accurate to state that there might be some uncommitted as well as committed data after the last check point occurred in the redo log file and that when the rolling forward happens the system will roll forward to the point of last instance failure and then will utilize the undo tablespace info to roll back what¿s uncommitted after the last check point. However the system will retain the committed data after the check point and will somehow apply the same to the data files to keep them in sync. Can you clarify that for me?
o Now lets say in the above bullet point where the undo tablespace is utilized for rolling backwards during recovery process, I have active transactions or the undo tablespace file is corrupted. What happens then to the uncommitted data that¿s sitting after the last check point? How will the system know it¿s uncommitted? I have read articles by you as well as by others about how to recovery the database instances from a corrupted undo tablespace. Let¿s say, that the information in the undo tablespace is lost. How does Oracle know that there is some uncommitted info in the redo log and some committed data in the redo log after the last checkpoint and that it needs to roll forward the active/current redo log and then rollback to the last committed data in the absence of the undo tablespace¿Can you clarify that for me.

I would appreciate it if you can enlighten me. Tom, I just made it to 3 questions and since they are related I made it just under the radar of your rules