Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Porting a VLDB to a different platform (quickly)?

Re: Porting a VLDB to a different platform (quickly)?

From: MotoX <rat_at_tat.a-tat.com>
Date: Tue, 20 Oct 1998 08:20:57 +0100
Message-ID: <908867999.21250.0.nnrp-02.c2de712e@news.demon.co.uk>


Are you sure that would work (even for exactly the same Oracle release) between two *different platforms*? I have my doubts. I wouldn't have thought a copy of Oracle datafiles from, say, a UNIX server to an NT server would work, would it? Anyone tried this?

I've moved db's of around 50G, and that's taken a day or so, using fairly fast UNIX servers and full imports, so I'm not quite so sure where you get 'at least 5 months' from?... I usually build an 'empty' db first, so you can get the system, temp, rollback and redo stuff built on the new box without messing with the old stuff.

For export, look at 'direct' mode, and look at running multiple sessions to separate disks in parallel.

For import, most of the time seems to be building the indexes, so you might want to stick them on after loading all the data, and look at building them in parallel. Again, look at running as much as possible of the import in parallel.

You might also want to look at extracting some of you db as flat files an loading with SQL Loader in direct mode (and running parallel sessions).

If you find a lot of your data is summary data, then just rebuild it (in parallel) on the new box, don't bother pulling it across.

If you still find (after all the above) it's going to take 5 months+, then buy a new server, as the one you got isn't up to the job! :-)

NB. For all the 'parallel' stuff above I take it you have an SMP box with fast, striped disk drives and multiple adapters. For a db of that size, you should.

MotoX.

raman batra wrote in message <362BFCD6.4424_at_feist.com>...
>A few ways you can minimize this. If the version of Oracle you are
>running is exactly the same, then you can "clone" your database using
>the principles of backup and recovery.
>
>Basically, copy all datafiles and log files from a full-offline backup,
>preferably with SHUTDOWN IMMEDIATE. You will then simulate the loss of
>a control file and recover the database and rename it.
>
>All the time it takes is the time to copy the data files. Once that is
>done, takes very little time to "clone". I do it all the time and works
>just fine.
>
>Have fun,
>
>
>doid_at_usa.net wrote:
>>
>> Fellow users,
>>
>> I'm looking into moving a ~200Gb Oracle instance onto a hot new platform.
The
>> new machine comes from a different manufacturer than the old one, and
uses a
>> much different architecture.
>>
>> Exports run very slowly on the old server. Based on tests that I've
done, I
>> expect that the Export/Import route would take at least 5 months.
>>
>> My manager doesn't seem willing to accept that kind of timeframe:(
>>
>> Can somebody here draw upon his/her experience and suggest an alternative
>> strategy? I hope to shorten the timeline significantly, if possible.
>>
>> For example, I'm beginning to consider 3rd-party backup/recovery tools.
Does
>> anyone here have experience using such products to move from one platform
to
>> another?
>>
>> I look forward to seeing any suggestions you may have.
>>
>> doid
>>
>> -----------== Posted via Deja News, The Discussion Network ==----------
>> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Received on Tue Oct 20 1998 - 02:20:57 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US