Re: Best migration way

On May 4, 9:09 am, "fitzjarr..._at_cox.net" <fitzjarr..._at_cox.net> wrote:
> On May 4, 7:43 am, "mtn_bik..._at_msn.com" <mtn_bik..._at_msn.com> wrote:
>
> > Hi guys!!
>
> > We plan to upgrade the old 8.1.7 in a old server, to 10g in a great
> > new server. We upgrade the OS too from Windows 2000 Server to Windows
> > Server 2003 x64.
> > In practice or with your experience, what is the best way to upgrade
> > to my new server?
>
> > We want to make sure that we don't get old stuff from the 8,1,7
> > server.
>
> > Thanks to share your opinion with me.
>
> Answered in another thread two years ago. Read either one of these:
>
> http://www.oracle.com/pls/db102/to_pdf?pathname=server.102%2Fb14238.p...http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14238.pdf
>
> David Fitzjarrell

With a new server usually comes new disk. I am a big fan of installing the new version and building a database with a layout designed for the new disk farm and then pre-creating my owning users with privileges and pre-allocating the tables using a distribution designed for the new platform. We exp/imp the table data, run scripts to create the indexes, add the constraints, and add the triggers. A few simple queries can verify that all objects were brought.

An import of an export made using full=y rows=n can be used to bring public synonyms and any missed objects.

Generate fresh statistics and you now have a freshly laid down system for how you want to manage your database going forward.

When you create a fresh database it gives you a chance to switch tablespaces from dictionary management to LMT, to choose to use ASSM or stick with manual segment space management, to redistribute objects that need to be in their own tablespace or just moved away from other large objects. It allows resizing tablespace so that your tablespaces will take about the same amount of time to backup and recover.

HTH -- Mark D Powell -- Received on Fri May 04 2007 - 10:18:18 CDT