Estamos vendo erros de aplicação (exceções) que reportam o log de transações"está cheio devido a ACTIVE_TRANSACTION". Não há transações pendentes informadas por DBCC OPENTRAN.
Em execução, DBCC SQLPERF('logspace')vejo que o tamanho do log é de apenas 1,3 MB, mas o espaço de log usado está reportando 107,7%
Este banco de dados é configurado com um arquivo de log Maxsize superior a 2 TB, o tamanho inicial é 2 MB, com Autogrowth definido como 10%. O modelo de recuperação está definido como Simples.
Como o espaço de log utilizado pode ser superior a 100% e, com tanto espaço disponível, por que seria gerada uma exceção?
Responder1
Procure o(s) culpado(s)
Você poderia corrersp_WhoIsActivee veja quem está executando o quê e examine a lógica desses processos em execução/transações ativas. Verifique se alguma consulta T-SQL pode ser otimizada para ser executada mais rapidamente ou como transações menores, de modo que libere o espaço livre não utilizado no arquivo de log mais rapidamente para reutilização.
É possível por design
Modelo de recuperação simples do SQL Server
Cada transação ainda é gravada no log de transações, mas assim que a transação for concluída e os dados forem gravados no arquivo de dados, o espaço usado no arquivo de log de transações agora poderá ser reutilizado por novas transações.
Já vi casos em que uma transação de longa duração aumentou enormemente o log de transações em uma SIMPLEconfiguração de modelo de recuperação. Essa transação realmente falhou e demorou o mesmo tempo para ser revertida. Portanto, transações de longa duração, mau desempenho ou consultas mal escritas e não otimizadas podem causar esse problema.
Depois que o espaço for alocado para um SIMPLEarquivo de log de transações do banco de dados do modelo de recuperação comespaço livre no log de transações não utilizadooupor crescimento automático a partir do espaço livre no nível do sistema operacional, o arquivo de log de transações reterá o novo espaço até que ocorra uma operação de redução de arquivo, por exemplo DBCC SHRINKFILE (database_log, 2048).
Importante:Quando ocorre uma operação de redução de arquivo, por exemplo DBCC SHRINKFILE (database_log, 2048), ela apenas liberará o espaço de log não utilizado no log de transações como espaço livre de volta para o sistema operacional. As transações ativas em execução gravadas no log de transações não serão liberadas durante uma operação de redução de arquivo.
Reduzindo o arquivo de log
O problema de reduzir o arquivo de log é que na próxima vez que uma transação enorme ou uma consulta mal escrita for executada, o arquivo de log será preenchido novamente e você precisará repetir a operação de redução. Encontre e resolva a raiz do problema para obter uma solução permanente para esse problema. Enquanto isso, continue reduzindo o arquivo de log.
Corrija a causa raiz
A raiz do problema provavelmente é uma consulta, portanto, determinar quem está fazendo o quê, entrar em contato com eles e relatar o problema com suas descobertas colocaria pressão sobre eles para corrigir sua lógica para não ocupar as partições de espaço em disco do servidor; veja como otimizar a lógica para consultar o ajuste de desempenho.
Às vezes, a causa raiz não é uma transação de longa duração – por exemplo, pode ser que alguém tenha configurado a replicação e nunca a tenha desmontado adequadamente. Comece verificando
log_reuse_wait_desc in sys.databases:SELECT name, log_reuse_wait_desc FROM sys.databases;Tenha em mente, porém, que isso é apenas um resumo do motivo pelo qual o log não pode diminuir AGORA.
Então, se você não encontrar nada de interessante lá, você poderegistrar sp_WhoIsActive em uma tabela para saber quando as pessoas fazem um
BEGIN TRANe deixar a sessão aberta por horas. Procure transações de longa duração, converse com o proprietário e veja se ele consegue fazer seu trabalho em partes menores, em vez de uma transação gigante.
Metadados de espaço de arquivo de log
DBCC SQLPERF(logspace)é um comando absolutamente funcional se você estiver interessado apenas no consumo dos arquivos de log do seu banco de dados. Ele fornece o tamanho cumulativo de cada arquivo de log de cada banco de dados na instância do SQL Server, bem como a quantidade de espaço consumido (como uma porcentagem do tamanho total do arquivo de log). Uma desvantagem é o fato de os resultados serem agregados ao banco de dados. Se você tiver vários arquivos de log, os resultados serão exibidos no nível do banco de dados e não no nível do arquivo.Embora este comando DBCC seja útil quando você está revisando problemas que surgem devido ao agendamento inadequado de backup de log ou ao dimensionamento incorreto do arquivo de log, ele não fornece todas as informações necessárias para tomar decisões informadas sobre o dimensionamento de seus arquivos de log, ajustando a frequência do agendamento de backup. ou modelo de recuperação.