Archivelog and Noarchivelog Modes: Module Summary

This module opened with a question that sounds simple and isn't: what kind of backup will you actually rely on when something goes wrong? Everything since has been building toward a specific, mechanical answer, one setting, a database's archiving mode, that determines which recovery options are even on the table. NOARCHIVELOG mode and ARCHIVELOG mode aren't a basic option and an advanced option; they're two genuinely different operating models with different costs, different guarantees, and different failure modes. This closing lesson pulls the six lessons that got you here back together.

Oracle divides protection into two classes, and the module opened by making sure that distinction was solid before building anything on top of it. A physical backup copies the actual files the instance needs to reconstruct the database: data files, control files, the SPFILE, and archived redo logs. A logical backup extracts objects, tables, schemas, PDB contents, into a dump file that's independent of any of those physical file names. Physical backups are the foundation of any recovery plan; logical backups are a genuinely useful supplement for migration, refresh, and object-level repair, but Oracle's own documentation is explicit that they are "not sufficient protection against data loss without physical backups."

Recovery Manager, RMAN, is the engine Oracle expects for physical backups, and it does considerably more than a plain file copy: whole-database, tablespace, data file, control file, and archived log backups; incremental backups at level 0 and level 1, with block change tracking keeping them fast even on a large database; encryption using AES256 in XTS mode by default; and destinations ranging from the Fast Recovery Area to tape, Recovery Appliance, or cloud object storage like OCI Object Storage and Amazon S3. A recovery catalog is optional, most single-database environments never need one, but it becomes worth the extra infrastructure once you're managing enough databases, or need longer backup history, that the control file's own limited retention window would actually hurt.

Data Pump, not the legacy exp/imp utilities, is the current tool for logical backups, built on DBMS_DATAPUMP and DBMS_METADATA. One genuinely significant fact worth carrying forward from this module: Data Recovery Advisor is desupported starting in 26ai, along with the RMAN commands built around it, LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE, with no replacement feature. Diagnosing and repairing a failure is a more manual process now than it was when DRA could walk you through it.

The decision this module kept coming back to isn't really "physical or logical," it's a short sequence of questions in a specific order: can the database come down for a consistent copy, or does it need to stay up; does a media failure need to reconstruct the whole CDB, or just move or refresh specific objects; and does the recovery point objective demand something faster than a restore, in which case Flashback technologies and a properly sized Fast Recovery Area complement the backup strategy rather than replacing it. Most real environments end up using both physical and logical backups together, not choosing one and discarding the other, physical for disaster recovery, logical for portability and object-level repair. And whichever path you land on, a backup strategy is only as good as its last successful restore, not its last successful backup job; an untested backup is an assumption, not a recovery plan.

NOARCHIVELOG mode is still the default at database creation, and it's still available in 26ai, but this module spent real time establishing exactly how narrow its protection actually is. It guards against instance failure, the ordinary crash-and-restart case every database handles automatically regardless of archiving mode, but it does nothing for media failure. Lose a data file after your last consistent backup, and everything committed between that backup and the failure is simply gone, not delayed, not partially recoverable, gone. If your last backup ran Sunday at midnight and the failure hits Wednesday afternoon, Wednesday's restore takes you back to Sunday, full stop.

The operational cost is just as real as the data-loss risk: because the only valid backup in this mode is a consistent one, taking a backup means shutting the database down, not just accepting a smaller recovery window. Online tablespace backups, point-in-time recovery, Flashback Database, and Data Guard redo transport are all simply unavailable here, not degraded, unavailable. NOARCHIVELOG mode is a legitimate choice for development, test, or training databases, or for small systems with frequent backups and a genuinely acceptable loss window, but it's a deliberate policy decision, not a default you fall into by not thinking about it.

Not every file loss is equally serious, and this module made that distinction sharper than older material tends to. A lost tempfile is barely a recovery event at all, RMAN doesn't back tempfiles up in the first place, since they can't hold permanent data, and it simply recreates them during recovery; without RMAN, one ALTER TABLESPACE temp ADD TEMPFILE statement fixes it with the database staying open the entire time. That's a real change from much older Oracle material, which walked through an elaborate offline-drop-and-recreate procedure built for an architecture, datafile-based temporary tablespaces, that modern Oracle simply doesn't use anymore.

