MSSQLSERVER_2570

S’applique à :SQL Server

Détails

Attribut Valeur
Nom du produit SQL Server
ID de l’événement 2570
Source de l’événement MSSQLSERVER
Composant SQLEngine
Nom symbolique DBCC_COLUMN_VALUE_OUT_OF_RANGE
Texte du message Page P_ID, slot S_ID de l'ID d'objet O_ID, ID d'index I_ID, ID de partition PN_ID, ID d'unité d'allocation A_ID (type TYPE). La valeur COLUMN_NAME de colonne est hors limite pour le type de données "DATATYPE". Mettez la colonne à jour avec une valeur valide.

Explication

La valeur de colonne contenue dans la colonne spécifiée est en dehors de la plage de valeurs possibles pour le type de données de colonne. Si vous avez des données non valides dans une colonne de table, vous pouvez rencontrer des problèmes, en fonction du type d’opérations effectuées sur les données non valides. Toutefois, il est également possible qu’aucun problème n’apparaisse et que les données non valides ne seront pas découvertes tant que vous n’exécutez pas une ou DBCC CHECKTABLE une DBCC CHECKDB commande.

Certains symptômes que vous pouvez remarquer en raison de la présence de données non valides incluent (mais ne sont pas limités à) :

  • Violations d’accès ou autres exceptions lors de l’exécution de requêtes sur la colonne affectée.
  • Résultats incorrects retournés par les requêtes exécutées sur la colonne affectée.
  • Erreurs ou problèmes lorsque les statistiques sont générées sur la colonne affectée.
  • Messages d’erreur tels que ceux suivants :

    Msg 9100, Level 23, State 2, Line <LineNum> Possible corruption d’index détectée. Exécutez DBCC CHECKDB.

vérifications de DATA_PURITY

Lorsque vous exécutez une commande DBCC CHECKDB ou DBCC CHECKTABLE , SQL Server effectue des validations de « pureté des données » des valeurs de colonne dans chaque ligne de chaque table de la base de données. Ces vérifications sont effectuées pour s’assurer que les valeurs stockées dans les colonnes sont valides. Autrement dit, la validation garantit que les valeurs ne sont pas hors limites du domaine associé au type de données des colonnes. La nature de la validation effectuée dépend du type de données de la colonne. La liste non exhaustive suivante donne quelques exemples :

Type de données de colonne Type de validation des données effectuée
Caractère Unicode La longueur des données doit être un multiple de 2.
Datetime Le champ date doit être compris entre le 1er janvier 1753 et le 31 décembre 9999. Le champ d’heure doit être antérieur à « 11:59:59.997PM ».
Réel et flottant Vérifiez l’existence de valeurs à virgule flottante non valides telles que SNAN, QNAN, NINF, ND, PD et PINF.

Tous les types de données ne sont pas vérifiés pour la validité des données de colonne. Seules les valeurs stockées hors limites peuvent être vérifiées. Par exemple, le tinyint type de données a une plage valide de 0 à 255 et est stocké dans un octet unique (qui ne peut stocker que des valeurs comprises entre 0 et 255), de sorte que la vérification de la valeur n’est pas nécessaire.

Notes

Ces vérifications sont activées par défaut et ne peuvent pas être désactivées. Il n’est donc pas nécessaire d’utiliser explicitement l’option DATA_PURITY lors de l’exécution d’une ou DBCC CHECKTABLE d’une DBCC CHECKDB commande. Toutefois, si vous utilisez l’option PHYSICAL_ONLY avec DBCC CHECKDB ou DBCC CHECKTABLEsi les vérifications de pureté des données ne sont pas effectuées.

DATA_PURITY rapport de problèmes

Lorsque vous exécutez une DBCC CHECKDB ou DBCC CHECKTABLE une commande avec l’option DATA_PURITY activée (ou que les vérifications de pureté des données sont exécutées automatiquement) et que les données non valides existent dans les tables vérifiées par les DBCC commandes, la DBCC sortie inclut d’autres messages qui indiquent les problèmes liés aux données. Les exemples de messages d’erreur suivants indiquent des problèmes de pureté des données :

DBCC results for "account_history". 
Msg 2570, Level 16, State 2, Line <LineNum> 
Page (1:1073), slot 33 in object ID <ObjectID>, index ID 0, partition ID <PartitionID>, alloc unit ID <UnitID> (type "In-row data"). Column "account_name" value is out of range for data type "nvarchar". Update column to a legal value. 
 
