When an undo block is updated with a new undo entry, the information
necessary to recreate (redo) that update is written to the redo log.
This information is required for the database to be recoverable. It is
possible (actually probable) that the database files contain data from
uncommitted transactions, due to space requirements in the buffer cache.
When a recovery is required, the exact state of the database must be
reproduced, so that uncommitted transactions can be rolled back, which
requires undo. If these undo changes were not also logged in redo, there
would be no way to recreate the exact state of the database (including
undo) in order to determine which data needed to be rolled back and what
it needed to be rolled back to.
Allow me to illustrate with a case of Fosters and a pack of Oreo cookies...
--
Daniel W. Fink
http://www.optimaldba.com
Naveen Nahata wrote:
>Even the UNDO records get written to the redo logs, isn't it?
>
>Regards
>Naveen
>
>-----Original Message-----
>Sent: Tuesday, May 20, 2003 5:22 AM
>To: Multiple recipients of list ORACLE-L
>
>
>Dennis,
>
>He asked about 'undo'. That is in the rollback segments, or the UNDO
>tablespace.
>
>Jared
>
>
>
>
>
>
>DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
>Sent by: root_at_fatcity.com
> 05/19/2003 03:37 PM
> Please respond to ORACLE-L
>
>
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> cc:
> Subject: RE: redo logs
>
>
>Yes. Remember that Oracle doesn't wait for a commit before it writes redo.
>It is even possible for uncommitted data to get written to the data files.
>This is a real performance boost on a busy system. In case of a crash,
>Oracle must be able to recreate the "before" image of the data.
> If you become more interested in this, take a look at LogMiner. Once
>you
>see all the details in a redo log, you'll be much more impressed with
>Oracle's integrity and throughput! And a good time to practice with
>LogMiner
>is when you aren't under pressure.
>
>Dennis Williams
>DBA, 80%OCP, 100% DBA
>Lifetouch, Inc.
>dwilliams_at_lifetouch.com
>
>
>-----Original Message-----
>Sent: Monday, May 19, 2003 4:58 PM
>To: Multiple recipients of list ORACLE-L
>
>
>Dennis , so what you are trying to say is that the redo logs store undo
>data
>also ?
>
>----- Original Message -----
>To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
>Sent: Sunday, May 18, 2003 09:41
>
>
>
>
>>Not every statement is committed. Some are rolled back. So when the
>>
>>
>database
>
>
>>is recovered, these statements must again be rolled back.
>>
>>Dennis Williams
>>DBA, 80%OCP, 100% DBA
>>Lifetouch, Inc.
>>dwilliams_at_lifetouch.com
>>
>>
>>-----Original Message-----
>>Sent: Saturday, May 17, 2003 9:09 PM
>>To: Multiple recipients of list ORACLE-L
>>
>>
>>Hello list
>>
>>the "backup and recovery concepts" manual says :"Each redo record
>>
>>
>contains
>
>
>>both the old and the new values. Oracle also records the old value to an
>>undo block located either in a rollback segment (if running in manual
>>
>>
>undo
>
>
>>management mode) or in a dedicated undo tablespace (if running in
>>
>>
>automatic
>
>
>>undo management mode)."
>>
>>Does this mean that undo data is stored in both the undo tablespace and
>>
>>
>the
>
>
>>redo
>>logs ?
>>
>>I thought that only statements were stored in the redo log file.
>>
>>If undo data is stored in the redo logs also, then , do we need the undo
>>tablespace during recovery ? shouldn't the redo logs be enough ?
>>
>>
>>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Daniel W. Fink
INET: optimaldba_at_yahoo.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Tue May 20 2003 - 09:31:45 CDT
