Este artigo descreve um problema que ocorre durante uma consulta de um índice columnstore clusterizado no Microsoft SQL Server 2014. Este artigo fornece uma solução para este problema.
Resumo
Quando você usa uma consulta que examina um índice columnstore clusterizado no Microsoft SQL Server 2014, você pode, em condições raras, receber resultados de consulta parcial. Esse problema ocorre quando a seguinte operação é executada.
Etapa 1
Uma instrução Transact-SQL [INSERT ou BULK-INSERT] insere dados em uma tabela que tem índice columnstore clusterizado. Durante essa operação, as seguintes condições se aplicam:
-
Quando a instrução Transact-SQL atinge o limite de grupo de grupo, ele fecha o grupo de discagem R1 que tem o segmento S1.
-
O segmento S1 aponta para o dicionário local D1.
-
A instrução continua a inserir linhas para o novo grupo de linhas R2.
-
Quando o ' grupo de R1 ' é fechado, o dicionário local D1 também não precisa ser fechado. Se o dicionário D1 ainda tiver espaço disponível, você poderá deixá-lo aberto e reutilizá-lo para o novo grupo de-grupo R2.
Etapa 2
Se a instrução Transact-SQL for finalizada anormalmente ou cancelada antes de fechar o novo grupo de itens R2, as seguintes condições se aplicam:
-
As alterações de metadados Columnstore ocorrem em subtransaçãos que são confirmadas independentemente da transação externa.
-
Nesse ponto, o o R1 do grupo de R1 persiste na tabela do sistema em um "em construção" ou em um estado invisível, e Segmente o dicionário de referências S1 D1.
-
Não há nenhuma linha criada na tabela do sistema para o dicionário D1. Isso ocorre porque a instrução Transact-SQL nunca tem oportunidade de fechar a linha existente. Portanto, a linha existente persiste.
Etapa 3
Em uma situação típica, se a tarefa em segundo plano do Tuple mover iniciar após a conclusão da instrução Transact-SQL, a tarefa em segundo plano removerá o grupo de trabalho invisível R1 e o segmento S1. Se uma nova instrução Transact-SQL for iniciada agora e criar o multigroup R3 que tenha um novo segmento S3 que exija um novo dicionário local, você não poderá reutilizar a ID interna do dicionário D1. Isso ocorre porque o estado de memória do columnstore mantém o controle das IDs de dicionário usadas. Portanto, o segmento S3 fará referência a um novo dicionário D2.Observação A condição nesta etapa é uma condição comum. Portanto, não ocorre nenhuma corrupção.
Etapa 4
Se o SQL Server perder o estado da memória do dicionário D1 antes de a tarefa do Tuple mover entrar em vigor (e executar conforme descrito na etapa 3), o problema descrito neste artigo ocorrerá.Observações
-
Esse evento ocorre por qualquer um dos seguintes motivos:
-
O SQL Server experimenta a sobrecarga de memória e o conteúdo da memória do dicionário D1 são removidos da memória.
-
A instância do SQL Server é reiniciada.
-
O banco de dados que contém o índice columnstore clusterizado fica offline e, em seguida, fica online novamente.
-
-
Após qualquer um desses eventos e o SQL Server recarrega as estruturas na memória, não há registro que um dicionário D1 e sua identificação interna existia. Isso ocorre porque o dicionário D1 não era mantido nas tabelas do sistema quando a instrução Transact-SQL foi encerrada ou Conceled.
-
Se a tarefa em segundo plano do Tuple mover começar nesse ponto, não ocorrerá nenhum erro porque as condições descritas na etapa 3 se aplicam.
-
Se um novo DATAGROUP R3 for criado antes da início da tarefa em segundo plano do Tuple mover (de acordo com o item do marcador anterior), o SQL Server atribuirá a mesma ID interna a um novo dicionário D1 e referenciará o dicionário D1 para segmento S3 no grupo de trabalho R3.
-
Quando a tarefa em segundo plano do Tuple mover é iniciada após a ação anterior, ela cai o grupo de grupos invisíveis R1 e seus respectivos segmentos em S1 com o novo dicionário D1. Isso ocorre porque o Tuple mover considera que o novo dicionário D1 e o dicionário original D1 de que as referências S1 são iguais.Observação Quando essa condição ocorre, você não pode consultar o conteúdo do grupo de grupos R3s.
Resolução
O problema foi corrigido primeiro nas seguintes atualizações cumulativas do SQL Server:
Atualização cumulativa 1 da atualização cumulativa 8 para SQL server 2014 SP1para SQL Server 2014A correção para esse problema também está incluída nas seguintes atualizações GDR (versão geral de distribuição):
Atualização de segurança do SQL Server 2014 QFE Esta atualização inclui a atualização cumulativa 8, esta correção importante e as atualizações de segurança MS15-058 necessárias.Atualização de segurança do SQL Server 2014 GDR Esta atualização inclui esta correção importante e correções de segurança cumulativas por meio do MS15-058.Atualização de não segurança do SQL Server 2014 Service Pack 1 GDR Esta atualização inclui apenas esta correção importante.
Cada nova atualização cumulativa do SQL Server contém todos os hotfixes e todas as correções de segurança incluídas na atualização cumulativa anterior. Veja as atualizações cumulativas mais recentes do SQL Server:
Informações adicionais
Mensagens de erroEm um banco de dados atualmente afetado, se você executar DBCC CHECKDB depois de aplicar essa correção, você receberá a seguinte mensagem de erro:
MSG 5289, nível 16, estado 1, linha 1 o índice columnstore clusterizado ' CCI ' na tabela ' t ' tem um ou mais valores de dados que não correspondem a valores de dados em um dicionário. Restaure os dados de um backup.
Em um banco de dados atualmente afetado, quando você executa uma consulta que examina as tabelas afetadas depois de aplicar essa correção, você recebe a seguinte mensagem de erro:
MSG 5288, nível 16, estado 1, índice Columnstore linha 1 tem um ou mais valores de dados que não correspondem a valores de dados em um dicionário. Para obter mais informações, execute DBCC CHECKDB.
Se você receber esses erros, pode salvar os dados não corrompidos exportando os dados de colunas/grupos não afetados e, em seguida, recarregando os dados após soltar ou criar o índice columnstore clusterizado. Você deve habilitar o sinalizador de rastreamento 10207 para suprimir o erro do 5288 e reverter para o comportamento antigo de ignorar grupos corrompidos. ObservaçãoAs mensagens de erro 5288 e 5289 são geradas para esse Multigrupo R3 que tem segmento S3. O sinalizador de rastreamento 10207 é usado para extrair os segmentos do grupo de grupos R3 que não são afetados pelo dicionário ausente D1.
Consultar bancos de dados afetadosPara determinar se o banco de dados que contém índices columnstore já está afetado por esse problema, execute a seguinte consulta:
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
Observações
-
Você precisa executar essa consulta em todos os bancos de dados que contenham índices de columnstore no servidor que está executando o SQL Server. Um conjunto de resultados vazio indica que o banco de dados não é afetado.
-
Execute esta consulta durante um período em que não houver atividade que crie novos grupos ou altere o estado dos grupos de grupos existentes. Por exemplo, as seguintes atividades podem modificar o estado de grupos de itens: compilação de índice, reorganização de índice, inserção em massa, agrupamentos de tupla compactação de repositórios Delta. Antes de executar a consulta, você pode desabilitar a tarefa de Tuple mover em segundo plano usando o sinalizador de rastreamento 634. Use este comando para desabilitar a tarefa em segundo plano: rastreamento DBCC (634,-1). Após a conclusão da execução da consulta, lembre-se de reabilitar a tarefa em segundo plano usando o comando: DBCC TRACEOFF (634,-1). Verifique também se não há comandos de inserção em massa/BCP/selecionar em inserindo dados nas tabelas que usam o índice columnstore enquanto essa consulta está em execução. É recomendável usar essas etapas para impedir que a consulta retorne falsos positivos.
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".
