Eu tenho um processo que cerca de uma vez por mês às vezes não relacionado (ou tanto quanto podemos dizer) vai para o SOS_SCHEDULER_YIELDestado. Esse processo bloqueia nosso pipeline principal de entrada de dados e paralisa todo o banco de dados.
Colocamos uma tabela de filas com o service broker na frente deste proc (pois era inicialmente o proc de entrada de dados) e estávamos perdendo dados porque os sistemas à frente ficaram sem espaço em suas filas. Isso nos impediu de perder dados, mas não corrigiu o problema, é simplesmente um curativo.
Existe alguma maneira em um procedimento para dizer que este proc deve receber uma prioridade mais alta na CPU ou deve estar no final da lista para tirar o tempo da CPU, demorou 7 minutos para o processador voltar a terminar o tarefa hoje (foi 12 minutos antes, parece ser a carga mais alta sob a qual estamos mais demorados, pois há mais dados chegando, então há mais processos lutando pelo tempo da CPU)
É impossível fazer isso no procedimento. Esse tipo de espera é uma função do agendador. Cada SPID obtém uma quantidade finita de tempo (4 ms) no processador. Uma vez decorrido esse tempo, ou quantum, o SPID é colocado de volta na lista de espera até que os recursos estejam disponíveis novamente. Esse tipo de espera indica que o SPID não conseguiu concluir seu trabalho na CPU no quantum e teve que "ceder" a outro processo em espera.
Isso não pode ser alterado com nenhum código SQL. Você pode especificar que os recursos sejam priorizados para sua carga com o Resource Governor, conforme sugerido por Paul White. Mesmo assim, a menos que, como sugeriu Kin, você esteja enfrentando muita pressão da CPU, o Resource Governor também não ajudará.
Verifique as operações intensivas da CPU e minimize onde puder. Uma que incomoda muita gente é a Conversão Implícita, que será descoberta rapidamente ao escanear o plano de execução.
Primeiro verifique se
Agora, se for o único tipo de espera que está causando problemas,
Sempre teste e certifique-se de que você está no último Service Pack e CU