Since we’re encouraging clients to move off Oracle 10g, we’d like to write up three of the 11g upgrades that we’ve done, to raise the comfort level of those who are still “window shopping” Oracle 11g.
Example upgrade #1 involved an upgrade from Oracle 10.2.0.4 to 11.1.0.7. This upgrade was an export/import upgrade, meaning that we exported the data from the 10.2.0.4 database, created an empty 11.1.0.7 database, and imported the 10.2.0.4 data into the 11.1.0.7 database. There were more steps involved than that, but that’s the big-picture view of how the upgrade was done.
The export/import style of database upgrade is a good one because it leaves the source database (the current database) unchanged. This can mean a relatively uncomplicated retreat, should something go wrong with the upgrade or should the client determine that their application is not running properly on the upgraded database. The export/import method also allows a jump to a different machine and even a different operating system at the same time the database upgrade is done. This is the most popular option for our clients, who often implement a new server at the same time as they upgrade their databases. One drawback to the export/import method is that, unless the amount of application data is relatively small, it usually involves a longer outage than other upgrade options.
So, back to example upgrade #1. This client implemented a new VM for the 11g database, so we created the new empty 11g database there, then imported the data from the 10.2.0.4 database. The client performed application testing, made some application changes on the production database, and then we re-imported from production 10.2.0.4 to the new 11g database. After a couple of cycles of this, the client was ready for the production cutover.
The application performs about the same on 11g as it did on 10g.
The weird things that happened with this database upgrade were unique to this client, because they’re still using an old custom application that initially didn’t respond well to the newer Oracle database. The client discovered the issues while testing prior to the production cutover and was able to work around them.