Re: Gonig from NT4 to Unix platform +Oracle 7.3.3 to 8.1.6

Michael Cooke wrote:

> My company have decided to go from our current NT 4.0 OS to Unis system at
> the same time as upgrading from Oracle 7 to 8. Has anyone out there carried
> out a similar exercise? and if so what (if any) problems can I expect to
> encounter.
> Does anyone have a project plan that they used and be willing to share with
> me?

The problem isn't in doing all of that - its just that it would probably go a whole lot smoother if you have a UNIX expert who knows how to set up the server properly. Unlike WinNT there are some things that must be done in the basic UNIX setup to make sure that Oracle will work properly. Unix system administrators, providing they read the Oracle installation guide, will know exactly what they have to do. Beyond that, however, there are a lot of decisions which must be made about how to construct the physical database and it is very different on UNIX then it is on WinNT where there are not as many options.

Once you get the physical database built, doing the logical database is a breeze. Simply do an export of the application schema with the 7.3 exp client and then import the data into the 8i database with an 8i imp client. Make sure that the schema name that you are importing into exists and that the schema owner has the correct default tablespace assigned. Don't allow imp to create indexes unless they reside in the same tablespace as the data (which is never a good idea anyhow).

Personally, I would take it one step farther and do a complete import of the schema with SHOW=Y and redirect the output to a text file. Go through that text file and turn it into a real sql script and make any changes to extent size, tablespace names, etc that you may want. Use that script to create your logical database and then use imp again to actually imput the data into the tables that you created. It is a pain to be this painstaking (I know, I know, bad pun) but you'll eventually congratulate youself for the ingenuity of doing so because it will give you an opportunity to fix things that are not the way they really should be (e.g. you can give all of your constraints meaningful names so that you don't end up with system assigned names).

I'll mention one more trick. Do everything that I just said with the exception of using imp to bring the data in. Simply leave the old database up and have it accessible to the new database via sqlnet. Then once you get everything constructed to your liking then just do INSERT INTO MYTABLE SELECT * FROM MYOLDTALE_at_MYDBLINK. Presto, all of your data comes across sqlnet. Might be a bit of a drag if you have a really large amount of data and it won't happen real fast, but in some cases you might actually like this better then using imp to bring the data in. Received on Wed Oct 04 2000 - 22:31:34 CDT