Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: command line vs grid control
On Jul 5, 11:53 am, i..._at_hotmail.com wrote:
> On Jul 5, 12:08 am, DA Morgan <damor..._at_psoug.org> 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
> > damor..._at_x.washington.edu (replace x with u to respond)
> > Puget Sound Oracle Users Groupwww.psoug.org
>
> 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 DBAReceived on Thu Jul 05 2007 - 07:57:39 CDT