하는가 @os_run_priority
에 sp_add_jobstep
SQL 서버 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 만 해당)했지만이 속성이 사용되고 있다는 표시는 없었습니다.