Msg 2570, Level 16, State 2, Line <LineNum> 
Page (1:1156), slot 120 in object ID <ObjectID>, index ID 0, partition ID <PartitionID>, alloc unit ID <UnitID> (type "In-row data"). Column "account_name" value is out of range for data type "nvarchar". Update column to a legal value.
There are 153137 rows in 1080 pages for object "account_history". 
CHECKDB found 0 allocation errors and 338 consistency errors in table "account_history" (object ID <ObjectID>). 
CHECKDB found 0 allocation errors and 338 consistency errors in database '<DatabaseName>'. 
DBCC execution completed. If DBCC printed error messages, contact your system administrator. 

DBCC results for 'table1'. 
Msg 2570, Level 16, State 3, Line <LineNum> 
Page (1:154), slot 0 in object ID <ObjectID>, index ID 0, partition ID <PartitionID>, alloc unit ID <UnitID> (type "In-row data"). Column "col2" value is out of range for data type "real". Update column to a legal value. 
There are 4 rows in 2 pages for object "table1". 
CHECKDB found 0 allocation errors and 1 consistency errors in table 'table1' (object ID <ObjectID>). 
CHECKDB found 0 allocation errors and 1 consistency errors in database 'realdata'. DBCC execution completed. If DBCC printed error messages, contact your system administrator. 

DBCC results for 'table2'. 
Msg 2570, Level 16, State 3, Line <LineNum> 
Page (1:155), slot 0 in object ID <ObjectID>, index ID 0, partition ID <PartitionID>, alloc unit ID <UnitID> (type "In-row data"). Column "col2" value is out of range for data type "decimal". Update column to a legal value. 
There are 4 rows in 1 pages for object "table2". 
CHECKDB found 0 allocation errors and 1 consistency errors in table 'table2' (object ID <ObjectID>). 
CHECKDB found 0 allocation errors and 1 consistency errors in database 'realdata'. DBCC execution completed. If DBCC printed error messages, contact your system administrator. 

DBCC results for 'table3'. 
Msg 2570, Level 16, State 3, Line <LineNum> 
Page (1:157), slot 0 in object ID <ObjectID>, index ID 0, partition ID <PartitionID>, alloc unit ID <UnitID> (type "In-row data"). Column "col2" value is out of range for data type "datetime". Update column to a legal value. 
There are 3 rows in 1 pages for object "table3". 
CHECKDB found 0 allocation errors and 1 consistency errors in table 'table3' (object ID <ObjectID>). 
CHECKDB found 0 allocation errors and 1 consistency errors in database 'realdata'. DBCC execution completed. If DBCC printed error messages, contact your system administrator. 

For every row that contains an invalid column value, a 2570 error is generated. 

Cause :

Les données non valides ou hors plage peuvent avoir été stockées dans la base de données SQL Server pour les raisons suivantes :

  • Les données non valides ont été insérées dans SQL Server via des événements d’appel de procédure distante (RPC).
  • D’autres causes potentielles d’altération des données physiques rendent la valeur de colonne non valide.

Résoudre le problème de pureté des données

Les erreurs 2570 ne peuvent pas être réparées à l’aide DBCC des options de réparation. La raison est que DBCC cela ne peut pas déterminer la valeur à utiliser pour remplacer la valeur de colonne non valide. Par conséquent, la valeur de colonne doit être mise à jour manuellement. Pour effectuer une mise à jour manuelle, vous devez trouver la ligne qui présente le problème. Utilisez l’une des méthodes suivantes pour rechercher la ligne :

  • Exécutez une requête sur la table qui contient les valeurs non valides pour rechercher les lignes qui contiennent les valeurs non valides.
  • Utilisez les informations de l’erreur 2570 pour identifier les lignes qui ont des valeurs non valides.

Les deux méthodes sont détaillées dans les sections suivantes et fournissent des exemples pour rechercher les lignes qui ont des données non valides.

Une fois que vous avez trouvé la ligne correcte, une décision doit être prise sur la nouvelle valeur qui sera utilisée pour remplacer les données non valides existantes. Cette décision doit être prise très soigneusement, en fonction de la plage de valeurs applicable à l’application et de la signification logique de cette ligne de données particulière. Les options suivantes sont disponibles :

  • Si vous savez quelle valeur elle doit être, définissez-la sur cette valeur spécifique.
  • Définissez-la sur une valeur par défaut acceptable.
  • Définissez la valeur de colonne sur NULL.
  • Définissez la valeur de colonne sur la valeur maximale ou minimale pour ce type de données de la colonne.
  • Si vous pensez que la ligne spécifique n’est pas utile sans valeur valide pour la colonne, supprimez complètement cette ligne.

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

