Re: Migrate databases to new servers and storage
- From: Mark Burgess <mark@xxxxxxxxxxxxxxxxxxxxxxxxx>
- To: sbecker6925@xxxxxxxxx
- Date: Thu, 16 Oct 2014 09:44:39 +1100
Sandra,
im not sure how the proposed method would work as the new database created
would have a different DBID and unable to be recovered using archivelogs from
the source database.
You might find that you need to use different methods depending on the version
of the database and the size of the database to be able to migrate within the
required window.
We recently migrated Sol 10 to Sol 11 and new storage on 11gR2 using RMAN
recover copy to the new storage. The actual outage was simply a case of
shutdown the source db - start it up mount, run the final recover copy command,
shutdown the source, copy the control file, redo logs over to the new host,
startup mount, rename datafiles and open the database. All up the process was
around 4hrs on a 6T database will approx 7k datafiles. It worked well with the
additional benefit of having a very low risk backout option of just restarting
the source database again. Using storage snapshots we were able to test this
migration process thoroughly without impacting the source prod database or
impacting the image copy on the target storage.
If you have standby databases to consider, preserving the controlfile from your
source will simplify the migration as well - you will not need to rebuild the
standby if you maintain the same physical copy of the database.
I hope this helps - quite possibly raises more questions than answers but feel
free to drop me a line if you want more details on our approach above.
Regards,
Mark
On 16 Oct 2014, at 9:09 am, Sandra Becker <sbecker6925@xxxxxxxxx> 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:
