× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. October 2005

Re: SQL Optimizer Issue

Sounds to me as though it needs another index for its own statistics purposes. How about creating one on name only, and one on plan only, and presumably you have one on name/plan, and see what it does? Always worth a try, and quicker than analysing the whole thing.... 

cheers,

Clare

Clare Holtham
Director, Small Blue Ltd - Archiving for BPCS
Web: www.smallblue.co.uk
IBM Certified iSeries Systems Professional
Email: Clare.Holtham@xxxxxxxxxxxxxxx
----- Original Message ----- From: "Pete Hall" <pbhall@xxxxxxxxxxxxx> 
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Saturday, October 15, 2005 2:03 AM
Subject: Re: SQL Optimizer Issue
You may need to just let IBM work through it. I've been down this road with the optimizer a few times. It's got to be everyone's worst nightmare to work on. Last time for me, it took three service sessions in debug on our production box before the problem was actually diagnosed, and then another several weeks before we had a fix. However, when the fix was ready, it did work, and didn't cause any other problems, so we were happy. If you're going to use SQL in a heavy duty way, you occasionally will end up with this kind of stuff. We always install new releases and PTFs on a test box and I try to test all of the fancy queries there first, exactly because of that issue. It's important to test with the full database, because the optimizer takes table size into consideration when it determines its access plans. 

--

Pete Hall
pbhall@xxxxxxxxxxxxx
http://www.pbhall.us/



Mark Allen wrote:


Posted for a colleague:
What I was told: A SEQUEL select statement is run over a very large (50-60 Million records), select by name and a plan field. MOST of the time results are returned quickly but for "some" names the statement does not use the existing index and thus creates one, which causes about a 20-30 minute response time. IBM support to date has not been able to help and they ahve submitted a PMR to IBM but no response yet and it is becoming (is) an issue. 
Example:
Name=Smith   Plan=B, quick response
Name=Jones Plan=C, takes forever
I was told that they have also tried it as a straight interactive SQL and get the same issue. They have not been able to find any rhyme or reason as to why "some" names/plan combinations take so long. Anyone run across this or have any ideas? 

---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list 
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.