조밀한 탄력적 풀의 리소스 관리

  • 아티클

적용 대상:Azure SQL Database

Azure SQL Database 탄력적 풀은 다양한 리소스 사용으로 많은 데이터베이스를 관리하는 비용 효율적인 솔루션입니다. 탄력적 풀의 모든 데이터베이스는 언제든지 풀에 있는 일부 데이터베이스만 컴퓨팅 리소스를 사용한다는 가정하에 CPU, 메모리, 작업자 스레드, 스토리지 공간, tempdb 등의 동일한 리소스 할당을 공유합니다. 이 가정을 통해 탄력적 풀을 비용 효율적으로 수행할 수 있습니다. 각 개별 데이터베이스에 잠재적으로 필요할 수 있는 모든 리소스에 대한 비용을 지불하는 대신, 고객은 풀의 모든 데이터베이스 간에 공유되는 훨씬 작은 리소스 집합에 대해 비용을 지불합니다.

리소스 거버넌스

리소스 공유를 사용하려면 시스템에서 리소스 사용량을 신중하게 제어하여 리소스 사용량이 많은 데이터베이스가 동일한 탄력적 풀의 다른 데이터베이스에 영향을 미치는 "노이즈 네이버" 효과를 최소화해야 합니다. Azure SQL Database는 리소스 거버넌스를 구현하여 이러한 목표를 달성합니다. 동시에 시스템은 안정적으로 작동하려면 HADR(고가용성 및 재해 복구), 백업 및 복원, 모니터링, 쿼리 저장소, 자동 조정 등과 같은 기능을 위한 충분한 리소스를 제공해야 합니다.

탄력적 풀의 주 디자인 목표는 비용 효율적입니다. 이러한 이유로 시스템은 고객에게 적절한 수준의 컴퓨팅 리소스를 할당하지만, 허용되는 최대 개수나 접근하는 데이터베이스의 개수를 나타내는 풀인 조밀한 풀을 의도적으로 만들 수 있도록 합니다. 같은 이유로 시스템은 내부 프로세스에 필요한 리소스를 모두 예약하지는 않지만 내부 프로세스와 사용자 워크로드 간에 리소스 공유를 허용합니다.

이 방법을 통해 고객은 조밀한 탄력적 풀을 사용하여 적절한 성능 및 주요 비용 절감을 달성할 수 있습니다. 그러나 조밀한 풀의 많은 데이터베이스에 대한 워크로드가 충분히 강렬하면 리소스 경합이 중요해집니다. 리소스 경합은 사용자 워크로드 성능을 감소시키고 내부 프로세스에 부정적인 영향을 줄 수 있습니다.

Important

활성 데이터베이스가 많은 조밀한 풀에서는 풀의 데이터베이스 수를 DTU 및 vCore 탄력적 풀에 대해 문서화된 최대값까지 늘리지 못할 수 있습니다.

리소스 경합 및 성능 문제를 발생시키지 않고 조밀한 풀에 배치할 수 있는 데이터베이스 수는 동시 활성 데이터베이스 수 및 각 데이터베이스의 사용자 워크로드에 의한 리소스 사용량에 따라 달라집니다. 이 수는 사용자 워크로드가 변경됨에 따라 시간이 지남에 따라 변경될 수 있습니다.

또한 데이터베이스당 최소 vCores 또는 데이터베이스당 최소 DTU 설정이 0보다 큰 값으로 설정된 경우 풀의 최대 데이터베이스 수는 암시적으로 제한됩니다. 자세한 내용은 풀링된 vCore 데이터베이스에 대한 데이터베이스 속성 및 풀링된 DTU 데이터베이스에 대한 데이터베이스 속성을 참조하세요.

조밀하게 압축된 풀에서 리소스 경합이 발생하면 고객은 다음 작업 중 하나 이상을 선택하여 완화할 수 있습니다.

  • 쿼리 워크로드를 조정하여 리소스 사용량을 줄이거나 시간이 지남에 따라 여러 데이터베이스에 걸쳐 리소스 소비를 분산합니다.
  • 일부 데이터베이스를 다른 풀로 이동하거나 독립 실행형 데이터베이스를 만들어 풀 밀도를 줄입니다.
  • 풀을 스케일 업하여 더 많은 리소스를 얻습니다.

