Action C (from the rest of the list) is "to get your applications from to stop querying the system tables so much", so that the index advisor will stop performing Symptom B, and the questions hence are aimed at getting to that.

* Index advices are also reported on test LPAR (7.1) which has no
business activity or development activity. So we can not blame these
advices on application. This is mentioned in my first post for this
thread.


* I have given multiple reasons while asking for setting to disable
"Index Advisor". One of them is indexes being advised high number of
times. Rob pointed out that there might be problem with application. I
told him that I will investigate it. If someone gives a reasonable
explanation, I am ready to verify it and act on it.

* The other reason is high number of "not so useful" indexes being
advised and making output of "Index Advisor" not useful. This is not
application issue, this is issue with "Index Advisor".



I was a little concerned that you wanted to stop a system operation


* I see "Index Advisor" as a add-on to optimizer and disabling "Index
Advisor" not impacting the functioning of optimizer. I am planning to
test the setting in test LPAR to make sure that it will not impact
other things. Other databases like DB2 LUW allow users to disable
certain features. FYI, I remember seeing post regarding QPFRADJ which
when enabled impacts sql workloads negatively and the post suggesting
disabling it for high sql workload systems. So, what I am asking is
not totally unprecedented.


* IBM has a PTF for disabling journaling on output of "Index Advisor"
(sysixadv) with explanation that output is advisory and journaling is
unnecessary. IBM stated that loss of output of "Index Advisor" does
not impact system functioning. Now extending the same logic, if output
of "Index Advisor" is unnecessary, why not disable it.


* If someone still thinks that output of "Index Advisor" is necessary,
let me know. Please go thru the thread before making suggestion.

Thanks....

Satya....

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].