Como você limpa o log de transações do SQL Server?


577

Não sou especialista em SQL e sou lembrado do fato toda vez que preciso fazer algo além do básico. Eu tenho um banco de dados de teste que não é grande em tamanho, mas o log de transações é definitivamente. Como limpo o log de transações?



3
Deve haver um comando no Managment Studio: "Clique para reduzir o log" e pronto.
frenchie

Respostas:


749

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 testdb SET RECOVERY FULL;

Mesmo se estiver a tomar backups completos regulares, o arquivo de log vai crescer e crescer até que você executar um log de backup - isto é para sua proteção, para não desnecessariamente comer fora de seu 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 no máximo 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, pois são terríveis).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + 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 tirá-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 SHRINKFILErepetidas vezes 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 quaisquer transações simultâneas que possam ocorrer. Os eventos de crescimento automático de arquivos 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 testdb 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). CHECKPOINTOs eventos ajudarão a controlar o log e garantir que ele não precise crescer, a menos que você gere muita atividade de 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
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
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 do 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 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 você deve marcá-lo como tal ALTER DATABASE), isso levará 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 com o arquivo de log problemático diretamente, 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 pequena quantidade e permitir que ele cresça automaticamente a uma taxa pequena por conta própria, defina-o para um tamanho razoavelmente grande (que acomodará 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 que seja 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 seus arquivos de dados .

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


5
A recuperação pontual não é a única razão para usar o modelo de recuperação completa. O principal motivo é evitar a perda de dados. Seu potencial para perda de dados é o tamanho entre os backups. Se você estiver fazendo apenas um backup diário, seu potencial para perda de dados é de 24 horas. Se você adicionar backups de log a cada meia hora, seu potencial para perda de dados será de 30 minutos. Além disso, os backups de log são necessários para executar qualquer tipo de restauração fragmentada (como recuperar de corrupção).
Robert L Davis

9
Além disso, esta é a resposta mais completa e correta dada nesta página.
Robert L Davis

11
Gostaria também de acrescentar que a limpeza do log é feita fazendo backup do log (na recuperação completa ou em massa) ou de um ponto de verificação (na recuperação simples). No entanto, se você estiver em uma situação em que deve reduzir o arquivo de log, isso não é suficiente. Você precisa fazer com que o VLF ativo no momento retorne ao início do arquivo de log. Você pode forçar isso no SQL 2008 e versões mais recentes, emitindo dois backups de log ou pontos de verificação consecutivos. O primeiro limpa e o segundo volta ao início do arquivo.
Robert L Davis

2
@Doug_Ivison porque a qualquer momento, os registros de log podem ser limpos. Qual seria o sentido de permitir que você faça backup de um log incompleto? Na recuperação simples, o log é realmente usado apenas para permitir reversões de transações. Depois que uma transação é confirmada ou revertida, no segundo seguinte ela pode sair do log.
Aaron Bertrand

3
@ zinczinc Ok, obrigado pelo seu feedback. O problema que vejo ao colocar a resposta em primeiro lugar e a explicação mais tarde é que eles nunca lerão as partes importantes. A palestra com que afoguei o leitor é realmente muito mais importante do que a resposta no final, e IMHO, o pano de fundo que forneço, é muito importante para fazer essas escolhas. Mas, ei, se você deseja enviar uma resposta em uma linha porque acha que é melhor para o OP, sinta-se à vontade para usar essa parte da minha resposta para fazer uma melhor que todos possamos aprender.
Aaron Bertrand

200
-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

De: DBCC SHRINKFILE (Transact-SQL)

Você pode querer fazer backup primeiro.


graças Maimonides, o seu a partir dos documentos, então eu diria que é o melhor: P especialmente porque não foi inventada por mim :)
Rui Lima

1
depois disso, o tamanho do meu log não mudou um pouco. fiz algo de errado?
Chester89

1
Esta abordagem conjuntos recuperar tipo de "FULL", mesmo que tipo de recuperação era outra coisa antes
Vil

1
Trabalhou como mágica! Note que o nome do arquivo de log é realmente seu nome lógico (que pode ser encontrado em db-> Propriedades> arquivos)
Bizhan

2
Eu incluiria uma cláusula BACKUP DATABASE neste script, para que ninguém esqueça essa parte. Digo isso, porque há alguns anos encolhi um banco de dados em um disco em que ele tem muito pouco espaço livre. No processo de redução, os arquivos estavam ficando maiores e um erro de falta de espaço foi lançado. Resultado: perdi o banco de dados. Felizmente, havia um banco de dados de log que perdia a tolerância.
Cesar

