| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Re[2]: undo tablespace
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 <ORACLE-L_at_fatcity.com>
<Mike.Hately_at_npowerno cc:
rthern.com> Subject: RE: Re[2]: undo tablespace
Sent by:
root_at_fatcity.com
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:breno_at_mercantilsoares.com.br
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 postmaster_at_npower.com (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: Mike.Hately_at_npowernorthern.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting servicesto: ListGuru_at_fatcity.com (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).
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: Charlie_Mengler_at_HomeDepot.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting servicesto: ListGuru_at_fatcity.com (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). Received on Wed Jan 29 2003 - 11:30:13 CST
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
 |
 |