locked
Problema com reindex de tabela RRS feed

  • Pergunta

  • Bom dia pessoal,

    Em meu ambiente, tenho uma tabela com 58Gb e mais 46Gb de índices, ou seja, mais de 100Gb só nesta tabela.
    Ela conta com 3 índices, sendo um deles clustered e com campo identity nele.
    Nesta tabela, existem mais de 500 milhões de registros e devido a regra de negócio da empresa, eu posso limpá-la apenas de tempos em tempos, transferindo para uma base histórica, alguns dos registros mais antigos.
    A versão do meu SQL é 2005 Standard x64 SP3.
    Agora vem o problema. Durante o feriado, fiz a transferência dos registros para a base histórica e procedi com a deleção dos registros já migrados, e obviamente os índices ficaram bastante fragmentados, então pensei em fazer um reindex, acontece que depois de um tempo executando, notei que a database estava crescendo demais, não só o log, mas também o datafile, chegando a um ponto de quase consumir todo o espaço disponível no disco, ou seja, pelo fato de rodar o DBCC DBREINDEX(nome_tabela), minha base cresceu mais do dobro do tamanho da tabela em questão, juntamente com os índices.
    Podem me ajudar ou dar idéias do que pode ter acontecido?

    Grande abraço,
    segunda-feira, 4 de janeiro de 2010 15:11

Respostas

  • Boa Noite,

    Me parece que a edição do SQL Server está inadequada ao seu ambiente. Se você está mexendo com volumes que não possuem janelas para a reindexação, o ideal seria optar pela edição Enterprise que possui recursos de reindexação online e não provocará indisponibilidade. O uso do particionamento também auxiliaria para evitar ter de reindexar dados históricos apenas porque a tabela precisa ser reindexada.

    O uso do Recovery Model Bulk pode ser uma tremenda "armadilha" se não for bem avaliado. Ele até pode reduzir a quantidade de log envolvida em algumas operações, mas no momento de efetuar o backup de log, os logs backupeados ficarão muito maiores do que no recovery model full.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte III
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!899.entry


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 5 de janeiro de 2010 00:34