185

AVISO LEGAL: Por favor, leia os comentários abaixo com atenção e presumo que você já tenha lido a resposta aceita. Como eu disse há quase 5 anos:

se alguém tiver algum comentário a acrescentar em situações em que essa NÃO seja uma solução adequada ou ideal, comente abaixo


  • Clique com o botão direito do mouse no nome do banco de dados.

  • Selecione Tarefas → Reduzir → Banco de Dados

  • Então clique OK!

Normalmente, abro o diretório do Windows Explorer que contém os arquivos do banco de dados, para que eu possa ver imediatamente o efeito.

Fiquei realmente surpreso que isso funcionou! Normalmente eu já usei DBCC antes, mas tentei isso e não diminuiu nada, então tentei a GUI (2005) e funcionou muito bem - liberando 17 GB em 10 segundos

No modo de recuperação completa, isso pode não funcionar, portanto, é necessário fazer backup do log primeiro ou alterar para Recuperação simples e encolher o arquivo. [obrigado @onupdatecascade por isso]

-

PS: Aprecio o que alguns comentaram sobre os perigos disso, mas no meu ambiente não tive problemas em fazer isso sozinho, especialmente porque sempre faço um backup completo primeiro. Portanto, leve em consideração qual é o seu ambiente e como isso afeta sua estratégia de backup e segurança do trabalho antes de continuar. Tudo o que eu estava fazendo era apontar as pessoas para um recurso fornecido pela Microsoft!


50
No modo de recuperação completa, isso pode não funcionar, portanto, é necessário fazer backup do log primeiro ou alterar para Recuperação simples e encolher o arquivo.
Onupdatecascade 6/08/09

7
@onupdatecascade - boa chamada para o truque de recuperação completa. tinha outro banco de dados com um log enorme: alternou para simples, reduza o banco de dados e retorne ao total. arquivo de log até 500kb!
Simon_Weaver

26
Desculpa. Mas essa resposta simplesmente não poderia estar MAIS errada. Ao reduzir o banco de dados, você aumentará o arquivo de log de transações. A qualquer momento que você mover dados em um banco de dados do SQL Server, será necessário fazer logon - inchando o arquivo de log. Para diminuir o tamanho do log, defina o banco de dados como Recuperação simples OU (se você precisar / precisar de dados registrados - e quase sempre faz em produção) faça backup do log. Mais detalhes nestes simples, livre, vídeos: sqlservervideos.com/video/logging-essentials sqlservervideos.com/video/sql2528-log-files
Michael K. Campbell

30
Uau, parabéns por obter mais de 1300 representantes para esta resposta, mas é realmente um péssimo conselho.
Aaron Bertrand

8
Aqui está um exagero para demonstrar o que está acontecendo e por que a redução é absolutamente crítica periodicamente: O registro A é alterado 1 milhão de vezes antes de um backup ser feito. O que está no log? 999.999 dados irrelevantes. Se os logs nunca forem reduzidos, você nunca saberá qual é a verdadeira despesa operacional do banco de dados. Além disso, você está consumindo recursos valiosos em uma SAN, provavelmente. Encolher é uma boa manutenção e mantém você em contato com o ambiente. Mostre-me alguém que acha que você nunca deve encolher e eu mostrarei a alguém que ignora o ambiente.
Newclique

54

Abaixo está um script para reduzir o log de transações, mas eu recomendaria definitivamente fazer o backup do log de transações antes de reduzi-lo.

Se você apenas reduzir o arquivo, perderá uma tonelada de dados que podem salvar a vida em caso de desastre. O log de transações contém muitos dados úteis que podem ser lidos usando um leitor de log de transações de terceiros (pode ser lido manualmente, mas com muito esforço).

O log de transações também é essencial quando se trata de recuperação pontual, portanto, não apenas jogue fora, mas faça o backup com antecedência.

Aqui estão várias postagens em que as pessoas usavam dados armazenados no log de transações para realizar a recuperação:

 

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

Você pode receber um erro parecido com este quando os comandos de execução acima

"Não é possível reduzir o arquivo de log (nome do arquivo de log) porque o arquivo de log lógico localizado no final do arquivo está em uso"

Isso significa que o TLOG está em uso. Nesse caso, tente executar isso várias vezes seguidas ou encontre uma maneira de reduzir as atividades do banco de dados.


30

