RE: I just submitted OEM feedback

Jared/Patrice,

We found that for its price, OEM was pretty good. I do agree that Perl/Ksh/SQL*Plus scripts is still more solid than OEM and its agents, but OEM 2.2 has come a long way since OEM 1.0. While there are many things that I do NOT like about OEM (i.e. stuck 'deregistrations', cumbersome repository, lack of Oracle Support's understanding, etc.) what I do like about OEM are *some* of it's add-ons. In particular: Management Pack for Oracle Apps, TopSessions, Change Manager, Capacity Manager. I tend to ignore any advice that these generate, but draw my own conclusions. Having to host the repository is a necessary evil :)

Really good stuff: You can customize the counters (from v$sesstat) to check in TopSessions, sorting based on different parameters is useful, Baseline comparison in Change Manager are a cinch, Top resource/waiting Reports in Oracle Apps is useful when we meet the users about performance problems, On-screen automatic/manual refresh allows you to spot changes/waits quickly, etc...

And the nicer part is that all the latest versions are supported when you take up the Repository/Agent that comes along with that version. We were really stuck with long lead times for Agents with HP-OV/OpC and BMC Patrol. (Don't know about Quest lead times).

We had BMC Patrol installed (both here and in a previous gig), but at least in the 3.x version the agent went haywire and grabbed 100% of a CPU. Replacing this by OEM (mainly to satisfy the PHBs) solved the problem since the difference (between OEM and BMC agentwise) was that the OEM Agent went out to capture stats when prompted by the Repository which in turn was based on the Events and their scheduling, while the BMC Agent just kept collecting stats. We were not able to figure out a way of toning this down. The issue was the same with HP's OpC (Operations Centre)/OpenView.

What I am trying to say is this: I am not an OEM fan, but parts of OEM have impressed even an old command line geezer like myself. Don't throw away your scripts, though - they are your suspenders that back up your belt!

FWIW!
John Kanagaraj
Oracle Applications DBA
DBSoft Inc
(W): 408-970-7002

Listen to great commercial-free christian music 24x7 at www.klove.com

• The opinions and statements above are entirely my own and not those of my employer or clients **

> -----Original Message-----
> From: Jared Still [mailto:jkstill_at_cybcon.com]
> Sent: Friday, November 09, 2001 12:55 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: I just submitted OEM feedback
>
>
>
> Patrice,
>
> You're reinforcing my already low opinion of OEM.
>
> At a previous job we had one very competent DBA that
> spent quite a bit of time on OEM, and it would never
> work properly.
>
> I'm still sold on homebrew monitoring, in Perl, ksh, or
> whatever you're comfortable with.
>
> One tool that I thought was impressive was BMC Patrol. Anything
> you could think of, it already did. Quite expensive and difficult
> to install I understand. Never got the opportunity to use it.
>
> Jared
>
> On Friday 09 November 2001 07:10, Boivin, Patrice J wrote:
> > FYI,
> >
> > I just submitted feedback to Oracle re. their OEM 2.2. product.
> >
> > So far I have had to rebuild the repository three times.
> With fifteen
> > servers, this is a major hassle. We have Oracle on NT, on
> Tru64 UNIX, and
> > a mix of versions: 7.3.4.4 (on Tru64 in the process of
> being upgraded) and
> > 8.1.7.2.1 (on NT). I had at least thirty events
> configured, and planned to
> > try using jobs. Not going to happen for a while yet...
> >
> > Oracle Support and I have been dancing around for weeks now, they
> > absolutely refuse to tell me how to clean up the repository
> without having
> > to rebuild it. Instead they just give me the same
> procedure to clean up
> > the agent directories, etc. but the problem is not at the
> remote hosts, it
> > is in the repository.
> >
> > The problem I ran into is twofold.
> >
> > 1) The OEM repository reported a referential integrity error, some
> > records in a child table do not have corresponding entries
> in their parent
> > table. This is a repository corruption problem, has
> nothing to do with the
> > agents on remote hosts.
> > 2) I have a number of events stuck in "de-registration
> pending" mode,
> > which prevents me from de-registering the events and
> removing the nodes
> > from the Navigation pane.
> >
> > Yes, I have shut down the agents, removed all the files in
> the /agent
> > directories, shut down the console, stopped and restarted
> the management
> > server, but the events are still there.
> >
> > I asked them to build into the next version of the OEM a
> utility that can
> > scan the repository, look for bad entries, and remove them.
> >
> > There is no need to force people to spend hours rebuilding
> the repository
> > and re-configuring everything just because of a few events
> being stuck in
> > de-registration pending mode.
> >
> > If anyone else has encountered this problem and know a way
> to clean up the
> > repository without having to rebuild it, please let me know, I would
> > appreciate it.
> >
> >
> > Other problems so far with the OEM:
> >
> > - The Oracle Expert this morning declared it cannot log into the
> > Oracle Management Server, even though I can start up a
> console. The error
> > I get is: org.omg.CORBA.NO_IMPLEMENT[completed=MAYBE]. I
> haven't looked in
> > MetaLink yet, will do that. One more problem to look up
> re. the OEM. - The
> > Forms listener event does not communicate properly with the
> > Forms Server.
> > - The Change Manager does not see tablespaces, tables,
> indexes from
> > one of my NT servers (8.1.7.2.1). Oracle Support could not
> reproduce the
> > problem. Next thing for me to try: rebuild the three
> databases on that
> > machine, to see if that will fix the problem. Something I
> would rather not
> > do.
> > - The agent on my Tru64 UNIX server cannot talk to the
> databases on
> > that machine, Oracle Support told me that there is probably
> a problem with
> > the agent and they suggested I upgrade. We are upgrading
> that server soon,
> > so I only used the node and TNS Listener events for the
> groups pane. The
> > events for db up/down against this machine are stuck in
> "de-registration
> > pending" mode.
> >
> >
> > Finally, a funny anecdote: yesterday I ran the Oracle
> Expert against one
> > of the three databases on that NT server I mentioned above.
> The Oracle
> > Expert as part of its recommendations told me to take
> non-system objects
> > out of the SYSTEM tablespace. All these objects were
> created when the
> > databases were created, using Oracle's own GUI tools. I
> moved them out of
> > there this morning using the script generated by the Oracle
> Expert, which
> > was nice.
> >
> > If you find any problems with the OEM, I encourage you to
> submit them with
> > Oracle.
> >
> > I am starting to think now that I should go into the
> repository manually
> > and clean up the tables with invalid records.
> >
> > Regards,
> > Patrice Boivin
> > Systems Analyst (Oracle Certified DBA)
> >
> > Systems Admin & Operations | Admin. et Exploit. des systèmes
> > Technology Services | Services technologiques
> > Informatics Branch | Direction de l'informatique
> > Maritimes Region, DFO | Région des Maritimes, MPO
> >
> > E-Mail: boivinp_at_mar.dfo-mpo.gc.ca <mailto:boivinp_at_mar.dfo-mpo.gc.ca>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Jared Still
> INET: jkstill_at_cybcon.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: John Kanagaraj
  INET: john.kanagaraj_at_hds.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).