Noarchivelog Mode in Oracle AI Database 26ai

NOARCHIVELOG mode is still available in Oracle AI Database 26ai, and it's still the default at database creation, but its use is discouraged outside a fairly narrow set of circumstances.

What NOARCHIVELOG mode means:

1. No redo log archiving. Filled online redo log groups are not archived; they're simply overwritten once they're no longer needed. Any change recorded in one is gone the moment it's reused.
2. Limited recovery. You can only recover the database up to the most recent whole-database consistent backup. Any changes made since that backup are lost if a failure occurs.

When NOARCHIVELOG mode might actually make sense:

• Development, test, or training databases where losing recent transactions is genuinely acceptable
• Very small systems with frequent consistent backups and a short acceptable data-loss window
• Databases with minimal write activity, where the practical risk is low even if the theoretical exposure isn't zero
• A modest reduction in operational overhead: no archive destination to size or monitor, and no pressure on the Fast Recovery Area from accumulating archived logs

Why ARCHIVELOG mode is strongly preferred for anything that matters:

• Point-in-time recovery, restoring to a specific moment before a failure rather than only to the last backup, requires it
• Oracle Data Guard requires it as a prerequisite
• Modern database administration and risk management practice favors it by default, not as an exception

NOARCHIVELOG mode is technically supported and available; it just shouldn't be your default choice without a specific reason for it.

NOARCHIVELOG mode protects against instance failure: if the instance crashes, Oracle can still roll forward using the current online redo logs and then roll back uncommitted work, the same automatic instance recovery every database gets regardless of archiving mode.

It does not protect against media failure. If a data file is lost or corrupted after your last consistent backup, there's no redo to apply to catch up; you restore that last whole-database consistent backup and accept the loss of everything done since. That's the entire trade this mode makes.

Put a number on it to make the trade concrete: if your last consistent backup ran Sunday at midnight and a disk holding a data file fails Wednesday afternoon, you restore to Sunday midnight and every transaction between then and the failure is simply gone, not delayed, not partially recoverable, gone. In ARCHIVELOG mode, that same failure would cost you nothing beyond the time it takes to restore and roll forward through the archived redo generated since. The gap between those two outcomes is the entire reason this module spends real time on the distinction rather than treating it as a footnote.

You don't have to guess which mode a database is running in. From SQL*Plus:

ARCHIVE LOG LIST;

or, if you'd rather query it directly:

SELECT log_mode FROM v$database;

Switching modes requires the database to be mounted but not open, since the archiving mode is a fundamental, whole-database property that can't change while sessions are actively using the database. A typical switch to ARCHIVELOG mode looks like:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

Switching the other direction, back to NOARCHIVELOG, uses the same mount-then-alter pattern with ALTER DATABASE NOARCHIVELOG instead. One detail worth remembering: switching from ARCHIVELOG to NOARCHIVELOG doesn't retroactively invalidate archived logs you already generated, they're still perfectly good archived logs, but from that point forward, any recovery you might need can no longer depend on new ones existing.

Several things happen when a database runs in noarchivelog mode. As users generate changes, information moves from the redo log buffer to the current online redo log file, cycling from one file to the next as each fills. Every Oracle database needs at least two redo log groups for exactly this reason, covered in more depth in this course's Module 4, so there's always a next group to switch into. If a database has only two redo log files, the next log switch after both have been used starts writing over the first one again, and once that overwrite happens, whatever redo it held is gone for good.

REDO LOG BUFFER
LGWR
log1orc1.ora
log2orc1.ora

The diagram below walks through this cycle across three steps: LGWR writing to the current group, a log switch moving it to the next group, and that first group eventually becoming reusable once it's no longer needed.

Because there are no archived logs to fall back on, NOARCHIVELOG mode narrows your options considerably:

• Online (hot) whole-database backups that would need media recovery to be usable simply aren't a viable recovery path here.
• User-managed online tablespace backups (ALTER TABLESPACE ... BEGIN BACKUP) require ARCHIVELOG mode; they're not available in NOARCHIVELOG mode.
• The typical RMAN strategy is a consistent backup taken after a clean shutdown, or at minimum while the database is mounted following a consistent close.
• After a restore, recovery is limited: RMAN uses RECOVER DATABASE NOREDO, which applies consistent incremental backups but doesn't look for redo that was never archived in the first place. You then open with RESETLOGS.
• Point-in-time recovery, tablespace point-in-time recovery, Flashback Database, and Data Guard redo transport all require ARCHIVELOG mode; none of them work here.

If you need to take a data file offline while running in NOARCHIVELOG mode, use ALTER DATABASE DATAFILE ... OFFLINE FOR DROP. This doesn't delete the file, it marks it so the database can keep running without attempting media recovery that isn't possible in this mode anyway.

Block change tracking, covered elsewhere in this course as a way to speed up incremental backups, can be enabled in either archiving mode. It helps RMAN find changed blocks faster; it does not give NOARCHIVELOG mode any of the recovery capability that archived redo provides. The two are solving different problems.

With NOARCHIVELOG mode enabled, you really only have one dependable option: a cold backup. The database is shut down, and you take an operating system-level backup of every data file, along with the redo and control files. Restoring means an operating system restore of those same files, and you lose any data entered since that backup was taken. A typical RMAN version of that same idea looks like this:

SHUTDOWN IMMEDIATE;
STARTUP FORCE DBA;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
BACKUP
  INCREMENTAL LEVEL 0
  DATABASE
  TAG 'BACKUP_1';
ALTER DATABASE OPEN;

The double shutdown is deliberate, not a typo: it guards against the case where the database suffered instance failure or was previously closed with SHUTDOWN ABORT, forcing it up cleanly first so the backup that follows is taken from a genuinely consistent, mounted state.

There's a narrow alternative worth knowing about, even if it applies to a small slice of real databases: for a read-only database, one with very limited transaction activity, or one with enough disk to spare, you can size and multiplex your redo log groups generously enough that you effectively never overwrite one. That keeps every bit of redo history intact without ever switching to ARCHIVELOG mode, but it's a narrow fit, applicable to maybe a small percentage of Oracle databases in practice, not a general-purpose substitute for archiving.

In a CDB, archiving mode is set at the container level; every PDB in that CDB shares whatever archiving behavior the CDB has, including inheriting NOARCHIVELOG mode's inability to do media recovery if that's how the CDB is configured. Oracle's own 26ai high availability guidance is direct about this: production databases should run in ARCHIVELOG mode with FORCE LOGGING enabled whenever recoverability actually matters, and most of what 26ai environments commonly rely on, online backup, incremental-forever cloud protection, Recovery Appliance, Data Guard, Flashback Database, assumes archived redo exists in the first place. Treat NOARCHIVELOG as a deliberate data-loss policy you're choosing on purpose, not a performance tweak.

The next lesson is about media recovery with noarchivelog mode.