Re: Why does Orcl generate REDO logs in NOARCHIVE mode?

Chakravarthy KM Nalamotu wrote in message <7d97kq$fh8_at_news.Hawaii.Edu>...
>Hello Oracle Users,
>I was wondering if someone could explain why Oracle
>writes transactions to redo logs even though
>the database is running in NOARCHIVELOG mode.
>If I am running in NOARCHIVELOG mode, doesn't it mean
>that I don't need the logs which also should include redo logs?
>What good are these logs doing to me except for wasting
>my system resources?
>There must be a good reason for this.
>Can someone explain the logic behind this architecture.
>Thanx,
> Kittu.

Separate these concepts:

-Redo log
The redo log consist of two or more log files, and contains all changes to data blocks in the buffer cache not synced with their datafiles. In case of a database crash, the redo log is used to sync the datafiles with the database state at the time of the crash. The redo log aids in recovering in case of a disk failure. When a redo log file is full, a log switch occurs, and the redo log is written to the next redo logfile. There are always two or more redo logfiles.

-Archive log
Since the redo log is circular, the redo log files are overwritten eventually. In archive log mode, a trail of redo log files is kept. An archive is created of a redo log file before the redo log overwrites it. The archive log aids in instance failures, being able to roll forward the database state from the last backup to a specific (check) point in time. Only backups (while the database is fully operational) are also possible.

In short, you need your redo logs files in all cases, because oracle needs it to guarantee database consistency. The use of archive log mode is optional. Benefits are recovering to point in time, and possibility for online backups. When you only require offline backups (shut-backup-start), and the tape from your last offline backup is good enough in case of a failure, you do not need archive log mode. Note that the archive log grows unless you do something about it, like cleaning after backup.

Hope this helps,

JM Received on Tue Mar 23 1999 - 18:45:04 CST