Pythian Blog: Technical Track

Migrating Your 10G Database to ODA with Minimal Downtime

Oracle Database Appliance (ODA) saves lots of time and effort on deployment, but you still need to migrate your databases to it. Often, it also means upgrading to the latest database release that ODA is running. This blog post is a short summary of one of our migration strategies used to migrate Oracle 10g databases to ODA, balancing the requirements of minimal downtime and efforts/costs of the project.

This solution is assembled from several different Oracle Support notes. When we were doing it the first time, we knew that all the ideas should work, but we wanted to make all the steps be fully supported so that the customer had full confidence in the migration and that we could rely on Oracle support if we hit any bugs along the way.

  1. Restore the database from 10G backup using 11G software on ODA (Oracle Database Appliance) — My Oracle Support Note ID 369644.1 Frequently Asked Questions about Restoring Or Duplicating Between Different Versions And Platforms.
  2. Open database in Upgrade mode.
    [sql]alter database open upgrade;[/sql]
  3. Upgrade the database — My Oracle Support Note ID 837570.1] Complete Checklist for Manual Upgrades to 11gR2.

I see your question now: “Hey Yury, what about minimal downtime?”

I bet some of you know the answer already. If we can restore and recover from a previous version’s backup, then we can apply archive logs from previous versions, right? Just keep applying newly generated archive logs in between step 1 and 2 until you are ready for migration cutover. When your migration window starts, stop the replication and make sure the database on ODA is up to date. In 1 hour, your production will be upgraded to 11G and up and running on your brand new ODA box. If anything goes wrong at this stage, your fallback strategy is very simple — go back to the old 10g environment that’s still intact.

Some additional points to mention are:

  • You can use this method to migrate 9.2 or later releases :)
  • You can migrate different “bitness” levels 32=>64 and 64=>32
  • You can migrate between the same endian platforms with “CONVERT DATABASE” RMAN command (2012.07.10 Yury: This options have limitations, please read the note carefully. Thanks to Jan for pointing it out.)
  • This migration strategy is not ODA specific. Why it makes it good fit for ODA customers is that ODA customers want simple and reliable solution at very reasonable cost.

I would like to thank my Tweeter community for helping me connecting the dots. In particular Philippe Fierens, Martin Berger, Ilmar Kerm, Fuad Arshad and Bjoern Rost — you folks are my great friends.

If you are reading this blog, you should follow these folks as they really add value and know what they are talking about.

BTW: If you are looking for a partner to help you out with your ODA (or any other) database migration you know where to find us :) – click here

No Comments Yet

Let us know what you think

Subscribe by email