Oracle Home Management – part 1: “Patch soon, patch often” vs. reality

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 : 12.1.0.2.180116 (26925218)
26925263;Database Bundle Patch : 12.1.0.2.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 12.1.0.2

Server B
/u01/app/oracle/product/12.1.0.2          -> Home "OraHome1",   contains 12.1.0.2.PSU161018
/u01/app/oracle/product/12.1.0.2.BP170117 -> Home "OraHome2",   contains 12.1.0.2.BP170117

Server C
/u01/app/oracle/product/12.1.0            -> Home "OraHome1",   contains clean 12.1.0.1
/u01/app/oracle/product/12.1.0.2          -> Home "DBHome_1",   contains 12.1.0.2.BP170117

A better approach, would be starting having some naming conventions, e.g.:

Server A
/u01/app/oracle/product/12.1.0.2           -> Home "Ora12cR2",           contains clean 12.1.0.2

Server B
/u01/app/oracle/product/12.1.0.2.PSU161018 -> Home "Ora12cR2_PSU161018", contains 12.1.0.2.PSU161018
/u01/app/oracle/product/12.1.0.2.BP170117  -> Home "Ora12cR2_BP170117",  contains 12.1.0.2.BP170117

Server C
/u01/app/oracle/product/12.1.0.1           -> Home "Ora12cR1",           contains clean 12.1.0.1
/u01/app/oracle/product/12.1.0.2.BP170117  -> Home "Ora12cR2_BP170117",  contains 12.1.0.2.BP170117

In the next blog post, I will talk about common patching patterns and their pitfalls.

 

关注dbDao.com的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569