Migrating from Oracle 8 to Oracle 10 g R2

[labadie_1]

Hello

I have a customer who wants to migrate from Alpha Vms 7.3-2 and Oracle 8.1.7 to Itanium 8.3-1h1 and Oracle 10g R2.

I think one possibility is to migrate to 10g R2 on Alpha, then to migrate Oracle from Alpha to Itanium.

Any other possibility ?

Thanks for any hint.

[Hein van den Heuvel · Accepted solution]

Skip the middleman.
Why bother?
Export on 7.3.2, import on 10.2.
How hard could it be?

If you want a middleman, then just go client-server? Keep the client on 7.3-2 + Ora 8 but make the server available on a new Itanium running Oracle 10, with imported data.

Next, stay on 7.3-2 and upgrade the Oracle client to 10.2 if you feel like it.

Good luck!
Hein.

[Mario Dhaenens]

We did this also.

1. Install Oracle 10.2.0.4 on I64
2. Export data on 8.1.7 on Alpha.
3. Import all data on Oracle 10.2.0.4 on I64
4. Change tnsnames.ora
5. Most of the queries run better on Oracle 10g (everything is cost based optimized.)
6. But test your applications because there are many settings on Oracle

see link below:
http://download.oracle.com/docs/cd/B19306_01/server.102/b25416/ch8.htm

Are your applications running on VMS?
Then also recompile and link your applications on I64.
Java based applications don't need any changes just copy them to I64 and they will work.

Some issues:
If you are using database links between different Oracle database. Database links between Oracle 10g and Oracle 8.1.7 don't work. Make sure all your databases are on Oracle 10g.
I never got Oracle 10g correctly working on Alpha the installation procedure never finished.

[Marc Van den Broeck]

Labadie,

another issue with Oracle 10gr2 is the Daylight saving if you are using a cluster configuration. Below you find an extract from Oracle note 744135.1 on metalink:

Oracle CRS (Clusterware) processes and RAC (Real Application Cluster) instances may crash when the OpenVMS system clock is changed.
Single instance non-RAC databases are not affected.
The information held here will be particularly relevant when dealing with Daylight Saving Time (DST) changes.

Likelihood of Occurrence
Any clock changes of the type described in this document can lead to CRS and/or RAC instance problems.
While there is a small chance that a clock change may have no impact, there is a good chance that it will.

Positive/Forward clock changes of greater than 3 minutes on a single node within a RAC cluster can result in the loss of CRS processes on the given node (and hence the loss of all RAC instances on the node) and the loss of RAC instances on other RAC cluster members.
Cluster wide positive/forward clock changes of greater than 3 minutes can result in the loss of CRS processes on all RAC nodes and thus a complete loss of service.

Negative/Backward clock changes of any size on a single node can result in the loss of RAC instances on other RAC cluster members. Local instances are not impacted.
Cluster wide negative/backward clock changes of any size can result in the loss of RAC instances across the entire RAC cluster.

Rgds
Marc

[Richard W Hunt]

Another vote for the migration via export and import. We looked into this ourselves and found that the operation involves issues in version compatibility. If you've got an Alpha and an Itanium at the correct OpenVMS levels, do export/import and be done with it.

Not to mention that with the exported data, if you screw up you can start over again at the mid-point of the process.