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)
Bring on the script, swammie! I am looking forward to mass spawning property instances! :)
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.
Thx man, will peruse...
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.
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.
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.
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.
Thanks again - Greatly appreciated.