Re: Using Oracle Replication To Move A New Production Database

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"