Azure SQL Database 및 Azure Synapse Analytics 서버에 대 한 리소스 제한Resource limits for Azure SQL Database and Azure Synapse Analytics servers

적용 대상: Azure SQL Database Azure Synapse Analytics

이 문서에서는 Azure SQL Database 및 Azure Synapse Analytics에서 사용 되는 논리 서버 에 대 한 리소스 제한에 대 한 개요를 제공 합니다.This article provides an overview of the resource limits for the logical server used by Azure SQL Database and Azure Synapse Analytics. 리소스 제한에 도달 하거나 초과 하는 경우 발생 하는 상황에 대 한 정보를 제공 하 고 이러한 제한을 적용 하는 데 사용 되는 리소스 관리 메커니즘을 설명 합니다.It provides information on what happens when those resource limits are hit or exceeded and describes the resource governance mechanisms used to enforce these limits.

참고

Azure SQL Managed Instance 제한의 경우 관리 되는 인스턴스의 리소스 제한을 참조 하세요.For Azure SQL Managed Instance limits, see resource limits for managed instances.

최대 리소스 한도Maximum resource limits

리소스Resource 제한Limit
논리 서버당 데이터베이스 수Databases per logical server 5,0005000
지역에서 구독 당 기본 논리 서버 수Default number of logical servers per subscription in a region 2020
한 지역에서 구독 당 최대 논리 서버 수Max number of logical servers per subscription in a region 200200
논리 서버당 DTU/eDTU 할당량DTU / eDTU quota per logical server 54,00054,000
논리 서버당 vCore 할당량vCore quota per logical server 540540
논리 서버당 최대 풀Max pools per logical server DTU 또는 vCore의 수로 제한됩니다.Limited by number of DTUs or vCores. 예를 들어 각 풀에 DTU가 1000개인 경우 서버는 54개 풀을 지원할 수 있습니다.For example, if each pool is 1000 DTUs, then a server can support 54 pools.

중요

데이터베이스 수가 논리 서버당 한도에 근접하면 다음이 발생할 수 있습니다.As the number of databases approaches the limit per logical server, the following can occur:

  • 마스터 데이터베이스에 대해 쿼리를 실행할 때 대기 시간이 증가합니다.Increasing latency in running queries against the master database. 여기에는와 같은 리소스 사용률 통계의 뷰가 포함 됩니다 sys.resource_stats .This includes views of resource utilization statistics such as sys.resource_stats.
  • 관리 작업을 수행하고 서버의 데이터베이스 열거와 관련된 포털 뷰 포인트를 렌더링할 때 대기 시간이 증가합니다.Increasing latency in management operations and rendering portal viewpoints that involve enumerating databases in the server.

참고

더 많은 DTU/eDTU 할당량, vCore 할당량 또는 기본 용량 보다 더 많은 논리 서버를 얻으려면 Azure Portal에 새 지원 요청을 제출 합니다.To obtain more DTU/eDTU quota, vCore quota, or more logical servers than the default amount, submit a new support request in the Azure portal. 자세한 내용은 Azure SQL Database에 대 한 요청 할당량 늘리기를 참조 하세요.For more information, see Request quota increases for Azure SQL Database.

스토리지 크기Storage size

단일 데이터베이스 리소스 저장소 크기의 경우 가격 책정 계층 당 저장소 크기 제한에 대 한 DTU 기반 리소스 제한 또는 vcore 기반 리소스 제한 을 참조 하세요.For single databases resource storage sizes, refer to either DTU-based resource limits or vCore-based resource limits for the storage size limits per pricing tier.

데이터베이스 리소스 한계에 도달하면 어떻게 되나요?What happens when database resource limits are reached

CPU 계산Compute CPU

데이터베이스 계산 CPU 사용률이 높으면 쿼리 대기 시간이 늘어나고 쿼리 시간이 초과 될 수도 있습니다. 이러한 조건에서 쿼리는 서비스에 의해 큐에 대기 될 수 있으며 리소스가 사용 가능 해지면 실행할 리소스를 제공 합니다.When database compute CPU utilization becomes high, query latency increases, and queries can even time out. Under these conditions, queries may be queued by the service and are provided resources for execution as resources become free. 높은 컴퓨팅 사용률에 도달할 경우 완화하는 방법에는 다음이 포함됩니다.When encountering high compute utilization, mitigation options include:

StorageStorage

사용된 데이터베이스 공간이 최대 크기 제한에 도달하면 데이터 크기 증가를 가져오는 데이터베이스 삽입 및 업데이트가 실패하고 클라이언트에 오류 메시지가 표시됩니다.When database space used reaches the max size limit, database inserts and updates that increase the data size fail and clients receive an error message. SELECT 및 DELETE 문은 계속 성공 합니다.SELECT and DELETE statements continue to succeed.

