@Os_run_priority em sp_add_jobstep realmente funciona no SQL Server 2008 R2?

13

Será que @os_run_priorityem sp_add_jobsteprealmente trabalho, no SQL Server 2008 R2?

É descrito como "reservado" ou "não documentado". No entanto, eu vejo isso na sp_add_jobstepdefinição:

@os_run_priority INT = 0, -- -15 = Idle, -1 = Below Normal, 0 = Normal, 1 = Above Normal, 15 = Time Critical)

sql-server sql-server-2008-r2 jobs

— benik9
fonte

Eu suspeitaria que isso está apenas relatando a @os_run_priority que foi usada, em vez de lhe dar uma chance de influenciar a prioridade. Nesse caso, o texto está apenas ajudando você a descobrir qual prioridade foi usada.

— RLF

11

Isso faz parte da definição da etapa do trabalho e você pode até ver que possui valores usados ou definidos em outras áreas.

Depois de examinar o código-fonte (trabalho na Microsoft e tenho acesso), enquanto o valor é realmente passado como parte das informações da etapa do trabalho enviadas a cada subsistema, não consegui encontrar um local que realmente definisse o valor como parte da execução da etapa do trabalho. No entanto, existem threads executados em diferentes níveis de prioridade como parte do SQL Server Agent e esses threads podem ou não ajudar na funcionalidade da etapa da tarefa ou nos subsistemas que preenchem uma função específica.

Embora eu não tenha feito uma verificação exaustiva, seria melhor assumir que esse valor é - como descrito - "reservado". Só porque não parece ser usado, não significa que não possa ser em nenhum outro momento, pois o encanamento existe.

— Sean diz remover Sara Chipps
fonte

4

Embora esse valor seja salvo como parte da etapa do trabalho, não encontro nenhuma evidência de que o valor seja usado.

Se eu definir o valor adicionando o parâmetro , @os_run_priority = Xa EXEC msdb.dbo.sp_update_jobstep, ele será exibido corretamente na os_run_prioritycoluna de msdb.dbo.sysjobsteps.

Criei um trabalho com 2 etapas: uma etapa T-SQL e uma etapa do sistema operacional (CmdExec). Suponho que é mais provável que uma opção como "os execute prioridade" afete uma etapa do CmdExec, mas é bom testar as duas.

Cada etapa foi WAITFOR DELAY '00:00:30.000'executada de forma a ficar pendente enquanto eu olhava os processos em execução para ver se a prioridade havia mudado.

Eu verifiquei os processos usando o Process Explorer . Tanto quanto eu posso dizer, os valores (e eu tentei 1, 15e -1) não têm nenhum efeito. Tentei usar o SQL Server 2012 e 2016 no Windows 10.

Eu também tentei no SQL Server 2008 R2 em execução no Windows XP. Mais uma vez, não vi nenhuma indicação dessa propriedade afetando o processo SQLAGENT ou o SQLCMD (que eu estava usando na etapa CmdExec para ligar novamente para o SQL Server WAITFOR DELAY).

Obviamente, deve-se notar que o próprio processo precisa de certas permissões para alterar o nível de prioridade de um encadeamento. Quando o agente do SQL Server está sendo executado como a conta Sistema Local, ele pode não ter esses direitos. No entanto, eu testei (apenas SQL Server 2016) usando meu próprio logon do Windows como a conta de serviço do agente do SQL Server e não vi nenhuma indicação dessa propriedade sendo usada.

— Solomon Rutzky
fonte

1

É passado na estrutura do trabalho para cada subsistema e cada subsistema é responsável por escolher o que faz com isso. Não consegui encontrar um subsistema que implementasse esse código em 2008R2 com patches de terminal.

— Sean diz remover Sara Chipps 26/12/16

@SeanGallardy Tom atualizou sua resposta com a peça que faltava que esclarece todas as preocupações :-). Eu não sabia que você tinha acesso à fonte, e muitas vezes as pessoas afirmam as coisas com muita confiança / ênfase, como se houvesse conhecimento direto e observado e, no entanto, é apenas um palpite. Promovi sua resposta, mas manterá minha resposta, pois fornece algumas informações adicionais sobre prioridades e sobre como investigar problemas semelhantes.

— Solomon Rutzky