Re: Enterprise mangler
Date: Sun, 3 May 2009 20:16:11 +0200
The real audience for OEM is probably not the same as the audience of this list. If the average site had DBA's with the skill of people like Jared, then there would probably not be a need for most of what OEM does. But most places does not seem to have even one person like Jared (or a lot of other people on this list), , so the product caters for a situation where one senior person tries to get more done with the help of fairly senior Oracle DBAs.
Apart from the performance overview section of OEM, I'm not sure I see much use for the real specialists. In fact I think that while these products may help junior resources, it may make the same resources less likely to learn enough about what's behind the curtain to survive without these products. Sooner or later we all end up in a shop where it is not configured or licensed and we have to make do anyway. It's similar to not know VI and end up in a shop where it is the only thing installed. Knowing how these products work is needed and using them can provide for enough laziness to make new talents never want to find out.
So while we debate if we find no or just little use in these products, there are managers everywhere talking to sales reps and becoming convinced that investing in these products is critical and will let the get by with just junior DBA resources.
For organizations with enough size to support OEM, it will make sense to have it unless the skill level of the resources bypasses it's use, but the same organization ought to push the DB specialists toward really understanding Oracle internals and make them understand that they are junior as long as they rely on those tools to be able to do their job.
Just my two cents on this. I really think we are debating the use of a product most people here are not the intended audience for.
On Sun, May 3, 2009 at 7:38 PM, Jared Still <jkstill_at_gmail.com> wrote:
> On Sat, May 2, 2009 at 9:27 PM, Keith Moore <kmoore_at_zephyrus.com> wrote:
>> I 'tried' to use OEM back when I think it was called OEM3. I tried a
>> couple of
>> different versions over the years but it was always more trouble than it
>> worth. The last version I used was for Oracle 8i.
> OEM is more work than it is worth for general database monitoring IMO.
> It does have it's uses. We have a few instances of Oracle Apps here,
> and OAM is useful for a number of admin tasks. OAM is Oracle App Mgr,
> and appears to be based on the same code base as OEM.
> Apps is a huge beast, and is quite difficult to remember where all the log
> files are, how to check on status of jobs, etc. Just checked a couple
> days ago, and just the apps install has 900k files.
> Scripts are still quite useful for a number of things with Apps, but OAM
> is quite necessary IMO.
> That said, I also much prefer scripts to OEM for database work.
> OEM just seems to create more work. We have one DBA, me,
> and I don't want to maintain another piece of software.
>> Recently I ate lunch with three Oracle sales people including their
>> person. He was shocked when I told him we didn't use OEM and it became
>> apparent that he thought I was just an old guy who was stuck in the past.
> Old guys tend to use what works, not what is the latest fad.
> I guess OEM is no longer the latest, that would be GC.
> GC is probably great for a shop that has enough people to deal
> with it, and the $$ to spend on the packs that make it useful.
> Also, some of us have developed interests outside of databases, and like to
> do something else after hours than learn the latest and greatest
> Personally, I prefer being alerted when something bad happens that requires
> immediate attention, rather than fine tuning the parameters in a monitoring
> tool to (finally) alert me only when needed, or explaining why yet again
> I didn't know about a serious database problem because the monitoring
> tool failed to notify me.
> Curiously, this topic seems to come up rather regularly.
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist