Como você limpar o log de transação SQL Server?

StackOverflow https://stackoverflow.com/questions/56628

  •  09-06-2019
  •  | 
  •  

Pergunta

Eu não sou um perito em SQL, e lembrei-me do fato de toda vez que eu precisar fazer alguma coisa 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 faço para limpar o log de transação?

Foi útil?

Solução

Fazer um arquivo de log de menores deve realmente ser reservado para situações em que ele encontrou o crescimento inesperado que você não espera acontecer novamente.Se o arquivo de log vai crescer para o mesmo tamanho de novo, não muito é feito reduzindo-lo temporariamente.Agora, dependendo dos objetivos de recuperação do banco de dados, estas são as ações que você deve tomar.

Em primeiro lugar, faça uma cópia de segurança completa

Nunca efectue quaisquer alterações ao seu banco de dados sem assegurando que você pode restaurá-lo caso algo saia errado.

Se você se preocupa com ponto-in-time recovery

(E por ponto-in-time recovery, eu quero dizer que você se importa sobre ser capaz de restaurar para algo diferente de um backup completo ou diferencial.)

Presumivelmente, o seu banco de dados está em FULL o modo de recuperação.Se não, em seguida, certifique-se de que ele é:

ALTER DATABASE testdb SET RECOVERY FULL;

Mesmo se você estiver tomando regularmente cópias de segurança completas, o arquivo de log irá crescer e crescer até que você executar uma registo backup - este é para a sua proteção, não precisaria comer seu espaço em disco.Você deve estar de realizar essas cópias de segurança de registo com bastante frequência, de acordo com seus objetivos de tempo de recuperação.Por exemplo, se você tiver uma regra de negócio que indica que você pode dar ao luxo de perder não mais do que 15 minutos de dados em caso de desastre, você deve ter um trabalho que faz o backup de log a cada 15 minutos.Aqui está um script que irá gerar o carimbo de data / hora nomes de ficheiro com base no tempo atual (mas você também pode fazer isso com os planos de manutenção, etc., só não escolha qualquer um dos encolher opções em planos de manutenção, eles são horrí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;

Note que \\backup_share\ deve ser em um computador diferente que representa um outro dispositivo de armazenamento subjacente.Fazendo a mesma máquina (ou a um computador diferente que usa a mesma base discos, ou uma VM que está no mesmo host físico) não realmente ajudá-lo, pois se a máquina explode, você perdeu o seu banco de dados e seus backups.Dependendo da sua infra-estrutura de rede, pode fazer mais sentido para backup localmente e, em seguida, transferi-los para um local diferente, por trás das cenas;em ambos os casos, você quer tirá-los do banco de dados primário máquina o mais rapidamente possível.

Agora, depois de regularmente backups do log de execução, ele deve ser razoável para reduzir o arquivo de log para algo mais razoável do que seja o que é soprado até agora.Este não não significa executar SHRINKFILE e outra vez até que o arquivo de log é de 1 MB - mesmo se você estiver fazendo backup do log de freqüência, ele ainda precisa acomodar a soma de quaisquer transações simultâneas que podem ocorrer.Arquivo de Log de crescimento automático eventos são caros, uma vez que o SQL Server possui para zero os arquivos (ao contrário dos arquivos de dados quando a inicialização instantânea de arquivos estiver habilitada), e transações do usuário ter que esperar, enquanto isso acontece.Você deseja fazer isso crescer-diminuir-aumentar-diminuir rotina tão pouco quanto possível, e você certamente não quer tornar seus usuários a pagar por ele.

Observe que você pode precisar para fazer backup do log de duas vezes antes de um psiquiatra é possível (graças Robert).

Então, você precisa vir para cima com um tamanho prático para o seu arquivo de log.Ninguém aqui pode dizer o que que é, sem saber muito mais sobre seu sistema, mas se tiver sido frequentemente diminuindo o arquivo de log e tem vindo a crescer novamente, uma boa marca d'água é, provavelmente, 10% a 50% maior do que o maior tem sido.Digamos que vem para 200 MB, e se você quiser que qualquer subsequente aumento automático de eventos a ser de 50 MB, em seguida, você pode ajustar o tamanho do arquivo de log desta forma:

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

Observe que se o arquivo de log é atualmente > 200 MB, você pode precisar de executar este primeiro:

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

Se você não gosta de point-in-time recovery

Se este é um banco de dados de teste, e você não se preocupa ponto no tempo de recuperação e, em seguida, você deve certificar-se de que o seu banco de dados está em SIMPLE o modo de recuperação.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Colocar o banco de dados em SIMPLE o modo de recuperação irá certificar-se de que o SQL Server re-utiliza partes do arquivo de log (essencialmente phasing out transações inativas) em vez de crescer para manter um registro de todos transações (como FULL recuperação não até que você faça backup do log). CHECKPOINT eventos irá ajudar a controlar o log e certifique-se de que ele não precisa crescer, a menos que você gerar um monte de t-log de atividade entre CHECKPOINTs.

Em seguida, você deve fazer a absoluta certeza de que esse crescimento de log foi realmente devido a um evento anormal (por exemplo, anual, na primavera de limpeza ou reconstrução de seus maiores índices), e não devido ao normal, o uso diário.Se você reduzir o arquivo de log para um ridiculamente pequeno tamanho, e SQL Server só tem a crescer novamente para acomodar a sua actividade normal, o que você ganha?Você foi capaz de fazer uso do espaço em disco liberado apenas temporariamente?Se você precisa de uma correção imediata, em seguida, você pode 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 adequado e taxa de crescimento.Como por exemplo, no ponto-in-time recovery caso, você pode usar o mesmo código e a lógica para determinar o tamanho do arquivo é apropriado e definido razoável aumento automático de parâmetros.

Algumas coisas que você não quer fazer

  • O log de backup com TRUNCATE_ONLY opção e, em seguida, SHRINKFILE.Por um lado, este TRUNCATE_ONLY a opção foi descontinuado e não está mais disponível nas versões atuais do SQL Server.Em segundo lugar, se você estiver em FULL modelo de recuperação, este irá destruir a sua cadeia de log e exigem um novo backup completo.

  • Desanexar o banco de dados, exclua o arquivo de log, e re-anexar.Eu não posso enfatizar o quão perigoso isso pode ser.Seu banco de dados pode não voltar, ela pode até vir como suspeito, poderá ter de reverter para um backup (se você tiver um), etc.etc.

  • Use a "reduzir o banco de dados" opção. DBCC SHRINKDATABASE e a opção de plano de manutenção para fazer o mesmo são más ideias, especialmente se você realmente só precisa resolver um log questão problema.Destino o arquivo que você deseja ajustar e ajuste-a de forma independente, usando DBCC SHRINKFILE ou ALTER DATABASE ... MODIFY FILE (exemplos acima).

  • Reduzir o arquivo de log para 1 MB.Este parece tentador, porque, hey, SQL Server, deixe-me fazê-lo em determinados cenários, e olhar para todo o espaço que liberta!A menos que seu banco de dados é somente para leitura (e é, você deve marcá-lo como tal, usando ALTER DATABASE), este com certeza vai apenas levar a muitas crescimento desnecessário eventos, como o registo de acomodar transações correntes, independentemente do modelo de recuperação.Qual é o ponto de libertar o espaço que temporariamente, apenas para que o SQL Server pode levá-lo de volta lentamente e dolorosamente?

  • Crie um segundo arquivo de log.Isto irá fornecer temporariamente alívio para a unidade, que encheu seu disco, mas isso é como tentar corrigir um pulmão perfurado com um band-aid.Você deve lidar com a problemática do arquivo de log diretamente, em vez de apenas adicionando outro problema em potencial.Outros que redirecionando alguns actividade de registo de transacções para uma unidade diferente, um segundo arquivo de log realmente não faz nada por você (ao contrário de um segundo arquivo de dados), uma vez que apenas um dos arquivos pode ser usado uma vez. Paul Randal também explica o porquê de vários ficheiros de registo podem mordê-lo mais tarde.

Ser pró-ativo

Em vez de encolher seu arquivo de log para algumas pequenas quantidade e deixá-la em constante crescimento automático em uma pequena taxa sobre a sua própria, defina-o para algum razoavelmente grande de tamanho (que irá acomodar a soma do maior conjunto de transações simultâneas) e definir uma razoável definição autogrow como uma alternativa, de modo que ele não tem a crescer várias vezes para satisfazer único transações e para que irá ser relativamente raros, para que ele sempre tem que crescer durante operações normais de negócios.

Os piores possíveis configurações aqui são de 1 MB de crescimento ou crescimento de 10%.Engraçado, esses são os padrões para o SQL Server (que eu já reclamou e pediu alterações sem sucesso) - De 1 MB para arquivos de dados e 10% para os arquivos de log.O primeiro é muito pequeno, neste dia e idade, e o segundo leva a mais e mais eventos de todos os tempo (por exemplo, o arquivo de log é de 500 MB, o primeiro de crescimento é de 50 MB, próximo de crescimento é de 55 MB, próximo de crescimento é de 60,5 MB, etc.etc.- e/S lento, acredite em mim, você vai realmente perceber esta curva).

Ler mais

Por favor, não pare por aqui;enquanto grande parte dos conselhos que você vê lá fora, sobre redução de arquivos de log é inerentemente má e até mesmo potencialmente desastroso, existem algumas pessoas que se preocupam mais com a integridade dos dados de libertar espaço no disco.

Um post de blog que escrevi em 2009, quando eu vi alguns "veja como reduzir o arquivo de log de" posts primavera.

Um post de blog Brent Ozar escreveu quatro anos atrás, apontando para vários recursos, em resposta a um Servidor de SQL artigo de Revista que deve não foram publicados.

Um post no blog de Paul Randal, explicando o porquê de t-manutenção do log é importante e por que você não deve reduzir seus arquivos de dados, ou.

Mike Walsh tem uma grande resposta cobrindo alguns desses aspectos, incluindo as razões por que você pode não ser capaz de reduzir o arquivo de log imediatamente.

Outras dicas

ISENÇÃO de responsabilidade: Por favor, leia os comentários abaixo cuidadosamente, e eu suponho que você já tenha lido o aceite de resposta.Como eu disse, há quase 5 anos atrás:

se alguém tiver algum comentário a acrescentar para as situações em que esta NÃO é uma adequada ou solução ideal, então, por favor, comente abaixo

  • Clique direito sobre o nome do banco de dados.

  • Selecione Tarefas → Reduzir → Banco De Dados

  • Em seguida, clique em OK!

Eu costumo abrir o Windows Explorer diretório que contém os arquivos de banco de dados, para que eu possa ver imediatamente o efeito.

Na verdade fiquei muito surpreso com isso funcionou!Normalmente eu usei o comando DBCC antes, mas eu apenas tentei isso e não diminuir em nada, então eu tentei o GUI (2005) e trabalhou grande liberação de até 17 GB em 10 segundos

No modo de recuperação Completa este pode não funcionar, então você tem que fazer o backup do log de primeira, ou alterar a Simples recuperação, em seguida, reduzir o arquivo.[obrigado @onupdatecascade para isso]

--

PS:Eu aprecio o que alguns comentaram sobre os perigos do presente, mas no meu ambiente eu não tenho quaisquer problemas fazendo isso sozinho, especialmente desde que eu faça sempre uma cópia de segurança completa em primeiro lugar.Por favor, leve em consideração que seu ambiente é, e como isso afeta sua estratégia de backup e segurança de trabalho antes de continuar.Tudo o que eu estava fazendo era apontar as pessoas para um recurso fornecido pela Microsoft!

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

A partir de: DBCC SHRINKFILE (Transact-SQL)

Você pode deseja fazer o backup primeiro.

Abaixo está um script para reduzir o log de transações, mas eu definitivamente recomendo o backup do log de transações antes de encolhendo.

Se você acabou de reduzir o arquivo que você vai perder uma tonelada de dados que pode vir como um saver de vida em caso de desastre.O log de transações contém uma grande quantidade de dados úteis que podem ser lidos usando um terceiro de log de transação do leitor (que pode ser lido manualmente, mas com esforço extremo embora).

O log de transações é também uma obrigação quando se trata de ponto no tempo de recuperação, por isso não basta jogá-lo fora, mas certifique-se de que você faça backup de antemão.

Aqui estão vários posts onde pessoas usaram dados armazenados no log de transação 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 semelhante a este, quando da execução de comandos acima

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

Isso significa que a arte de blogar está em uso.Neste caso, tente executar este várias vezes em uma linha ou encontrar uma maneira de reduzir as atividades de banco de dados.

Se você não usar os logs de transação para restaurações (i.e.Você só fazer backups completos), você pode definir o Modo de Recuperação para "Simples", e o log de transação será muito em breve encolher e nunca encher novamente.

Se você estiver usando o SQL 7 ou 2000, você pode ativar o "truncar log no ponto de verificação" no banco de dados guia opções.Isso tem o mesmo efeito.

Esta não é recomendado em ambientes de produção, obviamente, desde que você não será capaz de restaurar para um ponto no tempo.

Aqui está uma simples e muito deselegante & potencialmente perigosos caminho.

  1. Backup DB
  2. Desanexar DB
  3. Mudar o nome do arquivo de Log
  4. Anexar DB
  5. Novo arquivo de log será recriado
  6. Excluir arquivo de Log Renomeado.

Eu estou supondo que você não está fazendo backups de log.(Que truncar o log).Meu conselho é para alterar o modelo de recuperação de completo para simples.Isto irá impedir o registo de inchaço.

A maioria das respostas aqui até agora estão assumindo que você não precisa realmente o arquivo de Log de Transação, no entanto, se o seu banco de dados é utilizando o FULL modelo de recuperação, e você quiser manter suas cópias de segurança no caso de você precisar restaurar o banco de dados e, em seguida, não truncar ou excluir o arquivo de log como muitos de estas respostas sugerem.

Eliminar o ficheiro de registo (através de truncar, rejeitar, apagar, etc) irá quebrar a sua cadeia de backup, e vai impedir você de restauração para qualquer ponto no tempo desde a sua última completo, diferencial ou backup de log de transação, até o próximo backup completo ou diferencial é feito.

Do Artigo da Microsoft emBACKUP

Recomendamos que você nunca usa NO_LOG TRUNCATE_ONLY ou manualmente truncar o log de transações, porque isso quebra a cadeia de log.Até a próxima completo ou diferencial backup do banco de dados, o banco de dados não é protegidos contra falha de mídia.Manual de utilização de truncamento de log em apenas muito circunstâncias especiais, e criar cópias de segurança dos dados imediatamente.

Para evitar que, cópia de segurança do ficheiro de registo para o disco antes de encolhendo.A sintaxe seria algo parecido com isto:

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

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

O SQL Server log de transação precisa ser adequadamente mantidos, a fim de impedir o seu crescimento não desejado.Isso significa a execução de backups de log de transação, muitas vezes, suficiente.Não fazendo isso, você corre o risco de log de transação para se tornar completo e começar a crescer.

Além disso, as respostas para esta questão, eu recomendo a leitura e a compreensão do log de transação mitos comuns.Estas leituras podem ajudar a compreender o log de transação e decidir quais as técnicas a utilizar para "limpar" é:

A partir de 10 mais importantes do SQL Server log de transações mitos:

Mito:Minha SQL Server está muito ocupado.Eu não quero fazer o SQL Server backups de log de transação

Um dos maiores desempenho intensivo de operações no SQL Server é um auto-crescer evento online do arquivo de log de transação.Por não fazer backups de log de transação, muitas vezes, suficiente, a transação on-line de registo ficará cheia e vai ter que crescer.O padrão de tamanho de crescimento é de 10%.O mais ocupado banco de dados, mais rápida on-line de registo de transacções vai crescer se backups de log de transação não são criados A criação de um SQL Server de backup de log de transação não bloquear a transação on-line de registo, mas uma auto-crescimento do evento.Ele pode bloquear todas as atividades on-line de registo de transacções

A partir de Log de transação mitos:

Mito:Log Regular de encolhimento é uma boa prática de manutenção

FALSA.Log de crescimento é muito caro porque o novo trecho deve ser zerado-out.Toda a atividade de gravação pára no banco de dados até que a anulação de terminar, e se o seu disco de gravação é lenta ou de aumento automático do tamanho é grande, que a pausa pode ser grande e os usuários vão notar.Essa é uma razão por que você quer evitar crescimento.Se você reduzir o log, ele vai crescer de novo e você está apenas desperdiçando operação de disco no escusado será encolher-e-crescer-jogo novamente

Esta técnica, que João recomenda não é recomendável, pois não há nenhuma garantia de que o banco de dados sem anexar o arquivo de log.Alterar o banco de dados completo para simples, forçar um ponto de verificação e aguarde alguns minutos.O SQL Server irá limpar o log, que pode reduzir usando o comando DBCC SHRINKFILE.

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 a simples a recuperação de modelo (se não me engano).

Registo de cópia de segurança DatabaseName With Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile lhe dará o arquivo de log lógico.

Consulte:

Recuperar a partir de um total de log de transações em um banco de dados SQL Server

Se o seu banco de dados está no Modelo de Recuperação Completa e se você não está tendo TL cópia de segurança e, em seguida, alterá-lo para SIMPLES.

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

Lembre-se que TX logs de fazer uma espécie de mínimo/estado estacionário tamanho que eles crescem.Dependendo do seu modelo de recuperação que você pode não ser capaz de reduzir o log - se em CHEIO e você não emissão de TX backups de log o log não pode ser diminuído - ele vai crescer para sempre.Se você não precisa de TX backups de log, mudar o seu modelo de recuperação para Simples.

E lembre-se, nunca, jamais, sob quaisquer circunstâncias excluir o log (LDF) arquivo!Você será muito bem ter instantâneas corrupção de banco de dados.Cozido!Feito!A perda de dados!Se a esquerda "sem conserto" o principal arquivo MDF poderia tornar-se danificado permanentemente.

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

Para aqueles que têm excluído a TX de Registo poderá executar alguns checkdb comandos e corrigir a corrupção antes de perder mais dados.

Confira Paul Randal postagens sobre este tema, maus conselhos.

Também, em geral, não use shrinkfile em MDF arquivos, como ele pode ser gravemente fragmento de seus dados.Confira seus Maus Conselhos secção para mais informações ("Por que você não deve encolher os arquivos de dados")

Confira Paulo site - ele cobre estas mesmas perguntas.Mês passado, ele caminhou através de muitas dessas questões em sua Mito Um Dia a série.

Para Truncar o arquivo de log:

  • Cópia de segurança da base de dados
  • Desanexar o banco de dados, usando o Enterprise Manager ou executando : Sp_DetachDB [DBName]
  • Excluir o arquivo de log de transação.(ou renomear o arquivo, apenas no caso)
  • Re-anexar novamente o banco de dados 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:

  • Registo de cópia de segurança [DBName] com No_Log

  • Reduzir o banco de dados através de qualquer um:

    Utilizando o Enterprise manager :- Direito do mouse no banco de dados, Todas as tarefas, Diminuir a base de dados, Arquivos, Selecione o arquivo de log, OK.

    Usando T-SQL :- Dbcc Shrinkfile ([Log_Logical_Name])

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

A minha experiência em mais Servidores SQL não há nenhuma cópia de segurança do registo de transacções.Completa de cópias de segurança ou backups diferenciais são uma prática comum, mas backups de log de transação são muito raramente.Portanto, o arquivo de log de transação cresce para sempre (até que o disco esteja cheio).Neste caso, o modelo de recuperação deve ser definido para "simples".Não se esqueça de modificar o sistema de bancos de dados "modelo" e "tempdb", também.

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

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

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

Excluir ou mover o arquivo de log renomeado.

Tente isso:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO

Banco de dados → clique direito Propriedades → arquivo → adicionar outro arquivo de log com um nome diferente e definir o caminho o mesmo que o antigo arquivo de log com um nome de arquivo diferente.

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

  1. Backup DB
  2. Desanexar DB
  3. Mudar o nome do arquivo de Log
  4. Anexar DB (enquanto anexar remover renomeado .ldf (arquivo de log).Selecione-o e remova pressionando o botão Remover)
  5. Novo arquivo de log será recriado
  6. Excluir arquivo de Log Renomeado.

Isso vai funcionar, mas é recomendável fazer backup de sua base de dados primeiro.

Exemplo:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Isso aconteceu comigo, onde o banco de dados do arquivo de log foi, de 28 de GBs.

O que você pode fazer para reduzir esse?Na verdade, os arquivos de log são aqueles ficheiro de dados que o SQL server mantém quando uma transação.Para uma transação para o processo do SQL server aloca páginas para o mesmo.Mas após a conclusão da transação, estes não são liberados, de repente, na esperança de que pode haver uma transacção vinda como o mesmo.Este é o espaço.

Passo 1:Primeiro Execute este comando no banco de dados de consulta explorado ponto de verificação

Passo 2:Direito do mouse no banco de dados Tarefa> fazer backup Seleccione a cópia de segurança tipo de Log de Transação Adicionar um endereço de destino e o nome do arquivo para manter o backup de dados (.bak)

Repita este passo novamente e neste momento dar outro nome de ficheiro

enter image description here

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

Tarefas> Encolhe> Arquivos Escolha o tipo de Ficheiro como Registo Reduzir a ação como liberar espaço não utilizado

enter image description here

Passo 4:

Verifique o arquivo de log normalmente no SQL 2014 isso pode ser encontrado em

C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL\DATA

No meu caso, a sua redução a partir de 28 GB para 1 MB

Algumas das outras respostas não funciona para mim:Não foi possível criar o ponto de verificação enquanto o db foi on-line, porque o log de transações foi completa (que ironia).No entanto, depois de configurar o banco de dados para o modo de emergência, eu era capaz de 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);

DB Log de Transação Reduzir para min tamanho:

  1. Cópia de segurança:Log de transação
  2. Reduzir arquivos:Log de transação
  3. Cópia de segurança:Log de transação
  4. Reduzir arquivos:Log de transação

Eu fiz testes em mais de um número de DBs: esta sequência de obras.

Normalmente reduz-se a 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
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top