Aqui está uma maneira simples, muito deselegante e potencialmente perigosa .

  1. Banco de dados de backup
  2. Desanexar DB
  3. Renomear arquivo de log
  4. Anexar banco de dados
  5. Novo arquivo de log será recriado
  6. Exclua o arquivo de log renomeado.

Suponho que você não esteja fazendo backups de log. (Que trunca o log). Meu conselho é alterar o modelo de recuperação de completo para simples . Isso evitará o inchaço do log.


15
Respeitosamente, excluir / renomear / recriar / substituir o log é uma péssima idéia. Reduzir é menos arriscado, além de ser bastante simples de fazer.
Onupdatecascade 6/08/09

12
+1 - Deselegante ou não, esse método me tirou da água quente algumas vezes com logs de banco de dados que encheram todo o disco, de forma que mesmo um comando de redução não pode ser executado.
Shaul Behr,

3
Não existe o risco de transações não assinaladas existirem no log?
Paul

Isso também pode ser bom para bancos de dados menores, mas se você tiver um banco de dados de 3 ou 4 TB, pode não ser a melhor solução.
Jaques

Isso parece bom se você estiver desenvolvendo um sistema há muito tempo e carregando / excluindo milhares de registros durante o período de desenvolvimento. Então, quando você deseja usar esse banco de dados para implantar para viver, os dados de teste / desenvolvimento registrados são redundantes e, portanto, não importam se estão perdidos, não?
JsonStatham 07/12/16

28

Se você não usar os logs de transações para restaurações (ou seja, você só fará backups completos), poderá definir o Modo de recuperação como "Simples", e o log de transações diminuirá muito em breve e nunca será preenchido novamente.

Se você estiver usando o SQL 7 ou 2000, poderá ativar "truncar ponto de verificação de logon" na guia Opções do banco de dados. Isso tem o mesmo efeito.

Obviamente, isso não é recomendado em ambientes de produção, pois você não poderá restaurar para um ponto no tempo.


1
Definir o modo de recuperação como simples não reduzirá magicamente o log de transações.
Aaron Bertrand

@ Aaron Não por si só, não. Eu assumi que o OP usaria o banco de dados de teste e, portanto, "o log de transações diminuirá muito em breve", mas você está certo, pois é mais um efeito colateral: o modo de recuperação simples provavelmente fará com que você acabe com um encolhimento log de transações em breve
Jonathan

" Simple... e nunca mais encha novamente" - não é verdade. Eu já vi isso acontecer (nas últimas 48 horas) em um banco de dados em que o modelo de recuperação foi definido como "SIMPLES". O crescimento do arquivo do arquivo de log foi definido como "restrito" e estávamos realizando uma imensa atividade ... Entendo que era uma situação incomum. (Em nossa situação, onde tínhamos bastante espaço em disco, aumentamos o tamanho do arquivo de log e definimos o crescimento do arquivo como "irrestrito" ... que, a propósito - bug de interface - aparece, após a alteração, como "restrito "com um tamanho máximo de 2.097.152 MB.)
Doug_Ivison

2
@Doug_Ivison Sim, o log de transações terá transações abertas, mas elas serão removidas no modo simples assim que um ponto de verificação ocorrer. Essa resposta é pretendida apenas como uma rápida "minha caixa de desenvolvimento / teste tem um grande log de transações e eu quero que ela desapareça para que não precise me preocupar com isso com muita frequência", em vez de pretender entrar em uma produção meio Ambiente. Para reiterar: Não faça isso na produção .
Jonathan

1
Tudo isso é verdade, e entendi que era uma abordagem rápida apenas para desenvolvimento. Por que comentei: até que isso acontecesse comigo, eu realmente pensei que o modelo de recuperação simples NUNCA poderia ser preenchido ... e acho que demorei mais para descobrir / resolver, enquanto eu entendi que transações incomumente grandes podem fazer isso.
Doug_Ivison

9

Essa técnica recomendada por John não é recomendada, pois não há garantia de que o banco de dados seja anexado sem o arquivo de log. Altere o banco de dados de completo para simples, force um ponto de verificação e aguarde alguns minutos. O SQL Server limpará o log, que você poderá reduzir usando o DBCC SHRINKFILE.


... mas já fiz isso dezenas de vezes sem problemas. talvez você possa explicar por que o banco de dados não pode se reconectar.
31909 Johnno Nolan

