Re: Migrate databases to new servers and storage
Date: Thu, 16 Oct 2014 09:46:31 -0600
Message-ID: <CAJzM94CmDZNtQj2xd7aT6K35MJYjNK68GttgfwXnaiawJ_farg_at_mail.gmail.com>
Thanks everyone for your input. Had a brief discussion this morning with the DBA team. My manager and his manager have told me that I am driving this project and it is up to me to decide how we will proceed. We will be using the "create a standby on the new hardware" option for most of the databases. We have a couple that we can simply take a full backup, shutdown, restore on the new hardware. The usual "it depends" scenarios. Unfortunately, we will not be able to upgrade the 9i and 10g databases since the applications they support are not certified for higher versions.
Great discussion and much appreciated. Thanks again.
Sandy
On Thu, Oct 16, 2014 at 9:45 AM, Sandra Becker <sbecker6925_at_gmail.com> wrote:
>
> Forwarded conversation
> Subject: Migrate databases to new servers and storage
> ------------------------
>
> From: *Sandra Becker* <sbecker6925_at_gmail.com>
> Date: Wed, Oct 15, 2014 at 4:09 PM
> To: oracle-l <oracle-l_at_freelists.org>
>
>
> 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
>
> ----------
> From: *Mark Burgess* <mark_at_burgess-consulting.com.au>
> Date: Wed, Oct 15, 2014 at 4:44 PM
> To: sbecker6925_at_gmail.com
> Cc: Oracle List List <oracle-l_at_freelists.org>
>
>
> 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
>
> ----------
> From: *De DBA* <dedba_at_tpg.com.au>
> Date: Wed, Oct 15, 2014 at 5:56 PM
> To: sbecker6925_at_gmail.com
> Cc: oracle-l <oracle-l_at_freelists.org>
>
>
> 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
>
> ----------
> From: *Uzzell, Stephan* <SUzzell_at_micros.com>
> Date: Wed, Oct 15, 2014 at 6:08 PM
> To: "sbecker6925_at_gmail.com" <sbecker6925_at_gmail.com>, oracle-l <
> oracle-l_at_freelists.org>
> Cc: "Uzzell, Stephan" <SUzzell_at_micros.com>
>
>
> Include me in the group that doesn't understand what the consultants are
> proposing... You cannot recover a new database with archivelogs from the old
> database, nor can you apply archivelogs to a export.
>
>
>
> I hate to say "it depends" but it depends. Your best method is going to
> depend on your technology stack. Are these all on SAN storage? On ASM?
> We've been using a technique of shutting down on the old hosts, swinging
> the LUNs to the new servers, starting them up over there (of course, we've
> been adding Oracle upgrades to the process, but...). If these are SAN/ASM,
> that may be an easy approach.
>
>
>
> If not on SAN/ASM, I'd say the standby approach sounds like your best
> option.
>
>
>
> [image: Oracle | Micros] <http://www.oracle.com/>
>
> *Stephan Uzzell* | Database Administrator | HGBU Cloud Operations
>
> Mobile: +1 443.864.1725
>
> Oracle Hospitality
>
> Swarthmore, PA | US
>
> [image: cid:image002.gif_at_01CFDD84.DCD06460]
> <http://www.oracle.com/commitment>
>
> Oracle is committed to developing practices and products that help protect
> the environment
>
>
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Sandra Becker
> *Sent:* Wednesday, 15 October, 2014 18:09
> *To:* oracle-l
> *Subject:* Migrate databases to new servers and storage
>
> ----------
> From: *Seth Miller* <sethmiller.sm_at_gmail.com>
> Date: Wed, Oct 15, 2014 at 8:50 PM
> To: SUzzell_at_micros.com
> Cc: "sbecker6925_at_gmail.com" <sbecker6925_at_gmail.com>, oracle-l <
> oracle-l_at_freelists.org>
>
>
> Sandra,
>
> For the love of cheese and rice, I hope these consultants did not actually
> suggest using import/export. Data Pump would be better but probably not the
> ideal method here. Using RMAN DUPLICATE and Data Guard (since your licensed
> anyway) are probably your better option but you could also use
> transportable tablespace or transportable database with Data Pump. You
> could also use GoldenGate if you need to minimize downtime. Good old
> fashioned image copies would even work and would allow you to actually do
> the recovery with archivelogs.
>
> Seth Miller
>
> ----------
> From: *Chitale, Hemant K* <Hemant-K.Chitale_at_sc.com>
> Date: Wed, Oct 15, 2014 at 9:01 PM
> To: sbecker6925_at_gmail.com
> Cc: ORACLE-L <oracle-l_at_freelists.org>
>
>
>
>
> Besides the obvious fact that you can't apply archivelogs and rman to a
> database created through export-import :
>
> 1. 9.2 isn't certified on Solaris 11
>
> 2. 10.2. isn't certified on Solaris 11
>
> You HAVE to upgrade your 9.2 and 10.2 (or 10.1) versions. You could use
> RMAN Backups from 9.2 and 10.2 and RMAN Restore using 11.2 on the Solaris
> 11 server and then upgrade the databases. See the answer to the first
> question in Note#369644.1
>
>
>
> You might consider rebuilding the Standbys if they are small ?!
>
>
>
>
>
> Hemant K Chitale
>
>
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Sandra Becker
> *Sent:* Thursday, October 16, 2014 6:09 AM
> *To:* oracle-l
> *Subject:* Migrate databases to new servers and storage
>
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries at https://www.sc.com/en/incorporation-details.html
> .
>
> ----------
> From: *Seth Miller* <sethmiller.sm_at_gmail.com>
> Date: Wed, Oct 15, 2014 at 10:10 PM
> To: "Chitale, Hemant K" <Hemant-K.Chitale_at_sc.com>
> Cc: "sbecker6925_at_gmail.com" <sbecker6925_at_gmail.com>, ORACLE-L <
> oracle-l_at_freelists.org>
>
>
> That's a great point Hemant. Solaris 11 is so dramatically different from
> 10, you likely will not even be able to install the binaries (if you can
> even find them).
>
> Seth Miller
>
> ----------
> From: *Kenny Payton* <k3nnyp_at_gmail.com>
> Date: Thu, Oct 16, 2014 at 3:28 AM
> To: sbecker6925_at_gmail.com
> Cc: oracle-l <oracle-l_at_freelists.org>
>
>
> I like the standby approach myself. If you're talking about SAN storage
> another option would be to separate the storage move from the host swap.
> If you're using ASM you could let it rebalance to the new disks while
> dropping the old. This can be done on the new or old machine. If not
> using ASM and are using a volume manager you should be able to mirror to
> the new storage and then break the mirror leaving the new storage.
>
> Now you have minimized the downtime to deporting from the old machine and
> importing to the new. One reason this is nice is it allows you to make one
> change at a time and assess the impact.
>
> Kenny
>
>
>
>
> --
> Sandy
> GHX
>
-- Sandy GHXReceived on Thu Oct 16 2014 - 17:46:31 CEST
-- http://www.freelists.org/webpage/oracle-l
