Index du serveur SQL corrompu ?

Question

Je rencontre un problème très étrange concernant ce qui semble être une sorte d'index corrompu. Pas corrompu dans le sens où dbcc checkdb le détectera, mais corrompu dans le sens où il contient des lignes qu'il ne devrait pas avoir.

J'ai deux tables, TableA et TableB. Pour les besoins de mon application, certaines lignes sont considérées comme des doublons fonctionnels, ce qui signifie que même si les valeurs des colonnes ne sont pas toutes identiques, la ligne est traitée comme un doublon par mon application. Pour les filtrer, j'ai créé une vue appelée vTableAUnique. Cette vue est définie comme suit :

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

Les résultats de la vue sont tous les enregistrements de TableA qui n'ont pas d'autres lignes dans TableA avec les mêmes valeurs pour Col1. Pour cet exemple, disons que TableA a 10 lignes au total, mais seulement 7 avec des valeurs distinctes qui apparaissent dans vTableAUnique.

La TableB est essentiellement une liste de valeurs qui correspondent aux valeurs de la Col1 de la TableA. Dans ce cas, disons que TableB possède les 8 valeurs uniques qui apparaissent dans vTableAUnique. Ainsi, les données de TableA, TableB et vTableAUnique ressembleraient à ceci :

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

Voici donc la partie étrange. Parfois, lorsque je joins vTableAUnique à TableB sur Col1, je récupère les valeurs non distinctes de TableA. En d'autres termes, des lignes qui n'existent PAS dans vTableAUnique, mais qui existent dans TableA, apparaissent lorsque je fais la jointure. Si je fais la sélection juste à partir de vTableAUnique, je n'obtiens pas ces lignes. Dans ce cas, j'obtiendrais non seulement des lignes avec les identifiants 1, 3, 5, 6, 7, 8, 9 et 10, mais AUSSI des lignes avec les identifiants 2 et 4 !

Après m'être tapé la tête contre mon bureau, j'ai décidé d'essayer de reconstruire tous les index de la BD. Bien sûr, le problème a disparu. La même requête renvoie maintenant les bonnes lignes. Cependant, après une période de temps indéterminée, le problème est revenu. DBCC CHECKDB ne montre aucun problème et j'ai du mal à trouver l'index qui pourrait en être la cause.

J'utilise SQL Server 2008 Developer Edition sur Vista x64.

AIDE !

Answer 1

ROW_NUMBER() OVER (PARTITION By Col1 ORDER BY Col1)

n'est pas un ordre de tri stable, il peut changer d'une requête à l'autre en fonction du chemin d'accès.

Votre vue peut renvoyer des résultats différents si elle est exécutée plusieurs fois.

La reconstruction des index semble affecter l'ordre de tri.

Utilisez ça :

ROW_NUMBER() OVER (PARTITION By Col1 ORDER BY Id)

au lieu de cela, il garantit un ordre de tri stable.

Answer 2

Script hors des index et regardez le script, a-t-il été créé avec ALLOW_DUP_ROW ? si oui, alors cela pourrait être votre problème.