마지막 두 작업을 구현하는 방법에 대한 제안 사항은 이 문서의 뒷부분에 있는 운영 권장 사항을 참조하세요. 리소스 경합을 줄이면 사용자 워크로드와 내부 프로세스 모두에 이점이 있으며 시스템이 예상 서비스 수준을 안정적으로 기본 수 있습니다.

리소스 사용량 모니터링

리소스 경합으로 인한 성능 저하를 방지하려면 고밀도 탄력적 풀을 사용하는 고객은 리소스 소비를 사전에 모니터링하고 리소스 경합 증가가 워크로드에 영향을 미치기 시작하면 적시에 조치를 취해야 합니다. 시간이 지남에 따라 사용자 워크로드의 변경, 데이터 볼륨 및 배포의 변경, 풀 밀도의 변경 및 Azure SQL Database 서비스의 변경으로 인해 풀의 리소스 사용량이 변경되기 때문에 계속해서 모니터링하는 것이 중요합니다.

Azure SQL 데이터베이스는 이러한 유형의 모니터링과 관련된 몇 가지 메트릭을 제공합니다. 각 메트릭에 대해 권장되는 평균 값을 초과하면 풀의 리소스 경합이 표시되며 앞에서 설명한 작업 중 하나를 사용하여 주소를 지정해야 합니다.

풀 리소스 사용률(CPU, 데이터 IO, 로그 IO, 작업자 등)이 임계값을 초과할 때 경고를 보내려면 Azure Portal 또는 Add-AzMetricAlertRulev2 PowerShell cmdlet을 통해 경고를 만드는 것이 좋습니다. 탄력적 풀을 모니터링할 때 시나리오에서 필요한 경우 풀의 개별 데이터베이스에 대한 경고를 만드는 것도 좋습니다. 탄력적 풀 모니터링에 대한 샘플 시나리오는 다중 테넌트 SaaS 앱에서 Azure SQL Database의 성능 모니터링 및 관리를 참조하세요.

