For about the last … hmmm…maybe decade or more, when you downloaded a release update from MOS for your database, the patch would consist of a single folder which was the patch number.
You would unzip that to temporary location, download a fresh copy of OPatch and then patch your database. OPatch would take the relevant files from the patch folder and overlay them into the existing (or preferably new) $ORACLE_HOME. Once that was done, you would run ‘datapatch’ to patch the dictionary and the job was done.
So it may come as a bit of a surprise to you (it did to me) when you download the first release update for Oracle Database 26ai, which will take your database from 23.26.1 to 23.26.2. After I downloaded the patch zip file, the zip file contents looks like this:
That looks very much like the complete contents of an ORACLE_HOME and indeed it is. The “patch” is shipped as a freshly update gold image of the software. You simply unzip into a fresh ORACLE_HOME.
If you’re using AutoUpgrade (which you should be) this might all go unnoticed, but if you take a look at the README file within the patch, you will see the new approach. No more running OPatch!
The first step is to execute “runInstaller” just like a fresh database installation, although notice the “setupDBHomeAs” parameter which gives the installer a reference point to the existing ORACLE_HOME. I omitted the “silent” parameter so I could observe what was happening.
Once the installation is complete it is now time to the move your database(s) to the new ORACLE_HOME and ‘dbca’ has a parameter to do this task for you. Make sure you start your database in the original ORACLE_HOME before commencing.
Once this complete your database is now running under the new ORACLE_HOME.
A couple of discoveries I made:
If your database is not running before ‘dbca’, you’ll get an error
If your listener is not running, then the database will be migrated to the home but the listener will not be migrated.
Your running listener is migrated across, but this will be a new listener based on the existing running listener not the actual listener.ora file from your original ORACLE_HOME. I had some customised entries in my listener.ora that were not migrated. I recommend you go through each relevant file in your existing ORACLE_HOME and migrate across yourself after making any changes. Check out Daniel’s post on the potential list of files you need to look for. (Another reason why AutoUpgrade is good – it will take care of this for you)
Once dbca is finished, make sure you re-run ‘oraenv’ to pick up a fresh environment. Your oratab will be updated automatically but your existing shell will probably still be the old ORACLE_HOME (and you’ll get a shock when it says your database is idle :-))
I like this new patching method. It’s simpler, no more worrying about the right OPatch and the default mechanism is an out-of-place patch, which gives you an easier insurance policy if you have to abort and go back to the original ORACLE_HOME.
And of course, if you use AutoUpgrade then you’ll less likely to run into any quirks with files and database start/stop procedures.
Leave a Reply