Re: Rollback Segment vs Redo Log

Meh-Lit Kim wrote:
> OK, I'll admit I'm confused.

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/toc.htm

>
> 1. In Oracle, is there a difference between Rollback segment(s) vs
Redo
> Log(s) ?

Yes.

>
> 2. If the Rollback segment and Redo Log are 2 different entities, is
a
> transaction's uncommitted modifications stored in the Redo Log ? (it
> should already be stored in the Rollback segment)
>

Yes it is. And it is FIRST stored in the redo log, THEN in the rlbseg. Writing to redo is synchronous, while writing to rlbseg is asynchronous and most likely in "catch-up" mode by the dbwr processe(s).

> 3. If the Rollback segment and Redo Log are 2 different entities,
would

they most definitely are.

> it be conceptually correct to view them as follows:
>
> 3.1 Redo Log:
> Persistent record of modifications from committed
> transactions.
> This allows delayed write of the dirty disk buffers
> associated with the commited transactions.

Persistent record of ANY modifications. It can actually "race ahead" of uncommitted stuff to save time when the realcommit comes in. Like when it has to record changes to dictionary or to the rollback segments. And although it is synchronous vis-a-vis commits, it can "piggyback" more than one commit into each log write.

>
> 3.2 Rollback Segment:
> Stores modifications of as yet uncommitted transactions.
> This allows application to rollback the current transaction.

Yes. But the "store" bit is asynchronous.

> 4. One needs to size the Rollback Segments large enough to handle the
> largest amount of modification possible from any transaction.

Very much so. Although there are "variations". And sometimes you need to size much larger than that: read about 1555 errors.

> But what about the Redo Log Buffer (LOG_BUFFER) ? Is the penalty for
> not having a large enough Redo Log Buffer simply that of poorer
> performance, or will it cause large transactions to end with
exceptions
> ?

Redo log buffer is just a stage area to write into the redo log. It has no direct bearing on commits. Of course, you don't want TOO small a stage area. The same way you don't want to access a disk to write just 1 byte.

> 5. When the database is recovering, it performs roll-forward using
the
> archive redo logs. Can it perform the subsequent roll-back using just
> the archive redo logs or does it need to use the rollback segments ?

It needs to check the rollback segments. The rollforward resets the rollback segments with any pending but unwritten changes. THEN, if there are still uncommitted transactions, they get rolled back using the
restored rlbsegs.

> Thanks for any clarification!

Definitely have a look at that URL at the top. Received on Wed May 18 2005 - 20:23:09 CDT