Configuring Archivelog Mode in Oracle AI Database 26ai

Enabling ARCHIVELOG mode still follows the same basic shape it always has: the database must be mounted, not open, your archive destination needs to exist with enough space, and you take a short planned outage. 26ai's own best-practice guidance also expects ARCHIVELOG mode to be paired with FORCE LOGGING, covered in the previous lesson, for it to actually deliver on recoverability, Data Guard, and Flashback.

Before you start, you'll want SYSDBA access, a planned outage window (a clean SHUTDOWN IMMEDIATE is required, not ABORT), and enough disk for archived redo, whether that's the Fast Recovery Area or a dedicated archive filesystem or ASM disk group. Plan on taking a fresh backup right after you enable archiving, too; a backup taken while the database was still in NOARCHIVELOG mode can't serve as the starting point for point-in-time recovery using the redo you're about to start generating, since none of that redo existed when the old backup was made.

Everything in this lesson sets parameters with ALTER SYSTEM SET ... SCOPE=BOTH against a server parameter file (SPFILE), the modern default and the approach this course has used since its lesson on the database configuration file. If you're still working from a text PFILE (init.ora) instead, that's still fully supported, just less convenient for this kind of ongoing change, see Additional Database Parameters for how to edit and rebuild one.

Check your current mode before doing anything else:

SELECT log_mode, force_logging, flashback_on FROM v$database;
ARCHIVE LOG LIST;
SHOW PARAMETER db_recovery_file_dest;
SHOW PARAMETER log_archive_dest;

NOARCHIVELOG in that first query's result means archiving is currently off.

This part can be done while the database is still open. You have two reasonable approaches.

Option A: use the Fast Recovery Area (the recommended default).

ALTER SYSTEM SET db_recovery_file_dest_size = 40G SCOPE=BOTH;
ALTER SYSTEM SET db_recovery_file_dest = '/u01/app/oracle/fast_recovery_area' SCOPE=BOTH;
-- or, on ASM: '+RECO'
ALTER SYSTEM SET log_archive_dest_1 =
  'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)' SCOPE=BOTH;

Option B: an explicit filesystem or ASM path instead.

ALTER SYSTEM SET log_archive_dest_1 = 'LOCATION=/u02/archivelog' SCOPE=BOTH;
-- an optional second destination
ALTER SYSTEM SET log_archive_dest_2 = 'LOCATION=/u03/archivelog' SCOPE=BOTH;
ALTER SYSTEM SET log_archive_min_succeed_dest = 1 SCOPE=BOTH;

Current high-availability guidance recommends giving LOG_ARCHIVE_DEST_1 an alternate local destination on genuinely different storage, so a single full disk doesn't hang the instance. This is the modern replacement for the older duplexed-archive-log approach some training material still describes, using LOG_ARCHIVE_DUPLEX_DEST; numbered destinations give you the same redundancy with more flexibility, since each one can point somewhere different and be managed independently.

You can also set a naming format, if you want one other than the default:

ALTER SYSTEM SET log_archive_format = 'arch_%t_%s_%r.arc' SCOPE=SPFILE;

That last one needs an instance restart to take effect, since it's set with SCOPE=SPFILE rather than BOTH. Whichever option you choose, create the actual directories and make sure the Oracle OS user owns them before you move on to actually switching modes.

It's worth sizing the destination before you commit to it rather than after. A rough starting point: look at how much redo your database actually generates in a typical day, V$LOG and AWR both report this, and size for at least a few days of archived redo plus headroom, not just enough for one day's worth. Running out of archive space later isn't a minor inconvenience; it's exactly the scenario covered below that can stall the whole database.

For a single instance or CDB:

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

Don't use SHUTDOWN ABORT here. An abrupt shutdown can leave the database needing instance recovery, and Oracle won't let you change the archiving mode until that recovery has actually happened; recover first, then shut down cleanly before you try again.

Once the database is back open, this is also the natural point to enable the companions this course keeps pairing with ARCHIVELOG mode:

