Cet article traite d’un problème qui se produit lors de l’exécution d’une requête d’index ColumnStore en cluster dans Microsoft SQL Server 2014. Cet article fournit une solution à ce problème.
Résumé
Lorsque vous utilisez une requête qui analyse un index ColumnStore groupé dans Microsoft SQL Server 2014, il se peut que vous receviez des résultats de requête partiels dans de rares cas. Ce problème se produit lors de l’exécution de l’opération suivante.
Étape 1
Une instruction Transact-SQL [insertion ou insertion en bloc] insérer des données dans une table ayant un index ColumnStore clusterisé. Au cours de cette opération, les conditions suivantes s’appliquent :
-
Lorsque l’instruction Transact-SQL atteint le seuil rowgroup, elle ferme rowgroup R1 qui comporte le segment S1.
-
Segment S1 points vers le dictionnaire local D1.
-
L’instruction continue d’insérer des lignes dans la nouvelle rowgroup R2.
-
Lorsque rowgroup R1 est fermé, le dictionnaire local D1 ne doit pas nécessairement être fermé. Si le dictionnaire D1 dispose toujours de l’espace disponible, vous pouvez le laisser ouvert et le réutiliser pour le nouveau rowgroup R2.
Étape 2
Si l’instruction Transact-SQL est terminée de manière anormale ou annulée avant la fermeture du nouveau rowgroup R2, les conditions suivantes s’appliquent :
-
Les changements de métadonnées de ColumnStore se produisent dans les sous-transactions qui s’valident indépendamment de la transaction externe.
-
À ce stade, rowgroup R1 persiste dans la table système dans un État « en construction » ou invisible, et le segment S1 fait référence au dictionnaire D1.
-
Il n’existe aucune ligne créée dans la table système pour le dictionnaire D1. En effet, l’instruction Transact-SQL n’a jamais la possibilité de fermer la ligne existante. Par conséquent, la ligne existante est conservée.
Étape 3
Dans une situation classique, si la tâche en arrière-plan du Data Mover s’exécute après la fin de l’instruction Transact-SQL, la tâche en arrière-plan supprime le R1 rowgroup invisible et le segment S1. Si une nouvelle instruction Transact-SQL est démarrée et crée rowgroup R3 ayant un nouveau segment S3 qui nécessite un nouveau dictionnaire local, vous ne pouvez pas réutiliser l’ID interne du dictionnaire D1. En effet, l’État en mémoire de ColumnStore assure le suivi des ID de dictionnaire utilisés. Par conséquent, segment S3 fera référence à un nouveau dictionnaire D2.Remarque Cette étape est une condition courante. Par conséquent, il n’y a aucune corruption.
Étape 4
Si SQL Server perd l’État en mémoire du dictionnaire D1 avant que la tâche du Data Mover n’entre en vigueur (et fonctionne comme décrit à l’étape 3), le problème décrit dans cet article se produit.Remarque
-
Cet événement se produit pour l’une des raisons suivantes :
-
SQL Server se charge de la surcharge de la mémoire et le contenu en mémoire du dictionnaire D1 est expulsé de la mémoire.
-
L’instance de SQL Server est redémarrée.
-
La base de données qui contient l’index ColumnStore groupé est déconnectée, puis reconnectée.
-
-
Après que l’un de ces événements se produisait et que SQL Server recharge les structures en mémoire, il n’y a aucun enregistrement qu’un dictionnaire D1 et son ID interne existait. En effet, le dictionnaire D1 n’a pas été conservé dans les tables système lorsque l’instruction Transact-SQL a été achevée ou conceled.
-
Si la tâche en arrière-plan du Data Mover s’exécute à ce stade, il n’y a aucune erreur, car les conditions décrites dans l’étape 3 s’appliquent.
-
Si un nouveau rowgroup R3 est créé avant le démarrage de la tâche en arrière-plan du Data Mover en arrière-plan (par la puce précédente), SQL Server attribue le même ID interne au nouveau dictionnaire D1 et il fait référence au dictionnaire D1 pour le segment S3 dans rowgroup R3.
-
Lorsque la tâche en arrière-plan du Data Mover s’exécute après l’action précédente, celle-ci dépose rowgroup R1 invisible et ses segments S1 conjointement avec le nouveau dictionnaire D1. Ce problème se produit car le Data Mover s’estime que le nouveau dictionnaire D1 et le dictionnaire d’origine D1 sont les mêmes.Remarque Lorsque cette situation se produit, vous ne pouvez pas interroger le contenu de rowgroup R3.
Résolution
Le problème a été résolu dans les mises à jour cumulatives de SQL Server suivantes :
Mise à jour cumulative 1 pour SQL server 2014 SP1 cumulative update 8 pour SQL Server 2014Le correctif de ce problème est également inclus dans les mises à jour du GDR (General Distribution Release) suivantes :
Mise à jour de sécurité pour SQL Server 2014 QFE Cette mise à jour inclut la mise à jour cumulative 8, ce correctif important et les mises à jour de sécurité MS15-058 nécessaires.Mise à jour de sécurité pour SQL Server 2014 GDR Cette mise à jour inclut ce correctif important et les correctifs de sécurité cumulés par le biais de MS15-058.Mise à jour de sécurité pour SQL Server 2014 Service Pack 1 GDR Cette mise à jour inclut uniquement ce correctif important.
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs et les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
Informations supplémentaires
Messages d’erreurDans une base de données actuellement affectée, si vous exécutez DBCC CHECKDB après avoir appliqué ce correctif, vous recevez le message d’erreur suivant :
MSG 5289, niveau 16, état 1, ligne 1 ColumnStore index’ICC’sur table t’comporte une ou plusieurs valeurs de données qui ne correspondent pas à des valeurs de données dans un dictionnaire. Restaurez les données à partir d’une sauvegarde.
Dans une base de données actuellement affectée, lorsque vous exécutez une requête qui analyse les tables affectées après avoir appliqué ce correctif, vous recevez le message d’erreur suivant :
MSG 5288, niveau 16, état 1, ligne 1 ColumnStore index comporte une ou plusieurs valeurs de données qui ne correspondent pas à des valeurs de données dans un dictionnaire. Pour plus d’informations, exécutez DBCC CHECKDB.
Si vous recevez ces erreurs, vous pouvez enregistrer les données non corrompues en bloc en exportant les données des colonnes non affectées/RowGroups, puis en rechargeant les données après avoir déposé ou créé l’index ColumnStore groupé. Vous devez activer l’indicateur de suivi 10207 pour supprimer l’erreur 5288 et revenir à l’ancien comportement pour ignorer les RowGroups endommagés. RemarqueLes messages d’erreur 5288 et 5289 sont générés pour ce rowgroup R3 qui comporte segment S3. L’indicateur de suivi 10207 est utilisé pour extraire les segments de rowgroup R3 qui ne sont pas affectés par le dictionnaire D1 manquant.
Requête pour les bases de données affectéesPour déterminer si la base de données qui contient les index ColumnStore est déjà affectée 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 toutes les bases de données qui contiennent des 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ée.
-
Exécutez cette requête au cours d’une période quand il n’y a aucune activité de création de RowGroups ou de modification de l’état des RowGroups existants. Par exemple, les activités suivantes peuvent modifier l’état de RowGroups : index, réorganiser, insertion en bloc, décompresser les magasins Delta. Avant d’exécuter la requête, vous pouvez désactiver la tâche du Data Mover de tuple en arrière-plan à l’aide de l’indicateur de suivi 634. Utilisez cette commande pour désactiver la tâche en arrière-plan : DBCC tracen (634,-1). Après l’exécution de la requête, 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’il n’y a pas de commandes d’insertion/de sélection et de sélection en bloc permettant d’insérer des données dans les tables qui utilisent l’index ColumnStore lorsque cette requête est en cours d’exécution. Nous vous recommandons de suivre 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 à ».
