SQL Database のリソース制限およびリソース管理SQL Database resource limits and resource governance

この記事では、単一データベースとエラスティック プールを管理する SQL Database サーバーの SQL Database リソース制限について概要を示します。This article provides an overview of the SQL Database resource limits for a SQL Database server that manages single databases and elastic pools. リソース制限が上限に達するか、または超過した場合の動作に関する情報を示すと共に、これらの制限の適用に利用されるリソース管理のメカニズムについて説明します。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.


Managed Instance の制限については、マネージド インスタンスに関する SQL Database のリソース制限に関するページを参照してください。For Managed Instance limits, see SQL Database resource limits for managed instances.

最大リソース制限Maximum resource limits

リソースResource 制限Limit
サーバーあたりのデータベース数Databases per server 50005000
任意のリージョンにおけるサブスクリプションあたりの既定のサーバー数Default number of servers per subscription in any region 2020
任意のリージョンにおけるサブスクリプションあたりの最大サーバー数Max number of servers per subscription in any region 200200
サーバーあたりの DTU/eDTU クォータDTU / eDTU quota per server 54,00054,000
サーバー/インスタンスあたりの仮想コア クォータvCore quota per server/instance 540540
サーバーあたりの最大プールMax pools per server DTU または仮想コアの数によって制限されます。Limited by number of DTUs or vCores. たとえば、各プールが 1000 DTU の場合、1 つのサーバーで 54 プールをサポートできます。For example, if each pool is 1000 DTUs, then a server can support 54 pools.


既定量よりも多い DTU/eDTU クォータ、仮想コア クォータ、またはサーバーを取得する場合は、Azure portal 上でサブスクリプションに対する発行の種類を "クォータ として、新しいサポート リクエストを送信できます。To obtain more DTU/eDTU quota, vCore quota, or more servers than the default amount, a new support request can be submitted in the Azure portal for the subscription with issue type “Quota”. サーバーあたりの DTU/eDTU クォータとデータベース制限には、サーバーあたりのエラスティック プールの数が含まれます。The DTU/eDTU quota and database limit per server constrains the number of elastic pools per server.


データベースの数が SQL Database サーバーあたりの制限に近づくと、次の状況が発生します。As the number of databases approaches the limit per SQL Database 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.

ストレージ サイズStorage size

単一データベースのリソースのストレージ サイズについては、DTU ベースのリソース制限に関するページ、または価格レベルごとのストレージ サイズ制限についての仮想コア ベースのリソース制限に関するページのいずれかを参照してください。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

コンピューティング (DTU と eDTU/vCores)Compute (DTUs and eDTUs / vCores)

(DTU および eDTU または仮想コアによって測定された) データベース コンピューティングの使用率が高くなると、クエリの待機時間が増加し、そのクエリがタイムアウトすることもあります。このような状況下では、クエリはサービスによってキューに格納される場合があり、リソースが空くと実行用のリソースが提供されます。When database compute utilization (measured by DTUs and eDTUs, or vCores) 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:


使用済みのデータベース容量が最大サイズの上限に達すると、データのサイズが増えるデータベースの挿入および更新は失敗し、クライアントはエラー メッセージを受け取ります。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:

セッションとワーカー (要求)Sessions and workers (requests)

セッションおよびワーカーの最大数は、サービス レベルとコンピューティング サイズ (DTU/eDTU または仮想コア) によって決まります。The maximum number 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:

リソース管理Resource governance

Azure SQL Database では、リソース制限を適用するために、SQL Server Resource Governor に基づいたリソース管理の実装を利用します。Azure 上で SQL Server データベース サービスを実行するために、修正や拡張が行われます。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 a SQL Server database service in Azure. サービス内の各 SQL Server インスタンス上には、複数のリソース プールおよびワークロード グループがあり、プール レベルおよびグループ レベル両方でリソース制限が設定され、均衡の取れた Database-as-a-Service が提供されています。On each SQL Server instance in the service, there are multiple resource pools and workload groups, with resource limits set at both pool and group levels to provide a balanced Database-as-a-Service. ユーザー ワークロードと内部ワークロードは、別々のリソース プールとワークロード グループに分類されます。User workload and internal workloads are classified into separate resource pools and workload groups. プライマリ レプリカおよび読み取り可能なセカンダリ レプリカ (geo レプリカを含む) のユーザー ワークロードは、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 Server プロセス内でリソースを管理するだけでなく、Azure SQL Database ではプロセス レベルのリソース管理用に Windows Job Objects、また、ストレージ クォータ管理用に Windows ファイル サーバー リソース マネージャー (FSRM) も使用します。In addition to using Resource Governor to govern resources within the SQL Server 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 を使用して OS レベルとストレージ ボリューム レベルで適用され、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 に適用されます。一方、リソース プールの制限は、tempdb データベースを含め、同じ SQL Server インスタンス上のすべてのデータベースに対するすべてのストレージ IO に適用されます。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 SQL Server instance, 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. しかし、同じ SQL Server インスタンス上の複数のデータベースに対して組み合わされたワークロードによって、プールの制限に到達する場合があります。However, pool limits may be reached by the combined workload against multiple databases on the same SQL Server instance.