ALTER DATABASE FORCE LOGGING;
-- optional, only if you also want Flashback Database
ALTER DATABASE FLASHBACK ON;
ALTER SYSTEM SWITCH LOGFILE;

ARCHIVE LOG LIST;
SELECT log_mode FROM v$database;
SELECT sequence#, name, applied, deleted
FROM v$archived_log
ORDER BY sequence#;

You're looking for LOG_MODE = ARCHIVELOG, automatic archiving enabled, and a genuinely new archived log entry appearing after you force a log switch, not just a mode flag that changed but no actual archiving activity to back it up.

A handful of mistakes account for most of the trouble people run into here. Forgetting to configure the archive destination before switching modes is one; ALTER DATABASE ARCHIVELOG succeeds even without a valid destination configured, and the failure shows up later, at the first log switch, when there's suddenly nowhere for the archiver to actually write. Pointing the destination at a disk that's already tight on space is another; that FRA-fills-up scenario mentioned earlier isn't hypothetical, it's the single most common way a newly-archivelog database ends up hanging on its next log switch. And using SHUTDOWN ABORT out of impatience during the outage window is a third; it just delays you further, since you'll need to recover the instance before Oracle will even let you attempt the mode change.

One more worth naming specifically: enabling ARCHIVELOG mode without also enabling FORCE LOGGING. As the previous lesson covered, any table or index created with NOLOGGING still won't be protected by your archived redo stream even after this whole procedure is complete, that gap doesn't close on its own just because the database is now in ARCHIVELOG mode.

ALTER DATABASE ARCHIVELOG requires the database to be mounted exclusively, which means stopping the whole cluster first, not just one instance:

srvctl stop database -d <db_unique_name>
srvctl start database -d <db_unique_name> -o mount
sqlplus / as sysdba
ALTER DATABASE ARCHIVELOG;
EXIT
srvctl stop database -d <db_unique_name>
srvctl start database -d <db_unique_name>

Use a shared destination that every node can reach, ASM's +RECO or a cluster filesystem; each thread archives its own redo independently once the mode is on.

ARCHIVELOG mode is a CDB property, not a per-PDB one, consistent with everything this course has already established about redo belonging to the CDB as a whole. You enable it on the root, and every PDB in that CDB inherits redo archiving from the container; there's no separate switch to flip inside an individual PDB.

A few things belong on your checklist once ARCHIVELOG mode is actually running:

• Take a full RMAN backup that includes the archived logs, this is your new baseline.
• Back up and delete archived logs on a regular schedule, so the Fast Recovery Area doesn't fill up. A full FRA with nowhere else to send archives is exactly how a database ends up "archiver stuck," unable to reuse redo log groups.
• Size the Fast Recovery Area from actual redo generation, using V$LOG, AWR data, or V$RECOVERY_AREA_USAGE, rather than guessing at a number.
• For Data Guard specifically, ARCHIVELOG mode plus FORCE LOGGING remain expected prerequisites in 26ai.

One environment where this whole lesson doesn't apply: Autonomous AI Database is managed by Oracle, and you typically can't toggle ARCHIVELOG mode yourself there at all.

Rarely what you actually want in production, but worth knowing the mechanics:

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

This drops point-in-time recovery until you turn archiving back on and take a fresh full backup afterward. Your existing backups don't become worthless the moment you do this, they're still consistent, restorable snapshots of the database as it was, but they stop being useful as a baseline for the kind of forward recovery ARCHIVELOG mode makes possible.

It's worth closing on why this lesson matters for the rest of this course. Everything this module spent two lessons establishing about NOARCHIVELOG mode's limits, no online backups, no point-in-time recovery, a total loss of everything since the last closed backup, exists specifically because archived redo wasn't there to fall back on. This lesson is the other half of that story: the actual mechanics of making sure it is there. Once ARCHIVELOG mode is on, configured correctly, and paired with FORCE LOGGING, the recovery options that were simply unavailable in the last two lessons become the normal, expected path instead.

The next lesson is the module wrap-up.