Archivelog and Noarchivelog Overview

Managing a database means making some fundamental decisions, and one of the first is what kind of backup you'll actually rely on: physical or logical. This lesson introduces both at a conceptual level, then this module narrows in on physical backups specifically, and in particular, what running a database in noarchivelog versus archivelog mode actually means for your backup and recovery options. The deeper mechanics of logical backups, meaning Data Pump itself, come later in this series; what you need here is enough of the physical-versus-logical picture to understand why this module is built around archivelog mode in the first place.

Your options for backup and recovery in noarchivelog mode are genuinely limited, and this module addresses exactly where those limits are. Archivelog mode gets a fuller treatment in the modules that follow, and backup and recovery strategies built around it are the subject of the third course in this series.

By the end of this module, you should be familiar with:

1. The differences between physical and logical backups
2. The differences between online and offline backups
3. The differences between archivelog and noarchivelog mode
4. Operating a database in noarchivelog mode
5. Configuring a database for archivelog mode and automatic archiving
6. Configuring a database for duplex archivelog mode

By the end of this module, you'll be able to back up and restore a database running in noarchivelog mode specifically. Let's get started.

The right choice between physical and logical backups depends on what you're actually protecting against: a database's specific requirements, how you intend to use the backup, how much flexibility recovery needs to offer, and the database's size and complexity.

A physical backup is a copy of the actual files that make up the database: data files, control files, the server parameter file (SPFILE), archived redo logs, and, when required, online redo logs. It's a byte-for-byte copy of the database, and it can be taken while the database is online (a hot backup) or offline (a cold backup).

• Use case: physical backups are what disaster recovery scenarios actually depend on. They're the right tool when the requirement is restoring the entire database or performing point-in-time recovery.
• Advantages: generally faster to restore, since recovery mostly means copying files back to where they belong; comprehensive, since the entire database is included by definition.
• Disadvantages: can be large, since they include the whole database, and they're less flexible for partial or object-level recovery, restoring one dropped table from a physical backup alone isn't really what it's built for.

In 26ai, the recommended mechanism for physical backups is Recovery Manager (RMAN), integrated directly with the database engine. RMAN provides whole-database, tablespace, data file, control file, and archived log backups; incremental backups with block change tracking; unused-block and binary compression plus encryption; image copies that can be rolled forward with incremental backups (RECOVER COPY); automatic cataloging in the control file, or optionally a separate recovery catalog; and a wide range of destinations, including the Fast Recovery Area, tape via an SBT library, OCI Object Storage, Amazon S3, and Zero Data Loss Recovery Appliance. RMAN can also validate backups at the block level, including a CHECK LOGICAL option that looks for logical corruption once the physical checks have already passed.

User-managed, OS-level copies are still supported, but they require manually coordinating ALTER TABLESPACE ... BEGIN/END BACKUP for hot backups, and they don't get RMAN's incremental, compression, or cataloging capabilities. Because physical backups are the only method that reliably supports recovery from media failure, a complete database restore, and point-in-time recovery of an entire CDB or PDB using redo, Oracle's own documentation calls them the foundation of any sound backup and recovery strategy.

A few things worth knowing that are specific to 26ai: you can now designate a separate disk location for flashback logs rather than leaving them inside the Fast Recovery Area; cross-platform transport of tablespaces and PDBs is simplified, using ordinary RMAN backups plus metadata instead of a dedicated transportable-tablespace workflow; and there's a native SBT library for Recovery Appliance built in (libra.so on Linux, orara.dll on Windows), rather than requiring a separately installed media management library. There's also a genuinely significant removal to know about: 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. There's no replacement feature; diagnosing and repairing failures goes back to being a more manual process than it was when DRA could walk you through it.

A logical backup extracts database objects, tables, indexes, views, PL/SQL, grants, and so on, along with their data, into a platform-independent dump file. The standard tool is Oracle Data Pump (expdp/impdp), built on the DBMS_DATAPUMP and DBMS_METADATA packages. The legacy exp/imp utilities still exist but aren't recommended for new work.

