>It seems from the responses that this not occured before.
Correct. It makes no more sense to me than it does to you.
One question I should have asked in the first place. WHICH OF THE TWO
COUNTS IS CORRECT????
Roy Harvey
Beacon Falls, CT
Ken - 22 Jul 2008 17:01 GMT
On Jul 22, 4:30 pm, "Roy Harvey (SQL Server MVP)"
<roy_har...@snet.net> wrote:
> >It seems from the responses that this not occured before.
>
[quoted text clipped - 5 lines]
> Roy Harvey
> Beacon Falls, CT
315204 is the correct count (the second one). This is the number of
records returned when the date in the select clause is NOT using
@ForDate the procedure parameter.
My guess (and it's only a guess) is that there is something wrong with one
of your indexes. It may be that when using the stored proc parameter, the
Query Optimizer chooses a different plan than it does when you use a
variable that is not a parameter (due to parameter sniffing). If that
different plan uses an index which for some reason is missing rows then you
could see this problem.
I would run either a DBCC CHECKDB to check the whole database or do a DBCC
CHECKTABLE and DBCC CHECKALLOC on every table in your view to check the
tables in the view. If finding the time to run the checks on your
production system is a problem, you could run the checks on a restored copy
of your database on another machine.
Tom
On Jul 21, 7:23 pm, "Roy Harvey (SQL Server MVP)"
<roy_har...@snet.net> wrote:
> On Mon, 21 Jul 2008 11:09:14 -0700 (PDT), Ken <ken.clo...@gmail.com>
> wrote:
[quoted text clipped - 20 lines]
> Roy Harvey
> Beacon Falls, CT
The stored procedure demonstates the problem.
@ForDate is a parameter, which recieves a default null value, is then
modified to be '2008-07-31'.
@OtherDate is assigned the value of @ForDate, they are the same date.
The two selects are the same except that the where clause uses
different variables.
The view joins two static tables. The correct number of records for
the '2008-07-31' is 315204. This is the number of records returned
when the select is run interactively, or in any other way.
Only in the case of using the parameter variable @ForDate in the where
clause does the incorrect number of records.
The original version of this procedure seems to have worked for some
time. I am not sure that I can reproduce this problem in another
database (although it is reproduced in a restored copy of the original
database).
Unfortunately I may not post the schema for the view and underlying
tables.
It seems from the responses that this not occured before. We will
continue with the workaround of using a copy of the paramter variable.
Ken
Ken - 24 Jul 2008 10:18 GMT
On Jul 22, 5:24 pm, "Tom Cooper"
<tomcoo...@comcast.no.spam.please.net> wrote:
> My guess (and it's only a guess) is that there is something wrong with one
> of your indexes. It may be that when using the stored proc parameter, the
[quoted text clipped - 70 lines]
>
> - Show quoted text -
Tom you have got to the root of the problem.
The DBCC checks brought no errors, but when I turned on the actual
query plan in the management studio and the two variations have
slightly different plans (just a nested loop,which fails, instead of a
merge join which works).
So I syntactically rearranged the joins in the view from -- A join B
join C -- to -- A join C join B -- (the joins a semantically the same)
and the problem goes away (the plans are now completely different).
Next I rebuilt all the indexes, table a has 30 million rows with a
unique clustered index, table B and C have 15 thousand rows and each
has a unique clustered index. The joins are on the indexes, table A
being a superset of B and C.
Still no luck.
Ken
Tom Cooper - 25 Jul 2008 03:52 GMT
<snip>
> Tom you have got to the root of the problem.
>
[quoted text clipped - 15 lines]
>
> Ken
I'm mostly out of ideas. Couple of other thoughts.
If the query plan that is not working uses parallelism, turn parallelism off
for this query (using query hint setting MAXDOP to 1). There were known
bugs in parallel queries in SQL 2000 SP3.
You could also try restoring a backup of this database to a server with SQL
2000 SP4 and/or SQL 2005 and/or the prerelase version of SQL 2008 and see if
the problem goes away. If it does, you can take that into your planning for
when/if you are going to move to either SP4 or SQL 2005 or SQL 2008 (when
that version is released).
You could try Microsoft support, but I don't know how much help that will be
since mainstream support for SQL 2000 ended April, 2008.
Tom
Ken - 25 Jul 2008 11:50 GMT
On Jul 25, 3:52 am, "Tom Cooper"
<tomcoo...@comcast.no.spam.please.net> wrote:
> <snip>
>
[quoted text clipped - 36 lines]
>
> - Show quoted text -
Tom
Happy Days
Sp4 fixes the problem... We had not applied it as we were anticipating
an upgrade to 2005.
(Ironically when I change the syntax of the query parallelism is
used and the problem is not apparent).
Thanks for your help.
Cheers,
Ken