Managing archived redo logs is a core part of Oracle database administration. If you do not control how and when these logs are deleted, you risk running out of disk space or even losing your ability to recover the database in case of failure. That’s why it is so important to configure archivelog deletion policy. In this article, we’ll explain what this policy does, why it matters at every skill level, and how to set it up using both RMAN and Oracle Enterprise Manager (OEM). We’ll also cover automation techniques for log management, show you how to monitor your policies in action, discuss troubleshooting steps if things go wrong—and finally introduce how Vinchin can help protect your Oracle databases with reliable backup and archivelog management.
What Is Archivelog Deletion Policy?
An archivelog deletion policy is a set of rules that tells Oracle when it is safe to delete archived redo logs. These logs record every change made to the database; they are essential for point-in-time recovery after data loss or corruption events. By default, Oracle does not delete archived logs automatically—you must decide when they can be removed without risking data safety.
The deletion policy ensures that logs are only removed when they’re no longer needed for recovery operations or replication tasks such as Data Guard standby synchronization. You can set the policy so that logs must be backed up a certain number of times before deletion or applied across all standby databases—or both conditions together.
For example:
BACKED UP n TIMES TO DEVICE TYPE DISK means each log must have at least n backups on disk.
APPLIED ON ALL STANDBY means each log must be applied on every configured standby before removal.
You may combine these requirements for stricter protection.
This flexibility lets you match your organization’s risk tolerance with storage efficiency.
Why Configure Archivelog Deletion Policy?
Configuring an archivelog deletion policy balances safety against efficiency—a key concern for any DBA or operations administrator.
If you don’t set a clear policy:
Logs pile up until storage fills up completely.
The database may halt new transactions due to lack of space.
Recovery options become limited if old logs vanish too soon.
Manual cleanup increases human error risk.
A well-chosen policy helps you:
1. Prevent disk space issues by removing unneeded logs promptly.
2. Ensure all required backups or replications complete before any log disappears.
3. Meet compliance or audit requirements by retaining data as long as needed.
4. Automate routine log management tasks 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.
How to Configure Archivelog Deletion Policy with RMAN?
RMAN (Recovery Manager) is Oracle’s command-line tool for backup and recovery tasks—including fine-grained control over archivelog deletion policies at scale.
Before making changes:
To check your current policy setting:
SHOW ARCHIVELOG DELETION POLICY;
By default this returns NONE, meaning no automatic deletions occur unless triggered manually.
You can tailor the 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;
Now RMAN deletes only those archive files already safely copied twice onto disk media.
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):
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.
6. Special note on retention policies:
Remember that 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.
7. For 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!
Automating Archivelog Deletion with RMAN Scripts
Manual cleanups don’t scale well in busy production systems—but automation does! Most DBAs schedule regular jobs using either OS-level tools like cron (Linux/Unix) or Windows Task Scheduler—or leverage Oracle’s own DBMS_SCHEDULER package inside the database itself.
A typical Linux cron job might look like this:
1. Create an executable shell script named delete_arch_logs.sh containing:
#!/bin/bash
export ORACLE_SID=yourdb
export ORACLE_HOME=/path/to/oracle
$ORACLE_HOME/bin/rman target / <<EOF
DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
EXIT
EOF
2. Schedule it daily at midnight via crontab:
0 0 * * * /path/to/delete_arch_logs.sh > /tmp/delete_arch_logs.log 2>&1
Alternatively use DBMS_SCHEDULER within SQL*Plus:
BEGIN
DBMS_SCHEDULER.create_job (
job_name => 'ARCH_LOG_DELETE',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN EXECUTE IMMEDIATE ''DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE SYSDATE - 7''; END;',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=DAILY;BYHOUR=0;BYMINUTE=0',
enabled => TRUE);
END;
/
Automated jobs reduce manual effort while ensuring compliance with your chosen retention window—even during holidays!
How to Configure Archivelog Deletion Policy with OEM?
Oracle Enterprise Manager (OEM) offers a graphical way to manage archivelog deletion policies—perfect if you prefer clicks over command lines!
Start by logging into OEM Cloud Control then navigate as follows:
1. Open your target database home page.
2. Click Availability, then select Backup & Recovery, followed by Backup Settings under "Policy".
3. Find the section labeled Archive Log Deletion Policy near the bottom of settings pane.
4. To require backups before removal select Backed Up n Times To Disk, entering your desired count in the box provided.
5. For Data Guard setups choose Applied On All Standby instead—or combine both options if available in your version!
6. To disable automated deletions pick None instead.
7. Save changes using either OK or Apply, depending which button appears below settings panel.
To actually remove eligible archives afterward:
1. Go back through menu tree: click Recovery, then choose Manage Archive Logs
2. Select unwanted entries from list view (filtered according to active policies)
3. Click bolded option labeled simply as Delete
4–5: Confirm prompt(s), watch progress bar finish!
OEM ensures only safe-to-delete files get purged based upon whatever combination of rules currently applies—reducing accidental loss risk even further compared with ad-hoc scripting alone.
Protecting Your Database Backups With Vinchin Backup & Recovery
After implementing an effective archivelog deletion strategy in Oracle environments, robust backup remains crucial for true data resilience across complex infrastructures like yours. Vinchin Backup & Recovery stands out as an enterprise-grade solution supporting today’s leading databases—including Oracle first—as well as MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro,and TiDB.
For Oracle users,Vinchin Backup & Recovery delivers incremental backups,batch database backup,data retention/GFS retention policies,multiple levels of compression,and cloud/tape archival.Among its many features,the five most relevant include incremental backup,batch processing,retention policies ,GFS retention,and multi-level compression—which together streamline protection workflows,optimize storage utilization,and guarantee rapid disaster recovery without complexity.The web console makes safeguarding Oracle simple:
Step 1: Select the Oracle database to back up
Step 2: Choose your preferred backup storage
Step 3: Define a tailored backup strategy
Step 4: Submit the job
Trusted globally,Vinchin Backup & Recovery boasts top ratings among enterprise customers.Experience full functionality free for 60 days—download now and see why organizations worldwide rely on Vinchin Backup & Recovery.
Configure Archivelog Deletion Policy FAQs
Q1: Can I configure different archivelog deletion policies across clustered RAC nodes?
Yes; apply consistent settings cluster-wide but coordinate deletions since each instance generates its own archive stream within shared storage pools.
Q2: How do I confirm which archived redo logs meet my current deletion criteria?
Run SHOW ARCHIVELOG DELETION POLICY in RMAN then LIST BACKUP OF ARCHIVELOG ALL; cross-check results against V$ARCHIVED_LOG status columns for eligibility details.
Q3: What should I do if scheduled deletions fail due to locked files?
Check OS-level locks first; stop conflicting processes then rerun DELETE NOPROMPT ARCHIVELOG ALL command inside RMAN shell.
Conclusion
Configuring an effective archivelog deletion policy keeps Oracle databases healthy while supporting fast recovery when disaster strikes.Use RMAN scripting,OEM wizards,and careful monitoring together.Vinchin makes end-to-end protection simple,reliable,and efficient.Try their free trial today—and see why enterprises trust them worldwide!