Losing an ordinary data file is the scenario that actually matters. The RMAN path there is RESTORE CONTROLFILE, mount, RESTORE DATABASE, then RECOVER DATABASE NOREDO, which applies only consistent incremental backups without searching for archived redo that was never generated, followed by OPEN RESETLOGS. The recovered database reflects the last applied consistent incremental, not the moment of failure, and that gap is exactly the size of whatever happened between your last incremental and the failure itself. None of the options this module walked through, restoring a consistent backup, rolling incrementals forward with NOREDO, a Data Pump logical rebuild as a partial supplement, are workarounds for a missing Oracle feature. They're the honest, complete set of what's actually possible once redo has already been discarded, which is precisely the trade NOARCHIVELOG mode was built to make. Laid out plainly, NOARCHIVELOG mode gets you through an instance crash, a restore to your last consistent backup, and rolling that backup forward with closed incrementals; it does not get you recovery of one data file to its current SCN once the covering redo is gone, point-in-time recovery to an arbitrary moment, or any of online backups, Flashback Database, or Data Guard redo shipping. That's not a partial list of limitations to work around; it's the complete boundary of what the mode can do.

ARCHIVELOG mode is what changes the picture entirely, by copying every filled redo log group to an archived log before it can be reused. That archive stream, not a nightly backup by itself, is what "continuous data protection" actually means: a backup plus every committed change recorded since. It's what makes hot backups possible in the first place, since a data file backed up while it's actively being modified is fuzzy at any single instant, and archived redo is exactly what supplies the missing changes to make the restored file consistent again.

A long list of capabilities this module covered depend on that same stream: complete media recovery to the last committed transaction, point-in-time recovery to an arbitrary SCN or moment, block media recovery for a single corrupted block rather than a whole file, Flashback Database, Data Guard redo transport, and PDB or tablespace point-in-time recovery. One detail worth remembering specifically: Flashback Query and Flashback Time Travel use undo data and history tables, not archived redo, so they complement ARCHIVELOG mode without depending on it, and they're not a substitute for it during an actual media failure.

This module also surfaced a gap worth taking seriously: ARCHIVELOG mode protects every change that generates redo, but a table or index marked NOLOGGING generates none at all, and you cannot recover an object created that way even in ARCHIVELOG mode. FORCE LOGGING is what closes that hole, by overriding NOLOGGING requests at the database or tablespace level, which is exactly why this course keeps pairing the two terms rather than treating ARCHIVELOG mode alone as sufficient.

Put the two modes side by side and the contrast is stark: ARCHIVELOG mode supports online backups, point-in-time recovery through archived logs, and reuses redo log groups only once they've actually been archived, at the cost of extra storage for those archives. NOARCHIVELOG mode supports none of the first two, reuses redo the moment it's no longer needed for crash recovery regardless of whether it's been preserved anywhere, and needs minimal extra storage precisely because it's keeping so much less.

The last lesson in this module turned all of this into a concrete procedure. Configure the archive destination first, while the database is still open, either the Fast Recovery Area or an explicit filesystem or ASM path, sized from actual redo generation rather than a guess. Then take the outage: SHUTDOWN IMMEDIATE, never ABORT, STARTUP MOUNT, ALTER DATABASE ARCHIVELOG, ALTER DATABASE OPEN, followed immediately by ALTER DATABASE FORCE LOGGING so the NOLOGGING gap doesn't survive the switch. Verify it actually worked, a mode flag changing isn't the same thing as archiving actually happening, by forcing a log switch and confirming a new archived log shows up. In a CDB, this is a container-level setting; PDBs inherit it from the root rather than toggling it individually. In RAC, the whole cluster has to be mounted exclusively for the mode change, which means stopping every instance, not just one.

The most common ways this goes wrong all showed up as concrete pitfalls rather than abstract warnings: switching modes before the destination is actually configured, which succeeds immediately and fails later at the first log switch; pointing the destination at a disk that's already tight on space, the single most common way a freshly-archivelog database ends up hanging; and reaching for SHUTDOWN ABORT out of impatience, which only delays things further, since Oracle won't change the archiving mode until instance recovery has actually completed.

Step back and the whole module is really one argument, made from several different angles: the cost of ARCHIVELOG mode, extra storage, extra monitoring, an archive destination to manage, buys you something NOARCHIVELOG mode structurally cannot provide, the ability to recover forward from a failure instead of only backward to your last backup. Everything from here on in this course, RMAN backup strategy in depth, Data Guard, Flashback technologies, assumes that archived redo stream exists. The next module builds directly on that assumption.

Click the Quiz link below to complete a module wrap-up quiz.
Database Archiving Mode - Quiz

Click the Exercise link below to complete this module's Troubleshooter.
Duplex Archivelog Mode - Exercise
The next module examines manual and automatic archiving options.