Message-ID: <a779b53e8230a1c7c1a1a91caf22c5d0.squirrel@webmail.mufalani.com.br>
In-Reply-To: 
 <CAJzM94AiRffKoTkkt=n+gYKsJDMZy4S+wbANhkkbdpY4ZkYmhA@mail.gmail.com>
References:
    <CAJzM94AiRffKoTkkt=n+gYKsJDMZy4S+wbANhkkbdpY4ZkYmhA@mail.gmail.com>
Date: Wed, 6 Jun 2012 11:47:51 -0300
Subject: Re: Moving then migrating database
From: "Rodrigo Mufalani" <rodrigo@mufalani.com.br>
To: sbecker6925@gmail.com
Cc: "oracle-l" <oracle-l@freelists.org>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-type: text/plain
Content-Transfer-Encoding: 8bit
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: rodrigo@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