Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: command line vs grid control

Re: command line vs grid control

From: sybrandb <>
Date: Thu, 05 Jul 2007 05:57:39 -0700
Message-ID: <>

On Jul 5, 11:53 am, wrote:
> On Jul 5, 12:08 am, DA Morgan <> wrote:
> > Waking up all night long and sniffing the air might be considered by
> > some less expensive than buying a smoke alarm.
> > I understand your point but to me it is the point of a dinosaur.
> Well, your advice is to throw out all the scripts and get on to grid
> control.
> My advice is, if you have money (and the size of your environment
> warrants this), get grid control; otherwise use database control plus
> scripts. If your scripts cover your requirements, nothing's wrong with
> keeping them. I think my position is more balanced and practical so
> I'll stick to it.
> Also you may want to re-read hpuxrac's reply; it's a good one.
> > Your scripts are not version aware and will require rewrites with every
> > upgrade. Your scripts are far less capable than the grid. Your scripts
> > are incapable of real-time monitoring. Your scripts have no metadata
> > repository with which to compare previous results. And if you are like
> > 99% of all DBAs I know you will not submit your scripts to testing in
> > an independent test environment to make sure they are sound. You will
> > just throw them over the cubicle wall onto the production server and
> > assume they work because you wrote them.
> That's a lot of assumptions :) Accidentally all are wrong for 99% of
> sites I worked on.
> > --
> > Daniel A. Morgan
> > University of Washington
> > (replace x with u to respond)
> > Puget Sound Oracle Users
> Regards,
> Igor

Sooner or later Oracle is going to implement monitoring functionality in their controls only.
We have seen this with vendors over and over again. The obvious reason for this is they want you to use their product. I haven't so far seen any 'tool', deserving that name, implementing more than 10 percent of the functionality with OEM. Obviously you want to remain in the dark, and because of this your customers and developers will also remain in the dark. You are actually doing a disservice to them.
Qualifying this as a 'balanced' position sounds very strange, and suggest you are using the proverbial 'garage' approach to administration. To maintain your 'balanced' position you would need to instruct your customers NOT to upgrade. Because if they upgrade you will be probably out of business.
As many customers don't have any clue about Oracle's functionality and what it can do for them, this probably isn't going to be a difficult task. But what if they *have* to upgrade, because with the new hardware they get a new version of the OS, for which your historical versions of Oracle aren't certified at all?

Sybrand Bakker
Senior Oracle DBA
Received on Thu Jul 05 2007 - 07:57:39 CDT

Original text of this message