This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
By:
In Oracle, the ALTER SYSTEM ARCHIVE LOG command is used to manually control archive log operations. Depending on the option used, it can force the archiving of the current redo log, archive pending redo logs, or manage the archive process itself.
Even when automatic archiving is enabled, administrators may still need to manually archive logs before a backup, after recovery operations, or when resolving archive log gaps.
Before using ALTER SYSTEM ARCHIVE LOG CURRENT or ALTER SYSTEM ARCHIVE LOG ALL, the database should be running in ARCHIVELOG mode, and the user must have SYSDBA or SYSOPER privileges.
You can verify the current archive mode with: SELECT LOG_MODE FROM V$DATABASE; or ARCHIVE LOG LIST;
Command Overview
The Oracle ALTER SYSTEM ARCHIVE LOG command supports several options, but CURRENT, ALL, and STOP are the most commonly discussed.
The table below summarizes their behavior and typical use cases:
| Command | Synchronous | Triggers Switch | RAC Scope | Best For |
|---|---|---|---|---|
ARCHIVE LOG CURRENT |
Y | Y | All nodes | RMAN backup scripts |
ARCHIVE LOG ALL |
Y | N | All threads | Gap fill / post-recovery |
ARCHIVE LOG STOP |
/ | / | / | Avoid — deprecated |
ALTER SYSTEM ARCHIVE LOG CURRENT is the standard choice for backup operations. When executed, it forces a log switch on the active redo log and archives it before returning control to the session.
This command is synchronous. Oracle waits until the archive file has been fully written to disk before the session continues. That behavior is what makes it reliable in backup scripts — you know the redo data is safely captured before the next step runs.
In a standalone environment, the syntax is straightforward:
ALTER SYSTEM ARCHIVE LOG CURRENT;
In a Real Application Clusters (RAC) environment, running this command on one instance forces a log switch and archives logs across all threads on every active node. To target a specific instance, use the THREAD parameter:
-- Force archiving for redo thread 2
ALTER SYSTEM ARCHIVE LOG CURRENT THREAD 2;
A common mistake in backup scripts is using ALTER SYSTEM SWITCH LOGFILE instead. While it triggers a log switch, it is asynchronous — Oracle returns control immediately, before the ARCn process has finished writing the archive file to disk.
If an RMAN job proceeds at that point, it may not find the expected file, causing errors like RMAN-06054 or ORA-00279. Some legacy scripts work around this with a SLEEP 60 pause, but that is not reliable. ALTER SYSTEM ARCHIVE LOG CURRENT eliminates the problem entirely by making Oracle wait for the archive to complete.
Oracle recommends running this command twice during a hot backup: once before the backup begins, and once after it completes. This ensures all redo generated during the backup window is included in the recovery set.
ALTER SYSTEM ARCHIVE LOG ALL archives all redo log groups that are full but have not yet been archived. Unlike ARCHIVE LOG CURRENT, it does not force a switch on the active log. Instead, it scans for logs in a filled state and triggers archiving across all enabled threads.
This makes it the right tool when the automatic archiver falls behind or hits a temporary interruption.
The distinction comes down to log switch behavior. ARCHIVE LOG CURRENT forces the database to switch to a new redo log immediately. ARCHIVE LOG ALL only processes logs that are already closed and waiting to be archived. If the active redo log is 50% full, this command leaves it untouched and works through the older completed logs only.
There are three common scenarios where this command is the appropriate choice:
If the database is already fully caught up, Oracle returns:
ORA-00271: no logs need archiving
This is a status notification, not an error. In a healthy environment, this response means the background archiver is working correctly and there is no backlog to clear.
Archiving multiple redo logs at once can place a short but heavy load on the I/O subsystem. Where possible, run this command during off-peak hours to avoid competing with user transactions for disk throughput.
ALTER SYSTEM ARCHIVE LOG STOP is a legacy command that has no place in modern database administration. In Oracle 9i and earlier, it was used alongside ARCHIVE LOG START to manually control the ARCn background processes. Oracle deprecated it in version 10g, and while the syntax may still execute on newer versions, the risks make it one to avoid.
Executing this command tells Oracle to stop the archiver processes from writing redo data to the archive destination. The database, however, keeps recording transactions in the online redo logs.
Once all redo log groups are full, Oracle has nowhere to write new changes. Because the database is still in ARCHIVELOG mode with archiving stopped, it suspends all activity and waits indefinitely. The only way out is to resume archiving or shut the instance down.
The one scenario where a DBA might reach for this command is a severe emergency. If the archiver process is completely stuck and causing an I/O lockup at the system level, ARCHIVE LOG STOP can be used to kill the process immediately. This should be followed by a SHUTDOWN ABORT to prevent further instability.
To disable archiving, skip the STOP command entirely. The safe approach is to change the database logging mode directly:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE NOARCHIVELOG;
ALTER DATABASE OPEN;
This updates the control file and gracefully decommissions the background archiver processes, avoiding the risk of an unexpected hang.
Even in well-managed environments, archiving can occasionally trigger errors that block database activity. Knowing what each code means helps you resolve the issue quickly and get back to normal operations.
ORA-00257: Archiver Error — Connect as SYSDBA Only Until Freed
This is the most common archiving error. It occurs when the archive log destination, typically the Flash Recovery Area (FRA), runs out of space. Oracle responds by blocking non-administrative connections to prevent new redo from being generated when there is nowhere to save it.
To diagnose and resolve this:
V$RECOVERY_FILE_DEST.DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1';db_recovery_file_dest_size or configure a secondary archive destination.ORA-00271: No Logs Need Archiving
This message appears when ALTER SYSTEM ARCHIVE LOG ALL runs but all filled redo logs have already been processed. No action is needed. It confirms that the archiver is current and there is no backlog to clear.
ORA-16038: Log Sequence Cannot Be Archived
This error points to an I/O failure or a configuration problem that prevents Oracle from writing to the archive destination. Common causes include:
LOG_ARCHIVE_DEST_nRMAN-06054 and ORA-00279
These errors typically appear when ALTER SYSTEM SWITCH LOGFILE is used inside an RMAN backup script. Because that command is asynchronous, RMAN may attempt to back up a log that has not finished archiving yet. Replacing it with ALTER SYSTEM ARCHIVE LOG CURRENT resolves the issue, as covered in the archive log synchronization section above.
Managing archive logs manually keeps your Oracle environment recoverable, but it also introduces risk. A full archive destination triggers ORA-00257 and blocks user connections. A missed log gap leaves your Data Guard standby out of sync. And if archiving stalls during a backup window, your RMAN job may fail without warning. These are not edge cases — they are the everyday realities of running Oracle in production.
A dedicated backup solution removes much of that operational burden. i2Backup is an enterprise backup platform built to protect Oracle environments with minimal manual intervention.
For environments that need continuous protection rather than scheduled backups, i2CDP replicates data changes at the byte level in real time, reducing RPO to near zero. For high availability and automatic failover between Oracle instances, i2Availability provides real-time replication with sub-second switchover — keeping production running even when the primary environment fails.
Together, these solutions cover the full spectrum of Oracle data protection, from routine archive log management to site-level disaster recovery. And you can click the button to get free trail of solutions mentioned above.
The three archive log commands covered in this guide serve different purposes, and using the wrong one at the wrong time has real consequences. ARCHIVE LOG CURRENT is the reliable choice for backup scripts because it waits for archiving to complete before returning control. ARCHIVE LOG ALL is the right tool when logs have fallen behind and need to be caught up manually. ARCHIVE LOG STOP should be left alone in almost every situation — its behavior in modern Oracle is unpredictable enough to bring a database to a halt.
For day-to-day operations, pairing these commands with a solid understanding of common errors like ORA-00257 and ORA-16038 will help you resolve issues quickly before they affect users.
That said, manual archive log management only goes so far. If your Oracle environment runs in production, automating backup schedules, retention policies, and log capture through a solution like i2Backup by Info2soft reduces the risk of human error and keeps your recovery objectives within reach — without relying on someone remembering to run a command at the right time.
