Início / dba / Perguntas / 93588
Accepted
user3469285
Asked: 2015-02-24 09:25:14 +0800 CST

O log de transações do banco de dados 'database_name' está cheio devido a 'XTP_CHECKPOINT'

  • 772

Eu tenho uma pergunta sobre XTP_CHECKPOINT.

Estou usando o SQL Server 2014. Tenho um banco de dados que está no modo de modelo de recuperação SIMPLES. Também está sendo replicado.

Não há transações abertas. Já rodei DBCC OPENTRANe retorna:

"Nenhuma transação aberta ativa."

Mas continuo recebendo esta mensagem sempre que tento criar ou descartar uma tabela ou excluir dados:
(substituí meu nome real do banco de dados pela palavra database_name)

"O log de transações do banco de dados 'database_name' está cheio devido a 'XTP_CHECKPOINT'"

Alguém sabe por que isso pode estar acontecendo e, mais importante, como posso fazer isso parar?

E sim, o banco de dados realmente está no modo de modelo de recuperação SIMPLES. ou seja, o log de transações deve truncar automaticamente.

Aliás, outro banco que tenho em full recovery mode fez a mesma coisa, começou a retornar o mesmo erro:

O log de transações do banco de dados 'database_name' está cheio devido a 'XTP_CHECKPOINT'

Tentei alterar as configurações de crescimento do log para crescimento ilimitado, mas não permitia, retornando o mesmo erro.

Posso reproduzir o problema sem nenhum material XTP, exceto apenas o grupo de arquivos. Veja como: http://pastebin.com/jWSiEU9U

sql-server sql-server-2014

4 respostas

  1. Best Answer

    Eu tive um problema semelhante: não tive replicação, mas uma vez usei a tabela Memory Optimized como teste, banco de dados no modo de recuperação simples, mas meus logs de transação não foram truncados. O truncamento manual, mesmo logo após um backup completo, dava o erro:

    Não é possível reduzir o arquivo de log X porque o arquivo de log lógico localizado no final do arquivo está em uso.

    Um ponto de verificação manual falhou:

    Msg 41315, Nível 16, Estado 4, Linha N A operação do ponto de verificação falhou no banco de dados X.

    Um ponto de verificação manual só foi bem-sucedido logo após reiniciar o serviço SQL, o que levaria a um estado de recuperação de 4 horas devido ao tamanho do meu banco de dados Multi Tb. Também tentei definir o crescimento automático para um tamanho específico, mas acabou dando no mesmo: encher os logs de transação até não sobrar espaço.

    Finalmente, depois de dias e noites tentando e pesquisando, encontrei a solução para o meu problema instalando o Cumulative Update 3 para SQL Server 2014 SP1

    • 10

  2. Primeiro, certifique-se de que a replicação não está causando isso, conforme declarado no item de conexão, o "log_wait_reuse_desc=XTP_CHECKPOINT não significa necessariamente que o trabalhador do ponto de verificação XTP está retendo o truncamento de log". então comece executando sp_repltranse certifique-se de que todos os dados foram distribuídos.

    Depois, há este pequeno trecho aqui:

    "isso acontece em um banco de dados, que possui um grupo de arquivos com otimização de memória, independentemente de haver tabelas com otimização de memória ou não.

    A solução atual é definir o AutoGrown para um tamanho fixo. Ou alterar o modo de recuperação para Simples e reduzir o log."

    Portanto, se a limpeza da replicação não funcionar, tente o seguinte:

    checkpoint;
dbcc shrinkfile (Logfile, truncateonly)
alter database [database] modify file (filename = 'TRANSACTIONLOG', FILEGROWTH = 5MB)

    Não é declarado se isso é para o arquivo de log ou para os arquivos de banco de dados, mas vamos começar tentando os arquivos de log e, caso contrário, tente definir os arquivos de banco de dados para crescimento fixo:

    • 9

  3. Consegui contornar o problema adicionando outro arquivo de log, o que me permitiu executar um backup completo, ajustar o tamanho do arquivo de log principal e limitar o crescimento, além de remover o arquivo de log extra adicionado para resolver o problema XTP_CHECKPOINT.

    • 5

  4. Já passei por isso com um cliente. Os arquivos de dados FILESTREAM de log e na memória estavam na mesma unidade. Eles criaram um novo arquivo de log (poucos sugeriram isso), mas o sistema não pode CHECKPOINT, pois falha ao criar os arquivos de ponto de verificação na memória (*.HKCKP).

    Tente liberar espaço na unidade com os dados FILESTREAM na memória.

    • 1

relate perguntas