Início > Administração de Banco de Dados, Backup, Desafio do Gordo, Dicas, Disaster Recovery, SQLManics > DESAFIO DO GORDO – Arquivo de log gigante

DESAFIO DO GORDO – Arquivo de log gigante

Galera,

Para começar bem este ano, o primeiro post de 2014 será um novo DESAFIOOOOOOOO DO GORDOOOOOOOO!!!!!!

“Orra tio, tava demorando hein? Manda ai que tô pronto pra esse esquema.”

Vamos para a descrição do nosso cenário, certo?

Temos um servidor de banco de dados SQL Server 2008 Standard Edition (X64) com um banco de dados chamado DBTeste.

O banco de dados DBTeste possui um arquivo de dados com 10 GB de espaço alocado em disco e 5 GB realmente utilizados, e possui um arquivo de log com 80 GB e 99% do espaço utilizado.

Tenho duas questões para vocês:

1) Qual o motivo deste arquivo de log ser 8x maior do que o arquivo de dados?

2) Como é possível redimensionar o arquivo de log?

“Tio, esse desafio tá bem do besta isso sim. Para diminuir esse arquivo ai é só usar aquele winzip lá e pronto. Uma vez precisei diminuir aquela minha pasta secreta sabe? Vixi, a Creusinha nunca nem desconfiou, hahahahahaahaha”

…………………………………(Ligando para a Creusinha)

“Creusinha, meu amor, que foi? Calma Creusinha, larga esse teclado, calma. Não Creusinha, na cara nããããããããão!!!!!!”

Então vamos lá pessoal, quero ver as respostas nos comentários hein?

Aproveitem e inscrevem-se no blog para receber em primeira mão todas as atualizações.

Grande abraço.

Anúncios
  1. Bruno Almeida
    06/01/2014 às 23:39

    1- Provavelmente o LogFile é 8x maior que o DataFile devido à excessiva quantidade de alterações (Insert, Update e Delete) nos dados do banco.
    2- Caso o recovery model do banco seja Full, será necessário realizar um backup de log para truncar a parte inativa do LogFile e depois utilizar o comando DBCC SHRINKFILE
    para redimensionar o tamanho do mesmo. Porém, caso haja muitas transações abertas ou muitas alterações nos dados, é bem provável que a área ativa do Log esteja sendo utilizada, o que inviabiliza o comando de shrink. Se o recovery model for Simple, não será necesssário o backup de log, pois o próprio SQL Server faz o truncamento após o Checkpoint. Sendo assim, será necessário somente o DBCC SHRINKFILE, que fará o redimensionamento da área inativa do LogFile.

  2. Renato
    07/01/2014 às 2:48

    Oi Fava!
    Na minha opinião:

    1) Qual o motivo deste arquivo de log ser 8x maior do que o arquivo de dados?

    Auto-growth do arquivo de log. Perderam o controle ao gerenciar a base e o log foi crescendo sem parar (isso geralmente ocorre quando o crescimento é por porcentagem).
    Se o log não estivesse no talo, eu até diria que foi um Script Database de produção pra outro ambiente, e o tamanho acabou indo na manada.

    2) Como é possível redimensionar o arquivo de log?

    O Recovery model tá no full (chuto)? Se não tiver nenhum backup full, basta tirar um seguido de um backup de log pra truncar os VLF’s inativos do log (pra tirar do auto-truncate). Depois da operação, mensurar qual o tamanho ideal para o arquivo de log (considerando também com a rotina de bkps de log) e dar um shrink no arquivo de log.

  3. JeffDBA
    24/06/2014 às 11:22

    1)
    Muito INSERTs , UPDATEs e DELETEs , pode ser por uma aplicação ou seja, o que for, e não tem rotina de limpeza de backup.
    A verificação do log é uma rotina diária do DBA.

    2)
    Crie uma rotina de backup (agent, script, etc…) de T-log conforme a sua necessidade e o espaço em disco. Lembrando que o T-log não impacta muito no banco ao ser feito, seu problema maior é na demorar do restore (comparado com um backup Diff).
    Guarde os arquivo de backup t-log em um local seguro e ‘lime-os’ conforme sua regra de recuperação de dados.

    *Após fazer o primeiro backup de log (vai demorar pacas esses 80GB), faça um shirink do arquivo (como vai demorar muito, será necessário fazer 1 segundo backup de log após o primeiro), Após faça o shirink para um tamanho “aceitável” para evitar que o arquivo fique crescendo toda hora e que fique impactando no banco , além de evitar a fragmentação causada pelo shrink.

  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: