Azure SQL Database サーバーの SQL Database リソース制限SQL Database resource limits for Azure SQL Database server

この記事では、単一データベースとエラスティック プールを管理する 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 also provides information regarding what happens when those resource limits are hit or exceeded.

注意

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

最大リソース制限Maximum resource limits

ResourceResource 制限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.

データベース リソースが制限に達したときの影響What happens when database resource limits are reached

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

(DTU と、eDTU または vCores によって測定された) データベース コンピューティングの使用率が高くなると、クエリの待機時間が増加し、タイムアウトすることさえあります。このような状況下では、クエリはサービスによってキューに格納されることがあり、リソースが空くと実行用のリソースを提供されます。When database compute utilization (measured by DTUs and eDTUs, or vCores) becomes high, query latency increases and can even time out. Under these conditions, queries may be queued by the service and are provided resources for execution as resource 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. データベースの SELECTS と DELETES は引き続き成功します。Database SELECTS and DELETES 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 and eDTUs). セッションまたはワーカーが上限に達した場合、新しい要求は拒否され、クライアントはエラー メッセージを受け取ります。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.

セッションまたはワーカーの使用率が高い場合は、次のような軽減オプションがあります。When encountering high session or worker utilization, mitigation options include:

トランザクション ログ速度ガバナンス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 sub-second 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
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 フィードバック制御、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 larger tier in order to get the maximum 96 MB/s log rate.
  • 読み込まれるデータが一時的なデータである場合、つまり、ETL プロセスでのステージング データである場合は、tempdb に読み込むことができます (この場合、ログ記録が最小限に抑えられます)。If data being loaded is transient, i.e. 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