높은 공간 사용률에 도달할 경우 완화하는 방법에는 다음이 포함됩니다.When encountering high space utilization, mitigation options include:

  • 데이터베이스 또는 탄력적 풀의 최대 크기를 늘리거나 저장소를 더 추가 합니다.Increasing the max size of the database or elastic pool, or adding more storage. 단일 데이터베이스 리소스 확장탄력적 풀 리소스 확장을 참조하세요.See Scale single database resources and Scale elastic pool resources.
  • 데이터베이스가 탄력적 풀에 있는 경우에는 데이터베이스를 풀 외부로 이동 하 여 해당 저장소 공간을 다른 데이터베이스와 공유 하지 않을 수 있습니다.If the database is in an elastic pool, then alternatively the database can be moved outside of the pool so that its storage space isn't shared with other databases.
  • 데이터베이스를 축소하여 사용하지 않는 공간을 회수합니다.Shrink a database to reclaim unused space. 자세한 내용은 Azure SQL Database에서 파일 공간 관리를 참조 하세요.For more information, see Manage file space in Azure SQL Database.
  • 높은 공간 사용률이 영구 버전 저장소 (PVS)의 크기 급증 때문 인지 확인 합니다.Check if high space utilization is due to a spike in the size of Persistent Version Store (PVS). PVS는 각 데이터베이스의 일부 이며 가속화 된 데이터베이스 복구를 구현 하는 데 사용 됩니다.PVS is a part of each database, and is used to implement Accelerated Database Recovery. 현재 PVS 크기를 확인 하려면 pvs 문제 해결을 참조 하세요.To determine current PVS size, see PVS troubleshooting. 큰 PVS 크기에 대 한 일반적인 이유는 오랜 시간 동안 열려 있는 트랜잭션이 며,이는 PVS에서 이전 버전의 정리를 방지 하는 것입니다.A common reason for large PVS size is a transaction that is open for a long time (hours), preventing cleanup of older versions in PVS.

세션 및 작업자(요청)Sessions and workers (requests)

세션 및 작업자의 최대 수는 서비스 계층 및 계산 크기 (Dtu/Edtu 또는 vCores)에 따라 결정 됩니다.The maximum numbers of sessions and workers are determined by the service tier and compute size (DTUs/eDTUs or vCores). 세션 또는 작업자 제한에 도달하면 새 요청이 거부되고 클라이언트에 오류 메시지가 표시됩니다.New requests are rejected when session or worker limits are reached, and clients receive an error message. 사용할 수 있는 연결의 수는 애플리케이션에서 쉽게 제어할 수 있지만, 동시 작업자 수는 예측하고 제어하기가 어렵습니다.While the number of connections available can be controlled by the application, the number of concurrent workers is often harder to estimate and control. 이는 데이터베이스 리소스 제한에 도달 했을 때 발생 하는 최대 부하 기간 동안 쿼리, 큰 차단 체인 또는 과도 한 쿼리 병렬 처리로 인해 작업자를 누적 하는 경우에 특히 그렇습니다.This is especially true during peak load periods when database resource limits are reached and workers pile up due to longer running queries, large blocking chains, or excessive query parallelism.

높은 세션 또는 작업자 사용률에 도달할 경우 완화하는 방법에는 다음이 포함됩니다.When encountering high session or worker utilization, mitigation options include:

메모리Memory

다른 리소스 (CPU, 작업자, 저장소)와 달리 메모리 한도에 도달 하면 쿼리 성능에 부정적인 영향을 주지 않으며 오류 및 오류를 발생 시 키 지 않습니다.Unlike other resources (CPU, workers, storage), reaching the memory limit does not negatively impact query performance, and does not cause errors and failures. 메모리 관리 아키텍처 가이드에 자세히 설명 된 대로 SQL Server 데이터베이스 엔진은 사용 가능한 모든 메모리를 의도적으로 사용 합니다.As described in detail in Memory Management Architecture Guide, the SQL Server database engine often uses all available memory, by design. 메모리는 주로 데이터를 캐시 하는 데 사용 되어 비용이 많이 드는 저장소 액세스를 방지 합니다.Memory is used primarily for caching data, to avoid more expensive storage access. 따라서 더 높은 메모리 사용률은 일반적으로 저장소에서 더 느리게 읽을 수 있는 것이 아니라 메모리에서 읽기가 더 빠르기 때문에 쿼리 성능을 향상 시킵니다.Thus, higher memory utilization usually improves query performance due to faster reads from memory, rather than slower reads from storage.

데이터베이스 엔진을 시작한 후 작업이 저장소에서 데이터를 읽기 시작할 때 데이터베이스 엔진은 메모리에 데이터를 적극적으로 캐시 합니다.After database engine startup, as the workload starts to read data from storage, the database engine aggressively caches data in memory. 이 초기 램프 기간 후에는 일반적으로 avg_memory_usage_percent avg_instance_memory_percent sys.dm_db_resource_stats 의 및 열이 100% (특히 유휴 상태가 아닌 데이터베이스의 경우) 또는 메모리에 완전히 맞지 않는 것을 볼 수 있습니다.After this initial ramp-up period, it is common and expected to see the avg_memory_usage_percent and avg_instance_memory_percent columns in sys.dm_db_resource_stats to be close or equal to 100%, particularly for databases that are not idle, and do not fully fit in memory.

데이터 캐시 외에도, 메모리는 데이터베이스 엔진의 다른 구성 요소에서 사용 됩니다.Besides the data cache, memory is used in other components of the database engine. 메모리에 대 한 요구가 있고 데이터 캐시에서 사용 가능한 모든 메모리를 사용 하는 경우 데이터베이스 엔진은 메모리를 다른 구성 요소에 사용할 수 있도록 데이터 캐시 크기를 동적으로 축소 하 고 다른 구성 요소에서 메모리를 해제할 때 데이터 캐시를 동적으로 확장 합니다.When there is demand for memory and all available memory has been used by the data cache, the database engine will dynamically shrink data cache size to make memory available to other components, and will dynamically grow data cache when other components release memory.

