[Resolvido] banco com 8 giga LOG 115giga

[drago 0]

Boa tarde

 

Desda semana passada de um queda de força na empresa que estou tendo problema com SQl 2008 .

Tenho base de dados de 8 giga no servidor so que gerou um log que esta no tamanho de 115 gigas de log meu servidor esta travando .

Existe a possibilidade de restaurar a base sem log .

restaurar so informação do dados.

olhando a base eo log esta em duplicidade alguns itens de algumas tabelas.

 

qual quer ajuda palpite e bem vindo .

obrigado desde já pela força

[advaldomesquita 93]

Drago, o log em si eh o arquivo LDF? Se for eh possivel diminui-lo.... mas eu nao entendi esta parte

 

olhando a base eo log esta em duplicidade alguns itens de algumas tabelas.

 

Abçs

[drago 0]

opa boa tarde

 

Entao apliquei alguns comando no sql para diminuir paginas, comessei com 2000000 foi caindo ate 40000 mas nao teve efeito sobre log.ldf

to com bomba na mao que nao para de crescer ..

 

 

Drago, o log em si eh o arquivo LDF? Se for eh possivel diminui-lo.... mas eu nao entendi esta parte

 

 

olhando a base eo log esta em duplicidade alguns itens de algumas tabelas.

 

Abçs

 

[drago 0]

Estou tentando esse comando mas nao funciona a funçao TRUNCATE_ONLY no sql 2008

 

backup log NomeDaBD with NO_LOG

backup log NomeDaBD with TRUNCATE_ONLY

DBCC SHRINKDATABASE(NomeDaBD)

[advaldomesquita 93]

drago, no sql2008 os comandos sao kases esses, mas tem que ver como estao configurados o recovery da database:

Faca assim:

Passo 1

botao direito em cima da database --> propriedades --> options

Verifique nesta tela o item Recovery Model... se estiver em Simple beleza va ao passo 2, se nao tive altere....

e va ao passo 2

 

Passo 2:

botao direito em cima da database --> Shink Files -- > Escolha o arquivo de LOG (em file type)

*** Nesta tela jah aparece a qtde de espaco que vai ser desalocado (Avaliable free space)

Deixe marcado a opcao Release unsed space

 

De ok

 

 

Se o log nao diminuir tem outras coisas a serem analisadas, como processos rodando em seu db....

[Fernando Silveira 1]

drago

 

O importante é você não correr o risco de perder dados que ainda possam estar no arquivo de log. Feche as conexões dos usuários conectados a essa base de dados, faça um backup do tipo full, depois faça o procedimento de limpeza do arquivo de log e tente diminuir o tamanho. Por último, faça novamente um backup do tipo full.

 

[]'s

 

Fernando Silveira

[alex_fsi 0]

Fernando, há uma forma de, periodicamente, executar as operações que ainda estão pendentes no LOG e efetuar a limpeza do mesmo?

Quais são os comandos necessários?

 

No caso, vejo muito a recomendação de utilizar o backup do log com a opção truncateOnly, e depois executar o DBCC Shrinkfile().

 

No caso, quais os riscos da operação acima?

 

Estou com alguns problemas em relação a isto....

 

Obrigado.

 

Alex

[Fernando Silveira 1]

alex_fsi

 

Fernando, há uma forma de, periodicamente, executar as operações que ainda estão pendentes no LOG e efetuar a limpeza do mesmo?

R: Sim. você pode criar uma estratégia de backup para sua base de dados. Através de backup's do tipo full, diferencial e log você consegue administrar o crescimento e a limpeza desse arquivo.

Uma outra sugestão seria mudar o "Recovery model" da base de dados para o modo "Simple", com isso você não precisa se preocupar em limpar e diminuir o arquivo de log, pois o SQL Server limpa esse arquivo após a gravação das informações no arquivo de dados. Importante observar que no modo “simple” não é possível trabalhar com backup em nível de log.

Sugiro que você faça uma analise do cenário para identificar a melhor opção de configuração para a base e qual a estratégia de backup mais indicada.

 

Quais são os comandos necessários?

R: Os comandos necessários são exatamente os comandos de backup. Após a realização de um backup completo, você pode executar o comando "backup log nome_banco with truncate_only" para limpar o arquivo de log. Não recomendo a utilização do comando shrinkfile com tanta freqüência, o ideal seria alocar espaço em disco para o arquivo de log e administrar o seu uso através das rotinas de backup.

 

No caso, quais os riscos da operação acima?

R: É verdade que muitos recomendam a utilização desse comando, mas o importante é saber utiliza-lo no momento certo para não interferir na sua estratégia de backup. Utilizar esse comando a qualquer momento pode trazer grandes perdas de dados numa eventual necessidade de restauração da base de dados. Por isso recomendo sempre a realização de um backup full após a execução desse comando.

 

[]'s

 

Fernando Silveira

[drago 0]

Boa tarde..

 

Muita correria por aqui no serviço, mas vamos la.

Final de semana passado especificamente no sábado. Eu fiz os procedimentos dos colegas, Junior e Fernando Silveira , no laboratório aqui e funcionou tudo belezinha.

hoje meu log do SQL 2008 esta funcionando com 200 ~ 250 terminal pendurando e não passa de 4 megas . A noite na manutenção de rotina e backup full , baixa para 900k o log .

 

Desde já agradeço pelas dicas dos amigos ..

Muito Obrigado .

 

Forte Abraço

Drago.

[Fernando Silveira 1]

drago

 

Obrigado pelo retorno!

 

Só uma dica: Seu banco de dados utiliza em média 4 mega de log por dia, isso é um número baixo. No seu caso, acredito que mudar o "Recovery model" da base de dados para o modo "Simple" é mais produtivo do que executar o comando shrink todas as noites para diminuir o arquivo de log. Isso também gera um custo de I/O durante o dia quando é necessário alocar mais espaço em disco para o arquivo de log. Trabalhando no modo simple você elimina esses dois processos e faz apenas o backup full na madrugada.

 

[]'s

 

Fernando Silveira