What Is Oracle RMAN Archivelog Deletion Policy?
An Oracle RMAN archivelog deletion policy defines when it is safe to delete archived redo logs from disk or tape. These logs capture every change made in your database—they are essential for restoring data after failures or corruption. By default, Oracle never deletes these files automatically; you must decide when they can be removed without risking recovery.
The deletion policy ensures that logs are only deleted when they are no longer needed for recovery or replication tasks such as Data Guard synchronization. You can set rules so that logs must be backed up a certain number of times before deletion or applied across all standby databases first. This flexibility helps you balance risk tolerance with storage efficiency.
For example, if you have multiple standbys or strict compliance requirements, you may want stricter policies so nothing vital gets lost during failover or audits.
Why Set an Archivelog Deletion Policy?
A clear archivelog deletion policy protects both your data safety and storage resources—a key concern for any operations administrator. Without a defined policy, archive logs accumulate until storage fills up completely. When this happens, the database may halt new transactions due to lack of space. If old logs disappear too soon—before being backed up or shipped—your ability to recover from disaster shrinks fast.
Manual cleanup increases human error risk as well. A good policy helps you:
Prevent disk space problems by removing unneeded logs promptly
Ensure all required backups or replications finish before any log disappears
Meet compliance rules by retaining data as long as needed
Automate routine log management so admins focus on higher-value work
As environments grow more complex—with multiple standbys or strict retention rules—the right configuration becomes even more critical for smooth operations.
Method 1 Configuring Archivelog Deletion Policy in RMAN
RMAN (Recovery Manager) is Oracle’s command-line tool for backup and recovery—including fine-grained control over archivelog deletion policies at scale. Before making changes, make sure you have DBA privileges and always verify recent backups exist before deleting any archive files.
First, check current archive log usage by running:
SELECT DEST_NAME, STATUS, DESTINATION FROM V$ARCHIVE_DEST_STATUS WHERE STATUS='VALID';
This gives you a baseline of where your archive logs reside.
To see your current archivelog deletion policy setting in RMAN:
SHOW ARCHIVELOG DELETION POLICY;
By default, this returns NONE, meaning no automatic deletions occur unless triggered manually.
You can tailor behavior using several commands:
1. Delete logs only after they are backed up a certain number of times
Suppose you want each log kept until backed up twice on disk:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DEVICE TYPE DISK;
This means RMAN deletes only those archive files already safely copied twice onto disk media through RMAN itself—not OS scripts or other tools.
2. Delete logs only after they are applied to all standby databases
If using Data Guard or other standbys:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
This prevents premature removal until every standby has received each log file—a vital safeguard during failover scenarios.
3. Combine both conditions
For maximum caution:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO DEVICE TYPE DISK;
Here RMAN waits until both criteria are met before deleting any archive file—ideal where business continuity trumps storage cost concerns.
4. Remove the policy (disable automatic deletion)
To disable automatic deletions:
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
5. Delete obsolete logs manually
Even with a configured policy in place, actual deletions happen only when prompted by explicit commands such as:
DELETE ARCHIVELOG ALL;
RMAN prompts for confirmation unless overridden by adding NOPROMPT:
DELETE NOPROMPT ARCHIVELOG ALL;
You may also target older archives specifically—for example,
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';
removes files older than seven days if allowed by current settings.
Remember: DELETE OBSOLETE uses backup retention rules—not archivelog policies—to determine what gets purged! For cleaning based strictly on archive status always use DELETE ARCHIVELOG.
6. Special note on Data Guard environments
On primary servers set APPLIED ON STANDBY; on standbys themselves use NONE or adjust per local backup needs—but always coordinate between nodes so nothing vital gets lost due to lagging replication links! If the standby falls behind applying redo data from primary archives—and you've set APPLIED ON ALL STANDBY—the primary's archives will not be deleted until all standbys catch up.
Method 2 Managing Archive Logs with Retention Policies in RMAN
While the archivelog deletion policy controls when an archived redo log becomes eligible for removal based on backup count or apply status across standbys, retention policies define how long backups—and their related archived redo logs—are preserved overall within your environment.
A retention policy can be set by redundancy (number of backups) or recovery window (number of days):
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
--or--
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
When you run:
DELETE OBSOLETE;
RMAN deletes backups and archived redo logs that are no longer needed to recover the database within the retention window period specified above—but note that DELETE OBSOLETE considers only the retention policy settings; it does not reference your archivelog deletion criteria directly!
To delete archive logs based strictly on their backup/apply status according to your configured archivelog deletion policy always use DELETE ARCHIVELOG ALL.
Combining both policies gives more control over cleanup routines while ensuring compliance goals are met—for instance: keep backups seven days but delete archives only after two successful backups plus application across all standbys have occurred first.
Many DBAs choose to rely primarily on one approach depending on operational needs: some prefer aggressive cleanup via tight retention windows; others require extra caution via detailed archivelog eligibility checks before removal begins.
Introducing Vinchin Backup & Recovery: Enterprise-Level Database Protection
After implementing robust strategies for managing Oracle archived redo log lifecycle and ensuring reliable recoverability through proper configuration practices, organizations often seek comprehensive solutions that streamline protection further across diverse environments. Vinchin Backup & Recovery stands out as a professional enterprise-level database backup solution supporting today’s mainstream platforms—including Oracle (with advanced features tailored specifically), MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro, and TiDB.
For Oracle users especially concerned with efficient backup management and disaster readiness, Vinchin Backup & Recovery offers incremental backup capabilities alongside batch processing options; supports granular data retention/GFS policies; enables multi-level compression; provides cloud/tape archival integration; and delivers robust integrity verification—all designed to optimize resource utilization while minimizing administrative overhead.
The intuitive web console makes safeguarding mission-critical databases straightforward:
Step 1. Select the Oracle database to back up
Step 2. Choose the backup storage
Step 3. Define the backup strategy
Step 4. Submit the job
Recognized globally with top ratings from enterprise customers across industries—and trusted for its reliability—Vinchin Backup & Recovery offers a fully featured 60-day free trial experience: click below to download now and discover why leading organizations rely on its proven data-protection technology.
Oracle RMAN Archivelog Deletion Policy FAQs
Q1: Can I automate periodic cleanup without manual intervention?
Yes; schedule DELETE NOPROMPT ARCHIVELOG ALL after each successful nightly backup job using cron jobs or task schedulers as appropriate.
Q2: What should I check if my archive destination fills despite having a configured deletion policy?
Verify that all required conditions (backups completed/applied status) match current settings then confirm no external locks prevent file removal at OS level.
Q3: How do I ensure consistent policies across clustered RAC nodes?
Use a central Recovery Catalog Database so changes propagate cluster-wide then validate configuration with SHOW commands from each node’s RMAN prompt.
Conclusion
Configuring an effective oracle rman archivelog deletion policy keeps databases healthy while supporting fast recovery when disaster strikes Use both scripting tools plus careful monitoring together Vinchin makes end-to-end protection simple reliable efficient—try our free trial today!