드문 경우 지만 충분 한 작업을 수행 하면 메모리 부족 오류가 발생 하 여 메모리 부족 오류가 발생할 수 있습니다.In rare cases, a sufficiently demanding workload may cause an insufficient memory condition, leading to out-of-memory errors. 이는 0%에서 100% 사이의 모든 메모리 사용률 수준에서 발생할 수 있습니다.This can happen at any level of memory utilization between 0% and 100%. 이는 메모리 제한에 비례 하는 작은 계산 크기에서 발생 하거나, 조밀한 탄력적 풀등의 쿼리 처리를 위해 더 많은 메모리를 사용 하는 워크 로드를 사용 하는 경우에 발생할 수 있습니다.This is more likely to occur on smaller compute sizes that have proportionally smaller memory limits, and/or with workloads using more memory for query processing, such as in dense elastic pools.

메모리 부족 오류가 발생할 경우 완화 옵션은 다음과 같습니다.When encountering out-of-memory errors, mitigation options include:

해결 방법Solution DescriptionDescription
메모리 부여 크기 줄이기Reduce the size of memory grants 메모리 부여에 대 한 자세한 내용은 메모리 부여 SQL Server 이해 블로그 게시물을 참조 하세요.For more information about memory grants, see the Understanding SQL Server memory grant blog post. 과도 한 메모리 부여를 방지 하는 일반적인 솔루션은 통계 를 최신 상태로 유지 하는 것입니다.A common solution for avoiding excessively large memory grants is keeping statistics up to date. 이로 인해 쿼리 엔진에서 메모리 사용을 보다 정확 하 게 예측 하 여 불필요 한 메모리 부여를 방지 합니다.This results in more accurate estimates of memory consumption by the query engine, avoiding unnecessarily large memory grants.

호환성 수준 140 이상을 사용 하는 데이터베이스에서 데이터베이스 엔진은 일괄 처리 모드 메모리 부여 피드백을 사용 하 여 메모리 부여 크기를 자동으로 조정할 수 있습니다.In databases using compatibility level 140 and later, the database engine may automatically adjust memory grant size using Batch mode memory grant feedback. 호환성 수준 150 이상을 사용 하는 데이터베이스에서 데이터베이스 엔진은 보다 일반적인 행 모드 쿼리에 대해 행 모드 메모리 부여 피드백을 사용 합니다.In databases using compatibility level 150 and later, the database engine similarly uses Row mode memory grant feedback, for more common row mode queries. 이 기본 제공 기능을 사용 하면 불필요 하 게 많은 메모리 부여로 인 한 메모리 부족 오류를 방지할 수 있습니다.This built-in functionality helps avoid out-of-memory errors due to unnecessarily large memory grants.
쿼리 계획 캐시 크기 줄이기Reduce the size of query plan cache 데이터베이스 엔진은 모든 쿼리 실행에 대해 쿼리 계획을 컴파일하지 않도록 메모리에 쿼리 계획을 캐시 합니다.The database engine caches query plans in memory, to avoid compiling a query plan for every query execution. 한 번만 사용 되는 캐싱 계획으로 인해 발생 하는 쿼리 계획 캐시의 영향을 방지 하려면 OPTIMIZE_FOR_AD_HOC_WORKLOADS 데이터베이스 범위 구성을사용 하도록 설정 합니다.To avoid query plan cache bloat caused by caching plans that are only used once, enable the OPTIMIZE_FOR_AD_HOC_WORKLOADS database-scoped configuration.
잠금 메모리 크기 줄이기Reduce the size of lock memory 데이터베이스 엔진은 잠금에 메모리를 사용 합니다.The database engine uses memory for locks. 가능 하면 많은 수의 잠금을 획득 하 고 높은 잠금 메모리 사용을 유발할 수 있는 큰 트랜잭션을 사용 하지 마십시오.When possible, avoid large transactions that may acquire a large number of locks and cause high lock memory consumption.

사용자 작업 및 내부 프로세스의 리소스 사용량Resource consumption by user workloads and internal processes

각 데이터베이스의 사용자 작업에의 한 CPU 및 메모리 소비는 및 열에 sys.dm_db_resource_statssys.resource_stats 뷰에 보고 됩니다 avg_cpu_percent avg_memory_usage_percent .CPU and memory consumption by user workloads in each database is reported in the sys.dm_db_resource_stats and sys.resource_stats views, in avg_cpu_percent and avg_memory_usage_percent columns. 탄력적 풀의 경우 풀 수준 리소스 소비가 sys.elastic_pool_resource_stats 보기에 보고 됩니다.For elastic pools, pool-level resource consumption is reported in the sys.elastic_pool_resource_stats view. 또한 사용자 작업 CPU 소비는 cpu_percent 풀 수준에서 단일 데이터베이스탄력적 풀 에 대 한 Azure Monitor 메트릭을 통해 보고 됩니다.User workload CPU consumption is also reported via the cpu_percent Azure Monitor metric, for single databases and elastic pools at the pool level.

Azure SQL Database은 고가용성 및 재해 복구, 데이터베이스 백업 및 복원, 모니터링, 쿼리 저장소, 자동 조정 등의 핵심 서비스 기능을 구현 하기 위해 계산 리소스가 필요 합니다. 시스템은 리소스 거 버 넌 스 메커니즘을 사용 하 여 이러한 내부 프로세스에 대 한 전체 리소스의 특정 부분을 따로 설정 하 여 나머지 리소스를 사용자 작업에 사용할 수 있도록 합니다.Azure SQL Database requires compute resources to implement core service features such as high availability and disaster recovery, database backup and restore, monitoring, Query Store, Automatic tuning, etc. The system sets aside a certain limited portion of the overall resources for these internal processes using resource governance mechanisms, making the remainder of resources available for user workloads. 내부 프로세스에서 계산 리소스를 사용 하지 않는 경우 시스템에서 사용자 작업에 사용할 수 있도록 합니다.At times when internal processes aren't using compute resources, the system makes them available to user workloads.

