AFAIK, in 8i+ tablespaces can be created with the"NOLOGGING" clause
LOGGING | NOLOGGING
Specify the default logging attributes of all tables, indexes, and
partitions within the tablespace. LOGGING is the default.
The tablespace-level logging attribute can be overridden by logging
specifications at the table, index, and partition levels.
Only the following operations support the NOLOGGING mode:
DML: direct-load INSERT (serial or parallel), Direct Loader
(SQL*Loader)
DDL: CREATE TABLE ... AS SELECT, CREATE INDEX, ALTER INDEX ...
REBUILD, ALTER INDEX ... REBUILD PARTITION, ALTER INDEX ... SPLIT
PARTITION, ALTER TABLE ... SPLIT PARTITION, and ALTER TABLE ... MOVE
PARTITION
In NOLOGGING mode, data is modified with minimal logging (to mark new
extents INVALID and to record dictionary changes). When applied during
media recovery, the extent invalidation records mark a range of blocks as
logically corrupt, because the redo data is not logged. Therefore, if you
cannot afford to lose the object, you should take a backup after the
NOLOGGING operation.
"Hately, Mike
(NESL-IT)" To: Multiple recipients of
list ORACLE-L <[EMAIL PROTECTED]>
<Mike.Hately@npowerno cc:
rthern.com> Subject: RE: Re[2]: undo
tablespace
Sent by:
[EMAIL PROTECTED]
01/29/2003 08:04 AM
Please respond to
ORACLE-L
You're correct in saying that your undo blocks are protected by your redo
files.
What type of operation are you performing on your table? I ask because only
a small subset of commands support the NOLOGGING feature; the remainder
will
generate redo as usual.
If you're not using a syntax that supports NOLOGGING maybe you could adapt
your job to adopt one.
Alternatively you may find that you just need to optimise your redo log
placement in order to handle the load.
Regards,
Mike Hately
-----Original Message-----
Sent: 29 January 2003 14:10
To: Multiple recipients of list ORACLE-L
Mike,
I asked it because I have a problem.
Any insert data in UNDO tablespace generate insert in REDO Files. Is
is correct ?
When I execute a high procedure, many inserts in UNDO tablespace
ocurres, so many inserts in REDO´s are genereate.
I want to avoid this REDO´s generation.
My tables and indexes are in NOLOGGING, but I high value of
REDO are generate (100 MB each 20 minutes). It is desnecessary.
Oracle 9i / NT
--
Breno A. K. Magnago
mailto:[EMAIL PROTECTED]
Mercantil de Alimentos Soares
Wednesday, January 29, 2003, 10:29:15 AM, you wrote:
HMNI> Breno,
HMNI> There's no way to do this because it's the central pillar of Oracle's
read
HMNI> consistency mechanism.
HMNI> It's possible to minimise or suppress redo but undo is out of your
control.
HMNI> regards,
HMNI> Mike Hately
HMNI> -----Original Message-----
HMNI> Sent: 29 January 2003 11:39
HMNI> To: Multiple recipients of list ORACLE-L
HMNI> I have a high procedure (many INSERT's and UPDATE´s).
HMNI> This procedure generate insert's in UNDO TableSpace for rollback.
HMNI> I want to know if exists any way for don´t generate insert´s in UNDO
HMNI> Tablespace.
HMNI> Oracle 9i / NT
HMNI> Thanks.
**********************************************************************
The information contained in this e-mail is confidential and
intended only for the use of the addressee. If the reader of
this message is not the addressee, you are hereby notified
that you have received this e-mail in error and you must not
copy, disseminate, distribute, use or take any action as a
result of the information contained in it.
If you have received this e-mail in error, please notify
[EMAIL PROTECTED] (UK 01384 275454) and delete it
immediately from your system.
Neither Npower nor any of the other companies in the
Innogy group from whom this e-mail originates accept any
responsibility for losses or damage as a result of any viruses
and it is your responsibility to check attachments (if any) for
viruses.
Npower Limited
Registered office: Windmill Hill Business Park, Whitehill
Way, Swindon SN5 6PB. Registered in England and Wales:
number 3653277
This e-mail may be sent on behalf of a member of the Innogy
group of companies.
**********************************************************************
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Hately, Mike (NESL-IT)
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
