locked
DBCC CHECKDB RRS feed

  • Pergunta

  • Tenho ums servidor SQL Server 2005 instalado em um RAID. Este servidor tem um banco de dados com uma tabela com mais de dois bilhões de registros. Quando tenho fazer um DBCC no banco de dados, ou preciso acessar os dados desta tabela de alguma forma, o servidor trava.

    Estava pensando em criar um filegroup com alguns arquivos distribuídos nas partições e mover a tabela do filegroup primario para este novo. Pergunto, será que isso resolveria o meu problema? Só complementando as informações, este servidor tem uns 8gb de memória e um processador excelente.

     


    Fábio
    quinta-feira, 14 de outubro de 2010 12:04

Respostas

  • Boa Tarde,

    Comandos como CHECKDB, CHECKTABLE e UPDATE_STATISTICS podem levar a SCANs de uma tabela. Considerando que você tem uma tabela de 2 bilhões de registros e 8GB de memória, pode ser que sua memória não seja suficiente. Uma tabela com uma linha de 4 bytes e dois bilhões de registros já consumiria seus 8GB com facilidade. Considerando que uma tabela jamais terá uma linha de 4 bytes e que os 8GB não estão disponíveis somente para o CHECKDB, acredito que esse seja o limitador. Mesmo que um SCAN não seja necessário, acho que é uma proporção um tanto desigual.

    Utilizar o particionamento com filegroups pode ajudar em tarefas de manutenção como o REINDEX (e a atualização de estatísticas em alguns casos), mas a memória ainda parece restrita.

    [ ]s,

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

    Utilizando Common Table Expressions (CTEs) para estruturação de MENUs – Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1145.entry

    Utilizando Common Table Expressions (CTEs) para estruturação de MENUs – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1148.entry


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 14 de outubro de 2010 20:35

Todas as Respostas

  • Fábio,

    A principio aconselho fazer uma verificação da estrutura do seu banco de dados, pois este tipo de travamento não é normal!!!

    Fazendo um simples select com base em uma parte dos seus dados, você recebe alguma mensagem de erro?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    quinta-feira, 14 de outubro de 2010 18:36
    Moderador
  • Boa tarde Júnior!

    O Windows não informa nenhum erro nos logs. Consigo fazer um select top e não dá nenhuma mensagem de erro, porém, quando realizo do DBCC ou update statistics ele trava.

    Vou colocar o Sql Profile para rodar no server para tentar encontrar alguma coisa. Não sei, acredito que este banco esteja corrompido ou alguma coisa do tipo.

    O que acha?


    Fábio
    quinta-feira, 14 de outubro de 2010 19:03
  • Fábio,

    O Profiler pode ajudar, mas tente utilizart o DBCC CheckTable sobre as tables que você mais utiliza.

    Outra coisa, seria interessante realizar um backup deste banco de dados, e restaurá-lo sobre outro filegroup em outra unidade.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    quinta-feira, 14 de outubro de 2010 19:33
    Moderador
  • Boa Tarde,

    Comandos como CHECKDB, CHECKTABLE e UPDATE_STATISTICS podem levar a SCANs de uma tabela. Considerando que você tem uma tabela de 2 bilhões de registros e 8GB de memória, pode ser que sua memória não seja suficiente. Uma tabela com uma linha de 4 bytes e dois bilhões de registros já consumiria seus 8GB com facilidade. Considerando que uma tabela jamais terá uma linha de 4 bytes e que os 8GB não estão disponíveis somente para o CHECKDB, acredito que esse seja o limitador. Mesmo que um SCAN não seja necessário, acho que é uma proporção um tanto desigual.

    Utilizar o particionamento com filegroups pode ajudar em tarefas de manutenção como o REINDEX (e a atualização de estatísticas em alguns casos), mas a memória ainda parece restrita.

    [ ]s,

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

    Utilizando Common Table Expressions (CTEs) para estruturação de MENUs – Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1145.entry

    Utilizando Common Table Expressions (CTEs) para estruturação de MENUs – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1148.entry


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 14 de outubro de 2010 20:35
  • Maia,

    Realmente com este volume pode estar ocorrendo sim possíveis fragmentações de dados que estão se tornando gargalo na execução dos DBCCs.

    Isso eu não tinha pensado, os possíveis scans que possam ocorrer durante a execução dos DBCCs pensei mais para o lado do Select.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    quinta-feira, 14 de outubro de 2010 23:12
    Moderador
  • Post antigo, por isso o mesmo foi encerrado.

    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 13:03
    Moderador