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

In a development environment the redo logs should not be slowing things down. Typically, a development environment is not as transaction intensive as a production one (there are exceptions of course). I would like to see a way to mark a table as not recoverable or not logged. There are tables that we have that hold temporary information and if the instance went down the information is not used.

I think it is a design choice and I cannot think of another commercial RDBMS that allows you to basically make the database unrecoverable. Can you imagine competitor X advertising that company Y 's database is unrecoverable. Also they would have to make some major architecture changes and that also probably drives it.
Jim

Mike Burden wrote in message <36F8CD86.648A1AFE_at_capgemini.co.uk>...
>Agreed that redo logs aid recovery, but surely they are not essential. If
you
>accept that in the event of a failure, you will restore to a cold backup,
why do
>you need the redo logs. If you don't back them up and you loose everything
you
>can still go back to a cold back even without the redo logs. I have thought
>about putting redo and rollback segments into a RAM disk to prevent the
disk IO
>in certain situations (e.g. Development environment). I've already tried it
with
>Rollbacks in RAM which seem to work OK. If it all goes nasty you just
restore
>and re-run. No roll forward necessary.
>
>It would be nice if you could turn either or both off and save on the
overhead.
>Hence three modes. This would be particularly useful for large overnight
batch
>jobs where you do a cold backup at the end anyway. Because the job works
99.999%
>of the time you wish to take advantage of the fact by switching off redo
and
>rollback and save on loads of IO.
>
>Just my thoughts. Anyone else care to comment. Are these features available
in
>any other DBMS?
>
>I still think Oracle writes twice as much data to the redo logs than it
needs to
>because rollback info gets logged too. But that's another story.
>
>
>Jan-Marten Spit wrote:
>
>> 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 Wed Mar 24 1999 - 07:25:23 CST