RE: Cloning 21 GB Table - Review Approach please

Hi Tim, List

Another Idea suggested by some:-

create a snapshot between the source & target table of type complete and then alter the snapshot to type FAST & once the target table has exactly the same data as source table.

How would this approach (for creating the target clone via snapshot) Versus the insert /*+ append nologging parallel(x, 4) */ into <target> w.r.t. impact on production performance, time taken for completion, redo, undo generation etc?

Thanks so much for responding.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman Sent: Friday, March 11, 2005 4:28 AM
To: oracle-l_at_freelists.org
Subject: Re: Cloning 21 GB Table - Review Approach please

> Will Arhive Redo Log be generated by the INSERT /*+ APPEND */ Command
if =3D
> the Target Table has been PRE-Created with NOLOGGING?

No. Won't generate any "undo" either.

>=20
> Any possibility of giving Hint for NOLOGGING in the INSERT Command ?

Yes. /*+ APPEND NOLOGGING */

Why not use the built-in parallelism of Oracle? Unless you've left PARALLEL_MAX_SERVERS at the default of 5, you can add the PARALLEL hint to
both the INSERT and SELECT clauses. You might also want to precede with ALTER SESSION ENABLE PARALLEL DML and (of course) succeed with a COMMIT...     alter session enable parallel dml;
    insert /*+ append nologging parallel(x, 4) */ into <target> x     select /*+ full(y) parallel(y, 4) */ ... from <source> y;     commit;

No faster way to clone. Your mileage may vary, but if you have a decent sized box it shouldn't take more than 60-90 mins, tops...

--
http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l