하는가 @os_run_priority에 sp_add_jobstepSQL 서버 2008 R2에서 실제로 사용할 수 있습니까?
"예약 됨"또는 "언급되지 않음"으로 설명됩니다. 그러나 나는 그것을 sp_add_jobstep정의 에서 본다 :
@os_run_priority INT = 0, -- -15 = Idle, -1 = Below Normal, 0 = Normal, 1 = Above Normal, 15 = Time Critical)답변:
이것은 작업 단계 정의의 일부이며 다른 영역에서 사용되거나 정의 된 값이있을 수도 있습니다.
소스 코드를 살펴본 후 (Microsoft에서 근무하고 액세스 권한이 있음) 값이 실제로 각 하위 시스템으로 전송되는 작업 단계 정보의 일부로 전달되는 동안 실제로 값을 부분으로 설정하는 위치를 찾을 수 없습니다 작업 단계 실행 그러나 SQL Server 에이전트의 일부로 다른 우선 순위 수준에서 실행되는 스레드가 있으며 해당 스레드는 특정 역할을 수행하는 작업 단계 기능 또는 하위 시스템을 지원하거나 지원하지 않을 수 있습니다.
철저한 검사를하지는 않았지만이 값이 "예약 됨"이라고 가정하는 것이 가장 안전합니다. 그것이 사용되지 않는 것만으로 배관이 존재하기 때문에 다른 지점에있을 수 없다는 것을 의미하지는 않습니다.
이 값은 작업 단계의 일부로 저장되지만 해당 값이 사용되었다는 증거는 없습니다.
에 매개 변수 , @os_run_priority = X를 추가하여 값을 설정하면 EXEC msdb.dbo.sp_update_jobstep의 os_run_priority열에 올바르게 표시됩니다msdb.dbo.sysjobsteps .
T-SQL 단계와 운영 체제 (CmdExec) 단계의 두 단계로 작업을 만들었습니다. "os run priority"와 같은 옵션이 CmdExec 단계에 영향을 줄 가능성이 높지만 두 가지를 모두 테스트하는 것이 좋습니다.
각 단계는 WAITFOR DELAY '00:00:30.000' 우선 순위가 변경되었는지 확인하기 위해 실행중인 프로세스를 보면서 중단되도록했습니다.
Process Explorer를 사용하여 프로세스를 확인했습니다 . 지금까지 내가 말할 수있는 값은 내가 노력 ( 1, 15, 및-1 ) 영향을주지 않습니다. Windows 10에서 SQL Server 2012와 2016을 모두 사용해 보았습니다.
Windows XP에서 실행되는 SQL Server 2008 R2에서도 시도했습니다. 이 속성이 SQLAGENT 프로세스 또는 SQLCMD 프로세스 (CmdExec 단계에서 SQL Server로 다시 호출하여을 수행하는 데 영향을 미침)에 아무런 영향을 미치지 않음을 다시 알지 못했습니다 WAITFOR DELAY.
물론, 프로세스 자체는 스레드의 우선 순위 레벨을 변경하기 위해 특정 권한을 필요로합니다. SQL Server 에이전트가 로컬 시스템 계정으로 실행중인 경우 그러한 권한이 없을 수 있습니다. 그러나 SQL Server 에이전트의 서비스 계정으로 자체 Windows 로그인을 사용하여 테스트 (SQL Server 2016 만 해당)했지만이 속성이 사용되고 있다는 표시는 없었습니다.