Question which really disturbs you

Question

Hi experts,
I have a question which is really tempting me to ask somebody. But due to its
silly nature I never ask anyone. anyway im posting it now.
I'm inserting million of rows in a table which generates enormous Redo records
which makes redo buffer to fill. At one stage( possibly 1/3'rd of redo buffer) it is transferred to redologs, i.e. even uncommited transaction also gets logged in it.
I didn't commit any transaction untill now. My transaction never ends, i continue to insert more and more million records which makes the redolog file to fill and tends to switch the logfile. My database is in archive log mode.
my question is,
1. whether the uncommited transaction is written to archived logs.
2. what will be the status of the controlfile at this point of time.
3. If i issue rollback, will i retrieve data from undo.
4. How is the transaction gets synchronized in database.
please reply me
Thanks
SM

Answer 1

Oracle will 'empty' the redo buffer to theredo log file:
- when it has filled to 1M
- when it is 1/2 full
- when a commit happens
- every 3 seconds
- when the DBWR is called to move out dirty blocks.
This is documented at
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14220/process.htm#i7261
One of the benefits - we can minimize the time required to return from a commit request.
Remember that a commit request is simply a confirmation that the last remaining portion of a transaction's redo has been written to the redo log file. Once the commit has returned, we know that the redo information is safely tucked away, so other processes can use the resources we had been using.
(At the same time - we do not 'release' any resources as part of a commit. Others will come along and look whether the resources are in use, will note that we no longer need them, and will release the resources for us. So a commit can happen really fast.)
One common myth is that the tablespace's data files are important. They are nothing more than a backup (or materialized view) of the most recent contents of the database buffer cache plus any changes in the redo log file. By calling up the backup in the data files, we can avoid recreating a block from the initial format state and applying all redo. In an extreme case (called crash recovery) we actually do use a previous known image of the database blocks and apply redo.
Oracle will create an archive copy of a redo log after switching from the redo log and before reusing it. It does not matter whether a commit has happened.
During a transaction, the person making a change updates the block in place. A copy of the before image of the changed parts of the block (changed parts of the row) is placed in the UNDO or ROLLBACK area. Therefore, when a commit happens, the change is already in the block.
When a person 'A' wants to roll back, the block is rebuilt to the 'start of transaction' state. This is expensive - Oracle is built on the assumption that commits must be fast and commits happen a lot more often than rollbacks.
If person 'B' starts a a long query (say a table scan) on the same table as person 'A' is updating, but the scan gets to the block after person 'A' has updated the block, a 'consistent read' copy of the block will be created and the rollback will be applied to tyhe block. This ensures that person 'B' will always see the block the way it looked when his query started.
This consistent read process fails with an ORA-01555 "snapshot too old" error, if:
- person 'A' has committed before person 'B' could rebuild the block, and
- there is not enough rollback space to keep person 'A's undo lying around, and
- someone else grabbed the rollback because they needed it for an update.