この記事では、単一データベースとエラスティック プールを管理する 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.
サーバーあたりの最大プール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.
マスター データベースに対して実行するクエリの待機時間が増えます。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.
データベースまたエラスティック プールのコンピューティング サイズを上げて、より多くのコンピューティング リソースをデータベースに提供します。Increasing the compute size of the database or elastic pool to provide the database with more compute resources. シングルトンのリソースの拡大縮小に関する記事と、エラスティック プールのリソースの拡大縮小に関する記事を参照してください。See Scale single database resources and Scale elastic pool resources.
クエリを最適化して、各クエリのリソース使用率を引き下げます。Optimizing queries to reduce the resource utilization of each query. 詳しくは、「クエリの調整とヒント」をご覧ください。For more information, see Query Tuning/Hinting.
使用済みのデータベース容量が最大サイズの上限に達すると、データのサイズが増えるデータベースの挿入および更新は失敗し、クライアントはエラー メッセージを受け取ります。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.
データベースまたはエラスティック プールの最大サイズを増やすか、より多くの記憶域を追加します。Increasing the max size of the database or elastic pool, or add more storage. シングルトンのリソースの拡大縮小に関する記事と、エラスティック プールのリソースの拡大縮小に関する記事を参照してください。See Scale single database resources and Scale elastic pool resources.
データベースがエラスティック プール内にある場合は、もう 1 つの方法として、データベースをプールの外に移動し、ストレージ領域が他のデータベースと共有されないようにすることもできます。If the database is in an elastic pool, then alternatively the database can be moved outside of the pool so that its storage space is not shared with other databases.
セッションおよびワーカーの最大数は、サービス レベルとコンピューティング サイズ (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.
データベースまたはエラスティック プールのサービス レベルまたはコンピューティング サイズを高くします。Increasing the service tier or compute size of the database or elastic pool. シングルトンのリソースの拡大縮小に関する記事と、エラスティック プールのリソースの拡大縮小に関する記事を参照してください。See Scale single database resources and Scale elastic pool resources.
ワーカー使用率上昇の原因がコンピューティング リソースの競合である場合は、クエリを最適化して各クエリのリソース使用率を下げます。Optimizing queries to reduce the resource utilization of each query if the cause of increased worker utilization is due to contention for compute resources. 詳しくは、「クエリの調整とヒント」をご覧ください。For more information, see Query Tuning/Hinting.
トランザクション ログ速度ガバナンスは、一括挿入、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. 現在、トランザクション ログ生成速度は、ハードウェアに依存するポイントまで直線的にスケールアップされます。許容される最大ログ速度は、仮想コア購入モデルで 48 MB/秒です。Transaction log generation rates currently scale linearly up to a point that is hardware dependent, with the maximum log rate allowed being 48 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.
最大 48 MB/秒のログ速度を実現するために、より大きなレベルにスケールアップします。Scale up to a larger tier in order to get the maximum 48 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.
DTU と eDTU については、「データベース トランザクション ユニット (DTU) とエラスティック データベース トランザクション ユニット (eDTU) の説明」をご覧ください。For information about DTUs and eDTUs, see DTUs and eDTUs.
tempdb のサイズ制限については、「SQL Database の Tempdb データベース」をご覧ください。For information about tempdb size limits, see TempDB in Azure SQL Database.