Re: Basic Scripts for Database Administration

From: joel garry <>
Date: Fri, 26 Jun 2009 09:56:05 -0700 (PDT)
Message-ID: <>

On Jun 26, 6:30 am, John Hurley <> wrote:
> On Jun 25, 7:48 pm, exazonk <> wrote:
> snip
> > But some things you need to do no matter where you are? eg, disk space
> > monitoring, tablespace monitoring, load monitoring? So you write all
> > your scripts fresh every time?
> Oracle has put a lot of work into the 10g and 11g "rewritten" OEM
> functionality.
> Why don't you spend some time getting familiar with what's available
> canned from oracle before deciding that you want to use custom scripts
> instead?
> Many place are now doing a combo approach ... using some of the built
> in alerting and monitoring the OEM provides and supplementing that
> where it makes sense to them.

That's basically my view. With the limited experience I've had with EM, I do think it isn't really ready for prime time (as of, but it is useful enough.

I think every DBA should go through the script-writing routine in production environments at least 3 times. Then you start to appreciate what is really going on, and can differentiate when other tools are helpful or not. Note that I used to be strongly commandline  biased, but now I see that some of the pictures really are helpful visualizations, and some have even more value in quickly getting a point across to management.

The problems with EM in my view are:

It's a GUI, with all the abstraction and MS-think that implies, as with any GUI. The corollary is over-dependence without understanding.

It's fragile. It's way too easy to just make an apparently insignificant change that fries the whole thing. This includes using its own interface to change an alert.

It's not transactional. For example, it can get out of sync with what is actually happening, leaving you staring at an icon while nothing, or too much, is happening.

It's internally complex. Configuration files are all over the place, as are log files. This can lead to lots of effort so see what is going on, and patching can cause parallel universes where you don't know if Vulcan has really been destroyed, or whatever. When one thing doesn't work, the root cause may be somewhere else. If it breaks something important like job control, the problems can spiral. For RMAN, I'm maintaining dual OEM and scripted routines. Fortunately, I had the scripts from before when OEM broke.

Support is iffy. They will often give various analogues of "reboot the pc," such as "stop the service, reconfigure it, and start it again," which can lead you down the garden path to configuration hell. When the root cause of a problem is elsewhere from your original problem, you may get into subsidiary SR hell.

The organization can make it a bit difficult to find things if it isn't your entire job to deal with EM.

It has bugs.  Some are from incorrect assumptions about cross-platform
differences.  Some appear to be from crappy open-source (lack of)
engineering.  Some may be fundamental design issues.

That said, it's still pretty useful, and has the advantage of being in the Oracle kool-aide with a lot of people drinking it. One additional use is being able to see what SQL it creates to do something, that has saved me from bothering with the manuals a number of times. It's nice having a list of what backups have been done, and easily drill down into the details. It's nice having a performance screen, if it turns into a big green or blue bar, I know to look at things. It's nice being able to go directly to a plan from a running sql, make a screen print, and tack it up on the cubicle wall. I like the advisor screens (9i too, when I had it). I would have done the space screens differently, and don't trust alerts much, but they are there. In general, a few minutes poking around tells me everything I need to know, and theoretically I could use alerts for most of that (I do use some - "agent unreachable" alerts are useful for db down). I think I even saw an agenda for a Jonathan Lewis class that mentioned showing some useful things in EM.


-- is bogus.
Received on Fri Jun 26 2009 - 11:56:05 CDT

Original text of this message