메트릭 이름 설명 권장 평균 값
avg_instance_cpu_percent 기본 운영 체제에서 측정한 탄력적 풀과 연결된 SQL 프로세스의 CPU 사용률입니다. 모든 데이터베이스의 sys.dm_db_resource_stats 보기와 master 데이터베이스의 sys.elastic_pool_resource_stats 보기에서 사용할 수 있습니다. 또한 이 메트릭은 명명된sql_instance_cpu_percent Azure Monitor로 내보내지고, Azure Portal에서 볼 수 있습니다. 이 값은 동일한 탄력적 풀의 모든 데이터베이스에 대해 동일합니다. 70% 미만입니다. 때때로 최대 90%까지 짧은 급증이 허용될 수 있습니다.
max_worker_percent 작업자 스레드 사용률입니다. 풀의 각 데이터베이스와 풀 자체에 대해 제공됩니다. 데이터베이스 수준에서 작업자 스레드 수에 대한 제한은 다르며 풀 수준에서는 두 수준 모두에서 이 메트릭을 모니터링하는 것이 좋습니다. 모든 데이터베이스의 sys.dm_db_resource_stats 보기와 master 데이터베이스의 sys.elastic_pool_resource_stats 보기에서 사용할 수 있습니다. 또한 이 메트릭은 명명된workers_percent Azure Monitor로 내보내지고, Azure Portal에서 볼 수 있습니다. 80% 미만입니다. 최대 100%까지 증가하면 연결 시도 및 쿼리가 실패합니다.
avg_data_io_percent 읽기 및 쓰기 물리적 IO에 대한 IOPS 사용률입니다. 풀의 각 데이터베이스와 풀 자체에 대해 제공됩니다. 데이터베이스 수준에서 IOPS에 대한 제한하고는 다르며 풀 수준에서는 두 수준 모두에서 이 메트릭을 모니터링하는 것이 좋습니다. 모든 데이터베이스의 sys.dm_db_resource_stats 보기와 master 데이터베이스의 sys.elastic_pool_resource_stats 보기에서 사용할 수 있습니다. 또한 이 메트릭은 명명된physical_data_read_percent Azure Monitor로 내보내지고, Azure Portal에서 볼 수 있습니다. 80% 미만입니다. 때때로 최대 100%까지 짧은 급증이 허용될 수 있습니다.
avg_log_write_percent 트랜잭션 로그 쓰기 IO의 처리량 사용률입니다. 풀의 각 데이터베이스와 풀 자체에 대해 제공됩니다. 데이터베이스 수준에서 로그 처리량에 대한 제한하고는 다르며 풀 수준에서는 두 수준 모두에서 이 메트릭을 모니터링하는 것이 좋습니다. 모든 데이터베이스의 sys.dm_db_resource_stats 보기와 master 데이터베이스의 sys.elastic_pool_resource_stats 보기에서 사용할 수 있습니다. 또한 이 메트릭은 명명된log_write_percent Azure Monitor로 내보내지고, Azure Portal에서 볼 수 있습니다. 이 메트릭이 100%에 가까우면 모든 데이터베이스 수정(INSERT, UPDATE, DELETE, MERGE 문, SELECT ... INTO, BULK INSERT 등)이 느려집니다. 90% 미만입니다. 때때로 최대 100%까지 짧은 급증이 허용될 수 있습니다.
oom_per_second 메모리 압력을 나타내는 탄력적 풀의 OOM(메모리 부족) 오류 비율입니다. sys.dm_resource_governor_resource_pools_history_ex 보기에서 사용할 수 있습니다. 이 메트릭을 계산하는 샘플 쿼리의 예제를 참조하세요. 자세한 내용은 DTU를 사용하는 탄력적 풀 또는 vCore를 사용하는 탄력적 풀에 대한 리소스 제한 및 Azure SQL Database를 사용하여 메모리 부족 오류 문제 해결을 참조하세요. 메모리 부족 오류가 발생하면 sys.dm_os_out_of_memory_events를 검토합니다. 0
avg_storage_percent 탄력적 풀 내의 모든 데이터베이스 내 데이터에 사용되는 총 스토리지 공간입니다. 데이터베이스 파일에 빈 공간은 포함하지 않습니다. master 데이터베이스의 sys.elastic_pool_resource_stats 보기에서 사용할 수 있습니다. 또한 이 메트릭은 명명된storage_percent Azure Monitor로 내보내지고, Azure Portal에서 볼 수 있습니다. 80% 미만입니다. 데이터 증가가 없는 풀에 100% 접근할 수 있습니다.
avg_allocated_storage_percent 탄력적 풀 내의 모든 데이터베이스에서 스토리지의 데이터베이스 파일에 사용되는 총 스토리지 공간입니다. 데이터베이스 파일에 빈 공간이 포함됩니다. master 데이터베이스의 sys.elastic_pool_resource_stats 보기에서 사용할 수 있습니다. 또한 이 메트릭은 명명된allocated_data_storage_percent Azure Monitor로 내보내지고, Azure Portal에서 볼 수 있습니다. 90% 미만입니다. 데이터 증가가 없는 풀에 100% 접근할 수 있습니다.
tempdb_log_used_percent tempdb 데이터베이스의 트랜잭션 로그 공간 사용률입니다. 한 데이터베이스에서 만든 임시 개체가 동일한 탄력적 풀의 다른 데이터베이스에 표시되지 않더라도 tempdb는 동일한 풀에 있는 모든 데이터베이스에 대한 공유 리소스입니다. 풀의 한 데이터베이스에서 tempdb 시작된 장기 실행 또는 분리된 트랜잭션은 트랜잭션 로그의 상당 부분을 사용하고 동일한 풀에 있는 다른 데이터베이스의 쿼리에 실패할 수 있습니다. sys.dm_db_log_space_usage 및 sys.database_files 보기에서 파생됩니다. 또한 이 메트릭은 Azure Monitor로 내보내지고, Azure Portal에서 볼 수 있습니다. 이 메트릭의 현재 값을 반환하는 샘플 쿼리의 예제를 참조하세요. 50% 미만입니다. 때때로 최대 80%까지 짧은 급증이 허용될 수 있습니다.

이러한 메트릭 외에도 Azure SQL Database는 실제 리소스 거버넌스 제한을 반환하는 뷰와 리소스 풀 수준 및 워크로드 그룹 수준에서 리소스 사용률 통계를 반환하는 추가 보기를 제공합니다.

