DBCC ShirinkFile
03/04/2014
0
Gostaria de sugestoes, ou que me ajudassem no pensamento a respeito do BDCC Shrinkfile do SQL Server.
Estou com arquivos de logs que vem crescendo consideravelmente, elaborei minhas rotinas de Backps Full, Diferenciais e de Log e os LDFs nao diminuiram enquanto eu nao fizem o Shrink, pelo menos foi isso q eu entendi.
A minha questao eh, qual eh o procedimento correto para se fazer o Shrink?
para executa-lo sempre tera que ser feito a alteracao do recovery do banco?
Como devera ser o procedimento para implanta-lo em um job, e qual sua periodicidade ideal?
Gostaria de exaurir o assunto para poder fazer, e acredito que essa discussao seja saudavel para todos nos.
Desde ja agradeco a Todos que se dispuserem a me ajudar em mais essa.
Abraco.
Alex - Lekao
Alex Lekao
Posts
04/04/2014
Fabiano Carvalho
Sei somente isso, não tenho tanta experiencia com manutenção.
04/04/2014
Alex Lekao
Obrigado.
CAra eh basicamente a impressao que tenho, mas fica meio vago ne?
Parece que quando falam para nos fazermos assim, eh so para se livrar da gente e tirar o BO da frente... rsrsr
Mais uma vez obrigado, acho que vou ter que colocar isso no job e deixar agendado para uma vez por mes.
Nao estou vendo muita opcao, mas vamos aguardar para ver se mais alguem se aventura em tentar nos ajudar nessa. rsrsr
Abraco.
Alex - Lekao
04/04/2014
Roniere Almeida
05/04/2014
Fabiano Carvalho
07/04/2014
Alex Lekao
Nao tenho tanto conhecimento assim, mas acho que um exemplo seria isso sim.
Porque se vc fizer no banco de dados se nao me engano ele verifica espacos vazios e faz o ajuste, no caso do Log se nao estou enganamo ele remove os registros de log ate o tamanho ou percentual que vc definir respeitando sempre o tamanho origem do arquivo.
Acho que Desfragmentacao, mais ou menos... rsrsr
mas nao sou a pessoa mais indicada porque o meu conhecimento nao eh tao grande assim. rsrsr
Abraco.
Alex - Lekao
07/04/2014
Alexandre Matayosi
O shrink faz a compactação do espaço não utilizado da base de dados, por exemplo, se a base tem o tamanho total de 100GB mas o SQL Server só esta utilizando 70GB o shrink iria eliminar estes 30GB que não estão sendo utilizados porem estão pré alocados para o SQl Server.
Porem como o seu recovery model esta como FULL todas as transações são gravadas no arquivo de log o que faz o log de transação crescer, se voce fizer o shrink e eliminar todo o espaço livre na proxima transação que a base de dados fizer e precisar de espaço ela vai crescer em porcentagem que voce definiu na configuração, normalmente 10% e reservar este espaço para informações que vão entrar na base.
Tem que ter um cuidado na utilização do Shrink, pois o mesmo não tem a função de desfragmentar e sim com o ajuste do tamanho do banco de dados ele acaba fragmentando o disco.
07/04/2014
Roniere Almeida
07/04/2014
Alex Lekao
07/04/2014
Alex Lekao
Obrigado por responder.
Eh justamente por isso que ainda nao implementei nada disso, porque estou preocupado com essa funcionalidade, e estou precisando de algo que me ajude, porque o meu hd do banco de dados esta ficando cada dia menor.
e os logs estao cada dia maiores.
estou perdendo um espaco precioso em disco sendo ocupados por log, o que preciso eh ter uma diminuicao ou ajuste disso periodicamente, ja implementei as rotinas de backups full e diferenciais e de log, agora preciso que esses logs diminuam, porque ja estou com quase 100GB de espaco sendo usado pelos arquivos de log.
Obrigado mais uma vez por responder.
Abraco.
Alex - Lekao
08/04/2014
Roniere Almeida
totalmente, se alguem achar algum conteudo bom, por favor postar.
10/04/2014
João Françozo
O shrink no banco de dados pode ser feito a qualquer momento desde que a empresa esta parada pois dependendo do tamanho do banco de dados pode causar lentidão.
A primeira opção é alterar a forma que o SQL Server cuida do log, mudando o Recovery Model de FULL para SIMPLE. Isso é o mais comum e o mais encontrado por ai. Quando você faz isso, o SQL Server para de gravar LOGs das transações executadas (insert, delete, update) e você não conseguirá restaurar um backup para um ponto específico de data e hora baseado nos LOGs.
Isso vai depender como você esta gerenciando o backup, se fazer a alteração do Recovery para SIMPLE o arquivo de log não vai crescer porem você tem que fazer mais backup durante o dia para maior segurança, caso contrario o log vai crescer e criando lentidão no banco para algum retorno.
Att.
João Antonio
10/04/2014
João Françozo
O shrink no banco de dados pode ser feito a qualquer momento desde que a empresa esta parada pois dependendo do tamanho do banco de dados pode causar lentidão.
A primeira opção é alterar a forma que o SQL Server cuida do log, mudando o Recovery Model de FULL para SIMPLE. Isso é o mais comum e o mais encontrado por ai. Quando você faz isso, o SQL Server para de gravar LOGs das transações executadas (insert, delete, update) e você não conseguirá restaurar um backup para um ponto específico de data e hora baseado nos LOGs.
O FULL é importante para recuperar informação de um momento específico de dentro do LOG, depois de mudar o recovery model de SIMPLE pra FULL, é a necessidade de fazer um backup FULL da base. Sem isso, a restauração em um caso de desastre, só seria possível com base no ultimo backup dos dados realizado, e não do LOG.
Isso vai depender como você esta gerenciando o backup, se fazer a alteração do Recovery para SIMPLE o arquivo de log não vai crescer porem você tem que fazer mais backup durante o dia para maior segurança, caso contrario o log vai crescer e criando lentidão no banco para algum retorno.
Att.
João Antonio
10/04/2014
João Françozo
O shrink no banco de dados pode ser feito a qualquer momento desde que a empresa esta parada pois dependendo do tamanho do banco de dados pode causar lentidão.
A primeira opção é alterar a forma que o SQL Server cuida do log, mudando o Recovery Model de FULL para SIMPLE. Isso é o mais comum e o mais encontrado por ai. Quando você faz isso, o SQL Server para de gravar LOGs das transações executadas (insert, delete, update) e você não conseguirá restaurar um backup para um ponto específico de data e hora baseado nos LOGs.
O FULL é importante para recuperar informação de um momento específico de dentro do LOG, depois de mudar o recovery model de SIMPLE pra FULL, é a necessidade de fazer um backup FULL da base. Sem isso, a restauração em um caso de desastre, só seria possível com base no ultimo backup dos dados realizado, e não do LOG.
Isso vai depender como você esta gerenciando o backup, se fazer a alteração do Recovery para SIMPLE o arquivo de log não vai crescer porem você tem que fazer mais backup durante o dia para maior segurança, caso contrario o log vai crescer e criando lentidão no banco para algum retorno.
Att.
João Antonio
10/04/2014
Alex Lekao
Obrigado por responder.
Deixa eu comentar um pouco da estrutura que tenho montada, e meus backups demoram coisa de um minuto ou menos para executar.
Hoje tenho um Backup Full por dia, feito por volta das 11 horas da noite, durante o dia sao feitos 3 Backups Diferenciais em momentos durante o dia que dao um intervalo de 3 em 3 horas cada um, e backups de log neste intermeio, de hora em hora.
Full as 23 horas.
Diferencial as 11, 14 e 17 horas.
Logs as 09, 10, 12, 13, 15, 16, 18, 19, 20, 21 e 22.
A minha intencao eh colocar um Shrink ou depois das 22 e antes das 23 ou apos as 23 horas, mas nao sei se o ideal eh faze-lo todos os dias ou agendado para executar uma vez a cada mes, bimestre, etc.
Uma outra coisa que fiquei em duvida no seu comentario foi a respeito de um backup full apos o Shrink, pelo menos eu entendi assim, me desculpe se entendi errado. rsrsr
Existe sempre essa necessidade? um backup Full apos um Shrink, mesmo que ja exista uma rotima com Backups Full?
Olha, muito obrigado mesmo por se interessar em me ajudar nesta questao.
Abraco.
Alex - Lekao
Clique aqui para fazer login e interagir na Comunidade :)