• Use case: migrating data between databases, versions, or platforms; recovering a specific object rather than the whole database; pulling a subset of data for development or testing.
• Advantages: flexible enough to recover individual objects, portable across different database structures and versions, and usually smaller than an equivalent physical backup.
• Disadvantages: restoring is generally slower, since data has to be reinserted through SQL rather than copied as files, and logical backups don't capture the physical file layout, control file metadata, or a continuous redo stream, so they can't by themselves recover from media failure or provide a consistent point-in-time restore of an entire production database.

Oracle's own framing is direct about this: logical backups are "a useful supplement... but... not sufficient protection against data loss without physical backups."

1. Recovery requirements: complete disaster recovery calls for physical backups; selective recovery or migration calls for logical ones.
2. Database downtime: physical backups can run while the database stays online; logical backups may need downtime depending on the method and activity level.
3. Database size: physical backups scale more practically for large databases; a full logical export and import can become impractical purely on time and space.
4. Flexibility and portability: logical backups win here, offering partial recovery and portability across architectures and versions that a physical backup can't match.
5. Backup window: how much time you actually have to run a backup can push the decision either way; physical backups integrate well with media management solutions built for speed.
6. Resource utilization: logical backups tend to be more CPU and I/O intensive, since exporting and importing data is more work than copying files.
7. Data specificity: cloning a specific slice of data for development or testing is a logical-backup job.

Most real environments use both, physical backups for disaster recovery, logical backups for portability and object-level recovery, rather than treating the choice as either/or. A complete 26ai strategy starts with a well-tested RMAN physical backup regimen, including actual restore-and-recovery drills, and layers Data Pump exports on top for the cases physical backups don't handle well. Flashback Database, Flashback Table, and PDB-level point-in-time recovery further shrink the set of situations where a full restore is even necessary.

Everything above is background for the question this module is actually built around, and it's worth answering directly here rather than only in the lessons that follow. A database's LOG_MODE determines what happens to a filled online redo log group once LGWR switches away from it, and that one setting changes what kinds of backups you're even allowed to take.

In ARCHIVELOG mode, you can back up the database while it's open. An open-database backup is called an inconsistent backup, since it can contain changes made after its own checkpoint, but as long as you have the archived redo logs needed to bring it forward, an inconsistent backup protects your data just as effectively as a consistent one. A basic RMAN backup in this mode looks like:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

In NOARCHIVELOG mode, the only valid backup is a consistent one, which means the database has to be shut down cleanly and mounted, not open, before you can back it up at all:

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP FORCE DBA;
RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;
RMAN> BACKUP DATABASE;

That requirement, a full outage just to take a backup, is the real cost of noarchivelog mode, and it's why this module spends real time on it: it isn't a lesser version of archivelog mode, it's a fundamentally different operating model with a much narrower set of options. Recovery is narrower too. Media recovery isn't possible in NOARCHIVELOG mode at all, because no archived redo logs exist to roll forward with; restoring a consistent backup gets you back to exactly the moment that backup was taken, and anything committed after it is simply gone. About the only flexibility NOARCHIVELOG mode offers beyond a flat restore is recovering with incremental backups, applied with the NOREDO option so RMAN doesn't try to apply archived logs that don't exist, which narrows the data-loss window somewhat without ever eliminating it the way archivelog mode can.

That's the trade this module is going to walk through in detail: noarchivelog mode is simpler to operate and cheaper in storage, since there's no archive destination to manage, but it accepts real data loss as the price, and it forces backups to happen during a maintenance window rather than whenever you choose. Archivelog mode costs more to run and manage, but it's what makes online backups, point-in-time recovery, and Data Guard possible in the first place. The next several lessons work through both sides of that trade in practice, starting with noarchivelog mode's own limits in more depth.