A rapidly growing archive destination can fill during bulk loads or data migrations. A usage-triggered RMAN job is a useful emergency backstop, but it should complement—not replace—scheduled archivelog backups, monitoring, and capacity planning.
If you use the fast recovery area
Measure the Oracle-managed recovery area from the database rather than parsing a filesystem command:
SELECT name,
ROUND(space_used * 100 / NULLIF(space_limit, 0), 1)
AS percent_used,
ROUND(space_reclaimable * 100 / NULLIF(space_limit, 0), 1)
AS percent_reclaimable
FROM v$recovery_file_dest;
V$RECOVERY_AREA_USAGE breaks the total down by archived logs, backup pieces, flashback logs, and other file types.
If archives use a normal filesystem
Read the active archive destination from the database configuration, then check that exact mount with the operating system’s supported disk-usage tool. Do not assume the obsolete LOG_ARCHIVE_DEST parameter is the only destination; modern systems commonly use LOG_ARCHIVE_DEST_n.
RMAN command
RUN {
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
BACKUP ARCHIVELOG ALL
NOT BACKED UP 1 TIMES
DELETE INPUT;
}
DELETE INPUT removes only the archived-log copy that RMAN successfully backed up. With multiple archive destinations, use the deletion behavior appropriate to the redundancy and Data Guard policy.
Automation safeguards
- Use operating-system or Oracle Wallet authentication; never embed a recovery-catalog password in a world-readable script.
- Use a lock so two threshold checks cannot start overlapping RMAN jobs.
- Write logs to a protected directory and alert on any nonzero RMAN exit status.
- Set warning and critical thresholds with enough headroom for the backup to finish.
- Confirm that archived logs required by standby databases or downstream consumers are not deleted prematurely.
- Test a restore of the archived-log backups.
Reference
Oracle’s RMAN command quick reference includes BACKUP ARCHIVELOG ALL DELETE INPUT.

Leave a Reply