CORRECTIF : Partielle des résultats d'une requête d'un index ordonné en clusters columnstore dans SQL Server 2014

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: 3067257
Cet article décrit un problème qui se produit durant une requête d'un index ordonné en clusters columnstore dans Microsoft SQL Server 2014. Cet article fournit une résolution à ce problème.
Résumé
Lorsque vous utilisez une requête qui recherche un index ordonné en clusters columnstore dans Microsoft SQL Server 2014, vous pouvez, dans de rares conditions, recevoir des résultats d'une requête partielle.

Ce problème se produit lors de l'exécution de l'opération suivante.
Étape 1
Une instruction Transact-SQL [INSERT ou insertion en bloc] insère des données dans une table qui a clustered index columnstore. Au cours de cette opération, les conditions suivantes s'appliquent :
  • Lorsque l'instruction Transact-SQL atteint le seuil rowgroup, il ferme rowgroup R1 qui a segment S1.
  • Segment S1 pointe vers le dictionnaire local D1.
  • L'instruction continue d'insérer des lignes rowgroup nouvel R2.
  • Lorsque rowgroup R1 est fermé, le dictionnaire local D1 n'a pas également être fermé. Si le dictionnaire D1 a encore la quantité d'espace disponible, vous pouvez laisser ouverte et la réutiliser pour la nouvelle rowgroup R2.
Étape 2
Si l'instruction Transact-SQL est s'est terminée anormalement ou annulée avant de se fermer la rowgroup nouveau R2, les conditions suivantes s'appliquent :
  • Modification des métadonnées ColumnStore se produire dans les sous-transactions commit indépendamment de la transaction externe.
  • À ce stade, rowgroup que R1 est conservée dans la table système dans un « en chantier » ou INVISIBLE et segment S1 référence dictionnaire D1.
  • Il n'y a aucune ligne créée dans la table système de dictionnaire D1. C'est parce que l'instruction Transact-SQL a jamais la possibilité de fermer la ligne existante. Par conséquent, la ligne existante est conservée.
Étape 3
En général, si la tâche d'arrière-plan mover tuple démarre après la fin de l'instruction Transact-SQL, la tâche d'arrière-plan supprime la rowgroup invisible R1 et le segment de S1. Si une nouvelle instruction Transact-SQL est démarrée maintenant et crée rowgroup R3 qui a un nouveau segment S3 qui nécessite un nouveau dictionnaire local, vous ne pouvez pas réutiliser l'ID interne du dictionnaire D1. C'est parce que l'état en mémoire de la columnstore assure le suivi du dictionnaire de codes qui sont utilisées. Par conséquent, le segment S3 référencera nouveau dictionnaire D2.

Remarque La condition à cette étape est une condition commune. Par conséquent, aucune corruption se produit.
Étape 4
Si SQL Server perd l'état en mémoire du dictionnaire D1 avant de tuple mover prend effet (et exécute comme décrit à l'étape 3), le problème qui est décrit dans cet article se produit.

Remarques
  • Cet événement se produit pour une des raisons suivantes :
    • SQL Server connaît la surcharge de mémoire et le contenu en mémoire du dictionnaire D1 sont éliminées de la mémoire.
    • L'instance de SQL Server est redémarré.
    • La base de données qui contient l'index columnstore ordonné en clusters est mis hors connexion et puis revient en ligne.
  • Après l'un de ces événements se produisent et SQL Server recharge les structures en mémoire, il n'existe aucun enregistrement qui un dictionnaire D1 et ses propres ID existait. C'est parce que le dictionnaire D1 a été conservée pas dans les tables système lorsque l'instruction Transact-SQL a été interrompue ou conceled.
  • Si la tâche d'arrière-plan mover tuple démarre à ce stade, aucune erreur de se produire, car les conditions décrites à l'étape 3 s'appliquent.
  • Si un nouveau rowgroup R3 est créé avant le démarrage de la tâche d'arrière-plan mover tuple (par l'élément de liste à puces précédente), SQL Server affecte le même numéro d'identification interne à nouveau dictionnaire D1 et il fait référence au dictionnaire D1 pour segment S3 dans rowgroup R3.
  • Lorsque la tâche d'arrière-plan mover tuple démarre après l'action précédente, il dépose rowgroup invisible R1 et ses segments S1 et nouveau dictionnaire D1. Cela se produit parce que le tuple mover considère que ce dictionnaire nouveau de D1 et le dictionnaire d'origine D1 que S1 références sont les mêmes.

    Remarque Lorsque cela se produit, vous ne pouvez pas interroger le contenu du rowgroup R3.
Résolution
Le problème a été corrigé tout d'abord dans les mises à jour cumulatives suivantes de SQL Server :


Le correctif de ce problème est également inclus dans les mises à jour de version (GDR) distribution générale suivante :

