Re: Data Migration options - oracle to oracle

Many Thanks to everyone for enormous ideas with valuable time.

Will be presenting to management folks with all your valuable points, because no one understand big picture.

Need to get everyone to agreeable solution soon at my place.

Sure I will update everyone once we have that solution.

Thanks and this group is great.

Karth

On Sep 6, 2013, at 11:58 AM, Gleb Otochkin <gleb.otochkin_at_gmail.com> wrote:

> Hi Karth,
> I think a replication solution like streams can help with migration and
> minimize downtime for clients.
> I would split it to two task:
> 1. Migration the data from source to destination with transformation for
> a predefined scn.
> Depending from data and transformation can be done using
> select/insert over db link with "as of scn" clause or
> using datapump export with flashback scn . The data can me
> transformed after import/export.
> All the triggers/constrains can be disabled during import and
> enabled as soon as transformation completed.
> 2. As soon as data ready you can set up replication with data
> transformation on the fly using dml handlers for apply.
> Streams apply will not fire any triggers unless you want it to do
> it. Only users transactions will lead to triggers firing.
> As result you should have sync environment and can migrate your
> user almost with zero downtime.
>
> The problem is that way requires significant effort and doesn't support
> all datatypes. But it is doable and as soon as you've done it for one
> schema it is much easier to repeat for others.
>
> Cheers,
> Gleb
>
> On 06/09/2013 12:13 AM, Karth Panchan wrote:

>> Norm/Raj
>> Thanks very much for response and details.
>> 
>> Here is little more background information.
>> 
>> Old application data reside in around 600 tables on each schema for our
>> 
>> 
>> Karth

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