Essa parece ser uma pergunta comum na maioria dos fóruns e em toda a Web. É feita aqui em muitos formatos que normalmente são assim:

No SQL Server -

• Quais são algumas das razões pelas quais o log de transações cresce tanto?
• Por que meu arquivo de log é tão grande?
• Quais são algumas maneiras de impedir que esse problema ocorra?
• O que faço quando me coloco no caminho certo com a causa subjacente e quero colocar meu arquivo de log de transações em um tamanho saudável?

Uma resposta mais curta:

Você provavelmente possui uma transação de longa execução (manutenção do índice? Exclusão ou atualização em lote grande?) Ou está no modo de recuperação "padrão" (mais abaixo, sobre o que se entende por padrão) Fulle não fez um backup de log (ou não os tomem com frequência suficiente).

Se for um problema do modelo de recuperação, a resposta simples pode ser Alternar para o Simplemodo de recuperação se você não precisar de recuperação pontual e backups regulares de log. Muitas pessoas, no entanto, dão essa resposta sem entender os modelos de recuperação. Leia para entender por que isso importa e depois decida o que você faz. Você também pode começar a fazer backups de log e permanecer em Fullrecuperação.

Pode haver outros motivos, mas estes são os mais comuns. Essa resposta começa a se aprofundar nos dois motivos mais comuns e fornece algumas informações básicas sobre o porquê e como os motivos subjacentes, além de explorar outros motivos.

Uma resposta mais longa: quais cenários podem fazer com que o log continue crescendo? Há muitos motivos, mas geralmente esses são os dois padrões a seguir: Há um mal-entendido sobre modelos de recuperação ou há transações de execução longa. Leia para detalhes.

Principal motivo 1/2: Não compreendendo os modelos de recuperação

( Estar no modo de recuperação total e não fazer backups de log - esse é o motivo mais comum - a grande maioria dos que estão enfrentando esse problema ) .

Embora essa resposta não seja um mergulho profundo nos modelos de recuperação do SQL Server, o tópico dos modelos de recuperação é crítico para esse problema.

No SQL Server, existem três modelos de recuperação :

• Full,
• Bulk-Logged e
• Simple.

Por Bulk-Loggedenquanto, ignoraremos que dizeremos que é um modelo híbrido e a maioria das pessoas que estão nesse modelo está lá por uma razão e entende os modelos de recuperação.

Os dois nos preocupamos e sua confusão são a causa da maioria dos casos de pessoas com este problema são Simplee Full.

Intermissão: Recuperação em Geral

Antes de falarmos sobre modelos de recuperação: vamos falar sobre recuperação em geral. Se você quiser se aprofundar ainda mais neste tópico, basta ler o blog de Paul Randal e quantas postagens você quiser. Para esta pergunta, no entanto:

1. Recuperação de falha / reinicialização
   Um objetivo do arquivo de log de transações é a recuperação de falha / reinicialização . Para avançar e retroceder o trabalho que foi feito (avançar / refazer) antes de uma falha ou reiniciar e o trabalho iniciado mas não foi concluído após uma falha ou reiniciar (retroceder / desfazer). É o trabalho do log de transações verificar se uma transação foi iniciada, mas nunca foi concluída (reversão ou falha / reinicialização antes da confirmação da transação). Nessa situação, é tarefa do log dizer "Ei ... isso nunca realmente terminou, vamos reverter" durante a recuperação. Também é tarefa do log verificar que você terminou algo e que seu aplicativo cliente foi informado de que estava concluído (mesmo que ainda não tenha endurecido em seu arquivo de dados) e diga"Ei ... isso realmente aconteceu, vamos avançar, vamos fazer como os aplicativos pensam que era" após uma reinicialização. Agora há mais, mas esse é o objetivo principal.

2. Recuperação pontual
   O outro objetivo de um arquivo de log de transações é poder nos recuperar para um ponto no tempo devido a um "ops" em um banco de dados ou garantir um ponto de recuperação no caso de uma falha de hardware envolvendo os dados e / ou arquivos de log de um banco de dados. Se esse log de transações contiver os registros de transações iniciadas e concluídas para recuperação, o SQL Server poderá e poderá usar essas informações para obter um banco de dados onde estava antes de ocorrer um problema. Mas isso nem sempre é uma opção disponível para nós. Para que isso funcione, precisamos ter nosso banco de dados no modelo de recuperação correto e precisamos fazer backups de log .

Modelos de recuperação

Nos modelos de recuperação:

