Dépannage d’erreur DBCC 2570 dans SQL Server 2005 et versions ultérieures

INTRODUCTION

Cet article décrit l’erreur SQL Server 2570, ce qui provoque l’erreur et comment résoudre le problème.

Plus d'informations

Contrôles DATA_PURITY

Dans SQL Server 2005, une nouvelle option, DATA_PURITY, a été ajoutée pour les commandes DBCC CHECKDB et DBCC CHECKTABLE. Lorsque vous exécutez une commande DBCC CHECKDB ou DBCC CHECKTABLE avec cette option activée, la commande va effectuer des validations de « pureté de données » sur chaque valeur de colonne de toutes les lignes de la table ou les tables de la base de données. Ces nouvelles vérifications sont effectuées pour s’assurer que les valeurs stockées dans les colonnes sont valides (c'est-à-dire que les valeurs ne sont pas hors de la plage pour le domaine associé avec le type de données de cette colonne). La nature de la validation exécutée dépend du type de données de la colonne. La liste non exhaustive ci-dessous fournit quelques exemples :
Type de données de colonneType de validation de données effectuée
Caractère UnicodeLa longueur des données doit être un multiple de 2.
DateTimeLe champ jours doit être entre le 1 janvier 1753 et le 31 décembre 9999. Le champ heure doit être antérieur à la « 11:59:59:999 PM ».
Réel et FloatVérifier l’existence de valeurs à virgule flottante non valides telles que SNAN, QNAN, NINF, ND, PD, PINF.
Pas tous les types de données sont vérifiés pour la validité des données de la colonne. Seulement ceux où il est possible d’avoir une valeur stockée en dehors de la plage sont vérifiées. Par exemple, le type de données tinyint a une plage valide comprise entre 0 et 255 et est stocké dans un seul octet (qui ne peut stocker que des valeurs de 0 à 255), vérification si la valeur n’est pas nécessaire.

Les contrôles de validation de pureté de données ne sont pas automatiquement activés pour toutes les bases de données. Les contrôles sont activés en fonction de plusieurs facteurs :
  • Pour les bases de données créées dans SQL Server 2005 et versions ultérieures, ces contrôles sont activés par défaut et ne peut pas être désactivés, donc l’utilisation de l’option DATA_PURITY lors de l’exécution d’une commande DBCC CHECKDB ou DBCC CHECKTABLE est sans importance.
  • Pour les bases de données qui ont été créés dans les versions antérieures de SQL Server, comme SQL Server 2000, SQL Server 7.0 et les versions mises à niveau vers SQL Server 2005, ces contrôles ne sont pas activés par défaut. Afin que ces contrôles soient effectués, vous devez spécifier l’option DATA_PURITY dans la commande DBCC CHECKDB ou DBCC CHECKTABLE. Cela peut entraîner de deux choses :
    • La commande DBCC se termine et que la base de données est propre, y compris des contrôles de pureté toutes les données des rapports. Ce fait est enregistré dans l’en-tête de la base de données. Toutes les exécutions suivantes de commande DBCC CHECKDB ou DBCC CHECKTABLE Notez ces informations et effectuent automatiquement les vérifications de pureté des données, comme dans le cas de bases de données créées dans SQL Server 2005. En d’autres termes, une fois qu’une base de données est connue pour être « propre », les pureté des contrôles de données sont toujours exécutées.
    • La commande DBCC se termine mais signale des problèmes d’incohérence des données. Si c’est le cas, vous devez nettoyer la base de données pour supprimer les incohérences et puis essayez à nouveau d’exécuter la commande DBCC. Vous devez spécifier l’option DATA_PURITY de la commande DBCC jusqu'à ce que la base de données est signalée comme sain.
  • Si l’option PHYSICAL_ONLY est spécifiée lors de l’exécution de la commande DBCC CHECKDB ou DBCC CHECKTABLE, les pureté des contrôles de données ne sont pas effectuées.

SYMPTÔMES

Données non valides ou non valides peuvent ont été stockées dans la base de données SQL Server dans les versions antérieures pour les raisons suivantes :
  • Données non valides a été présentes dans la source lors de l’utilisation des méthodes d’insertion en bloc, tel que l’utilitaire bcp.
  • Données non valides a été passées à travers les appels d’événement RPC apportées à SQL Server.
  • Autres causes potentielles de corruption de données physiques à gauche de la valeur de colonne dans un état non valide.
Si vous avez des données non valides dans une colonne d’une table, vous pouvez rencontrer des problèmes en fonction du type d’opération effectuée sur les données non valides. Toutefois, il est également possible qu’aucun problème ne s’affichent et que les données non valides ne seront pas découverts jusqu'à ce que vous exécutez une commande DBCC CHECKDB ou DBCC CHECKTABLE sur SQL Server 2005 et versions ultérieures.

Certains des problèmes que vous pouvez le constater en raison de la présence de données non valides incluent (mais ne sont pas limitées à) :
  • Violations d’accès ou d’autres types d’exceptions lors de l’exécution de requêtes sur la colonne concernée.
  • Résultats incorrects renvoyés par les requêtes exécutées sur la colonne concernée.
  • Erreurs ou problèmes lorsque les statistiques en cours de génération contre les colonnes concernées.
  • Messages d’erreur comme suit :
    Msg 9100, niveau 23, état 2, ligne 1 index endommagé a peut-être détecté. Exécutez DBCC CHECKDB.

DATA_PURITY rapport de problème

Lorsque vous exécutez un DBCC CHECKDB ou DBCC CHECKTABLE avec l’option DATA_PURITY est activée (ou la pureté de données exécutent des vérifications automatiquement) et non valides les données existent dans les tables vérifiées par les commandes DBCC, la sortie DBCC inclut des messages supplémentaires qui indiquent des problèmes avec les données. Certains exemples de messages d’erreur qui indiquent des problèmes de pureté de données sont les suivants :
Résultats DBCC pour « account_history ».
Msg 2570, niveau 16, état 2, ligne 1
Page (1:1073), 33 en objet d’emplacement de code 1977058079, index ID 0, 129568478265344 de l’ID de partition, unité d’allocation ID 129568478265344 (type « données dans la ligne »). Valeur de la colonne « account_name_japan » est hors limites pour le type de données « nvarchar ». Mettre à jour la colonne une valeur autorisée.

Msg 2570, niveau 16, état 2, ligne 1
Page (1:1156), 120 en objet d’emplacement de code 1977058079, index ID 0, 129568478265344 de l’ID de partition, unité d’allocation ID 129568478265344 (type « données dans la ligne »). Valeur de la colonne « account_name_japan » est hors limites pour le type de données « nvarchar ». Mettre à jour la colonne une valeur autorisée.
Il y a 153137 lignes dans les pages de 1080 pour objet « account_history ».
CHECKDB trouvé 0 erreurs d’allocation et 338 erreurs de cohérence dans la table « account_history » (objet ID 1977058079).
CHECKDB trouvé 0 erreurs d’allocation et 338 erreurs de cohérence de base de données 'BadUnicodeData'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d’erreur, contactez votre administrateur système.
Résultats DBCC pour 'table1'.
Msg 2570, niveau 16, état 3, ligne 1
Page (1:154), slot 0 dans l’objet ID 2073058421, index ID 0, 72057594038321152 de l’ID de partition, unité d’allocation ID 72057594042318848 (type « données dans la ligne »). Valeur de la colonne « col2 » est hors limites pour le type de données « réel ». Mettre à jour la colonne une valeur autorisée.
Il y a 4 lignes de 2 pages pour objet « table1 ».
CHECKDB a trouvé 0 erreurs d’allocation et les erreurs de 1 cohérence dans la table 'table1' (objet ID 2073058421).
CHECKDB trouvé 0 erreurs d’allocation et 1 erreurs de cohérence de base de données 'realdata'. Exécution de DBCC terminée. Si DBCC vous a adressé des messages d’erreur, contactez votre administrateur système.
Résultats DBCC pour « table2 ».
Msg 2570, niveau 16, état 3, ligne 1
Page (1:155), slot 0 dans l’objet ID 2105058535, index ID 0, 72057594038452224 de l’ID de partition, unité d’allocation ID 72057594042449920 (type « données dans la ligne »). Valeur de la colonne « col2 » est hors limites pour le type de données « decimal ». Mettre à jour la colonne une valeur autorisée.
Il y a 4 lignes dans les pages de 1 pour objet « table2 ».
CHECKDB a trouvé 0 erreurs d’allocation et les erreurs de 1 cohérence dans la table « table2 » (objet ID 2105058535).
CHECKDB trouvé 0 erreurs d’allocation et 1 erreurs de cohérence de base de données 'realdata'. Exécution de DBCC terminée. Si DBCC vous a adressé des messages d’erreur, contactez votre administrateur système.
Résultats DBCC pour « Tableau3 ».
Msg 2570, niveau 16, état 3, ligne 1
Page (1:157), slot 0 dans l’objet ID 2121058592, index ID 0, 72057594038517760 de l’ID de partition, unité d’allocation ID 72057594042515456 (type « données dans la ligne »). Valeur de la colonne « col2 » est hors limites pour le type de données « datetime ». Mettre à jour la colonne une valeur autorisée.
Il existe 3 lignes dans les pages de 1 pour objet « Tableau3 ».
CHECKDB a trouvé 0 erreurs d’allocation et les erreurs de 1 cohérence dans la table « Tableau3 » (objet ID 2121058592).
CHECKDB trouvé 0 erreurs d’allocation et 1 erreurs de cohérence de base de données 'realdata'. Exécution de DBCC terminée. Si DBCC vous a adressé des messages d’erreur, contactez votre administrateur système.
Pour chaque ligne qui contient une valeur de colonne non valide, une erreur 2570 est générée.

Résolution du problème de pureté des données

Les erreurs 2570 ne peut pas être réparés à l’aide d’une des options de réparation DBCC. C’est parce qu’il est impossible à DBCC pour déterminer quelle valeur doit être utilisée pour remplacer la valeur de colonne non valide. Par conséquent, la valeur de colonne doit être mis à jour manuellement.

Pour effectuer une mise à jour manuelle, vous devez rechercher la ligne qui pose problème. Il existe deux façons de procéder.
  • Exécuter une requête sur la table qui contient les valeurs non valides pour rechercher les lignes qui contiennent les valeurs non valides.
  • Utiliser les informations de l’erreur 2570 pour identifier les lignes qui ont une valeur non valide.
Nous allons étudier ces deux méthodes en détail ci-dessous, à l’aide d’exemples pour rechercher les lignes qui ont des données non valides.

Une fois que vous trouvez la ligne correcte, une décision doit être faite sur la nouvelle valeur qui sera utilisée pour remplacer les données existantes de non valides. Cette décision doit être très soigneusement en fonction sur la plage de valeurs qui fonctionneront pour l’application, ainsi que l’organisation logique pour cette ligne particulière de données. Les choix sont :
  • Si vous connaissez la valeur qu’il convient, affectez-lui cette valeur spécifique.
  • Définir une valeur par défaut acceptables.
  • Définissez la valeur de colonne avec la valeur NULL.
  • Définissez la valeur de la colonne à la valeur minimale ou maximale pour ce type de données de la colonne.
  • Si vous pensez que la ligne spécifique n’est pas de toute utilisation sans une valeur valide pour la colonne, vous pouvez supprimer cette ligne.

Recherche de lignes avec des valeurs non valides à l’aide de requêtes de T-SQL

Le type de requête dont vous avez besoin d’exécuter pour rechercher des lignes qui ont des valeurs non valides en fonction du type de données de la colonne qui a signalé un problème. Si vous examinez le message d’erreur 2570, vous remarquerez deux éléments importants d’informations qui vous aideront à cela. Dans l’exemple suivant, la valeur de la colonne « account_name_japan » est hors limites pour le type de données « nvarchar ». Nous pouvons facilement identifier la colonne qui contient le problème ainsi que le type de données de la colonne. Par conséquent, une fois que vous connaissez les données de type et de colonne, vous pouvez formuler la requête pour rechercher les lignes qui contiennent des valeurs non valides pour cette colonne, sélectionner les colonnes nécessaires pour identifier cette ligne (comme les prédicats dans une clause WHERE) pour les plus à jour ou supprimer.

Type de données Unicode :
SELECT col1 ,DATALENGTH(account_name_japan) as Length ,account_name_japan FROM account_history
WHERE DATALENGTH(account_name_japan) % 2 != 0


Type de données float :
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from the CHECKDB output
SELECT col1, col2 FROM table1
WHERE col2<>0.0 AND (col2 < 2.23E-308 OR col2 > 1.79E+308) AND (col2 < -1.79E+308 OR col2 > -2.23E-308)

Type de données real :
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from -- the CHECKDB output
SELECT col1, col2 FROM testReal
WHERE col2<>0.0 AND (col2 < CONVERT(real,1.18E-38) OR col2 > CONVERT(real,3.40E+38)) AND (col2 < CONVERT(real,-3.40E+38) OR col2 > CONVERT(real,-1.18E-38))
ORDER BY col1; -- checks for real out of range

Decimal et Numeric type de données :
SELECT col1 FROM table2WHERE col2 > 9999999999.99999 
OR col1 < -9999999999.99999

Gardez à l’esprit que vous devrez ajuster les valeurs en fonction de la précision et l’échelle à laquelle vous avez défini la colonne decimal ou numeric. Dans l’exemple ci-dessus, la colonne a été définie en tant que decimal(15,5) de col2.

Date des données au moment du type :
Vous devrez exécuter deux requêtes différentes pour identifier les lignes qui contiennent des valeurs non valides pour la colonne de date heure.
SELECT col1 FROM table3WHERE col2 < '1/1/1753 12:00:00 AM' OR col2 > '12/31/9999 11:59:59 PM'

SELECT col1 FROM table3 WHERE
((DATEPART(ms,col2)+ (1000*DATEPART(s,col2)) + (1000*60*DATEPART(mi,col2)) + (1000*60*60*DATEPART(hh,col2)))/(1000*0.00333))
> 25919999

Recherche de lignes avec une valeur non valide à l’aide de l’emplacement physique :

Vous pouvez utiliser cette méthode si vous ne parvenez pas à trouver les lignes d’intérêt à l’aide de la méthode de T-SQL expliquée ci-dessus. Dans le message d’erreur 2570, l’emplacement physique de la ligne qui contient la valeur non valide est imprimé. Par exemple, examinez le message suivant :
Page (1:157), slot 0 dans l’objet ID 2121058592, index ID 0, 72057594038517760 de l’ID de partition, unité d’allocation ID 72057594042515456 (type « données dans la ligne »). Valeur de la colonne « col2 » est hors limites pour le type de données « datetime ». Mettre à jour la colonne une valeur autorisée.
Dans ce message, vous remarquerez les informations : Page (1:157), slot 0. Voici les informations nécessaires identifier la ligne. L’identificateur est 1, le PageInFile est 157 et la SlotId est 0. Une fois que vous avez ces informations, vous devez exécuter la commande, comme suit :
DBCC TRACEON ( 3604 )DBCC PAGE ( realdata , 1 , 157 , 3 )

Cette commande va imprimer tout le contenu d’une page. Paramètres de la commande DBCC PAGE sont les suivants :
  • nom de la base de données
  • Identificateur de fichier
  • PageInFile
  • option d’impression
Une fois que vous exécutez la commande suivante, vous remarquerez de sortie qui contient des informations semblables au format suivant :
Slot 0  Offset 0x60 Length 19 Record Type = PRIMARY_RECORD Record  Attributes = NULL_BITMAP Memory Dump @0x44D1C060 00000000: 10001000 01000000
ffffffff ffffffff †................ 00000010:
0200fc†††††††††††††††††††††††††††††††... Slot 0 Column 0 Offset 0x4 Length 4 col1 = 1 Slot 0 Column 1 Offset 0x8 Length 8 col2 = Dec 31 1899 19:04PM Slot 1 Offset 0x73 Length 19 Record Type = PRIMARY_RECORD Record
Attributes = NULL_BITMAP Memory Dump @0x44D1C073 00000000: 10001000 02000000
0ba96301 f8970000 †..........c..... 00000010:
0200fc†††††††††††††††††††††††††††††††... Slot 1 Column 0 Offset 0x4 Length 4
col1 = 2 Slot 1 Column 1 Offset 0x8 Length 8 col2 = Jul 8 2006 9:34PM Slot 2
Offset 0x86 Length 19 Record Type = PRIMARY_RECORD Record Attributes =
NULL_BITMAP Memory Dump @0x44D1C086 00000000: 10001000 03000000 0ba96301
f8970000 †..........c..... 00000010: 0200fc†††††††††††††††††††††††††††††††...
Slot 2 Column 0 Offset 0x4 Length 4 col1 = 3 Slot 2 Column 1 Offset 0x8 Length
8 col2 = Jul 8 2006 9:34PM
Dans cette sortie, vous voyez clairement les valeurs de colonne pour la ligne qui vous intéressent. Dans ce cas, vous devez la ligne stockée dans l’emplacement 0 de la page. Dans le message d’erreur, vous savez que col2 est celui avec le problème. Vous pouvez donc prendre la valeur de col1 pour Slot 0 et l’utiliser en tant que le prédicat de la clause WHERE de votre instruction de mise à jour ou l’instruction delete.

Avertissement Nous vous conseillons d’utiliser la première méthode (c'est-à-dire, utilisez T-SQL des requêtes pour trouver les informations requises). Utilisez la commande DBCC PAGE uniquement en dernier recours. Prendre le plus grand soin lorsque vous utilisez cette commande dans un environnement de production. Il est conseillé de restaurer la base de données de production sur un serveur de test, puis obtenir toutes les informations requises à l’aide de DBCC PAGE puis effectuez les mises à jour sur le serveur de production. Comme toujours, assurez-vous de conserver une sauvegarde prêt au cas où quelque chose se passe mal et vous devez revenir à une version antérieure de la base de données.

Références

Pour plus d’informations sur l’instruction DBCC CHECKDB, consultez la rubrique « DBCC CHECKDB (Transact-SQL) » sur le site Web de Microsoft Developer Network (MSDN) à l’adresse suivante :Pour plus d’informations sur les problèmes connus dans SQL Server 2000, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
CORRIGER des 900335 : opération de récupération automatique de la base de données de la 2000 de SQL Server peut échouer si un index contient un type de données FLOAT ou un type de données REAL, et ce type de données contient une valeur NaN

Pour plus d’informations sur les événements RPC, consultez la rubrique « Appel d’une procédure stockée (OLE DB) » sur le site Web MSDN suivant :Pour plus d’informations sur les différents types de données, consultez la rubrique « Appel d’une procédure stockée (OLE DB) » sur le site Web MSDN suivant :Pour plus d’informations sur les conventions de valeur de point flottant, visitez le site Web Intel suivant :Microsoft fournit des informations pour contacter des sociétés tierces afin de vous aider à obtenir une aide technique. Ces coordonnées peuvent changer sans préavis. Microsoft ne garantit pas l'exactitude des informations de contact de ces tiers.
Propriétés

ID d'article : 923247 - Dernière mise à jour : 17 janv. 2017 - Révision : 1

Commentaires