Discussion :

[Shuret]

J'ai des résultats bizarres sur des requêtes simples. J'ai une table qui se compose de plusieurs champs dont un champ varchar(20) et un champ bit que j'utilise dans mes requêtes.

Le champ varchar permet de restreindre les résultats. La table comporte plus de 6 millions d'enregistrements. Le champ bit permet de distinguer les lignes qui ont subi un traitement des autres. Il vaut soit NULL (non traité), soit 1 (traité).

J'obtiens des résultats différents quand je recherche les lignes non traitées (bit is null). Les résultats varient d'une exécution à l'autre.

Voici les requêtes testées et leurs résultats :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
select * from ma_table where champ_varchar='valeur' 
--29339 lignes
 
select * from ma_table where champ_varchar='valeur' and champ_bit = 1
--18854 lignes
 
Ces résultats semblent corrects.
 
select * from ma_table where champ_varchar='valeur' and champ_bit is null
--Plusieurs résultats différents au lieu de 10485 attendu :
--10689
--29339
--47217
 
select champ_bit, count(*) from ma_table where champ_varchar='valeur' group by champ_bit
-- NULL : 10485
-- 1    : 18854
 
Ce résultat semble correct.
 
select count(*) from ma_table
--6 319 886

J'obtiens les mêmes résultats si je remplace les * par count(*) au lieu de regarder le nombre de lignes retournées par SQL Query Analyser.

La table est-elle corrompue ? Si oui, comment corriger le problème et comment le repérer sur d'autres tables ? SQL Server a t-il un problème avec la gestion de "is null" ?

Pendant mes tests, aucune modification n'a été faite en base. Les données sont fixes.

J'utilise SQL Server 2000 sous Windows 2000 Server.

Merci de votre aide !

[SQLpro]

commencez par vous assurer d'être au bon niveau d'isolation des transactions en faisant :

Code :

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

1
2
3
4
5
SET TRANSACTION ISOLATION SERIALIZABLE
 
... mes requêtes ...
 
SET TRANSACTION ISOLATION READ COMMITTED

Ensuite postez nous les vrais requêtes effectuée avec le DDL des tables en jeu.

Enfin, pour savoir si une table est corrompue, faites :
DBCC CHECKTABLE (...)

A +

[rudib]

Non, il n'y a pas de problème de gestion des NULL en SQL Server 2000 ou autre version. Ton code a l'air correct, et si les données sont fixes, le niveau d'isolation n'entre pas en ligne de compte. Il reste le champ_varchar='valeur' qu'il faut vérifier. Sûr qu'il est le même ?

[SQLpro]

http://www.developpez.net/forums/d98...e/#post5498025

Si cela peut jouer si sa session est en READ UNCOMMITTED !

A +

[Shuret]

Merci pour vos réponses.

Pas d'amélioration avec SET TRANSACTION ISOLATION SERIALIZABLE.
La table incriminée a été copiée dans une nouvelle table. Les requêtes sont correctes dans cette table.

DBCC CHECKTABLE ne renvoie aucune erreur :

Code :

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

1
2
3
Résultats DBCC pour 'CBDRPAYLINE'.
Il y a 6319886 lignes dans 101040 pages pour l'objet 'CBDRPAYLINE'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur du système.

Je ne pense pas que ça fasse avancer les choses, mais voici quand même les vraies requêtes :

Code :

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

1
2
3
4
5
6
7
8
 
SELECT * FROM cbdrpayline WHERE cbdrpayline_fichier='RPA_20100714_015917' 
 
SELECT * FROM cbdrpayline WHERE cbdrpayline_fichier='RPA_20100714_015917' AND cbdrpayline_remis = 1
 
SELECT * FROM cbdrpayline WHERE cbdrpayline_fichier='RPA_20100714_015917' AND cbdrpayline_remis IS NULL
 
SELECT cbdrpayline_remis, count(*) FROM cbdrpayline WHERE cbdrpayline_fichier='RPA_20100714_015917' GROUP BY cbdrpayline_remis

Et le DDL :
Champ Type Longueur Null

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
CBDRPAYLINE_ID	numeric	5	0      
CBDRPAYLINE_CR	varchar	20	1    
CBDRPAYLINE_TPE	varchar	25	0    
CBDRPAYLINE_REF	varchar	50	0    
CBDRPAYLINE_DTDA	datetime	8	1  
CBDRPAYLINE_DTDR	datetime	8	1  
CBDRPAYLINE_AUT	varchar	6	1      
CBDRPAYLINE_MNT	numeric	5	0      
CBDRPAYLINE_PORTEUR	varchar	19	1
CBDRPAYLINE_REFPAYL	numeric	9	1  
CBDRPAYLINE_REMIS	bit	1	1        
CBDRPAYLINE_FICHIER	varchar	20	1

[rudib]

Ben, pour voir, envoie le DDL complet, index et contraintes comprises, des deux tables. Celle qui ne "marche" pas, celle qui "marche".

[Shuret]

Il semble que l'index soit corrompu. Il y a en effet un index sur le champ bit. En le supprimant, on obtient les bons résultats. Y'a t-il possibilité de le corriger ou de repérer les index corrompus ?

[rudib]

Un index sur une colonne de type BIT avec une distribution telle qu'on la voit dans tes requêtes et inutile, aucune sélectivité de l'index.

Un DBCC CHECKTABLE vérifie les index de la table, sauf si tu utilises l'option NOINDEX.

[iberserk]

Y'a t-il possibilité de le corriger ou de repérer les index corrompus ?

En reconstruisant l'index (s'il est utile...)?


ALTER INDEX [nomindex] ON [tableName] REBUILD par exemple