• Modelo de recuperação simples
  Portanto, com a introdução acima, é mais fácil falar sobre o Simple Recoverymodelo primeiro. Neste modelo, você está dizendo ao SQL Server: "Eu estou bem com você usando seu arquivo de log de transações para travar e reiniciar a recuperação ..." (Você realmente não tem escolha lá. Procure propriedades ACID e isso deve fazer sentido rapidamente). "... mas quando você não precisar mais dele para esse fim de recuperação de falha / reinicialização, vá em frente e reutilize o arquivo de log."

  O SQL Server escuta essa solicitação na Recuperação Simples e mantém apenas as informações necessárias para travar / reiniciar a recuperação. Quando o SQL Server tiver certeza de que pode se recuperar porque os dados estão protegidos para o arquivo de dados (mais ou menos), os dados que foram protegidos não são mais necessários no log e são marcados para truncamento - o que significa que são reutilizados.

• Modelo de recuperação completa
  Com Full Recovery, você está dizendo ao SQL Server que deseja recuperar para um momento específico, desde que seu arquivo de log esteja disponível ou para um momento específico coberto por um backup de log. Nesse caso, quando o SQL Server atingir o ponto em que seria seguro truncar o arquivo de log no Simple Recovery Model, ele não fará isso. Em vez disso, ele permite que o arquivo de log continue a crescer e continuará crescendo, até você fazer um backup de log (ou ficar sem espaço na unidade de arquivo de log) em circunstâncias normais.

Mudar de Simples para Cheio tem uma opção.

Existem regras e exceções aqui. Falaremos sobre transações de longa duração em profundidade abaixo.

Mas uma ressalva a ter em mente para o Modo de recuperação completa é a seguinte: se você simplesmente alternar para o Full Recoverymodo, mas nunca fizer um backup completo inicial, o SQL Server não atenderá à sua solicitação de estar no Full Recoverymodelo. Seu log de transações continuará a funcionar como está Simpleaté você alternar para o Modelo de recuperação completa e executar o seu primeiro Full Backup.

O modelo de recuperação completa sem backups de log é ruim.

Então, esse é o motivo mais comum para o crescimento descontrolado de logs? Resposta: Estar no modo de recuperação total sem ter backups de log.

Isso acontece todo o tempo com as pessoas.

Por que esse erro é tão comum?

Por que isso acontece o tempo todo? Como cada novo banco de dados obtém sua configuração inicial do modelo de recuperação, observando o banco de dados do modelo.

A configuração inicial do modelo de recuperação do modelo é sempre Full Recovery Model- até e a menos que alguém mude isso. Então, você poderia dizer que o "Modelo de recuperação padrão" é Full. Muitas pessoas não sabem disso e seus bancos de dados são executados Full Recovery Modelsem backups de log e, portanto, um arquivo de log de transações muito maior que o necessário. É por isso que é importante alterar os padrões quando eles não funcionam para sua organização e suas necessidades)

O modelo de recuperação completa com poucos backups de log é ruim.

Você também pode ter problemas aqui, não fazendo backups de log com frequência suficiente.
Fazer um backup de log por dia pode parecer bom, faz com que uma restauração exija menos comandos de restauração, mas lembre-se da discussão acima, esse arquivo de log continuará a crescer até que você faça backups de log.

Como descubro qual frequência de backup de log eu preciso?

Você precisa considerar sua frequência de backup de log com duas coisas em mente:

1. Necessidades de recuperação - esperamos que seja a primeira. No caso de a unidade que hospeda seu log de transações ficar ruim ou você sofrer uma corrupção séria que afeta seu backup de log, quantos dados podem ser perdidos? Se esse número não exceder 10 a 15 minutos, será necessário fazer o backup do log a cada 10 a 15 minutos, final da discussão.
2. Crescimento de log - Se sua organização está bem em perder mais dados, devido à capacidade de recriar facilmente naquele dia, você pode estar bem em ter um backup de log com muito menos frequência que 15 minutos. Talvez sua organização esteja bem a cada 4 horas. Mas você precisa analisar quantas transações você gera em 4 horas. Permitir que o log continue crescendo nessas quatro horas tornará um arquivo de log muito grande? Isso significa que seus backups de log demoram muito?

Principal motivo 2/2: transações de longa duração

