June 3, 2013 at 8:40 pm
Hello all
I have a big machine with 192gb, 16 cpus, and sql server 2012 RTM in it
I am trying to run this query
Select top 1
t.field1,
isnull( t.field2,'nothing'),
a.field3,
count(1) as total--,
FROM temptable2 t WITH(NOLOCK)
inner join temptable a WITH(NOLOCK) on t.field1 = a.field1
GROUP BY t.field1,a.field3,isnull( t.field2,'nothing')
NOthing fancy about it, temptable has 300k rows, temptable2 has 110k rows
the thing is that it never ends, none is blocking the process, the join is done using the clustered index
the fields are like this
field1 varchar(23, not null)
field2 datetime
field3 varchar(255)
I even recrete the tables in a different database with the same result, if I remove field 2 from the equation it will work just fine
Any ideas?
June 4, 2013 at 1:47 am
If field2 is a datetime, trying to return 'nothing' if it is null will be giving the database engine a headache in terms of mismatching data types.
Instead, maybe try returning '1900-01-01'.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
June 4, 2013 at 1:58 am
ricardo_chicas (6/3/2013)
Hello allI have a big machine with 192gb, 16 cpus, and sql server 2012 RTM in it
I am trying to run this query
Select top 1
t.field1,
isnull( t.field2,'nothing'),
a.field3,
count(1) as total--,
FROM temptable2 t WITH(NOLOCK)
inner join temptable a WITH(NOLOCK) on t.field1 = a.field1
GROUP BY t.field1,a.field3,isnull( t.field2,'nothing')
NOthing fancy about it, temptable has 300k rows, temptable2 has 110k rows
the thing is that it never ends, none is blocking the process, the join is done using the clustered index
the fields are like this
field1 varchar(23, not null)
field2 datetime
field3 varchar(255)
I even recrete the tables in a different database with the same result, if I remove field 2 from the equation it will work just fine
Any ideas?
It's a completely pointless query. TOP 1 by what? Car colour? Why do all the aggregation work then return a single random aggregated row? Nevertheless, folks will be curious. Can you post the estimated plan as a .sqlplan attachment?
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 4, 2013 at 5:35 am
Besides NOLOCK being a bad idea in general, as it can lead to bad thinks like missing data, duplicate data and more, the NOLOCKS on a temp table are pointless.
if you created the #temptable yourself, and noone else can use it(since it's session specific to this set of queries) , why would you need nolock? a bad habit you haven't broken yet?
some of my peers can point you to the link that has a great explanation on the hazards of nolock,
i think the actual query, instead of pseudo code might get you some better answers; the actual execution plan would show us what is going wrong int he query itself, if you can post that as an attached .sqlplan file.
Lowell
June 4, 2013 at 5:59 am
Here is a small piece of code to back up my assertion that this is a datatype problem:
if object_id('tempdb..#ex', 'U') is not null
drop table #ex
create table #ex
(
someDate datetime null
)
insert #ex
(someDate)
select '20130101'
select isnull(someDate, 'nothing')
from #ex
group by isnull(someDate, 'nothing')
Msg 241, Level 16, State 1, Line 13
Conversion failed when converting date and/or time from character string.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
June 4, 2013 at 6:05 am
All
Thanks but you are missing the point. The original query was something much bigger
I used a top 1 just to show you that there is something wrong with one of the tables
Even a select field2 from temptable
Never ends, it is a really small table,
The engine just can't resolve it, surely a bug or something
I am just asking what can it be?
June 4, 2013 at 6:10 am
ricardo_chicas (6/4/2013)
AllThanks but you are missing the point. The original query was something much bigger
I used a top 1 just to show you that there is something wrong with one of the tables
Even a select field2 from temptable
Never ends, it is a really small table,
The engine just can't resolve it, surely a bug or something
I am just asking what can it be?
Post the estimated plan for the original query, it's the first (and best) point of call for this type of problem. Without it, folks can only guess.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 4, 2013 at 6:11 am
if you have a specific performance problem, we really would want to see at least the estimated execution plan, and the actual query.
when you abstract it out, you end up cutting out critical details;
All of us are volunteers, but with a lot of experience and willingness to help.
help us help you!
provide better details, datatypes, etc.
post a .sqlplan for the query, that would show us a lot, for example we could see if out of date statistics are really affecting the query.
Lowell
June 4, 2013 at 6:54 am
All
I can't even generate the exec plan. It never ends, and none is using that table since it is a copy of the original
And none is blocking that spod either
This is only happenning to me with that specific query
June 4, 2013 at 6:56 am
ricardo_chicas (6/4/2013)
AllI can't even generate the exec plan. It never ends, and none is using that table since it is a copy of the original
And none is blocking that spod either
This is only happenning to me with that specific query
Not even an estimated plan?
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 4, 2013 at 6:56 am
show the real query, and you can generate an estimated execution plan without running the query at all. just highlight the query and click the button for estimated execution plan.
Lowell
June 4, 2013 at 7:09 am
I transformed the data so what I showed is yhe actual query
And the estimated plan never is calculated. It just keeps running for hours until I stop it
June 4, 2013 at 7:10 am
ChrisM@Work (6/4/2013)
ricardo_chicas (6/4/2013)
AllI can't even generate the exec plan. It never ends, and none is using that table since it is a copy of the original
And none is blocking that spod either
This is only happenning to me with that specific query
Not even an estimated plan?
Yes. Not even the estimate, and only happenning on that table.
June 4, 2013 at 7:21 am
wow that's unusual, can you check for corruption? that might explain everything:
dbcc checktable ('YourTableName') WITH ALL_ERRORMSGS
DBCC CHECKDB (<Database Name>) WITH NO_INFOMSGS, ALL_ERRORMSGS
Lowell
June 4, 2013 at 7:21 am
While this query is running in one SSMS tab, switch to another tab and run sp_who2. Is the spid running your stuck query blocked?
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply