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: kccrsz: expanded controlfile section AND controlfile_record_keep_time

Re: kccrsz: expanded controlfile section AND controlfile_record_keep_time

From: Howard J. Rogers <howardjr2000_at_yahoo.com.au>
Date: Tue, 7 Jan 2003 06:15:19 +1100
Message-ID: <FrkS9.18083$jM5.49557@newsfeeds.bigpond.com>

<mokat67_at_hotmail.com> wrote in message
news:3e189215.25434132_at_news.hccnet.nl...
>
> After activating archive logging the following message appears in the
> log file:
>
> " kccrsz: expanded controlfile section 11 from 13 to 27 records
> requested to grow by 13 record(s); added 1 block(s) of records "
>
> The following information about this subject:
>
> The init.ora parameter controlfile_record_keep_time applies to
> reusable sections. It specifies the minimum age in days that a record
> must have before it can be reused. This value defaults to 7 days. In
> the event a new record needs to be added to a reusable section and the
> oldest record has not aged enough, then the record section expands. A
> reason this might be set is to ensure the controlfile maintains
> information for a set period of days--perhaps between backups. Setting
> it to 0 (zero) will stop the controlfile from expanding.
>
> Three questions:
>
> 1 - What wil happen if this parameter is currently not available in
> the init.ora file (will the system still take 7 days as default)?

Yes it will.

> 2 - What are the consequences for archiving / recovery options if the
> default number of days (7) is changed to another value for example 0

It potentially means that when you perform your next recovery, Oracle won't have a clue which archive to prompt you to supply. You then just have to guess which one to supply, and keep your fingers crossed you got it right. It doesn't render your database unrecoverable, in other words, but it does make recovery a much more awkward and lengthy procedure than it otherwise would be.

Actually, this is more of a problem for a RAC (or OPS) than it would be for a single instance database, because with a single instance, you've just got one thread of redo, which is generated sequentially, and archive log numbers are therefore pretty easy to work out. With RAC, you've got multiple threads of redo, each of which has its own sequence number. Recovery of a RAC can mean applying thread 1, log 563 followed by thread 2 243, thread 2 244, thread 3 725, thread 4 612, thread 1 564, tread 4 613... and so on.

The chances of you guessing that sequence correctly are somewhere close to zero.

It's *really* important in a RAC environment to make sure that controlfile_record_keep_time is large enough to accomodate the worst possible recovery scenario. (IE, even though you back up every night, and therefore think you only need to set it to 1 or maybe 2, consider what happens if last night's backup is corrupt, the one before that has been lost, and the one before that caught fire.)

> 4 - Can an already huge controle file shrink without recreating the
> file?

Stands ready to be corrected, but no. The file doesn't shrink.

But I've got to say: what are you really worried about? Because the biggest controlfile I ever saw in my life was about 80M in size. Which isn't really going to kill you, and is probably one of the least important things you have to worry about I can think of!

Regards
HJR
>
> Thanks
>
>
>
>
>
Received on Mon Jan 06 2003 - 13:15:19 CST

Original text of this message

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