Re: command line vs grid control

From: DA Morgan <damorgan_at_psoug.org>
Date: Tue, 10 Jul 2007 10:54:44 -0700
Message-ID: <1184090083.739831@bubbleator.drizzle.com>

Noons wrote:
> On Jul 11, 1:50 am, DA Morgan <damor..._at_psoug.org> wrote:
>

>> Maybe you don't do what I do ... teach. But I can assure you that
>> the difference between "can learn" and "do learn" is a chasm of
>> unimaginable size for some.

>
> yeah sure, I hear you. It's a problem.
>

>> But you are missing some of the more important aspects of OEM grid.
>>
>> You can't write a shell script to check metalink for patches.

>
> Er..... Daniel, the patches that grid gets have nothing
> to do with solving problems or bugs: they are simply
> scripted bundles from Metalink to channel into grid.
> There is no guarantee whatsoever if you use the
> auto-patching you are not installing something that
> is not buggy or will stuff up some other aspect of
> the db.

Correct. That is for testers and test environments to do. But it does mean you can apply that patch to 342 servers in a perfectly repeatable fashion without an error.

> This is something that I've been telling Oracle for
> ages now and they just refuse to listen: their patch
> bundles are well known for creating problems and
> can't be installed without a proper application test
> process. Which is *expensive* to carry out with
> the regularity that Oracle releases these bundles.

I don't patch anything without testing: Not just Oracle. Last year the automatic download of a patch for my antivirus destroyed a machine until I was able to back it off.

> Anyone who installs an Oracle patch bundle
> through gird without proper testing, in blind trust that
> it won't create a problem, quite frankly needs to be
> locked out of the data centre!

No one will argue with that I would expect. But I wouldn't suggest OEM Grid for one-off patching. I would suggest it for an enterprise with tens or hundreds of servers.

>> You can't write a shell script that enforces a uniform set of alerts
>> and warnings on all databases in an enterprise.

>
> I don't have to, if I'm using already an alerting system.
> Which almost everyone is nowadays.

Again back to the original thread ... my argument was against one-off shell scripts for that purpose.

>> You can't write a shell script that will access ASH or AWR without
>> buying the licenses.

>
> Why sould I? Those two are not the end of tuning,
> Daniel. For the vast majority of performance and
> capacity problems, Statspack and explain plan does
> the job perfectly.

And for the vast majority of DBAs they are no more capable of actually understanding that statspack than my cat. You sir are not the "average" DBA.

>> You can't write a shell script to duplicate ADDM.

>
> Granted. But who would want to?

That was the original thread before you and I went off elsewhere ... shell scripts.

>> ... the full list is rather extensive but I hope these examples
>> demonstrate my point. And with 11g new advisors will increase the
>> delta even further.

>
> Sure, but Oracle can bleat as much as they want with the
> advisors, bottom line is: if folks don't need them, why should
> they pay for them? Because it makes them "better" dbas?

I agree and likely Oracle would agree. If you don't need the provisioning pack or the change management pack why would you buy it? Nowhere is it written that to use the Grid Control you must buy packs you don't want or need.

>> But please also acknowledge that each and every one of those errors
>> had an attendant price is time and brass.

>
> Of course. Like ANY human activity in ANY company,
> the learning process has a cost. What is new about that?

Nothing except you seemed to be assuming that your learning curve had no associated cost.

> Any manager knows it and has so for ages. The notion
> that some piece of software is somehow going to
> avoid that cost is bogus: it never has, it never will.

Avoid no. But it is part of the calculation. You are going to spend $X ... what's going to give you the most peace-of-mind? Some balding guy wearing suspenders with a bad attitude doing stuff you don't understand or a product, with support, from the third largest software company on the planet?

You may argue that the manager I am referring to, above, is a dullard and that may be so but originally you referred to this as a product only purchased by those being bullied and my point here is that the purchase is reasonable and not the result of FUD.

>> For the majority that is an improvement. What do you think is the
>> percentage of all DBAs in all organizations that right this second,
>> if an incident occurred, could run a StatsPack or a 10046 trace and
>> understand the result?

>
> Er... most I know can indeed do that.

Then you live in an unusual environment. And I will say that from my experience there are more competent DBAs in Europe, percentage-wise, than in most other places. But I have taught in multiple countries and multiple states in the US and what you describe is not the norm.

>> There is nothing that says you can't use the OEM Grid to handle most
>> things and extend it with your own skills and knowledge. This is not
>> a zero sum game.

>
> Agreed. What worries me is that grid is not
> helping anyone understand what goes on under
> the covers.

Separate issue and the same issue I have with students that want to use TOAD: I force everyone to SQL*Plus. Welcome to the dumbing down of technology workers. But that is a separate argument and you are preaching to the choir. I would like to see nothing less than Oracle stopping its certification programs and handing them over to a group of DBAs, like a Medical Board, to create and enforce standards.

> That is not learning, that is rote
> learning. And it can only end in tears, because
> running a db is not a rote job, it requires brains.

And you assume most have and apply them? <g>

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

Received on Tue Jul 10 2007 - 12:54:44 CDT