Início / dba / Perguntas / 217768
Accepted
Lee Hill
Asked: 2018-09-18 00:42:40 +0800 CST

Os VLFs do log de transações do SQL Server não estão sendo liberados (Status 2) no banco de dados de log enviado

  • 772

Vi alguns posts semelhantes ao meu cenário, mas nada que realmente resolva meu problema.

Cenário:

  • A reconstrução de índice de rotina acontece, uma vez por semana, às 2h da manhã de sábado.
  • O arquivo de log cresce cerca de 15x o tamanho normal.
  • O backup do log de transações é feito (a cada 10 minutos, 24 horas por dia, 7 dias por semana).
  • O backup COMPLETO é feito todos os dias às 3h.
  • Os VLFs permanecem "ativos" (status 2) quando olho paradbcc loginfo
  • log_reuse_wait_descestá relatando "LOGBACKUP" emsys.databases
  • dbcc opentrannão está relatando nenhuma transação ativa
  • @@version: Microsoft SQL Server 2005 - 9.00.5069.00 (X64) 22 de agosto de 2012 18:02:46 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition (64 bits) no Windows NT 6.1 (Build 7601: Service Pack 1)

Problema:

Portanto, meu problema é simples, devido a restrições de hardware e parâmetros de tempo, preciso manter o tamanho do log de transações o menor possível. acredito que o motivo de não estar liberando o espaço é porque os VLFs estão ativos e ele acha que precisa fazer um LOGBACKUP para liberar, mas depois de inúmeros backups de log, log_reuse_wait_descainda está informando aguardando um backup de log!

Eu poderia mudar o modelo de recuperação para simples, encolher e voltar, mas isso quebra minha cadeia de LSN e minha implementação de Log Shipping, então não é realmente uma solução viável!

TIA.

sql-server sql-server-2005

3 respostas

  1. Best Answer

    Depois de mais algumas investigações, descobri que, quando era necessário fazer um backup de log grande, o tempo necessário para produzir o arquivo de backup trn estava passando por um período de tempo limite de 5 minutos definido pelo lanmanserverserviço.

    O erro relatado foi error 64 (error not found)que na verdade é um problema bastante comum, aparentemente , conforme descrito aqui ; portanto, mesmo que o backup de log estivesse sendo criado, o mecanismo SQL não pôde verificar se o backup foi bem-sucedido.

    Por sua vez, os VLFs não foram definidos como 0, portanto, vendo os problemas descritos na pergunta.

    obrigado pela ajuda pessoal, mas acho que a raiz do problema foi o erro relatado (não mencionei isso, pois pude ver os arquivos de backup e o logshipping ainda os estava processando, então não achei que fosse parte do mesmo problema!)

    • 2

  2. Você precisa investigar seus VLFs. Quantos você tem? Dos que você tem, quantos estão em uso (status = 2)? E, dos que estão em uso, onde estão?

    Não se preocupe muito com o status "LOGBACKUP", você terá isso assim que não estiver no modelo de recuperação simples e também tiver mais de um VLF usado (o que é bastante normal). Mais algumas informações aqui: http://karaszi.com/large-transaction-log-file

    • 0

  3. Primeiro: você está em uma versão sem suporte do SQL Server. Você deve considerar fortemente a atualização. Tenho certeza que você provavelmente está cansado de ouvir isso =) Mas é uma preocupação real e algo que pode ser relevante para esse problema (em outras palavras, pode ser um bug na versão do SQL Server 2005 que você está ligado).

    É possível que os VLFs não estejam sendo limpos porque:

    1. A taxa de transferência de transações em seu sistema é relativamente baixa e, portanto, os CHECKPOINTs não estão ocorrendo e, portanto, os VLFs não podem ser limpos. Você pode ver se esse é o seu problema executando um CHECKPOINT manual em seu banco de dados e, em seguida, verificando se os VLFs são limpos (status 0) após o próximo backup de log. Observe que isso pode ser uma operação intensiva de E/S:

      USE YourDatabaseName;
GO

CHECKPOINT;

    2. Outra possibilidade é que os VLFs sejam grandes e, portanto, sob operação normal, seus registros de log podem permanecer em um VLF por um longo tempo antes de passar para o próximo.

    Também pode ser uma combinação de 1 e 2 acima, ou algo completamente diferente.

    Seria útil se você pudesse postar os detalhes de DBCC LOGINFO(você já mencionou informações resumidas em alguns lugares, mas neste momento acho que os detalhes são necessários).

    Observe que uma possível solução para o seu problema é simplesmente não fazer esse INDEX REBUILD, portanto, não incorrendo no crescimento massivo de log em primeiro lugar. Se a reconstrução estiver sendo feita devido a problemas de desempenho percebidos, você pode considerar outras soluções (atualização de estatísticas, por exemplo).

    • 0

relate perguntas