DBCC ShirinkFile
Ola Senhores, boa tarde!!!
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
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
Curtidas 0
Respostas
Fabiano Carvalho
03/04/2014
Quando me explicaram, quando o log da base é FULL (Somente quando é full) é necessário alterar pra simple realizar o shirink e em seguida voltar para full.
Sei somente isso, não tenho tanta experiencia com manutenção.
Sei somente isso, não tenho tanta experiencia com manutenção.
GOSTEI 0
Alex Lekao
03/04/2014
Oi Fabiano, bom dia!!!
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
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
GOSTEI 0
Roniere Almeida
03/04/2014
primeiramente, me desculpem por me meter e não saber nada sobre o assunto. eu sei uma base sobre esses backups e confesso que nunca tinha ouvido falar sobre o mesmo, alguem poderia me explicar, o que na forma mais simples possivel. obrigado.
GOSTEI 0
Fabiano Carvalho
03/04/2014
Shirink é uma organização/Limpeza feita nos arquivos de cada base dados, isso é feito via script ou pelo wizard.
GOSTEI 0
Roniere Almeida
03/04/2014
como se fosse um desfragmentador?
GOSTEI 0
Alex Lekao
03/04/2014
Ola Bom dia!!!
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
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
GOSTEI 0
Alexandre Matayosi
03/04/2014
Boa tarde !
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.
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.
GOSTEI 0
Roniere Almeida
03/04/2014
desculpa a comparação, hehehe, mas faz mais ou menos isso.
GOSTEI 0
Alex Lekao
03/04/2014
a impressao que da eh essa mesma. rsrsr
desculpa a comparação, hehehe, mas faz mais ou menos isso.
GOSTEI 0
Alex Lekao
03/04/2014
Oi Alexandre, boa tarde!!!
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
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
GOSTEI 0
Roniere Almeida
03/04/2014
a impressao que da eh essa mesma. rsrsr
desculpa a comparação, hehehe, mas faz mais ou menos isso.
totalmente, se alguem achar algum conteudo bom, por favor postar.
GOSTEI 0
João Françozo
03/04/2014
Bom dia Alex,
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
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
GOSTEI 0
João Françozo
03/04/2014
Bom dia Alex,
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
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
GOSTEI 0
João Françozo
03/04/2014
Bom dia Alex,
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
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
GOSTEI 0
Alex Lekao
03/04/2014
Oi Joao, bom dia!!!
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
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
GOSTEI 0
João Françozo
03/04/2014
Boa Tarde Alex,
Se o Backup FULL for antes de rodar o SHIRINK não preciso se for depois é mais uma segurança.
O Backup FULL substitui os arquivos de log.
O que pode ser implementado nos JOB de BACKUP são as notificações via e-mail quando houver algum erro ou quando o backup foi realizado com sucesso.
Também pode ser feito uma replicação de dados entre servidores caso um parar ativar o outro, se quiser saber mais de replicação de dados estou a disposição.
Email : joaofrancozo@gmail.com
Skype : JoaoTassoli
Att.
João Antonio
Se o Backup FULL for antes de rodar o SHIRINK não preciso se for depois é mais uma segurança.
O Backup FULL substitui os arquivos de log.
O que pode ser implementado nos JOB de BACKUP são as notificações via e-mail quando houver algum erro ou quando o backup foi realizado com sucesso.
Também pode ser feito uma replicação de dados entre servidores caso um parar ativar o outro, se quiser saber mais de replicação de dados estou a disposição.
Email : joaofrancozo@gmail.com
Skype : JoaoTassoli
Att.
João Antonio
GOSTEI 0
Alex Lekao
03/04/2014
Oi Joao, boa tarde!!
Desculpe a demora, mas acho que nao recebi e-mail informando a sua resposta. rsrsr
Eu nao entendi, se eu uso a opcao Full de Backup, eu nao preciso fazer os backups de log? mas isso so na questao do Shrink, certo?
Cara, honestamente eu nao consegui entender mesmo, o que vc disse a respeito do Backup full substituir o log. rsrsr
Eu ja faco uso das notificacoes do job, eh muito util isso.
No momento nao daria para fazer replicacoes e tal, mas tenho intencao de no futuro comecar a fazer, mas por hora nao da. rsrsr
Obrigado.
Alex - Lekao
Desculpe a demora, mas acho que nao recebi e-mail informando a sua resposta. rsrsr
Eu nao entendi, se eu uso a opcao Full de Backup, eu nao preciso fazer os backups de log? mas isso so na questao do Shrink, certo?
Cara, honestamente eu nao consegui entender mesmo, o que vc disse a respeito do Backup full substituir o log. rsrsr
Eu ja faco uso das notificacoes do job, eh muito util isso.
No momento nao daria para fazer replicacoes e tal, mas tenho intencao de no futuro comecar a fazer, mas por hora nao da. rsrsr
Obrigado.
Alex - Lekao
GOSTEI 0