nologging
DESCRIPTION
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 words "sod" and "all" spring to mind as one possible answer, but that would be just a little simplistic.TRANSCRIPT
Nologging Administration Tips
Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 1
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).