Re: Deletion of old Archived Redo Logs
Date: Wed, 18 Jul 2012 20:50:07 -0700 (PDT)
Message-ID: <1342669807.25146.YahooMailNeo_at_web126004.mail.ne1.yahoo.com>
Patrice,
Sort of. It implies Oracle will not so much overwrite as delete the logs when the available space in the fast recovery area is depleted.
We relied on this initially, but we ran into the same issue you described, not only on our 11.2.0.3 databases but on some other versions as well. We believe it's because our backups were being written to the fast recovery area, too, so Oracle thought it had enough room to preclude deleting the old log archives until the backup process ran and filled the available space, then it suspended the backup since it was out of room. It was almost like the available space had to be nearly zero before the software would start to delete the archived logs, which was far too late.
We ended
up with an rman script for the backups that ended with: (1)
crosschecking the backups (crosscheck backup;), (2) crosschecking the
archived logs (crosscheck archivelog all;), then (3) deleting the
obsolete files (delete obsolete;).
This allows rman to apply the retention policy (e.g., 7 days for the backups, backed up at least once for the archived logs) before it actually deletes anything. Combined with the Oracle recommended backup strategy (attention to detail in the documents when there is a requirement to retain the backups for more than one day), this reduced the required fast recovery area by about 50 percent.
HTH
- Randy
From: Patrice sur GMail <patrice.boivin_at_gmail.com> To: ORACLE-L <oracle-l_at_freelists.org> Sent: Monday, July 16, 2012 6:11 AM
Subject: Deletion of old Archived Redo Logs
Deletion of Archived Redo Logs
As explained in "Basic Concepts of Backup and Repository Maintenance", the
recommended maintenance strategy is to configure a fast recovery area, a
backup retention policy, and an archived redo log deletion policy. By
default, the archived redo logs deletion policy is configured to NONE. In
this case, the fast recovery area considers the logs eligible for deletion
if they have been backed up at least once to disk or tape or the logs are
obsolete according to the backup retention policy.
Archived redo logs can be deleted automatically by the database or by any
of the user-initiated RMAN commands listed in Table 12-1. For logs in the
recovery area, the database retains them as long as possible and
automatically deletes eligible logs when disk space is required. You can
delete eligible logs from any location, inside or outside the recovery
area, with BACKUP ... DELETE INPUT or DELETE ARCHIVELOG. Both of these
commands obey the archive redo log deletion policy when the policy is any
setting other than NONE. You can override the archived redo log deletion
policy settings by using the FORCE option in the DELETE command.
English is not my first language, but doesn't this imply that if the fast_recovery_area is short of space, RMAN will overwrite older logs?
It's not doing it on our server, we are at 11.2.0.3..
- Patrice
<http://www.viadeo.com/fr/profile/patrice.boivin>
[image: Facebook]
<http://www.facebook.com/profile.php?id0000206805521> [image:
LinkedIn] <http://ca.linkedin.com/pub/patrice-boivin/a/933/5a9> [image:
Twitter] <http://www.twitter.com/PatriceBoivin> [image:
Amazon]<http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fgp%2Fregistry%2Fregistry.html%3Fie%3DUTF8%26type%3Dwishlist%26id%3D2JU0BBL2AGGSD&tagÊsper-20>
[image:
Digg] <http://digg.com/patriceboivin> [image:
Google]<http://https://sites.google.com/site/patriceboivin/>
Get a signature like this.
<http://r1.wisestamp.com/r/landing?promo&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_19>
CLICK
HERE.<http://r1.wisestamp.com/r/landing?promo&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_19>
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Wed Jul 18 2012 - 22:50:07 CDT