사용자 작업 및 내부 프로세스의 총 CPU 및 메모리 사용은 및 열에서 sys.dm_db_resource_statssys.resource_stats 뷰에 보고 됩니다 avg_instance_cpu_percent avg_instance_memory_percent .Total CPU and memory consumption by user workloads and internal processes is reported in the sys.dm_db_resource_stats and sys.resource_stats views, in avg_instance_cpu_percent and avg_instance_memory_percent columns. 이 데이터는 sqlserver_process_core_percent sqlserver_process_memory_percent 단일 데이터베이스 에 대 한 및 Azure Monitor 메트릭과 풀 수준에서 탄력적 풀 을 통해서도 보고 됩니다.This data is also reported via the sqlserver_process_core_percent and sqlserver_process_memory_percent Azure Monitor metrics, for single databases and elastic pools at the pool level.

사용자 작업 및 내부 프로세스에의 한 최근 리소스 사용에 대 한 자세한 분석은 sys.dm_resource_governor_resource_pools_history_exsys.dm_resource_governor_workload_groups_history_ex 보기에서 보고 됩니다.A more detailed breakdown of recent resource consumption by user workloads and internal processes is reported in the sys.dm_resource_governor_resource_pools_history_ex and sys.dm_resource_governor_workload_groups_history_ex views. 이러한 보기에서 참조 되는 리소스 풀 및 작업 그룹에 대 한 자세한 내용은 리소스 관리를 참조 하세요.For details on resource pools and workload groups referenced in these views, see Resource governance. 이러한 뷰는 연결 된 리소스 풀 및 작업 그룹의 특정 내부 프로세스 및 사용자 작업에의 한 리소스 사용률을 보고 합니다.These views report on resource utilization by user workloads and specific internal processes in the associated resource pools and workload groups.

성능 모니터링 및 문제 해결의 맥락에서 사용자 작업 및 내부 프로세스 (,)에의 한 사용자 cpu 소비 ( avg_cpu_percent , cpu_percent ) 및 총 cpu 소비 를 고려 하는 것이 중요 합니다 avg_instance_cpu_percent sqlserver_process_core_percent .In the context of performance monitoring and troubleshooting, it's important to consider both user CPU consumption (avg_cpu_percent, cpu_percent), and total CPU consumption by user workloads and internal processes (avg_instance_cpu_percent,sqlserver_process_core_percent).

사용자 CPU 소비 는 각 서비스 목표에서 사용자 작업 제한의 백분율로 계산 됩니다.User CPU consumption is calculated as a percentage of the user workload limits in each service objective. 100%의 사용자 CPU 사용률 은 사용자 작업이 서비스 목표 한도에 도달 했음을 나타냅니다.User CPU utilization at 100% indicates that the user workload has reached the limit of the service objective. 그러나 총 cpu 사용량이 70-100% 범위에 도달 하면 보고 된 사용자 CPU 사용량이 100% 미만으로 유지 되는 경우에도 사용자 작업 처리량이 증가 하 고 쿼리 대기 시간이 증가 하는 것을 볼 수 있습니다.However, when total CPU consumption reaches the 70-100% range, it's possible to see user workload throughput flattening out and query latency increasing, even if reported user CPU consumption remains significantly below 100%. 이는 계산 리소스의 중간 할당으로 더 작은 서비스 목표를 사용 하는 경우에 발생할 수 있지만, 조밀한 탄력적 풀과 같은 비교적 강력한 사용자 작업을 사용 하는 경우가 많습니다.This is more likely to occur when using smaller service objectives with a moderate allocation of compute resources, but relatively intense user workloads, such as in dense elastic pools. 이는 데이터베이스의 새 복제본을 만드는 경우와 같이 내부 프로세스에 일시적으로 추가 리소스가 필요할 때 더 작은 서비스 목표에서 발생할 수도 있습니다.This can also occur with smaller service objectives when internal processes temporarily require additional resources, for example when creating a new replica of the database.

총 CPU 사용량이 높으면 완화 옵션은 앞에서 설명한 것과 같으며 서비스 목표 증가 및/또는 사용자 작업 최적화를 포함 합니다.When total CPU consumption is high, mitigation options are the same as noted earlier and include service objective increase and/or user workload optimization.

리소스 거버넌스Resource governance

