Recently, I had a customer who needed to upgrade their database to 11gR2 from 10.2.0.3. The upgrade needed to move the database from a cooked file system to Oracle’s ASM. Additionally, the customer wanted to have Oracle Enterprise Manager installed and configured.
1. The database is being used as a Data Warehouse database.
2. Database is in no archivelog mode.
3. Database currently administrated by 3rd party not associated with XTIVIA.
4. Database performance is slow with high I/O
1. I verified that there had been NO backups on the database. Due to the fact the database is a Data Warehouse the customer wanted to keep the database in no archivelog mode and do cold backups. I shutdown the database and obtained a full cold backup of the database.
2. Performed two fresh installs of the 18.104.22.168 binaries into two separate ORACLE_HOMES, one for ASM and one for 11gR2. I like to keep the ORACLE_HOMES separate for upgrade, patching, isolation.
3. Obtained RAW disk for ASM. Used Windows utility, DISKPART to size and configure the RAW disk. Finally, I used ASMTOOL to stamp the RAW disk to be used by ASM.
4. I created an ASM instance from the ASM ORACLE_HOME.
4. Set the environment variables to the 11gR2 ORACLE_HOME and ran the Oracle database upgrade assistant (DBUA).
5. During the upgrade I pointed to the appropriate ASM diskgroups for the datafiles to be automatically moved by the DBUA, (this is very nice).
6. During the upgrade I selected that OEM be installed.
7. The upgrade completed.
POST UPGRADE CONSIDERATIONS:
1. During the upgrade the OEM installation failed. I had to manually run emca to remove any previous OEM repository information. I then ran emca again to recreate OEM and this completed successfully.
2. The following were not moved from the 10g directory structure to the new 11g directory structure by the DBUA:
c. Dump directories
I used RMAN to relocate the above referenced files.
This upgrade was relatively painless. ORACLE’s DBUA worked very well! Although, you need to ensure after the upgrade that everything is moved to the proper directory structures.
This upgrade included quite a bit of planning to ensure the move of the redo logs, datafiles, controlfiles and archivelogs to the ASM disk groups. It was important that the I/O was spread out across the disk groups to allow for the best performance.
Finally, it was most important that the cold backup was obtained prior to doing anything.