Boa prática, tudo gira em torno de boas práticas.
Mas muita gente esquece delas quando passa por um momento de crise ou simplesmente não lê a docuementação do produto. Existem muitas razões para criarmos mais do que um arquivo de log de transações no SQL SERVER:
- Existe uma transação gigantesca em execução e o disco onde está o LOG está com o espaço no final…
- That’s it….
Sim, não existe outra razão, apenas nos salvar num momento onde a base não pode parar…. Isso porque a escrita no LDF é totalmente serial, ou seja, o SQL SERVER sempre vai usar apenas UM arquivo por vez, diferente de um possível balanceamento via Filegroups (procurem pelos posts do Paul Randall no google, em breve coloco eles como referência).
O que acontece é que muitas vezes resolvemos o incidente, mas não lembramos de fazer a limpeza posterior…. Devemos limpar a sujeira temporária, como ficará a imagem do DBA quando virem dois ou mais arquivos de LOG desnecessários?
First things first:
- Você consegue remover os arquivos de log que tenham ID diferente de 2 ou seja, não são o inicial. Nem adianta procurar como remover o 2, não perca seu tempo!
- Log de transações guarda adivinha, transações! Caso não esteja conseguindo remover um arquivo adicionado posteriormente, verifique as transações ativas na base (DBCC OPENTRAN) e veja porque não é possível truncar o log:
[sql]
select name, log_reuse_wait_desc
from sys.databases;
[/sql] - Você pode precisar realizar um Backup de LOG (recovery em BULK LOOGED ou FULL) antes de remover o arquivo LDF. Por que? Você precisa garantir pro SQL SERVER que as informações que ele precisa para recuperar seus dados estão sã e salvas em local seguro, caso contrário ele não deixará você remover o mesmo.
- Verifique o status de seus VLFs (Virtual Log Files) com o comando DBCC LOGINFO, caso algum VLF esteja com status 2 no fileid que você quer remover, esqueça, você precisa deixar ele sem uso (status 0) antes de prosseguir.
Aqui está o video com o passo a passo, enjoy!
