none
Fazer Shrink em um banco de 2,6 TB RRS feed

  • Pergunta

  • Olá,

    Eu tenho um SQLServer 2008 Standard R2 em um servidor de 32GB de RAM, 5 HD de 2TB fazendo RAID5, cujo banco de dados é de 2,6 TBytes de tamanho sendo que uma tabela utiliza 96% de todo arquivo MDF, como podem ver na imagem abaixo:

    inserir a descrição da imagem aqui

    A tabela "Materia_Cliente" consiste em duas colunas de tipos:

    -TEXT, que corresponde 27% do tamanho da tabela e utilizo ela para buscar em texto;

    -IMAGE, que corresponde 73% do tamanho, são arquivos .MHT que estão incluídos imagens e textos.

    Quero extrair esses dados text e colocar em um ElasticSearch, os binários image em arquivos de um serviço de storage e fazer um SHRINK no banco, e é aqui que entra minha dúvida.

    Minha opções que pensei até agora para expurgar os dados são:

    • Fazer gradualmente a extração de dados setando NULL no campo e fazendo SHRINK junto com BACKUP LOG a cada 100.000 linhas.

    • Extrair todos os dados, utilizar DROP COLUMN e aí então fazer BACKUP LOG e SHRINK.

    Minha vontade é utilizar a primeira sugestão, mesmo sabendo que o SHRINK é um comando extremamente pesado que utiliza um alto uso de disco, pois na segunda opção por mais que seja mais rápido para excluir o dado tenho medo de ficar travado mais de 12h no SHRINK.

    Gostaria de saber se estou no caminho mais adequado para me livrar do dado, se o SHRINK pode me gerar um problema, e também se alguém imaginou uma abordagem diferente.


    quinta-feira, 28 de dezembro de 2017 12:56

Respostas

  • Jeanderson, bom dia.

    O Shrink é um processo de "baixa prioridade" pro SQL Server o que quer dizer que seu banco continuará funcionando enquanto o Shrink estiver sendo executado. O problema disso é que se você tiver muito acesso no banco, o shrink pode ficar dias executando.

    Aqui nós já tivemos um shrink numa base de 1 TB que ficou executando por 5 dias, pois a base é acessada muitas vezes por segundo.

    Não sei se é possível na sua operação, mas se você puder parar qualquer acesso à sua base por um tempo, seria mais interessante você criar um novo database com a mesma estrutura (exceto essas duas colunas TEXT/IMAGE) e fazer a cópia dos dados.

    Quando estiver ok, você pode matar o banco original,  renomear esse novo database e subir sua aplicação novamente. É um processo mais rápido que o SHRINK e mais garantido.

    Sobre isso "Fazer gradualmente a extração de dados setando NULL no campo e fazendo SHRINK junto com BACKUP

    LOG a cada 100.000 linhas." a não ser que você precise realmente desses backups de log, eu colocaria o banco como SIMPLE antes de fazer a alteração. Assim você não precisa fazer o backup de log tantas vezes assim.

    Espero ter ajudado.


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    sexta-feira, 29 de dezembro de 2017 13:18

Todas as Respostas

  • Olá,

    Como não sou especialista em SQL Server não irei opinar sobre a questão do Shrink, porem gostaria de deixar a minha contribuição sobre a Performance do Banco no que diz respeito aos Discos.

    O RAID 5 não é a melhor opção para utilização com Banco de Dados, uma vez que a sua Leitura é até que relativamente Boa, porem a sua taxa de Escrita não é das melhores. Levando em consideração apenas as questões de Perfomance, uma das melhores configurações de RAID para Banco é o RAID 10 que une o RAID 0 "Stripped" + RAID 1 "MIRROR", está configuração de RAID possui uma boa Perfomance de Leitura e Escrita, porem a "perda" de Espaço de Disco é da ordem de 50%.

    Se for possível, recomendo a alteração do RAID de 5 para RAID 10.

    A disposição,

    Marcos Roberto de Lima
    MCT-MCTS-MCITP-MCP

    Por favor, lembre-se de Marcar como Resposta as postagens que resolveram o seu problema. Essa é uma maneira comum de reconhecer aqueles que o ajudaram e fazer com que seja mais fácil para os outros visitantes encontrarem a resolução mais tarde.

    quinta-feira, 28 de dezembro de 2017 13:41
  • Olá Marcos !

    Obrigado pela sua dica!

    Realmente a performance é bem significante, inclusive estamos cogitando trocar para SSD, porém com esse tamanho do banco o custos ficam inviáveis.  

    quinta-feira, 28 de dezembro de 2017 14:57
  • Jeanderson, bom dia.

    O Shrink é um processo de "baixa prioridade" pro SQL Server o que quer dizer que seu banco continuará funcionando enquanto o Shrink estiver sendo executado. O problema disso é que se você tiver muito acesso no banco, o shrink pode ficar dias executando.

    Aqui nós já tivemos um shrink numa base de 1 TB que ficou executando por 5 dias, pois a base é acessada muitas vezes por segundo.

    Não sei se é possível na sua operação, mas se você puder parar qualquer acesso à sua base por um tempo, seria mais interessante você criar um novo database com a mesma estrutura (exceto essas duas colunas TEXT/IMAGE) e fazer a cópia dos dados.

    Quando estiver ok, você pode matar o banco original,  renomear esse novo database e subir sua aplicação novamente. É um processo mais rápido que o SHRINK e mais garantido.

    Sobre isso "Fazer gradualmente a extração de dados setando NULL no campo e fazendo SHRINK junto com BACKUP

    LOG a cada 100.000 linhas." a não ser que você precise realmente desses backups de log, eu colocaria o banco como SIMPLE antes de fazer a alteração. Assim você não precisa fazer o backup de log tantas vezes assim.

    Espero ter ajudado.


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    sexta-feira, 29 de dezembro de 2017 13:18
  • Olá,

    Como não sou especialista em SQL Server não irei opinar sobre a questão do Shrink, porem gostaria de deixar a minha contribuição sobre a Performance do Banco no que diz respeito aos Discos.

    O RAID 5 não é a melhor opção para utilização com Banco de Dados, uma vez que a sua Leitura é até que relativamente Boa, porem a sua taxa de Escrita não é das melhores. Levando em consideração apenas as questões de Perfomance, uma das melhores configurações de RAID para Banco é o RAID 10 que une o RAID 0 "Stripped" + RAID 1 "MIRROR", está configuração de RAID possui uma boa Perfomance de Leitura e Escrita, porem a "perda" de Espaço de Disco é da ordem de 50%.

    Se for possível, recomendo a alteração do RAID de 5 para RAID 10.

    A disposição,

    Marcos Roberto de Lima
    MCT-MCTS-MCITP-MCP

    Por favor, lembre-se de Marcar como Resposta as postagens que resolveram o seu problema. Essa é uma maneira comum de reconhecer aqueles que o ajudaram e fazer com que seja mais fácil para os outros visitantes encontrarem a resolução mais tarde.

    Marcos,

    Tenho uma opinião e consideração diferente da sua, mas a respeito e gostaria de expor a minha: O RAID 1 realmente é mais indicado por questões de contingência e redundância dos dados, mas RAID 5 é por outro lado uma questão de maior segurança no que diz respeito a possível perdas, realmente ele apresenta uma taxa da leitura interessante, já as taxas de gravação não são das melhores, mas temos uma maior segurança, então para este tipo de cenário, quando trabalhamos com arquivos de dados o RAID 5 pode ser bem útil e somente para arquivos de Log o RAID 1 pode ser uma melhor solução.

    O RAID 10 poderia ser realmente uma opções interessante para se trabalhar somente com bancos de dados com baixa taxa de manipulação, por exemplo, bancos de dados de histórico pode ser algo mais indicado.

    Este link pode ser uma boa resposta para nossas argumentações: https://technet.microsoft.com/pt-br/library/ms190764(v=sql.105).aspx


    Pedro Antonio Galvao Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]



    sexta-feira, 29 de dezembro de 2017 19:22
    Moderador
  • Olá Junior,

    Perfeito, aliás agradeço muito o seu Post!! Vejo que esta é a real finalidade desta comunidade, o compartilhamento de conhecimento. Aqui tenho a oportunidade de compartilhar o pouco conhecimento que tenho, e também tenho a excelente oportunidade de apreender ainda mais com os Mestres que fazem parte desta Comunidade.

    Achei muito interessante o seu Post, pois eu havia pensado apenas em Bases de Dados que possuem uma alta taxa de manipulação, conforme mencionado pelo Mestre. De fato não havia me atentado as Bases que possuem mais Leitura do que Escrita.

    Muito obrigado pelo enriquecimento deste Post!!

    A disposição,

    Marcos Roberto de Lima
    MCT-MCTS-MCITP-MCP

    Por favor, lembre-se de Marcar como Resposta as postagens que resolveram o seu problema. Essa é uma maneira comum de reconhecer aqueles que o ajudaram e fazer com que seja mais fácil para os outros visitantes encontrarem a resolução mais tarde.

    terça-feira, 2 de janeiro de 2018 12:52
  • Olá Junior,

    Perfeito, aliás agradeço muito o seu Post!! Vejo que esta é a real finalidade desta comunidade, o compartilhamento de conhecimento. Aqui tenho a oportunidade de compartilhar o pouco conhecimento que tenho, e também tenho a excelente oportunidade de apreender ainda mais com os Mestres que fazem parte desta Comunidade.

    Achei muito interessante o seu Post, pois eu havia pensado apenas em Bases de Dados que possuem uma alta taxa de manipulação, conforme mencionado pelo Mestre. De fato não havia me atentado as Bases que possuem mais Leitura do que Escrita.

    Muito obrigado pelo enriquecimento deste Post!!

    A disposição,

    Marcos Roberto de Lima
    MCT-MCTS-MCITP-MCP

    Por favor, lembre-se de Marcar como Resposta as postagens que resolveram o seu problema. Essa é uma maneira comum de reconhecer aqueles que o ajudaram e fazer com que seja mais fácil para os outros visitantes encontrarem a resolução mais tarde.

    Marcos,

    Obrigado, estou aqui justamente para isso para aprender e compartilhar.


    Pedro Antonio Galvao Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    sábado, 6 de janeiro de 2018 20:38
    Moderador