DBAsupport.com Forums - Powered by vBulletin
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Migration from 8.1.7 on Sun to 9.2 on AIX

  1. #1
    Join Date
    Nov 2003
    Posts
    2

    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!

  2. #2
    Join Date
    Mar 2002
    Location
    Mesa, Arizona
    Posts
    1,204
    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 do not fear computers. I fear the lack of them." Isaac Asimov
    Oracle Scirpts DBA's need

  3. #3
    Join Date
    Mar 2002
    Location
    Mesa, Arizona
    Posts
    1,204
    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.
    "I do not fear computers. I fear the lack of them." Isaac Asimov
    Oracle Scirpts DBA's need

  4. #4
    Join Date
    Nov 2002
    Location
    New Delhi, INDIA
    Posts
    1,796
    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."

    Amar's Blog  Get Firefox!

  5. #5
    Join Date
    Nov 2002
    Location
    New Delhi, INDIA
    Posts
    1,796
    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."

    Amar's Blog  Get Firefox!

  6. #6
    Join Date
    Nov 2000
    Location
    greenwich.ct.us
    Posts
    9,092
    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

  7. #7
    Join Date
    Mar 2002
    Location
    Mesa, Arizona
    Posts
    1,204
    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.
    "I do not fear computers. I fear the lack of them." Isaac Asimov
    Oracle Scirpts DBA's need

  8. #8
    Join Date
    Nov 2002
    Location
    New Delhi, INDIA
    Posts
    1,796
    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."

    Amar's Blog  Get Firefox!

  9. #9
    Join Date
    Nov 2003
    Posts
    2
    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?

  10. #10
    Join Date
    Nov 2000
    Location
    Birmingham, UK
    Posts
    360
    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
  •  


Click Here to Expand Forum to Full Width