리소스 제한을 적용 하기 위해 Azure SQL Database는 SQL Server Resource Governor, 수정 및 확장을 기반으로 하는 리소스 거 버 넌 스 구현을 사용 하 여 Azure SQL Database에서 실행 합니다.To enforce resource limits, Azure SQL Database uses a resource governance implementation that is based on SQL Server Resource Governor, modified and extended to run in Azure SQL Database. SQL Database에서 리소스 제한이 풀과 그룹 수준 모두에서 설정 된 여러 리소스 풀작업 그룹분산 된 데이터베이스 서비스를 제공 합니다.In SQL Database, multiple resource pools and workload groups, with resource limits set at both pool and group levels, provide a balanced Database-as-a-Service. 사용자 작업 및 내부 작업은 별도의 리소스 풀 및 작업 그룹으로 분류 됩니다.User workload and internal workloads are classified into separate resource pools and workload groups. 지역 복제본을 비롯 하 여 읽기 가능한 주 보조 복제본의 사용자 작업은 SloSharedPool1 리소스 풀 및 작업 그룹으로 분류 됩니다 UserPrimaryGroup.DBId[N] . 여기서는 N 데이터베이스 ID 값을 나타냅니다.User workload on the primary and readable secondary replicas, including geo-replicas, is classified into the SloSharedPool1 resource pool and UserPrimaryGroup.DBId[N] workload group, where N stands for the database ID value. 또한 다양 한 내부 워크 로드에 대 한 여러 리소스 풀 및 작업 그룹이 있습니다.In addition, there are multiple resource pools and workload groups for various internal workloads.

는 Resource Governor를 사용 하 여 SQL 프로세스 내에서 리소스를 제어 하는 것 외에도 Windows 작업 개체 를 사용 하 여 프로세스 수준 리소스 거 버 넌 스와 저장소 할당량 관리를 위한 Windows 파일 서버 리소스 관리자 (FSRM) 를 사용 Azure SQL Database.In addition to using Resource Governor to govern resources within the SQL process, Azure SQL Database also uses Windows Job Objects for process level resource governance, and Windows File Server Resource Manager (FSRM) for storage quota management.

Azure SQL Database 리소스 관리는 본질적으로 계층적입니다.Azure SQL Database resource governance is hierarchical in nature. 위에서 아래로, 운영 체제 리소스 관리 메커니즘을 사용 하 고 저장소 볼륨 수준에서 운영 체제 리소스 관리 메커니즘을 사용 하 고 Resource Governor 한 다음 Resource Governor를 사용 하 여 리소스 풀 수준에서 제한을 적용 하 고 Resource Governor를 사용 하 여 작업 그룹 수준에서 제한을 적용 합니다.From top to bottom, limits are enforced at the OS level and at the storage volume level using operating system resource governance mechanisms and Resource Governor, then at the resource pool level using Resource Governor, and then at the workload group level using Resource Governor. 현재 데이터베이스 또는 탄력적 풀에 적용 되는 리소스 관리 제한이 sys.dm_user_db_resource_governance 보기에 표시 됩니다.Resource governance limits in effect for the current database or elastic pool are surfaced in the sys.dm_user_db_resource_governance view.

데이터 IO 거 버 넌 스Data IO governance

데이터 IO 거 버 넌 스는 데이터베이스의 데이터 파일에 대 한 읽기 및 쓰기 물리적 IO를 제한 하는 데 사용 되는 Azure SQL Database의 프로세스입니다.Data IO governance is a process in Azure SQL Database used to limit both read and write physical IO against data files of a database. 각 서비스 수준에 대해 IOPS 제한이 설정 되어 "잡음이 있는 환경" 효과를 최소화 하 고, 다중 테 넌 트 서비스에서 리소스 할당 범위를 제공 하 고, 기본 하드웨어 및 저장소의 기능을 유지할 수 있습니다.IOPS limits are set for each service level to minimize the "noisy neighbor" effect, to provide resource allocation fairness in the multi-tenant service, and to stay within the capabilities of the underlying hardware and storage.

단일 데이터베이스의 경우 데이터베이스에 대 한 모든 저장소 IO에 작업 그룹 제한이 적용 되는 반면, 리소스 풀 제한은 데이터베이스를 포함 하 여 동일한 전용 SQL 풀에 있는 모든 데이터베이스에 대 한 모든 저장소 IO에 적용 됩니다 tempdb .For single databases, workload group limits are applied to all storage IO against the database, while resource pool limits apply to all storage IO against all databases on the same dedicated SQL pool, including the tempdb database. 탄력적 풀의 경우 작업 그룹 제한은 풀의 각 데이터베이스에 적용 되는 반면, 리소스 풀 제한은 tempdb 풀의 모든 데이터베이스 간에 공유 되는 데이터베이스를 포함 하 여 전체 탄력적 풀에 적용 됩니다.For elastic pools, workload group limits apply to each database in the pool, whereas resource pool limit applies to the entire elastic pool, including the tempdb database, which is shared among all databases in the pool. 일반적으로 작업 그룹 제한은 리소스 풀 제한 보다 낮으므로 IOPS/처리량을 단축 하기 때문에 데이터베이스 (단일 또는 풀)에 대해 작업에서 리소스 풀 제한을 달성 하지 못할 수 있습니다.In general, resource pool limits may not be achievable by the workload against a database (either single or pooled), because workload group limits are lower than resource pool limits and limit IOPS/throughput sooner. 그러나 풀 제한은 동일한 풀의 여러 데이터베이스에 대해 결합 된 워크 로드에서 도달할 수 있습니다.However, pool limits may be reached by the combined workload against multiple databases on the same pool.

예를 들어 쿼리가 IO 리소스 관리 없이 1000 IOPS를 생성 하지만 작업 그룹 최대 IOPS 제한이 900 IOPS로 설정 된 경우 쿼리에서 900 IOPS를 초과 하 여 생성할 수 없습니다.For example, if a query generates 1000 IOPS without any IO resource governance, but the workload group maximum IOPS limit is set to 900 IOPS, the query won't be able to generate more than 900 IOPS. 그러나 리소스 풀의 최대 IOPS 한도가 1500 IOPS로 설정 되 고 리소스 풀과 연결 된 모든 작업 그룹의 총 IO가 1500 IOPS를 초과 하는 경우 동일한 쿼리의 IO가 작업 그룹 제한 (900 IOPS) 아래로 줄어들 수 있습니다.However, if the resource pool maximum IOPS limit is set to 1500 IOPS, and the total IO from all workload groups associated with the resource pool exceeds 1500 IOPS, then the IO of the same query may be reduced below the workgroup limit of 900 IOPS.

