RE: RMAN and control_file_record_keep_time
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 23 Jun 2004 08:30:11 -0400
First, I've never been sure when someone will want an old backup loaded and
rolled forward to some point. So unless you've thrown all but a recent few
of the COLD (or HOT) backups away, those archlog records could be quite
convenient. A backup being COLD is not an impediment to rolling it forward
(unless the COLD backup procedure is faulty. Possibly you're just indicating
you don't think you need the old archive logs any longer, period. I've seen
plenty of times when something didn't tie out at quarter end, so load up the
test system and roll it through all the transactions to find out where the
programs went wrong. (Of course them implies you have a source of the
logical transactions and data to run through the programs.)
Second, controlfile write may or may not affect performance depending on
frequency and time to write. More importantly, you want the window of that
hopefully atomic operation to be as short as possible for file integrity.
Your mileage may vary, but some systems take significant amounts of time to
seek to the end of very large files for append writes. I have never measured
this delay for controlfile writes, but one of the reasons that most log
objects in Oracle can now be cycled without stopping service is that there
was a time when you could measure a diffence in connection times with a
stopwatch by truncating various log files (and you didn't need a quick
finger.) As systems became stable and started staying up for months at a
time, log file lengths became a real issue (especially the listener's log
for connection delays, but also the alert logging that you had switched log
files causing false attribution of delays to the checkpoint process.) As a
side issue, it can pay large dividends to grandfather log files frequently
to an "old" directory containing datenamed directories. This not only is
tidy (which should be reason enough), but it keeps whatever structures must
be searched to open new output files small (inodes for unix).
It is pretty easy to test both of these timings on a system. The first,
simply by charting doubling of file size versus the time to append a small
marker to the file, you can find out if seek to append is significant on
your system. The second, generate lots of eensey weensy files in a single
directory and spit out the time every 100 or 1000 or so. If these times are
low through values you think you're unlikely to see, then the argument to
keep things small and uncluttered is organizational rather than production
process performance.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Ron Rogers
Sent: Wednesday, June 23, 2004 8:00 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: RMAN and control_file_record_keep_time
Peter,
I whole heartedly agree with the "Broke/don't fix" theory. This matter
came up in a meeting I attended last week and I was looking for a method
of bringing the database archlog info up to date with the backup info.
For example, I have over 500 archlogs listed when I view the info with
the OEM and I have performed numerious COLD backups of the database.
Should I not be able to remove the information if they are not needed
for a restore?. In the production database there are archivelogs listed
since May 2003 when I went live on the new server. The production
database is backed up using RMAN with a catalog. Maybe Oracle has not
thought about the need or the ability to keep the data in step and
cleaned up.
"Size doesn't really matter" is a true statement but cleaning up
after yourself would be nice.
Ron
>>> peter.gram@xxxxxxxxxxxx 06/22/2004 5:27:26 PM >>>
Ron
Even if the control file is 27, 60 and 200 Mb I don't see a reason to
recreate the file. If you have some how can prove that the
performance of the database is affected by the size if the control
file
size it is fine to make a new control file. I have never
seen a prof that size does mater when it comes control files. A wise
DBA once sad to me "If it is not broken don't fix it".
/peter
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
