Re: command line vs grid control

ivl5_at_hotmail.com wrote:

> Perhaps we should define "monitoring" more precisely but it's hardly
> an ability to select from dba_hist views. Anyway any decent custom
> monitoring scripts save point-in-time measurements as historical data.
> Or you can fall back to Staspack. It doesn't equal AWR or Diagnostics
> Pack but certainly covers "monitoring" bit.

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. 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.

>> More developers were used to build the 10g Grid Control than
>> to build the 10g database. How far do you think you are going
>> to get duplicating that with a shell script unless you violate
>> your employer's license agreement.

The monitoring portion alone exceeds anything you are capable of writing.

And the point of this exercise would be what? To save your employer money or to avoid learning something new?

> Is it still "You can not monitor a database using shell/perl scripts
> any longer"?

 From my standpoint that is the case. Just as I would say that anyone using shell/perl scripts to perform a backup should be trained or terminated.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org