Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Why does Orcl generate REDO logs in NOARCHIVE mode?

Re: Why does Orcl generate REDO logs in NOARCHIVE mode?

From: Thomas Kyte <tkyte_at_us.oracle.com>
Date: Wed, 24 Mar 1999 18:37:55 GMT
Message-ID: <37032cd7.22113707@192.86.155.100>


A copy of this was sent to Mike Burden <michael.burden_at_capgemini.co.uk> (if that email address didn't require changing) On Wed, 24 Mar 1999 15:58:56 +0000, you wrote:

>I agree with all your points about switching off redo and rollback, but still think
>there are some occasions when it might be useful. I agree you must know what you're
>doing and accept you will have to restore to a cold backup, but it would be nice to
>have the choice. Although perhaps we already have too many choices so I'm not
>compalining.
>
>I also agree with not using a single area for roll back and redo because, as you say,
>it does have advantages.
>
>However, are you sure that you need to log rollback. I say this again because
>consider the following example:
>
>Table A column A is updated:
>
>XXXX to YYYY
>XXXX gets written to the rollback.

xxxx is written to rollback segments which are buffered in the buffer cache like all other segments (good thing they are -- consistent reads that use the rollback segment need this). So XXXX is not on disk generally its in the buffer cache.

>YYYY gets written to the redo.

yyyy gets written to redo on the commit.

>and XXXX gets written to the redo. (This is the bit I think is not needed)

this XXXX does in the same IO typically with the YYYY but the XXXX written to rollback is still buffered (see digression in previous post about why you want to write to redo on a commit but not do scattered IO all over the place to datafiles)

>
>Lets now restore the database and roll forward as we would expect.
>
>table contains
>XXXX
>
>YYYY is read from the redo and applied to the datafile.
>XXXX is read from the redo and is applied to the rollback.
>
>Lets say this is 2 reads and 2 writes
>
>However consider the alternative were XXXX was not written to redo log.
>
>table contains
>
>XXXX
>
>YYYY is read from the redo log. Before it is applied the previous value on the
>datafile is read XXXX.
>XXXX is applied to the rollback.
>YYYY is then applied to the datafile.
>
>This too is two reads and two writes.
>

but your simple example falls apart in almost every case. The reason is checkpointing and log switches. Lets say you have 2-1 meg log files (2meg total log). You are updating 3meg of data. updating XXXX to YYYY is the FIRST row you updated. It was written to redo log #1. partway through the transaction we switched from log #1 to log #2 -- this fires a checkpoint (so that blocks that were modified and recorded in redo log#1 will be flushed to disk). We now start filling redo #2 with redo. Bam -- system crashes.

We goto recover now. Lets say we did not record rollback to redo as you suggest. Unfortunately for us -- the checkpoint that had been in progress when we switched logfiles had a chance to flush to disk our first update from XXXX to YYYY. So, in your scenario:

You cannot rollback anymore-- your database is broken, this transaction cannot be rolled back anymore, nor can it be rolled forward. You *need* to have rollback in redo. Rollback is buffered and datafiles are fuzzy -- you cannot rely on the datafiles to have the before image.... Otherwise we would have to stop all activity during a checkpoint and get a consistent picture of the datafiles (and never have them be 'fuzzy' which they almost *always* are).

>Hence we get to the same position but without rollback being written to the redo.
>

no we couldn't... checkpoints, wrapping logfiles (eg: you have 2meg of log and do 3meg of updates -- some of the redo disappears from the online logs)

>You could also make more optimizations like buffering up rollback so if you get to
>the commit in the redo log you can throw away the rollback updates as they are not
>needed. They are only needed if you stop rolling forward at a point in time before
>the commit and then need to rollback.
>

but they are needed for consistent reads -- ORA-1555 would happen in many many more cases if we did that.

don't forget rollback isn't just for rolling back -- its an integral part of our consistent read mechanism -- people read rollback (prevents LOCKs from blocking reads so readers are not blocked by writers -- try to do a select count(*) from T in another database when there is an outstanding UPDATE on the table -- one thats not committed or rolledback -- it'll block).

>I can so no real technical reason why this wouldn't work however, I may have missed
>something really obvious in which case please say, anyone.
>
>I know the change would not be trivial but it may save a good percentage of the redo.
>Would this not be beneficial.
>
>When I have run a test to update a 2K columns it does seem to write 4K to the redo
>log. However, it is not easy to confirm this one way or the other.
>

redo of the data (2k) + redo of the rollback (2k) = 4k done in one large sequential write as opposed to randon seeks and writes. Multiply your single session by dozens or hundreds and the payoff is there big time.

>Thomas Kyte wrote:
>
>> A copy of this was sent to Mike Burden <michael.burden_at_capgemini.co.uk>
>> (if that email address didn't require changing)
>> On Wed, 24 Mar 1999 11:33:27 +0000, you wrote:
>>
>> >Agreed that redo logs aid recovery, but surely they are not essential. If you
>> >accept that in the event of a failure, you will restore to a cold backup, why do
>>
>> The redo logs are used to recover from things like a POWER failure, software
>> failure, database crash, etc. They are only "essential" if you don't want to
>> always have to go back to your last full cold backup after a power failure,
>> system failure, software failure of some sort (eg: they are pretty essential).
[snip]  

Thomas Kyte
tkyte_at_us.oracle.com
Oracle Service Industries
Reston, VA USA

--
http://govt.us.oracle.com/ -- downloadable utilities  



Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Wed Mar 24 1999 - 12:37:55 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US