Re: Use EM 11g Grid Control (or 12c) versus opatch to save time with quarterly PSUs?

  • From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
  • To: oratune@xxxxxxxxx
  • Date: Fri, 20 Jul 2012 18:57:37 +0100

But there won't be any cpu/psu for those anyway.
I haven't played enough with em12c to say how well I'd like the patching.
In previous releases though em took the view that all you were doing was
patching the platform. Management of the applications during the patching
process was outside of the remit of em unless you were running an all
Oracle setup, and even then patches were released for Oracle products that
broke support for the target in em. So you'd still have to arrange downtime
or failover, still need to arrange restarts/fail back and so on. In
contrast using Enterprise schedulers while painful sometimes could
certainly achieve this. We had a client that we applied patches quarterly
using a scheduler, batch files (windows) and opatch for db and middleware
including app downtime, failover and client notification. It took about 3-4
hours to do 8 prod Oracle homes, 12 databases inc standbys and 10-12
webapps. EM was never going to compete. Oh and we didn't need a license for
whatever the deployment pack is actually called. I love EM but its a hell
of a way to do Enterprise automation prior to 12 at least.
On Jul 20, 2012 6:25 PM, "David Fitzjarrell" <oratune@xxxxxxxxx> wrote:
>
> There may be installations still using 9.2.0.x (I'm supporting one now)
and EM12c won't 'talk' to any release prior to 10.
> David Fitzjarrell
>
>
>
> ________________________________
> From: Peter Sharman <pete.sharman@xxxxxxxxxx>
> To: dananrg@xxxxxxxxx; oracle-l <oracle-l@xxxxxxxxxxxxx>
> Sent: Friday, July 20, 2012 10:09 AM
> Subject: RE: Use EM 11g Grid Control (or 12c) versus opatch to save time
with quarterly PSUs?
>
> Dana
>
> I'll leave any comments on the politics of the situation to others.
>
> Purely from a product perspective, I would see no reason to upgrade to EM
11g now that 12c has been released and out for a while.  The additional
functionality you get with the 12c release is a huge step forward, and
since you can upgrade from 10.2.0.5 direct to 12c, you might as well take
advantage of that.  To take the patching issue that you mention alone,
there are new out of the box procedures to perform mass database upgrades
in parallel, minimum downtime patching for single instance environments,
FMW domain cloning and topology scaling, and WebLogic application mass
deployment, just as some examples.  And of course, much more in other areas
which I won't go into because it'll make me sound like a salesman.  :)
>
> Pete
>
> Pete Sharman
> Principal Product Manager
> Enterprise Manager Product Suite
> 33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
> Phone: +61262924095 | | Fax: +61262925183 | | Mobile: +61414443449
>
> "Controlling developers is like herding cats."
> Kevin Loney, Oracle DBA Handbook
>
> "Oh no, it's not, it's much harder than that!"
> Bruce Pihlamae, long term Oracle DBA
>
>
>
> -----Original Message-----
> From: Dana Nibby [mailto:dananrg@xxxxxxxxx]
> Sent: Friday, 20 July 2012 6:39 PM
> To: oracle-l
> Subject: Use EM 11g Grid Control (or 12c) versus opatch to save time with
quarterly PSUs?
>
> For a shop with 30 instances on a dozen hosts, would it make sense to use
Grid Control EM 11g or EM 12c to deploy PSUs? Is one more reliable than the
other? Our approach is opatch. And each quarter it takes much labor, time,
and frustration to complete. We have an aging but functioning EM 10g Grid
Control infrastructure. Never tried to use it for patching. But we have the
diagnostic + tuning packs for our instances. So we should be licensed to
use this technology for PSUs.
> When I've suggested we upgrade to EM 11g or EM 12c I typically get a
response of the variety "we don't have time for that" (e.g. researching,
testing, and then deploying EM 11g or 12c). My opinion? We don't have time
*not* to do this. It's an investment in efficiency and I take the long
view. It gives me no pleasure, and much pain, to repeatedly hear "we don't
have time to learn X" when X is something that will improve efficiency,
customer service, excellence, etc.
>
> Sound familiar to anyone? If so, how have you played it short of finding
another gig? I may try to track all staff hours involved with getting July
PSUs completed to have some baseline metrics--everyone from the DBA team
(reading about quirks and idiosyncracies of various PSUs on particular
platforms/Oracle releases) to sysadmins to ops to managers, etc. In the
time it takes to coordinate and execute the work using opatch, I can't help
but wonder if we could have set-up at least EM 11g Grid Control in
preparation for the next quarter. For now, I'm trying to socialize a
January 1st, 2013 date to deploy EM 11g or EM 12c for patching and other
goodness. You know, try to implement it, at least on some Production Floor
dev and test boxes, when things have slowed down and most people (here in
the U.S.) will be out of the office.
>
> It may be that patching with EM 11g or EM 12c isn't patching nirvana. I'm
not sure precisely how many staff hours (and frustration) it might save.
Would love to hear personal stories here. But I'll settle for incremental
improvement so we can move on to work higher up the value chain. If all my
instances got moved to The Cloud, for instance, patching is a task I
wouldn't miss.
>
> Finally, are there cases in which folks would recommend sticking with
opatch versus applying patches with Grid/Cloud Control? I imagine in very
small shops using opatch would be fine. But in shops as large as the one
I've described or larger--when DBAs are managing hundreds or thousands of
instances--I can't imagine using opatch. Not unless it is fully scripted in
some way.
>
> If no one bites, and persists in saying "we don't have time for this",
I'm going to make time on my home sandbox and work everything out there on
my own time. Feels like The Right Thing To Do. Because an operational DBA
group could always say "we don't have time for X." It's a bit like saying
"I don't have money to invest in a retirement plan." Decades pass and then
you find you have to work forever...
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
> --
> //www.freelists.org/webpage/oracle-l
> --
> //www.freelists.org/webpage/oracle-l
>
>


--
//www.freelists.org/webpage/oracle-l


Other related posts: