Início / dba / Perguntas / 119184
Accepted
Reaces
Asked: 2015-10-27 03:28:21 +0800 CST

Encolhendo arquivos de log no desenvolvimento

  • 772

Estou tentando recuperar algum espaço em disco em algumas de nossas máquinas de desenvolvimento.
Estas são máquinas que não estão tendo backup, não estão sendo desenvolvidas diretamente e não estão sendo mantidas particularmente bem.
Qualquer recuperação é feita de PRD ou PRE-PRD para o ambiente DEV, nada neste ambiente DEV específico é crítico.

Os modelos de recuperação nesses bancos de dados devem permanecer ativados FULLporque foram ordenados (apesar de nenhum backup real ser feito).
Como esses bancos de dados, em alguns casos, existem há algum tempo sem backups, estou procurando uma maneira adequada de reduzir seus logs.

Eu encontrei duas abordagens que podem servir ao propósito:

BACKUP LOG [databasename] TO DISK=’NUL:’

Seguido pela redução do log.

Ou:

ALTER DATABASE [databasename] SET RECOVERY SIMPLE;
ALTER DATABASE [databasename] SET RECOVERY FULL;

Seguido pela redução do log.

Minhas perguntas atuais:
Quais são as diferenças entre essas duas abordagens?
Há algo que estou perdendo / negligenciando?

sql-server sql-server-2008-r2

2 respostas

  1. Best Answer

    Para este cenário, prefiro o método de fazer (adicionei WITH NO_COMPRESSIONapenas no caso de a configuração padrão do servidor usar compactação, pois não há muito sentido em usar CPU extra quando o arquivo resultante não ocupará espaço de qualquer maneira):

    BACKUP LOG [databasename] TO DISK = 'NUL:' WITH NO_COMPRESSION;

    A razão pela qual prefiro esse método em vez de alternar para SIMPLEe depois voltar FULLé que ele não altera o processo geral de backup. Assim você consegue ter mais consistência entre seus ambientes. Ele também permite que você tenha um ambiente de teste para o seu processo de backup porque não é diferente do que você tem na Produção. E se enviar o arquivo para NUL: apresentar muita diferença, então é só enviar para uma pasta onde o arquivo de backup possa ser deletado.

    Virar para SIMPLEe depois voltar para FULLtorna mais difícil testar DIFFbackups erencial, pois você precisa ter um FULLbackup primeiro. Portanto, se você fizer um backup COMPLETO uma vez por semana e DIFF no resto da semana, alternar para SIMPLEe voltar FULLfuncionaria se feito logo antes do FULLbackup semanal, mas não em qualquer outro momento durante a semana. Por outro lado, fazer o LOGbackup e direcioná-lo para NUL: ou excluir o arquivo de backup pode ser feito a qualquer momento durante a semana.

    Além disso, fazer o LOGbackup e direcioná-lo para NUL: ou excluir o arquivo de backup permite manter um arquivo LOG / .ldf pré-criado . E nesse ponto você pode usar DBCC SHRINKFILE para impor um tamanho inicial máximo do arquivo LOG vazio e não ficar preso a um arquivo que cresceu MUITO devido à reindexação ou outra coisa.

    OBSERVE que livrar-se de seus backups de LOG significa que você não poderá restaurar pontos no tempo entre seus backups FULL / DIFF. Obviamente, se você não tiver backups FULL / DIFF em primeiro lugar, esse é um ponto discutível.

    • 3

  2. quando você faz BACKUP LOG [databasename] TO DISK=’NUL:’, é como fazer um backup para uma unidade que nunca existe, é como um backup de log normal, mas na verdade não faz backup do log e finge de certa forma, por não ocupar nenhum espaço.

    Isso não é uma boa prática, mas como você disse que isso é DEV e não é crítico, você pode abordá-lo apenas quando estiver em uma situação em que quase não há espaço na unidade e pode derrubar o sistema.

    Caso você não seja tão ruim no espaço, você deve seguir a segunda abordagem de fazer o backup de log primeiro e, em seguida, alterar os modelos de recuperação de COMPLETO para Simples e de volta para COMPLETO de acordo.

    Considerando que o ponto no tempo de recuperação é o que não é uma preocupação aqui, você pode,

    ALTER DATABASE DBNAME SET RECOVERY SIMPLE;


USE DBNAME;
GO
CHECKPOINT;
GO
CHECKPOINT;
GO

DBCC SHRINKFILE(DB_log, 512);-- 512 is something you can adjust accordingly
GO

    E então ajuste a configuração/crescimento do arquivo de acordo

    USE [master];
GO
ALTER DATABASE DBNAME 
  MODIFY FILE
  (NAME = DB_log, SIZE = 520 MB, FILEGROWTH = 256MB);-- 512 and 256 should be adjusted as analysed from database growth events
GO

    Além do acima, leia a resposta de Aaron Por que o log de transações continua crescendo ou fica sem espaço? para melhor compreensão

    • 0

relate perguntas