Re: Moving then migrating database

From: Rodrigo Mufalani <rodrigo_at_mufalani.com.br>
Date: Wed, 6 Jun 2012 11:47:51 -0300
Message-ID: <a779b53e8230a1c7c1a1a91caf22c5d0.squirrel_at_webmail.mufalani.com.br>


Hi Sanrdra,

  When I read your message I though in Dataguard to replicate, sync, then in proper window activate the secundary (standby), then upgrade to 11g. I don't tested yet, but you can open a TAR with MOS to check this info that on 10g supports a kind of different OS's as seems that you will do in this migration.

 
This is a very good blog post http://emrebaransel.blogspot.com.br/2010/12/dataguard-on-different-operating.html

  I hope this link can helps you.

  If it works in your sandbox, will reduce drastically your downtime to several hours to minutes.

Best Regards,

Rodrigo Mufalani
Oracle Ace
Member
Tel.: +55 21 88994817
http://www.mufalani.com.br

Currently:     

OS: SLES10
     Oracle: 10.2.0.5
Moving to:

    OS: SLES11
     Oracle: 11.2.0.2 (the latest
version for zLinux when we began
migrating)

We purchased a new IBM mainframe and faster storage. I now have to move
all my databases to the new VMs and storage and upgrade them to 11gR2. I have already
moved a small production database (50G) without any problems.  I now have to move the next one which is 850G. The problem is copying the
datafiles to the new storage before the upgrade--taking too much time. I then
need to move the next one that is 1.5T. Again, just copying the datafiles will require more downtime than my current window. My SAs have
not come up with any method for moving the files faster. I know there are tools out there, but we don't seem to have any. I see my options as telling my boss I need a bigger window or come up with a better method to
move the database before I begin the upgrade.

Question: Will the
following work?

  1. Using last level 0 backup of the database, restore it to the new VM/storage a few days before the actual migration date.
  2. Using the incremental backups taken daily, run the restores on the new VM/storage.
  3. On the migration date:
    • shutdown the database
    • run a final incremental backup
    • restore the final incremental to the new VM/storage
    • upgrade the database to 11g

I do have a sandbox database I can practice with to get timings, script everything,
document to the nth degree, etc. I just don't want to go down a rat hole if this isn't at all feasible.

Thank you for your input.

--
Sandy
Transzap, Inc.


--
http://www.freelists.org/webpage/oracle-l








--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jun 06 2012 - 09:47:51 CDT

Original text of this message