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).