Definir manualmente o tamanho do arquivo de log após reduzir o SQL Server 2008 R2

Estou me tornando um DBA involuntário no trabalho no momento e realmente preciso de ajuda em alguma coisa.

Temos um banco de dados de 40 GB no modo de recuperação total, nenhum backup de log configurado e um enorme arquivo de log de 84 GB. Até agora, meu plano para recuperar essa situação é executar um backup de log completo no banco de dados, reduzir o arquivo de log e instigar um plano de manutenção para executar um backup de log todas as noites com o backup do banco de dados para ajudar a mantê-lo sob controle.

Meu problema é que não quero que o arquivo de log diminua e passe a primeira manhã de segunda-feira em constante crescimento. Tenho uma estimativa aproximada de qual deve ser o arquivo (cerca de 20% do banco de dados) e gostaria de definir isso desde o início para garantir o máximo de espaço contíguo possível. É apenas um caso de alteração do "Tamanho inicial" em Propriedades do banco de dados -> Arquivos? Eu acho que também o banco de dados precisa estar offline para que isso ocorra?

desde já, obrigado

Basta encolher para o que você acha que é o tamanho ideal. Não use a interface do usuário, faça isso - digamos que 200 MB é o seu tamanho ideal:

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

Se você estiver interessado apenas em fazer um backup de log uma vez por dia e não estiver interessado em recuperação pontual, mude para um modelo de recuperação simples. Isso significa que os backups de log são desnecessários (de fato impossíveis), mas o conteúdo do log é autogerenciado.

Se você deseja que os backups de log sejam significativos, não planeje fazer um backup completo à noite e, em seguida, faça um único backup logo após. Isso mantém você no modelo de recuperação total, torna o log muito difícil e não compra nada. Portanto, se você deseja recuperação point-in-time, execute backups de log com mais frequência a uma taxa que satisfaça sua tolerância à perda de dados. Se você nunca quiser perder mais de 15 minutos de dados, execute um backup de log a cada 15 minutos.

Seu gerenciamento de arquivos pode ser uma operação totalmente online. Você tem dois caminhos, dependendo da necessidade de manter suas informações de log para fins de recuperação:

Recuperação pontual não necessária

1. Converta o banco de dados em SIMPLErecuperação. Execute um ponto de verificação para gravar transações no disco.
2. Achate o log.
3. Redimensione o log para o tamanho apropriado.

Também recomendo definir uma quantidade fixa de crescimento e um crescimento ilimitado (para ajudar a gerenciar melhor o seu log). Observe que a quantidade fixa de crescimento depende muito da quantidade, recomendo que você comece com 1 a 2 GB inicialmente, dependendo da quantidade de crescimento que o log pode esperar. Idealmente, seu log não crescerá muito, portanto, isso não deve causar muito impacto. Se o seu log estiver crescendo regularmente, pode ser necessário revisitar seu tamanho.

Realizado usando:

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

Recuperação pontual necessária

O maior problema é que você não pode reduzir seu arquivo de log além do segmento VLF atualmente ativo. Para ver isso, você pode usar DBCC LOGINFOno contexto do banco de dados. Qualquer segmento com um Status = 2 está ativo. Para limpar segmentos ativos, você precisará executar um backup do log de transações quando nenhuma transação estiver ativa nesse segmento no momento. Suas etapas são:

1. Execute um backup do log de transações.
2. Encolha seu arquivo. (Idealmente, aplainar, mas se seu banco de dados estiver ativo, será difícil).
3. Repita as etapas 1 e 2 até que seu log tenha um tamanho apropriado, idealmente o menor possível.
4. Redimensione o log para o tamanho apropriado.

Realizado usando:

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

Alguns recursos adicionais para entender o que está acontecendo aqui:

• Modelos de recuperação do SQL Server

• Recomendações t-log de Kimberly Tripp

• Pontos de verificação do banco de dados

Na verdade não, o banco de dados não precisa estar offline para reduzir o log. E direi que este é provavelmente um dos poucos casos em que diminuir o log é uma boa ideia. Você pode definir o tamanho inicial, mas seria mais fácil diminuir o tamanho e pedir que ele diminuísse para um tamanho específico.

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

Você também pode fazer isso usando a GUI e o segundo botão de opção e a caixa de seleção que diz qual o tamanho que você deseja que o log tenha no final. Você pode acessar a GUI clicando com o botão direito do mouse no banco de dados no Pesquisador de Objetos no SSMS, selecionando tarefas, reduzir, arquivos.

Em complemento à resposta de Aaron sobre o modo simples , você pode agendar 2 (ou mais) backups diferenciais por dia, reduzindo assim a janela de perda de dados da operação do banco de dados e mantendo o modo SIMPLE.