Re: Using Oracle Replication To Move A New Production Database

Thanks for the suggestions Brian. We did not consider Standby because it requires making a cold copy of our current database. Management does not want to take a chance of the problem following us.

I'll explore transportable tablespaces & LogMiner further.

If we use replication, will we be able to gracefully turn off replication?

Thanks

Brian Peasland <dba_at_remove_spam.peasland.com> wrote in message news:<3FA83208.7E27F309_at_remove_spam.peasland.com>...
> If you will be on the same platform, then you have lots of options for a
> 6 hour downtime window.
>
> - You could use Transportable Tablespace to move stuff pretty quickly.
> This may/may not fit into your window depending on how long it takes you
> to move the datafiles (network speed and all of that).
> - You could move the data over (export/import) and then use LogMiner to
> get the changes and create a script which will apply those changes to
> the destination database.
> - You could implement Standby and have your old production database
> propagate changes to the new database. At some point, perform a graceful
> switchover.
>
> HTH,
> Brian
>
> "Robert D. Perry" wrote:
> >
> > We have been working Oracle Support to resolve an database problem
> > that causes our application to present the "Do You Want To Save"
> > message after an update 3 or more times to the end user before you can
> > navigate to the next record or another screen. Oracle has been
> > assisting us with this problem since June and resolution has not been
> > found. This problem began after we experience a major crash in May
> > that resulted in our production database being rebuilt by the DBA's at
> > our hosting facility.
> >
> > A decision has been made by management to move the production data to
> > a new database before year end. Since we are a credit card processing
> > company, the database is available 24 by 7. We have created test
> > database on the production server and moved the data over via
> > export/import to see if we could duplicate the problem. The problem
> > did not manifest itself.
> >
> > At this point, management would like to find the fastest way to
> > rebuild 100GB database. It is important that we keep downtime less
> > than 6 hours. Based on the research I have done so far, replication
> > may be our best option. A new database can be created and offline
> > instatiantions can be made of all the schema's required for the
> > application. It is not our intention to replicate all of our tables,
> > just the dynamic ones. Once the new database has completed the
> > instantiation and synced with production, we can begin testing the new
> > database. After testing successfully completes, we can schedule a
> > cutover date.
> >
> > From what I have read, the table names created in the new production
> > database will be the same as the current database(no MV$<table_name>).
> >
> > Once the we have successfully tested the new database, what will need
> > to do to turn off replication? We do not plan to use replication with
> > the new database instance. Standby database will be set up to satisfy
> > our disaster recovery needs. Since the data is only going ONE WAY, is
> > it safe to assume that there will not be any conflicts?
> >
> > Are there any gotcha's that we should be aware of? If there is a
> > better approach to this issue, please let me know.
>
> --
> ===================================================================
>
> Brian Peasland
> dba_at_remove_spam.peasland.com
>
> Remove the "remove_spam." from the email address to email me.
>
>
> "I can give it to you cheap, quick, and good. Now pick two out of
> the three"
Received on Tue Nov 04 2003 - 22:30:37 CST