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

In Oracle8 you can bypass logging. You can use direct insert:

    INSERT /* append */ INTO table_name     SELECT ... or create a table as nologging:

    CREATE TABLE test_table (...) nologgin;

Remember to do a backup after large operations in these objects.

Alexandre Leite
leite_alexandre_at_hotmail.com

Mike Burden escreveu na mensagem <36F8F97E.481424C1_at_capgemini.co.uk>...
>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 Fri Mar 26 1999 - 08:12:53 CST