Re: Moving an Instance

From: Richard Hoffbeck <rwh_at_visi.com>
Date: 1997/05/16
Message-ID: <MPG.de6bd7076d464bf98968c_at_news.visi.com>#1/1


In article <337B4245.99D_at_chevron.com>, rber_at_chevron.com says...
> Sheilah Scheurich wrote:
> > snip
 

> > I think that if you are going to do this, you would be better off
> > creating a new database with the same tablespaces, and importing in.
> > In essence this is what you are doing. Just for curiosity, what are
> > the technical reasons for doing this with links rather than with
> > export/import? While slow, it can be performed overnight or over the
> > weekend without intervention. This way you can be sure you are getting
> > all of the objects. Be sure to have the users already in place
> > otherwise the grants will fail.
> >
> > -Sheilah Scheurich
> > DBA
> > scheuric_at_sprynet.com
> > >I agree with Sheilah
>
> I've been moving several of our databases and I do the following:
> 1.export objects by user (no data)
> 2.run some sqlcode to capture roles and users and public objects
> (synonyms)
> 3. Import the objects in the new database.
> 4. after some testing in the new database I do a final data only
> export by user
> 5. Import by user
> 6. Validate connections and functionality on new database on e
> last time
> 7. Celebrate!

I need to generate several copies of my production database on a development machine once a week. To get the data onto the development machine I just copy the cold backup image. Then I run a short PL/SQL script that creates a rename script to rename all of the datafiles to their match their new locations. Then I copy the data into the new directories for the other instances, do a startup mount, run the rename script for that instance and then open the database. Using this technique I can make a copy of an instance in about 2 hours vs 16 hours for a full import to new tablespaces.

--rick Received on Fri May 16 1997 - 00:00:00 CEST

Original text of this message