With this post, I am starting a new blog series about Oracle Database home management, provisioning, patching… Best (and worst) practices, common practices and blueprints from my point of view as consultant and, sometimes, as operational DBA.
I hope to find the time to continue (and finish) it
How often should you upgrade/patch?
Database patching and upgrading is not an easy task, but it is really important.
Many companies do not have a clear patching strategy, for several reasons.
- Patching is time consuming
- It is complex
- It introduces some risks
- It is not always really necesary
- It leads to human errors
Oracle, of course, recommends to apply the patches quarterly, as soon as they are released. But the reality is that it is (still) very common to find customers that do not apply patches regularly.
Look at this:
$ opatch lspatches 26925218;OCW Patch Set Update : 22.214.171.124.180116 (26925218) 26925263;Database Bundle Patch : 126.96.36.199.180116 (26925263) 22243983; OPatch succeeded. $ cd $ORACLE_HOME/inventory $ grep -r "bug description" * | wc -l 1883 $ grep -r "bug description" * | grep -i "wrong result" | wc -l 56
With January 2018 Bundle Patch, you can fix 1883 bugs, including 56 “wrong results” bugs! I hope I will talk more about this kind of bugs, but for now consider that if you are not patching often, you are taking serious risks, including putting at risk your data consistency.
I will not talk about bugs, upgrade procedures, new releases here… For this, I recommend to follow Mike Dietrich’s blog: Upgrade your Database – NOW!
I would like rather to talk, as the title of this blog series states, about the approaches of maintaining the Oracle Homes across your Oracle server farm.
Common worst practices in maintaining homes
Maintaining a plethora of Oracle Homes across different servers requires thoughtful planning. This is a non-exhaustive list of bad practices that I see from time to time.
- Installing by hand every new Oracle Home
- Applying different patch levels on Oracle Homes with the same path
- Not tracking the installed patches
- Having Oracle Home paths hard-coded in the operational scripts
- Not minding about Oracle Home path naming convention
- Not minding about Oracle Home internal names
- Copying Oracle Homes without minding about the Central Inventory
All these worst practices lead to what I like to call “patching madness”… that monster that makes regular patching very difficult / impossible.
THIS IS A SITUATION THAT YOU NEED TO AVOID:
Server A /u01/app/oracle/product/12.1.0 -> Home "OraHOme12C", contains clean 188.8.131.52 Server B /u01/app/oracle/product/184.108.40.206 -> Home "OraHome1", contains 220.127.116.11.PSU161018 /u01/app/oracle/product/18.104.22.168.BP170117 -> Home "OraHome2", contains 22.214.171.124.BP170117 Server C /u01/app/oracle/product/12.1.0 -> Home "OraHome1", contains clean 126.96.36.199 /u01/app/oracle/product/188.8.131.52 -> Home "DBHome_1", contains 184.108.40.206.BP170117
A better approach, would be starting having some naming conventions, e.g.:
Server A /u01/app/oracle/product/220.127.116.11 -> Home "Ora12cR2", contains clean 18.104.22.168 Server B /u01/app/oracle/product/22.214.171.124.PSU161018 -> Home "Ora12cR2_PSU161018", contains 126.96.36.199.PSU161018 /u01/app/oracle/product/188.8.131.52.BP170117 -> Home "Ora12cR2_BP170117", contains 184.108.40.206.BP170117 Server C /u01/app/oracle/product/220.127.116.11 -> Home "Ora12cR1", contains clean 18.104.22.168 /u01/app/oracle/product/22.214.171.124.BP170117 -> Home "Ora12cR2_BP170117", contains 126.96.36.199.BP170117
In the next blog post, I will talk about common patching patterns and their pitfalls.