4) Also, as I said, when windows shutdown, ORCL goes off, is it equivalent to instance failure (or shutdown abort) in database terms ?Take a look at the alert log. See if there is a 'crash recovery' operation as part of the automatic startup. Then you will have discovered for yourself the answer to the above.
Should I manually stop the ORCLService everytime before windows shutdown ?
AnkitV wrote:Well, you have pretty much gotten the answer already but just to echo, DBWR writes only when there is a CHECKPOINT call done. And with COmmit, there is no such thing that happens. Your colleague, doesn't matter where he is sitting, is getting the data from the buffer cache only because, with the change, the actual buffer gets modified. Normally, what's told in the DBA classes that Oracle would keep both the old and the new images at the same time in the buffer cache when an update happens which is partially true. Oracle does brings in the undo image but only when there is a requirement of it, for read consistancy purpose. It's not going to do it just iike that. So if you have done a change, rather a small change, it's going to effect the actual copy of the buffer in the buffer cache and with the transaction being committed, it's that buffer only which is marked as committed with the actual data being updated with the Commit SCN. So you and your colleague are going to see that very same buffer only being given for the select purpose.
I have below doubts/questions.
1) Its said that DBWn doesn't write to data files in real-time for performance reasons. The changes remain in buffer cache before being written to data files via DBWn.
When I COMMIT a change, and within a SECOND, my colleague sitting thousands of miles away from me fire a SELECT to check the modified data, he does see the new
modified data. Does it mean that DBWn wrote to data file within that SECOND or is it read consistency in action ?