Re: Using Oracle Replication To Move A New Production Database

Thanks for your response. Brian has really peaked my interest with Transportable Tablespaces. Since we have never been able to duplicate the problem, it would not be a total loss if the problem manifested itself in the new database during the test phase. The tables we are having the problem with are some of the most frequently used so I have not been able to test some ideas I have been kicking around.

If using transportable tablespace works......GREAT!. If the problem rears it's head, I would welcome the opportunity to resolve it in a non production environment. Worse case, we would either use replication or log miner to move the data.

BTW....does the location of the datafiles on the target database have to mirror the location of production when you use transportable tablespace. If not, I can move the problem tablespaces to a test database located on our production server. This database was created to help troubleshoot our problem.

Once again...thanks for the response.

"Anurag Varma" <avdbi_at_hotmail.com> wrote in message news:<OK%pb.16378$2M1.14555_at_news01.roc.ny>...
> Transportable tablespaces will be a standby like solution. However, definitely
> worth a try to see if it fixes your problem.
>
> Considering that you don't plan on using replication your solution can have its share
> of complications if things go wrong.
> Not that it won't work. Theoretically it should work.
>
> Brian's suggestion of exp/imp with LogMiner might be worth a shot. However, making
> LogMiner work with the exp/imp might not be as easy as it sounds. You would
> first need (afaik) to turn supplemental logging on. After that sure .. this seems like
> a solution worth trying.
> In essence its a solution similar to your replication + offline instantiation suggestion ..
> however, exp/imp + Logminer might be less complicated.
>
>
> YMMV
>
> Anurag
>
>
> "Robert D. Perry" <rdperry_at_gowebway.com> wrote in message news:e4fbf364.0311042030.2e8ed10a_at_posting.google.com...
> > 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 Wed Nov 05 2003 - 10:21:33 CST