Em nosso laboratório de teste, tenho experimentado diferentes trabalhos para evitar que nossos índices críticos fiquem muito fragmentados.
No momento, estou usando a abordagem descrita aqui: sys.dm_db_index_physical_stats (na seção Exemplos -> D: Usando sys.dm_db_index_physical_stats em um script para reconstruir ou reorganizar índices).
Basicamente, a cada hora eu consulto a dm_db_index_physical_statsvisão de gerenciamento dinâmico e se um índice estiver entre 5% e 30% fragmentado eu o reorganizo, se for maior que 30% fragmentado eu o reconstruo. Parece funcionar bem durante a maior parte de nossos testes, no entanto, duas vezes me deparei com um problema em que o trabalho agendado falha com um erro:
O sistema operacional retornou o erro 23 (erro de dados (verificação de redundância cíclica).) para o SQL Server durante uma leitura no deslocamento 0x00000eae3b2000 no arquivo 'C:\Arquivos de Programas\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\database.mdf' .
Mensagens adicionais no log de erros do SQL Server e no log de eventos do sistema podem fornecer mais detalhes.
Esta é uma condição de erro grave no nível do sistema que ameaça a integridade do banco de dados e deve ser corrigida imediatamente.
Conclua uma verificação completa de consistência do banco de dados (DBCC CHECKDB). Esse erro pode ser causado por vários fatores; para obter mais informações, consulte os manuais online do SQL Server. [SQLSTATE HY000] (Erro 823)
Quando executo DBCC CHECKDBum problema é relatado em um dos meus índices, a única maneira de corrigir esse problema é usando
DBCC CHECKDB ('dbname', REPAIR_ALLOW_DATA_LOSS)
Não tenho certeza, mas suspeito que esse erro seja causado pela reconstrução ou reorganização de índices enquanto meus testes de carga estão sendo executados no laboratório de teste.
Pesquisei e não encontrei mais ninguém relatando esse erro de consistência relacionado à reconstrução de índices. Você pode ver mais informações sobre o meu problema na postagem do meu blog: SQL Server Index Corruption: CRC Error & DBCC CHECKDB
Minha abordagem para ajustar índices é falha? Eu não deveria estar tentando reconstruir índices em um banco de dados "ao vivo" (enquanto o tráfego está atingindo-o)? Devo usar o recurso do SQL Server Enterprise Edition de recriar um índice com (online=on)? Qualquer ajuda é apreciada.
Estou executando o SQL Server 2008 R2 Standard.
Isso indica que o sistema operacional detectou um problema ao ler os dados do próprio disco rígido. Quando os dados são gravados no sistema de arquivos, o sistema operacional calcula um código CRC para cada bloco gravado; quando esses dados são posteriormente lidos, o sistema operacional executa a operação CRC novamente nos dados lidos e os compara com o CRC armazenado no sistema de arquivos. Se esses dois códigos CRC não corresponderem ao sistema operacional, relata o erro 23. Ficaria muito surpreso se não houvesse um problema de hardware com a própria unidade ou talvez com algum outro componente, como a placa-mãe ou o controlador da unidade.
WITH (ONLINE=ON)no Enterprise Edition do SQL Server não terá nenhum efeito sobre esse problema. Operações de índice online versus operações de índice offline não são diferentes na camada do sistema operacional; os dados são lidos e gravados conforme necessário para reconstruir ou recriar o índice.Bem, é bom restaurar a partir do backup válido mais recente. Certifique-se de verificar a consistência do backup usando a verificação de restauração antes de aplicar.