Re: Use EM 11g Grid Control (or 12c) versus opatch to save time with quarterly PSUs?
- From: Dana Nibby <dananrg@xxxxxxxxx>
- To: "niall.litchfield@xxxxxxxxx" <niall.litchfield@xxxxxxxxx>, "oratune@xxxxxxxxx" <oratune@xxxxxxxxx>
- Date: Sat, 21 Jul 2012 02:58:49 -0700 (PDT)
Much thanks to Pete, Michael, David, Niall, and anyone else I've omitted.
Bheem, yes we use a separate database instance for our EM repository.
Here are some takeaways from this thread. And a bit more gratuitous
editorializing (hoping someone out there can relate / expand / expound--if not
online then off). Please correct me if I've misstated anything. Or if anyone
else has a difference of opinion (or fact). Or would like to share their
experiences with ways to make quarterly patching more efficient.
* T1: Bypass EM 11g and go straight for 12c; and there is a direct upgrade path
from EM 10.2.0.5 to 12c.
Commentary: I'd imagine EM 12c would naturally have great synergies with the
v12 RDBMS. Has it even been hinted at when the v12 db engine will be released?
* T2: Automated patching requires either the Provisioning pack (an offline
answer. Is this 11g terminology?) or the Lifecycle Management Pack (Michael).
Commentary: This isn't realistic for us. No money for additional packs.
Management has required the org to migrate every app that does not absolutely
require Oracle (e.g. third party vendor apps that support only Oracle on the
back-end) over to SQL Server. This is due to a perceived overall cost savings;
and evidently so the developers--who
chiefly program in C# / .NET--can have the same Vendor Stack / be better
integrated with Visual Studio. As for cost, I haven't seen any TCO figures on
licensing, any labor calculations for converting in-house Oracle apps to SQL
Server apps. The latter isn't "free", right? And probably not even trivial if
SQL Server has different implicit behaviors when it comes to, I don't know,
default sort orders or other "gotchas" that may not be immediately apparent.
Not saying I know what the subtle differences in SQL/behavior might be--just
that they likely exist and may not be evident and/or easy to debug later on.
And what's the cost of that?
Whether these developers (good people to work with; no gripes here) view an
RDBMS as another more than a Data Dumpster / Black Box, I'm not sure. But this
seems to be a common Developer view out there in the larger world, e.g. just
let us use objects for data access and we don't care what's on the back-end. If
this is a growing view, is it growing in correctness? Abstraction can be a good
thing. Except when it isn't...
And although I haven't used SQL Server much, and am not making an argument for
its use (there are obviously many more considerations in RDBMS selection than
ease of patching and superficial cost estimates), I've heard anecdotally that
patching for SQL Server is a breeze. That it happens automagically like Windows
Updates? Can anyone who manages both Oracle and SQL Server comment on what's
really the case there, warts and all? I'd rather focus all my energies on
Oracle. But the reality is that I may have to ramp up on SQL Server rather
quickly. Any good resources out there for DBAs who must add SQL Server support
to their duties? The decision has been made, the migration work has begun, and
the org must live with it. Wonder if anyone else is finding themselves in this
position--wanting to grow their Oracle expertise while having their attention
and time siphoned off by new SQL Server instances / migrations. Not sure I have
the mind space and memory to
know both platforms equally well. I've nothing against SQL Server per se. But
Oracle is vast. And I often feel I've only scratched the surface with it.
* T3: Overall patching in diverse Oracle environments is still complicated
enough that automation through EM isn't necessarily a no-brainer in time
savings for a "large" Enterprise.
Commentary: I'd love to hear more details / opinions about quarterly patching
and how to make it faster / less painful in large Enterprises; whether that
includes additional licensed packs for EM 12c or not.
Thanks again for the replies. Sorry for including org politics. It's likely
wise not to comment. And probably unwise for me to have mentioned it. But it's
very frustrating. And if I can't do The Right Thing, I'd at least to have
validation about what the Right Thing is or could have been. Just always
looking for ways to be more efficient and add value. And "if that's wrong, I
don't wanna be right" to crib a turn of phrase from I know not where. :-)
Have a great weekend everyone.
Best,
Dana
________________________________
From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
To: oratune@xxxxxxxxx
Cc: Dana Nibby <dananrg@xxxxxxxxx>; ORACLE-L <oracle-l@xxxxxxxxxxxxx>;
"pete.sharman@xxxxxxxxxx" <pete.sharman@xxxxxxxxxx>
Sent: Friday, July 20, 2012 1:57 PM
Subject: Re: Use EM 11g Grid Control (or 12c) versus opatch to save time with
quarterly PSUs?
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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
