Bad executed Plan and wrong Result by SQL

Hi, I didn't receive any answer about my problem. I'll repeat that!:
I have one query:
SELECT count(*) FROM SAM_GUIA_EVENTOS E,
SAM_GUIA G WHERE G.PEG= 752074
AND E.GUIA= G.HANDLE AND E.CLASSEGERENCIALPAGTO is NULL
This query, after many updates after rebuid at saturday, return column
E.CLASSEGERENCIALPAGTO with not null(many data). The execution plan mount
merger join with hash aggregate, that too lazy. I test this at monday(one day
after rebuil), but the result is correct, but when that query are executed at
middle of week, change some G.PEG values, the result is total wrong.
Plese, anyone help me to this question!Krisnamourt wrote:
> Hi, I didn't receive any answer about my problem. I'll repeat that!:
> I have one query:
> SELECT count(*) FROM SAM_GUIA_EVENTOS E,
> SAM_GUIA G WHERE G.PEG= 752074
> AND E.GUIA= G.HANDLE AND E.CLASSEGERENCIALPAGTO is NULL
> This query, after many updates after rebuid at saturday, return column
> E.CLASSEGERENCIALPAGTO with not null(many data). The execution plan
> mount merger join with hash aggregate, that too lazy. I test this at
> monday(one day after rebuil), but the result is correct, but when
> that query are executed at middle of week, change some G.PEG values,
> the result is total wrong.
> Plese, anyone help me to this question!
Could be a parallel plan issue. When using COUNT(*) it can help to add a
MAXDOP 1 to the query to avoid the possible issue:
http://support.microsoft.com/kb/822746
http://support.microsoft.com/kb/q277738/
--
David Gugick
Imceda Software
www.imceda.com|||In addition to David's reply: Service Pack 4 included a few fixes with
respect to parallelism, so installing SP4 could solve your problem.
Gert-Jan
Krisnamourt wrote:
> Hi, I didn't receive any answer about my problem. I'll repeat that!:
> I have one query:
> SELECT count(*) FROM SAM_GUIA_EVENTOS E,
> SAM_GUIA G WHERE G.PEG= 752074
> AND E.GUIA= G.HANDLE AND E.CLASSEGERENCIALPAGTO is NULL
> This query, after many updates after rebuid at saturday, return column
> E.CLASSEGERENCIALPAGTO with not null(many data). The execution plan mount
> merger join with hash aggregate, that too lazy. I test this at monday(one day
> after rebuil), but the result is correct, but when that query are executed at
> middle of week, change some G.PEG values, the result is total wrong.
> Plese, anyone help me to this question!