Re: Migrate databases to new servers and storage

  • From: De DBA <dedba@xxxxxxxxxx>
  • To: sbecker6925@xxxxxxxxx
  • Date: Thu, 16 Oct 2014 09:56:55 +1000

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

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


Other related posts: