existe um GOTCHA - DBCC CHECKDB ('DBNAME', NOINDEX)?

1

Estou ativando o DBCC CHECKDB em nosso ambiente OLTP (SQL 2005,2008). A sobrecarga do sistema é uma coisa muito visível em nossos servidores, portanto, quero que eles sejam tão eficientes quanto faz sentido para eles. HENCE - Eu quero ativar a opção NOINDEX, uma opção que nunca usei antes. Meus pensamentos são estes: se houver um problema com um índice que é detectado fora da verificação de integridade, posso apenas reconstruir o índice. Além disso, a duração das verificações de integridade será drasticamente reduzida, e a corrupção mais desagradável será detectada.

Qual é a falha no meu plano?

Obrigado Deb

    
por Deb Anderson 19.11.2010 / 18:28

2 respostas

1

O DBCC CHECKDB precisa ser feito fora do horário ou em períodos de baixo uso. Em um banco de dados enorme, ele irá (de propósito) martelar o subsistema de disco do servidor tão mal que ele se torna quase inutilizável. Precisa ler todas as páginas do banco de dados. Usando a opção NOINDEX não ajuda muito, porque você precisa verificar se nenhum dos índices (re-buildable) está corrompido. Se um desses fosse corrompido, os erros poderiam ser retornados para seus aplicativos ou dentro de procedimentos / transações. Se todos esses erros não forem tratados adequadamente pelo código ou pelos procedimentos do aplicativo (ou seja, reverter as transações aninhadas corretamente), você poderá acabar com a corrupção de dados lógica (como um débito sem crédito um sistema de contabilidade).

Fazemos CHECKDBs semanais de todos os bancos de dados nas primeiras horas da manhã de domingo, já que o uso é muito baixo. Para nossas maiores e mais intensas operações 24x7, executamos DBCC CHECKTABLEs em vez de um WAITFOR entre tabelas para minimizar o impacto do usuário final. Se você seguir esse caminho, também precisará executar o DBCC CHECKALLOC e o DBCC CHECKCATALOG no banco de dados periodicamente (eles estão incluídos em um CHECKDB completo).

Por fim, se você estiver enfrentando algum tipo de corrupção em um banco de dados do SQL Server, precisará examinar imediatamente sua pilha de hardware de armazenamento. Nós não vimos corrupção de DB de qualquer tipo desde o SQL 6.5 nos anos 90 em nossa loja, e temos dezenas de servidores SQL de alto volume. A única vez que vi corrupção de banco de dados no SQL 7 e posterior foi por causa de um controlador RAID com defeito em um site do cliente (Promise realmente é uma droga).

    
por 19.11.2010 / 18:53
0

Não há nenhuma falha, mas você está correndo o risco de que uma falha de integridade em um índice não agrupado possa afetar um usuário ou aplicativo final, você não perderá nenhum dado, mas pode haver impacto enquanto você reconstrói o índice.

Se o desempenho for uma grande preocupação, execute backups completos diariamente, restaure em um servidor diferente e execute a verificação em relação à cópia.

    
por 19.11.2010 / 18:53