-
What Is Oracle RMAN Backup Archivelog All Delete Input?
-
Why Use Delete Input with Archivelog Backups
-
Method 1: Manual RMAN Archivelog Backup and Deletion
-
Method 2: Automating RMAN Archive Log Management with OS Cron Jobs or Windows Task Scheduler
-
Method 3: Automating Archive Log Management Using Oracle Scheduler
-
Common Pitfalls and Best Practices for DELETE INPUT
-
How to Protect Oracle Databases with Vinchin Backup & Recovery?
-
Oracle RMAN Backup Archivelog All Delete Input FAQs
-
Conclusion
Managing Oracle archive logs is a daily task for database administrators. If not managed proactively, archive logs can rapidly consume allocated storage, potentially leading to database halts. The oracle rman backup archivelog all delete input command is a simple but powerful tool that helps you back up and clean up archive logs in one step. In this guide, we’ll explore what this command does, why it matters for your environment’s health, and how to use it—both manually and through automation.
What Is Oracle RMAN Backup Archivelog All Delete Input?
The oracle rman backup archivelog all delete input command instructs Oracle Recovery Manager (RMAN) to back up every archived redo log file known to the control file or recovery catalog. After each log is backed up successfully using your configured channels—whether disk or tape—RMAN deletes that specific log from its original location on disk.
When you execute:
RMAN> backup archivelog all delete input;
here’s what happens step by step:
1. RMAN scans for all archived redo logs registered in the control file or recovery catalog.
2. It backs them up using your defined channel settings (for example: disk or SBT_TAPE). Make sure these channels are properly configured before running backups.
3. After confirming each log has been included in a successful backup set without errors, RMAN deletes only those files from their source directory.
If multiple copies of an archive log exist across different destinations (such as LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_DEST_2), only the copy used during backup gets deleted by default with delete input. Other copies remain unless you specify delete all input, which removes every copy after successful backup.
This process ensures that only safely backed-up logs are removed from disk storage—a key safeguard against accidental data loss.
Why Use Delete Input with Archivelog Backups
Using delete input when backing up archivelogs addresses two major concerns: efficient storage management and reliable data protection.
First, Oracle databases running in ARCHIVELOG mode generate new archived redo logs continuously as transactions occur. Without regular cleanup, these files accumulate quickly—potentially filling disks and causing unplanned outages if left unchecked.
Second, deleting archive logs manually carries risk; removing files before they’re securely backed up could compromise your ability to recover lost data after a failure. By letting RMAN handle both tasks together—backup followed by deletion—you ensure no critical recovery information disappears prematurely.
This approach also supports compliance efforts: every log is preserved until it’s safely stored elsewhere before removal from primary storage locations. It’s an efficient workflow recommended by Oracle best practices, reducing manual intervention while improving auditability of your backup processes.
Method 1: Manual RMAN Archivelog Backup and Deletion
Manual operation gives you full control over timing and scope—ideal during maintenance windows or troubleshooting sessions where precision matters most.
To perform a manual oracle rman backup archivelog all delete input operation:
Start by connecting to RMAN as an administrator:
$ rman target /
Once at the RMAN prompt:
1. List current archive logs:
RMAN> list archivelog all;
2. Run the combined backup-and-delete command:
RMAN> backup archivelog all delete input;
You’ll see output similar to:
Starting backup at ... channel ORA_DISK_1: starting archived log backup set input archived log thread=1 sequence=5 ... ... channel ORA_DISK_1: deleting archived log(s) archived log file name=/path/to/arch1_5.dbf ... Finished backup at ...
Note: This assumes your channels (disk or SBT) are correctly configured for your target location; review CONFIGURE CHANNEL settings if needed.
After completion, only those archive logs just backed up will be deleted from their source directory; others remain until next time you run this process.
For more granular control—for example backing up only recent logs—you can add options like until time 'sysdate-2' or until sequence N. For instance:
RMAN> backup archivelog until time 'sysdate-2' delete input;
This backs up and deletes only those generated before two days ago. Adjust parameters based on your retention needs or compliance requirements.
Method 2: Automating RMAN Archive Log Management with OS Cron Jobs or Windows Task Scheduler
Most production environments require regular automation so backups happen reliably—even outside business hours! You can automate oracle rman backup archivelog all delete input using operating system schedulers like cron on Linux/Unix systems or Task Scheduler on Windows servers.
Choose between OS-level scheduling or database-integrated scheduling based on your team’s operational preferences and monitoring frameworks.
Here’s how it works on Linux using cron:
1. Create an executable shell script called rman_arch_backup.sh containing:
#!/bin/bash
export ORACLE_SID=yourdbsid
export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
$ORACLE_HOME/bin/rman target / <<EOF
run {
backup archivelog all delete input;
}
exit
EOFFor production use, enhance this script with error handling (check $? exit codes) and logging features so failures are detected early.
2. Make it executable:
chmod +x /path/to/rman_arch_backup.sh
3. Schedule daily execution at 2am via cron:
0 2 * * * /path/to/rman_arch_backup.sh > /var/log/rman_arch_backup.log 2>&1
Consider storing logs in a dedicated directory with rotation policies for long-term management.
On Windows Server systems, create a .bat file calling rman.exe, then schedule it through Task Scheduler using "Create Basic Task." Set triggers according to your desired frequency (daily/nightly).
Automating this way ensures consistent protection of archive logs without relying on manual intervention—reducing risks of full disks or missed backups due to human error.
Method 3: Automating Archive Log Management Using Oracle Scheduler
Oracle Scheduler allows job management directly within the database itself—no need for external scripts or OS-level tools—which suits environments requiring centralized oversight or restricted server access rights.
To automate oracle rman backup archivelog all delete input via Oracle Scheduler:
1. Connect as a user with DBA privileges.
2. Create a program object referencing your shell script/batch file responsible for invoking RMAN commands.
3. Define a job that calls this program according to your chosen schedule (for example nightly at 02:00).
Example steps:
BEGIN DBMS_SCHEDULER.create_job ( job_name => 'ARCHIVELOG_BACKUP_JOB', job_type => 'EXECUTABLE', job_action => '/u01/scripts/rman_arch_backup.sh', start_date => SYSTIMESTAMP, repeat_interval => 'FREQ=DAILY;BYHOUR=2;BYMINUTE=0', enabled => TRUE); END; /
Replace /u01/scripts/rman_arch_backup.sh with your actual script path. For robust operations include standard error handling within scripts so any issues are logged clearly for later review.
Centralizing scheduling inside Oracle makes auditing easier since everything runs under database security controls—a benefit many organizations value when managing critical workloads across teams.
Common Pitfalls and Best Practices for DELETE INPUT
While delete input streamlines archive log management significantly, there are important caveats every administrator should know before relying solely on automated cleanup routines.
First—and most crucial—the deletion of each archive log depends entirely on successful inclusion in the current backup set. If an error interrupts the process midway through large batches of files, some earlier logs may already have been deleted while others remain untouched; always verify completion status after scheduled jobs finish by checking both system alerts/logs and issuing LIST BACKUP commands within RMAN itself before assuming cleanup was complete.
Second, understand precisely how delete input differs from delete all input when working with multiple LOG_ARCHIVE_DEST_n destinations:
With multiple destinations configured (such as LOG_ARCHIVE_DEST_1 pointing locally while LOG_ARCHIVE_DEST_2 writes remotely), running
backup archivelog all delete inputremoves only the copy present at whichever destination was actually read during that session's channel configuration—not every copy everywhere.To remove every instance of each archived redo log after successful inclusion in backups regardless of destination path/location use
backup archivelog all delete all input. Be cautious though—this action cannot be reversed once completed!
Thirdly consider how this workflow interacts with broader retention policies set via commands like CONFIGURE RETENTION POLICY TO REDUNDANCY n;. While deleted from active disk storage immediately upon successful inclusion into backups sets/copies per above logic—the physical presence within those sets remains governed by whatever redundancy/time-based rules you've established inside RMAN's catalog metadata itself. Only when retention criteria expire will old backups themselves be purged automatically from secondary media/storage arrays/cloud repositories etc.—so plan accordingly if tight space constraints apply!
Finally remember that depending upon underlying filesystem type (ASM/ext4/NFS/etc.), reclaiming freed space may not always occur instantly following deletion events initiated via RMAN commands alone; consult platform-specific documentation regarding delayed block reuse behaviors especially when working atop clustered/shared volumes where fragmentation might impact performance over time.
How to Protect Oracle Databases with Vinchin Backup & Recovery?
Given the complexities of protecting Oracle environments efficiently, organizations often turn to specialized tools that simplify backup management while ensuring reliable recovery. Vinchin Backup & Recovery is a professional, enterprise-level database backup solution supporting today’s mainstream databases, including Oracle 10g, 11g/11g R2, 12c, 18c, 19c, 21c, Oracle RAC, MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro, and TiDB, making it suitable for diverse enterprise database infrastructures.
Vinchin Backup & Recovery provides powerful capabilities such as incremental backup, archived log backup, any-point-in-time recovery, data compression and deduplication, and flexible data retention policies including GFS retention. Together, these features help organizations reduce storage usage, automate backup lifecycles, and ensure reliable recovery for mission-critical databases.
The web-based console is designed to be simple and intuitive. Creating an Oracle database backup typically takes only four steps:
Step 1. Select the Oracle database to backup

Step 2. Choose the backup storage

Step 3. Define the backup strategy

Step 4. Submit the job

Trusted by enterprises worldwide, Vinchin Backup & Recovery is widely recognized for reliable data protection. Try the full-featured 60-day free trial to explore how easily it can safeguard your Oracle databases.
Oracle RMAN Backup Archivelog All Delete Input FAQs
Q1: Will "backup archivelog all delete input" remove unbacked-up files?
No—it deletes only those files successfully included in that specific completed backup set execution cycle.
Q2: Can I limit which archives get deleted?
Yes—add "until time" or "until sequence" clauses directly into your command syntax.
Q3: How does DELETE INPUT interact with my retention policy?
DELETE INPUT removes files from disk immediately after successful inclusion in backups but does not affect their presence inside retained catalog entries until overall retention criteria expire.
Conclusion
Backing up—and cleaning out—oracle archive logs should become routine rather than risky guesswork! The oracle rman backup archivelog all delete input command gives admins confidence their data stays protected while keeping storage under control whether used manually or automated via scripts/schedulers inside/outside Oracle itself.
For unified cross-platform protection including advanced features like immutable storage consider exploring solutions such as Vinchin designed around real-world admin needs.
Share on: