Managing archive logs in an Oracle Data Guard environment is vital for database health and disaster recovery. Picture this: your Fast Recovery Area (FRA) is at 95% capacity because archived redo logs are piling up. Even though your standby databases seem healthy, storage fills up fast—risking outages or lost data. The culprit? Often it’s a misconfigured or default archivelog deletion policy. In this guide, we’ll walk through what “archivelog deletion policy to applied on all standby” means, why it matters, how to set it up step by step using both RMAN and SQL*Plus—and how you can monitor and troubleshoot along the way.
What Is Archive Log Deletion Policy?
An archive log deletion policy tells Oracle when it’s safe to delete archived redo logs. By default, Oracle may remove logs that are obsolete or backed up enough times. But in a Data Guard setup with primary and standby databases, you need more control.
The applied on all standby policy ensures that an archived log is only deleted after every configured standby database has applied it. This prevents accidental loss of logs needed for recovery or failover. The policy works across all standbys—physical or logical—and helps automate cleanup without risking data protection.
Why Apply Deletion Policy on All Standby Databases?
In multi-standby environments, each standby might lag behind the primary at different rates. If you delete logs before they’re applied everywhere, you could break synchronization or lose the ability to recover a standby after a failure.
Applying the deletion policy to all standbys guarantees that no log is removed until every site has finished using it. This approach prevents gaps during switchover or failover events. It also avoids manual checks that can lead to errors while keeping your FRA from filling up with unnecessary files. For organizations with compliance needs around data retention or audit trails, this setting supports those requirements too.
It’s a simple rule: don’t delete what someone still needs.
Prerequisites and Pre-Configuration Checks
Before changing any archivelog deletion policies in Oracle Data Guard environments, make sure your system meets key requirements. Skipping these checks can cause unexpected results—or even data loss.
First, confirm your Data Guard configuration is healthy by checking views like V$DATAGUARD_CONFIG and V$DATABASE from both primary and standby sites. Ensure archive log mode is enabled; run ARCHIVE LOG LIST in SQL*Plus if unsure.
Next, verify that your FRA (Fast Recovery Area) is properly sized and configured using SHOW PARAMETER db_recovery_file_dest in SQLPlus. Check current archivelog deletion policies by running SHOW ARCHIVELOG DELETION POLICY; in RMAN or querying SELECT FROM V$ARCHIVELOG_DELETION_POLICY; if available (Oracle 12c+).
Always connect as SYSDBA when making changes—and do so from the primary database since it controls log retention across all standbys in most configurations.
Method 1: Configuring Archivelog Deletion Policy Using RMAN
RMAN (Recovery Manager) is Oracle’s main tool for backup and recovery tasks—including setting archivelog policies safely across complex environments.
Start by connecting to RMAN as a user with SYSDBA privileges:
rman target /
Check your current archivelog deletion policy:
SHOW ARCHIVELOG DELETION POLICY;
To set the policy so that logs are deleted only after being applied on all standbys:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
If you want stricter control—for example, deleting only if also backed up—you can combine clauses:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO DISK;
This means: Only delete if each log was applied everywhere and backed up at least once to disk.
Important: Always put “APPLIED ON ALL STANDBY” before “BACKED UP n TIMES TO DISK.” If reversed due to a known bug, no logs will be eligible for deletion—even if they meet both conditions!
After changing policies, check reclaimable space:
SELECT * FROM V$RECOVERY_AREA_USAGE WHERE FILE_TYPE='ARCHIVED LOG';
If reclaimable space does not increase as expected—especially when databases are mounted but not open—refresh file status manually:
SQL "BEGIN DBMS_BACKUP_RESTORE.refreshagedfiles; END;";
This command updates FRA metadata so Oracle knows which files can be deleted according to current rules.
Method 2: Setting Archivelog Deletion Policy via SQL*Plus
While actual configuration of archivelog deletion policies must be done via RMAN—not SQLPlus—you can use SQLPlus for monitoring status and troubleshooting issues related to archivelogs application across sites.
To check which archived logs have been applied:
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
For reclaimable status (which files FRA considers deletable), try this advanced query:
SELECT APPLIED,
DELETED,
DECODE(RECTYPE,11,'YES','NO') AS RECLAIMABLE,
COUNT(*),
MIN(SEQUENCE#),
MAX(SEQUENCE#)
FROM V$ARCHIVED_LOG LEFT OUTER JOIN SYS.X$KCCAGF USING(RECID)
WHERE IS_RECOVERY_DEST_FILE='YES' AND NAME IS NOT NULL
GROUP BY APPLIED,DELETED,DECODE(RECTYPE,11,'YES','NO')
ORDER BY MIN(SEQUENCE#);
This shows which files are ready for removal under current policies—a useful view when tracking down why storage isn’t being freed as expected!
If reclaimable space isn’t updating—a common issue when databases are mounted but not open—refresh aged files manually:
EXEC DBMS_BACKUP_RESTORE.refreshagedfiles;
Or run this command from within RMAN as shown earlier above.
Remember: To actually change the deletion policy itself (“to applied on all standby”), always use RMAN—not SQL*Plus!
How Can Vinchin Simplify Backup Management Across Diverse IT Environments?
Building upon robust Oracle strategies above, organizations often seek unified solutions for backup management spanning virtualized platforms and hybrid infrastructures.
Vinchin Backup & Recovery stands out with its broad compatibility, supporting over 19 virtualization platforms including VMware, Hyper-V, Proxmox—as well as physical servers, mainstream databases, plus both local file storage and cloud environments—to address diverse IT architecture needs seamlessly.
When migrations arise—whether between virtual machines or moving workloads across physical/cloud hosts—Vinchin delivers flexible full-system migration capabilities, making transitions straightforward regardless of source or destination.
For critical workloads running directly on virtual or physical machines where downtime isn’t an option, Vinchin offers real-time backup & replication, providing additional recovery points alongside automated failover mechanisms that minimize RPO/RTO.
To ensure reliability of backups at scale, Vinchin features automatic integrity checks of backup data plus isolated recoverability validation—so restoration works exactly when needed most.
Let’s take VMware VM backup as an example:
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
You can experience Vinchin Backup & Recovery free for 60 days—with comprehensive documentation plus responsive support engineers ensuring smooth deployment tailored precisely to your environment.
Oracle Configure Archivelog Deletion Policy To Applied On All Standby FAQs
Q1: Will configuring "applied on all standby" prevent accidental log loss during switchover?
Yes—it ensures no archive log is deleted until every standby applies it fully.
Q2: How do I check which archive logs are reclaimable?
Run SELECT FROM V$RECOVERY_AREA_USAGE WHERE FILE_TYPE='ARCHIVED LOG'; in SQLPlus.
Q3: What should I do if my FRA doesn’t release space after applying this policy?
Run SQL "BEGIN DBMS_BACKUP_RESTORE.refreshagedfiles; END;" from within RMAN.
Conclusion
Setting oracle configure archivelog deletion policy to applied on all standby protects against premature log removal while keeping storage manageable—a win-win for uptime compliance alike! For unified management across mixed IT landscapes—including seamless migration robust DR—consider Vinchin Backup & Recovery as your next step toward worry-free operations.
