-
Migration from 8.1.7 on Sun to 9.2 on AIX
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 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.
Thanks!
-
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...
-
Here's another idea...
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.
-
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."
-
Originally posted by KenEwald
Here's another idea...
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.
Jeff Hunter
-
adewri,
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.
-
Originally posted by KenEwald
adewri,
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?
-
Yep - you cant run 9i on a 32-bit O/S - must be 64bit!
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|