Ocasionalmente (não com muita frequência), o SQL Server não consegue anexar o banco de dados ao banco de dados quando o arquivo de log foi excluído. Isso deixa você com um arquivo MDF inútil. Existem várias possibilidades que podem causar o problema. As transações pendentes de reversão vêm à mente.
22410 mrdenny

4
Concordo com essa tática, mas ela deve ser reservada para os casos em que o registro explodiu devido a algum evento imprevisto e / ou extraordinário. Se você definir um trabalho para fazer isso toda semana, estará fazendo isso muito, muito errado.
Aaron Bertrand

2
Aaron muito, muito verdadeiro.
mrdenny

Sim, isso aconteceu conosco. Queríamos abandonar 20G de arquivo de log, pois havíamos feito backup dos dados antes de mover o banco de dados. De maneira alguma o MSSQL nos permitiria anexar novamente o novo banco de dados sem o enorme arquivo de log.
George M Restabelecer Monica

9

Até agora, a maioria das respostas presume que você não precisa do arquivo Log de transações, no entanto, se o banco de dados estiver usando o FULLmodelo de recuperação e desejar manter seus backups caso precise restaurar o banco de dados, não trunque ou exclua o arquivo arquivo de log da maneira que muitas dessas respostas sugerem.

A eliminação do arquivo de log (truncando-o, descartando-o, apagando-o etc.) interromperá sua cadeia de backups e impedirá que você restaure a qualquer momento desde o último backup completo, diferencial ou de log de transações, até o próximo backup completo ou backup diferencial é feito.

No artigo da Microsoft sobreBACKUP

Recomendamos que você nunca use NO_LOG ou TRUNCATE_ONLY para truncar manualmente o log de transações, porque isso interrompe a cadeia de log. Até o próximo backup completo ou diferencial do banco de dados, o banco de dados não está protegido contra falhas de mídia. Use o truncamento de log manual apenas em circunstâncias muito especiais e crie backups dos dados imediatamente.

Para evitar isso, faça backup do seu arquivo de log em disco antes de reduzi-lo. A sintaxe seria algo como isto:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

3
Eu concordo com sua resposta, exceto a , 1)parte. O problema é que, se você reduzi-lo para 1 MB, os eventos de crescimento que levam a um tamanho de log normal serão bastante caros, e haverá muitos deles se a taxa de crescimento for deixada no padrão de 10%.
Aaron Bertrand

9

O log de transações do SQL Server precisa ser mantido adequadamente para impedir seu crescimento indesejado. Isso significa executar backups de log de transações com bastante frequência. Ao não fazer isso, você corre o risco de o log de transações ficar cheio e começar a crescer.

Além das respostas para essa pergunta, recomendo ler e entender os mitos comuns do log de transações. Essas leituras podem ajudar a entender o log de transações e decidir quais técnicas usar para "limpá-lo":

Dos 10 mitos mais importantes sobre o log de transações do SQL Server :

Mito: Meu SQL Server está muito ocupado. Não quero fazer backups do log de transações do SQL Server

Uma das maiores operações com alto desempenho no SQL Server é um evento de crescimento automático do arquivo de log de transações online. Ao não fazer backups do log de transações com bastante frequência, o log de transações online ficará cheio e precisará crescer. O tamanho padrão de crescimento é 10%. Quanto mais ocupado o banco de dados, mais rápido o log de transações on-line aumentará se os backups do log de transações não forem criados. Criar um backup do log de transações do SQL Server não bloqueia o log de transações on-line, mas sim um evento de crescimento automático. Ele pode bloquear todas as atividades no log de transações online

Dos mitos do log de transações :

Mito: O encolhimento regular de toras é uma boa prática de manutenção

FALSO. O crescimento do log é muito caro porque o novo bloco deve ser zerado. Todas as atividades de gravação são interrompidas nesse banco de dados até a conclusão do zeramento e, se a gravação do disco for lenta ou o tamanho do crescimento automático for grande, essa pausa poderá ser grande e os usuários perceberão. Essa é uma das razões pelas quais você deseja evitar o crescimento. Se você reduzir o log, ele voltará a crescer e você estará desperdiçando a operação do disco em um jogo desnecessário de reduzir e voltar a crescer


5

Primeiro verifique o modelo de recuperação do banco de dados. Por padrão, o SQL Server Express Edition cria um banco de dados para o modelo de recuperação simples (se não me engano).

Log de backup DatabaseName With Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile fornecerá o nome do arquivo de log lógico.

Referir-se:

Recuperar de um log de transações completo em um banco de dados SQL Server

Se o seu banco de dados estiver no Modelo de recuperação completa e se você não estiver executando o backup TL, altere-o para SIMPLE.


É assim que limpo os arquivos de log nas minhas caixas de desenvolvimento. Ambientes Prod Com todas as estratégias de backup etc I licença associada ao DBA :-)
Joon

TRUNCATE_ONLYnão é mais uma opção nas versões atuais do SQL Server e não é recomendado em versões que o suportam (consulte a resposta de Rachel ).
Aaron Bertrand

5

Use o DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)comando Se este é um banco de dados de teste e você está tentando economizar / recuperar espaço, isso ajudará.

Lembre-se, porém, de que os logs TX têm um tipo de tamanho mínimo / de estado estacionário em que crescerão. Dependendo do seu modelo de recuperação, talvez você não consiga reduzir o log - se estiver COMPLETO e não estiver emitindo backups de log TX, o log não poderá ser reduzido - ele crescerá para sempre. Se você não precisar de backups de log TX, mude seu modelo de recuperação para Simples .

E lembre-se, nunca, em hipótese alguma, exclua o arquivo de log (LDF)! Você praticamente terá corrupção instantânea no banco de dados. Cozinhou! Feito! Dados perdidos! Se deixado "não reparado", o arquivo principal do MDF pode ficar corrompido permanentemente.

Nunca exclua o log de transações - você perderá dados! Parte dos seus dados está no log TX (independentemente do modelo de recuperação) ... se você desanexar e "renomear" o arquivo de log TX que exclui efetivamente parte do seu banco de dados.

Para aqueles que excluíram o TX Log, convém executar alguns comandos checkdb e corrigir a corrupção antes de perder mais dados.

Confira as postagens de Paul Randal no blog sobre esse mesmo tópico, maus conselhos .

Em geral, também não use o arquivo shrinkfile nos arquivos MDF, pois pode fragmentar severamente seus dados. Confira a seção de maus conselhos para obter mais informações ("Por que você não deve reduzir seus arquivos de dados")

Confira o site de Paul - ele cobre essas mesmas perguntas. No mês passado, ele examinou muitas dessas questões em sua série Myth A Day .


+1 Por ser a primeira resposta a mencionar que isso pode não ser uma boa ideia! O OP especifica um banco de dados de teste, mas é um ponto que vale a pena destacar no caso mais geral.
Martin Smith

Eu deveria ter adicionado - Se você excluir o registro TX - Atualizar currículo!
ripvlan

4

Para truncar o arquivo de log:

  • Faça backup do banco de dados
  • Desanexe o banco de dados, usando o Enterprise Manager ou executando: Sp_DetachDB [DBName]
  • Exclua o arquivo de log de transações. (ou renomeie o arquivo, apenas por precaução)
  • Reconecte o banco de dados novamente usando: Sp_AttachDB [DBName]
  • Quando o banco de dados é anexado, um novo arquivo de log de transações é criado.

Para reduzir o arquivo de log:

  • Log de backup [DBName] com No_Log
  • Reduza o banco de dados:

    Usando o Enterprise manager: - Clique com o botão direito do mouse no banco de dados, Todas as tarefas, Encolher banco de dados, Arquivos, Selecionar arquivo de log, OK.

    Usando T-SQL: - Arquivo Shrink Dbcc ([Log_Logical_Name])

Você pode encontrar o nome lógico do arquivo de log executando sp_helpdb ou procurando nas propriedades do banco de dados no Enterprise Manager.


Nunca exclua o log de transações. Parte dos seus dados está no log. Exclua-o e o banco de dados ficará corrompido. Eu não tenho representante para votar.
22415 Ripvlan

4

Para minha experiência na maioria dos servidores SQL, não há backup do log de transações. Backups completos ou diferenciais são práticas comuns, mas os backups de log de transações são realmente raros. Portanto, o arquivo de log de transações cresce para sempre (até que o disco esteja cheio). Nesse caso, o modelo de recuperação deve ser definido como " simples ". Não se esqueça de modificar também o "modelo" e o "tempdb" dos bancos de dados do sistema.

Um backup do banco de dados "tempdb" não faz sentido; portanto, o modelo de recuperação desse banco de dados sempre deve ser "simples".


Apenas definir o banco de dados como simples não reduzirá o arquivo de log, em qualquer estado em que esteja atualmente. Isso pode ajudar a impedir que ele cresça ainda mais (mas ainda pode).
Aaron Bertrand