( "Meu modelo de recuperação está bom! O log ainda está crescendo! )

Isso também pode ser uma causa de crescimento descontrolado e descontrolado de logs. Não importa o modelo de recuperação, mas muitas vezes aparece como "Mas eu estou no Modelo de Recuperação Simples - por que meu log ainda está crescendo ?!"

O motivo aqui é simples: se o SQL estiver usando esse log de transações para fins de recuperação, como descrevi acima, ele deverá voltar ao início de uma transação.

Se você tiver uma transação que leva muito tempo ou faz muitas alterações, o log não pode truncar no ponto de verificação para nenhuma das alterações que ainda estão em transações abertas ou que foram iniciadas desde o início da transação.

Isso significa que uma grande exclusão, excluindo milhões de linhas em uma instrução de exclusão, é uma transação e o log não pode truncar até que toda a exclusão seja concluída. Em Full Recovery Model, essa exclusão é registrada e pode haver muitos registros de log. O mesmo ocorre com o trabalho de otimização de índice durante as janelas de manutenção. Isso também significa que o gerenciamento deficiente da transação e a falta de atenção e fechamento de transações abertas podem realmente prejudicar você e seu arquivo de log.

O que posso fazer sobre essas transações de longa duração?

Você pode se salvar aqui:

• Dimensione adequadamente seu arquivo de log para dar conta do pior cenário possível - como sua manutenção ou grandes operações conhecidas. E ao aumentar seu arquivo de log, você deve seguir estas orientações (e os dois links para os quais ela envia) de Kimberly Tripp. O dimensionamento correto é super crítico aqui.
• Observando seu uso de transações. Não inicie uma transação no servidor de aplicativos e comece a ter longas conversas com o SQL Server e corre o risco de deixar uma aberta por muito tempo.
• Observando as transações implícitas em suas instruções DML. Por exemplo: UPDATE TableName Set Col1 = 'New Value'é uma transação. Eu não coloquei um BEGIN TRANlá e não preciso, ainda é uma transação que é confirmada automaticamente quando concluída. Portanto, se estiver executando operações em um grande número de linhas, considere agrupar essas operações em blocos mais gerenciáveis ​​e dar tempo ao log para recuperar. Ou considere o tamanho certo para lidar com isso. Ou talvez veja como alterar os modelos de recuperação durante uma janela de carregamento em massa.

Esses dois motivos também se aplicam ao envio de logs?

Resposta curta: sim. Resposta mais longa abaixo.

Pergunta: "Estou usando o envio de logs, para que meus backups sejam automatizados ... Por que ainda estou vendo o crescimento do log de transações?"

Resposta: continue a ler.

O que é o Log Shipping?

O envio de logs é exatamente o que parece - você está enviando seus backups de log de transações para outro servidor para fins de recuperação de desastres. Há alguma inicialização, mas depois disso o processo é bastante simples:

• Um trabalho para fazer backup do log em um servidor,
• um trabalho para copiar esse backup de log e
• um trabalho para restaurá-lo sem recuperação ( NORECOVERYou STANDBY) no servidor de destino.

Existem também alguns trabalhos para monitorar e alertar se as coisas não saírem conforme o planejado.

Em alguns casos, convém restaurar a remessa de logs apenas uma vez por dia ou a cada três dias ou uma vez por semana. Está bem. Mas se você fizer essa alteração em todos os trabalhos (incluindo os trabalhos de backup e cópia de log), significa que estará aguardando o tempo todo para fazer um backup de log. Isso significa que você terá muito crescimento de log - porque está no modo de recuperação completa sem backups de log - e provavelmente também significa um grande arquivo de log para copiar. Você só deve modificar o agendamento da tarefa de restauração e permitir que os backups e cópias de log ocorram com mais frequência; caso contrário, sofrerá com o primeiro problema descrito nesta resposta.

Solução de problemas gerais via códigos de status

Há outras razões além dessas duas, mas essas são as mais comuns. Independentemente da causa: existe uma maneira de analisar o motivo desse crescimento inexplicável de log / falta de truncamento e ver o que eles são.

Ao consultar a sys.databasesexibição do catálogo, é possível ver informações que descrevem o motivo pelo qual o arquivo de log pode estar aguardando truncar / reutilizar.

Há uma coluna chamada log_reuse_waitcom um ID de pesquisa do código de razão e uma log_reuse_wait_desccoluna com uma descrição do motivo da espera. No artigo on-line dos livros referenciados, encontram-se a maioria dos motivos (os que você provavelmente verá e os que podemos explicar). Os desaparecidos estão fora de uso ou para uso interno) com algumas notas sobre a espera itálico :

