SQL Server recriando planos todos os dias

Temos esse problema em nosso ambiente de produção.

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Enterprise Edition (64 bits) no Windows NT 6.1 (Build 7601: Service Pack 1).

O SQL Server está descartando todos (quase 100%) dos planos de execução antigos e recriando-os todos os dias da noite para o dia (das 23:00 às 08:00). Isso aconteceu até quando as 'estatísticas de atualização automática' estavam no estado desativado. Ativamos as 'estatísticas de atualização automática' nas últimas 2-3 semanas. Mas ainda está acontecendo.

Realmente não sabemos o que desencadeia essa re-geração de planos, mas temos certeza de que não o fazemos manualmente.

A única coisa que realmente coincide com o momento em que os planos estão sendo regenerados é um trabalho de manutenção de banco de dados que temos: a reorganização diária do índice (quando a fragmentação é de 5 a 30%) e a reconstrução diária do índice (quando a fragmentação é superior a 30% ) trabalho. Normalmente, esse trabalho de manutenção diária é reorganizado (como a fragmentação do índice nunca é superior a 30% diariamente).

Impacto:

Esses planos recém-criados fazem com que algumas chamadas UDF / chamadas de consulta (chamadas de UI / páginas da web) demorem muito mais (minutos em vez de menos de 1 segundo) e, portanto, as sessões são empilhadas, levando a CPU perto de 90% .

O problema desaparece no momento em que essas sessões bloqueadas são excluídas à força (no lado do banco de dados) e 1) quando todos os planos de execução correspondentes são limpos manualmente (para consultas) ou 2) quando os UDFs são alterados (para funções). Quaisquer novos planos criados pelo SQL Server a partir desse momento funcionam perfeitamente durante todo o dia até que acabem tendo o mesmo problema na manhã seguinte. Além disso, esse comportamento não é 100% consistente, na verdade não o vemos todas as manhãs. Mas houve períodos em que o vimos consistentemente por 4-5 dias seguidos.

O problema acontece nas manhãs de negócios, é quando as páginas da interface do usuário / web são acessadas com mais intensidade, ao que parece.

Alguém tem idéia do que está causando isso e como resolver esse problema? Qualquer ajuda seria muito apreciada.

Bem, eu tenho algumas idéias que podem causar esse comportamento.

1. Você monitora sua pressão de memória? Talvez suas consultas aumentem um certo limite, o que causará a liberação do cache do plano. Não conheço o seu aplicativo, mas isso corresponde aos seus logs dos servidores front-end? Há pressão também durante esse período?
2. Você tem um SQL Server dedicado ou o servidor compartilha seu hardware com outros processos / serviços? Caso contrário, tente terceirizar o SQL Server para uma máquina dedicada. Isso reduzirá os efeitos colaterais de outros serviços.
3. Você pode usar optimize for ad hoc workloads, o que salvará apenas um esboço do plano e o compilará, se necessário. Isso reduzirá a carga do seu plancache, o que diminuirá a chance de um rubor do plancache. Você pode habilitá-lo usando sp_configure 'optimize for ad hoc workloads',1; reconfigure. Isso pode ser feito se você tiver ativado o advanced optionsuso sp_configure 'show advanced options',1; reconfigure.
4. Outra idéia pode ser backups. Apenas backups simples. Se forem agressivos, pode ocorrer que a sua máquina também fique sob pressão. O horário em que você menciona parece um bom período para planejar um backup.
5. Talvez seja um bug muito simples no seu script de manutenção. Você verificou se há um problema lógico que faz com que seu script reconstrua todos os índices em vez de apenas aqueles que correspondem aos critérios. Isso talvez possa causar isso também.

Mesmo ao lado tudo isso possibilidades, pode ser útil para verificar os arquivos de log para algumas alterações nas opções affinity mask, affinity I/O maske seus parceiros x64. Outra coisa pode ser uma alteração da MAXDOPopção da sua instância. Por favor, verifique os logs para eles também. Eles precisarão liberar o plancache também.

Por último, mas não menos importante, você ainda pode executar um rastreamento no servidor (apenas configurando-o usando o criador de perfil, inicie-o, pare-o e use o comando sql para iniciá-lo novamente no servidor). Além disso, perfmoné seu amigo. Ele pode assistir e monitorar seus valores de desempenho por um tempo. Talvez você possa ver paralelos na pressão com certas ações no servidor que podem causar a descarga.

Espero que isso ajude você, mesmo que a resposta venha um pouco mais tarde.