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.
- 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.
- Open database in Upgrade mode.
[sql]alter database open upgrade;[/sql] - 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
14 Comments. Leave new
Great blog, Ive got one question:
‘You can migrate between the same endian platforms with “CONVERT DATABASE” RMAN command’
Why do You need convert database if You are on the same endian .
That doesnt make sense to me .
Regards
GregG
I agree Greg, that it doesn’t make sense to me ether. This is how Oracle build it in the current version. I am guessing we should ask Oracle about it ;)
Hey Greg,
I just happened to came across the reference for you. Check this out :)
One prerequisite is that both the source and destination platform *MUST* share the *SAME* endian format.
https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmxplat.htm#BRADV89986
Oracle® Database Backup and Recovery User’s Guide
11g Release 2 (11.2)
Part Number E10642-05
27 Transporting Data Across Platforms
“Checking the Database Before Cross-Platform Database Conversion”
[…] is just a “proxy” blog post with a new title. Yesterday I published “Migrating your 10G database to ODA with minimal downtime“. However if you read it carefully the upgrade process described isn’t ODA specific. […]
Hi Yury
Interesting article, especially because I’m currently working on something similar (10.2 Windows -> 11.2 Linux).
I’m not sure if I read the MOS article the same way as you do. ;)
You write that this will work for migration 9.2 or later. But DOC ID 369644.1 states, that this cross-platform restores are only supported for 10.2 or above. In DOC ID 1079563.1 is stated, that they assume (I interpret this as “support”) that source and destination database are the same version. Also there are only a few supported cases for 10.2. Windows->Linux is only supported for 11.1 or above. This basically leads me to the conclusion, that for my case a cross-platform restore is not a supported option.
Did you come to another conclusion, or did I misunderstand you?
Jan
Hey Jan,
I just reviewed the documents you are referencing in a bit more details and I think your understanding is correct.
Just wonder if you can try to use Transportable Tablespaces? Unless you are running application with huge number of objects it should work.
It works even for EBS :). If you wish I can give you some MOS references for EBS TT method to use as an example.
PS I am adjusting relative part of the blog now.
Thank you for pointing it out,
Yury
Hi Yury
Transportable-Tablespaces would probably work, but the time needed to get them out of the source-ASM (3-Node Windows RAC) and into the target-ASM (2-Node Linux RAC) would take to much time (databases are quite big, the downtime-window quite short).
For Windows->Windows I once did something like this (physical standby to target system with same version, then Transportable Tablespaces from that standby-database to the target-database with higher version) resulting in a downtime of about 15 minutes. Would have been cool if this would have been a supported case for this situation, too. No such luck, I guess.
Kind regards,
Jan
Hey Jan,
Well in your current case most probably the easiest option is to (step A) upgrade the DB to 11G level on the source system and (step B) move it to new host.
step A optimization – can use transportable tablespaces as you described with 15 mins downtime
step B optimization – 11G stand by in between Windows and Linux method with downtime 5-15 minutes
Total downtime = 20-30 mins with a price of a bit of work to optimize things or 1h15mins without optimization.
Yury
Hi Yury
Didn’t notice your answer until now.
Well, I could install 11gR2 on the source machine. But: It’s a RAC. That means I would have to upgrade CRS to GI first. Why oh why didn’t I think of this before? Maybe next time. :)
Jan
Hi Yury,
How do you overcome the compatibile.rdbms setting of the DATA diskgroup on ODA, which is set to 11.2.0.2?
How do you restore a 10g databases into the DATA diskgroup with the above setting?
The way how I did it – I wasn’t aware of this MOS note – which is probably not supported:
1. Removed all stuff from the DATA diskgroup
a, removed ocr mirror
b, moved voting disks to RECO
c, moved asm spfile to RECO
2. Dropped DATA diskgroup and recreated with a lower rdbms compatibility level
3. Installed 10gR2 Oracle on one of the instances.
4. Restored 10g DB into DATA
5. Setup standby with the source system
6. Switched over in the maintenance window
7. Upgraded to 11.2.0.2
8. Moved all the stuff back to the DATA diskgroup
9. Business started.
Kind regards,
Istvan
Hello Istvan,
>> How do you overcome the compatibile.rdbms setting of the DATA diskgroup on ODA
The key here the the fact that you can restore 10G database using 11G software and open it using “alter database open upgrade” option. If you set *.compatible=11.2.0.x (3 in my case) you can restore 10G database on 11G compatibile.rdbms ASM disk group. The rest is simple.
Before I discovered the note I used close to your described method to migrate 10G database to ODA. The only difference I left all the system components on DATA disk group and “steal” several HDDs from DATA using ASM re-balancing. Than I have created an intermediate disk group DMIG with compatibile.rdbms = 10G and established 10G standby the same way you did. After the upgrade completed I moved data files from DMIG to DATA (using refreshable image copies) and re-added the DMIG disks back to DATA disk group. This way I have kept the ODA configuration as close to initial as possible.
Yury
You could also use old school snapshots (if you’re on standard), which is what i just did and had less than 5 min down for 10g -> 11g, Solaris -> Linux, EMC -> Netapp. Was a massive move. This allows us to do full functional testing. One caveat, you MUST have PKs on the big table otherwise the drop snapshots will insist on performing a full tablescan prior to drop/convert to real table. Alternative, if you’re on EE, use streams to replicate the DBs and perform the cut-over.
Thank you for the comment Shakir,
Replication (MV, streams, home grown, etc) is a valid migration option and quite often provides minimal downtime. The only disadvantage comparing with SBY or Restore method is the fact that there are quite a lot application dependent limitations. Those need to be addressed depending on the application used (e.g. data types, PKs etc).
Replication may require more DBA time to get it working for an application.
I would say it is a trade off between minimal downtime (Replication) and migration simplicity/cost (SBY).
Yury
Absolutely, agreed.