Sys.dm_user_db_resource_governance 뷰에서 반환 된 IOPS 및 처리량 최소/최대 값은 보장 되는 것이 아니라 극한/cap 역할을 합니다.The IOPS and throughput min/max values returned by the sys.dm_user_db_resource_governance view act as limits/caps, not as guarantees. 또한 리소스 관리는 특정 저장소 대기 시간을 보장 하지 않습니다.Further, resource governance doesn't guarantee any specific storage latency. 지정 된 사용자 작업에 대해 가장 적합 한 대기 시간, IOPS 및 처리량은 IO 리소스 거 버 넌 스 제한 뿐만 아니라 사용 되는 IO 크기와 기본 저장소의 기능에 따라 달라 집니다.The best achievable latency, IOPS, and throughput for a given user workload depend not only on IO resource governance limits, but also on the mix of IO sizes used, and on the capabilities of the underlying storage. SQL Database는 512 KB와 4mb 사이의 크기를 변경 하는 IOs를 사용 합니다.SQL Database uses IOs that vary in size between 512 KB and 4 MB. IOPS 제한을 적용 하기 위해 모든 IO는 크기와 관계 없이 사용 되며 데이터 파일이 있는 데이터베이스는 Azure Storage에서 제외 됩니다.For the purposes of enforcing IOPS limits, every IO is accounted regardless of its size, with the exception of databases with data files in Azure Storage. 이 경우 256 KB 보다 큰 IOs는 Azure Storage IO 계정에 맞게 여러 256 KB IOs로 계산 됩니다.In that case, IOs larger than 256 KB are accounted as multiple 256-KB IOs, to align with Azure Storage IO accounting.

Azure Storage의 데이터 파일을 사용 하는 기본, 표준 및 범용 데이터베이스의 경우 primary_group_max_io 데이터베이스에 누적 된 IOPS 수를 제공 하는 충분 한 데이터 파일이 없거나, 데이터가 파일에 균등 하 게 분산 되지 않거나, 기본 blob의 성능 계층이 리소스 관리 제한 보다 낮은 IOPS/처리량을 제한 하는 경우 값을 달성할 수 없습니다.For Basic, Standard, and General Purpose databases, which use data files in Azure Storage, the primary_group_max_io value may not be achievable if a database doesn't have enough data files to cumulatively provide this number of IOPS, or if data isn't distributed evenly across files, or if the performance tier of underlying blobs limits IOPS/throughput below the resource governance limits. 마찬가지로 빈번한 트랜잭션 커밋에 의해 생성 된 작은 로그 Io를 사용 하는 경우 primary_max_log_rate 기본 Azure Storage blob에 대 한 IOPS 제한으로 인해 작업에서 값을 달성 하지 못할 수 있습니다.Similarly, with small log IOs generated by frequent transaction commits, the primary_max_log_rate value may not be achievable by a workload due to the IOPS limit on the underlying Azure Storage blob. Azure Premium Storage Azure SQL Database을 사용 하는 데이터베이스의 경우 데이터베이스 크기에 관계 없이 충분히 큰 저장소 blob을 사용 하 여 필요한 IOPS/처리량을 얻습니다.For databases using Azure Premium Storage, Azure SQL Database uses sufficiently large storage blobs to obtain needed IOPS/throughput, regardless of database size. 큰 데이터베이스의 경우 총 IOPS/처리량 용량을 늘리기 위해 여러 데이터 파일이 생성 됩니다.For larger databases, multiple data files are created to increase total IOPS/throughput capacity.

및와 같은 리소스 사용률 avg_data_io_percentavg_log_write_percentsys.dm_db_resource_stats, sys.resource_statssys.elastic_pool_resource_stats 뷰에 보고 되며, 리소스 관리의 최대 한도의 백분율로 계산 됩니다.Resource utilization values such as avg_data_io_percent and avg_log_write_percent, reported in the sys.dm_db_resource_stats, sys.resource_stats, and sys.elastic_pool_resource_stats views, are calculated as percentages of maximum resource governance limits. 따라서 리소스 관리 외의 요소가 IOPS/처리량을 제한 하는 경우 보고 된 리소스 사용률이 100% 미만으로 유지 되는 경우에도 워크 로드 수가 늘어나면 IOPS/처리량을 평면화 하 고 대기 시간을 늘릴 수 있습니다.Therefore, when factors other than resource governance limit IOPS/throughput, it's possible to see IOPS/throughput flattening out and latencies increasing as the workload increases, even though reported resource utilization remains below 100%.