보기 이름 설명
sys.dm_user_db_resource_governance 현재 데이터베이스 또는 탄력적 풀의 리소스 거버넌스 메커니즘에서 사용되는 구성과 용량 설정을 반환합니다.
sys.dm_resource_governor_resource_pools 현재 리소스 풀 상태, 리소스 풀의 현재 구성 및 누적 리소스 풀 통계에 대한 정보를 반환합니다.
sys.dm_resource_governor_workload_groups 축적 작업 그룹 통계 및 작업 그룹의 현재 구성을 반환합니다. 이 보기를 pool_id 열의 sys.dm_resource_governor_resource_pools와 조인하여 리소스 풀 정보를 얻을 수 있습니다.
sys.dm_resource_governor_resource_pools_history_ex 사용 가능한 스냅샷 수에 따라 최근 기록에 대한 리소스 풀 사용률 통계를 반환합니다. 각 행은 시간 간격을 나타냅니다. 간격의 지속 시간은 duration_ms 열에서 제공됩니다. delta_ 열은 간격 동안의 각 통계에 대한 변경 내용을 반환합니다.
sys.dm_resource_governor_workload_groups_history_ex 사용 가능한 스냅샷 수에 따라 최근 기록에 대한 작업 그룹 사용률 통계를 반환합니다. 각 행은 시간 간격을 나타냅니다. 간격의 지속 시간은 duration_ms 열에서 제공됩니다. delta_ 열은 간격 동안의 각 통계에 대한 변경 내용을 반환합니다.

팁

서버 관리자 외의 주체를 사용하여 이러한 동적 관리 보기 및 기타 동적 관리 보기를 쿼리하려면 이 주체를 ##MS_ServerStateReader##서버 역할에 추가합니다.

해당 보기를 사용하여 리소스 사용률을 모니터링하고 리소스 경합 문제를 거의 실시간으로 해결할 수 있습니다. 지역 복제본을 비롯하여 주 복제본 및 읽기 가능한 보조 복제본의 사용자 워크로드는 SloSharedPool1 리소스 풀 및 UserPrimaryGroup.DBId[N] 워크로드 그룹으로 분류됩니다. 여기서 N은 데이터베이스 ID 값을 나타냅니다.

조밀한 풀을 사용하는 고객은 현재 리소스 사용률을 모니터링하는 것 외에도 별도의 데이터 저장소에서 기록 리소스 사용률 데이터를 기본 수 있습니다. 이 데이터는 예측 분석에 사용하여 기록 및 계절 추세에 따라 리소스 사용률을 사전에 관리할 수 있습니다.

운영 권장 사항

충분한 리소스 헤드룸을 그대로 둡니다. 리소스 경합 및 성능 저하가 발생하는 경우에는 이전에 설명한 대로 영향을 받는 탄력적 풀에서 일부 데이터베이스를 이동하거나 풀을 스케일 업해야 할 수 있습니다. 그러나 이러한 작업을 완료하려면 추가 컴퓨팅 리소스가 필요합니다. 특히 프리미엄 및 중요 비즈니스용 풀의 경우 이러한 작업을 수행하려면 이동 중인 데이터베이스 또는 풀이 확장된 경우 탄력적 풀의 모든 데이터베이스에 대한 모든 데이터를 전송해야 합니다. 데이터 전송은 장기 실행되고 리소스를 많이 사용하는 작업입니다. 풀이 이미 높은 리소스 압력을 받고 있는 경우 완화 작업 자체는 성능이 더욱 저하됩니다. 극단적인 경우 필요한 리소스를 사용할 수 없으므로 데이터베이스 이동 또는 풀 강화를 통해 리소스 경합을 해결할 수 없습니다. 이 경우 영향을 받는 탄력적 풀에서 쿼리 워크로드를 일시적으로 줄이는 것이 유일한 솔루션일 수 있습니다.

조밀한 풀을 사용하는 고객은 앞에서 설명한 대로 리소스 사용률 추세를 면밀히 모니터링하고, 메트릭이 권장 범위 내에서 다시 기본 탄력적 풀에 충분한 리소스가 있는 동안 완화 작업을 수행해야 합니다.

