Lesson 7

This module explained how Oracle AI Database 26ai protects and restores a database that operates in NOARCHIVELOG mode. The central lesson is that this mode creates a deliberate recovery boundary. Oracle continues to generate online redo, but a filled redo log group can be reused without first being archived. After older redo has been overwritten, it is no longer available to roll an old datafile forward following media failure.

A dependable NOARCHIVELOG recovery strategy therefore begins with a usable, consistent whole-database backup. If storage fails, the normal physical recovery point is the checkpoint represented by that backup, or a later checkpoint captured by an applicable chain of consistent incremental backups. Committed changes that exist only after the latest usable recovery point cannot be recreated by RMAN.

This limitation does not make NOARCHIVELOG mode inherently incorrect. It can be appropriate for training databases, development systems, read-mostly repositories, and databases that can be rebuilt from an authoritative external source. It is a poor choice when the business requires online backups, point-in-time recovery, Data Guard, or recovery of nearly all committed transactions after storage loss.

An unexpected shutdown does not automatically require restoration from backup. If the datafiles, control files, and required online redo survive, Oracle normally performs instance recovery when the instance starts. It reads persistent redo from the checkpoint position, rolls recorded changes forward, and uses undo to reverse uncommitted work.

The System Global Area and redo log buffer are volatile memory. They disappear when the instance terminates and are not restored as backup assets. The starting point for instance recovery is determined by checkpoint information in persistent database structures, not by the date of the latest backup.

Media recovery addresses damaged or unavailable files. If a storage failure destroys a current datafile and the DBA restores an older copy, Oracle needs the intervening changes to make that file consistent with the rest of the database. An ARCHIVELOG database can use retained archived redo for that purpose. A NOARCHIVELOG database may have already overwritten the required history, so replacing only the damaged file is normally insufficient.

The reliable NOARCHIVELOG response is usually to restore the complete set of permanent datafiles from the same consistent backup. This returns the CDB, including its required root, seed, and PDB files, to a compatible checkpoint. Consistent incremental backups can sometimes advance that baseline, but they cannot supply changes that were never captured in a backup.

RMAN cannot back up active datafiles while a database is open in NOARCHIVELOG mode. A standard baseline begins with a clean shutdown using NORMAL, IMMEDIATE, or TRANSACTIONAL, followed by startup in MOUNT state. Mounting after SHUTDOWN ABORT does not by itself make the database consistent because instance recovery may still be required.

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE
2>   TAG 'NOARCHIVELOG_LEVEL0';
RMAN> ALTER DATABASE OPEN;

A level 0 incremental can serve as the parent of later level 1 incrementals. An ordinary full backup does not become an incremental parent merely because it contains all used blocks. If the strategy relies on consistent incrementals, those backups must also be created from an appropriate cleanly shut down and mounted state.

The backup plan must include more than datafile bytes. Configure and verify control-file and SPFILE autobackups. Protect encryption keys, credentials, and media-manager settings. Keep at least one recoverable copy beyond the storage failure domain containing the production datafiles. A fast recovery area on the same failed storage does not provide an independent recovery copy.

Do not judge a backup solely by its completion message. LIST BACKUP, CROSSCHECK, and validation report different facts. The strongest evidence is an isolated restore rehearsal that proves the team can locate the media, decrypt it, rebuild the startup environment, restore the files, open the required PDBs, and validate the application within the approved recovery time.

The recovery point objective, or RPO, measures the maximum acceptable data-loss interval. In a basic NOARCHIVELOG strategy, it is governed by the age of the latest usable consistent backup, not merely by the intended schedule. If the last usable backup completed at midnight and storage fails late the following day, nearly a day of committed work may be outside the recovery boundary.

The recovery time objective, or RTO, measures how long the service can remain unavailable. It must include retrieving backup media, preparing replacement storage, restoring startup files when needed, transferring datafiles, applying eligible incrementals, opening the CDB and PDBs, recreating tempfiles, and validating the applications. Backup frequency alone says nothing about whether several terabytes can be restored within the required outage window.

Some organizations can reconstruct lost work from source feeds, message queues, logical exports, or independent application records. Those techniques may reduce the business loss, but they are application reconciliation methods rather than Oracle media recovery. Their completeness, ordering, duplicate handling, and auditability must be designed and tested before an incident.

