For a database to be reliable should be ACID compliant. Undo comes in to picture to meet these requirement.
ACID means
A --> atomicity
C --> Consistency
I --> Isolation
D --> Durability
Link below explains why we need undo tablespace and what it does.
Yes, you could use redo logs to perform the rollback. If that's all you wanted to do with the undo ...
In an ideally configured system, the redo logs are effectively 'write-only' files for performance reasons. Ideally the redo logs are read only for archive (at each log file switch) and for recovery purposes (at start up). One job only, and very, very optimized. (Oracle is slowly moving away from this ... log miner, cdc, streams, etc.)
A commit is only considerd complete when the redo log is updated with the last dregs of the transaction that requested the commit. Any delay in writing to the redo log that means a delay in the commit performance.
On the undo/rollback side, Oracle guarantees 'read consistency' by [if necessary] rebuilding each and every block being queried to the way it looked when the query started. That rebuilding is effectively rolling back the block to the point-in-time of the start of the query. A LOT of rebuilding may occur when the database is active, and (again, for performance reasons) you don't want to get that from the redo logs.
Some questions:
Would it be true to say that the redo logs contain records of committed transactions only, while the under holds the "temporary" records before the commit?
Basic concept:
REDO => Committed transactions
UNDO => Uncommitted Transactions.
But , it is not true always. In case of huge volume transactions, redo also contain un-committed transactions.
Sometimes, if more buffer space is needed, LGWR writes redo log entries before a transaction is committed. These entries become permanent only if the transaction is later committed.
In such case, undo information will needed when Oracle do auto recovery. It will use the undo information to rollback the uncommited entries in redo logfiles.
ACID means
A --> atomicity
C --> Consistency
I --> Isolation
D --> Durability
Link below explains why we need undo tablespace and what it does.
Yes, you could use redo logs to perform the rollback. If that's all you wanted to do with the undo ...
In an ideally configured system, the redo logs are effectively 'write-only' files for performance reasons. Ideally the redo logs are read only for archive (at each log file switch) and for recovery purposes (at start up). One job only, and very, very optimized. (Oracle is slowly moving away from this ... log miner, cdc, streams, etc.)
A commit is only considerd complete when the redo log is updated with the last dregs of the transaction that requested the commit. Any delay in writing to the redo log that means a delay in the commit performance.
On the undo/rollback side, Oracle guarantees 'read consistency' by [if necessary] rebuilding each and every block being queried to the way it looked when the query started. That rebuilding is effectively rolling back the block to the point-in-time of the start of the query. A LOT of rebuilding may occur when the database is active, and (again, for performance reasons) you don't want to get that from the redo logs.
Some questions:
Would it be true to say that the redo logs contain records of committed transactions only, while the under holds the "temporary" records before the commit?
Basic concept:
REDO => Committed transactions
UNDO => Uncommitted Transactions.
But , it is not true always. In case of huge volume transactions, redo also contain un-committed transactions.
Sometimes, if more buffer space is needed, LGWR writes redo log entries before a transaction is committed. These entries become permanent only if the transaction is later committed.
In such case, undo information will needed when Oracle do auto recovery. It will use the undo information to rollback the uncommited entries in redo logfiles.
No comments:
Post a Comment