RE: redo logs

Ditto. That is what my understanding is.  

But I got confused with Jared's remark regarding the undo data beign only in UNDO tablespace. Obviously he knows more than me, maybe the context in which he made the remark was different and i failed to understand it.  

Regards
Naveen

-----Original Message-----

Sent: Tuesday, May 20, 2003 8:02 PM
To: Multiple recipients of list ORACLE-L

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   <mailto:DWILLIAMS_at_LIFETOUCH.COM> <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
<mailto:ORACLE-L_at_fatcity.com> <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"   <mailto:ORACLE-L_at_fatcity.com>
<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 ?



    



DISCLAIMER:
This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consulting Private Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return  e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited.  Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Naveen Nahata
  INET: naveen_nahata_at_mindtree.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).