¿Funciona @os_run_priority en sp_add_jobstep realmente en SQL Server 2008 R2?

13

Lo hace @os_run_priorityen sp_add_jobsteprealidad el trabajo, en SQL Server 2008 R2?

Se describe como "reservado" o "no documentado". Sin embargo, lo veo en la sp_add_jobstepdefinición:

@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
fuente

Sospecho que esto es solo informar la @os_run_priority que se usó, en lugar de darle la oportunidad de influir en la prioridad. Si es así, el texto solo lo ayuda a descubrir qué prioridad se utilizó.

— RLF

11

Esto es parte de la definición del paso del trabajo e incluso puede ver que tiene valores utilizados o definidos en otras áreas.

Después de echar un vistazo al código fuente (trabajo en Microsoft y tengo acceso), aunque el valor se pasa como parte de la información del paso del trabajo enviada a cada subsistema, no pude encontrar un lugar que realmente establezca el valor como parte de la ejecución del paso de trabajo. Sin embargo, hay subprocesos que se ejecutan en diferentes niveles de prioridad como parte del Agente SQL Server y esos subprocesos pueden o no ayudar con la funcionalidad de paso de trabajo o subsistemas que cumplen un rol específico.

Si bien no hice una verificación exhaustiva, sería mejor asumir que este valor es, como se describe, "reservado". El hecho de que no parezca ser usado no significa que no pueda ser en ningún otro punto ya que la tubería existe.

— Sean Gallardy
fuente

4

Si bien este valor se guarda como parte del paso del trabajo, no puedo encontrar evidencia de que se use el valor.

Si configuro el valor agregando el parámetro , @os_run_priority = Xa EXEC msdb.dbo.sp_update_jobstep, entonces se muestra correctamente en la os_run_prioritycolumna de msdb.dbo.sysjobsteps.

Creé un trabajo con 2 pasos: un paso T-SQL y un paso del sistema operativo (CmdExec). Supongo que es más probable que una opción como "prioridad de ejecución del sistema operativo" afecte un paso CmdExec, pero es bueno probar ambos.

Cada paso hizo un paso WAITFOR DELAY '00:00:30.000'para que permaneciera mientras miraba los procesos en ejecución para ver si la prioridad había cambiado.

Verifiqué los procesos usando Process Explorer . Por lo que yo puedo decir, los valores (y he intentado 1, 15y -1) no tienen ningún efecto. Intenté usar SQL Server 2012 y 2016 en Windows 10.

También probé en SQL Server 2008 R2 que se ejecuta en Windows XP. Nuevamente, no vi ninguna indicación de que esta propiedad tuviera algún efecto en el proceso SQLAGENT o el proceso SQLCMD (que estaba usando en el paso CmdExec para volver a llamar a SQL Server para hacer WAITFOR DELAY).

Por supuesto, debe tenerse en cuenta que el proceso en sí mismo necesita ciertos permisos para cambiar el nivel de prioridad de un hilo. Cuando el agente de SQL Server se ejecuta como la cuenta del sistema local, es posible que no tenga dichos derechos. Sin embargo, probé (solo SQL Server 2016) usando mi propio inicio de sesión de Windows como la cuenta de servicio para el agente de SQL Server, y no vi ninguna indicación de que esta propiedad fuera utilizada.

— Solomon Rutzky
fuente

1

Se pasa en la estructura de trabajo a cada subsistema y cada subsistema es responsable de elegir qué hace con esto. No pude encontrar un subsistema que implementara dicho código en 2008R2 con parches de terminal.

— Sean Gallardy

@SeanGallardy Tom actualizó su respuesta con la pieza que falta que aclara cualquier inquietud :-). No sabía que tenías acceso a la fuente, y con frecuencia suficientes personas afirman las cosas con mucha confianza / enfáticamente, como si hubiera conocimiento directo y observado y, sin embargo, es solo una mejor suposición. He votado tu respuesta, pero mantendré mi respuesta, ya que proporciona información adicional sobre las prioridades y sobre cómo investigar problemas similares.

— Solomon Rutzky