Review the logging-mode decision as the database grows or becomes more important. If the organization cannot accept the measured data-loss window or the outage required to create frequent consistent backups, enable ARCHIVELOG mode and adopt an online RMAN strategy with protected redo.

The exact commands depend on what survived. In the common training case, the instance can start and mount with a usable control file, and RMAN can locate a consistent whole-database backup. Previewing and validating the selected restore source reduces avoidable surprises:

RMAN> REPORT SCHEMA;
RMAN> LIST BACKUP SUMMARY;
RMAN> RESTORE DATABASE PREVIEW SUMMARY;
RMAN> RESTORE DATABASE VALIDATE;

After the recovery decision has been approved, restore the complete database. When an applicable chain of consistent incremental backups exists, RECOVER DATABASE NOREDO can apply it without attempting archived-redo recovery:

RMAN> STARTUP FORCE MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE NOREDO;
RMAN> ALTER DATABASE OPEN RESETLOGS;

This is a teaching pattern, not a universal script. The required startup state and final open command depend on whether the current or a backup control file is used, whether recovery was performed, and which documented NOARCHIVELOG procedure applies. OPEN RESETLOGS belongs to the incremental-recovery workflow shown in this module and to other specific recovery cases. It should not be added to every restore by habit.

A backup tag helps identify backup records, but it does not prove consistency or automatically limit every incremental selected during recovery. Confirm the DBID, incarnation, checkpoint, file coverage, and selected pieces. Do not clear an online redo group as a routine way to force the database open. Clearing required redo can destroy the only remaining records needed for recovery and can invalidate recovery options.

After opening the database, inspect the alert log and verify the actual recovery point. Open the required PDBs, check temporary tablespaces, run application integrity tests, and reconcile transactions that occurred after the restored checkpoint. Then create a new consistent backup according to the approved NOARCHIVELOG schedule.

Failed storage may prevent RMAN from writing files to their recorded paths. The alternate-location sequence is SET NEWNAME, RESTORE, SWITCH, and RECOVER. SET NEWNAME selects the replacement location; RESTORE writes the backup contents; SWITCH updates the control file so the restored copies become current; and RECOVER applies the available recovery inputs.

RMAN> RUN {
2>   SET NEWNAME FOR DATABASE
3>     TO '/u02/oradata/PRODCDB/%U';
4>   RESTORE DATABASE;
5>   SWITCH DATAFILE ALL;
6>   RECOVER DATABASE NOREDO;
7> }

The %U substitution produces collision-resistant names. %b preserves each base name but is safe only when all base names are unique in the destination. For ASM, an individual new name can identify a healthy disk group such as +DATA2. For Oracle Managed Files, set the intended DB_CREATE_FILE_DEST and use SET NEWNAME FOR DATABASE TO NEW. Merely changing that parameter does not silently redirect every restore.

In ARCHIVELOG mode, sufficient redo can support a targeted restore of one datafile or one PDB. That is not the normal NOARCHIVELOG response because the old file usually cannot be advanced to the current database checkpoint. A changed destination does not change this recovery limitation. Restore the complete consistent database set when the required redo is unavailable.

Control files and online redo logs require separate decisions. If one multiplexed control-file member survives, repair the missing member from a valid current copy instead of automatically restoring an older control file. Do not apply a generic CLEAR UNARCHIVED LOGFILE command to an online redo loss. Determine whether another member survives and whether the affected group is current, active, or inactive.

If the source datafile remains healthy and the task is a planned storage migration, consider the supported ALTER DATABASE MOVE DATAFILE workflow instead of restoring an older backup. Recovery and planned relocation solve different problems.

SQL> SELECT name, open_mode, log_mode
2  FROM   v$database;

SQL> SELECT con_id, file#, name, status
2  FROM   v$datafile
3  ORDER  BY con_id, file#;

SQL> SELECT name FROM v$controlfile;

SQL> SELECT group#, member
2  FROM   v$logfile
3  ORDER  BY group#, member;

Use the following quizzes to review the module's principal recovery decisions:

• Restoring Database: Required Components Quiz
• Recovering a NOARCHIVELOG Database Quiz

Click the Quiz link below to review your understanding of recovering a database without archiving.
Recovery Scenario - Quiz