Bypass Rollback Segment

[engiri]

Hi

I am going to update a large table contains 5 million + records.

With normal mechanism of Rollback segment usage it is
a time consuming job.
The above can be accomplished by a create table command.But we dont want to create so.

I am running the database in RESTRIct mode
during this update command.


Is there any way to bypass the Rollback segment Mechanism So that we could make this updation process
runs faster.

Thanks
Giri

[abhaysk]

Can't

[SANJAY_G]

I don't think you can bypass UNDO generation. Create a BIG rollback segment and set your transaction to use that segment.
HTH

[rotem_fo]

you can write a PL/SQL loop caluse and commit every n records.

[abhaysk]

His concern is to speed up process and not Rollback Space ( as per his post ).

So, PL/SQL code will not be of much help.

[engiri]

Yes Mr.abhaysk
is correct

[abhaysk]

Originally posted by engiri
Yes Mr.abhaysk
is correct

U cant bypass ROLLBACK, to spead up process.

Ofccource you cud aviod LOGS..if table created in NOLOGGING or u cud Alter it to NOLOGGING.

[SANJAY_G]

Originally posted by abhaysk
U cant bypass ROLLBACK, to spead up process.

Ofccource you cud aviod LOGS..if table created in NOLOGGING or u cud Alter it to NOLOGGING.

UPDATE is not eligible for NOLOGGING only certain operations like CREATE INDEX, REBUILD INDEX, CTAS, DIRECT_INSERT can take advantage of nogging. UPDATEs and DELETEs will always be logged to redo.

[SANJAY_G]

As of Version 8i following operations can make use of no-logging mode:

direct load (SQL*Loader)
direct-load INSERT
CREATE TABLE ... AS SELECT
CREATE INDEX
ALTER TABLE ... MOVE PARTITION
ALTER TABLE ... SPLIT PARTITION
ALTER INDEX ... SPLIT PARTITION
ALTER INDEX ... REBUILD
ALTER INDEX ... REBUILD PARTITION
INSERT, UPDATE, and DELETE on LOBs in NOCACHE NOLOGGING mode stored out of line

[abhaysk]

Originally posted by SANJAY_G
UPDATE is not eligible for NOLOGGING only certain operations like CREATE INDEX, REBUILD INDEX, CTAS, DIRECT_INSERT can take advantage of nogging. UPDATEs and DELETEs will always be logged to redo.

Sanjay :

Thas correct.

I was refering to Engiri's "Create Select" Part ( which he didnt want to use ).