• 0 = Nada
  Como parece ... Não deveria estar esperando

• 1 = Ponto de verificação
  Aguardando a ocorrência de um ponto de verificação. Isso deve acontecer e você deve ficar bem - mas há alguns casos a serem procurados aqui para obter respostas ou edições posteriores.

• 2 = Backup de log
  Você está aguardando a ocorrência de um backup de log. Você os tem agendado e isso acontecerá em breve, ou você tem o primeiro problema descrito aqui e agora sabe como corrigi-lo

• 3 = Backup ou restauração ativa
  Uma operação de backup ou restauração está em execução no banco de dados

• 4 = Transação ativa
  Há uma transação ativa que precisa ser concluída (de qualquer maneira - ROLLBACKou COMMIT) antes que o backup possa ser efetuado. Este é o segundo motivo descrito nesta resposta.

• 5 = Espelhamento de banco de dados
  Um espelho está ficando para trás ou sob alguma latência em uma situação de espelhamento de alto desempenho ou o espelhamento está em pausa por algum motivo

• 6 = Replicação
  Pode haver problemas com a replicação que causariam isso - como um agente de leitor de log não sendo executado, um banco de dados pensando que está marcado para replicação que não existe mais e por vários outros motivos. Você também pode ver esse motivo e é perfeitamente normal, porque você está olhando na hora certa, assim como as transações estão sendo consumidas pelo leitor de log

• 7 = Criação de instantâneo de banco de dados
  Você está criando um instantâneo de banco de dados e verá isso se observar o momento certo enquanto um instantâneo está sendo criado

• 8 = Verificação de log
  Ainda não encontrei um problema com isso funcionando para sempre. Se você procurar por tempo suficiente e com frequência suficiente, poderá ver isso acontecer, mas isso não deve ser uma causa do crescimento excessivo do log de transações, como eu já vi.

• 9 = Uma réplica secundária do AlwaysOn Availability Groups está aplicando registros de log de transações desse banco de dados a um banco de dados secundário correspondente. Sobre a descrição mais clara até o momento ..

Como não estou realmente satisfeito com nenhuma das respostas do Stack Overflow , incluindo a sugestão mais votada, e porque há algumas coisas que gostaria de abordar que a resposta de Mike não oferece, pensei em fornecer minha entrada aqui também. Também coloquei uma cópia desta resposta.

Diminuir um arquivo de log deve ser realmente reservado para cenários em que ele encontrou um crescimento inesperado que você não espera que aconteça novamente. Se o arquivo de log crescer novamente para o mesmo tamanho, isso não será feito muito, reduzindo-o temporariamente. Agora, dependendo das metas de recuperação do seu banco de dados, estas são as ações que você deve executar.

Primeiro, faça um backup completo

Nunca faça alterações no seu banco de dados sem garantir que você possa restaurá-lo, caso algo dê errado.

Se você se preocupa com a recuperação point-in-time

(E com a recuperação pontual, quero dizer que você se preocupa em poder restaurar para algo diferente de um backup completo ou diferencial.)

Presumivelmente, seu banco de dados está no FULLmodo de recuperação. Caso contrário, verifique se é:

ALTER DATABASE yourdb SET RECOVERY FULL;

Mesmo se você estiver fazendo backups completos regulares, o arquivo de log aumentará até você realizar um backup de log - isso é para sua proteção, para não consumir desnecessariamente o espaço em disco. Você deve executar esses backups de log com bastante frequência, de acordo com seus objetivos de recuperação. Por exemplo, se você tiver uma regra comercial que declare que pode perder pelo menos 15 minutos de dados no caso de um desastre, deverá ter um trabalho que faça backup do log a cada 15 minutos. Aqui está um script que irá gerar nomes de arquivos com registro de data e hora com base no horário atual (mas você também pode fazer isso com planos de manutenção etc., apenas não escolha nenhuma das opções de redução nos planos de manutenção, elas são terríveis).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Observe que \\backup_share\deve estar em uma máquina diferente que represente um dispositivo de armazenamento subjacente diferente. Fazer backup deles na mesma máquina (ou em uma máquina diferente que use os mesmos discos subjacentes ou em uma VM diferente que esteja no mesmo host físico) não ajuda muito, pois se a máquina explodir, você perderá seu banco de dados. e seus backups. Dependendo da infraestrutura da sua rede, pode fazer mais sentido fazer backup localmente e depois transferi-lo para um local diferente nos bastidores; nos dois casos, você deseja retirá-los da máquina principal do banco de dados o mais rápido possível.

