Discussion :

[Donpi]

Voilà,
j'ai un bug très étrange et j'ai besoin de savoir d’où il vient ou par ou commencer à chercher.


J'ai une requête simple qui date d'un époque ou je ne travaillais pas encore a mon post actuel.
Il s'agit de 4 tables avec des jointures internes simples, sur une seule clé et quelque filtres dans ma clause Where.

Malheureusement la politique de confidentialité de ma boite ne m'autorise pas a fournir les descriptif de tables.

La requête suivante me retourne deux lignes ce qui est juste

Code :

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

1
2
3
4
5
6
7
8
9
 
Select *
FROM T1
INNER JOIN T2 ON T2.IdT2 = T1.IdT2 
INNER JOIN T3  ON T3.IdT3 = T2.IdT3 
INNER JOIN T4  ON T4.IdT4 = T3.IdT4 
WHERE  T1.IdT1  = 65955 
	AND T2.AutreCle IS NULL AND T4.CODE  = 'LeCode'  
	AND CONVERT( DECIMAL(9,2) , T2.NouveauPrix  ) =  2.8

Mais si je fais un select * de T2 ça ne retourne aucune ligne

Code :

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

1
2
3
4
5
6
7
8
9
 
Select T2.*
FROM T1
INNER JOIN T2 ON T2.IdT2 = T1.IdT2 
INNER JOIN T3  ON T3.IdT3 = T2.IdT3 
INNER JOIN T4  ON T4.IdT4 = T3.IdT4 
WHERE  T1.IdT1  = 65955 
	AND T2.AutreCle IS NULL AND T4.CODE  = 'LeCode'  
	AND CONVERT( DECIMAL(9,2) , T2.NouveauPrix  ) =  2.8

Encore plus drôle, cette variante donne 2 lignes

Code :

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

1
2
3
4
5
6
7
8
9
 
Select T2.*,T3.*
FROM T1
INNER JOIN T2 ON T2.IdT2 = T1.IdT2 
INNER JOIN T3  ON T3.IdT3 = T2.IdT3 
INNER JOIN T4  ON T4.IdT4 = T3.IdT4 
WHERE  T1.IdT1  = 65955 
	AND T2.AutreCle IS NULL AND T4.CODE  = 'LeCode'  
	AND CONVERT( DECIMAL(9,2) , T2.NouveauPrix  ) =  2.8

mais celle ci aucune

Code :

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

1
2
3
4
5
6
7
8
9
 
Select T2.*,T3.IdT3 
FROM T1
INNER JOIN T2 ON T2.IdT2 = T1.IdT2 
INNER JOIN T3  ON T3.IdT3 = T2.IdT3 
INNER JOIN T4  ON T4.IdT4 = T3.IdT4 
WHERE  T1.IdT1  = 65955 
	AND T2.AutreCle IS NULL AND T4.CODE  = 'LeCode'  
	AND CONVERT( DECIMAL(9,2) , T2.NouveauPrix  ) =  2.8

Encore plus fort, plus ma clause where est permissive, mois j'ai de résultats
ça donne aucune ligne

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Select *
FROM T1
INNER JOIN T2 ON T2.IdT2 = T1.IdT2 
INNER JOIN T3  ON T3.IdT3 = T2.IdT3 
INNER JOIN T4  ON T4.IdT4 = T3.IdT4 
WHERE  T1.IdT1  = 65955 
	AND T2.AutreCle IS NULL 
	--AND T4.CODE  = 'LeCode'  
	AND CONVERT( DECIMAL(9,2) , T2.NouveauPrix  ) =  2.8

ça donne 2 ligne

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Select *
FROM T1
INNER JOIN T2 ON T2.IdT2 = T1.IdT2 
INNER JOIN T3  ON T3.IdT3 = T2.IdT3 
INNER JOIN T4  ON T4.IdT4 = T3.IdT4 
WHERE  T1.IdT1  = 65955 
	AND T2.AutreCle IS NULL 
	AND T4.CODE  = 'LeCode'  
	AND CONVERT( DECIMAL(9,2) , T2.NouveauPrix  ) =  2.8