Mise à jour de sécurité pour SQL Server 2014 QFE
Cette mise à jour inclut 8 mise à jour Cumulative, ce correctif important et les mises à jour de sécurité MS15-058 requis.

Mise à jour de sécurité pour SQL Server 2014 GDR
Cette mise à jour inclut ce correctif important et correctifs de sécurité cumulatifs via MS15-058.

Mise à jour non sécurisée pour GDR 2014 Service Pack 1 de SQL Server
Cette mise à jour inclut uniquement ce correctif important.

À propos des mises à jour cumulatives 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. Consultez les dernières mises à jour cumulatives pour SQL Server :
Plus d'informations

Messages d'erreur

Dans une base de données actuellement affectée, si vous exécutez DBCC CHECKDB après avoir appliqué ce correctif, vous recevez les message d'erreur suivant :
Msg 5289, niveau 16, état 1, ligne 1
Columnstore en cluster d'index « ICC » sur la table ' t ' possède une ou plusieurs valeurs de données qui ne correspondent pas aux valeurs de données dans un dictionnaire. Restaurer les données à partir d'une sauvegarde.

Dans une base de données actuellement affecté, lorsque vous exécutez une requête qui recherche les tables concernées après avoir appliqué ce correctif, le message d'erreur suivant s'affiche :
Msg 5288, niveau 16, état 1, ligne 1
Index ColumnStore possède une ou plusieurs valeurs de données qui ne correspondent pas aux valeurs de données dans un dictionnaire. Exécutez DBCC CHECKDB pour plus d'informations.

Si vous recevez ces erreurs, vous pouvez enregistrer les données non endommagées en bloc, exportation des données des colonnes/rowgroups pas affecté et en le rechargeant les données après avoir supprimer ou créer l'index columnstore ordonné en clusters. Vous devez activer l'indicateur de Trace 10207 supprimer l'erreur 5288 et revenir à l'ancien comportement de rowgroups endommagé est ignorée.

Remarque : Messages d'erreur 5288 et 5289 sont générés pour cette rowgroup R3 avec segment S3. L'indicateur de trace 10207 est utilisé pour extraire des segments du rowgroup R3 qui ne sont pas affectés par le dictionnaire manquant D1.

Requêtes pour les bases de données affectées

Pour déterminer si la base de données qui contient l'index de columnstore est déjà affecté par ce problème, exécutez la requête suivante :
select         object_name(i.object_id) as table_name,        i.name as index_name,        p.partition_number,        count(distinct s.segment_id) as damaged_rowgroups from        sys.indexes i        join sys.partitions p on p.object_id = i.object_id and p.index_id = i.index_id        join sys.column_store_row_groups g on g.object_id = i.object_id and g.index_id = i.index_id and g.partition_number = p.partition_number        join sys.column_store_segments s on s.partition_id = p.partition_id and s.segment_id = g.row_group_id where         i.type in (5, 6)        and s.secondary_dictionary_id <> -1         and g.state_description = 'COMPRESSED'        and s.secondary_dictionary_id not in        (               select dictionary_id from sys.column_store_dictionaries d               where d.hobt_id = p.hobt_id and d.column_id = s.column_id        ) group by         object_name(i.object_id),        i.name,        p.partition_number 

Remarques
  • Vous devez exécuter cette requête sur chaque base de données qui contient l'index de columnstore sur le serveur qui exécute SQL Server. Un jeu de résultats vide indique que la base de données n'est pas affecté.
  • Exécutez cette requête pendant une période lorsqu'il n'y a aucune activité Créer nouveau rowgroups ou modifier l'état de rowgroups existant. Par exemple, les activités suivantes peuvent modifier l'état de rowgroups : création de l'index, index reorganize, insertion en bloc, mover tuple compression delta magasins.

    Avant d'exécuter la requête, vous pouvez désactiver la tâche mover de tuple en arrière-plan à l'aide de l'indicateur de trace 634. Utilisez cette commande pour désactiver la tâche d'arrière-plan : DBCC TRACEON (634, -1). Une fois la requête terminée en cours d'exécution, n'oubliez pas de réactiver la tâche en arrière-plan à l'aide de la commande : DBCC TRACEOFF (634, -1).

    Assurez-vous également qu'aucune commande BULK INSERT/BCP/SELECT-en insertion de données dans les tables qui utilisent columnstore index pendant l'exécution de cette requête.

    Il est recommandé d'utiliser ces étapes pour empêcher la requête de renvoyer des faux positifs.
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 : 3067257 - Dernière mise à jour : 07/22/2015 17:41:00 - Révision : 3.0

Microsoft SQL Server 2014 Service Pack 1, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Standard

  • kbqfe kbsurveynew kbexpertiseadvanced kbfix kbmt KB3067257 KbMtfr
Commentaires