Re: What is the size of arc files

From: Howard J. Rogers <howardjr_at_dizwell.com>
Date: Mon, 04 Oct 2004 17:59:37 +1000
Message-Id: <41625514$0$20130$afc38c87@news.optusnet.com.au>

Hans Forbrich wrote:

> U C wrote:
>

>> Hi All,
>>       I would like to know few things from about different log files:
>> 
>> 1) What is the size of arc file. When it creates new files and what is
>> the maximum size that it can have.

>
> Assuming you mean an archived log file, it's simply a copy of a log file
> set aside by the archiver process to be available for database recovery if
> needed. When the database is running with archiving enabled and active,
> each log switch should not be considered complete until the log file is
> archived.
>
> Depending on your needs (and assuming you are using archiving), you might
> decide to keep all the archived log files online or near line.
>
> If archiving is not used, there are no archive files. Otherwise each is
> the size of the log file it archives, and you have as many online and
> nearline as are needed for your recovery strategy.
>
> One way to look at log sizes: the size of the log file is the unit of
> unrecoverable transactions - if your log file is sized for a switch at 10
> minutes, the worst case scenario is that you will lose 10 minutes of
> transactions (assuming all log files die or become corrupt & you are
> actively archiving).

That is not actually true. It will mean, for sure, that only the last 10 minutes of dirtied buffers will have to be re-constructed, since the dirty buffers extant at the time of the last log switch will have been checkpointed to the data files and can thus be read whole and entire from there. But that's not the same as saying you will only lose 10 minutes of transactions. If I start a transaction at 9.00am, and it only gets around to offering me the chance to commit at 11.00am, then a loss of the current redo log at 10.59am would cause me to lose the entire 1 hour 59 minutes worth of transaction, even though the last log switch took place at 10.58am. "Recovery" in that scenario will consist of applying peanut-sized quantities of redo, and then performing massive quantities of rollback.

We need to be careful to make the distinction between 'applying redo' (which frequent checkpointing and hence frequent log switches will certainly limit the need for) and 'recovering transactions', which is a different matter entirely.

Regards
HJR Received on Mon Oct 04 2004 - 02:59:37 CDT