I have a weird problem in Sql Server 2005 that I need some help on.
Below
you'll find two queries. Both queries are exactly the same; they query
the
same database, query for the same info, same sql statement, same where
clause... The first query (with the longer date range) runs perfectly
against my databases. The
second query is as I've said exactly the same, the only difference is
that
the date range is much smaller and is infact included in the first
query. The
problem with this query is that it seems to churn away but do nothing.
It
seems to execute my query but it never finishes. Last time I cancelled
it after +2 hours. Does anybody why I see this behavior? Is there
something that I can do about it? Since it never seems to finish, I'm
not able to generate a execute plan for it to see what the problem is.
Thanks in advance :P
THE SANE QUERY:
------
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT " T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABL E" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 asc
------
THE BAD QUERY:
------
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT " T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABL E" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 asc
P.S.
I have already reindexed the tables, cleared the cached query plans and
updated the statistics with no change in the outcome.
|||swaroop.atre@.gmail.com wrote:
> I have a weird problem in Sql Server 2005 that I need some help on.
> Below
> you'll find two queries. Both queries are exactly the same; they query
> the
> same database, query for the same info, same sql statement, same where
> clause... The first query (with the longer date range) runs perfectly
> against my databases. The
> second query is as I've said exactly the same, the only difference is
> that
> the date range is much smaller and is infact included in the first
> query. The
> problem with this query is that it seems to churn away but do nothing.
> It
> seems to execute my query but it never finishes. Last time I cancelled
> it after +2 hours. Does anybody why I see this behavior? Is there
> something that I can do about it? Since it never seems to finish, I'm
> not able to generate a execute plan for it to see what the problem is.
> Thanks in advance :P
> THE SANE QUERY:
> ------
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT " T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABL E" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
> T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
> 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
> ------
> THE BAD QUERY:
> ------
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT " T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABL E" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
> T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
> 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
>
Compare the ESTIMATED execution plans for the two queries - what's the
difference between them? Where is the time being spent?
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Tracy,
They both have the exact same execution plan (which they should
considering its just a change in the value for a conditional
expression). The expected usage is largely with the lookup for the
transaction data table which uses a clustered index.
Swaroop
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Compare the ESTIMATED execution plans for the two queries - what's the
> difference between them? Where is the time being spent?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
|||UPDATE:
The execution plans changed once I updated the statistics on the dbases
again.
swaroop.atre@.gmail.com wrote:[vbcol=seagreen]
> Tracy,
> They both have the exact same execution plan (which they should
> considering its just a change in the value for a conditional
> expression). The expected usage is largely with the lookup for the
> transaction data table which uses a clustered index.
> Swaroop
>
> Tracy McKibben wrote:
|||swaroop.atre@.gmail.com wrote:
> UPDATE:
> The execution plans changed once I updated the statistics on the dbases
> again.
>
Did the performance change as well?
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Adding in the index on one of the tables altered the performance.
However on two other queries with the same problem they have no effect.
All tables being used are indexed.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Did the performance change as well?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
|||swaroop.atre@.gmail.com wrote:
> Adding in the index on one of the tables altered the performance.
> However on two other queries with the same problem they have no effect.
> All tables being used are indexed.
Review the execution plans. The queries may "appear" to have the same
problem, i.e. slow performance, but their indexing needs may be totally
different.
A good index will allow the WHERE clause to filter out unwanted rows as
quickly as possible, and may even provide all of the data necessary to
prevent a second trip to the table.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||The query is actually making a single trip to each table that it needs
information from.
The query in a jist gathers information from six tables the biggest one
being 150M records or so with a clustered unique index while the other
5 have non clustered non unique indexes. As long as the query looks for
data for the month of dec it never returns (the date constraint is
contained in the big table) however if i expand the range to include
dec but not just dec it comes back with the data i seek. The execution
plans for the two are very different and I think that might be because
the new one uses the indexes while the old one in the cache dosnt.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Review the execution plans. The queries may "appear" to have the same
> problem, i.e. slow performance, but their indexing needs may be totally
> different.
> A good index will allow the WHERE clause to filter out unwanted rows as
> quickly as possible, and may even provide all of the data necessary to
> prevent a second trip to the table.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
Showing posts with label weird. Show all posts
Showing posts with label weird. Show all posts
Monday, March 26, 2012
Query Hangs when Parameters are scaled down.
Query Hangs when Parameters are scaled down.
I have a weird problem in Sql Server 2005 that I need some help on.
Below
you'll find two queries. Both queries are exactly the same; they query
the
same database, query for the same info, same sql statement, same where
clause... The first query (with the longer date range) runs perfectly
against my databases. The
second query is as I've said exactly the same, the only difference is
that
the date range is much smaller and is infact included in the first
query. The
problem with this query is that it seems to churn away but do nothing.
It
seems to execute my query but it never finishes. Last time I cancelled
it after +2 hours. Does anybody why I see this behavior? Is there
something that I can do about it? Since it never seems to finish, I'm
not able to generate a execute plan for it to see what the problem is.
Thanks in advance :P
THE SANE QUERY:
----
----
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 asc
----
---
THE BAD QUERY:
----
---
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 ascP.S.
I have already reindexed the tables, cleared the cached query plans and
updated the statistics with no change in the outcome.|||swaroop.atre@.gmail.com wrote:
> I have a weird problem in Sql Server 2005 that I need some help on.
> Below
> you'll find two queries. Both queries are exactly the same; they query
> the
> same database, query for the same info, same sql statement, same where
> clause... The first query (with the longer date range) runs perfectly
> against my databases. The
> second query is as I've said exactly the same, the only difference is
> that
> the date range is much smaller and is infact included in the first
> query. The
> problem with this query is that it seems to churn away but do nothing.
> It
> seems to execute my query but it never finishes. Last time I cancelled
> it after +2 hours. Does anybody why I see this behavior? Is there
> something that I can do about it? Since it never seems to finish, I'm
> not able to generate a execute plan for it to see what the problem is.
> Thanks in advance :P
> THE SANE QUERY:
> ----
----
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
> T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
> 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
> ----
---
> THE BAD QUERY:
> ----
---
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
> T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
> 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
>
Compare the ESTIMATED execution plans for the two queries - what's the
difference between them? Where is the time being spent?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy,
They both have the exact same execution plan (which they should
considering its just a change in the value for a conditional
expression). The expected usage is largely with the lookup for the
transaction data table which uses a clustered index.
Swaroop
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Compare the ESTIMATED execution plans for the two queries - what's the
> difference between them? Where is the time being spent?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||UPDATE:
The execution plans changed once I updated the statistics on the dbases
again.
swaroop.atre@.gmail.com wrote:[vbcol=seagreen]
> Tracy,
> They both have the exact same execution plan (which they should
> considering its just a change in the value for a conditional
> expression). The expected usage is largely with the lookup for the
> transaction data table which uses a clustered index.
> Swaroop
>
> Tracy McKibben wrote:|||swaroop.atre@.gmail.com wrote:
> UPDATE:
> The execution plans changed once I updated the statistics on the dbases
> again.
>
Did the performance change as well?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Adding in the index on one of the tables altered the performance.
However on two other queries with the same problem they have no effect.
All tables being used are indexed.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Did the performance change as well?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||swaroop.atre@.gmail.com wrote:
> Adding in the index on one of the tables altered the performance.
> However on two other queries with the same problem they have no effect.
> All tables being used are indexed.
Review the execution plans. The queries may "appear" to have the same
problem, i.e. slow performance, but their indexing needs may be totally
different.
A good index will allow the WHERE clause to filter out unwanted rows as
quickly as possible, and may even provide all of the data necessary to
prevent a second trip to the table.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||The query is actually making a single trip to each table that it needs
information from.
The query in a jist gathers information from six tables the biggest one
being 150M records or so with a clustered unique index while the other
5 have non clustered non unique indexes. As long as the query looks for
data for the month of dec it never returns (the date constraint is
contained in the big table) however if i expand the range to include
dec but not just dec it comes back with the data i seek. The execution
plans for the two are very different and I think that might be because
the new one uses the indexes while the old one in the cache dosnt.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Review the execution plans. The queries may "appear" to have the same
> problem, i.e. slow performance, but their indexing needs may be totally
> different.
> A good index will allow the WHERE clause to filter out unwanted rows as
> quickly as possible, and may even provide all of the data necessary to
> prevent a second trip to the table.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
Below
you'll find two queries. Both queries are exactly the same; they query
the
same database, query for the same info, same sql statement, same where
clause... The first query (with the longer date range) runs perfectly
against my databases. The
second query is as I've said exactly the same, the only difference is
that
the date range is much smaller and is infact included in the first
query. The
problem with this query is that it seems to churn away but do nothing.
It
seems to execute my query but it never finishes. Last time I cancelled
it after +2 hours. Does anybody why I see this behavior? Is there
something that I can do about it? Since it never seems to finish, I'm
not able to generate a execute plan for it to see what the problem is.
Thanks in advance :P
THE SANE QUERY:
----
----
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 asc
----
---
THE BAD QUERY:
----
---
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 ascP.S.
I have already reindexed the tables, cleared the cached query plans and
updated the statistics with no change in the outcome.|||swaroop.atre@.gmail.com wrote:
> I have a weird problem in Sql Server 2005 that I need some help on.
> Below
> you'll find two queries. Both queries are exactly the same; they query
> the
> same database, query for the same info, same sql statement, same where
> clause... The first query (with the longer date range) runs perfectly
> against my databases. The
> second query is as I've said exactly the same, the only difference is
> that
> the date range is much smaller and is infact included in the first
> query. The
> problem with this query is that it seems to churn away but do nothing.
> It
> seems to execute my query but it never finishes. Last time I cancelled
> it after +2 hours. Does anybody why I see this behavior? Is there
> something that I can do about it? Since it never seems to finish, I'm
> not able to generate a execute plan for it to see what the problem is.
> Thanks in advance :P
> THE SANE QUERY:
> ----
----
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
> T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
> 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
> ----
---
> THE BAD QUERY:
> ----
---
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" =
> T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" =
> 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
>
Compare the ESTIMATED execution plans for the two queries - what's the
difference between them? Where is the time being spent?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy,
They both have the exact same execution plan (which they should
considering its just a change in the value for a conditional
expression). The expected usage is largely with the lookup for the
transaction data table which uses a clustered index.
Swaroop
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Compare the ESTIMATED execution plans for the two queries - what's the
> difference between them? Where is the time being spent?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||UPDATE:
The execution plans changed once I updated the statistics on the dbases
again.
swaroop.atre@.gmail.com wrote:[vbcol=seagreen]
> Tracy,
> They both have the exact same execution plan (which they should
> considering its just a change in the value for a conditional
> expression). The expected usage is largely with the lookup for the
> transaction data table which uses a clustered index.
> Swaroop
>
> Tracy McKibben wrote:|||swaroop.atre@.gmail.com wrote:
> UPDATE:
> The execution plans changed once I updated the statistics on the dbases
> again.
>
Did the performance change as well?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Adding in the index on one of the tables altered the performance.
However on two other queries with the same problem they have no effect.
All tables being used are indexed.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Did the performance change as well?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||swaroop.atre@.gmail.com wrote:
> Adding in the index on one of the tables altered the performance.
> However on two other queries with the same problem they have no effect.
> All tables being used are indexed.
Review the execution plans. The queries may "appear" to have the same
problem, i.e. slow performance, but their indexing needs may be totally
different.
A good index will allow the WHERE clause to filter out unwanted rows as
quickly as possible, and may even provide all of the data necessary to
prevent a second trip to the table.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||The query is actually making a single trip to each table that it needs
information from.
The query in a jist gathers information from six tables the biggest one
being 150M records or so with a clustered unique index while the other
5 have non clustered non unique indexes. As long as the query looks for
data for the month of dec it never returns (the date constraint is
contained in the big table) however if i expand the range to include
dec but not just dec it comes back with the data i seek. The execution
plans for the two are very different and I think that might be because
the new one uses the indexes while the old one in the cache dosnt.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> Review the execution plans. The queries may "appear" to have the same
> problem, i.e. slow performance, but their indexing needs may be totally
> different.
> A good index will allow the WHERE clause to filter out unwanted rows as
> quickly as possible, and may even provide all of the data necessary to
> prevent a second trip to the table.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
Query Hangs when Parameters are scaled down.
I have a weird problem in Sql Server 2005 that I need some help on.
Below
you'll find two queries. Both queries are exactly the same; they query
the
same database, query for the same info, same sql statement, same where
clause... The first query (with the longer date range) runs perfectly
against my databases. The
second query is as I've said exactly the same, the only difference is
that
the date range is much smaller and is infact included in the first
query. The
problem with this query is that it seems to churn away but do nothing.
It
seems to execute my query but it never finishes. Last time I cancelled
it after +2 hours. Does anybody why I see this behavior? Is there
something that I can do about it? Since it never seems to finish, I'm
not able to generate a execute plan for it to see what the problem is.
Thanks in advance :P
THE SANE QUERY:
------
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" = T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" = 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 asc
------
THE BAD QUERY:
------
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" = T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" = 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 ascP.S.
I have already reindexed the tables, cleared the cached query plans and
updated the statistics with no change in the outcome.|||swaroop.atre@.gmail.com wrote:
> I have a weird problem in Sql Server 2005 that I need some help on.
> Below
> you'll find two queries. Both queries are exactly the same; they query
> the
> same database, query for the same info, same sql statement, same where
> clause... The first query (with the longer date range) runs perfectly
> against my databases. The
> second query is as I've said exactly the same, the only difference is
> that
> the date range is much smaller and is infact included in the first
> query. The
> problem with this query is that it seems to churn away but do nothing.
> It
> seems to execute my query but it never finishes. Last time I cancelled
> it after +2 hours. Does anybody why I see this behavior? Is there
> something that I can do about it? Since it never seems to finish, I'm
> not able to generate a execute plan for it to see what the problem is.
> Thanks in advance :P
> THE SANE QUERY:
> ------
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
> ------
> THE BAD QUERY:
> ------
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
>
Compare the ESTIMATED execution plans for the two queries - what's the
difference between them? Where is the time being spent?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy,
They both have the exact same execution plan (which they should
considering its just a change in the value for a conditional
expression). The expected usage is largely with the lookup for the
transaction data table which uses a clustered index.
Swaroop
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> > I have a weird problem in Sql Server 2005 that I need some help on.
> > Below
> > you'll find two queries. Both queries are exactly the same; they query
> > the
> > same database, query for the same info, same sql statement, same where
> > clause... The first query (with the longer date range) runs perfectly
> > against my databases. The
> > second query is as I've said exactly the same, the only difference is
> > that
> > the date range is much smaller and is infact included in the first
> > query. The
> > problem with this query is that it seems to churn away but do nothing.
> > It
> > seems to execute my query but it never finishes. Last time I cancelled
> > it after +2 hours. Does anybody why I see this behavior? Is there
> > something that I can do about it? Since it never seems to finish, I'm
> > not able to generate a execute plan for it to see what the problem is.
> > Thanks in advance :P
> >
> > THE SANE QUERY:
> > ------
> > select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> > T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> > sum(T2."TRANSACTION_AMT") AS "c5"
> >
> > from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> > "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> > "Accounting"."ACCOUNTING"."GL_DIM" T4,
> > "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> > "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> > substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> >
> > where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => > T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => > 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> > ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> > 00:00:00.000' and '2006-12-31 00:00:00.000'
> >
> > group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> >
> > order by 1 asc , 2 asc , 3 asc
> > ------
> >
> > THE BAD QUERY:
> > ------
> > select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> > T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> > sum(T2."TRANSACTION_AMT") AS "c5"
> >
> > from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> > "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> > "Accounting"."ACCOUNTING"."GL_DIM" T4,
> > "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> > "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> > substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> >
> > where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => > T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => > 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> > ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> > 00:00:00.000' and '2006-12-31 00:00:00.000'
> >
> > group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> >
> > order by 1 asc , 2 asc , 3 asc
> >
> Compare the ESTIMATED execution plans for the two queries - what's the
> difference between them? Where is the time being spent?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||UPDATE:
The execution plans changed once I updated the statistics on the dbases
again.
swaroop.atre@.gmail.com wrote:
> Tracy,
> They both have the exact same execution plan (which they should
> considering its just a change in the value for a conditional
> expression). The expected usage is largely with the lookup for the
> transaction data table which uses a clustered index.
> Swaroop
>
> Tracy McKibben wrote:
> > swaroop.atre@.gmail.com wrote:
> > > I have a weird problem in Sql Server 2005 that I need some help on.
> > > Below
> > > you'll find two queries. Both queries are exactly the same; they query
> > > the
> > > same database, query for the same info, same sql statement, same where
> > > clause... The first query (with the longer date range) runs perfectly
> > > against my databases. The
> > > second query is as I've said exactly the same, the only difference is
> > > that
> > > the date range is much smaller and is infact included in the first
> > > query. The
> > > problem with this query is that it seems to churn away but do nothing.
> > > It
> > > seems to execute my query but it never finishes. Last time I cancelled
> > > it after +2 hours. Does anybody why I see this behavior? Is there
> > > something that I can do about it? Since it never seems to finish, I'm
> > > not able to generate a execute plan for it to see what the problem is.
> > > Thanks in advance :P
> > >
> > > THE SANE QUERY:
> > > ------
> > > select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> > > T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> > > sum(T2."TRANSACTION_AMT") AS "c5"
> > >
> > > from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> > > "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> > > "Accounting"."ACCOUNTING"."GL_DIM" T4,
> > > "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> > > "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> > > substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> > >
> > > where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => > > T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => > > 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> > > ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> > > 00:00:00.000' and '2006-12-31 00:00:00.000'
> > >
> > > group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> > >
> > > order by 1 asc , 2 asc , 3 asc
> > > ------
> > >
> > > THE BAD QUERY:
> > > ------
> > > select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> > > T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> > > sum(T2."TRANSACTION_AMT") AS "c5"
> > >
> > > from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> > > "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> > > "Accounting"."ACCOUNTING"."GL_DIM" T4,
> > > "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> > > "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> > > substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> > >
> > > where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => > > T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => > > 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> > > ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> > > 00:00:00.000' and '2006-12-31 00:00:00.000'
> > >
> > > group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> > >
> > > order by 1 asc , 2 asc , 3 asc
> > >
> >
> > Compare the ESTIMATED execution plans for the two queries - what's the
> > difference between them? Where is the time being spent?
> >
> >
> > --
> > Tracy McKibben
> > MCDBA
> > http://www.realsqlguy.com|||swaroop.atre@.gmail.com wrote:
> UPDATE:
> The execution plans changed once I updated the statistics on the dbases
> again.
>
Did the performance change as well?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Adding in the index on one of the tables altered the performance.
However on two other queries with the same problem they have no effect.
All tables being used are indexed.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> > UPDATE:
> >
> > The execution plans changed once I updated the statistics on the dbases
> > again.
> >
> Did the performance change as well?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||swaroop.atre@.gmail.com wrote:
> Adding in the index on one of the tables altered the performance.
> However on two other queries with the same problem they have no effect.
> All tables being used are indexed.
Review the execution plans. The queries may "appear" to have the same
problem, i.e. slow performance, but their indexing needs may be totally
different.
A good index will allow the WHERE clause to filter out unwanted rows as
quickly as possible, and may even provide all of the data necessary to
prevent a second trip to the table.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||The query is actually making a single trip to each table that it needs
information from.
The query in a jist gathers information from six tables the biggest one
being 150M records or so with a clustered unique index while the other
5 have non clustered non unique indexes. As long as the query looks for
data for the month of dec it never returns (the date constraint is
contained in the big table) however if i expand the range to include
dec but not just dec it comes back with the data i seek. The execution
plans for the two are very different and I think that might be because
the new one uses the indexes while the old one in the cache dosnt.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> > Adding in the index on one of the tables altered the performance.
> >
> > However on two other queries with the same problem they have no effect.
> > All tables being used are indexed.
> Review the execution plans. The queries may "appear" to have the same
> problem, i.e. slow performance, but their indexing needs may be totally
> different.
> A good index will allow the WHERE clause to filter out unwanted rows as
> quickly as possible, and may even provide all of the data necessary to
> prevent a second trip to the table.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.comsql
Below
you'll find two queries. Both queries are exactly the same; they query
the
same database, query for the same info, same sql statement, same where
clause... The first query (with the longer date range) runs perfectly
against my databases. The
second query is as I've said exactly the same, the only difference is
that
the date range is much smaller and is infact included in the first
query. The
problem with this query is that it seems to churn away but do nothing.
It
seems to execute my query but it never finishes. Last time I cancelled
it after +2 hours. Does anybody why I see this behavior? Is there
something that I can do about it? Since it never seems to finish, I'm
not able to generate a execute plan for it to see what the problem is.
Thanks in advance :P
THE SANE QUERY:
------
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" = T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" = 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 asc
------
THE BAD QUERY:
------
select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
sum(T2."TRANSACTION_AMT") AS "c5"
from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
"Accounting"."ACCOUNTING"."TIME_DIM" T1,
"Accounting"."ACCOUNTING"."GL_DIM" T4,
"Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
"Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" = T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" = 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
00:00:00.000' and '2006-12-31 00:00:00.000'
group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
order by 1 asc , 2 asc , 3 ascP.S.
I have already reindexed the tables, cleared the cached query plans and
updated the statistics with no change in the outcome.|||swaroop.atre@.gmail.com wrote:
> I have a weird problem in Sql Server 2005 that I need some help on.
> Below
> you'll find two queries. Both queries are exactly the same; they query
> the
> same database, query for the same info, same sql statement, same where
> clause... The first query (with the longer date range) runs perfectly
> against my databases. The
> second query is as I've said exactly the same, the only difference is
> that
> the date range is much smaller and is infact included in the first
> query. The
> problem with this query is that it seems to churn away but do nothing.
> It
> seems to execute my query but it never finishes. Last time I cancelled
> it after +2 hours. Does anybody why I see this behavior? Is there
> something that I can do about it? Since it never seems to finish, I'm
> not able to generate a execute plan for it to see what the problem is.
> Thanks in advance :P
> THE SANE QUERY:
> ------
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
> ------
> THE BAD QUERY:
> ------
> select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> sum(T2."TRANSACTION_AMT") AS "c5"
> from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> "Accounting"."ACCOUNTING"."GL_DIM" T4,
> "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> 00:00:00.000' and '2006-12-31 00:00:00.000'
> group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> order by 1 asc , 2 asc , 3 asc
>
Compare the ESTIMATED execution plans for the two queries - what's the
difference between them? Where is the time being spent?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy,
They both have the exact same execution plan (which they should
considering its just a change in the value for a conditional
expression). The expected usage is largely with the lookup for the
transaction data table which uses a clustered index.
Swaroop
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> > I have a weird problem in Sql Server 2005 that I need some help on.
> > Below
> > you'll find two queries. Both queries are exactly the same; they query
> > the
> > same database, query for the same info, same sql statement, same where
> > clause... The first query (with the longer date range) runs perfectly
> > against my databases. The
> > second query is as I've said exactly the same, the only difference is
> > that
> > the date range is much smaller and is infact included in the first
> > query. The
> > problem with this query is that it seems to churn away but do nothing.
> > It
> > seems to execute my query but it never finishes. Last time I cancelled
> > it after +2 hours. Does anybody why I see this behavior? Is there
> > something that I can do about it? Since it never seems to finish, I'm
> > not able to generate a execute plan for it to see what the problem is.
> > Thanks in advance :P
> >
> > THE SANE QUERY:
> > ------
> > select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> > T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> > sum(T2."TRANSACTION_AMT") AS "c5"
> >
> > from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> > "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> > "Accounting"."ACCOUNTING"."GL_DIM" T4,
> > "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> > "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> > substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> >
> > where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => > T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => > 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> > ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> > 00:00:00.000' and '2006-12-31 00:00:00.000'
> >
> > group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> >
> > order by 1 asc , 2 asc , 3 asc
> > ------
> >
> > THE BAD QUERY:
> > ------
> > select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> > T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> > sum(T2."TRANSACTION_AMT") AS "c5"
> >
> > from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> > "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> > "Accounting"."ACCOUNTING"."GL_DIM" T4,
> > "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> > "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> > substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> >
> > where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => > T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => > 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> > ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> > 00:00:00.000' and '2006-12-31 00:00:00.000'
> >
> > group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> >
> > order by 1 asc , 2 asc , 3 asc
> >
> Compare the ESTIMATED execution plans for the two queries - what's the
> difference between them? Where is the time being spent?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||UPDATE:
The execution plans changed once I updated the statistics on the dbases
again.
swaroop.atre@.gmail.com wrote:
> Tracy,
> They both have the exact same execution plan (which they should
> considering its just a change in the value for a conditional
> expression). The expected usage is largely with the lookup for the
> transaction data table which uses a clustered index.
> Swaroop
>
> Tracy McKibben wrote:
> > swaroop.atre@.gmail.com wrote:
> > > I have a weird problem in Sql Server 2005 that I need some help on.
> > > Below
> > > you'll find two queries. Both queries are exactly the same; they query
> > > the
> > > same database, query for the same info, same sql statement, same where
> > > clause... The first query (with the longer date range) runs perfectly
> > > against my databases. The
> > > second query is as I've said exactly the same, the only difference is
> > > that
> > > the date range is much smaller and is infact included in the first
> > > query. The
> > > problem with this query is that it seems to churn away but do nothing.
> > > It
> > > seems to execute my query but it never finishes. Last time I cancelled
> > > it after +2 hours. Does anybody why I see this behavior? Is there
> > > something that I can do about it? Since it never seems to finish, I'm
> > > not able to generate a execute plan for it to see what the problem is.
> > > Thanks in advance :P
> > >
> > > THE SANE QUERY:
> > > ------
> > > select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> > > T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> > > sum(T2."TRANSACTION_AMT") AS "c5"
> > >
> > > from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> > > "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> > > "Accounting"."ACCOUNTING"."GL_DIM" T4,
> > > "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> > > "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> > > substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> > >
> > > where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => > > T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => > > 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> > > ('430', '431') and T2."TRANS_POST_DATE" between '2006-07-01
> > > 00:00:00.000' and '2006-12-31 00:00:00.000'
> > >
> > > group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> > >
> > > order by 1 asc , 2 asc , 3 asc
> > > ------
> > >
> > > THE BAD QUERY:
> > > ------
> > > select T1."FISCAL_YEAR" AS "c1", T2."DOC_TYPE" AS "c2",
> > > T3."PJ1_OPER_SECTOR_CODE" AS "c3", count(T2."TRANS_DOC_SFX") AS "c4",
> > > sum(T2."TRANSACTION_AMT") AS "c5"
> > >
> > > from "Accounting"."ACCOUNTING"."TRANSACTION_DETAIL_FACT" T2,
> > > "Accounting"."ACCOUNTING"."TIME_DIM" T1,
> > > "Accounting"."ACCOUNTING"."GL_DIM" T4,
> > > "Accounting"."ACCOUNTING"."PROJECT_DIM" T5 LEFT OUTER JOIN
> > > "Accounting"."ACCOUNTING"."LOCATION_SUPER_TABLE" T3 on
> > > substring(T5."PROJECT_CODE_1",1,4) = substring(T3."PJ1_LOC_CODE",1,4)
> > >
> > > where T2."TIME_KEY" = T1."TIME_KEY" and T2."PROJECT_KEY" => > > T5."PROJECT_KEY" and T2."GL_KEY" = T4."GL_KEY" and T1."FISCAL_YEAR" => > > 2007 and T2."DOC_TYPE" in ('IV', 'WI', 'PC') and T4."GL_ACCT_CODE" in
> > > ('430', '431') and T2."TRANS_POST_DATE" between '2006-12-01
> > > 00:00:00.000' and '2006-12-31 00:00:00.000'
> > >
> > > group by T1."FISCAL_YEAR", T2."DOC_TYPE", T3."PJ1_OPER_SECTOR_CODE"
> > >
> > > order by 1 asc , 2 asc , 3 asc
> > >
> >
> > Compare the ESTIMATED execution plans for the two queries - what's the
> > difference between them? Where is the time being spent?
> >
> >
> > --
> > Tracy McKibben
> > MCDBA
> > http://www.realsqlguy.com|||swaroop.atre@.gmail.com wrote:
> UPDATE:
> The execution plans changed once I updated the statistics on the dbases
> again.
>
Did the performance change as well?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Adding in the index on one of the tables altered the performance.
However on two other queries with the same problem they have no effect.
All tables being used are indexed.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> > UPDATE:
> >
> > The execution plans changed once I updated the statistics on the dbases
> > again.
> >
> Did the performance change as well?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||swaroop.atre@.gmail.com wrote:
> Adding in the index on one of the tables altered the performance.
> However on two other queries with the same problem they have no effect.
> All tables being used are indexed.
Review the execution plans. The queries may "appear" to have the same
problem, i.e. slow performance, but their indexing needs may be totally
different.
A good index will allow the WHERE clause to filter out unwanted rows as
quickly as possible, and may even provide all of the data necessary to
prevent a second trip to the table.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||The query is actually making a single trip to each table that it needs
information from.
The query in a jist gathers information from six tables the biggest one
being 150M records or so with a clustered unique index while the other
5 have non clustered non unique indexes. As long as the query looks for
data for the month of dec it never returns (the date constraint is
contained in the big table) however if i expand the range to include
dec but not just dec it comes back with the data i seek. The execution
plans for the two are very different and I think that might be because
the new one uses the indexes while the old one in the cache dosnt.
Tracy McKibben wrote:
> swaroop.atre@.gmail.com wrote:
> > Adding in the index on one of the tables altered the performance.
> >
> > However on two other queries with the same problem they have no effect.
> > All tables being used are indexed.
> Review the execution plans. The queries may "appear" to have the same
> problem, i.e. slow performance, but their indexing needs may be totally
> different.
> A good index will allow the WHERE clause to filter out unwanted rows as
> quickly as possible, and may even provide all of the data necessary to
> prevent a second trip to the table.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.comsql
Monday, March 12, 2012
Query doesn't hangs when run using parameters
I have a weird problem in Sql Server 2005 that I need some help on. Below
you'll find two queries. Both queries are exactly the same; they query the
same database, query for the same info, same sql statement, same where
clause... The first query (the one with all the parameters included in the
sql statement) runs perfectly against my database in less than a second. The
second query is as I've said exactly the same, the only difference is that
the parameters are now passed using the SqlCommand.Parameters-collection. The
problem with this query is that it seems to cause Sql Server to hang. It
seems to execute my query (CPU varies between 70% and 100%) but it never
finishes. Last time I cancelled it after +20 minutes. Does anybody why I see
this behavior? Is there something that I can do about it? For what it's
worth, my database hardly contains any data. Since it never seems to finish,
I'm not able to generate a execute plan for it to see what the problem is.
The good query:
SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn], a.[ModifiedBy],
a.[Tag], a.[FileCount]
FROM tblRECORDS a
WHERE a.[ID] IN (
SELECT a.[ID]
FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
ON a.[Id] = f.[RecordId]
WHERE
(
(
(
(
b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
b.[Keywords] LIKE 'Dit %' ESCAPE '~'
)
AND
(
c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
c.[Keywords] LIKE 'de %' ESCAPE '~'
)
AND
(
d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
)
AND
(
e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
e.[Keywords] LIKE 'eerste %' ESCAPE '~'
)
AND
(
f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
f.[Keywords] LIKE 'optie %' ESCAPE '~'
)
)
OR
(
(
b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
b.[Keywords] LIKE 'Dit %' ESCAPE '~'
)
AND
(
c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
c.[Keywords] LIKE 'de %' ESCAPE '~'
)
AND
(
d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
)
AND
(
e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
e.[Keywords] LIKE 'eerste %' ESCAPE '~'
)
AND
(
f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
f.[Keywords] LIKE 'optie %' ESCAPE '~'
)
)
) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
)
)
The bad query:
exec sp_executesql N'
SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
a.[ModifiedBy], a.[Tag], a.[FileCount]
FROM tblRECORDS a
WHERE a.[ID] IN
(
SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
ON a.[Id] = f.[RecordId]
WHERE
(
(
(
(
b.[LanguageId] = @.__0
AND
b.[Keywords] LIKE @.__1 ESCAPE ''~''
)
AND
(
c.[LanguageId] = @.__2
AND
c.[Keywords] LIKE @.__3 ESCAPE ''~''
)
AND
(
d.[LanguageId] = @.__4
AND
d.[Keywords] LIKE @.__5 ESCAPE ''~''
)
AND
(
e.[LanguageId] = @.__6
AND
e.[Keywords] LIKE @.__7 ESCAPE ''~''
)
AND
(
f.[LanguageId] = @.__8
AND
f.[Keywords] LIKE @.__9 ESCAPE ''~''
)
)
OR
(
(
b.[LanguageId] = @.__10
AND
b.[Keywords] LIKE @.__11 ESCAPE ''~''
)
AND
(
c.[LanguageId] = @.__12
AND
c.[Keywords] LIKE @.__13 ESCAPE ''~''
)
AND
(
d.[LanguageId] = @.__14
AND
d.[Keywords] LIKE @.__15 ESCAPE ''~''
)
AND
(
e.[LanguageId] = @.__16
AND
e.[Keywords] LIKE @.__17 ESCAPE ''~''
)
AND
(
f.[LanguageId] = @.__18
AND
f.[Keywords] LIKE @.__19 ESCAPE ''~''
)
)
)
AND
a.[ID] = @.__20
)
)',
N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
nvarchar(4),
@.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
nvarchar(8),
@.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
nvarchar(5),
@.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
nvarchar(13),
@.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
nvarchar(7),
@.__20
uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %',
@.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
@.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
@.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
@.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
@.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
@.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
@.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
@.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
@.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
@.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'Michael Vanhoutte wrote:
> I have a weird problem in Sql Server 2005 that I need some help on. Below
> you'll find two queries. Both queries are exactly the same; they query the
> same database, query for the same info, same sql statement, same where
> clause... The first query (the one with all the parameters included in the
> sql statement) runs perfectly against my database in less than a second. The
> second query is as I've said exactly the same, the only difference is that
> the parameters are now passed using the SqlCommand.Parameters-collection. The
> problem with this query is that it seems to cause Sql Server to hang. It
> seems to execute my query (CPU varies between 70% and 100%) but it never
> finishes. Last time I cancelled it after +20 minutes. Does anybody why I see
> this behavior? Is there something that I can do about it? For what it's
> worth, my database hardly contains any data. Since it never seems to finish,
> I'm not able to generate a execute plan for it to see what the problem is.
> The good query:
> SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn], a.[ModifiedBy],
> a.[Tag], a.[FileCount]
> FROM tblRECORDS a
> WHERE a.[ID] IN (
> SELECT a.[ID]
> FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> ON a.[Id] = f.[RecordId]
> WHERE
> (
> (
> (
> (
> b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> )
> AND
> (
> c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> c.[Keywords] LIKE 'de %' ESCAPE '~'
> )
> AND
> (
> d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> )
> AND
> (
> e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> )
> AND
> (
> f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> f.[Keywords] LIKE 'optie %' ESCAPE '~'
> )
> )
> OR
> (
> (
> b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> )
> AND
> (
> c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> c.[Keywords] LIKE 'de %' ESCAPE '~'
> )
> AND
> (
> d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> )
> AND
> (
> e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> )
> AND
> (
> f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> f.[Keywords] LIKE 'optie %' ESCAPE '~'
> )
> )
> ) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
> )
> )
> The bad query:
> exec sp_executesql N'
> SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
> a.[ModifiedBy], a.[Tag], a.[FileCount]
> FROM tblRECORDS a
> WHERE a.[ID] IN
> (
> SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> ON a.[Id] = f.[RecordId]
> WHERE
> (
> (
> (
> (
> b.[LanguageId] = @.__0
> AND
> b.[Keywords] LIKE @.__1 ESCAPE ''~''
> )
> AND
> (
> c.[LanguageId] = @.__2
> AND
> c.[Keywords] LIKE @.__3 ESCAPE ''~''
> )
> AND
> (
> d.[LanguageId] = @.__4
> AND
> d.[Keywords] LIKE @.__5 ESCAPE ''~''
> )
> AND
> (
> e.[LanguageId] = @.__6
> AND
> e.[Keywords] LIKE @.__7 ESCAPE ''~''
> )
> AND
> (
> f.[LanguageId] = @.__8
> AND
> f.[Keywords] LIKE @.__9 ESCAPE ''~''
> )
> )
> OR
> (
> (
> b.[LanguageId] = @.__10
> AND
> b.[Keywords] LIKE @.__11 ESCAPE ''~''
> )
> AND
> (
> c.[LanguageId] = @.__12
> AND
> c.[Keywords] LIKE @.__13 ESCAPE ''~''
> )
> AND
> (
> d.[LanguageId] = @.__14
> AND
> d.[Keywords] LIKE @.__15 ESCAPE ''~''
> )
> AND
> (
> e.[LanguageId] = @.__16
> AND
> e.[Keywords] LIKE @.__17 ESCAPE ''~''
> )
> AND
> (
> f.[LanguageId] = @.__18
> AND
> f.[Keywords] LIKE @.__19 ESCAPE ''~''
> )
> )
> )
> AND
> a.[ID] = @.__20
> )
> )',
> N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
> nvarchar(4),
> @.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
> nvarchar(8),
> @.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
> nvarchar(5),
> @.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
> nvarchar(13),
> @.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
> nvarchar(7),
> @.__20
> uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %',
> @.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
> @.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
> @.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
> @.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
> @.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
> @.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
> @.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
> @.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
> @.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
> @.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'
Do a Google search for "parameter sniffing"
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Hi Tracy,
Thanks for your reply. First of all, sorry for the brilliant typo in my
subject. I only noticed that now. ;-)
I see where you're going with your answer. I know that Sql Server caches the
execution plan of a query and that you might sometimes get a slower response
if it happens to use an execution plan that is not optimal for your
parameters.
However, I wonder if there's not something more going on here. The reason
why I'm saying this is that my table hardly contains any data. The biggest
table involved in my query contains a few dozen records. I mean that
literally: 61 records to be exact. There are a few other tables involved in
the view but they contain even fewer records. Most less than 10. So, even if
the execution plan would be completely wrong and Sql Server would use table
scans for everything, it should still finish instantaneously. Could the
impact really be this bad that it takes +20 minutes to query and join a few
tables that all contain less than 100 rows?
By the way, I have tried using RECOMPILE and the query does seem to run at
normal speed now.
Regards,
Michael
"Tracy McKibben" wrote:
> Michael Vanhoutte wrote:
> > I have a weird problem in Sql Server 2005 that I need some help on. Below
> > you'll find two queries. Both queries are exactly the same; they query the
> > same database, query for the same info, same sql statement, same where
> > clause... The first query (the one with all the parameters included in the
> > sql statement) runs perfectly against my database in less than a second. The
> > second query is as I've said exactly the same, the only difference is that
> > the parameters are now passed using the SqlCommand.Parameters-collection. The
> > problem with this query is that it seems to cause Sql Server to hang. It
> > seems to execute my query (CPU varies between 70% and 100%) but it never
> > finishes. Last time I cancelled it after +20 minutes. Does anybody why I see
> > this behavior? Is there something that I can do about it? For what it's
> > worth, my database hardly contains any data. Since it never seems to finish,
> > I'm not able to generate a execute plan for it to see what the problem is.
> >
> > The good query:
> > SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn], a.[ModifiedBy],
> > a.[Tag], a.[FileCount]
> > FROM tblRECORDS a
> > WHERE a.[ID] IN (
> > SELECT a.[ID]
> > FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> > ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> > ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> > ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> > ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> > ON a.[Id] = f.[RecordId]
> > WHERE
> > (
> > (
> > (
> > (
> > b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> > )
> > AND
> > (
> > c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > c.[Keywords] LIKE 'de %' ESCAPE '~'
> > )
> > AND
> > (
> > d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> > )
> > AND
> > (
> > e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> > )
> > AND
> > (
> > f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > f.[Keywords] LIKE 'optie %' ESCAPE '~'
> > )
> > )
> > OR
> > (
> > (
> > b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> > )
> > AND
> > (
> > c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > c.[Keywords] LIKE 'de %' ESCAPE '~'
> > )
> > AND
> > (
> > d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> > )
> > AND
> > (
> > e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> > )
> > AND
> > (
> > f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > f.[Keywords] LIKE 'optie %' ESCAPE '~'
> > )
> > )
> > ) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
> > )
> > )
> >
> > The bad query:
> > exec sp_executesql N'
> > SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
> > a.[ModifiedBy], a.[Tag], a.[FileCount]
> > FROM tblRECORDS a
> > WHERE a.[ID] IN
> > (
> > SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> > ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> > ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> > ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> > ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> > ON a.[Id] = f.[RecordId]
> > WHERE
> > (
> > (
> > (
> > (
> > b.[LanguageId] = @.__0
> > AND
> > b.[Keywords] LIKE @.__1 ESCAPE ''~''
> > )
> > AND
> > (
> > c.[LanguageId] = @.__2
> > AND
> > c.[Keywords] LIKE @.__3 ESCAPE ''~''
> > )
> > AND
> > (
> > d.[LanguageId] = @.__4
> > AND
> > d.[Keywords] LIKE @.__5 ESCAPE ''~''
> > )
> > AND
> > (
> > e.[LanguageId] = @.__6
> > AND
> > e.[Keywords] LIKE @.__7 ESCAPE ''~''
> > )
> > AND
> > (
> > f.[LanguageId] = @.__8
> > AND
> > f.[Keywords] LIKE @.__9 ESCAPE ''~''
> > )
> > )
> > OR
> > (
> > (
> > b.[LanguageId] = @.__10
> > AND
> > b.[Keywords] LIKE @.__11 ESCAPE ''~''
> > )
> > AND
> > (
> > c.[LanguageId] = @.__12
> > AND
> > c.[Keywords] LIKE @.__13 ESCAPE ''~''
> > )
> > AND
> > (
> > d.[LanguageId] = @.__14
> > AND
> > d.[Keywords] LIKE @.__15 ESCAPE ''~''
> > )
> > AND
> > (
> > e.[LanguageId] = @.__16
> > AND
> > e.[Keywords] LIKE @.__17 ESCAPE ''~''
> > )
> > AND
> > (
> > f.[LanguageId] = @.__18
> > AND
> > f.[Keywords] LIKE @.__19 ESCAPE ''~''
> > )
> > )
> > )
> > AND
> > a.[ID] = @.__20
> > )
> > )',
> > N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
> > nvarchar(4),
> > @.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
> > nvarchar(8),
> > @.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
> > nvarchar(5),
> > @.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
> > nvarchar(13),
> > @.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
> > nvarchar(7),
> > @.__20
> > uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %',
> > @.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
> > @.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
> > @.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
> > @.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
> > @.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
> > @.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
> > @.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
> > @.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
> > @.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
> > @.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'
> Do a Google search for "parameter sniffing"
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Michael Vanhoutte wrote:
> Hi Tracy,
> Thanks for your reply. First of all, sorry for the brilliant typo in my
> subject. I only noticed that now. ;-)
> I see where you're going with your answer. I know that Sql Server caches the
> execution plan of a query and that you might sometimes get a slower response
> if it happens to use an execution plan that is not optimal for your
> parameters.
> However, I wonder if there's not something more going on here. The reason
> why I'm saying this is that my table hardly contains any data. The biggest
> table involved in my query contains a few dozen records. I mean that
> literally: 61 records to be exact. There are a few other tables involved in
> the view but they contain even fewer records. Most less than 10. So, even if
> the execution plan would be completely wrong and Sql Server would use table
> scans for everything, it should still finish instantaneously. Could the
> impact really be this bad that it takes +20 minutes to query and join a few
> tables that all contain less than 100 rows?
> By the way, I have tried using RECOMPILE and the query does seem to run at
> normal speed now.
20 minutes does seem excessive for such little data, but it's still not
impossible to believe. Worst case, as you said, is that the execution
plan is so bad that it falls down to doing full table scans on all the
involved tables. That makes you vulnerable to a couple of things:
1. Blocking - you don't say how busy these tables are, so this is
speculation. Assuming that other processes are using these tables, your
table scans could be blocked. Even SELECTs can place locks on a table,
and those locks will interfere with a scan.
2. Resource contention - without knowing your hardware specs, this is
also speculation. If the server is extremely tight on memory, these
tables might have to be read from disk when the scan occurs. If your
drives are I/O bound, these reads will be affected.
There could be something other than parameter sniffing at work here, but
based on the symptoms, I'm going to stick with that as my answer.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Today, I wanted to update my code to include the RECOMPILE-option in the
query but the first time I executed the query with the RECOMPILE-option on, I
noticed that it again took forever to run. I have let it run for over two and
a half hours now and it is still busy, so I'm guessing that something else is
going on.
Some more info:
1. The query runs against the Sql Server on my laptop. I have plenty of
memory available when the query starts and my Sql Server is not used at all
except to run this query. No other users are connected.
2. Before the query starts, Sql Server is using about 150MB of RAM (of the
1,5GB that I have on my laptop) and after a couple of minutes, the memory
used by Sql Server increases up to more than 1GB. So, memory usage to run
this particular query is enormous. This is weird because as I've said it
queries tables that almost don't contain any records and it should return a
single record in the end.
3. I have checked in Activity Monitor while the query is running and there
are no blocking or blocked processes.
4. Also, the Sql Server process is constantly using CPU, with an average of
about 25% during the last two hours.
5. I have constant disc activity while the query is running
6. My laptop is simply not usable anymore while the query is running. Sql
Server is using so much memory and disc activity that anything I try to do
takes ages.
Any other insights on what might be causing this problem?
"Tracy McKibben" wrote:
> Michael Vanhoutte wrote:
> > Hi Tracy,
> >
> > Thanks for your reply. First of all, sorry for the brilliant typo in my
> > subject. I only noticed that now. ;-)
> >
> > I see where you're going with your answer. I know that Sql Server caches the
> > execution plan of a query and that you might sometimes get a slower response
> > if it happens to use an execution plan that is not optimal for your
> > parameters.
> >
> > However, I wonder if there's not something more going on here. The reason
> > why I'm saying this is that my table hardly contains any data. The biggest
> > table involved in my query contains a few dozen records. I mean that
> > literally: 61 records to be exact. There are a few other tables involved in
> > the view but they contain even fewer records. Most less than 10. So, even if
> > the execution plan would be completely wrong and Sql Server would use table
> > scans for everything, it should still finish instantaneously. Could the
> > impact really be this bad that it takes +20 minutes to query and join a few
> > tables that all contain less than 100 rows?
> >
> > By the way, I have tried using RECOMPILE and the query does seem to run at
> > normal speed now.
> 20 minutes does seem excessive for such little data, but it's still not
> impossible to believe. Worst case, as you said, is that the execution
> plan is so bad that it falls down to doing full table scans on all the
> involved tables. That makes you vulnerable to a couple of things:
> 1. Blocking - you don't say how busy these tables are, so this is
> speculation. Assuming that other processes are using these tables, your
> table scans could be blocked. Even SELECTs can place locks on a table,
> and those locks will interfere with a scan.
> 2. Resource contention - without knowing your hardware specs, this is
> also speculation. If the server is extremely tight on memory, these
> tables might have to be read from disk when the scan occurs. If your
> drives are I/O bound, these reads will be affected.
> There could be something other than parameter sniffing at work here, but
> based on the symptoms, I'm going to stick with that as my answer.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Michael Vanhoutte wrote:
> Today, I wanted to update my code to include the RECOMPILE-option in the
> query but the first time I executed the query with the RECOMPILE-option on, I
> noticed that it again took forever to run. I have let it run for over two and
> a half hours now and it is still busy, so I'm guessing that something else is
> going on.
> Some more info:
> 1. The query runs against the Sql Server on my laptop. I have plenty of
> memory available when the query starts and my Sql Server is not used at all
> except to run this query. No other users are connected.
> 2. Before the query starts, Sql Server is using about 150MB of RAM (of the
> 1,5GB that I have on my laptop) and after a couple of minutes, the memory
> used by Sql Server increases up to more than 1GB. So, memory usage to run
> this particular query is enormous. This is weird because as I've said it
> queries tables that almost don't contain any records and it should return a
> single record in the end.
> 3. I have checked in Activity Monitor while the query is running and there
> are no blocking or blocked processes.
> 4. Also, the Sql Server process is constantly using CPU, with an average of
> about 25% during the last two hours.
> 5. I have constant disc activity while the query is running
> 6. My laptop is simply not usable anymore while the query is running. Sql
> Server is using so much memory and disc activity that anything I try to do
> takes ages.
> Any other insights on what might be causing this problem?
>
You should probably try to get a Profiler trace to see what SQL is doing
while the machine is getting hammered...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I don't believe it... I wanted to run a more detailed profiler trace today to
get some more information. I had already run a default trace earlier, but all
that got me was an RPC Starting-event with the Sql statement that was in my
report. Today, I activated ALL events in profiler and I started the query.
Guess what? I can't reproduce the problem anymore! Nothing has changed as far
as data, structure, queries... I'm guessing that Sql Server automatically
updated some statistics which causes it to use a different execution plan.
This morning, I said to myself to take a backup of the database while the
problem is still there, but apparently I'm too late. We'll see in the coming
days if the problem comes back. Thanks for your help so far!
"Tracy McKibben" wrote:
> Michael Vanhoutte wrote:
> > Today, I wanted to update my code to include the RECOMPILE-option in the
> > query but the first time I executed the query with the RECOMPILE-option on, I
> > noticed that it again took forever to run. I have let it run for over two and
> > a half hours now and it is still busy, so I'm guessing that something else is
> > going on.
> >
> > Some more info:
> > 1. The query runs against the Sql Server on my laptop. I have plenty of
> > memory available when the query starts and my Sql Server is not used at all
> > except to run this query. No other users are connected.
> > 2. Before the query starts, Sql Server is using about 150MB of RAM (of the
> > 1,5GB that I have on my laptop) and after a couple of minutes, the memory
> > used by Sql Server increases up to more than 1GB. So, memory usage to run
> > this particular query is enormous. This is weird because as I've said it
> > queries tables that almost don't contain any records and it should return a
> > single record in the end.
> > 3. I have checked in Activity Monitor while the query is running and there
> > are no blocking or blocked processes.
> > 4. Also, the Sql Server process is constantly using CPU, with an average of
> > about 25% during the last two hours.
> > 5. I have constant disc activity while the query is running
> > 6. My laptop is simply not usable anymore while the query is running. Sql
> > Server is using so much memory and disc activity that anything I try to do
> > takes ages.
> >
> > Any other insights on what might be causing this problem?
> >
> You should probably try to get a Profiler trace to see what SQL is doing
> while the machine is getting hammered...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Michael Vanhoutte wrote:
> I don't believe it... I wanted to run a more detailed profiler trace today to
> get some more information. I had already run a default trace earlier, but all
> that got me was an RPC Starting-event with the Sql statement that was in my
> report. Today, I activated ALL events in profiler and I started the query.
> Guess what? I can't reproduce the problem anymore! Nothing has changed as far
> as data, structure, queries... I'm guessing that Sql Server automatically
> updated some statistics which causes it to use a different execution plan.
> This morning, I said to myself to take a backup of the database while the
> problem is still there, but apparently I'm too late. We'll see in the coming
> days if the problem comes back. Thanks for your help so far!
>
If you have auto-stats enabled, or run a scheduled stats update, that
very well could be what happened. Or, it could have been an inefficient
query plan that was cached, and has since dropped out of the cache.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
you'll find two queries. Both queries are exactly the same; they query the
same database, query for the same info, same sql statement, same where
clause... The first query (the one with all the parameters included in the
sql statement) runs perfectly against my database in less than a second. The
second query is as I've said exactly the same, the only difference is that
the parameters are now passed using the SqlCommand.Parameters-collection. The
problem with this query is that it seems to cause Sql Server to hang. It
seems to execute my query (CPU varies between 70% and 100%) but it never
finishes. Last time I cancelled it after +20 minutes. Does anybody why I see
this behavior? Is there something that I can do about it? For what it's
worth, my database hardly contains any data. Since it never seems to finish,
I'm not able to generate a execute plan for it to see what the problem is.
The good query:
SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn], a.[ModifiedBy],
a.[Tag], a.[FileCount]
FROM tblRECORDS a
WHERE a.[ID] IN (
SELECT a.[ID]
FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
ON a.[Id] = f.[RecordId]
WHERE
(
(
(
(
b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
b.[Keywords] LIKE 'Dit %' ESCAPE '~'
)
AND
(
c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
c.[Keywords] LIKE 'de %' ESCAPE '~'
)
AND
(
d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
)
AND
(
e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
e.[Keywords] LIKE 'eerste %' ESCAPE '~'
)
AND
(
f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
f.[Keywords] LIKE 'optie %' ESCAPE '~'
)
)
OR
(
(
b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
b.[Keywords] LIKE 'Dit %' ESCAPE '~'
)
AND
(
c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
c.[Keywords] LIKE 'de %' ESCAPE '~'
)
AND
(
d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
)
AND
(
e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
e.[Keywords] LIKE 'eerste %' ESCAPE '~'
)
AND
(
f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
f.[Keywords] LIKE 'optie %' ESCAPE '~'
)
)
) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
)
)
The bad query:
exec sp_executesql N'
SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
a.[ModifiedBy], a.[Tag], a.[FileCount]
FROM tblRECORDS a
WHERE a.[ID] IN
(
SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
ON a.[Id] = f.[RecordId]
WHERE
(
(
(
(
b.[LanguageId] = @.__0
AND
b.[Keywords] LIKE @.__1 ESCAPE ''~''
)
AND
(
c.[LanguageId] = @.__2
AND
c.[Keywords] LIKE @.__3 ESCAPE ''~''
)
AND
(
d.[LanguageId] = @.__4
AND
d.[Keywords] LIKE @.__5 ESCAPE ''~''
)
AND
(
e.[LanguageId] = @.__6
AND
e.[Keywords] LIKE @.__7 ESCAPE ''~''
)
AND
(
f.[LanguageId] = @.__8
AND
f.[Keywords] LIKE @.__9 ESCAPE ''~''
)
)
OR
(
(
b.[LanguageId] = @.__10
AND
b.[Keywords] LIKE @.__11 ESCAPE ''~''
)
AND
(
c.[LanguageId] = @.__12
AND
c.[Keywords] LIKE @.__13 ESCAPE ''~''
)
AND
(
d.[LanguageId] = @.__14
AND
d.[Keywords] LIKE @.__15 ESCAPE ''~''
)
AND
(
e.[LanguageId] = @.__16
AND
e.[Keywords] LIKE @.__17 ESCAPE ''~''
)
AND
(
f.[LanguageId] = @.__18
AND
f.[Keywords] LIKE @.__19 ESCAPE ''~''
)
)
)
AND
a.[ID] = @.__20
)
)',
N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
nvarchar(4),
@.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
nvarchar(8),
@.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
nvarchar(5),
@.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
nvarchar(13),
@.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
nvarchar(7),
@.__20
uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %',
@.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
@.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
@.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
@.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
@.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
@.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
@.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
@.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
@.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
@.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'Michael Vanhoutte wrote:
> I have a weird problem in Sql Server 2005 that I need some help on. Below
> you'll find two queries. Both queries are exactly the same; they query the
> same database, query for the same info, same sql statement, same where
> clause... The first query (the one with all the parameters included in the
> sql statement) runs perfectly against my database in less than a second. The
> second query is as I've said exactly the same, the only difference is that
> the parameters are now passed using the SqlCommand.Parameters-collection. The
> problem with this query is that it seems to cause Sql Server to hang. It
> seems to execute my query (CPU varies between 70% and 100%) but it never
> finishes. Last time I cancelled it after +20 minutes. Does anybody why I see
> this behavior? Is there something that I can do about it? For what it's
> worth, my database hardly contains any data. Since it never seems to finish,
> I'm not able to generate a execute plan for it to see what the problem is.
> The good query:
> SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn], a.[ModifiedBy],
> a.[Tag], a.[FileCount]
> FROM tblRECORDS a
> WHERE a.[ID] IN (
> SELECT a.[ID]
> FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> ON a.[Id] = f.[RecordId]
> WHERE
> (
> (
> (
> (
> b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> )
> AND
> (
> c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> c.[Keywords] LIKE 'de %' ESCAPE '~'
> )
> AND
> (
> d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> )
> AND
> (
> e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> )
> AND
> (
> f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> f.[Keywords] LIKE 'optie %' ESCAPE '~'
> )
> )
> OR
> (
> (
> b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> )
> AND
> (
> c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> c.[Keywords] LIKE 'de %' ESCAPE '~'
> )
> AND
> (
> d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> )
> AND
> (
> e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> )
> AND
> (
> f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> f.[Keywords] LIKE 'optie %' ESCAPE '~'
> )
> )
> ) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
> )
> )
> The bad query:
> exec sp_executesql N'
> SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
> a.[ModifiedBy], a.[Tag], a.[FileCount]
> FROM tblRECORDS a
> WHERE a.[ID] IN
> (
> SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> ON a.[Id] = f.[RecordId]
> WHERE
> (
> (
> (
> (
> b.[LanguageId] = @.__0
> AND
> b.[Keywords] LIKE @.__1 ESCAPE ''~''
> )
> AND
> (
> c.[LanguageId] = @.__2
> AND
> c.[Keywords] LIKE @.__3 ESCAPE ''~''
> )
> AND
> (
> d.[LanguageId] = @.__4
> AND
> d.[Keywords] LIKE @.__5 ESCAPE ''~''
> )
> AND
> (
> e.[LanguageId] = @.__6
> AND
> e.[Keywords] LIKE @.__7 ESCAPE ''~''
> )
> AND
> (
> f.[LanguageId] = @.__8
> AND
> f.[Keywords] LIKE @.__9 ESCAPE ''~''
> )
> )
> OR
> (
> (
> b.[LanguageId] = @.__10
> AND
> b.[Keywords] LIKE @.__11 ESCAPE ''~''
> )
> AND
> (
> c.[LanguageId] = @.__12
> AND
> c.[Keywords] LIKE @.__13 ESCAPE ''~''
> )
> AND
> (
> d.[LanguageId] = @.__14
> AND
> d.[Keywords] LIKE @.__15 ESCAPE ''~''
> )
> AND
> (
> e.[LanguageId] = @.__16
> AND
> e.[Keywords] LIKE @.__17 ESCAPE ''~''
> )
> AND
> (
> f.[LanguageId] = @.__18
> AND
> f.[Keywords] LIKE @.__19 ESCAPE ''~''
> )
> )
> )
> AND
> a.[ID] = @.__20
> )
> )',
> N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
> nvarchar(4),
> @.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
> nvarchar(8),
> @.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
> nvarchar(5),
> @.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
> nvarchar(13),
> @.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
> nvarchar(7),
> @.__20
> uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %',
> @.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
> @.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
> @.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
> @.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
> @.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
> @.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
> @.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
> @.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
> @.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
> @.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'
Do a Google search for "parameter sniffing"
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Hi Tracy,
Thanks for your reply. First of all, sorry for the brilliant typo in my
subject. I only noticed that now. ;-)
I see where you're going with your answer. I know that Sql Server caches the
execution plan of a query and that you might sometimes get a slower response
if it happens to use an execution plan that is not optimal for your
parameters.
However, I wonder if there's not something more going on here. The reason
why I'm saying this is that my table hardly contains any data. The biggest
table involved in my query contains a few dozen records. I mean that
literally: 61 records to be exact. There are a few other tables involved in
the view but they contain even fewer records. Most less than 10. So, even if
the execution plan would be completely wrong and Sql Server would use table
scans for everything, it should still finish instantaneously. Could the
impact really be this bad that it takes +20 minutes to query and join a few
tables that all contain less than 100 rows?
By the way, I have tried using RECOMPILE and the query does seem to run at
normal speed now.
Regards,
Michael
"Tracy McKibben" wrote:
> Michael Vanhoutte wrote:
> > I have a weird problem in Sql Server 2005 that I need some help on. Below
> > you'll find two queries. Both queries are exactly the same; they query the
> > same database, query for the same info, same sql statement, same where
> > clause... The first query (the one with all the parameters included in the
> > sql statement) runs perfectly against my database in less than a second. The
> > second query is as I've said exactly the same, the only difference is that
> > the parameters are now passed using the SqlCommand.Parameters-collection. The
> > problem with this query is that it seems to cause Sql Server to hang. It
> > seems to execute my query (CPU varies between 70% and 100%) but it never
> > finishes. Last time I cancelled it after +20 minutes. Does anybody why I see
> > this behavior? Is there something that I can do about it? For what it's
> > worth, my database hardly contains any data. Since it never seems to finish,
> > I'm not able to generate a execute plan for it to see what the problem is.
> >
> > The good query:
> > SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn], a.[ModifiedBy],
> > a.[Tag], a.[FileCount]
> > FROM tblRECORDS a
> > WHERE a.[ID] IN (
> > SELECT a.[ID]
> > FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> > ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> > ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> > ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> > ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> > ON a.[Id] = f.[RecordId]
> > WHERE
> > (
> > (
> > (
> > (
> > b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> > )
> > AND
> > (
> > c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > c.[Keywords] LIKE 'de %' ESCAPE '~'
> > )
> > AND
> > (
> > d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> > )
> > AND
> > (
> > e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> > )
> > AND
> > (
> > f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> > AND
> > f.[Keywords] LIKE 'optie %' ESCAPE '~'
> > )
> > )
> > OR
> > (
> > (
> > b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> > )
> > AND
> > (
> > c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > c.[Keywords] LIKE 'de %' ESCAPE '~'
> > )
> > AND
> > (
> > d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> > )
> > AND
> > (
> > e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> > )
> > AND
> > (
> > f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> > AND
> > f.[Keywords] LIKE 'optie %' ESCAPE '~'
> > )
> > )
> > ) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
> > )
> > )
> >
> > The bad query:
> > exec sp_executesql N'
> > SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
> > a.[ModifiedBy], a.[Tag], a.[FileCount]
> > FROM tblRECORDS a
> > WHERE a.[ID] IN
> > (
> > SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> > ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> > ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> > ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> > ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> > ON a.[Id] = f.[RecordId]
> > WHERE
> > (
> > (
> > (
> > (
> > b.[LanguageId] = @.__0
> > AND
> > b.[Keywords] LIKE @.__1 ESCAPE ''~''
> > )
> > AND
> > (
> > c.[LanguageId] = @.__2
> > AND
> > c.[Keywords] LIKE @.__3 ESCAPE ''~''
> > )
> > AND
> > (
> > d.[LanguageId] = @.__4
> > AND
> > d.[Keywords] LIKE @.__5 ESCAPE ''~''
> > )
> > AND
> > (
> > e.[LanguageId] = @.__6
> > AND
> > e.[Keywords] LIKE @.__7 ESCAPE ''~''
> > )
> > AND
> > (
> > f.[LanguageId] = @.__8
> > AND
> > f.[Keywords] LIKE @.__9 ESCAPE ''~''
> > )
> > )
> > OR
> > (
> > (
> > b.[LanguageId] = @.__10
> > AND
> > b.[Keywords] LIKE @.__11 ESCAPE ''~''
> > )
> > AND
> > (
> > c.[LanguageId] = @.__12
> > AND
> > c.[Keywords] LIKE @.__13 ESCAPE ''~''
> > )
> > AND
> > (
> > d.[LanguageId] = @.__14
> > AND
> > d.[Keywords] LIKE @.__15 ESCAPE ''~''
> > )
> > AND
> > (
> > e.[LanguageId] = @.__16
> > AND
> > e.[Keywords] LIKE @.__17 ESCAPE ''~''
> > )
> > AND
> > (
> > f.[LanguageId] = @.__18
> > AND
> > f.[Keywords] LIKE @.__19 ESCAPE ''~''
> > )
> > )
> > )
> > AND
> > a.[ID] = @.__20
> > )
> > )',
> > N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
> > nvarchar(4),
> > @.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
> > nvarchar(8),
> > @.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
> > nvarchar(5),
> > @.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
> > nvarchar(13),
> > @.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
> > nvarchar(7),
> > @.__20
> > uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %',
> > @.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
> > @.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
> > @.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
> > @.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
> > @.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
> > @.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
> > @.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
> > @.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
> > @.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
> > @.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'
> Do a Google search for "parameter sniffing"
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Michael Vanhoutte wrote:
> Hi Tracy,
> Thanks for your reply. First of all, sorry for the brilliant typo in my
> subject. I only noticed that now. ;-)
> I see where you're going with your answer. I know that Sql Server caches the
> execution plan of a query and that you might sometimes get a slower response
> if it happens to use an execution plan that is not optimal for your
> parameters.
> However, I wonder if there's not something more going on here. The reason
> why I'm saying this is that my table hardly contains any data. The biggest
> table involved in my query contains a few dozen records. I mean that
> literally: 61 records to be exact. There are a few other tables involved in
> the view but they contain even fewer records. Most less than 10. So, even if
> the execution plan would be completely wrong and Sql Server would use table
> scans for everything, it should still finish instantaneously. Could the
> impact really be this bad that it takes +20 minutes to query and join a few
> tables that all contain less than 100 rows?
> By the way, I have tried using RECOMPILE and the query does seem to run at
> normal speed now.
20 minutes does seem excessive for such little data, but it's still not
impossible to believe. Worst case, as you said, is that the execution
plan is so bad that it falls down to doing full table scans on all the
involved tables. That makes you vulnerable to a couple of things:
1. Blocking - you don't say how busy these tables are, so this is
speculation. Assuming that other processes are using these tables, your
table scans could be blocked. Even SELECTs can place locks on a table,
and those locks will interfere with a scan.
2. Resource contention - without knowing your hardware specs, this is
also speculation. If the server is extremely tight on memory, these
tables might have to be read from disk when the scan occurs. If your
drives are I/O bound, these reads will be affected.
There could be something other than parameter sniffing at work here, but
based on the symptoms, I'm going to stick with that as my answer.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Today, I wanted to update my code to include the RECOMPILE-option in the
query but the first time I executed the query with the RECOMPILE-option on, I
noticed that it again took forever to run. I have let it run for over two and
a half hours now and it is still busy, so I'm guessing that something else is
going on.
Some more info:
1. The query runs against the Sql Server on my laptop. I have plenty of
memory available when the query starts and my Sql Server is not used at all
except to run this query. No other users are connected.
2. Before the query starts, Sql Server is using about 150MB of RAM (of the
1,5GB that I have on my laptop) and after a couple of minutes, the memory
used by Sql Server increases up to more than 1GB. So, memory usage to run
this particular query is enormous. This is weird because as I've said it
queries tables that almost don't contain any records and it should return a
single record in the end.
3. I have checked in Activity Monitor while the query is running and there
are no blocking or blocked processes.
4. Also, the Sql Server process is constantly using CPU, with an average of
about 25% during the last two hours.
5. I have constant disc activity while the query is running
6. My laptop is simply not usable anymore while the query is running. Sql
Server is using so much memory and disc activity that anything I try to do
takes ages.
Any other insights on what might be causing this problem?
"Tracy McKibben" wrote:
> Michael Vanhoutte wrote:
> > Hi Tracy,
> >
> > Thanks for your reply. First of all, sorry for the brilliant typo in my
> > subject. I only noticed that now. ;-)
> >
> > I see where you're going with your answer. I know that Sql Server caches the
> > execution plan of a query and that you might sometimes get a slower response
> > if it happens to use an execution plan that is not optimal for your
> > parameters.
> >
> > However, I wonder if there's not something more going on here. The reason
> > why I'm saying this is that my table hardly contains any data. The biggest
> > table involved in my query contains a few dozen records. I mean that
> > literally: 61 records to be exact. There are a few other tables involved in
> > the view but they contain even fewer records. Most less than 10. So, even if
> > the execution plan would be completely wrong and Sql Server would use table
> > scans for everything, it should still finish instantaneously. Could the
> > impact really be this bad that it takes +20 minutes to query and join a few
> > tables that all contain less than 100 rows?
> >
> > By the way, I have tried using RECOMPILE and the query does seem to run at
> > normal speed now.
> 20 minutes does seem excessive for such little data, but it's still not
> impossible to believe. Worst case, as you said, is that the execution
> plan is so bad that it falls down to doing full table scans on all the
> involved tables. That makes you vulnerable to a couple of things:
> 1. Blocking - you don't say how busy these tables are, so this is
> speculation. Assuming that other processes are using these tables, your
> table scans could be blocked. Even SELECTs can place locks on a table,
> and those locks will interfere with a scan.
> 2. Resource contention - without knowing your hardware specs, this is
> also speculation. If the server is extremely tight on memory, these
> tables might have to be read from disk when the scan occurs. If your
> drives are I/O bound, these reads will be affected.
> There could be something other than parameter sniffing at work here, but
> based on the symptoms, I'm going to stick with that as my answer.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Michael Vanhoutte wrote:
> Today, I wanted to update my code to include the RECOMPILE-option in the
> query but the first time I executed the query with the RECOMPILE-option on, I
> noticed that it again took forever to run. I have let it run for over two and
> a half hours now and it is still busy, so I'm guessing that something else is
> going on.
> Some more info:
> 1. The query runs against the Sql Server on my laptop. I have plenty of
> memory available when the query starts and my Sql Server is not used at all
> except to run this query. No other users are connected.
> 2. Before the query starts, Sql Server is using about 150MB of RAM (of the
> 1,5GB that I have on my laptop) and after a couple of minutes, the memory
> used by Sql Server increases up to more than 1GB. So, memory usage to run
> this particular query is enormous. This is weird because as I've said it
> queries tables that almost don't contain any records and it should return a
> single record in the end.
> 3. I have checked in Activity Monitor while the query is running and there
> are no blocking or blocked processes.
> 4. Also, the Sql Server process is constantly using CPU, with an average of
> about 25% during the last two hours.
> 5. I have constant disc activity while the query is running
> 6. My laptop is simply not usable anymore while the query is running. Sql
> Server is using so much memory and disc activity that anything I try to do
> takes ages.
> Any other insights on what might be causing this problem?
>
You should probably try to get a Profiler trace to see what SQL is doing
while the machine is getting hammered...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I don't believe it... I wanted to run a more detailed profiler trace today to
get some more information. I had already run a default trace earlier, but all
that got me was an RPC Starting-event with the Sql statement that was in my
report. Today, I activated ALL events in profiler and I started the query.
Guess what? I can't reproduce the problem anymore! Nothing has changed as far
as data, structure, queries... I'm guessing that Sql Server automatically
updated some statistics which causes it to use a different execution plan.
This morning, I said to myself to take a backup of the database while the
problem is still there, but apparently I'm too late. We'll see in the coming
days if the problem comes back. Thanks for your help so far!
"Tracy McKibben" wrote:
> Michael Vanhoutte wrote:
> > Today, I wanted to update my code to include the RECOMPILE-option in the
> > query but the first time I executed the query with the RECOMPILE-option on, I
> > noticed that it again took forever to run. I have let it run for over two and
> > a half hours now and it is still busy, so I'm guessing that something else is
> > going on.
> >
> > Some more info:
> > 1. The query runs against the Sql Server on my laptop. I have plenty of
> > memory available when the query starts and my Sql Server is not used at all
> > except to run this query. No other users are connected.
> > 2. Before the query starts, Sql Server is using about 150MB of RAM (of the
> > 1,5GB that I have on my laptop) and after a couple of minutes, the memory
> > used by Sql Server increases up to more than 1GB. So, memory usage to run
> > this particular query is enormous. This is weird because as I've said it
> > queries tables that almost don't contain any records and it should return a
> > single record in the end.
> > 3. I have checked in Activity Monitor while the query is running and there
> > are no blocking or blocked processes.
> > 4. Also, the Sql Server process is constantly using CPU, with an average of
> > about 25% during the last two hours.
> > 5. I have constant disc activity while the query is running
> > 6. My laptop is simply not usable anymore while the query is running. Sql
> > Server is using so much memory and disc activity that anything I try to do
> > takes ages.
> >
> > Any other insights on what might be causing this problem?
> >
> You should probably try to get a Profiler trace to see what SQL is doing
> while the machine is getting hammered...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Michael Vanhoutte wrote:
> I don't believe it... I wanted to run a more detailed profiler trace today to
> get some more information. I had already run a default trace earlier, but all
> that got me was an RPC Starting-event with the Sql statement that was in my
> report. Today, I activated ALL events in profiler and I started the query.
> Guess what? I can't reproduce the problem anymore! Nothing has changed as far
> as data, structure, queries... I'm guessing that Sql Server automatically
> updated some statistics which causes it to use a different execution plan.
> This morning, I said to myself to take a backup of the database while the
> problem is still there, but apparently I'm too late. We'll see in the coming
> days if the problem comes back. Thanks for your help so far!
>
If you have auto-stats enabled, or run a scheduled stats update, that
very well could be what happened. Or, it could have been an inefficient
query plan that was cached, and has since dropped out of the cache.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Query doesn't hangs when run using parameters
I have a weird problem in Sql Server 2005 that I need some help on. Below
you'll find two queries. Both queries are exactly the same; they query the
same database, query for the same info, same sql statement, same where
clause... The first query (the one with all the parameters included in the
sql statement) runs perfectly against my database in less than a second. The
second query is as I've said exactly the same, the only difference is that
the parameters are now passed using the SqlCommand.Parameters-collection. Th
e
problem with this query is that it seems to cause Sql Server to hang. It
seems to execute my query (CPU varies between 70% and 100%) but it never
finishes. Last time I cancelled it after +20 minutes. Does anybody why I see
this behavior? Is there something that I can do about it? For what it's
worth, my database hardly contains any data. Since it never seems to finish,
I'm not able to generate a execute plan for it to see what the problem is.
The good query:
SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
a.[ModifiedBy],
a.[Tag], a.[FileCount]
FROM tblRECORDS a
WHERE a.[ID] IN (
SELECT a.[ID]
FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
ON a.[Id] = f.[RecordId]
WHERE
(
(
(
(
b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
b.[Keywords] LIKE 'Dit %' ESCAPE '~'
)
AND
(
c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
c.[Keywords] LIKE 'de %' ESCAPE '~'
)
AND
(
d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
)
AND
(
e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
e.[Keywords] LIKE 'eerste %' ESCAPE '~'
)
AND
(
f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
f.[Keywords] LIKE 'optie %' ESCAPE '~'
)
)
OR
(
(
b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
b.[Keywords] LIKE 'Dit %' ESCAPE '~'
)
AND
(
c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
c.[Keywords] LIKE 'de %' ESCAPE '~'
)
AND
(
d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
)
AND
(
e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
e.[Keywords] LIKE 'eerste %' ESCAPE '~'
)
AND
(
f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
f.[Keywords] LIKE 'optie %' ESCAPE '~'
)
)
) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
)
)
The bad query:
exec sp_executesql N'
SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
a.[ModifiedBy], a.[Tag], a.[FileCount]
FROM tblRECORDS a
WHERE a.[ID] IN
(
SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
ON a.[Id] = f.[RecordId]
WHERE
(
(
(
(
b.[LanguageId] = @.__0
AND
b.[Keywords] LIKE @.__1 ESCAPE ''~''
)
AND
(
c.[LanguageId] = @.__2
AND
c.[Keywords] LIKE @.__3 ESCAPE ''~''
)
AND
(
d.[LanguageId] = @.__4
AND
d.[Keywords] LIKE @.__5 ESCAPE ''~''
)
AND
(
e.[LanguageId] = @.__6
AND
e.[Keywords] LIKE @.__7 ESCAPE ''~''
)
AND
(
f.[LanguageId] = @.__8
AND
f.[Keywords] LIKE @.__9 ESCAPE ''~''
)
)
OR
(
(
b.[LanguageId] = @.__10
AND
b.[Keywords] LIKE @.__11 ESCAPE ''~''
)
AND
(
c.[LanguageId] = @.__12
AND
c.[Keywords] LIKE @.__13 ESCAPE ''~''
)
AND
(
d.[LanguageId] = @.__14
AND
d.[Keywords] LIKE @.__15 ESCAPE ''~''
)
AND
(
e.[LanguageId] = @.__16
AND
e.[Keywords] LIKE @.__17 ESCAPE ''~''
)
AND
(
f.[LanguageId] = @.__18
AND
f.[Keywords] LIKE @.__19 ESCAPE ''~''
)
)
)
AND
a.[ID] = @.__20
)
)',
N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
nvarchar(4),
@.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
nvarchar(8),
@.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
nvarchar(5),
@.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
nvarchar(13),
@.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
nvarchar(7),
@.__20
uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %',
@.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
@.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
@.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
@.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
@.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
@.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
@.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
@.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
@.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
@.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'Michael Vanhoutte wrote:
> I have a weird problem in Sql Server 2005 that I need some help on. Below
> you'll find two queries. Both queries are exactly the same; they query the
> same database, query for the same info, same sql statement, same where
> clause... The first query (the one with all the parameters included in the
> sql statement) runs perfectly against my database in less than a second. T
he
> second query is as I've said exactly the same, the only difference is that
> the parameters are now passed using the SqlCommand.Parameters-collection.
The
> problem with this query is that it seems to cause Sql Server to hang. It
> seems to execute my query (CPU varies between 70% and 100%) but it never
> finishes. Last time I cancelled it after +20 minutes. Does anybody why I s
ee
> this behavior? Is there something that I can do about it? For what it's
> worth, my database hardly contains any data. Since it never seems to finis
h,
> I'm not able to generate a execute plan for it to see what the problem is.
> The good query:
> SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn
], a.[ModifiedBy],
> a.[Tag], a.[FileCount]
> FROM tblRECORDS a
> WHERE a.[ID] IN (
> SELECT a.[ID]
> FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> ON a.[Id] = f.[RecordId]
> WHERE
> (
> (
> (
> (
> b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> )
> AND
> (
> c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> c.[Keywords] LIKE 'de %' ESCAPE '~'
> )
> AND
> (
> d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> )
> AND
> (
> e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> )
> AND
> (
> f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> f.[Keywords] LIKE 'optie %' ESCAPE '~'
> )
> )
> OR
> (
> (
> b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> )
> AND
> (
> c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> c.[Keywords] LIKE 'de %' ESCAPE '~'
> )
> AND
> (
> d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> )
> AND
> (
> e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> )
> AND
> (
> f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> f.[Keywords] LIKE 'optie %' ESCAPE '~'
> )
> )
> ) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
> )
> )
> The bad query:
> exec sp_executesql N'
> SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedO
n],
> a.[ModifiedBy], a.[Tag], a.[FileCount]
> FROM tblRECORDS a
> WHERE a.[ID] IN
> (
> SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> ON a.[Id] = f.[RecordId]
> WHERE
> (
> (
> (
> (
> b.[LanguageId] = @.__0
> AND
> b.[Keywords] LIKE @.__1 ESCAPE ''~''
> )
> AND
> (
> c.[LanguageId] = @.__2
> AND
> c.[Keywords] LIKE @.__3 ESCAPE ''~''
> )
> AND
> (
> d.[LanguageId] = @.__4
> AND
> d.[Keywords] LIKE @.__5 ESCAPE ''~''
> )
> AND
> (
> e.[LanguageId] = @.__6
> AND
> e.[Keywords] LIKE @.__7 ESCAPE ''~''
> )
> AND
> (
> f.[LanguageId] = @.__8
> AND
> f.[Keywords] LIKE @.__9 ESCAPE ''~''
> )
> )
> OR
> (
> (
> b.[LanguageId] = @.__10
> AND
> b.[Keywords] LIKE @.__11 ESCAPE ''~''
> )
> AND
> (
> c.[LanguageId] = @.__12
> AND
> c.[Keywords] LIKE @.__13 ESCAPE ''~''
> )
> AND
> (
> d.[LanguageId] = @.__14
> AND
> d.[Keywords] LIKE @.__15 ESCAPE ''~''
> )
> AND
> (
> e.[LanguageId] = @.__16
> AND
> e.[Keywords] LIKE @.__17 ESCAPE ''~''
> )
> AND
> (
> f.[LanguageId] = @.__18
> AND
> f.[Keywords] LIKE @.__19 ESCAPE ''~''
> )
> )
> )
> AND
> a.[ID] = @.__20
> )
> )',
> N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
> nvarchar(4),
> @.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
> nvarchar(8),
> @.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
> nvarchar(5),
> @.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
> nvarchar(13),
> @.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
> nvarchar(7),
> @.__20
> uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %
',
> @.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
> @.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
> @.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
> @.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
> @.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
> @.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
> @.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
> @.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
> @.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
> @.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'
Do a Google search for "parameter sniffing"
Tracy McKibben
MCDBA
http://www.realsqlguy.com
you'll find two queries. Both queries are exactly the same; they query the
same database, query for the same info, same sql statement, same where
clause... The first query (the one with all the parameters included in the
sql statement) runs perfectly against my database in less than a second. The
second query is as I've said exactly the same, the only difference is that
the parameters are now passed using the SqlCommand.Parameters-collection. Th
e
problem with this query is that it seems to cause Sql Server to hang. It
seems to execute my query (CPU varies between 70% and 100%) but it never
finishes. Last time I cancelled it after +20 minutes. Does anybody why I see
this behavior? Is there something that I can do about it? For what it's
worth, my database hardly contains any data. Since it never seems to finish,
I'm not able to generate a execute plan for it to see what the problem is.
The good query:
SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
a.[ModifiedBy],
a.[Tag], a.[FileCount]
FROM tblRECORDS a
WHERE a.[ID] IN (
SELECT a.[ID]
FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
ON a.[Id] = f.[RecordId]
WHERE
(
(
(
(
b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
b.[Keywords] LIKE 'Dit %' ESCAPE '~'
)
AND
(
c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
c.[Keywords] LIKE 'de %' ESCAPE '~'
)
AND
(
d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
)
AND
(
e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
e.[Keywords] LIKE 'eerste %' ESCAPE '~'
)
AND
(
f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
AND
f.[Keywords] LIKE 'optie %' ESCAPE '~'
)
)
OR
(
(
b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
b.[Keywords] LIKE 'Dit %' ESCAPE '~'
)
AND
(
c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
c.[Keywords] LIKE 'de %' ESCAPE '~'
)
AND
(
d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
)
AND
(
e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
e.[Keywords] LIKE 'eerste %' ESCAPE '~'
)
AND
(
f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
AND
f.[Keywords] LIKE 'optie %' ESCAPE '~'
)
)
) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
)
)
The bad query:
exec sp_executesql N'
SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn],
a.[ModifiedBy], a.[Tag], a.[FileCount]
FROM tblRECORDS a
WHERE a.[ID] IN
(
SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
ON a.[Id] = f.[RecordId]
WHERE
(
(
(
(
b.[LanguageId] = @.__0
AND
b.[Keywords] LIKE @.__1 ESCAPE ''~''
)
AND
(
c.[LanguageId] = @.__2
AND
c.[Keywords] LIKE @.__3 ESCAPE ''~''
)
AND
(
d.[LanguageId] = @.__4
AND
d.[Keywords] LIKE @.__5 ESCAPE ''~''
)
AND
(
e.[LanguageId] = @.__6
AND
e.[Keywords] LIKE @.__7 ESCAPE ''~''
)
AND
(
f.[LanguageId] = @.__8
AND
f.[Keywords] LIKE @.__9 ESCAPE ''~''
)
)
OR
(
(
b.[LanguageId] = @.__10
AND
b.[Keywords] LIKE @.__11 ESCAPE ''~''
)
AND
(
c.[LanguageId] = @.__12
AND
c.[Keywords] LIKE @.__13 ESCAPE ''~''
)
AND
(
d.[LanguageId] = @.__14
AND
d.[Keywords] LIKE @.__15 ESCAPE ''~''
)
AND
(
e.[LanguageId] = @.__16
AND
e.[Keywords] LIKE @.__17 ESCAPE ''~''
)
AND
(
f.[LanguageId] = @.__18
AND
f.[Keywords] LIKE @.__19 ESCAPE ''~''
)
)
)
AND
a.[ID] = @.__20
)
)',
N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
nvarchar(4),
@.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
nvarchar(8),
@.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
nvarchar(5),
@.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
nvarchar(13),
@.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
nvarchar(7),
@.__20
uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %',
@.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
@.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
@.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
@.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
@.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
@.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
@.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
@.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
@.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
@.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'Michael Vanhoutte wrote:
> I have a weird problem in Sql Server 2005 that I need some help on. Below
> you'll find two queries. Both queries are exactly the same; they query the
> same database, query for the same info, same sql statement, same where
> clause... The first query (the one with all the parameters included in the
> sql statement) runs perfectly against my database in less than a second. T
he
> second query is as I've said exactly the same, the only difference is that
> the parameters are now passed using the SqlCommand.Parameters-collection.
The
> problem with this query is that it seems to cause Sql Server to hang. It
> seems to execute my query (CPU varies between 70% and 100%) but it never
> finishes. Last time I cancelled it after +20 minutes. Does anybody why I s
ee
> this behavior? Is there something that I can do about it? For what it's
> worth, my database hardly contains any data. Since it never seems to finis
h,
> I'm not able to generate a execute plan for it to see what the problem is.
> The good query:
> SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedOn
], a.[ModifiedBy],
> a.[Tag], a.[FileCount]
> FROM tblRECORDS a
> WHERE a.[ID] IN (
> SELECT a.[ID]
> FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> ON a.[Id] = f.[RecordId]
> WHERE
> (
> (
> (
> (
> b.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> )
> AND
> (
> c.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> c.[Keywords] LIKE 'de %' ESCAPE '~'
> )
> AND
> (
> d.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> )
> AND
> (
> e.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> )
> AND
> (
> f.[LanguageId] = 'c2bd4f9b-bb95-4bcb-80c3-1e924c9c26dc'
> AND
> f.[Keywords] LIKE 'optie %' ESCAPE '~'
> )
> )
> OR
> (
> (
> b.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> b.[Keywords] LIKE 'Dit %' ESCAPE '~'
> )
> AND
> (
> c.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> c.[Keywords] LIKE 'de %' ESCAPE '~'
> )
> AND
> (
> d.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> d.[Keywords] LIKE 'nederlandse %' ESCAPE '~'
> )
> AND
> (
> e.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> e.[Keywords] LIKE 'eerste %' ESCAPE '~'
> )
> AND
> (
> f.[LanguageId] = '00000000-0000-0000-0000-000000000000'
> AND
> f.[Keywords] LIKE 'optie %' ESCAPE '~'
> )
> )
> ) AND a.[ID] = 'a6ff3da9-6618-4f62-9a24-79aad5e755ca'
> )
> )
> The bad query:
> exec sp_executesql N'
> SELECT a.[ID], a.[CreatedOn], a.[CreatedBy], a.[ModifiedO
n],
> a.[ModifiedBy], a.[Tag], a.[FileCount]
> FROM tblRECORDS a
> WHERE a.[ID] IN
> (
> SELECT a.[ID] FROM tblRECORDS a INNER JOIN getRECORDFULLTEXT b
> ON a.[Id] = b.[RecordId] INNER JOIN getRECORDFULLTEXT c
> ON a.[Id] = c.[RecordId] INNER JOIN getRECORDFULLTEXT d
> ON a.[Id] = d.[RecordId] INNER JOIN getRECORDFULLTEXT e
> ON a.[Id] = e.[RecordId] INNER JOIN getRECORDFULLTEXT f
> ON a.[Id] = f.[RecordId]
> WHERE
> (
> (
> (
> (
> b.[LanguageId] = @.__0
> AND
> b.[Keywords] LIKE @.__1 ESCAPE ''~''
> )
> AND
> (
> c.[LanguageId] = @.__2
> AND
> c.[Keywords] LIKE @.__3 ESCAPE ''~''
> )
> AND
> (
> d.[LanguageId] = @.__4
> AND
> d.[Keywords] LIKE @.__5 ESCAPE ''~''
> )
> AND
> (
> e.[LanguageId] = @.__6
> AND
> e.[Keywords] LIKE @.__7 ESCAPE ''~''
> )
> AND
> (
> f.[LanguageId] = @.__8
> AND
> f.[Keywords] LIKE @.__9 ESCAPE ''~''
> )
> )
> OR
> (
> (
> b.[LanguageId] = @.__10
> AND
> b.[Keywords] LIKE @.__11 ESCAPE ''~''
> )
> AND
> (
> c.[LanguageId] = @.__12
> AND
> c.[Keywords] LIKE @.__13 ESCAPE ''~''
> )
> AND
> (
> d.[LanguageId] = @.__14
> AND
> d.[Keywords] LIKE @.__15 ESCAPE ''~''
> )
> AND
> (
> e.[LanguageId] = @.__16
> AND
> e.[Keywords] LIKE @.__17 ESCAPE ''~''
> )
> AND
> (
> f.[LanguageId] = @.__18
> AND
> f.[Keywords] LIKE @.__19 ESCAPE ''~''
> )
> )
> )
> AND
> a.[ID] = @.__20
> )
> )',
> N'@.__0 uniqueidentifier,@.__1 nvarchar(5),@.__2 uniqueidentifier,@.__3
> nvarchar(4),
> @.__4 uniqueidentifier,@.__5 nvarchar(13),@.__6 uniqueidentifier,@.__7
> nvarchar(8),
> @.__8 uniqueidentifier,@.__9 nvarchar(7),@.__10 uniqueidentifier,@.__11
> nvarchar(5),
> @.__12 uniqueidentifier,@.__13 nvarchar(4),@.__14 uniqueidentifier,@.__15
> nvarchar(13),
> @.__16 uniqueidentifier,@.__17 nvarchar(8),@.__18 uniqueidentifier,@.__19
> nvarchar(7),
> @.__20
> uniqueidentifier',@.__0='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__1=N'Dit %
',
> @.__2='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__3=N'de %',
> @.__4='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__5=N'nederlandse %',
> @.__6='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__7=N'eerste %',
> @.__8='C2BD4F9B-BB95-4BCB-80C3-1E924C9C26DC',@.__9=N'optie %',
> @.__10='00000000-0000-0000-0000-000000000000',@.__11=N'Dit %',
> @.__12='00000000-0000-0000-0000-000000000000',@.__13=N'de %',
> @.__14='00000000-0000-0000-0000-000000000000',@.__15=N'nederlandse %',
> @.__16='00000000-0000-0000-0000-000000000000',@.__17=N'eerste %',
> @.__18='00000000-0000-0000-0000-000000000000',@.__19=N'optie %',
> @.__20='a6ff3da9-6618-4f62-9a24-79aad5e755ca'
Do a Google search for "parameter sniffing"
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Saturday, February 25, 2012
query between 2 dates error
Having this table with sales
select * from viewcomis2 where date between '05/27/2005' and '05/30/2005'
I got this weird result:
05/27/2005
04/28/2005 <-- this is not suppose to be here
05/28/2005
05/30/2005
I solved:
((substring(datee,1,2)) >= (substring('" & DTPicker1.Value & "',1,2)) and
(substring(datee,4,2)) >= (substring('" & DTPicker1.Value & "',4,2)) and
(substring(datee,7,4)) >= (substring('" & DTPicker1.Value & "',7,4))) AND
((substring(datee,1,2)) <= (substring('" & DTPicker2.Value & "',1,2)) and
(substring(datee,4,2)) <= (substring('" & DTPicker2.Value & "',4,2)) and
(substring(datee,7,4)) <= (substring('" & DTPicker2.Value & "',7,4)))
but still: 05-27-2005 >= 04-27-2005 ?
it was the only way to solve my problem but still have not answered my
original question on why some dates from others months appeared between
5.1.2005 and 5.30.2005
ah-> datee was from a view where convert(char(10),dbo.venta.SaleDate,103)
as datee
SaleDate is Datetime type, but I need to group them by day so I converted
to char(10) in order to query between dates. I know I did something wrong
somewhere but I have no clue on what or where. Any Ideas? ThanksHi
Did you try it this way:
select * from viewcomis2 where cast(date as datetime) between '05/27/2005'
and '05/30/2005'
best Regards,
Chandra
http://chanduas.blogspot.com/
http://groups.msn.com/SQLResource/
---
"humberto gonzalez" wrote:
> Having this table with sales
> select * from viewcomis2 where date between '05/27/2005' and '05/30/2005'
> I got this weird result:
> 05/27/2005
> 04/28/2005 <-- this is not suppose to be here
> 05/28/2005
> 05/30/2005
> I solved:
> ((substring(datee,1,2)) >= (substring('" & DTPicker1.Value & "',1,2)) and
> (substring(datee,4,2)) >= (substring('" & DTPicker1.Value & "',4,2)) and
> (substring(datee,7,4)) >= (substring('" & DTPicker1.Value & "',7,4))) AND
> ((substring(datee,1,2)) <= (substring('" & DTPicker2.Value & "',1,2)) and
> (substring(datee,4,2)) <= (substring('" & DTPicker2.Value & "',4,2)) and
> (substring(datee,7,4)) <= (substring('" & DTPicker2.Value & "',7,4)))
> but still: 05-27-2005 >= 04-27-2005 ?
> it was the only way to solve my problem but still have not answered my
> original question on why some dates from others months appeared between
> 5.1.2005 and 5.30.2005
> ah-> datee was from a view where convert(char(10),dbo.venta.SaleDate,103)
> as datee
> SaleDate is Datetime type, but I need to group them by day so I converted
> to char(10) in order to query between dates. I know I did something wrong
> somewhere but I have no clue on what or where. Any Ideas? Thanks
>
select * from viewcomis2 where date between '05/27/2005' and '05/30/2005'
I got this weird result:
05/27/2005
04/28/2005 <-- this is not suppose to be here
05/28/2005
05/30/2005
I solved:
((substring(datee,1,2)) >= (substring('" & DTPicker1.Value & "',1,2)) and
(substring(datee,4,2)) >= (substring('" & DTPicker1.Value & "',4,2)) and
(substring(datee,7,4)) >= (substring('" & DTPicker1.Value & "',7,4))) AND
((substring(datee,1,2)) <= (substring('" & DTPicker2.Value & "',1,2)) and
(substring(datee,4,2)) <= (substring('" & DTPicker2.Value & "',4,2)) and
(substring(datee,7,4)) <= (substring('" & DTPicker2.Value & "',7,4)))
but still: 05-27-2005 >= 04-27-2005 ?
it was the only way to solve my problem but still have not answered my
original question on why some dates from others months appeared between
5.1.2005 and 5.30.2005
ah-> datee was from a view where convert(char(10),dbo.venta.SaleDate,103)
as datee
SaleDate is Datetime type, but I need to group them by day so I converted
to char(10) in order to query between dates. I know I did something wrong
somewhere but I have no clue on what or where. Any Ideas? ThanksHi
Did you try it this way:
select * from viewcomis2 where cast(date as datetime) between '05/27/2005'
and '05/30/2005'
best Regards,
Chandra
http://chanduas.blogspot.com/
http://groups.msn.com/SQLResource/
---
"humberto gonzalez" wrote:
> Having this table with sales
> select * from viewcomis2 where date between '05/27/2005' and '05/30/2005'
> I got this weird result:
> 05/27/2005
> 04/28/2005 <-- this is not suppose to be here
> 05/28/2005
> 05/30/2005
> I solved:
> ((substring(datee,1,2)) >= (substring('" & DTPicker1.Value & "',1,2)) and
> (substring(datee,4,2)) >= (substring('" & DTPicker1.Value & "',4,2)) and
> (substring(datee,7,4)) >= (substring('" & DTPicker1.Value & "',7,4))) AND
> ((substring(datee,1,2)) <= (substring('" & DTPicker2.Value & "',1,2)) and
> (substring(datee,4,2)) <= (substring('" & DTPicker2.Value & "',4,2)) and
> (substring(datee,7,4)) <= (substring('" & DTPicker2.Value & "',7,4)))
> but still: 05-27-2005 >= 04-27-2005 ?
> it was the only way to solve my problem but still have not answered my
> original question on why some dates from others months appeared between
> 5.1.2005 and 5.30.2005
> ah-> datee was from a view where convert(char(10),dbo.venta.SaleDate,103)
> as datee
> SaleDate is Datetime type, but I need to group them by day so I converted
> to char(10) in order to query between dates. I know I did something wrong
> somewhere but I have no clue on what or where. Any Ideas? Thanks
>
Subscribe to:
Posts (Atom)