Usuário com melhor resposta
Sql Express reduzir tamanho do banco

Pergunta
-
Respostas
-
jceoms
Não, perder dados, não...
Porém o shrink pode causar uma fragmentação muito grande no banco, causando lentidão em algumas consultas, por exemplo. Por isso o trabalho posterior de manutenção de índices e estatísticas. Mas isso vai fazer o teu banco crescer um pouco mais novamente, devido a reorganização (ou rebuild) dos índices.
[]'s!
/* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */Essa lentidão é causada por que todas as referencias são perdidas/alteradas !!!!
Por isso é importante você atualizar as estatísticas, lembrando que isso não vai impedir uma lentidão no primeiro momento já que o SQL está refazendo todos os planos de execução !!!Para atualizar as estatísticas use isso:
EXEC sp_updatestats;
Para ler mais vá aqui:
Flávio Farias
"May the Force be with you"
Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"- Marcado como Resposta jceoms quinta-feira, 22 de outubro de 2015 19:07
Todas as Respostas
-
jceoms,
Se vocês precisam diminuir o espaço em disco do servidor, essa é a forma. Mas honestamente, eu evitaria, pois o shrink database pode causar mais problemas do que benefício. Até porque se é por causa do backup, por exemplo, você pode usar a opção COMPRESSION.
Agora, se optar pelo shrink, não se esqueça de realizar as manutenções no servidor posteriormente.
[]'s!
/* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */ -
-
jceoms
Não, perder dados, não...
Porém o shrink pode causar uma fragmentação muito grande no banco, causando lentidão em algumas consultas, por exemplo. Por isso o trabalho posterior de manutenção de índices e estatísticas. Mas isso vai fazer o teu banco crescer um pouco mais novamente, devido a reorganização (ou rebuild) dos índices.
[]'s!
/* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */ -
-
jceoms
Não, perder dados, não...
Porém o shrink pode causar uma fragmentação muito grande no banco, causando lentidão em algumas consultas, por exemplo. Por isso o trabalho posterior de manutenção de índices e estatísticas. Mas isso vai fazer o teu banco crescer um pouco mais novamente, devido a reorganização (ou rebuild) dos índices.
[]'s!
/* Logan Destefani Merazzi - DBA | @LoganMerazzi | http://www.merazzi.eti.br
Se a resposta for útil, vote nela. Se resolveu, marque-a como resposta. */Essa lentidão é causada por que todas as referencias são perdidas/alteradas !!!!
Por isso é importante você atualizar as estatísticas, lembrando que isso não vai impedir uma lentidão no primeiro momento já que o SQL está refazendo todos os planos de execução !!!Para atualizar as estatísticas use isso:
EXEC sp_updatestats;
Para ler mais vá aqui:
Flávio Farias
"May the Force be with you"
Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"- Marcado como Resposta jceoms quinta-feira, 22 de outubro de 2015 19:07
-
Não só isso, a grande lentidão, vem de fragmentações internas.
Imagina o seguinte, você tem um indice fragmentado, e como é do engine do sql server, as paginas ficam em memoria. Portanto, quando se tem fragmentação interna, os dados que estão em memorias, não estão referenciados, então o sql server necessitará realizar o processo de trash dessas paginas e fará requisições de I/O para ler as paginas que estão em discos e coloca-la novamente em memoria. Por isso o shrink não é recomendado, porque você gera diversas fragmentações, entre outros.
abs,
Vinícius Kleber
-
Não só isso, a grande lentidão, vem de fragmentações internas.
Imagina o seguinte, você tem um indice fragmentado, e como é do engine do sql server, as paginas ficam em memoria. Portanto, quando se tem fragmentação interna, os dados que estão em memorias, não estão referenciados, então o sql server necessitará realizar o processo de trash dessas paginas e fará requisições de I/O para ler as paginas que estão em discos e coloca-la novamente em memoria. Por isso o shrink não é recomendado, porque você gera diversas fragmentações, entre outros.
abs,
Vinícius Kleber
Flávio Farias
"May the Force be with you"
Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil" -
Em relação as estatisticas, geralmente tem mais impacto sobre performance do que a fragmentação.
Se Q.O derivar de uma cardinalidade de forma errada, não gerar um plano bom, não existirá indice que salve.
É sempre bom manter as estatisticas atualizadas, existem diversos scripts que atualizam as estatisticas, eu uso o do ola.hallengren.com. As estatisticas ficam desatualizadas, devido aos inserts, updates e delete do dia a dia.
Outra coisa referente ao shrink, shrink em t-log não é bom, devido você forçar o seu log a tomar um efeito sanfona, pois toda vez que seu log realiza um grownth ele coloca todos os processos da base em suspended para ele zerar o log para garantir integridade.
E você tem dois wait types WriteLog e o preemptive_os_writefilegather.
abs,
Vinícius Kleber
- Editado Vinícius Matias quinta-feira, 22 de outubro de 2015 19:25