'Nologging' is commonly misunderstood; it does not disable redo generation for all database actions, only for specific operations like creating indexes or direct loads. General DML operations still generate redo regardless of the nologging attribute. Additionally, using the hidden parameter _disable_logging can disable all redo generation but risks making the database unrecoverable.

1. Nologging Administration Tips
What does "NOLOGGING" do for me?
The words "sod" and "all" spring to mind as one possible answer, but that would be just a
little simplistic.
What I'm getting at is that people generally take it to mean that you can switch off ALL
redo generation for an entire table (or, even better, an entire tablespace), under all
circumstances. That is simply, 100%, not true.
The nologging attribute is never respected by ordinary inserts, updates and deletes.
Boring old DML will therefore always generate redo, however many times you might yell
'nologging!!!!' at it.
Only a very select class of database actions will notice the nologging attribute, and respect
it. These include:
o Create index
o Create table new_blah as select * from old_blah
o SQL Loader direct loads
o Insert /*+APPEND*/ into table select * from table (i.e., what are termed direct
load inserts)
...and one or two other obscure bits of DDL that are mostly related to working with table
partitions.
The 'create index' is about the only one that you're likely to encounter on a fairly regular
basis (along with, possibly, the Direct Load run of SQL Loader).
Given that, when the "nologging" attribute is respected by one of these commands, no redo
is generated for that particular operation, you should consider taking a fresh backup of the
tables or indexes affected by the nologging operation immediately it has finished. Without
such a backup, the segment affected is at risk of being effectively unrecoverable. Backups
are not a free exercise (they induce I/O and can swamp the redo system) ...so what you
gain on the lack of redo, you tend to lose on the backup work afterwards.
If you genuinely wish to switch off ALL redo generation for the entire database, it is
possible -but not by using "nologgiing". Instead, there is a hidden init.ora parameter,
_DISABLE_LOGGING (yes, that's an underscore at the very beginning!), which will do just that.
On your own head be it, however: use of hidden parameters is entirely unsupported by
Oracle, and this particular one will render your database totally and utterly unrecoverable
the very first time the Instance crashes (or you inadvertently issue a 'shutdown abort',
which amounts to the same thing).
Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 1