데이터베이스 파일당 읽기 및 쓰기 IOPS, 처리량 및 대기 시간을 확인 하려면 sys.dm_io_virtual_file_stats () 함수를 사용 합니다.To see read and write IOPS, throughput, and latency per database file, use the sys.dm_io_virtual_file_stats() function. 이 함수는 고려 되지 않는 백그라운드 IO를 비롯 하 여 데이터베이스에 대 한 모든 IO를 표시 avg_data_io_percent 하지만 기본 저장소의 IOPS 및 처리량을 사용 하며 관찰 된 저장소 대기 시간에 영향을 줄 수 있습니다.This function surfaces all IO against the database, including background IO that isn't accounted towards avg_data_io_percent, but uses IOPS and throughput of the underlying storage, and can impact observed storage latency. 함수는 및 열에서 각각 읽기 및 쓰기에 대 한 IO 리소스 관리에 의해 도입 될 수 있는 추가 대기 시간을 표시 합니다 io_stall_queued_read_ms io_stall_queued_write_ms .The function surfaces additional latency that may be introduced by IO resource governance for reads and writes, in the io_stall_queued_read_ms and io_stall_queued_write_ms columns respectively.

트랜잭션 로그 요금 거 버 넌 스Transaction log rate governance

트랜잭션 로그 속도 거 버 넌 스는 대량 삽입, SELECT INTO 및 인덱스 빌드와 같은 워크 로드에 대 한 높은 수집 속도를 제한 하는 데 사용 되는 Azure SQL Database의 프로세스입니다.Transaction log rate governance is a process in Azure SQL Database used to limit high ingestion rates for workloads such as bulk insert, SELECT INTO, and index builds. 이러한 한도는 초이 수준에서 로그 레코드 생성 속도까지 추적 되 고 적용 되며, 데이터 파일에 대해 실행할 수 있는 IOs 수에 관계 없이 처리량이 제한 됩니다.These limits are tracked and enforced at the subsecond level to the rate of log record generation, limiting throughput regardless of how many IOs may be issued against data files. 현재 트랜잭션 로그 생성 속도는 하드웨어에 종속 된 지점까지 선형적으로 확장 되며 vCore 구매 모델을 사용 하 여 최대 로그 속도는 96 m b/초까지 허용 됩니다.Transaction log generation rates currently scale linearly up to a point that is hardware-dependent, with the maximum log rate allowed being 96 MB/s with the vCore purchasing model.

참고

실제 실제 Io 트랜잭션 로그 파일은 제어 되거나 제한 되지 않습니다.The actual physical IOs to transaction log files are not governed or limited.

로그 속도는 다양 한 시나리오에서 달성 하 고 유지할 수 있도록 설정 되며, 전체 시스템은 사용자 부하에 대 한 영향이 최소화 된 기능을 유지할 수 있습니다.Log rates are set such that they can be achieved and sustained in a variety of scenarios, while the overall system can maintain its functionality with minimized impact to the user load. 로그 전송률 관리는 트랜잭션 로그 백업이 게시 된 복구 가능성 Sla 내에 유지 되도록 합니다.Log rate governance ensures that transaction log backups stay within published recoverability SLAs. 이 거 버 넌 스는 또한 보조 복제본의 과도 한 백로그를 방지 합니다.This governance also prevents an excessive backlog on secondary replicas.

로그 레코드가 생성 되 면 각 작업이 평가 되 고, 최대 원하는 로그 전송률 (초당 MB/s)을 유지 하기 위해 지연 되어야 하는지 여부가 평가 됩니다.As log records are generated, each operation is evaluated and assessed for whether it should be delayed in order to maintain a maximum desired log rate (MB/s per second). 로그 레코드가 저장소에 플러시될 때 지연 시간이 추가 되지 않고 로그 속도가 자동으로 생성 되는 동안 로그 속도가 적용 됩니다.The delays aren't added when the log records are flushed to storage, rather log rate governance is applied during log rate generation itself.

런타임에 적용 되는 실제 로그 생성 요금은 피드백 메커니즘의 영향을 받을 수 있으므로 시스템이 안정화 될 수 있도록 허용 가능한 로그 비율을 일시적으로 줄일 수 있습니다.The actual log generation rates imposed at run time may also be influenced by feedback mechanisms, temporarily reducing the allowable log rates so the system can stabilize. 로그 파일 공간 관리를 사용 하 여 로그 공간 부족 상태를 방지 하 고 가용성 그룹 복제 메커니즘을 통해 전체 시스템 제한을 일시적으로 낮출 수 있습니다.Log file space management, avoiding running into out of log space conditions and Availability Group replication mechanisms can temporarily decrease the overall system limits.

로그 전송률 관리자 트래픽 셰이핑은 다음 대기 유형 ( sys.dm_exec_requestssys.dm_os_wait_stats 뷰에 노출 됨)을 통해 표시 됩니다.Log rate governor traffic shaping is surfaced via the following wait types (exposed in the sys.dm_exec_requests and sys.dm_os_wait_stats views):

대기 유형Wait Type 참고Notes
LOG_RATE_GOVERNORLOG_RATE_GOVERNOR 데이터베이스 제한Database limiting
POOL_LOG_RATE_GOVERNORPOOL_LOG_RATE_GOVERNOR 풀 제한Pool limiting
INSTANCE_LOG_RATE_GOVERNORINSTANCE_LOG_RATE_GOVERNOR 인스턴스 수준 제한Instance level limiting
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZEHADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE 피드백 컨트롤, 가용성 그룹 프리미엄/중요 비즈니스용의 물리적 복제를 유지 하지 않음Feedback control, availability group physical replication in Premium/Business Critical not keeping up
HADR_THROTTLE_LOG_RATE_LOG_SIZEHADR_THROTTLE_LOG_RATE_LOG_SIZE 로그 공간 부족 상태를 방지 하기 위해 사용자 의견 제어, 속도 제한Feedback control, limiting rates to avoid an out of log space condition
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLOHADR_THROTTLE_LOG_RATE_MISMATCHED_SLO 지리적 복제 피드백 제어, 로그 빈도를 제한 하 여 데이터 대기 시간이 높고 지역 보조 복제본이 사용 되지 않도록 합니다.Geo-replication feedback control, limiting log rate to avoid high data latency and unavailability of geo-secondaries