Todas as Respostas

  • Boa tarde Diego

    A primeira providencia seria você alterar o recovery model do database para Bulk-Logged. Acho que isso vai ser o suficiente para resolver a questão do espaço.




    Espero ter ajudado


    Anderson - DBA/MCP/MCTS/MCITP/MCT - Sua pergunta foi respondida ? Marque-a como tal! www.myspace.com/andersondpa
    segunda-feira, 4 de janeiro de 2010 15:15
  • Oi Anderson,

    Obrigado por responder.
    Infelizmente o recovery model já estava com Bulk-logged, apenas esqueci de comentar.
    O estranho é que o mdf começou a crescer junto...não só o log...e verifiquei e o TempDB também estava normal.
    segunda-feira, 4 de janeiro de 2010 15:18
  • Se o seu problema é fragmentação, experimenta utilizar o DBCC IndexDefrag e analisa o resultado



    Espero ter ajudado


    Anderson - DBA/MCP/MCTS/MCITP/MCT - Sua pergunta foi respondida ? Marque-a como tal! www.myspace.com/andersondpa
    segunda-feira, 4 de janeiro de 2010 15:39
  • Boa tarde Diego,


    Bem, se o recovery model já está no modo mencionado pelo Anderson, creio que seja interessante você reindexar um índice por vez.

    Outra coisa, caso o tempdb esteja em disco diferente, você pode utilizar o hint como abaixo, diminuindo a utilização do espaço de onde a base está.

    ALTER  INDEX   INDEX_NAME   ON  dbo . TABLE   REBUILD  WITH  ( SORT_IN_TEMPDB  =  ON )

    Abraços.
    ANDRÉ ROCHA
    segunda-feira, 4 de janeiro de 2010 15:42
  • Muito bem lembrado pelo André, o correto é alterar o DBCC REINDEX para o Alter Index. Por algum motivo respondi sua questão pensando que estivesse no modo de compatibilidade 80 (rs)



    Abraços
    Anderson - DBA/MCP/MCTS/MCITP/MCT - Sua pergunta foi respondida ? Marque-a como tal! www.myspace.com/andersondpa
    segunda-feira, 4 de janeiro de 2010 15:45
  • Anderson e André,

    Obrigado, vou fazer uns testes assim que obtiver uma janela...mas creio que o problema vai continuar acontecendo.

    Quanto a utilizar o Sort_in_TempDb, creio que não seja aconselhável no meu caso...pois mesmo o TempDB estando em uma unidade de disco separada e mais rápida, já tenho ativo o nível de isolamento read_commited_snapshot, o que já aumenta o I/O, então não quero onerar mais ainda este disco. Mas valeu as dicas!

    Abraços!
    segunda-feira, 4 de janeiro de 2010 16:37
  • Olá Diego,

    Quer dizer que o sistema que utiliza essa base opera 24x7 e as manutenções serão online? é por isto não quer "onerar" o tempdb?

    Lembre que (espaço em disco) x (manutenção) em bases grandes, é uma relação na qual você não poderá esperar que precise menos que o dobro espaço em disco para realizar suas operações tranquilamente, de forma que nem sempre este "problema" citado será realmente um problema a se resolver, e sim algo que devemos aprender a conviver e tentar alguma melhora na medida do possível.

    Espero sucesso nos seus testes, caso encontre alguma solução viável para não acontecer o que foi descrito no tópico, por favor compartilhar conosco.

    Abraços.

    ANDRÉ ROCHA
    segunda-feira, 4 de janeiro de 2010 17:20
  • Oi André,

    Realmente, o negócio aqui é complicado. O espaço em disco sempre é pouco e as janelas de manutenção são sempre online em final de semana, quando a produção cai drasticamente, pois durante a semana, nem pensar...os gerentes de infra e de sistemas não liberam "brechas" para manutenção.

    Gostaria muito de poder contar com bastante espaço em disco, ter janelas com parada programada e tal, mas infelizmente tenho que me virar com o que me disponibilizam (e no meu caso, sendo terceirizado, é mais difícil ainda)...é o caso clássico de "faça mais com menos", hehehehe.

    Mas obrigado pela ajuda, com certeza volto para postar os resultados.

    Grande abraço,
    segunda-feira, 4 de janeiro de 2010 17:42
  • Boa Noite,

    Me parece que a edição do SQL Server está inadequada ao seu ambiente. Se você está mexendo com volumes que não possuem janelas para a reindexação, o ideal seria optar pela edição Enterprise que possui recursos de reindexação online e não provocará indisponibilidade. O uso do particionamento também auxiliaria para evitar ter de reindexar dados históricos apenas porque a tabela precisa ser reindexada.

    O uso do Recovery Model Bulk pode ser uma tremenda "armadilha" se não for bem avaliado. Ele até pode reduzir a quantidade de log envolvida em algumas operações, mas no momento de efetuar o backup de log, os logs backupeados ficarão muito maiores do que no recovery model full.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte III
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!899.entry


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 5 de janeiro de 2010 00:34
  • Concordo Plenamento com o Gustavo. 
    Se a falta de espaço é um problema, eu optaria por rebuild nos indices  desabilitando os indices não cluster  em transações separadas . Quando você não desabilita o inidce nao cluster,  o rebuild precisa ter espaço para o indice antigo e o novo. O que não acontece se você desabilitá-los.or



    Aqui explica melhor

    http://msdn.microsoft.com/en-us/library/ms177406.aspx

    www.laertejuniordba.spaces.live.com www.simple-talk.com/author/laerte-junior/
    terça-feira, 5 de janeiro de 2010 02:19
  • Gustavo,

    Sei que para o ambiente que tenho, a versão standard não comporta mais, acontece que como disse acima, aqui a metodologia é "faça mais com menos", e o pessoal da gerencia não consegue compreender a real necessidade de fazer um upgrade para a versão Enterprise. Estou tantando fazer de tudo para provar que teremos ganhos com este upgrade, mas está difícil. Inclusive teremos uma reunião com o pessoal da Microsoft nos próximos dias, onde eles irão expor as vantagens de da versão Enterprise. Estou torcendo para que dê certo.

    Laerte,

    Obrigado pelas dicas vou testar.

    A todos que postaram e deram idéias, agradeço a todos. Obrigado.

    Abraço,
    terça-feira, 5 de janeiro de 2010 13:09
  • Olá Diego,

    Tomára que você consiga convencer da necessidade. Se for realmente ficar com a Standart pesquise sobre o recurso de Views Particionadas. Elas "emulam" um particionamento que poderá facilitar a reindexação e por consequência o tamanho dos logs e as janelas.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte III
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!899.entry


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 5 de janeiro de 2010 15:30
  • Gustavo,

    Obrigado.



    Abraço!
    terça-feira, 5 de janeiro de 2010 16:15
  • Este post foi encerrado por ser considerado um post antigo.

    Pedro Antonio Galvão 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]

    terça-feira, 5 de junho de 2018 18:08
    Moderador