SQL Server 索引损坏?
我遇到了一个非常奇怪的问题,似乎是某种损坏的索引。 没有损坏是指 dbcc checkdb 将拾取它,但损坏是指它包含不应该包含的行。
我有两个表,TableA 和 TableB。 出于我的应用程序的目的,某些行被认为在功能上重复,这意味着虽然并非所有列值都相同,但该行被我的应用程序视为重复。 为了过滤掉这些内容,我创建了一个名为 vTableAUnique 的视图。 该视图的定义如下:
SELECT a.*
FROM TableA a
INNER JOIN
(
SELECT ID, ROW_NUMBER() OVER
(PARTITION By Col1
ORDER BY Col1) AS Num
FROM TableA
) numbered ON numbered.ID = a.ID
WHERE numbered.Num = 1
视图的结果是 TableA 中不存在具有相同 Col1 值的任何其他行的所有记录。 对于此示例,假设 TableA 总共有 10 行,但只有 7 行具有显示在 vTableAUnique 中的不同值。
TableB 基本上只是与 TableA 中的 Col1 值匹配的值列表。 在本例中,假设 TableB 具有 vTableAUnique 中出现的全部 8 个唯一值。 因此 TableA、TableB 和 vTableAUnique 中的数据将如下所示:
TableA (ID, Col1, Col2, Col3)
1,A,X,X
2,A,X,X
3,B,X,X
4,A,X,X
5,E,X,X
6,F,X,X
7,G,X,X
8,H,X,X
9,I,X,X
10,J,X,X
TableB (ID)
A
B
C
D
E
F
G
H
I
J
vTableAUnique (ID, Col1, Col2, Col3)
1,A,X,X
3,B,X,X
5,E,X,X
6,F,X,X
7,G,X,X
8,H,X,X
9,I,X,X
10,J,X,X
所以这是奇怪的部分。 有时,当我在 Col1 上将 vTableAUnique 与 TableB 连接时,我会从 TableA 中返回非不同的值。 换句话说,当我执行联接时,会出现在 vTableAUnique 中不存在但在 TableA 中确实存在的行。 如果我在 vTableAUnique 上进行选择,我不会得到这些行。 在这种情况下,我不仅会返回 id 为 1,3,5,6,7,8,9,10 的行,还会返回 id 为 2 和 4 的行!
在用头撞桌子后,我决定尝试重建数据库中的所有索引。 果然,问题消失了。 现在,相同的查询返回了正确的行。 然而,一段时间后,问题又回来了。 DBCC CHECKDB 没有显示任何问题,我很难追踪哪个索引可能导致此问题。
我在 Vista x64 上使用 SQL Server 2008 Developer Edition。
帮助!
I'm encountering a very strange problem concerning what appears to be a corrupt index of some kind. Not corrupt in the sense that dbcc checkdb will pick it up, but corrupt in the sense that it has rows that it shouldn't have.
I have two tables, TableA and TableB. For the purposes of my application, some rows are considered functionally duplicate, meaning while not all the column values are the same, the row is treated as a dup by my app. To filter these out, I created a view, called vTableAUnique. The view is defined as follows:
SELECT a.*
FROM TableA a
INNER JOIN
(
SELECT ID, ROW_NUMBER() OVER
(PARTITION By Col1
ORDER BY Col1) AS Num
FROM TableA
) numbered ON numbered.ID = a.ID
WHERE numbered.Num = 1
The results of the view is all the records from TableA that don't have any other rows in TableA with the same values for Col1. For this example, let's say that TableA has 10 total rows, but only 7 with distinct values that show up in vTableAUnique.
TableB is basically just a list of values that match the values of Col1 from TableA. In this case, let's say that TableB has all 8 unique values that appear in vTableAUnique. So the data from TableA, TableB, and vTableAUnique would look like:
TableA (ID, Col1, Col2, Col3)
1,A,X,X
2,A,X,X
3,B,X,X
4,A,X,X
5,E,X,X
6,F,X,X
7,G,X,X
8,H,X,X
9,I,X,X
10,J,X,X
TableB (ID)
A
B
C
D
E
F
G
H
I
J
vTableAUnique (ID, Col1, Col2, Col3)
1,A,X,X
3,B,X,X
5,E,X,X
6,F,X,X
7,G,X,X
8,H,X,X
9,I,X,X
10,J,X,X
So here is the strange part. Sometimes when I join vTableAUnique with TableB on Col1, I get back the non-distinct values from TableA. In other words, rows that do NOT exist in vTableAUnique, but that do exist in TableA, appear when I do the join. If I do the select just off vTableAUnique, I don't get these rows. In this case, I would get back not just rows with the ids of 1,3,5,6,7,8,9,10, but ALSO rows with the ids of 2 and 4!
After banging my head against my desk, I decided to try and rebuild all the indexes in the DB. Sure enough, the problem disappeared. The same query now returned the correct rows. After an indererminant period of time, however, the problem comes back. DBCC CHECKDB doesn't show any issues, and I'm having a hard time tracking down which index might be causing this.
I'm using SQL Server 2008 Developer Edition on Vista x64.
HELP!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
编写索引并查看脚本,它是使用 ALLOW_DUP_ROW 创建的吗? 如果是这样,那可能是你的问题
script out the indexes and look at the script, was it created with ALLOW_DUP_ROW? if so then that could be your problem
不是稳定的排序顺序,它可以根据访问路径在查询之间发生变化。
您的视图多次运行可能会返回不同的结果。
重建索引似乎会影响排序顺序。
使用这个:
相反,它保证稳定的排序顺序。
is not a stable sort order, it can change from query to query depending on access path.
Your view may return different results being run several times.
Rebuilding indexes seems to affect the sort order.
Use this:
instead, it guarantees stable sort order.