Archive log files reaches maxloghistory

[Database Administrator]

What happens if the number of archive log files reaches the number
equal to MAXLOGHISTORY? The control does not have enough space to hold
information of any additional archive log files. Is it now safe to
delete some of the older archive log fles.

Thanks

[Database Administrator]

You will find that the CONTROL_FILE_RECORD_KEEP_TIME is more of a driver
than MAXLOGHISTORY. For instance, C_F_R_K_T defaults to 7 days. Let's
assume that you have MAXLOGHISTORY set to 1,000. What happens if you
generate more than 1,000 logs in those 7 days? The control file will
automatically expand and then the value for MAXLOGHISTORY will be
increased. Eventually, the 7th day has been reached and the records will be
overwritten in the control file. It was a couple of years ago that I did
some experiments and posted the results to this very newsgroup.

HTH,
Brian

On Friday 24 October 2003 18:42, Peter thoughtfully contributed:

> What happens if the number of archive log files reaches the number
> equal to MAXLOGHISTORY? The control does not have enough space to hold
> information of any additional archive log files. Is it now safe to
> delete some of the older archive log fles.
>
> Thanks

[Database Administrator]

You will find that the CONTROL_FILE_RECORD_KEEP_TIME is more of a driver
than MAXLOGHISTORY. For instance, C_F_R_K_T defaults to 7 days. Let's
assume that you have MAXLOGHISTORY set to 1,000. What happens if you
generate more than 1,000 logs in those 7 days? The control file will
automatically expand and then the value for MAXLOGHISTORY will be
increased. Eventually, the 7th day has been reached and the records will be
overwritten in the control file. It was a couple of years ago that I did
some experiments and posted the results to this very newsgroup.

HTH,
Brian

On Friday 24 October 2003 18:42, Peter thoughtfully contributed:

> What happens if the number of archive log files reaches the number
> equal to MAXLOGHISTORY? The control does not have enough space to hold
> information of any additional archive log files. Is it now safe to
> delete some of the older archive log fles.
>
> Thanks

[Database Administrator]

Brian Peasland writes:

> You will find that the CONTROL_FILE_RECORD_KEEP_TIME is more of a
> driver than MAXLOGHISTORY. For instance, C_F_R_K_T defaults to 7
> days. Let's assume that you have MAXLOGHISTORY set to 1,000. What
> happens if you generate more than 1,000 logs in those 7 days? The
> control file will automatically expand and then the value for
> MAXLOGHISTORY will be increased. Eventually, the 7th day has been
> reached and the records will be overwritten in the control file. It
> was a couple of years ago that I did some experiments and posted the
> results to this very newsgroup.

Very interesting but if I understand the OP quite right then he asked:
is the creation parameter MAXLOGHISTORY very *important* for database
that are in ARCHIVELOGMODE or in other words has this parameter an
influence in the recovery process. From reading it seems to me that
the log history records are only for informational purposes. If the
limit is reached then the records are reused. But I am not quite sure.

> On Friday 24 October 2003 18:42, Peter thoughtfully contributed:
>
>> What happens if the number of archive log files reaches the number
>> equal to MAXLOGHISTORY? The control does not have enough space to
>> hold information of any additional archive log files. Is it now
>> safe to delete some of the older archive log fles.

Here I would say it is *not safe to* delete them. Especially if you
restore a data file that points to a SCN that is recorded in one of
the deleted log files. In that case you *cannot* recover the database
to the current point and you have to cancel the recover process with
all the consequences. As far as I understand.

Harald

[Database Administrator]

Brian Peasland writes:

> You will find that the CONTROL_FILE_RECORD_KEEP_TIME is more of a
> driver than MAXLOGHISTORY. For instance, C_F_R_K_T defaults to 7
> days. Let's assume that you have MAXLOGHISTORY set to 1,000. What
> happens if you generate more than 1,000 logs in those 7 days? The
> control file will automatically expand and then the value for
> MAXLOGHISTORY will be increased. Eventually, the 7th day has been
> reached and the records will be overwritten in the control file. It
> was a couple of years ago that I did some experiments and posted the
> results to this very newsgroup.

Very interesting but if I understand the OP quite right then he asked:
is the creation parameter MAXLOGHISTORY very *important* for database
that are in ARCHIVELOGMODE or in other words has this parameter an
influence in the recovery process. From reading it seems to me that
the log history records are only for informational purposes. If the
limit is reached then the records are reused. But I am not quite sure.

> On Friday 24 October 2003 18:42, Peter thoughtfully contributed:
>
>> What happens if the number of archive log files reaches the number
>> equal to MAXLOGHISTORY? The control does not have enough space to
>> hold information of any additional archive log files. Is it now
>> safe to delete some of the older archive log fles.

Here I would say it is *not safe to* delete them. Especially if you
restore a data file that points to a SCN that is recorded in one of
the deleted log files. In that case you *cannot* recover the database
to the current point and you have to cancel the recover process with
all the consequences. As far as I understand.

