O procedimento de split ou stripping de Backup é particularmente interessante quando nos deparamos com dois problemas:

  • Depenho abaixo do esperado no momento de realização de backup de um banco por contenção de I/O;
  • Temos que disponibilizar o arquivo em algum caminho para cópia e um arquivo seria inviável pelo tamanho do mesmo.

Real World Case: Já passei por alguns casos onde este ajuste foi necessário, um cliente tinha uma base de cer

O único cuidado que devemos ter é: Você precisará de TODOS os arquivos gerados no backup para realizar o restore, tenha isso em mente.

Fazemos o split a partir do comando de backup, conforme abaixo:


 Backup database POMBO
 to disk = 'c:\emp\pombo_01.bak',
 disk = 'c:\emp\pombo_02.bak',
 disk = 'c:\emp\pombo_03.bak'
 with stats=5, compression
,copy_only --use esta opção se você não quer estragar a sua política atual de Backup!
;

 

 

Ficaria algo como na figura abaixo:

backup_stripped

 

É isso pessoal, espero ter ajudado!

 

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:
    select name, log_reuse_wait_desc
    from sys.databases;
    
  • 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!