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 .
