Question on upgrade plan from 8.1.7 to 9i

[batavus]

Here's the need:

- Upgrade a large (near 1TB) database from 8.1.7 to 9i
- Move from 32 bit oracle, to 64 bit oracle
- Move from Solaris to AIX
- Move from Sun to RS6000
- Do it in a small outage window

So, here is my idea:

I would like to minimize the down time when switching production from Sun to RS6000. So my approach is to see if I can run the 8.1.7 production, and use some method to keep a 9i database on the AIX boxes in sync with the data changes occuring on the sun 8.1.7 boxes. This way each will be running in parallel until the time comes to switch the application servers to point to the new AIX boxes. I'm trying to avoid having to, the night of the switch over, perform and ENTIRE extract from 8.1.7 and a full import into 9i. There is just too much data to do this in a small outage window.

So - what options do I have to take daily (or smaller time span) data changes from an 8.1.7 32 bit database on Sun, and push those changes into a 9i 64 bit database running on AIX? Can redo logs from 8.1.7 32 bit be applied directly into a 9i 64 bit database?

Thanks!

---
Batavus

 

[SantaMufasa]

Batavus,

First, I believe your idea of applying the redo logs from 32-bit 8.1.7 Solaris against a 64-bit 9i Aix is probably doomed (unless you check with Oracle Tech Support/Metalink and they give you their blessing, which I'd bet half my paycheck that they won't).

Before I propose my suggestion, please advise how many tables we are talking about migrating and the average number of INSERTs, UPDATEs, DELETEs per table you anticipate during the time from export from Solaris to cut-over to Aix.

Dave
Sandy, Utah, USA @ 17:23 (18Nov03) GMT, 10:23 (18Nov03) Mountain Time

 

[batavus]

Yeah - I figured redo logs wouldn't work from one version to the next. Just threw that out there as a tickler. I'm looking into replication, but not sure that is the best method (or even workable) at the moment either.

The number of inserts, updates, deletes... to be honest, that is unknown at the moment. I can say that it is a multi role database - as in it is used for both OLTP and batch. I wouldn't say it's throwing multiple 100MB archive logs a minute, but I could fathom that the number of rows modified by inserts/updates/deletes is below the 1 million per day measure.

Thanks.

---
Batavus

 

[SantaMufasa]

Batavus,

Given:

* You have a limited time window for this migration
* You cannot do a standard export/import/test/cutover in the time allowed
* You anticipate ~1 million rows/day changing in your application tables during the migration window.

I have thought about your need for several hours today. Your migration represents a business-critical, high-risk proposition, given your time-window limitations. Although I created a migration scenario for you, I evaluated the table-interdependency issues and decided to suggest the following:

Contact the "Pros from Dover" (Oracle Consulting). Speak with a practice manager that has successfully done MANY major migrations like yours. Have them share references of their success stories...Have them discuss the methodology that they recommend, and get a bid from them for coming in and managing this migration for you.

This way you mitigate your (significant) risks with proven, successful experience, plus Oracle Consulting has access to proprietary tools (not available to the general public) to logically replicate the contents of redo log files and apply them against an imported database on machine with dissimilar O/S and architecture from the exporting database.

Help from Oracle Consulting will cost some dollars, but when compared against the possible costs of mis-fires, migration screw-ups and potential lost revenue due to production down time, their price will be small.

Thoughts from other Tek-Tips gurus?

Dave
Sandy, Utah, USA @ 08:09 (19Nov03) GMT, 01:09 (19Nov03) Mountain Time

 

[bookouri]

I recently had to deal with something similar, although on a smaller scale moving from Win2K to Solaris, and there turned out to be pretty much no option but export/import due to the lack of compatibility of the physical files. The only real option seemed to boil down to some kind of incremental export/import, but in the end it was just too much "risk/effort" and I elected to take the several hours of down time and be done with it. But, you probably dont have that option.