cancel
Showing results for 
Search instead for 
Did you mean: 

Oracle migration

SOLVED
Go to solution
Lavoine
Occasional Visitor

Oracle migration

Hi,
We have an old (very old) Oracle database 7.3.2.2 running on an old D-380 server (HP/UX 10.20).
we plan to move to a newer architecture : L1000/HP-11i.
1) Is it possible to run Oracle 7.3.2.2 with HP 11i?
2) If this is not possible, we plan to migrate to Oracle 8.1.7 - L1000 - HP/UX 11i.
which is the best (more secure) way to go :
2.1) 2 phases jump :
first jump :
from D380/10.20/7.3.2.2
to D380/10.20/8.1.7
second jump :
from D380/10.20/8.1.7
to L1000/11i (32bits)/8.1.7
2.2) 3 phases jump :
first jump :
from D380/10.20/7.3.2.2
to D380/10.20/8.0.6
second jump :
from D380/10.20/8.0.6
to D380/10.20/8.1.7
third jump :
from D380/10.20/8.1.7
to L1000/11i(32 bits)/8.1.7
2.3 an other way to go?
3) if we plan to use an HP11i/8.1.7 with a 64bits architecture (OS + Oracle) : which is the best way to proceed?


best regards,
Frederic,
6 REPLIES
Pete Randall
Outstanding Contributor

Re: Oracle migration

Since you will have two boxes available, I'd leave your old one alone, do all the installs on the new one and then you can compare until you're happy with the results, then pull the plug on the old one.

Pete

Pete
A. Clay Stephenson
Acclaimed Contributor
Solution

Re: Oracle migration

If it were me, I would essentially do it in one step.

1) Install 64-bit (why not?) 8.1.7 on your new box. Install any 8.1.7 patches.
2) Do a full export on the old box and a full import on the new box.

I have done exactly this transition and it works flawlessly. The beauty of this method is that it is perfectly safe. Your 10.20 box reemains untouched and if for some reason this Plan A fails, you have an intact starting point for Plan B.

If it ain't broke, I can fix that.
Lavoine
Occasional Visitor

Re: Oracle migration

OK,

But this application is critical, and if we plan to move one way, we can't go back.
A lot of interfaces write and read "non duplicated informations" from this system.
And one of the constraint, is to let interface code free of modifications.
we can only modify the name of the target OracleSID. but not had one!

Are you sure that an export/import from 7.3.2.2/8.1.7 run without problems (case of stored procedure?)

Best regards,

Fred,
A. Clay Stephenson
Acclaimed Contributor

Re: Oracle migration

Of course I can't be sure that your export/import will work. Mine did, including stored procedures. Moreover, long before I did this 'for real'; the ported data was first tested very extensively. Only then was the production export/import done. I can say that the export/import from your existing version on 10.20 to 11x 8.1.7 is no more likely to fail than any of the other migration paths that you have outlined. Again, the beauty of my proposal is that it is perfectly safe because your original system remains intact. Of course, if you are one of those who believe that software testing is for wimps then go ahaed and do the production export/import and keep your fingers crossed.
If it ain't broke, I can fix that.
Lavoine
Occasional Visitor

Re: Oracle migration

Sorry, but the olddest Oracle distribution that I used was a 7.3.4. and that was during the last millenium :-).
Otherwise, I don't use to spend my time crossing my fingers, I am not a plug 'n play/ mouse player!
I used to work with 8/8i version, and I don't remember if the import/export tools are compatible between 7.3.2.2 (which is not supported by Oracle) and 8.1.7.
Volker Borowski
Honored Contributor

Re: Oracle migration

... long time ago.

As far as I remember...

1) It is not possible to upgrade anything lower than 7.3.4 to 8.0
2) It is not possible to upgrade from 7.x to 8.1.x in one step (recommendation is to go via 8.0.6)
3) To import a version 7 dump to an 8.0 database, special scripts needed to be applied on the 8.0 database (catexp7. or likewise), not sure about possibility / requirements for 8.1.x

Pitfalls: Version 7 databases used to default the charset zu US7ASCII, version 8 default to WE8DEC. In any case if you use export / import you may (afaik) not change the DB-charset. If you like to do that, you might need to convert some chars afterwards.

I would recommend the following:
- check out if the version 7 dump can somehow be imported to 8.1.7-64 bit and proceed like this (this would be best choice as someone already said), but do not change the db-charset.

If this is not possible I would go like this:
- upgrade to 7.3.4 on existing box
- install 7.3.4 on new box with UX 11.x executables
- export/import from 734/UX10.20 to 734/UX11
- upgrade new database to 8.0.6
- upgrade new database to 8.1.7
- convert to 64 bit

Hope this helps
Volker