cancel
Showing results for 
Search instead for 
Did you mean: 

denied expansion of controlfile

Former Member
0 Kudos

Hi All,

I am getting this problem in DB12 since one month . Any one can solve this problem.

kccrsz: denied expansion of controlfile section 19 by 65535 record(s)

the number of records is already at maximum value (65535)

krcpwnc: following controlfile record written over:

RECID #1186613 Recno 3308 Record timestamp

04/02/07 00:03:51

Object type=245 Object recid=295683 Object timestamp=

02/10/07 18:01:58

Server details

SUN solaris 9

ECC 5.0

Oracle 9I

Regards,

Arjun

098900 39627

Mail : arjun.b.r@gmail.com

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

It looks like the filesystem on which your controlfile resides has become full ,denying controlfile expansion.

Oracle controlfile has circularly reusable records(containing archivelog/backup info) and non-reusable records(containing datafiles/logfiles info etc).

The reusablility is controlled by CONTROL_FILE_RECORD_KEEP_TIME init.ora parameter. It defaults to 7 days. This is the minimum number of days the reusable records are retained in the controlfile before they get overwritten. The file expands ,filesystem permitting,to meet the minimum keep time.

But if the filesystem(or if say you store the controlfile on a raw device which cannot expand automatically) is full or some other issue prevents the controlfile from expanding, than the oldest records get overwritten irrespective of the control_file_record_keep_time and Oracle registers such a warning message in the alert.log file for you to take necessary action.

You dont have to worry too much about it if for example you use recovery catalog for RMAN and resync the catalog periodically( say every day or so) or if you dont need to recover the database from a backup taken before the control_file_Record_keep_time number of days, becos now the archivelog info has been overwritten.

You will need to free up the filesystem space and confirm if your keep_time setting is appropriate vs the frequency of the backups/resync catalog etc.

Former Member
0 Kudos

Arjun,

As Fidel suggested check CONTROL_FILE_RECORD_KEEP_TIME I guess it is 7.

And check SQL> select * from v$controlfile_record_section where type='LOG HISTORY' ;

And check RECORDS_USED and RECORDS_TOTAL.

Let us know if you are using RMAN for backups.

Regards

Vinod

Former Member
0 Kudos

Hi,

Are you using RMAN?

What is the value of CONTROL_FILE_RECORD_KEEP_TIME?

Former Member
0 Kudos

Hi Fidel,

Thanks for responding. Yes we are using RMAN.

Regards,

Arjun

Former Member
0 Kudos

Hi,

I wish you would have given output of query I have given.Hmmmm

Any way to help you!!

Controlfile Record "section 19" tracks deleted objects.

When a RMAN maintenance command like delete Etc are used section 19 of the controlfile is updated. If the RMAN retention period is set to a high value and many RMAN deletes occur, you may see this kind of error.

Reduce the retention period. For example, instead of setting the recovery window

to 30 days set it to 5 days. If the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is at the default of 7 days, and you're not creating an extraordinary number of backups each day, you should not see this message.

Example:

RMAN>CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAYS;

Regards

Vinod

Message was edited by:

Vinod U