리소스 사용률은 각 데이터베이스와 각 탄력적 풀에 대해 시간이 지나면서 변경되는 여러 요소에 따라 다릅니다. 조밀한 풀에서 최적의 가격/성능 비율을 달성하려면 지속적으로 모니터링하고 균형을 조정해야 합니다. 즉 더 많이 사용되는 풀에서 더 적게 사용되는 풀로 데이터베이스를 이동하고 증가된 워크로드를 수용하기 위해 필요한 대로 새 풀을 만드는 것입니다.

참고 항목

DTU 탄력적 풀의 경우 풀 수준에서 eDTU 메트릭은 개별 데이터베이스 사용률의 MAX 또는 SUM이 아닙니다. 다양한 풀 수준 메트릭의 사용률에서 파생됩니다. 풀 수준 리소스 제한은 개별 데이터베이스 수준 제한보다 클 수 있으므로 풀에 대한 eDTU 보고에서 제한에 도달하지 않았다고 표시된 경우에도 개별 데이터베이스가 특정 리소스 제한(CPU, 데이터 IO, 로그 IO 등)에 도달할 수 있습니다.

“핫” 데이터베이스를 이동하지 마세요. 풀 수준의 리소스 경합이 주로 적은 수의 높은 사용률의 데이터베이스로 인해 발생하는 경우 이러한 데이터베이스를 덜 활용된 풀로 이동하거나 독립 실행형 데이터베이스로 만드는 것이 좋습니다. 그러나 데이터베이스기본를 다시 사용하는 동안에는 이 작업을 수행하지 않는 것이 좋습니다. 이동 작업으로 인해 이동 중인 데이터베이스와 전체 풀의 성능이 더욱 저하되기 때문입니다. 대신 높은 사용률이 진정될 때까지 기다리거나, 풀 수준에서 리소스 압력을 완화하기 위해 더 적게 사용되는 데이터베이스를 이동합니다. 그러나 사용률이 매우 낮은 데이터베이스를 이동해도 풀 수준에서 리소스 사용률이 실질적으로 감소하지 않으므로 이 경우 어떤 이점도 제공하지 않습니다.

"격리" 풀에 새 데이터베이스를 만듭니다. 데이터베이스당 테넌트 모델을 사용하는 애플리케이션과 같이 새 데이터베이스가 자주 만들어지는 시나리오에서 기존 탄력적 풀에 배치되는 새 데이터베이스가 예기치 않게 상당한 양의 리소스를 사용하고 풀의 다른 데이터베이스 및 내부 프로세스에 영향을 줄 수 있습니다. 이러한 위험을 완화하려면 충분한 리소스 할당을 사용하여 별도의 "격리" 풀을 만듭니다. 아직 알 수 없는 리소스 사용 패턴이 있는 새 데이터베이스에 이 풀을 사용합니다. 데이터베이스가 1주일 또는 1개월과 같은 비즈니스 주기 동안 이 풀에 머물렀고 해당 리소스 사용량이 알려지면 이 추가 리소스 사용량을 수용할 수 있는 충분한 용량의 풀로 이동할 수 있습니다.

사용된 공간과 할당된 공간을 모두 모니터링합니다. 할당된 풀 공간(풀의 모든 데이터베이스에 대한 스토리지 내 모든 데이터베이스 파일의 전체 크기)이 최대 풀 크기에 도달하면 공간 부족 오류가 발생할 수 있습니다. 할당된 공간 추세가 높고 최대 풀 크기에 도달하기 위해 궤도에 있는 경우 완화 옵션은 다음과 같습니다.

  • 일부 데이터베이스를 풀 외부로 이동하여 할당된 총 공간 줄이기
  • 파일의 빈 할당 공간을 줄이기 위해 데이터베이스 파일 축소
  • 최대 풀 크기가 더 큰 서비스 목표로 풀 스케일 업

풀 공간(풀의 모든 데이터베이스에 있는 데이터의 전체 크기, 파일에 빈 공간을 포함하지 않음)이 많아지고 최대 풀 크기에 도달하려고 하는 경우 완화 옵션은 다음과 같습니다.

  • 사용 중인 전체 공간을 줄이기 위해 일부 데이터베이스를 풀 외부로 이동
  • 데이터베이스 외부로 데이터를 이동(보관)하거나 더 이상 필요하지 않은 데이터를 삭제합니다.
  • 데이터 압축 구현
  • 최대 풀 크기가 더 큰 서비스 목표로 풀 스케일 업

