This content has been marked as final. Show 15 replies
In your scenario DB upgrade, platform change and storage move to ASM are involved.
Better first start with DB upgrade to 18.104.22.168.
22.214.171.124 is supported on Windows server 2003 R2
To know upgrade steps, refer
Note 837570.1 Complete Checklist for Manual Upgrades to 11gR2
Note 870814.1 Complete checklist to upgrade the database to 11gR2 using DBUA
Once upgrade is completed, you can move DB to ASM file system in windows 2008 R2
Steps are mentioned in
Steps To Migrate/Move a Database From Non-ASM to ASM And Vice-Versa (Doc ID 252219.1)
Since DB is upgrade to 126.96.36.199, we can utilize new features to upgrade to 11gR2
I kinda agree with 'Simon DBA': split the hardware upgrade from the transition to ASM.
If it was me, I'd install 188.8.131.52 on the new server, and simply copy the database across.
Then, once that was working well, I'd upgrade to 184.108.40.206.
Then, once that had been tested to be working, I'd use RMAN to duplicate the database into new ASM storage.
Otherwise, there are too many moving parts. I'd certainly want to test and evaluate each one before moving on. (But maybe I'm just cowardly).
My DB size is around 500GB.
I agree Export/import or datapump is an option. Since there are many inter dependencies between the DB schemas i fear the import will fail or complete with inconsistencies. Also resolution of these errors will be a mammoth exercise.
yes RMAN can be used. Since i am migrating the database all together to the new hardware and new OS (win2008) i think out-of-place upgrade cannot be considered. I believe out of place upgrade should be done in the same environment without changing the hardware or OS.
The steps given by you fits if i wanted to upgrade the DB to 220.127.116.11 and move the Database from Non-ASM to ASM in the same server environment.
In my case i wanted to migrate the database to the new hardware, new OS, new DB version with ASM.
Hi Catfive Lander ,
When you say "I'd install 18.104.22.168 on the new server" you mean 22.214.171.124 on windows 2003 or windows 2008 OS ?
To sum up i am expecting a migration procedure like the one below. But not sure whether this is possible.
1. Install 2008 OS in the new server.
2. Install 126.96.36.199 GI & Oracle RDBMS binaries and patches.
3. Take a cold backup of the source 188.8.131.52 DB using RMAN or Manual method.
4. Restore in the 184.108.40.206 DB. (But dont open the DB)
5. Upgrade the DB using DBUA.
6. Move the Database from Non-ASM to ASM
7. Test and evaluate the DB.
There's no need to have steps 4 and 6 separate. When you do the RMAN restore in step 4 just restore it into ASM.
Keep in mind that ASM software runs out of it's own home. Seems like you're not RAC so it would be "Standalone Grid Infrastructure". That software should be at the highest release so install the GI home as 220.127.116.11. That will be fine for the 11gR1 database, heck even a 10g database can use a 11gR2 GI home. ASM and your listener will run from the GI home.
And as far as "out-of-place" goes, you're really still on the same OS - it's still Windows. You're not changing Endian which would make things much more complicated.
So you can just take a backup of the old 11.1 database on Win2003, restore that into ASM on Win2008, open it with the 11.2 RDBMS software as "startup upgrade" and then perform the upgrade. You don't actually need to even have the 11.1. software on the Win2008 machine.
Thanks for the migration approach provided. What are the steps required to be completed in the new server before restoring the RMAN backup on win2008 ?
I have completed the below steps in the new server.
1. Install 2008 OS in the new server.
2. Configure storage for ASM in the new server.
3. Install 18.104.22.168 standalone GI & Oracle RDBMS binaries and patches.
But there is no DB instance created so far in the new server. In this case how to map the RMAN backup with the database on the new server?
Also i like to know the steps required to "Restore RMAN backup into ASM on Win2008". I checked the below MOS doc but it seems it does not use RMAN backup.
Steps To Migrate/Move a Database From Non-ASM to ASM And Vice-Versa [ID 252219.1]