たとえば、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 will not 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 およびスループットの最小値および最大値は、保証としてではなく、制限/上限として機能します。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 does not 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 Server で使用される IO のサイズは、512 KB から 4 MB の間で変動します。SQL Server uses IOs that vary in size between 512 KB and 4 MB. IOPS 制限の適用という目的のために、Azure Storage 内でデータ ファイルを備えるデータベースに例外が発生した場合は、サイズに関係なくどの IO も考慮されます。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. その場合、Azure Storage IO の説明に従って、256 KB より大規模な IO は、複数の 256 KB の IO として考慮されます。In that case, IOs larger than 256 KB are accounted as multiple 256 KB IOs, to align with Azure Storage IO accounting.

Azure Storage 内のデータ ファイルを使用する Basic、Standard、General Purpose データベースでは、IOPS のこの数値を累積的に提供できる十分なデータ ファイルがデータベースにない場合、データがファイルにわたって均等に分散されていない場合、または、基本となる BLOB のパフォーマンス レベルによってリソース管理の制限より下に IOPS/スループットが制限されている場合、primary_group_max_io 値には到達することはありません。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 does not have enough data files to cumulatively provide this number of IOPS, or if data is not distributed evenly across files, or if the performance tier of underlying blobs limits IOPS/throughput below the resource governance limit. 同様に、頻繁なトランザクション コミットによって生成された小規模なログ IO では、基になる Azure ストレージ BLOB 上の IOPS 制限があるため、ワークロードによって primary_max_log_rate 値に到達することはありません。Similarly, with small log IOs generated by frequent transaction commit, the primary_max_log_rate value may not be achievable by a workload due to the IOPS limit on the underlying Azure storage blob.

sys.dm_db_resource_statssys.resource_statssys.elastic_pool_resource_stats ビュー上で報告される avg_data_io_percent および avg_log_write_percent などのリソース使用率の値は、リソース管理の上限の割合として計算されています。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 is 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. この関数では、avg_data_io_percent に対しては考慮されないバックグラウンド IO を含む、データベースに対するすべての IO が網羅されますが、基になるストレージの IOPS とスループットが使用され、監視されているストレージの待機時間に影響を及ぼす可能性があります。This function surfaces all IO against the database, including background IO that is not 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 also 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. こうした制限は追跡され、1 秒未満のレベルでログ レコード生成速度に適用されて、データ ファイルに対して発行できる IO の数に関係なく、スループットが制限されます。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. 現在、トランザクション ログ生成速度は、ハードウェアに依存するポイントまで直線的にスケールアップされます。許容される最大ログ速度は、仮想コア購入モデルで 96 MB/秒です。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/秒) を維持するために遅延する必要があるかどうかが判断されます。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 are not 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_db_wait_stats DMV で公開されます)。Log rate governor traffic shaping is surfaced via the following wait types (exposed in the sys.dm_db_wait_stats DMV):

待機の種類Wait Type メモNotes
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZEHADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE フィードバック制御、Premium/Business Critical での可用性グループの物理的なレプリケーションが維持されていない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

望ましいスケーラビリティを損なうログ速度制限が発生した場合は、次のオプションを検討してください。When encountering a log rate limit that is hampering desired scalability, consider the following options:

  • 最大 96 MB/秒のログ速度を実現するために、より高いサービス レベルにスケールアップします。Scale up to a higher service level in order to get the maximum 96 MB/s log rate.
  • 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).
  • 分析シナリオでは、クラスター化列ストアの対象テーブルに読み込みます。For analytic scenarios, load into a clustered columnstore covered table. この場合は圧縮されるため、必要なログ速度が小さくなります。This reduces the required log rate due to compression. この手法では CPU 使用率が増加し、クラスター化列ストア インデックスからメリットを得られるデータ セットにのみ適用できます。This technique does increase CPU utilization and is only applicable to data sets that benefit from clustered columnstore indexes.

次のステップNext steps