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

  • From: Peter Sharman <pete.sharman@xxxxxxxxxx>
  • To: oratune@xxxxxxxxx, dananrg@xxxxxxxxx, oracle-l <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 20 Jul 2012 14:21:01 -0700 (PDT)

Actually, that's incorrect David, unless you're talking about the repository.  
As a managed target, 12c will "talk" to the following (straight off the 
certifications tab in MOS):

Oracle Database (Managed Target)        8 Releases (11.2.0.3.0, 11.2.0.2.0, 
11.2.0.1.0, 11.1.0.7.0, 10.2.0.5.0, 10.2.0.4.0, 10.1.0.5.0, 9.2.0.8.0).

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: David Fitzjarrell [mailto:oratune@xxxxxxxxx] 
Sent: Saturday, 21 July 2012 3:22 AM
To: Peter Sharman; dananrg@xxxxxxxxx; oracle-l
Subject: Re: Use EM 11g Grid Control (or 12c) versus opatch to save time with 
quarterly PSUs?

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: