9 Replies Latest reply on Apr 20, 2012 8:04 AM by Jeff Orndorff

    Oracle Patch Compliancy

    Anthony Bove

      I am trying to come up with a good way to verify installation of oracle patches on a DB. I can do this via 'opatch lsinventory' using extended objects. However, the tricky part for me is ensuring the compliance rule(s) check all the DBs on a given server. With some scripting, I can identify the DBs on a server and run 'opatch' against each of them successfully using a 'for' loop. This doesn't work so well for EOs, though, when attempting a compliance rule. Another option I thought of is prior to running the compliance job, having the 'opatch' export the patch info for each DB to temp file based on a standard naming scheme (i.e., opatches_). I can then wildcard my compliance rule so it will check all the files. The problem here is that I then would have to make sure every file I want to check is added as a template part. This would be nearly impossible to accomplish, as there are hundreds of servers in the client's environment with thousands of DBs in total (plus it isn't exactly clean because it lumps all the DB files into 1 check). Any suggestions?


      Regards, Tony


      Message was edited by:

      tony bove

        • 1. Re: Oracle Patch Compliancy
          Bill Robinson

          1 Create a Template for Oracle, make the EO local to the template.


          2 Create instances for all the possible databases that exist in the environment (I have a script that can help w/ this) and then setup the discovery conditions on the template such that it will find the various instances on a particular server.


          3 then perform your compliance checks on the components (instances of oracle)


          4 profit!

          • 2. Re: Oracle Patch Compliancy
            Anthony Bove

            Bring on the script, swammie! I am looking forward to mass spawning property instances! :)

            • 3. Re: Oracle Patch Compliancy
              Bill Robinson

              4th post down:




              I did this for a customer that had tons of oracle instances that were constantly changing (moving between servers, active/inactive, etc), though not specifically w/ the opatch. I had a bunch of EOs that ran sql commands and we did compliance on that output.


              This seemed to work well for them because instead of knowing what server had violations, they knew what instance of oracle had violations and the name of the instance pointed to the culprit where as the servers were shared.

              • 4. Re: Oracle Patch Compliancy
                Anthony Bove

                Thx man, will peruse...

                • 5. Re: Oracle Patch Compliancy
                  Anthony Bove

                  Just a little post-mortem on this one. The client has apprx 4K dbs & 11K instances among them, so we were concerned about the scalability of adding local instances/components by either of those classifications. So, we revisited the prior idea of dumping the opatch lsinventory results into separate a file per DB on the local targets. We then realized we could prevent having to add every single file as part to our component template by instead grabbing the directory where those files reside instead and setting up a wildcard inclusion at the file level for them. Then, our compliance rule states that the 'wildcarded' file must exist and that its contents must contain the patch number we're looking for. The only drawback is that now compliance is judged at the 'server' level per patch, instead of at the db level. Therefore we can't 'remediation' patch at the db level. Instead, we'd have to build some additional intelligence into our remediation packages to check which dbs were missing the patch being deployed and only deploy to those dbs.


                  Regards, Tony

                  • 6. Re: Oracle Patch Compliancy
                    Bill Robinson

                    For that amount of db instances I think you're right to go w/ the non-instance approach. Though we should raise this issue w/ the scaleablility team.


                    i bet w/ some work you could have your deploy package read the EO files and then install patches to the db instances that were missing the patch. basically put all the logic that's in your rules into a script that then runs the opatch against the instance.

                    • 7. Re: Oracle Patch Compliancy

                      I am interested in the script you developed for creating instances for all possible databases.  I may need to develop a report for Oracle patch complaince at my site.  The link referenced above is no longer working.


                      Thanks in advance for your expert assistance.

                      • 8. Re: Oracle Patch Compliancy
                        Bill Robinson

                        Let’s see if they are attached now.


                        You had to do this in two parts – you have to use a script to find all the oracle instances and setup the local parameter instances in the CT.  Then you run discovery which creates components for the servers depending on what exists.  Yes – you are ‘discovering’ the same thing twice, once w/ find and once via blade.  that’s just how it is.  I haven’t used these scripts since 7.4 so ymmv.  The logic should be the same but the blcli commands may be different now.  the set_oracle_componet_props.nsh was to set a bunch of props the EOs used later like SID and such to run whatever the EOs were doing.

                        • 9. Re: Oracle Patch Compliancy

                          Thanks again - Greatly appreciated.