지나치게 조밀한 서버를 방지합니다. Azure SQL 데이터베이스는 서버당 최대 5,000개의 데이터베이스를 지원합니다. 수천 개의 데이터베이스에서 탄력적 풀을 사용하는 고객은 단일 서버에 여러 탄력적 풀을 배치하는 것이 좋습니다. 이 경우 총 데이터베이스 수는 지원되는 최대치입니다. 그러나 수천 개의 데이터베이스가 있는 서버는 운영 문제를 야기합니다. 서버의 모든 데이터베이스를 열거해야 하는 작업(예: 포털의 데이터베이스 보기)은 더 느려집니다. 서버 수준 로그인 또는 방화벽 규칙의 잘못된 수정과 같은 운영 오류는 더 많은 수의 데이터베이스에 영향을 줍니다. 서버를 실수로 삭제하려면 삭제된 서버의 데이터베이스를 복구하기 위해 Microsoft 지원 지원이 필요하며 영향을 받는 모든 데이터베이스에 대해 장기간 중단이 발생합니다.

서버당 데이터베이스 수를 지원되는 최대 개수보다 낮게 제한합니다. 대부분의 시나리오에서 서버당 최대 1000-2000 개의 데이터베이스를 사용하는 것이 가장 좋습니다. 실수로 서버를 삭제할 가능성을 줄이려면 서버 또는 해당 리소스 그룹에 삭제 잠금을 배치하는 것이 좋습니다.

예제

개별 데이터베이스 용량 설정 보기

현재 데이터베이스 또는 탄력적 풀에서 리소스 거버넌스에 의해 사용되는 실제 구성 및 용량 설정을 확인하려면 sys.dm_user_db_resource_governance 동적 관리 뷰를 사용합니다. 자세한 내용은 sys.dm_user_db_resource_governance를 참조하세요.

탄력적 풀의 모든 데이터베이스에서 이 쿼리를 실행합니다. 풀의 모든 데이터베이스에는 동일한 리소스 거버넌스 설정이 있습니다.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

전체 탄력적 풀 리소스 사용률 모니터링

전체 풀의 리소스 사용률을 모니터링하려면 sys.elastic_pool_resource_stats 시스템 카탈로그 뷰를 사용합니다. 자세한 내용은 sys.elastic_pool_resource_stats를 참조하세요.

마지막 10분을 보는 이 샘플 쿼리를 원하는 탄력적 풀이 포함된 논리 Azure SQL Server의 master 데이터베이스에서 실행해야 합니다.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

개별 데이터베이스 리소스 사용률 모니터링

개별 데이터베이스의 리소스 사용률을 모니터링하려면 sys.dm_db_resource_stats 동적 관리 뷰를 사용합니다. 자세한 내용은 sys.dm_db_resource_stats를 참조하세요. 활동이 없더라도 15초 간격으로 한 행이 있습니다. 기록 데이터는 약 1시간 동안 유지됩니다.

마지막 10분의 데이터를 보는 이 샘플 쿼리를 원하는 데이터베이스에서 실행해야 합니다.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

빈도가 더 적고 보존 시간이 긴 경우에는 Azure SQL 논리 서버의 master 데이터베이스에서 sys.resource_stats 실행에 대해 다음 쿼리를 고려해 보세요. 자세한 내용은 sys.resource_stats (Azure SQL Database)를 참조하세요. 5분 간격으로 한 행이 있으며 기록 데이터는 2주 동안 유지됩니다.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

메모리 사용률 모니터링

이 쿼리는 사용 가능한 스냅샷 수를 기준으로 최근 기록에 대해 각 리소스 풀에의 oom_per_second 메트릭을 계산합니다. 이 샘플 쿼리는 풀에서 실패한 메모리 할당의 최근 평균 수를 식별하는 데 도움이 됩니다. 이 쿼리는 탄력적 풀의 모든 데이터베이스에서 실행할 수 있습니다.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

tempdb 로그 공간 사용률 모니터링

이 쿼리는 허용되는 최대 크기를 기준으로 tempdb_log_used_percent 트랜잭션 로그의 상대 사용률을 보여 주는 tempdb 메트릭의 현재 값을 반환합니다. 이 쿼리는 탄력적 풀의 모든 데이터베이스에서 실행할 수 있습니다.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

다음 단계