October 5, 2012 at 8:34 am
I have a view whose underlying query will run indefinitely. The query ran within 15 seconds yesterday and today it just won't complete. However, if I run a query like:
SELECT *
FROM viewname
I do get results, which seems odd to me. Shouldn't I be able to run the query itself and have it complete?
Granted, this is a big query, but again, yesterday and prior it completed within 15 seconds. Any ideas on how I might identify what the issue is/how to solve it? It's been a while since I've had to tune this kind of thing, so I'm open to any suggestions.
Thanks,
Mike
Mike Scalise, PMP
https://www.michaelscalise.com
October 5, 2012 at 9:46 am
You're using a couple of vague terms, so let me see if I can probe for more details. You start by saying that when you query it, it runs indefinitely, but if you "select * from yourview" you'll get results.
I'm assuming the following:
1. When you say that you're querying the view, you mean that you're supplying a clause to filter the data, i.e., WHERE id = @somevalue.
2. That when this happens, SSMS doesn't display anything for an "indefinite" period of time in the results pane, and the query timer is ticking happily away in the bottom corner.
3. That when you query "select * from yourview" that the results pane populates instantly.
4. That when #3 occurs, despite the fact that you have results, the timer is still ticking happily away in the bottom corner.
Let me know if I've got that right.
If so, here's something to keep in mind, especially considering that you mention that this is a rather large view. When you query "select * from yourview", SQL doesn't have to do much other than just dump the contents of the view into the results pane. That's why you'll always see results pretty quickly, even though SQL Server is still dumping the contents out. However, if you specify a filter, SQL does have to do a bit more work, as (from what you've mentioned) it's not able to perform the search for the data in a more expedient fashion than going through row-by-agonizing-row of the underlying tables to find data that qualifies to be in the result set.
In either case, it sounds like a) your view could stand to be refactored so that it is more efficient or b) your view could stand to be indexed. It's hard to say without knowing more about the view, the table structures that are being accessed, and/or the queries that are being asked to run against the view.
Edit: You also mentioned that this was able to run yesterday without issue. I know this sounds like a no-brainer, but have any changes taken place to this environment since the last time it was able to run successfully? Anything at all..
October 5, 2012 at 12:23 pm
Are the two uses of the query identical? "Select * from MyView" vs just running the exact query in the view without modification?
If so, have you checked for blocking issues when you run the view and it takes forever?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 5, 2012 at 12:26 pm
A few things to clarify...
1) It's the query that makes up the view that never completes. It churns along in SSMS. No records are returned while it's running, the timer is still running, etc.
2) When I run a query like "SELECT * FROM myview" I get results in about 20 seconds (different from when I run the actual query that makes up the view -- see point #1) and the query completes successfully....it's not that it continues running. GSquared -- I'm not using any WHERE criteria. In effect, it should just be running the query that's in the view.
3) There weren't any significant changes from yesterday to today. I updated statistics on all of the tables used in the view, which didn't resolve the problem. It's not my query/view, but I think the crux of the issue is that it was written inefficiently. I've worked with my coworker to rewrite the query and join indexed fields (which wasn't the case initially).
I think I'm OK for now, but I'm still a little puzzled as to why the view returned results yesterday (albeit after 15 seconds) and why today it required me to rewrite the whole thing. Moreover, I don't know why "SELECT * FROM myview" worked before I refactored the query that made up the view.
Mike
Mike Scalise, PMP
https://www.michaelscalise.com
October 9, 2012 at 11:26 am
I'd have to see both execution plans, at the very least, to help more on this. Can you post those?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 9, 2012 at 1:58 pm
Gsquared,
Thanks for the reply. After rewriting the query, the process now runs in one second (down from 20 seconds / not completing at all), so I'm not sure it's worth revisiting it the old way. I appreciate the response.
Mike
Mike Scalise, PMP
https://www.michaelscalise.com
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply