[SQL Server 2000] Erreur lors d'un DBCC DBREINDEX

Windows Server 2003 Standard SP2
Microsoft SQL Server 2000 - 8.00.2273 (Intel X86)

Bonjour,

Je rencontre une erreur lors de la tentative de reconstruction des indexes de 2 de mes tables possédant 250 000 lignes pour l'une et 542 000 pour l'autre.

Commande utilisée :
DBCC DBREINDEX ('TableName','',90)

Message d'erreur :
Error 3628: [Microsoft][ODBC SQL Server Driver][SQL Server]A floating point exception occurred in the user process. Current transaction is canceled.

J'ai fait des tests sur un backup de la base de données que j'ai restauré dans une base "clown" afin de ne pas impacter la prod...

Malgré la suppression de tous les indexes de 2 tables, la commande fini avec la même erreur.

Seule manip qui semble fonctionner :
-> Copier toutes les données dans une autre table
-> Purger la table incriminée
-> Réimporter les données

SELECT * INTO TABLE_Temp FROM Table_Prod
GO
TRUNCATE TABLE Table_Prod
GO
INSERT INTO Table_Prod SELECT * FROM TABLE_Temp
GO

Quelqu'un a-t-il une idée de cette énigme ?

Pour complément, j'ai aussi passé des tests d'intégrité qui n'ont retournés aucune erreur :
DBCC CHECKDB
DBCC CHECKTABLE

De plus, la reconstruction index par index fonctionne très bien.
DBCC DBREINDEX ('TableName','IndexName1',90)
DBCC DBREINDEX ('TableName','IndexName2',90)
DBCC DBREINDEX ('TableName','IndexName3',90)
[...]

Merci d'avance pour vos idées...
Cordialement.

David

Apparemment dû à des données corrompues.
Voici des liens qui pourront t'aider :
http://www.bigresource.com/MS_SQL-St...-bs2HUGni.html
http://www.dbforums.com/microsoft-sq...ils-table.html
http://sqlforums.windowsitpro.com/we...&enterthread=y

Il faut passer toutes les commandes DBCC CHECK avec les options comme REPAIR_REBUILD (ALLOC).

En général ce genre d'erreur provient d'un disque en train de lâcher.

Je vous conseille donc de
1) changer le disque
2) une fois remplacer analyser ce dernier à l'aide d'un outil de vérification de la surface.

A +

Bonjour,
Je vous suggère de scruter l'utilisation de la mémoire RAM à l'aide des compteurs de performances. Il se pourait que ton système manque de mémoire RAM, car la reconstruction des Index est couteuse.

Bonne chance.

Bonjour,

Malgré le passage des commandes suivantes :
DBCC CHECKDB ('DatabaseName',REPAIR_BUILD)
DBCC CHECKALLOC ('DatabaseName',REPAIR_BUILD)
DBCC CHECKTABLE ('TableName',REPAIR_BUILD)

La commande DBCC DBREINDEX ne passe toujours pas.

Pour rappel, je fais ces tests sur une Restore d'un backup de prod. que j'ai restauré sur une VM avec "Virtual PC 2007".

Le serveur de prod :
Bi-CPU 3.20GHz
4Go de RAM

Pensez-vous que les 2Go adressables par défaut par Windows ne soient pas suffisants ?

Côté disques, j'espère qu'il ne s'agit pas d'un problème de ce type, car les datas sont sur un RAID 5...

Citation:

---

Envoyé par dily0403

Pensez-vous que les 2Go adressables par défaut par Windows ne soient pas suffisants ?

---

A toi d'en mesurer la consommation.......

En fait, j'avais écarté la thèse du pb de ressources car lorsque je tronque la table puis y réinjecte les données que j'avais copié dans une table temporaire au préalable, le DBREINDEX passe...
Sauf erreur de ma part, cette manip. devrait permettre de présenter la même volumétrie (Data & Indexes)...

Précision : il n'y a que des indexes non-cluster dans cette table, aucun index-cluster...

Si des données sont corrompues, pourquoi les différents CHECK ne l'ont pas détecté ? Sinon, comment identifier ces données ?

Je reste ouvert à toutes nouvelles thèses ou contre-thèses...

1° Avez vous une application Access de laquelle provienne les données ?
2° si c'est le cas, la corruption vient de Acces et lors de l'intégration elle n'a pas été vue
3° est-te vous à jours des service Pack ?
4° pour corriger cela il faut faire un UPDATE sur les données de la table.

A +

Il ne s'agit pas d'une base de données issue de MsAccess...

Ce qui est troublant, c'est qu'un grain de sable a due se glisser dans l'engrenage, en effet, la tâche d'optimisation du plan de maintenance fonctionnait très bien jusqu'à il y a 2 semaines... Il s'agit d'un plan de maintenance lancé 1 fois par semaine.

Je pencherais de plus en plus pour la thèse des données corrompues, mais comment puis-je le vérifier ?

Pour ce qui est du SP, c'est l'un des dernier...

8.00.2273

SQL Server Builds by SQLSecurity.com

Citation:

---

Je pencherais de plus en plus pour la thèse des données corrompues, mais comment puis-je le vérifier ?

---

Reportez vos données et JT sur une autre axe physique.
Auditez le disque en cause avec un outil d'analyse surfacique.

A +

A priori, nous n'avons aucune remontée d'erreur émanant du système RAID du serveur.

Le Backup/Restore n'aurait due-t-il pas me jeter si une page était endommagée ?

Sachant que le Backup est fait sur le serveur de Prod et que le Restore est fait sur une VM complètement indépendant physiquement du serveur de Prod...

Sur des serveur Dell avec contrôleur PERC, j'ai déjà vu des erreurs d'écriture sciemment effectuées par un bug du firmware du controleur donc indétectable...

Un restore n'étant qu'une remise en place binaire des pages dans un fichier, il n'y a heureusement aucun contrôle !

A +