When operating in "NOARCHIVELOG mode". Here's a breakdown to confirm the validity of each point:
-
NOARCHIVELOG Mode Behavior
In NOARCHIVELOG mode, Oracle does not archive the redo logs after they are filled. This has significant implications for recovery:
- You can only recover the database to the point of the last whole consistent backup.
- Media recovery cannot apply redo logs to bring the database up-to-date beyond the last backup.
Thus, the most recent whole closed database backup is essential.
-
Consistent Whole Database Backup
For the database to be restored and opened:
- All datafiles and control files must have the same checkpoint SCN (System Change Number) and log sequence number.
- Files with inconsistent SCNs indicate that the database was not closed properly during the backup, rendering recovery impossible in NOARCHIVELOG mode.
- Read-only tablespaces or offline datafiles can be excluded from this requirement because they do not change.
In summary:
- If files are inconsistent, Oracle will not allow the database to open.
-
No Redo Logs Applied
In NOARCHIVELOG mode:
- Redo logs cannot be applied during recovery because the database is only recoverable to the consistent state at the time of the backup.
- Oracle does not retain archived redo logs to reconstruct changes after the last consistent backup.
-
Files Required for Recovery
To perform recovery in NOARCHIVELOG mode, the following files must be present:
- Datafiles: Essential for storing database data.
- Control Files: Required to manage the structure and state of the database.
- Redo Logs: The current redo logs are necessary to achieve database consistency during startup.
- Parameter Files (PFILE/SPFILE): Needed to configure and start the database instance.
- Password File: Required for authentication if operating in SYSDBA mode.
Key Conclusion
In Oracle 19c:
- If media failure corrupts any datafiles in a database running in NOARCHIVELOG mode, you can only recover the database using the most recent consistent whole closed backup.
- All files must have synchronized checkpoint numbers and SCNs, except for read-only or offline tablespaces.
- No redo logs can be applied during recovery.
The above information is accurate for Oracle 19c.
Recovering parameter and password files is optional. You only need to restore these files if they are damaged.
The next lesson explains the implications for recovery when a database is running in NOARCHIVELOG mode.
Restoring a database running in NOARCHIVELOG mode is similar to restoring a database in ARCHIVELOG mode. The main differences are:
- Only consistent backups can be used in restoring a database in NOARCHIVELOG mode.
- Media recovery is not possible because no archived redo logs exist.
You can perform limited recovery of changes to a database running in NOARCHIVELOG
mode by applying incremental backups. The incremental backups must be consistent, like all backups of a database run in NOARCHIVELOG mode, so you cannot make backups of the database when it is open.
When you are recovering a NOARCHIVELOG database, specify the NOREDO option on the RECOVER command to indicate that RMAN should not
attempt to apply archived redo logs. Otherwise, RMAN returns an error. To recover a NOARCHIVELOG database with incremental backups:
- After connecting to the target database and the recovery catalog, place the database in a mounted state:
STARTUP FORCE MOUNT
- Restore and recover the database.
For example, you can perform incomplete recovery with the following commands:
RESTORE DATABASE
FROM TAG "consistent_whole_backup";
RECOVER DATABASE NOREDO;
- Open the database with the RESETLOGS option. For example, enter the following command:
ALTER DATABASE OPEN RESETLOGS;