Re: Process and tools for managing Critical Patch Updates

From: Wayne Smith <wts_at_maine.edu>
Date: Mon, 30 Apr 2012 11:09:49 -0400
Message-ID: <CAEgY-F4_cPrJJzf7_1_vNOmTD2wJHHmx9Yzy5-ZNpWX=DzRQYg_at_mail.gmail.com>



That's a great question, Stan.
I've been thinking about the same area. This doesn't have to be an all-or-none solution ... you (I) could build it over time and each part could be useful as it is available to be deployed.
  • script to connect to a/each machine and verify/determine
    • Op/sys
    • homes
      • patchset
      • CPU/PSU
      • running services
      • script to download/explode appropriate CPU/PSU patch(es)
  • script to run/return/analyze "opatch prereq CheckConflictAgainstOHWithDetail"
  • (actually applying CPU/PSU with total automation is beyond what I want to do, but I might build a script to take Oracle down, a script to run/record/analyze patch application and another to bring things up as they were?)

Have others addressed this area with code they can share or see issues deserving warning?

Cheers, Wayne

  • "Never argue with an idiot. They drag you down to their level and then beat you with experience." - Unknown

On Mon, Apr 30, 2012 at 10:07 AM, Kroll, Stanley R. <krolls_at_umsystem.edu>wrote, in part:

> Our environment:
> 95% RHEL5
> 5% Windows
> Approximately 120 Oracle EE 11.2.0.2 databases.
> 3 DBAs
> We're looking for a method to help automate the application of the
> quarterly CPUs. We've looked into the Database Lifecycle Management Pack
> to help provide automation for the process but that is very costly. We
> can manually apply the CPU to each database but as the number of databases
> increase and our head count does not, that approach does not scale well.
> We've thought about somehow building our own automation but that can
> become a maintenance issue over time.

>

> I would be interested in hearing about the tools and processes that others
> use to manage the application of CPUs across many database installations.
>
--
http://www.freelists.org/webpage/oracle-l
Received on Mon Apr 30 2012 - 10:09:49 CDT

Original text of this message