none
Sql Express reduzir tamanho do banco RRS feed

  • Pergunta

  • Usamos sql express 2012

    nossa base tem 6.3 gigas

    eliminamos uma tabela que tinha 5 milhoes de registros

    devo fazer  o srink database para reduzir o tamanho do mdf do banco?

    quinta-feira, 22 de outubro de 2015 18:42

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:

    Update Statistics


    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
    quinta-feira, 22 de outubro de 2015 19:05

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. */

    quinta-feira, 22 de outubro de 2015 18:52
  • isto significa que posso perder dados com  o srink?
    quinta-feira, 22 de outubro de 2015 18:54
  • 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. */

    quinta-feira, 22 de outubro de 2015 18:57
  • fiz um teste com o srink

    o banco de 6.3  fica em 4.2

    quinta-feira, 22 de outubro de 2015 18:59
  • 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:

    Update Statistics


    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
    quinta-feira, 22 de outubro de 2015 19:05
  • 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

    quinta-feira, 22 de outubro de 2015 19:11
  • 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

    Mas no caso de um banco SQLExpress, onde seu limite são 10 GB, uma redução de 2GB compensa isso !!!! Não que seja recomendado !

    Flávio Farias
    "May the Force be with you"
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 22 de outubro de 2015 19:17
  • 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




    quinta-feira, 22 de outubro de 2015 19:24