Estou sendo desafiado, pois temos clientes que estão vendo diferentes tipos de erros ao executar o que deveria ser manutenção online. erros como tempos limite, verificação interrompida devido à movimentação de dados e muito mais.
Alguns de nossos clientes compraram o SQL Server Enterprise Edition para obter o recurso online de índice de reconstrução.
Para replicar os problemas, tenho testado em um grande banco de dados o dbcc checkdb, reorganização e reconstrução de índices e atualização de estatísticas enquanto bombardeio o servidor com transações em um banco de dados que tem quase 1TB.
Meu primeiro teste foi com o checkdb com maxdop=1 enquanto o sqlServer estava processando 124000 pequenas transações... Recebi um timeout da minha aplicação que tem um timeout definido para 5 minutos. Pesquise sobre como o check db funciona, é que ele cria um snapshot, usa tempdb intensivamente e nolocks são criados para criar o snapshot... Então, como uma das minhas pequenas transações pode ser bloqueada se não bloquear tabelas?
Meu segundo teste foi reorganizar todos os índices (que também deveria estar online) enquanto processava 124.000 transações, dessa vez consegui um impasse...
Meu terceiro teste foi atualizar todas as estatísticas com maxdop=1 enquanto executava 124.000 transações. O erro recebido neste caso é: Não foi possível continuar a varredura sem bloqueio devido à movimentação de dados
meu quarto teste para reconstruir todos os índices online durante a execução de 124.000 transações será executado em breve e atualizarei meu post com os resultados.
O maxdop=1 que usei onde pode ser usado foi para eliminar a contenção de recursos.
Eu li vários artigos, incluindo a explicação de Paul Randal sobre online vs offline da reconstrução de índices e entendo a diferença ... .
Qualquer entrada seria muito apreciada.
O que estou perdendo
Muitas perguntas aqui. Tenho a sensação de que as respostas não vão fazer você feliz, no entanto.
DBCC CheckDB
Não sei se confundi
DBCC CHECKDBcom "manutenção online", mas certamente não é uma atividade offline por natureza. Dito isto, ainda pode consumir muitos recursos, o que pode se manifestar como um aplicativo "não funcionando", embora o banco de dados ainda esteja tecnicamente online e disponível.Isso não indica nenhum bloqueio, especialmente porque
DBCC CHECKDBnão causa bloqueio , a menos que você especifique. Você deve dar uma olhada no monitoramento das consultas para ver qual pode ser a causa do tempo limite - pode ser muitas coisas honestamente.Builds de índice on-line
O impasse foi com a instrução de reorganização do índice ou outra instrução de aplicativo? Não consigo me lembrar de uma reorganização que tenha causado esse problema para mim, mas os impasses são um fato da vida e o aplicativo deve ser capaz de tentar novamente quando os encontrar. A operação online não garante de forma alguma que você não terá impasses.
A maioria das pessoas agenda a manutenção do índice durante a noite/fins de semana para ajudar a evitar problemas relacionados ao bloqueio, bloqueio e contenção de recursos. Testar em uma carga de trabalho normal do horário comercial certamente causará problemas como você está vendo.
Atualizar estatísticas
Este é você (ou melhor, o aplicativo): não use
NOLOCKe você não receberáNOLOCKerros relacionados. Novamente, não tenho certeza se eu recomendaria atualizar todas as estatísticas em um sistema ocupado durante alto volume, então isso parece um teste destinado a ter problemas também.Definições técnicas
Se você leu isso, sabe que on-line não significa que nenhum bloqueio seja feito. A definição da palavra é altamente contextual. Você pode apontar quem precisar para a documentação sobre reconstruções online :
Conclusão
Tudo isso para dizer que, independentemente das operações de manutenção poderem ser "online", a maioria das pessoas não as testa durante cargas de trabalho completas nem espera que funcionem bem durante o volume transacional normal.
Na maioria das vezes, você realmente não precisará reconstruir/reorganizar todos os índices ou atualizar todas as estatísticas ao mesmo tempo, mesmo durante as janelas de manutenção. Se você tiver um VLDB, divida-o
DBCC CHECKDBem janelas diferentes (como Paul cobriu tão bem).Eu me concentraria mais em como/quando essas coisas realmente funcionarão. Use algo como a solução de manutenção da Ola para não fazer o SQL Server trabalhar mais do que o necessário.
E faça com que seu cliente reduza suas expectativas!
Veja também