Agora, depois que você tiver backups regulares de log em execução, deve ser razoável reduzir o arquivo de log para algo mais razoável do que o que está sendo usado até agora. Isso não significa executar SHRINKFILErepetidamente até que o arquivo de log tenha 1 MB - mesmo se você estiver fazendo backup do log com frequência, ele ainda precisará acomodar a soma de todas as transações simultâneas que possam ocorrer. Os eventos de crescimento automático de arquivo de log são caros, pois o SQL Server precisa zerar os arquivos (diferente dos arquivos de dados quando a inicialização instantânea de arquivos está habilitada) e as transações do usuário precisam aguardar enquanto isso acontece. Você quer fazer essa rotina de crescimento-encolhimento-encolhimento o mínimo possível e certamente não quer que seus usuários paguem por isso.

Observe que você pode precisar fazer backup do log duas vezes antes que um encolhimento seja possível (obrigado Robert).

Portanto, você precisa criar um tamanho prático para o seu arquivo de log. Ninguém aqui pode lhe dizer o que é isso sem saber muito mais sobre o seu sistema, mas se você reduziu freqüentemente o arquivo de log e voltou a crescer, uma boa marca d'água é provavelmente 10-50% maior que a maior que já foi . Digamos que isso chegue a 200 MB e você deseja que os eventos subsequentes de crescimento automático tenham 50 MB, então você pode ajustar o tamanho do arquivo de log desta maneira:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Observe que, se o arquivo de log tiver mais de 200 MB, talvez seja necessário executar isso primeiro:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Se você não se importa com a recuperação point-in-time

Se esse é um banco de dados de teste e você não se importa com a recuperação pontual, verifique se o banco de dados está no SIMPLEmodo de recuperação.

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

A colocação do banco de dados no SIMPLEmodo de recuperação garantirá que o SQL Server reutilize partes do arquivo de log (essencialmente eliminando as transações inativas) em vez de aumentar para manter um registro de todas as transações (como a FULLrecuperação faz até o backup do log). CHECKPOINTeventos vai ajudar a controlar o registro e se certificar de que ele não precisa de crescer a menos que você gerar muita atividade t-log entre CHECKPOINTs.

Em seguida, você deve ter certeza absoluta de que esse crescimento de log deve-se realmente a um evento anormal (por exemplo, uma limpeza anual da primavera ou a reconstrução de seus maiores índices) e não ao uso diário normal. Se você reduzir o arquivo de log para um tamanho ridiculamente pequeno, e o SQL Server apenas precisar aumentá-lo novamente para acomodar sua atividade normal, o que você ganhou? Você conseguiu usar o espaço em disco liberado apenas temporariamente? Se você precisar de uma correção imediata, poderá executar o seguinte:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

Caso contrário, defina um tamanho e uma taxa de crescimento adequados. Conforme o exemplo no caso de recuperação point-in-time, você pode usar o mesmo código e lógica para determinar qual tamanho de arquivo é apropriado e definir parâmetros razoáveis ​​de crescimento automático.

Algumas coisas que você não quer fazer

• Faça backup do log com a TRUNCATE_ONLYopção e, em seguidaSHRINKFILE . Por um lado, esta TRUNCATE_ONLYopção foi preterida e não está mais disponível nas versões atuais do SQL Server. Segundo, se você estiver no FULLmodelo de recuperação, isso destruirá sua cadeia de logs e exigirá um novo backup completo.

• Desanexe o banco de dados, exclua o arquivo de log e reconecte-o . Não posso enfatizar o quão perigoso isso pode ser. Seu banco de dados pode não voltar, pode aparecer como suspeito, talvez você precise reverter para um backup (se você tiver um), etc. etc.

• Use a opção "encolher banco de dados" . DBCC SHRINKDATABASEe a opção de plano de manutenção para fazer o mesmo são más idéias, especialmente se você realmente precisar apenas resolver um problema de log. Alveje o arquivo que você deseja ajustar e ajuste-o independentemente, usando DBCC SHRINKFILEou ALTER DATABASE ... MODIFY FILE(exemplos acima).

• Reduza o arquivo de log para 1 MB . Isso parece tentador porque, ei, o SQL Server me permite fazer isso em determinados cenários e olha todo o espaço que ele libera! A menos que seu banco de dados seja somente leitura (e deve ser marcado como tal ALTER DATABASE), isso levará absolutamente a muitos eventos de crescimento desnecessários, pois o log precisa acomodar transações atuais, independentemente do modelo de recuperação. Qual é o sentido de liberar esse espaço temporariamente, para que o SQL Server possa recuperá-lo lenta e penosamente?