4
  1. Faça um backup do arquivo MDB.
  2. Interromper serviços SQL
  3. Renomeie o arquivo de log
  4. Iniciar o serviço

(O sistema criará um novo arquivo de log.)

Exclua ou mova o arquivo de log renomeado.


3

Aconteceu comigo onde o arquivo de log do banco de dados era de 28 GBs.

O que você pode fazer para reduzir isso? Na verdade, os arquivos de log são aqueles dados que o servidor SQL mantém quando ocorre uma transação. Para que uma transação processe, o SQL Server aloca páginas para o mesmo. Mas após a conclusão da transação, eles não são liberados repentinamente na esperança de que possa haver uma transação como a mesma. Isso mantém o espaço.

Etapa 1: primeiro execute este comando no ponto de verificação explorado da consulta ao banco de dados

Etapa 2: Clique com o botão direito do mouse no banco de dados Tarefa> Fazer backup Selecione o tipo de backup como log de transações Adicione um endereço de destino e um nome de arquivo para manter os dados de backup (.bak)

Repita esta etapa novamente e, nesse momento, forneça outro nome de arquivo

insira a descrição da imagem aqui

Etapa 3: Agora vá para o banco de dados Clique com o botão direito do mouse no banco de dados

Tarefas> Reduzir> Arquivos Escolha o tipo de arquivo como ação Reduzir log como liberar espaço não utilizado

insira a descrição da imagem aqui

Passo 4:

Verifique seu arquivo de log normalmente no SQL 2014, que pode ser encontrado em

C: \ Arquivos de Programas \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA

No meu caso, é reduzido de 28 GB para 1 MB


2

Tente o seguinte:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

TRUNCATE_ONLYnão é mais uma opção nas versões atuais do SQL Server e não é recomendado em versões que o suportam (consulte a resposta de Rachel ).
Aaron Bertrand

Funciona para mim usando o MSSQL Server 2005 Standard edition
bksi

2

Banco de dados → clique com o botão direito do mouse em Propriedades → arquivo → adicione outro arquivo de log com um nome diferente e defina o caminho igual ao arquivo de log antigo com um nome de arquivo diferente.

O banco de dados pega automaticamente o arquivo de log recém-criado.


1
  1. Banco de dados de backup
  2. Desanexar DB
  3. Renomear arquivo de log
  4. Anexe o banco de dados (ao anexar remover renomeado .ldf (arquivo de log). Selecione-o e remova-o pressionando o botão Remover)
  5. Novo arquivo de log será recriado
  6. Exclua o arquivo de log renomeado.

Isso funcionará, mas é recomendável fazer backup do seu banco de dados primeiro.


1

Algumas das outras respostas não funcionaram para mim: não foi possível criar o ponto de verificação enquanto o banco de dados estava online, porque o log de transações estava cheio (que irônico). No entanto, depois de definir o banco de dados para o modo de emergência, consegui reduzir o arquivo de log:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

0

Exemplo:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

TRUNCATE_ONLYnão é mais uma opção nas versões atuais do SQL Server e não é recomendado em versões que o suportam (consulte a resposta de Rachel ).
Aaron Bertrand

A pergunta não está relacionada ao tópico Estouro de pilha, conforme definido na Central de Ajuda . Por favor, não responda a essas perguntas; em vez disso, você deve sinalizá-los para atenção e eles serão fechados ou migrados adequadamente.
precisa saber é o seguinte

0

Resposta ligeiramente atualizada, para MSSQL 2017 e usando o SQL Server Management Studio. Eu segui principalmente essas instruções https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

Eu tinha um backup recente do banco de dados, então fiz o backup do log de transações. Então eu fiz o backup novamente por uma boa medida. Finalmente, encolhi o arquivo de log e passei de 20G para 7MB, muito mais de acordo com o tamanho dos meus dados. Eu não acho que os logs de transações já foram salvos em backup desde que foram instalados há 2 anos .. por isso, colocar essa tarefa no calendário de limpeza.


-1

Reduzir o log de transações do banco de dados para o tamanho mínimo :

  1. Backup: log de transações
  2. Encolher arquivos: log de transações
  3. Backup: log de transações
  4. Encolher arquivos: log de transações

Fiz testes em vários números de bancos de dados: essa sequência funciona .

Geralmente diminui para 2 MB .

OU por um script:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO

1
TRUNCATE_ONLYnão é mais uma opção nas versões atuais do SQL Server e não é recomendado em versões que o suportam (consulte a resposta de Rachel ).
Aaron Bertrand
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.