Archivelog | Noarchivelog   «Prev  Next»
Lesson 3Noarchivelog mode
ObjectiveDiscuss noarchivelog mode.

Discuss noarchivelog mode in Oracle

Yes, NOARCHIVELOG mode is still available and used in Oracle 19c. However, here's why its use is generally discouraged unless very specific circumstances apply:
What NOARCHIVELOG Mode Means
  1. No Redo Log Archiving: When the database is in NOARCHIVELOG mode, filled online redo logs (which contain all changes made to the database) are not archived. They are allowed to be overwritten.
  2. Limited Recovery: This means you can only recover the database up to the point of the most recent full backup. Any changes since that backup are lost if a failure occurs.

When NOARCHIVELOG Mode Might Be Used
  • Non-Critical Databases: For development or testing environments where data loss isn't a major concern, and frequent full backups are manageable.
  • Databases with Minimal Changes: If a database has very little update activity, and its structure is relatively static, the risk might be considered acceptable.
  • Legacy Compatibility: Some older applications may have been designed with NOARCHIVELOG mode in mind.

Why ARCHIVELOG Mode is Strongly Preferred
  • Point-in-Time Recovery: ARCHIVELOG mode allows you to restore the database to a specific moment in time before a failure, minimizing data loss.
  • Data Guard Support: ARCHIVELOG mode is a prerequisite to setting up Oracle Data Guard for disaster recovery.
  • Standards Compliance: Most modern database administration and risk management practices strongly favor ARCHIVELOG mode's better protection.

In Summary While NOARCHIVELOG mode is technically still supported in Oracle 19c, it should be considered an exceptional choice only made with strong justifications. For the vast majority of cases, ARCHIVELOG mode provides significantly better data protection and recovery options.


Remember that the database by default starts in noarchivelog mode. If we operate a database in noarchivelog mode we must perform either a logical backup or a physical offline mode backup. (Again, logical backups will be covered in the third part of this series, in the discussions on the Export/Import utilities.)

Noarchivelog mode

Several things happen when you operate a database in noarchivelog mode. As users access the database, information is written from the redo log buffer area to redo log files in a cyclical fashion. Information is first written to one redo log file, a log switch occurs and then information starts being written to the next redo log file. If there are only two redo log files, the next log switch will start to write data over the first redo log file. Once we start writing over the first redo log file, any information contained in this log file is lost.
The following series of images illustrates redo log file processing with noarchivelog mode enabled.
REDO LOG BUFFER
LGWR
log1orc1.ora
log2orc1.ora
This series of images illustrates the process of moving redo log buffer into our redo log files. This first image shows LGWR copying information from the redo log buffer and storing the information in log1orc1.ora. When log1orc1.ora fills up, a log switch occurs."
This image shows the log switch process. LGWR closes the first logfile, log1orc1.ora, when it is full and starts writing information from the redo log buffer to log2orc1.ora
1) This image shows the log switch process. LGWR closes the first logfile, log1orc1.ora, when it is full and starts writing information from the redo log buffer to log2orc1.ora

This image shows the log switch process. LGWR closes the first logfile, log1orc1.ora, when it is full and starts writing information from the redo log buffer to log2orc1.ora.
2) This image shows the log switch process. LGWR closes the first logfile, log1orc1.ora, when it is full and starts writing information from the redo log buffer to log2orc1.ora.

When log2orc1.ora fills up, another log switch occurs. LGWR closes log2orc1.ora and starts writing information from the redo log buffer to log1orc1.ora. At this point all data that was contained in log1orc1.ora is lost
3) When log2orc1.ora fills up, another log switch occurs. LGWR closes log2orc1.ora and starts writing information from the redo log buffer to log1orc1.ora. At this point all data that was contained in log1orc1.ora is lost


Backup and recovery options

With noarchivelog mode enabled you only have one option to backup and recover your database. You must do a cold backup. This means that the database is shutdown and you do an operating system backup of all the data files including the redo and control files. Your restore will be an operating system restore of these same files. You will lose any data entered into the database since this backup.
There is a very limited alternative. Let us say you have a read only database, one with limited transactions or containing many large disk drives. You can set up groups of multiplexed redo logs files, such that you never overwrite any redo log file. This could apply to maybe 1% of all the Oracle databases.
The next lesson is about media recovery with noarchivelog mode.