Re: The penny hasn't dropped yet...

From: Noons <>
Date: Wed, 3 Mar 2010 13:41:28 -0800 (PST)
Message-ID: <>

On Mar 4, 4:58 am, joel garry <> wrote:

> I strongly agree with the sentiments in this thread.  But, here I have
> to point out how common it is, to the point of being the mode, that
> people won't supply the necessary information up front (right
> Sybrand? :-) .  From that viewpoint, it merely becomes an issue of

Not really. If you look at the SR entry process, the basics of information are all there: type of licence, release number and patch level, OS/hardware. And the ability to load trace files and other supporting evidence. As well as clear instructions asking if possible to provide a simplified reproducible case. That's a heap more than the usual Usenet "help" entry and has served well before, why would it not be effective now?

> Where they cross the line is grabbing all information ever possibly
> needed.

And not needed. That is the problem.

> Think of this:  if you have everyone upload all their trace

> files, you can mine that to create a decision support tool that can
> automate much trace file analysis.  I'm sure you can name popular and
> not-so-popular people who have done that.  So why not generalize
> that?

I disagree. Support is not reducible to a mechanized, half-arsed pseudo-AI tool cobbled together from past information. Each release of Oracle has its own problems with new features - as well as a fair share of others that are common with previous releases - most unfortunately, but it's a fact! Any attempt to automate analysis of SRs in such a climate is doomed to even more overhead, while still needing specialist work. The notion that every SR can be analyzed upfront by such a tool is doomed, like so many other prior attempts at the same: nothing new here, it's not even a new idea. Tried before, never worked, never will: software is not some immutable universe definable by a static rule set.

> Well, what if that ORA-600 is hidden under several levels of
> technology stack?  Way before you get there, you may indeed need to
> follow the problem including over the network.  

Not at all. Ora-600 is an internal error in Oracle code. Period. What causes it may be a simple command in sqlplus, or a very complex chain of events starting with the fluttering of a butterfly's wings in China. It still is an internal error in Oracle kernel code and needs to be treated as such. Forget the rest: it's got nothing to do with geography or entomology!

> I would think most
> support calls are of the form "my program isn't working,"

Sure. And how/where is OCM going to help there?

> I'm sure
> ora-600's are pretty scarce in the overall scheme of Oracle support.

I wish... I've hit 13 of them in the last year alone...

> there quick.  But if I'm getting a java virtual error, I'm just as
> newbie as "my program isn't working" and I think an RDA is probably
> appropriate.  OCM is just a proactive version of that, isn't it?  The
> Network Is The Computer.  And OCM puts all your Oracle usernames into
> a world readable file.  Sigh.

I don't have a problem with a tool that collects basic information *about Oracle configuration*. Like hell I'm gonna let lose a tool in my servers that collects information about the network itself, its setup and most secure information. Read on about the arp command, present in any pc although few know what it can do. No way it's gonna happen. Period. Received on Wed Mar 03 2010 - 15:41:28 CST

Original text of this message