Is it possible that control_file_record_keep_time used to be higher and so the controlfile already grew to accommodate it? If so, that would explain it since setting the parameter back down later wouldn't force it to shrink. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Rich Jesse Sent: Tuesday, September 29, 2009 11:58 AM To: Oracle L Subject: RE: What controls RMAN history size in controlfile? Hey Brandon, > Control_file_record_keep_time only sets the time after which a record is > eligible to be reused, it's not a setting for when it is automatically > deleted. For example, you could run a backup today and then not run any > other backups for 10 years, and when you checked 10 years from now, the > backup you ran today would still be there in the controlfile even with the > default setting of 7 days. It's only overwritten if needed. Ok, but that doesn't explain why I'm seeing 167 days of backups with 32K records in the controlfile. RMAN fulls are run nightly with archivelogs going every 15 minutes. > There are few > known bugs for performance problems related to v$rman_status - just search > for the view name on metalink. Already did. However, note 375386.1 is terribly inconclusive. A patch does exist, but is only for 10.2 (I mentioned I'm on 10.1). Despite having current system statistics, I've needed to include setting the session optimization mode to rule as a workaround, which takes the delays from >1 minute down to ~15 seconds. Better, but going against the X$ view directly is subsecond. Aside from RMAN performance, there's a lot of disk wasted on this. At the controlfiles current size of 50MB each (PROD is only 4MB) and with a maximum of ~200 copies required for a minimum 1 day RMAN retention period with autobackup, I'm needing 10GB in my FRA just for controlfile backups (which don't appear to be compressed). At this point, I have no idea how big the controlfile is going to get, which is a bit scary. Thanks! Rich -- //www.freelists.org/webpage/oracle-l Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. -- //www.freelists.org/webpage/oracle-l