If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Migration from 8.1.7 on Sun to 9.2 on AIX

- 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 relatively small outage window, even if things were flawlessly.

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?

Oh - and the estimated I/O rates in the database during peak times is two 150MB redo logs per minute.

Have you looked at SharePlex? We did a proof of concept on our crm database (8.1.7 on HP/UX to 9.2 on Linux) a few months ago and the actual downtime was in the seconds.

After an export, it reads the redo from the source and collects dml until the target completes it's import .. then it catches up with the source by applying the cached dml .. you shutdown the source, complete the sync, then point the users to the target. Then you can back-port the dml from the target back to the source, just incase something really goes wrong. It's really cool stuff.

Upgrade to 10g (which should be available any day, right?) on your source database and use the transportable tablespace feature. The tablespaces will need to be off-line to transport and you'll need to use RMAN to convert the datafiles once they get to the target.

It's not real pretty, but it's an option we don't have in previous versions.

Originally posted by KenEwald Have you looked at SharePlex? We did a proof of concept on our crm database (8.1.7 on HP/UX to 9.2 on Linux) a few months ago and the actual downtime was in the seconds.

After an export, it reads the redo from the source and collects dml until the target completes it's import .. then it catches up with the source by applying the cached dml .. you shutdown the source, complete the sync, then point the users to the target. Then you can back-port the dml from the target back to the source, just incase something really goes wrong. It's really cool stuff.

Best of luck on your migration...

I don't think buying the costly Shareplex for one time operation (Migration) is a good idea.

Amar"There is a difference between knowing the path and walking the path."

Upgrade to 10g (which should be available any day, right?) on your source database and use the transportable tablespace feature. The tablespaces will need to be off-line to transport and you'll need to use RMAN to convert the datafiles once they get to the target.

It's not real pretty, but it's an option we don't have in previous versions.

Again, best of luck.

Current limitations for Transportable Tablespace feature:

- The source and target databases must be on the same hardware platform
- The source and target databases must have the same block size
- The source and target databases must have the same character set.
- The transportable set must be self-contained.

And moving to 10g directly without testing ?? Hmmm... that would be one risk that i won't suggest.

Amar"There is a difference between knowing the path and walking the path."

First off, that's too many variables for my taste. I would upgrade to 9i on Sun first, and then worry about swapping OS/Hardware.

If your downtime is really that minimal, I would look at multi-master replication. I would setup both boxes where users could do updates on either box. Then I would move a trial group of users to the new box to verify functionality knowing that I can switch them back to the old box should something go wrong. I would then switch everybody over to the new box and keep the updates going to the old box so I have a fall-back plan.

Afraid of 10g? Really, the idea was offered in jest. I'm with you, I wouldn't do it either.

SharePlex can be leased for a migration. It's really not a bad migration option. My opinion is that it's much better than 10g's cross platform transportable tablespaces or setting up then dissembling cross platform replication.

Just a side note.. A feature I really like about 10g is the threading of the export/import process. You can break it, re-adjust the number of workers then resume it. That's a really cool feature. And you can call export/import directly from pl/sql too.

Afraid of 10g? Really, the idea was offered in jest. I'm with you, I wouldn't do it either.

SharePlex can be leased for a migration. It's really not a bad migration option. My opinion is that it's much better than 10g's cross platform transportable tablespaces or setting up then dissembling cross platform replication.

Just a side note.. A feature I really like about 10g is the threading of the export/import process. You can break it, re-adjust the number of workers then resume it. That's a really cool feature. And you can call export/import directly from pl/sql too.

Throw me the docs of 10G, have been waiting for them for ages...

Amar"There is a difference between knowing the path and walking the path."

Thanks, everyone, for your input. I'm gathering all ideas I can. I kindof like the idea of upgrade to 9i on the Sun before moving to AIX idea. But - if things are 31 bit on the Sun side, and 64 bit on the AIX side, are there issues from that stand point?