Re: command line vs grid control

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.

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.

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!

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

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

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

Granted. But who would want to?

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

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

If nothing else because ALL software requires a learning curve. And if you think grid can't possibly cause a problem, then just let it install all Oracle bundled patches in your live system full of third party software, then watch the fireworks! Better yet, let it install those patches on a Peoplesoft or JDE setup, Oracle's own products. Spend some time looking at the install readmes for those two, Daniel!

> 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. They might not take the best corrective action in the context of their applications, but neither can grid guarantee that. But most can indeed easily identify the problem statement and trace it. Sorry, but that is the case here.

> 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. 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. Received on Tue Jul 10 2007 - 11:22:56 CDT