Ravi Kumar, August 10, 2016 - 11:33 am UTC
Hi Mc Donald,
Thanks for your response, please let me know what will happen for the following scenario :
1.User1 updates a row in table x.
2.User2 updates a row in table y.
3.The database writes the before-change data in the undo tablespace.
4.User 2 has given commit.
5.Logwriter is called and writes both the commited entry by user2 and uncommited entry by user 1 from redolog buffer
to the online redolog files.
6.the database assigns a SCN for a commited transaction in the redolog file, i.e., for the transaction generated by user2.
7.Due to checkpoint,Flushing the contents of the redo log buffers to the redo log files will be done and
Flushing the contents of the database buffer cache to disk.
8.So at step 7, online redolog file and Data File will contain uncommited data generated by user1. When this uncomitted
data will be removed from the respective files, if there is no user initiated Rollback? How long will the uncommited data be retained in both the files?
August 11, 2016 - 12:44 pm UTC
The database (by design) is really really lazy. There's a good reason for that - why do work if you can avoid it ? The less work you do, the faster performance you have.
So there are many scenarios where we simply leave blocks in an "untidy" state on disk - it is not a big drama. For example, if you change LOTS of rows, then when you commit, we dont go back to all those blocks and wipe out the lock information on the rows...it's not worth the effort.
Now, then *next* person (session) who comes along and reads those rows...well, they are going to see all that mess. How do *they* know what's really committed, what's really uncommitted etc ? It's not too difficult - the details of the seemingly active transaction on that block can be looked for in the undo area. If its marked as committed, or is not there (ie, was committed so long ago that we dont care), then that messy block can be tidied up by that reading session.
Hope this helps.