Le type de requête que vous devez exécuter pour rechercher des lignes qui ont des valeurs non valides dépend du type de données de la colonne signalant un problème. Si vous examinez le message d’erreur 2570, vous remarquerez deux informations importantes qui peuvent vous aider à résoudre ce problème. Dans l’exemple suivant, la valeur de la colonne account_name est hors plage pour le type nvarcharde données. Nous pouvons facilement identifier la colonne avec le problème et le type de données de la colonne impliquée. Ainsi, une fois que vous connaissez le type de données et la colonne impliqués, vous pouvez formuler des requêtes pour rechercher les lignes qui contiennent des valeurs non valides pour cette colonne, puis sélectionner les colonnes nécessaires pour identifier cette ligne (comme prédicats dans une WHERE clause) pour toute mise à jour ou suppression ultérieure.

Type de données Unicode
SELECT col1, DATALENGTH(account_name) AS Length, account_name  
FROM account_history 
WHERE DATALENGTH(account_name) % 2 != 0
Type de données Float

Exécutez l’extrait de code suivant en passant col1 à votre ou vos colonnes clés primaires réelles, col2 à la colonne de l’erreur 2570 et table1 à la table de la CHECKDB sortie.

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 réel

Exécutez l’extrait de code suivant en passant col1 à votre ou vos colonnes clés primaires réelles, col2 à la colonne de l’erreur 2570 et table1 à la table de la CHECKDB sortie.

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 
Types de données décimaux et numériques
SELECT col1 FROM table2 
WHERE col2 > 9999999999.99999  
OR col1 < -9999999999.99999

N’oubliez pas que vous devez ajuster les valeurs en fonction de la précision et de l’échelle avec lesquelles vous avez défini la ou numeric la decimal colonne. Dans l’exemple ci-dessus, la colonne est définie en tant que col2 decimal(15,5).

Type de données Datetime

Vous devez exécuter deux requêtes différentes pour identifier les lignes qui contiennent des valeurs non valides pour la datetime colonne.

SELECT col1 FROM table3 
WHERE 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

Rechercher des lignes avec des valeurs non valides à l’aide de l’emplacement physique

Vous pouvez utiliser cette méthode si vous ne trouvez pas les lignes avec des valeurs non valides à l’aide de la méthode T-SQL. 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 in object ID <ObjectID>, index ID 0, partition ID <PartitionID>, alloc unit ID <UnitID> (type "In-row data"). Column "col2" value is out of range for data type "datetime". Update column to a legal value. 

Dans ce message, vous remarquez Page (1:157), slot 0. Il s’agit des informations dont vous avez besoin pour identifier la ligne. C’est, c’est 157PageInFile , et c’est SlotId0.FileId1

Une fois que vous disposez de ces informations, vous devez exécuter la commande suivante :

DBCC TRACEON (3604)
DBCC PAGE (realdata , 1 , 157 , 3)

Notes

Cette commande imprime l’intégralité du contenu d’une page. Les paramètres de la DBCC PAGE commande sont les suivants :

  • Database name: nom de la base de données.
  • File number: numéro de fichier du fichier de base de données.
  • Page number: numéro de la page à examiner.
  • Print option: paramètre facultatif qui détermine le niveau de détail de sortie.

Une fois que vous avez exécuté cette commande, vous remarquerez une sortie qui contient des informations similaires 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 pouvez clairement voir les valeurs de colonne pour la ligne d’intérêt. Dans ce cas, vous avez besoin de la ligne stockée dans slot 0 la page. À partir du message d’erreur, vous savez qu’il col2 s’agit du problème. Vous pouvez donc prendre la valeur de col1Slot 0 cette instruction et l’utiliser comme prédicat dans la WHERE clause de votre instruction update ou delete.

Avertissement

Nous vous recommandons d’utiliser la première méthode (autrement dit, utilisez des requêtes T-SQL pour rechercher les informations requises). Utilisez la DBCC PAGE commande uniquement comme dernier recours. Prenez le plus grand soin lorsque vous utilisez cette commande dans un environnement de production. Il est recommandé de restaurer la base de données de production sur un serveur de test, d’obtenir toutes les informations requises à l’aide DBCC PAGE, puis d’effectuer les mises à jour sur le serveur de production. Comme toujours, veillez à conserver une sauvegarde prête en cas de problème, et vous devez revenir à une copie antérieure de la base de données.

Voir aussi