Le "bug" se produit sur la prod et sur mes 4 serveur test sur du 2008R2 et du 2012


Un de vous a-t-il une explication ?
ou un moyen de prévoir ce comportement?

Merci a bientot.

Edit
Après un bon coup de flippe et un rebuild des tout les indexes des 4 tables, tout est a nouveau cohérent.

[SQLpro]

Il est probable que vous avez des index corrompus. Faites très attention, car si c'est le cas, un de vos disque est en train de lâcher. SQL Server est connu pour n'avoir aucun bug concernant le moteur de stockage. En reconstruisant vos tables comme vous l'avez fait, il y a fort à parier que votre disque n'a pas été réparé et que ce problème va survenir à un autre endroit !

Première chose lorsque vous vérifiez une base avec DBCC CHECKDB (à faire au moins une fois par jour), si des erreurs sont remontées, c'est de déplacer le stockage sur d'autres disques avant de procéder à une reconstruction des index !

A +

[Donpi]

Re,

Mon serveur est complètement virtualisé ( machine et disques ).
Le SAN ne mentionne aucune erreur et DBCC CHECKDB tourne une fois par semaine sans jamais retourner la moindre erreur.

Ce qui porte a croire qu'il ne s'agit pas d'un problème physique.
Ou alors c'est carrément le contrôleur du SAN, mais j'aurais d'autre problèmes ailleurs.

A+

[hmira]

- Les descriptions des symptômes laisse à penser, comme l’a déjà suggéré SQLPro, qu’il y a un sérieux problème quant à l’intégrité des indexes.

- Avez-vous au moins essayé de reconstruire tous les indexes ou du moins tous les indexes mis en jeu dans les plans d’exécution de chacune des requêtes que vous avez évoquées ci-dessus ?

- Avez-vous préfixé chacune des tables par le nom du schéma (en l’occurrence dbo). En effet, sans la qualification du nom du schéma la résolution du nom des objets est parfois hasardeuse ?

- Est-ce au moins une des Tables T1, T2 ou Tn référence des Serveurs liés, exemple ORACLE, DB2, etc… ? Cela peut provenir du provider utilisé (?) même si les SGBD comme ORACLE ou DB2, que je connais bien, sont très sûrs et très fiables.

- Que donne le résultat des 2 requêtes ci-dessous ?

Code SQL :

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

1
2
3
Select db.name, db.page_verify_option, db.page_verify_option_desc
From sys.databases db
WHERE db.database_id = db_id()

Code SQL :

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

Select DATABASEPROPERTYEX(db_name(), 'IsTornPageDetectionEnabled');

A+

[Donpi]

- Les descriptions des symptômes laisse à penser, comme l’a déjà suggéré SQLPro, qu’il y a un sérieux problème quant à l’intégrité des indexes.

- Avez-vous au moins essayé de reconstruire tous les indexes ou du moins tous les indexes mis en jeu dans les plans d’exécution de chacune des requêtes que vous avez évoquées ci-dessus ?

Oui, c'est dans mon édit, après un rebuild ça marche mieux

- Avez-vous préfixé chacune des tables par le nom du schéma (en l’occurrence dbo). En effet, sans la qualification du nom du schéma la résolution du nom des objets est parfois hasardeuse ?

- Est-ce au moins une des Tables T1, T2 ou Tn référence des Serveurs liés, exemple ORACLE, DB2, etc… ? Cela peut provenir du provider utilisé (?) même si les SGBD comme ORACLE ou DB2, que je connais bien, sont très sûrs et très fiables.

Elles sont toutes dans le même schéma sur le même server

- Que donne le résultat des 2 requêtes ci-dessous ?

Code SQL :

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

1
2
3
Select db.name, db.page_verify_option, db.page_verify_option_desc
From sys.databases db
WHERE db.database_id = db_id()

Code SQL :

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

Select DATABASEPROPERTYEX(db_name(), 'IsTornPageDetectionEnabled');

A+

Je ne peux "malheureusement" plus faire de test après le rebuild

[hmira]

Oui, j’avais zappé votre "Edit" (ci-dessous) !

