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

As far as performance is concerned I was thinking about large inserts which need to be done via a program. Inserting 100MB of data to the datafiles means 100MB being written to the rollback and 200MB being written to the redo log. In development on a single disk this must slow things down a bit. Especially if the 100MB to the data files is almost sequential. I agree that there are many other cases when the overhead is minimal.

I was thinking that if the facility existed it would be an advanced option. i.e. You use it if you know what you are doing (and perhaps a bit mad) like many other options. I have no doubts that using logs in no archive log mode is defiantly the best default choice, but like most developers we like to have the choice:-) Don't worry, it's not on my top 100 list.

As for the advertising, well if they said that, it would be the users choice. It would not be Oracles fault.

I'm surprised it would be a major architectural change. I thought you could just miss out the writes to redo and rollback. The rest, i.e., checking, must already by present. So in short it would be:

if flag_set
  write redo
end

I am being slightly flippant with the above code. I'm sure any change to Oracle database is a significant change. I know there is a lot more to it.

Thanks for the reply.

Jim Kennedy wrote:

> 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 - 08:41:03 CST