Very serious bug with Materialized/Indexed views and SQL server

[Vincent LIDOU]

Do not trust values returned by materialized views under SQL Server
without frequently checking underlying tables!!!

I already posted this message under microsoft.public.sqlserver.server
and I'm amazed nobody from Microsoft answered about this problem. By
inserting lots of data into our two main tables for about 30 minutes,
we can fail our materialized view that performs a count_big on those
two tables.

Executing (after of course having stopped inserting rows in our two
tables)

SELECT SUM(field1+field2+field3) FROM MatView option(expand views)
DOES NOT RETURN the same value than:
SELECT SUM(field1+field2+field3) FROM MatView with (noexpand)

The second call - using the materialized view - returns a smaller
number (as if counts were lost during our bulk insert)

As our data has to be accurate, we cannot use Materialized views
anymore. This problem does not occur when the amount of data inserted
is smaller. Rebuilding the clustered index on the view fixes the
problem; do we have to constantly be rebuilding the index to keep the
view synchronize !?!!?!

Is there a way to tell that our view is not synchronized? Just
comparing values returned by our view does not work for us as data is
constantly been inserted.

System: SQL server 2000 SP3 Enterprise Edition

Vincent LIDOU

[Simon Hayes]

"Vincent LIDOU" <vl****@laposte.net> wrote in message
news:f6**************************@posting.google.c om...

Do not trust values returned by materialized views under SQL Server
without frequently checking underlying tables!!!

I already posted this message under microsoft.public.sqlserver.server
and I'm amazed nobody from Microsoft answered about this problem. By
inserting lots of data into our two main tables for about 30 minutes,
we can fail our materialized view that performs a count_big on those
two tables.

Executing (after of course having stopped inserting rows in our two
tables)

SELECT SUM(field1+field2+field3) FROM MatView option(expand views)

DOES NOT RETURN the same value than:

SELECT SUM(field1+field2+field3) FROM MatView with (noexpand)

The second call - using the materialized view - returns a smaller
number (as if counts were lost during our bulk insert)

As our data has to be accurate, we cannot use Materialized views
anymore. This problem does not occur when the amount of data inserted
is smaller. Rebuilding the clustered index on the view fixes the
problem; do we have to constantly be rebuilding the index to keep the
view synchronize !?!!?!

Is there a way to tell that our view is not synchronized? Just
comparing values returned by our view does not work for us as data is
constantly been inserted.

System: SQL server 2000 SP3 Enterprise Edition

Vincent LIDOU

I've also used indexed views, and I've never seen this issue, but we don't
really use them the same way - we rarely update data in the underlying
tables. In any case, if you can reproduce this, then the best thing to do is
to open a support case with Microsoft - support calls due to bugs in the
product are free.

Simon

[Erland Sommarskog]

[posted and mailed, répondre en news s'il vous plaît]

Vincent LIDOU (vl****@laposte.net) writes:

Do not trust values returned by materialized views under SQL Server
without frequently checking underlying tables!!!

I already posted this message under microsoft.public.sqlserver.server
and I'm amazed nobody from Microsoft answered about this problem.

I am not. While Microsoft hosts the newsgroups, they are intended to
be peer-to-peer communites. There is one exception: if you are a
MSDN or Technet Managed Customer, you should expect an answer if
you:

1) Post to a group which is listed by MSDN or Technet as registred. (And
of course, if you are a managed MSDN customer, posting to a group
managed by Technet will not help you).
2) You post with the address you have registered with Technet or
MSDN. Since you posted your original post from the web interface
with the default address an*******@discussions.microsoft.com you
was not able to get a Technet answer anyhow.

And actually, I believe that not even in this case you may get a
Microsoft answer, if someone gives a satisfactory answer before
Microsoft comes around to it.

Now, all that said, MS staff often answers questions in the newsgroups
anyway, both in microsoft.* as well as in this newsgroup. But that
still does not mean you will get an answer. And your original post was not
one that was easily answered. And this post in comp.databases.ms-sqlserver
was even worse.

Why? Because there is no way for the person who reads the post to
reproduce the problem. Basically, all that can be said is: First
verify that you are running at least SP3 of SQL Server. If you do,
then open a case with Microsoft. If there is a bug, then you will
have your initial expenses refunded.

Now, if you would like me to pursue the issue through the newsgroups,
the normal procedure would be that I asked you for the CREATE TABLE
CREATE VIEW and CREATE INDEX statements for the view as well and
underlying tables. (I see that you included the view in your original
post, but it's nice to have all in one place). I would then need then data,
and instructions how to reproduce the problem with that data.

But given the volumes, you cannot post it on the newsgroup. Possibly
you could post it on a web site. However, it might be that this only
happens if you have some certain degree of parallelism, certain
hardware etc. And this is why I think a PSS case might be more effecient.
Note: I did not see the original post at the time it was posted, but
I did look it up for this posting.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Ryan Stonecipher [MSFT]]

Vincent,

Please open a support case with SQL Server support, and they can help you to diagnose/work around/get a fix for this problem.

Thanks,
Ryan Stonecipher
SQL Server Storage Engine.
"Vincent LIDOU" <vl****@laposte.net> wrote in message news:f6**************************@posting.google.c om...
Do not trust values returned by materialized views under SQL Server
without frequently checking underlying tables!!!

I already posted this message under microsoft.public.sqlserver.server
and I'm amazed nobody from Microsoft answered about this problem. By
inserting lots of data into our two main tables for about 30 minutes,
we can fail our materialized view that performs a count_big on those
two tables.

Executing (after of course having stopped inserting rows in our two
tables)

SELECT SUM(field1+field2+field3) FROM MatView option(expand views)
DOES NOT RETURN the same value than:
SELECT SUM(field1+field2+field3) FROM MatView with (noexpand)

