Good question... none

Anyway, if you missed the original post, I have someone who works with me
who is asking to make the change. He is running some new monitoring tool (
some free scripts) and it points at this 1 query (and several others) as
needing an index.

--

"Paul Brewer" <paul (AT) paul (DOT) brewers.org.uk> wrote

You gotta love those tuning tools that are nothing more than glorified
expert systems. The biggest problem with these tuning tools is that you
wouldn't pay any more for it if it didn't make any suggestions.
Therefore, it always makes a suggestion! I once had a tuning tool which
told me I had problem A and to perform action A to solve it. So I did. I
ran the tuning tool again and it told me I had problem B and to perform
action B to solve it. So I did. I ran the tuning tool again and it told
me that I had problem A and to perform action A to solve it. Right then
and there I knew that tuning tools are structured to always make a
suggestion, no matter what.

Personally, I only use two tuning tools:
1) SQL*Plus
2) Oracle Trace Facility

Everything else just clouds the issue.

Cheers,
Brian

Burton Peltier wrote:
--
================================================== =================

Brian Peasland
oracle_dba (AT) remove_spam (DOT) peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
the three"

Daniel Morgan wrote:


Right now I'm in a comparable situation to this dba. I'm the only guy who actually
sees performance data because everyone else is absolutely clueless. (Dunno whether
the cluelessnes is comparable there, but here it's a fact. Just db users, no developers
right now.)
So, my boss hears the complains but is unable to do anything about it and
thinks it's the HW anyways, our users grumble quietly but have no idea if
it has to be that way and the last thing I'd need is for some guy to go whining
about whether he should follow the advice of his dba.
Dba suggested it, the user should make clear that the dba assumes responsibility for
that change and that's it.

As for that particular change, I had this too. We installed some software together
with a db schema and it ran really slow. So, while a bigger server was being
discussed I had a look at the schema and it turned out that one rather big table
had no indexes at all. Looked at the problematic query, asked whether anyone had
a problem with me tryin out a coupla indexes and voila - five minutes later performance
was all right.

Lots of Greetings!
Volker
--
While it is a known fact that programmers
never make mistakes, it is still a good idea
to humor the users by checking for errors at
critical points in your program.
-Robert D. Schneider, "Optimizing INFORMIX
Applications"

Volker Hetzer wrote:

Your situation is not comparable to the OP's. You had user complaints the OP had nothing
but the recommendation of
some scripts of unkown (at least to us here) value. In your case you had something specific
to fix and a measure to
determine success or failure. All the OP can do is satisfy a tool or create real problems.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Is the table static? What types of queries are performed? Depending on
it's use, you could place it in the cache. An index on the table may or may
not help out, depending on the size/use/environment (other activity). Find
out if numerous inserts will be taking place...

KL

"Burton Peltier" <burttemp1REMOVE_THIS (AT) bellsouth (DOT) net> wrote

--
"Volker Hetzer" <volker.hetzer (AT) ieee (DOT) org> wrote


As I stated above, this is just something we will have to test in our test
environment, which is available...

Actually, after posting my original post, I can now see this as 2 issues:

1) Another DBA suggesting changing production without testing - I don't do
that for anything ... almost

2) Priorities and where do you draw the line in benefits for time spent on
this vs. time spent on other things .