Re: Use EM 11g Grid Control (or 12c) versus opatch to save time with quarterly PSUs?
Date: Sat, 21 Jul 2012 02:58:49 -0700 (PDT)
Message-ID: <1342864729.76350.YahooMailNeo_at_web113508.mail.gq1.yahoo.com>
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_at_gmail.com> To: oratune_at_yahoo.com
Cc: Dana Nibby <dananrg_at_yahoo.com>; ORACLE-L <oracle-l_at_freelists.org>; "pete.sharman_at_oracle.com" <pete.sharman_at_oracle.com> 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.
-- http://www.freelists.org/webpage/oracle-lReceived on Sat Jul 21 2012 - 04:58:49 CDT