Discussion :

[Maxime_Gendre]

Bonjour à tous,
j'espère que je suis dans la bonne catégorie pour ce sujet.

Je constate un problème assez déroutant sur une requête toute simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select count(1) from myTable where someField = 46

retourne "56221"

mais un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from myTable where someField = 46

retourne 3997 lignes

voilà le plan d'exécution :




Je ne vois pas comment un simple count() peut renvoyer un résultat erroné.

J'ai testé de faire un rebuild et un reorganize de l'index, pas mieux.

La seule façon d'avoir le bon 'count' est de forcer l'utilisation d'un autre index (via un hint)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select count(1) from myTable with(index= anotherIndex) where someField = 46

retourne "3997"



A toute fin utile, voilà le script de création de l'index

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
CREATE NONCLUSTERED INDEX [IX_myTable] ON [myTable]
(
	[SomeField] ASC,
	[AnotherField] ASC
)
INCLUDE ( 	[Field1],
	[Field2],
	[Field3],
	[Field4]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 70) 
GO

Je suis en version Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64)

Quelqu'un a déjà eu ce genre de problèmes ?

Merci !

PS : le champ "SomeField" est en int nullable mais ne contient aucune valeur NULL dans la table.

[aieeeuuuuu]

Bonjour,

C'est très suspect... je commencerais par un DBCC CHECKDB pour vérifier l'intégrité de la base.

[Maxime_Gendre]

Bonjour,
merci pour la suggestion.
Je vais tester ça. Je vous tiens au courant.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
DBCC CHECKDB WITH PHYSICAL_ONLY;
GO

DBCC results for 'xxxxx'.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxxxx'.

Avec l'option "WITH PHYSICAL_ONLY", le dbcc checkdb ne détecte rien d'anormal.
Je retenterai un FULL durant la nuit mais ça met un peu le serveur à genou.

[SQLpro]

Ne seriez vous pas en READ UNCOMMITED ? (ou NOLOCK ce qui est la même chose ?)

A +

[julien94320]

Bonjour,

J'ai déjà rencontré un probleme similaire sur une version SP1 de SQL Server 2016 sur un columnstore index...

J'ai du passé le SP2 ou un CU pour remedier au probleme.

Le problème était que dans les statistiques le nombre de lignes étaient erronés par rapport au données stockées même en réalisant un update stat cela ne fonctionnait pas ...

En reconstruisant l'index non plus ...


Puis j'ai cherché un peu :

https://littlekendra.com/2017/01/17/...mnstore-index/

https://support.microsoft.com/en-us/...-in-sql-server

A+

[Maxime_Gendre]

Effectivement le dbcc check complet renvoie des millions d'erreurs sur cette table:

Table error: table 'xxxxxxxxxxxx' (ID 1399857691). Index row in index 'monIndex' (ID 4) does not match any data row. Possible extra or invalid keys for:
Msg 8956, Level 16, State 1, Line 1
Index row (3:5148009:89) with values (yyyyyyyyyyyyyyyyyy) pointing to the data row identified by (id = 1103493).
Msg 8952, Level 16, State 1, Line 1

Je vais en programmer un sur tous nos environnements.
Je vais aussi voir pour planifier le passage en SP2.

Je reste quand même surpris qu'un rebuild d'index ne soit pas suffisant.

Merci à tous pour vos réponses !

[SQLpro]

Effectivement le dbcc check complet renvoie des millions d'erreurs sur cette table:

Table error: table 'xxxxxxxxxxxx' (ID 1399857691). Index row in index 'monIndex' (ID 4) does not match any data row. Possible extra or invalid keys for:
Msg 8956, Level 16, State 1, Line 1
Index row (3:5148009:89) with values (yyyyyyyyyyyyyyyyyy) pointing to the data row identified by (id = 1103493).
Msg 8952, Level 16, State 1, Line 1

Le DBCC CHECK.. doit être effectué à la même fréquence que les sauvegardes complètes sur toutes les bases de production et sur les bases master, model et msdb.


En général ceci indique une corruption du stockage. Donc la première mesure est de déplacer le stockage de la base et de retirer le ou les disques fautifs.

Après lisez l'article que j'ai écrit pour les méthodes de réparation :
https://blog.developpez.com/sqlpro/f...corrompues.pdf

A +

[Maxime_Gendre]

Le DBCC CHECK.. doit être effectué à la même fréquence que les sauvegardes complètes sur toutes les bases de production et sur les bases master, model et msdb.


En général ceci indique une corruption du stockage. Donc la première mesure est de déplacer le stockage de la base et de retirer le ou les disques fautifs.

Après lisez l'article que j'ai écrit pour les méthodes de réparation :
https://blog.developpez.com/sqlpro/f...corrompues.pdf

A +

En fait, il est bien schedulé quotidiennement mais avec l'option "WITH PHYSICAL_ONLY".
Ça ne semble cependant pas suffisant. Je vais en parler à notre DBA.
Merci pour l'article, il a l'air très complet.

[julien94320]

Pour info avant la mise en place du SP2, la seul méthode permettant de corriger le problème était la suppression et la reconstruction d'index.

Comme l'a dit SQLpro , il faut vérifier le stockage mais jetez un œil du coté du SP2 également ça ressemble fortement au bug