리소스 관리자 개념
다음은 리소스 관리자를 이해하고 사용하기 위한 세 가지 기본 개념입니다.
리소스 풀. SQL Server 2008을 설치하면 두 개의 리소스 풀(내부 및 기본)이 만들어집니다. 또한 리소스 관리자는 사용자 정의 리소스 관리자를 지원합니다.
작업 그룹. SQL Server 2008을 설치하면 두 개의 작업 그룹(내부 및 기본)이 만들어지고 해당 리소스 풀에 매핑됩니다. 또한 리소스 관리자는 사용자 정의 작업 그룹을 지원합니다.
분류. 들어오는 요청을 분류하고 작업 그룹에 라우팅하는 내부 규칙이 있습니다. 또한 리소스 관리자는 분류 규칙을 구현하는 사용자 정의 분류자 함수를 지원합니다.
[!참고]
리소스 관리자는 DAC(관리자 전용 연결)를 제어하지 않습니다. 내부 작업 그룹과 리소스 풀에서 실행되는 DAC 쿼리는 분류할 필요가 없습니다.
리소스 관리자의 컨텍스트에서는 위의 개념이 구성 요소로 간주될 수 있습니다. 다음 그림에서는 이러한 구성 요소와 이러한 구성 요소가 데이터베이스 엔진 환경에 있을 때 서로 어떤 관계가 있는지를 보여 줍니다. 처리 측면에서 이 흐름은 다음과 같이 요약할 수 있습니다.
세션에 대한 들어오는 연결(세션 1/n)이 있습니다.
세션이 분류됩니다(분류).
세션 작업이 작업 그룹(예: 그룹 4)으로 라우팅됩니다.
작업 그룹이 관련 리소스 풀(예: 풀 2)을 사용합니다.
리소스 풀이 응용 프로그램(예: 응용 프로그램 3)에 필요한 리소스를 제공하고 제한합니다.
리소스 풀
리소스 풀 또는 풀은 서버의 물리적 리소스를 나타냅니다. 풀은 SQL Server 인스턴스 내부의 가상 SQL Server 인스턴트로 간주할 수 있습니다.
풀은 두 부분으로 구성되어 있는데, 최소 리소스 예약을 사용하는 한 부분은 다른 풀과 겹치지 않고 가능한 최대 리소스 소비를 지원하는 다른 한 부분은 다른 풀과 공유됩니다. 이 릴리스의 리소스 관리자에서는 풀 리소스가 각 리소스에 대해 다음 중 하나를 지정하여 설정됩니다.
CPU에 대해 MIN 또는 MAX
메모리에 대해 MIN 또는 MAX
MIN과 MAX는 이러한 각 리소스에 대해 각각 풀의 최소 보장 리소스 가용성과 풀의 최대 크기를 나타냅니다.
모든 풀의 MIN 값의 합은 서버 리소스의 100%를 초과할 수 없습니다. MAX 값은 MIN과 100%(포함) 사이의 임의 값으로 설정할 수 있습니다.
한 풀에 0이 아닌 MIN이 정의되어 있으면 다른 풀의 유효한 MAX 값이 풀에 구성된 MAX 값의 최소값으로 다시 조정되고 100%에서 다른 풀의 MIN 값 합이 차감됩니다.
다음 표에서는 위의 개념에 대해 설명하고 내부 풀, 기본 풀 및 사용자 정의 풀 두 개에 대한 설정을 보여 줍니다. 다음 공식은 유효한 MAX % 및 공유 %를 계산하는 데 사용됩니다.
Min(X,Y)은 X와 Y 중에서 더 작은 값을 의미합니다.
Sum(X)은 모든 풀에서 X 값의 합계를 의미합니다.
총 공유 % = 100 - sum(MIN %)
유효한 MAX % = min(X,Y)
공유 % = 유효한 MAX % - MIN %
풀 이름 |
MIN % 설정 |
MAX % 설정 |
계산된 유효한 MAX % |
계산된 공유 % |
설명 |
---|---|---|---|---|---|
내부 |
0 |
100 |
100 |
0 |
유효한 MAX % 및 공유 %는 내부 풀에 적용할 수 없습니다. |
기본 |
0 |
100 |
30 |
30 |
유효한 MAX 값은 다음과 같이 계산됩니다. min(100,100-(20+50)) = 30. 계산된 공유 백분율(%)은 유효 MAX - MIN = 30입니다. |
풀 1 |
20 |
100 |
50 |
30 |
유효한 MAX 값은 다음과 같이 계산됩니다. min(100,100-50) = 50. 계산된 공유 백분율(%)은 유효 MAX - MIN = 30입니다. |
풀 2 |
50 |
70 |
70 |
20 |
유효한 MAX 값은 다음과 같이 계산됩니다. min(70,100-20) = 70. 계산된 공유 백분율(%)은 유효 MAX - MIN = 20입니다. |
위의 표를 계속 사용하여 다른 풀이 만들어질 때 수행되는 조정 작업을 보다 자세히 설명할 수 있습니다. 이 풀은 풀 3이며 MIN %가 5로 설정되어 있습니다.
풀 이름 |
MIN % 설정 |
MAX % 설정 |
계산된 유효한 MAX % |
계산된 공유 % |
설명 |
---|---|---|---|---|---|
내부 |
0 |
100 |
100 |
0 |
유효 MAX % 및 공유 %는 내부 풀에 적용할 수 없습니다. |
기본값 |
0 |
100 |
25 |
25 |
유효한 MAX 값은 다음과 같이 계산됩니다. min(100,100-(20+50+5)) = 25. 계산된 공유 백분율(%)은 유효 MAX - MIN = 25입니다. |
풀 1 |
20 |
100 |
45 |
25 |
유효한 MAX 값은 다음과 같이 계산됩니다. min(100,100-55) = 45. 계산된 공유 백분율(%)은 유효 MAX - MIN = 25입니다. |
풀 2 |
50 |
70 |
70 |
20 |
유효한 MAX 값은 다음과 같이 계산됩니다. min(70,100-25) = 70. 계산된 공유 백분율(%)은 유효 MAX - MIN = 20입니다. |
풀 3 |
5 |
100 |
30 |
25 |
유효한 MAX 값은 다음과 같이 계산됩니다. min(100,100-70) = 30. 계산된 공유 백분율(%)은 유효 MAX - MIN = 25입니다. |
풀의 공유 부분은 리소스가 사용 가능한 경우 사용 가능한 리소스가 이동할 수 있는 위치를 나타내는 데 사용됩니다. 그러나 사용된 리소스는 지정된 풀로 이동하지만 공유되지는 않습니다. 따라서 지정된 풀에 요청이 없고 이 풀에 구성된 리소스를 다른 풀에 사용할 수 있는 경우 리소스 활용도가 높아질 수 있습니다.
다음은 몇 가지 극단적인 풀 구성 사례입니다.
모든 풀은 서버 리소스의 100%를 나타내는 최소값을 정의합니다. 이 경우 유효한 최대값은 최소값과 같습니다. 이것은 지정된 풀 내부에서 리소스가 소비되는지 여부에 관계없이 서버 리소스를 겹치지 않는 부분으로 분할하는 것과 같습니다.
모든 풀은 최소값으로 0을 갖습니다. 모든 풀은 사용 가능한 리소스를 서로 차지하기 위해 경쟁하며 최종 크기가 각 풀의 리소스 소비에 따라 결정됩니다. 정책과 같은 다른 요소는 최종 풀 크기를 구체화하는 데 사용됩니다.
리소스 관리자는 두 개의 리소스 풀, 내부 풀과 기본 풀을 미리 정의합니다.
내부 풀
내부 풀은 SQL Server 자체에서 소비한 리소스를 나타냅니다. 이 풀은 항상 내부 그룹만 포함하며 어떤 식으로든 변경할 수 없습니다. 내부 풀에서는 리소스를 제한 없이 소비할 수 있습니다. 풀의 모든 작업은 서버가 작동하는 데 있어서 중요한 것으로 간주되며, 리소스 관리자를 사용하면 다른 풀에 설정된 제한을 위반하더라도 다른 풀의 리소스를 내부 풀에 사용할 수 있습니다.
[!참고]
내부 풀 및 내부 그룹 리소스 사용량은 전체 리소스 사용량에서 차감되지 않습니다. 백분율은 사용 가능한 전체 리소스를 기준으로 계산됩니다.
기본 풀
기본 풀은 미리 정의된 첫 번째 사용자 풀입니다. 구성에 관계없이 기본 풀은 기본 그룹만 포함합니다. 기본 풀은 만들거나 삭제할 수는 없지만 변경할 수는 있습니다. 기본 풀은 기본 그룹 외에 사용자 정의 그룹을 포함할 수 있습니다.
[!참고]
기본 그룹은 변경할 수는 있지만 기본 풀 밖으로 이동할 수는 없습니다.
사용자 정의 리소스 풀
리소스 관리자는 리소스 풀을 생성, 변경 및 삭제하는 DDL 문을 제공합니다. 자세한 내용은 리소스 관리자 DDL 및 시스템 뷰를 참조하십시오.
작업 그룹
작업 그룹은 각 요청에 적용되는 분류 조건에 따라 유사한 세션 요청의 컨테이너 역할을 수행합니다. 작업 그룹을 사용하면 리소스 소비에 대해 집계 모니터링을 수행하고 그룹에 있는 모든 요청에 단일 정책을 적용할 수 있습니다. 그룹은 해당 멤버에 대한 정책을 정의합니다.
[!참고]
사용자 정의 작업 그룹은 한 리소스 풀에서 다른 리소스 풀로 이동할 수 있습니다.
리소스 관리자는 내부 그룹과 기본 그룹, 두 가지의 작업 그룹을 미리 정의합니다. 사용자는 내부 그룹으로 분류된 그룹을 변경할 수 없지만 모니터링은 할 수 있습니다. 다음 조건에 해당하는 경우 요청은 기본 그룹으로 분류됩니다.
요청을 분류할 조건이 없습니다.
존재하지 않는 그룹으로 요청을 분류하려는 시도가 있습니다.
일반 분류 실패가 있습니다.
리소스 관리자는 작업 그룹을 생성, 변경 및 삭제하는 DDL 문도 제공합니다. 자세한 내용은 리소스 관리자 DDL 및 시스템 뷰를 참조하십시오.
분류
리소스 관리자는 들어오는 세션의 분류를 지원합니다. 분류는 함수에 포함된 사용자 작성 조건 집합을 기준으로 합니다. 함수 논리의 결과는 리소스 관리자가 세션을 기존 작업 그룹으로 분류할 수 있도록 합니다.
[!참고]
내부 작업 그룹은 내부 전용 요청으로 채워집니다. 이러한 요청을 라우팅하는 데 사용되는 조건은 변경할 수 없으며, 요청을 내부 작업 그룹으로 분류할 수 없습니다.
들어오는 세션을 작업 그룹에 할당하는 데 사용되는 논리가 포함된 스칼라 함수를 작성할 수 있습니다. 이 함수를 사용하려면 우선 다음 동작을 완료해야 합니다.
ALTER RESOURCE GOVERNOR 문을 사용하여 함수를 만들고 등록합니다. 자세한 내용은 ALTER RESOURCE GOVERNOR(Transact-SQL)를 참조하십시오.
ALTER RESOURCE GOVERNOR 문을 RECONFIGURE 매개 변수와 함께 사용하여 리소스 관리자 구성을 업데이트합니다.
함수를 만들고 구성 변경 내용을 적용하면 리소스 관리자 분류자는 함수에서 반환한 작업 그룹 이름을 사용하여 적절한 작업 그룹으로 새 요청을 보냅니다.
중요 |
---|
지정된 로그인 제한 시간 내에 분류 함수가 완료되지 않으면 클라이언트 세션이 시간 초과될 수 있습니다. 로그인 시간 제한은 클라이언트 속성이기 때문에 서버에서는 시간 제한을 인식하지 못합니다. 장기 실행 분류자 함수는 서버를 오랫동안 연결되지 않은 상태로 둘 수 있습니다. 따라서 연결 시간 제한 전에 실행을 종료하는 분류자 함수를 만들어야 합니다. |
사용자 정의 함수에는 다음과 같은 특징과 동작이 있습니다.
사용자 정의 함수는 모든 새 세션에 대해 평가됩니다. 연결 풀링이 사용되는 경우에도 마찬가지입니다.
사용자 정의 함수는 세션에 작업 그룹 컨텍스트를 제공합니다. 그룹 멤버가 확인되면 세션은 세션이 사용되는 기간 동안 작업 그룹에 바인딩됩니다.
사용자 정의 함수가 NULL, 기본값 또는 존재하지 않는 그룹의 이름을 반환하면 기본 작업 그룹 컨텍스트가 세션에 제공됩니다. 또한 어떤 이유로든 함수가 실패하는 경우에도 세션에 기본 컨텍스트가 제공됩니다.
함수는 서버 범위(master 데이터베이스)로 정의되어야 합니다.
분류자 사용자 정의 함수 지정은 ALTER RESOURCE GOVERNOR RECONFIGURE가 실행된 후에만 적용됩니다.
한 번에 하나의 사용자 정의 함수만 분류자로 지정될 수 있습니다.
해당 분류자 상태가 제거되지 않는 한 분류자 사용자 정의 함수는 삭제하거나 변경할 수 없습니다.
분류자 사용자 정의 함수가 없으면 모든 세션이 기본 그룹으로 분류됩니다.
분류자 함수에서 반환한 작업 그룹은 스키마 바인딩 제한의 범위를 벗어납니다. 예를 들어 테이블은 삭제할 수 없지만 작업 그룹은 삭제할 수 있습니다.
중요 |
---|
서버에서 DAC(관리자 전용 연결)를 사용하는 것이 좋습니다. DAC는 리소스 관리자 분류의 영향을 받지 않으며 분류자 함수의 모니터링 및 문제 해결에 사용할 수 있습니다. 자세한 내용은 전용 관리자 연결 사용을 참조하십시오. 문제 해결에 DAC를 사용할 수 없는 경우 사용 가능한 다른 방법은 단일 사용자 모드로 시스템을 다시 시작하는 것입니다. 단일 사용자 모드는 분류의 영향을 받지 않지만 이렇게 해도 리소스 관리자 분류가 실행 중일 때 이를 진단하는 기능은 제공되지 않습니다. |
분류 프로세스
리소스 관리자 컨텍스트에서 세션에 대한 로그인 프로세스는 다음 단계로 구성됩니다.
로그인 인증
LOGON 트리거 실행
분류
분류가 시작되면 리소스 관리자는 분류자 함수를 실행하고 이 함수에서 반환된 값을 사용하여 적절한 작업 그룹으로 요청을 보냅니다. 자세한 내용은 분류자 함수 작성 시 고려 사항을 참조하십시오.
[!참고]
분류자 함수 및 LOGON 트리거 실행에 대한 자세한 내용은 sys.dm_exec_sessions 및 sys.dm_exec_requests를 참조하십시오.