The second call - using the materialized view - returns a smaller
number (as if counts were lost during our bulk insert)

As our data has to be accurate, we cannot use Materialized views
anymore. This problem does not occur when the amount of data inserted
is smaller. Rebuilding the clustered index on the view fixes the
problem; do we have to constantly be rebuilding the index to keep the
view synchronize !?!!?!

Is there a way to tell that our view is not synchronized? Just
comparing values returned by our view does not work for us as data is
constantly been inserted.

System: SQL server 2000 SP3 Enterprise Edition

Vincent LIDOU

[Vincent LIDOU]

Thanks for your answers.

My problem is the following: even if Microsoft can provide us with a
fix, I wouldn't be allowed to install it on our porduction servers (we
can only install service packs). Also, I wish I could spend more time
tracking down this bug with Microsoft, but the time spent would be
lost for the company I work for. Finally I'm obvioulsy not allowed to
send our database model in this newsgroup.

I remain convinced that this bug should be reproduced easily:
* Create a complex materialized view, that performs at least 4-5 inner
joins on high-volume tables.
* Add multiple 'count_big' and 'group by' to this mat view. In my
case, I had 5 count_big like :

count_big(CASE WHEN (fi.txtStatus = 'New') THEN 1 ELSE NULL END ) as
IssueTotalNew )

* Insert new records to its underlying tables without interruption for
at least 30minutes.

Please let me know if you have more information about this bug.

Thanks,

Vincent LIDOU

"Ryan Stonecipher [MSFT]" <ry******@online.microsoft.com> wrote in message news:<40********@news.microsoft.com>...

Vincent,

Please open a support case with SQL Server support, and they can help
you to diagnose/work around/get a fix for this problem.

Thanks,
Ryan Stonecipher
SQL Server Storage Engine.

[Steve Jorgensen]

On 9 Jun 2004 22:06:22 -0700, vl****@laposte.net (Vincent LIDOU) wrote:

Thanks for your answers.

My problem is the following: even if Microsoft can provide us with a
fix, I wouldn't be allowed to install it on our porduction servers (we
can only install service packs). Also, I wish I could spend more time
I don't mean the following in an agressive way or to be demeaning to you at
all, but ... Rules are just words on paper. Immutable rules are poison. If
your company isn't flexible enough to make exceptions in special cases for
core business reasons, it'll go the way of the dinosaur. Have you asked if an
exception could be made if there was a busniness value case for it? Perhaps,
your comany is more flexible than you think.
tracking down this bug with Microsoft, but the time spent would be
lost for the company I work for. Finally I'm obvioulsy not allowed to
send our database model in this newsgroup.
If you can reproduce the problem with other data, you don't have to send your
data to anyone.
I remain convinced that this bug should be reproduced easily:
* Create a complex materialized view, that performs at least 4-5 inner
joins on high-volume tables.
The only way you should ever be convinced of that is if you've reproduced it
in this way. Once you have, you can submit that to Microsoft. That's just
the way the world works - you get help after you can demonstrate the problem
for tech support. It's not hard to populate a fat table with random data for
testing purposes.
* Add multiple 'count_big' and 'group by' to this mat view. In my
case, I had 5 count_big like :

Relax - repro the problem, and get help from MS. Convince your company, you
need the patch from MS now, and not wait for it to be included in a service
pack. If MS is still unhelpful, then you can come back here, and bad-mouth MS
all you want. I'm not saying Microsoft wil definitely give you satisfaction,
but you have to jump through the requisite hoops first, if you want to have
any hope of getting your problem fixed. If you have no confidence Microsoft
can help you, don't bother - convince your company to switch to oracle or
PostgreSql - or quit.

[Erland Sommarskog]

Vincent LIDOU (vl****@laposte.net) writes:

My problem is the following: even if Microsoft can provide us with a
fix, I wouldn't be allowed to install it on our porduction servers (we
can only install service packs).
That is obviously your problem. But as Steve Jorgensen pointed out,
this is a trade-off. If this bug is business-critical to your
organisation, you should certainly make an exception from the rule.
Then again, if this is a problem you can live with, your strategy to
install only service packs is not a bad one. Although there are
several post-SP3 available for public download, they have not been
subject to the same level of regression testing as a true hotfix, so
there is certainly an increased risk for other surprises.

Also, I wish I could spend more time tracking down this bug with
Microsoft, but the time spent would be lost for the company I work for.
...
I remain convinced that this bug should be reproduced easily:
I'm sorry, but this is not how the world works. If you are not
prepared to spend the time to investigate this, don't expect anyone else
to do so. You have the view, and you have the problem. I am not going
to create complex indexed view just for a guess to see if the problem
appears. There might be something very special in your setup which
is the source of the problem. In fact, I don't want to rule out that
this may also be related to your hardware configuration. But if you
would give me a repro that you know demonstrates the problem, and I
would not be able to reproduce it, that would at least be a clue.

And mind you, any time I spend on this, is of no profit to my company,
but this is something I do in my spare time.

But if you are not interested in pursuing the issue, let's drop it.
But it would be a pity, because if there is indeed a bug, then MS
would like to make sure that at very least it is not in the next version
of SQL Server.
Finally I'm obvioulsy not allowed to send our database model in this >
newsgroup.

And no one is expecting to do so. To get the issue out here, you would
have to carve out a view similar to the one you have in production. Yes,
that would be a couple of hours of work, but I am afraid that unless
you open a case with Microsoft, no one else will do it. (I'm assuming
that you would give the MS Support Engineer access to the database.)

And, oh, running a couple of integrity checks on the database may be
a good idea.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp