Re: redo records

Hi, Kyle,

Your message is correct but I don't think the original poster will be satisfied with it. He seems to be wondering why Oracle writes uncommitted data to redo logfiles. Isn't a redo file supposed to contain only valid data change? At rollback, will Oracle go into the redo file and find the record and change it or delete it?

My understanding is that redo log files are always sequentially written to. Oracle will never go back inside the logfile and modify a record. In the case of a rollback (meaning the record written a while back is wrong), Oracle simply writes to the current tail of the logfile "record 1234 should be regarded invalid".

If his question is really where does Oracle keep rollback info, isn't that simple? Rollback segments.

Yong Huang
yong321_at_yahoo.com

In article <961h0f$g83$1_at_nnrp1.deja.com>,   hailey_kyle_at_my-deja.com wrote:
> Changes, transaction, are made directly in the datablock (whether
> directly by a user or from redo during a recovery). A transaction also
> gets an entry in the rollback segments. A transaction in a data block
> has a pointer to the rollback segments entries containing info about
> the transcation. As long as the transaction is not commited then the
> info in the RBS can't be over written. Once the transaction is
 commited
> the info in the RBS is free to be overwritten. Thus when a user comes
> along and reads a block and sees there is an active transcation they
> can go look at the RBS to find out if it is commited or not. If there
> is info in the RBS fine, if not it means the transaction was commited
> and info in the RBS overwritten.
>
> If a transaction is uncommited it is forcibly in the Rollback
 Segments.
> An uncommited transaction can't be overwritten in the rollback
> segments.
>
> During recovery Oracle apply the redo and then rollback what needs to
> be from the rollback segments. If after that moment you read a block
> that has an uncommited transaction, Oracle will check the rollback
> segments, if the transaction is not there, that means it has been
> commited. This is called block cleanout, increases efficiency for the
> original transaction because it doesn't have to mark the transaction
 as
> commited, but the user who comes later has to do more work. Oracle has
> introduced some parameters to play with this functionality over the
> yesrs. This is the short easy story. There are some fun complicated
> scenarios that arise during concurent access to a block by multiple
> users.
>
> Best
> Kyle
>
> In article <9617r0$76n$1_at_nnrp1.deja.com>,
> steveee_ca_at_my-deja.com wrote:
> > Hi,
> >
> > I don't have a reference handy, but as I recall, when a commit is
 issued
> > the transaction is marked with a commit record. The non-existence of
> > this record is sufficient for Oracle to know it should be rolled
 back.
> >
> > Hth,
> >
> > Steve
> >
> > In article <9612sg$25r$1_at_nnrp1.deja.com>,
> > letokai_at_my-deja.com wrote:
> > > In :
> > >
> > > Oracle8i Administrator's Guide
> > > Release 8.1.5
> > > 6 Managing the Online Redo Log
> > > chapter : Online Redo Log Contents
> > >
> > > I've read this :
> > > "...Redo records can also be written to an online redo log file
> > > before the corresponding transaction is committed. If the
 redo log
> > > buffer fills, or another transaction commits, LGWR flushes all
> > > of the redo log entries in the redo log buffer to an online
 redo log
> > > file, even though some redo records may not be committed. If
> > > necessary, Oracle can roll back these changes."
> > >
> > > If a rollback occurs how does Oracle do to process it?
> > > I mean it must have stored somewhere the information that a
> > > modification has not been commited yet.
> > > Where is stored this information?

Sent via Deja.com
http://www.deja.com/ Received on Fri Feb 09 2001 - 14:09:56 CST