• Crie um segundo arquivo de log . Isso proporcionará alívio temporário para a unidade que encheu seu disco, mas é como tentar consertar um pulmão perfurado com um curativo. Você deve lidar diretamente com o arquivo de log problemático, em vez de apenas adicionar outro problema em potencial. Além de redirecionar algumas atividades do log de transações para uma unidade diferente, um segundo arquivo de log realmente não faz nada para você (diferente de um segundo arquivo de dados), pois apenas um dos arquivos pode ser usado por vez. Paul Randal também explica por que vários arquivos de log podem mordê-lo mais tarde .

Seja pro ativo

Em vez de reduzir o arquivo de log para uma quantidade pequena e permitir que ele cresça automaticamente a uma taxa pequena por conta própria, defina-o para um tamanho razoavelmente grande (que acomode a soma do seu maior conjunto de transações simultâneas) e defina um crescimento automático razoável definindo como um substituto, para que não precise crescer várias vezes para satisfazer transações únicas e, portanto, será relativamente raro que tenha que crescer durante operações comerciais normais.

As piores configurações possíveis aqui são 1 MB de crescimento ou 10% de crescimento. Engraçado, esses são os padrões do SQL Server (dos quais reclamei e solicitei alterações sem sucesso ) - 1 MB para arquivos de dados e 10% para arquivos de log. O primeiro é muito pequeno hoje em dia, e o segundo leva a eventos cada vez mais longos (digamos, seu arquivo de log tem 500 MB, primeiro crescimento é 50 MB, próximo crescimento é 55 MB, próximo crescimento é 60.5 MB , etc. etc. - e com E / S lenta, acredite, você realmente notará essa curva).

Leitura adicional

Por favor, não pare aqui; embora muitos dos conselhos que você vê por aí sobre a redução de arquivos de log sejam inerentemente ruins e até potencialmente desastrosos, algumas pessoas se preocupam mais com a integridade dos dados do que com a liberação de espaço em disco.

• Um post de blog que escrevi em 2009, quando vi algumas postagens "aqui está como reduzir o arquivo de log", surgiram .

• Uma postagem de blog que Brent Ozar escreveu há quatro anos, apontando para vários recursos, em resposta a um artigo da SQL Server Magazine que não deveria ter sido publicado .

• Um post de Paul Randal explicando por que a manutenção do t-log é importante e por que você também não deve reduzir os arquivos de dados .

• Mike Walsh tem uma ótima resposta acima, é claro, cobrindo alguns desses aspectos também, incluindo razões pelas quais você pode não conseguir reduzir seu arquivo de log imediatamente .

Você também pode ver o conteúdo do seu arquivo de log. Para fazer isso, você pode usar o não documentado fn_dblogou um leitor de log de transações, como o ApexSQL Log .

Ele não mostra índice de reorganização, mas mostra todos DML e DDL vários eventos: ALTER, CREATE, DROP, gatilho ativar / desativar, concessão / revogar permissões, objeto Renomear.

Isenção de responsabilidade: trabalho para o ApexSQL como engenheiro de suporte

Esse é o problema mais frequentemente enfrentado por quase todos os DBAs em que os logs crescem e preenchem o disco.

• Por que motivo o log de transações cresce tanto?

1. Transação ativa longa
2. Transações de log altas, como o índice reconstruir, reorganizar, inserção em massa, exclusões etc.
3. Qualquer HA como replicação, espelhamento configurado que retém o log e não permite liberar o espaço de log

• Por que meu arquivo de log é tão grande?

Verifique a log_reuse_wait_descoluna c na sys.databasestabela para saber o que está impedindo os logs de truncar:

select name, log_reuse_wait_desc 
from sys.databases

• Quais são algumas maneiras de impedir que esse problema ocorra?

Os backups de log ajudarão a controlar o crescimento do log, a menos que exista algo que esteja impedindo a reutilização dos logs.

• O que faço quando me coloco no caminho certo com a causa subjacente e quero colocar meu arquivo de log de transações em um tamanho saudável?

Se você identificou o que realmente está causando isso, tente corrigi-lo de acordo com o explicado na página abaixo.

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

Ter backups de log adequados agendados é a melhor maneira de lidar com o crescimento de logs, a menos que seja uma situação incomum.