Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Moving large amounts of data from one Oracle Server to another
lempert_at_my-deja.com a écrit :
> In article <9vaH4.143011$Hq3.3361229_at_news2.rdc1.on.home.com>,
> "Bobc" <bobchaytor_at_hotmail.com> wrote:
> > Here is the situation:
> > There is 10 gb of data on a production server (Oracle 7.3.?.?) that I
need
> > to move to a second server on a quarterly basis (Same version of
Oracle).
> > Currently this data is bundled up in a full oracle export, sent to the
> > second Unix box, an import is performed and then the quarterly
processing
> > takes place on the second box. The whole process from the start of
the
> > export to the end of the import is taking 8-10 hours!!! This is way
to
> > long. The export processing is taking place on a large parallel
siemens box
> > the import is being done on a smaller siemens machine.
> >
> > Does anyone out there have an suggestions on a different approach to
moving
> > this data to the second machine? I am open to any and all ideas. I
can
> > only assume, since I have not had a chance to look at the database
tuning
> > issues that both databases are well tuned, if you know of any tuning
issue
> > specific to import/export I would really like to hear about them.
> >
> > One requirement of any suggestion is that it can not heavily impact
> > performance on the main production server.
> >
> > If it is not to much trouble, could you email me directly.
> >
> > Thanks in advance,
> > Bob.
> >
> >
> Hi
> 1. Try the import/export in the direct=y mode, it's much faster. Yet I
> don't know if it runs also on 7.3.x
> 2. Don't mkae full exp/imp. Just leave the system alone and try to
> exp/imp only the tables from the owners U need. In the small machine,
> truncate all the tables and disable the Indexes. Import the rows of data
> and then only enable the Indexes.
> 3. On a quaterly basis, a 10 hour load is OK if it's all written in a
> script.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Depending on what you do with your second database, a solution based on a standby database could be interesting. Received on Mon Apr 10 2000 - 00:00:00 CDT