Re: Transaction without redolog

"Stefan" <sroesch3_at_attbi.com> wrote in message news:OPwZ7.4916$Sf2.45726_at_rwcrnsc52...
> If oracle support ever detects you have set this parameter you
> lost support for the lifetime of this instance.
>

I *did* emphasise it was an unsupported option! In any case, the "lifetime of the instance" means what, exactly? Issue the shutdown and startup commands and you have a new Instance, with a new "lifetime"...

> So don't use it. Better solution is to set the table to nologging.

That's no solution at all. As I said, and as should be well known by now, the nologging keyword can be a set a thousand and one times, and yet have precisely zero effect on standard DML.

> But use it only for tables where a backup is performed afterwards.
> If the information isn't needed afterwards you may look into global
> temporary tables.
>

That's not a bad idea, so long as the poster is using 8i (no version was actually mentioned, of course!).

At the end of the day, it is impossible to offer reasonable advice until we know what this PL/SQL program is actually doing.

Regards
HJR
> Stefan
>
>
> Howard J. Rogers wrote:
>
> > Short answer: no. You're asking for the one mechanism we have to ensure
> > data security to be switched off. Oracle simply won't allow you to do
> > that.
> >
> > However. The slightly longer answer is that it depends on what your
> > PL/SQL
> > program is actually doing. Certain operations *can* have their redo
> > switched off, because there are alternative mechanisms available to
ensure
> > data security. For example, 'create index' statements can be done with
> > the 'nologging' attribute, because if anything happens to the index, it
> > can always be rebuilt, therefore it doesn't need redo to protect its
data.
> >
> > Similarly, 'create table blah as select * from blahold' can be done
> > nologging. If anything happens to BLAH, BLAHOLD is still safe and
sound,
> > and we can reconstruct BLAH from it, without recourse to redo.
> >
> > So there are some special DDL and even more special DML statements that
> > can be done 'nologging', but good old inserts, updates and deletes can
> > *never* be done nologging.
> >
> > Unless.... unless.... you want to take your life in your hands, and risk
> > your entire database becoming utterly unrecoverable (and do something
> > which is totally unsupported by Oracle to boot).... there is a hidden
> > parameter
> > which can be set in the init.ora called "_disable_logging". Set that to
> > TRUE, and absolutely nothing will be logged. Ever. But you'd better
pray
> > you've got bloody good backups before using it, and whilst you're at it,
> > pray that you never have an Instance crash -because you won't be able to
> > recover from it.
> >
> > One site I worked with had a big batch update performed once a month,
with
> > cold backups taken immediately before and after. For them,
> > _disable_logging was a perfectly viable option, and it made the update
> > take place at
> > something like three times the speed than before. If anything awful
> > happened, they happily signed up to the loss of the update, and reverted
> > to
> > their previous cold backup. So there is a use for it, but you really
need
> > to know what you are doing, and the potential costs involved.
> >
> > All of which basically amounts to: stick with the short answer. There's
> > nothing you can do about it safely if its ordinary DML you're
performing.
> >
> > Regards
> > HJR
> >
> >
> > "Elías Alpuente" <ealpuente_at_isoco.com> wrote in message
> > news:a14gn0$nb7$1_at_talia.mad.ttd.net...
> >> We have a PL/SQL program that generate a lot of redo log data. Each
time
> > the
> >> archiver
> >> make its job we have 3 Gb in the arc directory.
> >>
> >> Is posible make a transaction without generate redolog data with
> > ARCHIVELOG
> >> mode?
> >>
> >> Thanks.
> >>
> >>
>
Received on Sun Jan 06 2002 - 00:55:10 CST