Harald

[Database Administrator]

On Sat, 25 Oct 2003 12:13:11 -0500, Brian Peasland
wrote:

I original set the maxloghistory to 500 but now it has expanded to 900
within 7 days, thanks to CONTROL_FILE_RECORD_KEEP_TIME = 7 days
Now I am considering resetting CONTROL_FILE_RECORD_KEEP_TIME to a
smaller number.

Thanks

>You will find that the CONTROL_FILE_RECORD_KEEP_TIME is more of a driver
>than MAXLOGHISTORY. For instance, C_F_R_K_T defaults to 7 days. Let's
>assume that you have MAXLOGHISTORY set to 1,000. What happens if you
>generate more than 1,000 logs in those 7 days? The control file will
>automatically expand and then the value for MAXLOGHISTORY will be
>increased. Eventually, the 7th day has been reached and the records will be
>overwritten in the control file. It was a couple of years ago that I did
>some experiments and posted the results to this very newsgroup.
>
>HTH,
>Brian
>
>On Friday 24 October 2003 18:42, Peter thoughtfully contributed:
>
>> What happens if the number of archive log files reaches the number
>> equal to MAXLOGHISTORY? The control does not have enough space to hold
>> information of any additional archive log files. Is it now safe to
>> delete some of the older archive log fles.
>>
>> Thanks

[Database Administrator]

On Sat, 25 Oct 2003 12:13:11 -0500, Brian Peasland
wrote:

I original set the maxloghistory to 500 but now it has expanded to 900
within 7 days, thanks to CONTROL_FILE_RECORD_KEEP_TIME = 7 days
Now I am considering resetting CONTROL_FILE_RECORD_KEEP_TIME to a
smaller number.

Thanks

>You will find that the CONTROL_FILE_RECORD_KEEP_TIME is more of a driver
>than MAXLOGHISTORY. For instance, C_F_R_K_T defaults to 7 days. Let's
>assume that you have MAXLOGHISTORY set to 1,000. What happens if you
>generate more than 1,000 logs in those 7 days? The control file will
>automatically expand and then the value for MAXLOGHISTORY will be
>increased. Eventually, the 7th day has been reached and the records will be
>overwritten in the control file. It was a couple of years ago that I did
>some experiments and posted the results to this very newsgroup.
>
>HTH,
>Brian
>
>On Friday 24 October 2003 18:42, Peter thoughtfully contributed:
>
>> What happens if the number of archive log files reaches the number
>> equal to MAXLOGHISTORY? The control does not have enough space to hold
>> information of any additional archive log files. Is it now safe to
>> delete some of the older archive log fles.
>>
>> Thanks

[Database Administrator]

"Peter" wrote in message
news:skotqvoanclaph59e2bae702eijnd7hfhr@4ax.com...
> On Sat, 25 Oct 2003 12:13:11 -0500, Brian Peasland
> wrote:
>
> I original set the maxloghistory to 500 but now it has expanded to 900
> within 7 days, thanks to CONTROL_FILE_RECORD_KEEP_TIME = 7 days
> Now I am considering resetting CONTROL_FILE_RECORD_KEEP_TIME to a
> smaller number.


900 archives in 7 days means you are producing 128 archives per day. That's
128 log switches per day, or about 6 switches per hour. That's one every 10
minutes.

I'd be increasing the size of your online logs if I were you. Log switches
are big events in the life of the database, with lots of I/O going on, etc
etc. Best not to be switching (generally speaking) more than about once
every half hour or so, worst case.

Of course, if you've already got Gigabyte-sized logs and are still switching
at this rate, it very much becomes 'the nature of the beast' and you learn
to live with it. But I'd be looking at log sizes first and worrying about
control_file_record_keep_time a distant second.

Regards
HJR

[Database Administrator]

"Peter" wrote in message
news:skotqvoanclaph59e2bae702eijnd7hfhr@4ax.com...
> On Sat, 25 Oct 2003 12:13:11 -0500, Brian Peasland
> wrote:
>
> I original set the maxloghistory to 500 but now it has expanded to 900
> within 7 days, thanks to CONTROL_FILE_RECORD_KEEP_TIME = 7 days
> Now I am considering resetting CONTROL_FILE_RECORD_KEEP_TIME to a
> smaller number.


900 archives in 7 days means you are producing 128 archives per day. That's
128 log switches per day, or about 6 switches per hour. That's one every 10
minutes.

I'd be increasing the size of your online logs if I were you. Log switches
are big events in the life of the database, with lots of I/O going on, etc
etc. Best not to be switching (generally speaking) more than about once
every half hour or so, worst case.

Of course, if you've already got Gigabyte-sized logs and are still switching
at this rate, it very much becomes 'the nature of the beast' and you learn
to live with it. But I'd be looking at log sizes first and worrying about
control_file_record_keep_time a distant second.

Regards
HJR