Edit
Après un bon coup de flippe et un rebuild des tout les indexes des 4 tables, tout est a nouveau cohérent.

Donc si je comprends bien votre problème est résolu sans que vous sachiez le pourquoi du comment !

Je ne peux "malheureusement" plus faire de test après le rebuild

Pourquoi ? Pouvez-vous être plus explicite (?) Cela me parait en contradiction avec votre phrase précédente ".., tout est a nouveau cohérent"

A+

[Donpi]

J'ai enlevé la coche résolu car SqlPro parle d'un problème physique, mais je suis vraiment incapable de mettre la main dessus.
Ni CHECKDB ni le SAN ne donnent d'information sur un problème phisique.

Et je ne peux plus faire de testes sur les incohérences, car tout est rentré dans l'ordre.

[mikedavem]

Est-ce que tu as vérifié si ta base de données possédait une méthode de vérification des pages ? (checksum ou torn page).
Dans le cas contraire il est possible que le fait de lire ta table / indexes ne produise aucune erreur et que dans certains cas que la commande dbcc checkdb ne te remonte aucune erreur également.

++

[Donpi]

Est-ce que tu as vérifié si ta base de données possédait une méthode de vérification des pages ? (checksum ou torn page).
Dans le cas contraire il est possible que le fait de lire ta table / indexes ne produise aucune erreur et que dans certains cas que la commande dbcc checkdb ne te remonte aucune erreur également.

++

Je viens de regarder, et dans "Recovery/Page Verify" j'ai "NONE".
ça peut être pour ça que ChkDB ne retourne rien ?

[mikedavem]

Oui effectivement si aucune vérification de page n'est configurée pour la base de données et que ta corruption se trouve en plein milieu d'une page de données dbcc checkdb est incapable de te remonter une erreur car il n'a aucun moyen de te dire si une page a été altérée ou non. Même chose lors de la lecture d'une page ...

Le fait d'avoir reconstruit tes indexes peut avoir réglé ton problème si la corruption concernait uniquement tes index non cluster mais par prudence j'activerais quand même cette option pour le futur.

++

[Donpi]

Merci ,

J'ai regardé un peu sur Google.

Les gens semblent recommander le Checksum. Je dois m'attendre a des problèmes si j'active ça sur ma base de production de ~120Go ?

A+

[mikedavem]

Des problèmes dans le sens strict du terme non. En revanche l'activation de cette option va te générer par la suite un "léger" overhead CPU car pour chaque page modifié et lu il faudra calculer et écrire le checksum dans un cas et calculer et vérifier si le checksum correspond dans l'autre cas mais rien de bien méchant à part si ton activité business est suffisamment grande pour engendrer une activité CPU déjà très importante sur ton serveur.

++

[mikedavem]

Par curiosité le dbcc checkdb qui était lancé dans ton plan / job de maintenance utilisait l'option WITH PHYSICAL_ONLY ?

++

[Donpi]

La commande se trouve dans un pack SSIS planifiée une fois par semaine et est déclarée comme suit :

Code :

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

DBCC CHECKDB(N'DbName')  WITH NO_INFOMSGS

[mikedavem]

Ok et donc dernière question je pense afin de mieux comprendre l'origine de ton problème (par curiosité):
Est-ce que la maintenance de tes indexes se fait via le plan de maintenance ? Si oui à quelle fréquence ? Avant la vérification d'intégrité ? Un job SQL personnalisé ?

++

[Donpi]

Ok et donc dernière question je pense afin de mieux comprendre l'origine de ton problème (par curiosité):
Est-ce que la maintenance de tes indexes se fait via le plan de maintenance ? Si oui à quelle fréquence ? Avant la vérification d'intégrité ? Un job SQL personnalisé ?
++

Hahaaa pas de maintenance des indexes. Mes collègues l'avaient désactivé avant que je travaille a ce post car trop long.

J'ai lancé une maintenance manuellement le week end dernier ça à pris ~2h avec les script que j'ai mis dans un autre post.

Il reste juste le Checkdb qui tourne une fois par semaine le dimanche