Re: Migrate databases to new servers and storage

From: De DBA <dedba_at_tpg.com.au>
Date: Thu, 16 Oct 2014 09:56:55 +1000
Message-ID: <543F09C7.2020406_at_tpg.com.au>

Maybe old-fashioned, but with databases in the terabyte range, import/export would not be my first option as it is in my experience the slowest and most cumbersome way to migrate a database.. When you create a new database and use import/export, you also need to make sure that any system/sys objects that relate to the migrated schemas will be recreated, etc.

Since the OS does not change, and assuming that you're not moving from SPARC to Intel or vice-versa, I'd go with creating a standby wherever possible and simply switch-over at the appropriate time. The old production (now standby) can be removed later at your leisure. Failover would also work, but it would mean that in case you need to revert to the old hardware, you have start over again and loose any transactions processed on the new hardware. Small databases (several GB) you may be able to restore from a fresh backup onto the new hardware within the outage window, with the same caveat as for failover of course.

The advantage of using a standby or restoring from backup is that the entire database is (re)created as it was and no extra attention needs to be paid to creating non-schema objects etc. Less opportunity for error..

I'd question these consultants' credentials. There is nothing to recover in their solution and archivelogs copied from the old database will not be able to be applied to any newly created databases. Do they understand Oracle?

Hth,
Tony

On 16/10/14 08:09, Sandra Becker wrote:
> Current Environment: Solaris 10, EE 9.2 through 11.2
> New Environment: Solaris 11, no change to the Oracle versions
> Databases range in size from 8G to 3T.
>
> Over the next 5 months we will be moving our production databases to new servers and storage. The consultants working with use (no DBAs) have proposed the following method for moving the databases:
> 1. create new databases on the new servers
> 2. create an export of the current database
> 3. import into the new database
> 4. copy archivelogs to the new server
> 5. use RMAN to recover the new database
> 6. Consultants didn't address this - what do we do with standby databases? Not every database has a standby.
>
> This is really high level, but is this the best way to migrate the databases? For the smaller databases that do not have a lot of DML or a standby, I don't see this as problematic. Am I mistaken? What have others done? Our downtime window for any one database is 4 hours.
>
> The other oracle DBA and I have considered two other possible options:
> 1. import through a dblink
> 2. create a standby on the new server and switch it to primary during the downtime window
>
> Are these really valid options for us to consider?
>
> Appreciate your suggestions and thoughts.
>
> --
> Sandy
> GHX

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

Received on Thu Oct 16 2014 - 01:56:55 CEST