Re: What is the size of arc files

From: Hans Forbrich <news.hans_at_telus.net>
Date: Tue, 05 Oct 2004 12:49:41 GMT
Message-ID: <FLw8d.27310$N%.13971@edtnps84>

Howard J. Rogers wrote:

> 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.
> 

True.

As an observation ... in the world I've experienced, the longer transaction tends to be repeatable/restartable batch or background runs whereas the OLTP sessions requiring paper to be set aside tend to be very rapid screen entries (or machine scans) with a commit after each. Total loss tends to occur for the data entry, not the batch.

I will modify my future discussions to include your extremely valid points.

/Hans Received on Tue Oct 05 2004 - 07:49:41 CDT