원하는 확장성을 hampering 로그 전송률 제한이 발생할 경우 다음 옵션을 고려 하십시오.When encountering a log rate limit that is hampering desired scalability, consider the following options:

  • 최대 96 m b/초 로그 속도를 얻거나 다른 서비스 계층으로 전환 하기 위해 더 높은 서비스 수준으로 확장 합니다.Scale up to a higher service level in order to get the maximum 96 MB/s log rate, or switch to a different service tier. Hyperscale 서비스 계층은 선택한 서비스 수준에 관계 없이 100 m b/초 로그 비율을 제공 합니다.The Hyperscale service tier provides 100 MB/s log rate regardless of chosen service level.
  • 데이터를 로드 하는 경우 ETL 프로세스에서 데이터를 준비 하는 것과 같이 임시 데이터는 tempdb로 로드 될 수 있습니다 (최소 기록 됨).If data being loaded is transient, such as staging data in an ETL process, it can be loaded into tempdb (which is minimally logged).
  • 분석 시나리오의 경우 클러스터형 columnstore 대상 테이블로 로드 합니다.For analytic scenarios, load into a clustered columnstore covered table. 이렇게 하면 압축으로 인해 필요한 로그 전송률이 줄어듭니다.This reduces the required log rate due to compression. 이 기법은 CPU 사용률을 높이고 클러스터형 columnstore 인덱스를 활용 하는 데이터 집합에만 적용 됩니다.This technique does increase CPU utilization and is only applicable to data sets that benefit from clustered columnstore indexes.

저장소 공간 관리Storage space governance

프리미엄 및 중요 비즈니스용 서비스 계층에서 데이터 및 트랜잭션 로그 파일은 데이터베이스 또는 탄력적 풀을 호스트 하는 컴퓨터의 로컬 SSD 볼륨에 저장 됩니다.In Premium and Business Critical service tiers, data and transaction log files are stored on the local SSD volume of the machine hosting the database or elastic pool. 높은 IOPS 및 처리량을 제공 하 고 IO 대기 시간을 낮게 제공 합니다.This provides high IOPS and throughput, and low IO latency. 이 로컬 볼륨의 크기는 하드웨어 기능에 따라 다르며 유한 합니다.The size of this local volume depends on hardware capabilities, and is finite. 지정 된 컴퓨터에서 tempdb , 운영 체제, 관리 소프트웨어, 모니터링 데이터, 로그 등을 비롯 한 고객 데이터베이스에서 로컬 볼륨 공간을 사용 합니다. 데이터베이스를 만들고 삭제 하 고 공간 사용량을 늘리거나 줄일 때 컴퓨터의 로컬 공간 소비는 시간이 지남에 따라 변동 됩니다.On a given machine, local volume space is consumed by customer databases including tempdb, the operating system, management software, monitoring data, logs, etc. As databases are created, deleted, and increase/decrease their space usage, local space consumption on a machine fluctuates over time.

시스템에서 컴퓨터의 사용 가능한 공간이 부족 하 고 데이터베이스 또는 탄력적 풀의 공간이 부족 한 것으로 감지 되 면 데이터베이스 또는 탄력적 풀을 사용 가능한 공간이 충분 한 다른 컴퓨터로 이동 하 여 구성 된 서비스 목표의 최대 크기 제한까지 늘릴 수 있습니다.If the system detects that available free space on a machine is low and a database or elastic pool is at risk of running out of space, it will move the database or elastic pool to a different machine with sufficient free space, allowing growth up to maximum size limits of the configured service objective. 이러한 이동은 데이터베이스 크기 조정 작업과 마찬가지로 온라인 방식으로 발생 하며, 작업 끝에 짧은 (초) 장애 조치 (failover)를 포함 하 여 유사한 영향을 줍니다.This move occurs in an online fashion, similarly to a database scaling operation, and has a similar impact, including a short (seconds) failover at the end of the operation. 이 장애 조치 (failover)는 열려 있는 연결을 종료 하 고 트랜잭션을 롤백합니다. 이때 데이터베이스를 사용 하는 응용 프로그램에 영향을 줄 수This failover terminates open connections and rolls back transactions, potentially impacting applications using the database at that time.

데이터는 물리적으로 다른 컴퓨터로 복사 되기 때문에 더 큰 데이터베이스를 이동 하려면 상당한 시간이 필요할 수 있습니다.Because data is physically copied to a different machine, moving larger databases may require a substantial amount of time. 이 시간 동안 큰 사용자 데이터베이스 또는 탄력적 풀의 로컬 공간 사용 또는 데이터베이스에 의해 tempdb 매우 빠르게 증가 하는 경우 공간이 부족 해질 위험이 증가 합니다.During that time, if local space consumption by a large user database or elastic pool, or by the tempdb database grows very rapidly, the risk of running out of space increases. 시스템이 공간 부족 오류를 방지 하 고 불필요 한 장애 조치 (failover)를 방지 하기 위해 분산 된 방식으로 데이터베이스 이동을 시작 합니다.The system initiates database movement in a balanced fashion to prevent out-of-space errors and to avoid unnecessary failovers.

다음 단계Next steps