Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

CORRECTIF : Erreur d'incohérence des métadonnées après changement des partitions de table et de supprimer des groupes de fichiers et les fichiers correspondants

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3095958
Symptômes
Considérez le scénario suivant :
  • Vous avez deux tables partitionnées dans Microsoft SQL Server 2014, et les partitions de la première table sont mappées à différents fichiers et groupes de fichiers en utilisant le même schéma de partition et de la fonction.
  • Vous basculez l'une de ces partitions à la deuxième table, et puis vous tronquez la seconde table.
  • Vous déposez les fichiers et groupes de fichiers qui sont associés à la partition commutée.
  • Vous exécutez une instruction SELECT sur la seconde table.
Dans ce scénario, le message d'erreur suivant s'affiche :

Msg 606, niveau 21, état 1
Incohérence des métadonnées. Id du groupe de fichiersid du groupe de fichiers> spécifiées pour la tablenom de la table> n'existe pas. Exécutez DBCC CHECKDB ou CHECKCATALOG.

Lorsque vous exécutez DBCC CHECKDB/CHECKTABLE, le message d'erreur suivant s'affiche :

Impossible de traiter l'indexIndexName> de tableTableName> car le groupe de fichiers (ID de groupe de fichiersFileGroupNumber>) n'est pas valide.
Résolution
Le problème a été résolu tout d'abord dans les mises à jour cumulatives suivantes de SQL Server : Recommandation : Installez la mise à jour cumulative la plus récente pour SQL Server
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs logiciels et des correctifs de sécurité qui ont été inclus dans la précédente mise à jour cumulative. Nous vous recommandons de télécharger et d'installer les dernières mises à jour cumulatives pour SQL Server :


Remarque Ce correctif empêche uniquement les occurrences futures de ce problème. Si vous avez déjà rencontré ce problème, exportez vos données dans une nouvelle base de données sans toute corruption de métadonnées existants. Pour ce faire, procédez comme suit :
  1. Pour déterminer si une partition est un groupe de fichiers non valide, exécutez la requête suivante pour voir si elle retourne un résultat :
    SELECT * FROM sys.allocation_units AS au WHERE au.data_space_id NOT IN (SELECT data_space_id FROM sys.filegroups)
  2. Afficher la table avec la corruption de métadonnées à nouveau.

    Si la requête de l'étape 1 retourne un résultat, la partition avec les métadonnées corrompue vous empêche d'affichage (sélectionnez * à partir de) toutes les lignes de la table. Pour contourner ce problème, supprimez cette partition défectueux.

    Remarque
    la partition défectueux doit être vide. Dans le cas contraire, les fichiers et le groupe de fichiers où elle était n'impossible pas ont été ignorés ou supprimés.

    Pour ce faire, déplacez cette partition dans une autre table qui utilise le même schéma de partitionnement. Cette table peut être simplement une table fictive. Utilisez l'ID_Conteneur à partir de la requête à l'étape 1 et la faire correspondre avec l'id_partition à partir de sys.partitions. (Assurez-vous de noter le numéro_partition.) Le numéro_partition permet d'exécuter un commutateur de TABLE ALTER PARTITION de la table qui a été non affichable dans la table fictive. La table fictive doit avoir le même jeu de colonnes et utiliser le même schéma de partition. Votre requête pour trouver la partition incohérente peut ressembler au suivant :

    SELECT au.container_id, au.data_space_id, p.partition_number FROM sys.partitions AS p JOIN sys.allocation_units AS au ON p.partition_id = au.container_id LEFT JOIN sys.filegroups AS fgs ON fgs.data_space_id = au.data_space_id WHERE object_id = OBJECT_ID('MyTableName') AND fgs.data_space_id IS NULL;
  3. Copie les données la table précédemment non affichable dans la nouvelle base de données.
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3095958 - Dernière mise à jour : 04/12/2016 00:47:00 - Révision : 2.0

Microsoft SQL Server 2014 Service Pack 1

  • kbfix kbqfe kbexpertiseadvanced kbsurveynew kbmt KB3095958 KbMtfr
Commentaires