Azure SQL Database サーバーレスAzure SQL Database serverless

適用対象: Azure SQL Database

サーバーレスは、ワークロードの需要に基づいてコンピューティングが自動的にスケーリングされ、1 秒あたりのコンピューティング使用量に対して請求される、Azure SQL Database の単一データベース用のコンピューティング レベルです。Serverless is a compute tier for single databases in Azure SQL Database that automatically scales compute based on workload demand and bills for the amount of compute used per second. またサーバーレス コンピューティング レベルでは、アイドル期間にデータベースを自動的に一時停止します。このときはストレージのみに課金され、再びアクティブになると自動的にデータベースが再開されます。The serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns.

サーバーレス コンピューティング レベルServerless compute tier

Azure SQL Database の単一データベースのサーバーレス コンピューティング レベルは、コンピューティングの自動スケーリング範囲と自動一時停止遅延でパラメーター化されます。The serverless compute tier for single databases in Azure SQL Database is parameterized by a compute autoscaling range and an autopause delay. これらのパラメーターの構成によって、データベース パフォーマンス エクスペリエンスとコンピューティング コストが決まります。The configuration of these parameters shapes the database performance experience and compute cost.

サーバーレスの請求

パフォーマンス構成Performance configuration

  • 最小仮想コア最大仮想コア は、データベースに使用可能なコンピューティング容量の範囲を定義する構成可能なパラメーターです。The minimum vCores and maximum vCores are configurable parameters that define the range of compute capacity available for the database. メモリと IO の上限は、指定された仮想コアの範囲に比例します。Memory and IO limits are proportional to the vCore range specified.
  • 自動一時停止遅延 は、データベースが自動的に一時停止するために必要な非アクティブ期間を定義する構成可能なパラメーターです。The autopause delay is a configurable parameter that defines the period of time the database must be inactive before it is automatically paused. 次のログインまたはその他のアクティビティが発生すると、データベースは自動的に再開されます。The database is automatically resumed when the next login or other activity occurs. 自動一時停止を無効にすることもできます。Alternatively, autopausing can be disabled.

コストCost

  • サーバーレス データベースのコストは、コンピューティング コストとストレージ コストの合計です。The cost for a serverless database is the summation of the compute cost and storage cost.
  • コンピューティングの使用量が構成された最小制限と最大制限の間にある場合、コンピューティング コストは仮想コアとメモリの使用に基づきます。When compute usage is between the min and max limits configured, the compute cost is based on vCore and memory used.
  • コンピューティングの使用量が構成された最小制限を下回っている場合、コンピューティング コストは、構成された最小仮想コア数と最小メモリに基づきます。When compute usage is below the min limits configured, the compute cost is based on the min vCores and min memory configured.
  • データベースが一時停止すると、コンピューティング コストはゼロになり、ストレージ コストのみが発生します。When the database is paused, the compute cost is zero and only storage costs are incurred.
  • ストレージ コストは、プロビジョニングされたコンピューティング レベルと同じ方法で決定されます。The storage cost is determined in the same way as in the provisioned compute tier.

より詳細なコストについては、課金に関する項目を参照してください。For more cost details, see Billing.

シナリオScenarios

サーバーレスは、アイドル使用期間後のコンピューティング ウォームアップにおいてある程度の遅延を許容できる一時的な予測できない使用パターンの単一データベースに対して価格とパフォーマンスが最適化されています。Serverless is price-performance optimized for single databases with intermittent, unpredictable usage patterns that can afford some delay in compute warm-up after idle usage periods. これに対し、プロビジョニング済みコンピューティング レベルは、コンピューティング ウォームアップの遅延を許容できない平均的に使用量が多いエラスティック プール内の単一データベースまたは複数のデータベースに対して価格とパフォーマンスが最適化されています。In contrast, the provisioned compute tier is price-performance optimized for single databases or multiple databases in elastic pools with higher average usage that cannot afford any delay in compute warm-up.

サーバーレス コンピューティングに最適なシナリオScenarios well-suited for serverless compute

  • 間欠的で予測できない使用パターンの単一データベースで、長期にわたってアクティブではない期間と平均コンピューティング使用率が低い期間が散在している場合。Single databases with intermittent, unpredictable usage patterns interspersed with periods of inactivity and lower average compute utilization over time.
  • 頻繁に再スケールされるプロビジョニング済みコンピューティング レベル内の単一データベースと、コンピューティングの再スケールをサービスに委任することを好むお客様。Single databases in the provisioned compute tier that are frequently rescaled and customers who prefer to delegate compute rescaling to the service.
  • SQL Database へのデプロイ前にコンピューティング サイズを見積もることが困難か不可能な、使用履歴のない新しい単一データベース。New single databases without usage history where compute sizing is difficult or not possible to estimate prior to deployment in SQL Database.

プロビジョニング済みコンピューティングに最適なシナリオScenarios well-suited for provisioned compute

  • より定期的で予測できる使用パターンを持ち、長期にわたって平均コンピューティング使用率が高い単一データベース。Single databases with more regular, predictable usage patterns and higher average compute utilization over time.
  • 頻繁なメモリ トリミングまたは一時停止状態からの自動再開での遅延によるパフォーマンスのトレードオフを許容できないデータベース。Databases that cannot tolerate performance trade-offs resulting from more frequent memory trimming or delay in autoresuming from a paused state.
  • 価格とパフォーマンスの最適化向上のためにエラスティック プールに統合できる、間欠的な予測できない使用パターンを持つ複数のデータベース。Multiple databases with intermittent, unpredictable usage patterns that can be consolidated into elastic pools for better price-performance optimization.

プロビジョニング済みコンピューティング レベルとの比較Comparison with provisioned compute tier

次の表は、サーバーレス コンピューティング レベルとプロビジョニング済みコンピューティング レベル間の違いをまとめたものです。The following table summarizes distinctions between the serverless compute tier and the provisioned compute tier:

サーバーレス コンピューティングServerless compute プロビジョニング済みコンピューティングProvisioned compute
データベースの使用パターンDatabase usage pattern 長期にわたって平均コンピューティング使用率が低い、間欠的で予測できない使用状況。Intermittent, unpredictable usage with lower average compute utilization over time. 長期間にわたって平均コンピューティング使用率が高い、より定期的な使用パターン、またはエラスティック プールを使用する複数のデータベース。More regular usage patterns with higher average compute utilization over time, or multiple databases using elastic pools.
パフォーマンス管理作業Performance management effort Lower Higher
コンピューティングのスケーリングCompute scaling 自動Automatic マニュアルManual
コンピューティングの応答性Compute responsiveness 非アクティブな期間の後は低いLower after inactive periods 即時Immediate
請求の最小単位Billing granularity 1 秒あたりPer second 1 時間あたりPer hour

購入モデルとサービス レベルPurchasing model and service tier

SQL Database サーバーレスは、現在、仮想コア購入モデルの第 5 世代ハードウェアの General Purpose レベルでのみサポートされます。SQL Database serverless is currently only supported in the General Purpose tier on Generation 5 hardware in the vCore purchasing model.

自動スケールAutoscaling

スケーリング応答性Scaling responsiveness

一般に、サーバーレス データベースは、リソースの需要を満たすために十分な容量を備え、最大仮想コア値によって設定される制限内で要求されたどのようなコンピューティング量に対しても中断することのないコンピューター上で実行されます。In general, serverless databases are run on a machine with sufficient capacity to satisfy resource demand without interruption for any amount of compute requested within limits set by the max vCores value. 場合によっては、コンピューターが数分以内にリソースの需要を満たすことができない場合、自動的に負荷分散が行われることがあります。Occasionally, load balancing automatically occurs if the machine is unable to satisfy resource demand within a few minutes. たとえば、リソースの需要が 4 個の仮想コアであるが、利用できる仮想コアが2 個のみの場合は、4 個の仮想コアが提供される前の負荷分散に数分かかる可能性があります。For example, if the resource demand is 4 vCores, but only 2 vCores are available, then it may take up to a few minutes to load balance before 4 vCores are provided. データベースは、接続が切断されるときの操作の最後の短時間を除き、負荷分散の間オンライン状態を維持します。The database remains online during load balancing except for a brief period at the end of the operation when connections are dropped.

メモリ管理Memory management

サーバーレス データベースのメモリは、プロビジョニング済みコンピューティング データベースより頻繁に回収されます。Memory for serverless databases is reclaimed more frequently than for provisioned compute databases. この動作は、サーバーレスでのコストを管理するために重要で、パフォーマンスに影響を及ぼすことがあります。This behavior is important to control costs in serverless and can impact performance.

キャッシュの再利用Cache reclamation

プロビジョニング済みコンピューティング データベースとは異なり、CPU またはアクティブなキャッシュの使用率が低いとき、SQL キャッシュからのメモリはサーバーレス データベースから回収されます。Unlike provisioned compute databases, memory from the SQL cache is reclaimed from a serverless database when CPU or active cache utilization is low.

  • 最近使用したキャッシュ エントリの合計サイズが一定期間しきい値を下回ると、アクティブなキャッシュの使用率が低いと見なされます。Active cache utilization is considered low when the total size of the most recently used cache entries falls below a threshold for a period of time.
  • キャッシュの回収がトリガーされると、ターゲットのキャッシュ サイズは段階的に減少して前のサイズよりも少なくなります。回収は、使用率が低い状態が続く場合にのみ続行されます。When cache reclamation is triggered, the target cache size is reduced incrementally to a fraction of its previous size and reclaiming only continues if usage remains low.
  • キャッシュの回収が発生している場合、削除するキャッシュ エントリの選択ポリシーは、メモリ負荷が高いときのプロビジョニングされたコンピューティング データベースの選択ポリシーと同じです。When cache reclamation occurs, the policy for selecting cache entries to evict is the same selection policy as for provisioned compute databases when memory pressure is high.
  • キャッシュ サイズは、構成可能な最小仮想コアで定義されている最小メモリ制限よりも小さくなることはありません。The cache size is never reduced below the min memory limit as defined by min vCores which can be configured.

サーバーレス コンピューティング データベースとプロビジョニング済みコンピューティング データベースの両方で、使用可能なメモリがすべて使用されている場合、キャッシュ エントリを削除できます。In both serverless and provisioned compute databases, cache entries may be evicted if all available memory is used.

CPU 使用率が低い場合、使用パターンによってはアクティブなキャッシュの使用率が高いままになり、メモリの再利用が妨げられる可能性があることに注意してください。Note that when CPU utilization is low, active cache utilization can remain high depending on the usage pattern and prevent memory reclamation. また、以前のユーザー アクティビティに定期的なバックグラウンド プロセスが応答するために、ユーザー アクティビティが停止した後、メモリが再利用される前に、遅延時間が追加で発生する可能性があります。Also, there can be additional delay after user activity stops before memory reclamation occurs due to periodic background processes responding to prior user activity. たとえば、削除対象としてマークされるゴースト レコードは、削除操作と QDS クリーンアップ タスクによって生成されますが、キャッシュへのデータ ページの読み取りを伴うゴースト クリーンアップ プロセスが実行されるまで、物理的には削除されません。For example, delete operations and QDS cleanup tasks generate ghost records that are marked for deletion, but are not physically deleted until the ghost cleanup process runs which can involve reading data pages into cache.

キャッシュのハイドレーションCache hydration

データがディスクからフェッチされると、SQL キャッシュは、プロビジョニング済みデータベースと同じ方法および速度で拡大します。The SQL cache grows as data is fetched from disk in the same way and with the same speed as for provisioned databases. データベースがビジー状態の場合、キャッシュは、最大メモリ制限に達するまで制約なしで拡大できます。When the database is busy, the cache is allowed to grow unconstrained up to the max memory limit.

自動一時停止と自動再開Autopausing and autoresuming

自動一時停止Autopausing

自動一時停止遅延の期間を通して次のすべての条件が満たされた場合、自動一時停止がトリガーされます。Autopausing is triggered if all of the following conditions are true for the duration of the autopause delay:

  • セッション数 = 0Number sessions = 0
  • ユーザー プールで実行されているユーザー ワークロードの場合は CPU = 0CPU = 0 for user workload running in the user pool

必要な場合に自動一時停止を無効にするオプションが用意されています。An option is provided to disable autopausing if desired.

次の機能では自動一時停止はサポートされていませんが、自動スケールはサポートされています。The following features do not support autopausing, but do support auto-scaling. 次の機能のいずれかが使用されている場合、自動一時停止を無効にする必要があります。データベースは、非アクティブである期間に関係なくオンラインのままとなります。If any of the following features are used, then autopausing should be disabled and the database will remain online regardless of the duration of database inactivity:

  • geo レプリケーション (アクティブ geo レプリケーションと自動フェールオーバー グループ)Geo-replication (active geo-replication and auto-failover groups).
  • 長期的なバックアップ保有期間 (LTR)。Long-term backup retention (LTR).
  • SQL データ同期で使用される同期データベース。同期データベースとは異なり、ハブ データベースとメンバー データベースでは自動一時停止がサポートされています。The sync database used in SQL data sync. Unlike sync databases, hub and member databases support autopausing.
  • DNS エイリアシングDNS aliasing
  • エラスティック ジョブで使用されるジョブ データベース (プレビュー)。The job database used in Elastic Jobs (preview).

データベースをオンラインにする必要がある一部のサービス更新プログラムのデプロイ中は、自動一時停止は一時的に回避されます。Autopausing is temporarily prevented during the deployment of some service updates which require the database be online. このような場合、サービス更新プログラムが完了すると、自動一時停止は再び許可されます。In such cases, autopausing becomes allowed again once the service update completes.

自動再開Autoresuming

次の条件のいずれかに該当した場合は常に、自動再開がトリガーされます。Autoresuming is triggered if any of the following conditions are true at any time:

機能Feature 自動再開トリガーAutoresume trigger
認証と権限承認Authentication and authorization ログインLogin
脅威の検出Threat detection データベース レベルまたはサーバー レベルでの脅威検出の設定の有効化/無効化。Enabling/disabling threat detection settings at the database or server level.
データベース レベルまたはサーバー レベルでの脅威検出の設定の変更。Modifying threat detection settings at the database or server level.
データの検出と分類Data discovery and classification 機密ラベルの追加、変更、削除、表示Adding, modifying, deleting, or viewing sensitivity labels
監査Auditing 監査レコードの表示。Viewing auditing records.
監査ポリシーの更新または表示。Updating or viewing auditing policy.
データ マスクData masking データ マスク ルールの追加、変更、削除、表示Adding, modifying, deleting, or viewing data masking rules
透過的なデータ暗号化Transparent data encryption 透過的データ暗号化の状態またはステータスの表示View state or status of transparent data encryption
脆弱性評価Vulnerability assessment アドホック スキャンと定期的なスキャン (有効な場合)Ad hoc scans and periodic scans if enabled
クエリ (パフォーマンス) データ ストアQuery (performance) data store クエリ ストアの設定の変更または表示Modifying or viewing query store settings
自動調整Autotuning 自動インデックス作成などの自動調整の推奨事項の適用と検証Application and verification of autotuning recommendations such as auto-indexing
データベースのコピーDatabase copying コピーとしてのデータベースの作成。Create database as copy.
BACPAC ファイルへのエクスポート。Export to a BACPAC file.
SQL データ同期SQL data sync 構成可能なスケジュールまたは手動で実行される、ハブとメンバー データベースの間の同期Synchronization between hub and member databases that run on a configurable schedule or are performed manually
特定のデータベース メタデータの変更Modifying certain database metadata 新しいデータベース タグの追加。Adding new database tags.
最大仮想コア数、最小仮想コア数、または自動一時停止遅延の変更。Changing max vCores, min vCores, or autopause delay.
SQL Server Management Studio (SSMS)SQL Server Management Studio (SSMS) 18.1 以前の SSMS バージョンを使用し、サーバーでデータベースの新しいクエリ ウィンドウを開くと、同じサーバーで自動一時停止されていたデータベースが再開します。Using SSMS versions earlier than 18.1 and opening a new query window for any database in the server will resume any auto-paused database in the same server. この動作は、18.1 以降の SSMS バージョンを使用している場合は発生しません。This behavior does not occur if using SSMS version 18.1 or later.

監視、管理、または上記のいずれかの操作を実行するその他のソリューションでは、自動再開がトリガーされます。Monitoring, management, or other solutions performing any of the operations listed above will trigger auto-resuming.

データベースをオンラインにする必要がある一部のサービス更新プログラムのデプロイ中にも、自動再開がトリガーされます。Autoresuming is also triggered during the deployment of some service updates which require the database be online.

接続Connectivity

サーバーレス データベースが一時停止されている場合、データベースは最初のログインで再開され、データベースが使用できないことを示すエラーがエラー コード 40613 で返されます。If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. データベースが再開され後、ログインを再試行して接続を確立する必要があります。Once the database is resumed, the login must be retried to establish connectivity. 接続再試行ロジックを備えたデータベース クライアントは、変更する必要はありません。Database clients with connection retry logic should not need to be modified.

LatencyLatency

サーバーレス データベースの自動再開および自動一時停止の待機時間は、通常、自動再開までに 1 分、自動停止までに 1 - 10 分かかります。The latency to autoresume and autopause a serverless database is generally order of 1 minute to autoresume and 1-10 minutes to autopause.

お客様が管理する透過的なデータ暗号化 (BYOK)Customer managed transparent data encryption (BYOK)

お客様が管理する透過的なデータ暗号化 (BYOK) を使用していて、キーの削除または失効が発生したときにサーバーレス データベースが自動一時停止されている場合、データベースは自動一時停止状態のままになります。If using customer managed transparent data encryption (BYOK) and the serverless database is auto-paused when key deletion or revocation occurs, then the database remains in the auto-paused state. この場合、データベースが次に再開された後、約 10 分以内にデータベースにアクセスできなくなります。In this case, after the database is next resumed, the database becomes inaccessible within approximately 10 minutes. データベースがアクセス不可になった後、復旧プロセスは、プロビジョニングされたコンピューティング データベースの場合と同じです。Once the database becomes inaccessible, the recovery process is the same as for provisioned compute databases. キーの削除または失効が発生したときにサーバーレス データベースがオンラインになっている場合も、プロビジョニングされたコンピューティング データベースと同じように約 10 分以内にデータベースにアクセスできなくなります。If the serverless database is online when key deletion or revocation occurs, then the database also becomes inaccessible within approximately 10 minutes in the same way as with provisioned compute databases.

サーバーレス コンピューティング レベルへのオンボードOnboarding into serverless compute tier

サーバーレス コンピューティング レベルでの新しいデータベースの作成または既存のデータベースの移動は、プロビジョニング済みコンピューティング レベルでの新規データベースの作成と同じパターンに従い、次の 2 つのステップが含まれます。Creating a new database or moving an existing database into a serverless compute tier follows the same pattern as creating a new database in provisioned compute tier and involves the following two steps.

  1. サービス目標を指定します。Specify the service objective. サービス目標では、サービス レベル、ハードウェアの世代、および最大仮想コア数が規定されます。The service objective prescribes the service tier, hardware generation, and max vCores. サービス目標オプションについては、サーバーレス リソースの制限に関するページを参照してください。For service objective options, see serverless resource limits

  2. 必要に応じて、最小仮想コア数と自動一時停止遅延を指定して、既定値を変更します。Optionally, specify the min vCores and autopause delay to change their default values. これらのパラメーターに対して使用可能な値を次の表に示します。The following table shows the available values for these parameters.

    パラメーターParameter 値の選択肢Value choices 既定値Default value
    最小仮想コアMin vCores 構成された最大仮想コアによって異なります。リソースの制限に関するページを参照してください。Depends on max vCores configured - see resource limits. 0.5 仮想コア0.5 vCores
    自動一時停止遅延Autopause delay 最小:60 分 (1 時間)Minimum: 60 minutes (1 hour)
    最大値:10080 分 (7 日)Maximum: 10080 minutes (7 days)
    増分: 10 分Increments: 10 minutes
    自動一時停止の無効化: -1Disable autopause: -1
    約 60 分60 minutes

サーバーレス コンピューティング レベルで新しいデータベースを作成するCreate a new database in the serverless compute tier

次の例では、サーバーレス コンピューティング レベルで新しいデータベースを作成します。The following examples create a new database in the serverless compute tier.

Azure ポータルの使用Use the Azure portal

クイック スタート:Azure portal を使用して Azure SQL Database で単一データベースを作成する」をご覧ください。See Quickstart: Create a single database in Azure SQL Database using the Azure portal.

PowerShell の使用Use PowerShell

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -ComputeModel Serverless -Edition GeneralPurpose -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720

Azure CLI の使用Use the Azure CLI

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose -f Gen5 -min-capacity 0.5 -c 2 --compute-model Serverless --auto-pause-delay 720

Transact-SQL (T-SQL) の使用Use Transact-SQL (T-SQL)

T-SQL を使用すると、最小仮想コアと自動一時停止遅延に既定値が適用されます。When using T-SQL, default values are applied for the min vcores and autopause delay.

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

詳細については、「CREATE DATABASE」を参照してください。For details, see CREATE DATABASE.

プロビジョニングされたコンピューティング レベルからサーバーレス コンピューティング レベルにデータベースを移動するMove a database from the provisioned compute tier into the serverless compute tier

次の例では、プロビジョニングされたコンピューティング レベルからサーバーレス コンピューティング レベルにデータベースを移動します。The following examples move a database from the provisioned compute tier into the serverless compute tier.

PowerShell の使用Use PowerShell

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440

Azure CLI の使用Use the Azure CLI

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --min-capacity 1 --capacity 4 --family Gen5 --compute-model Serverless --auto-pause-delay 1440

Transact-SQL (T-SQL) の使用Use Transact-SQL (T-SQL)

T-SQL を使用すると、最小仮想コアと自動一時停止遅延に既定値が適用されます。When using T-SQL, default values are applied for the min vcores and autopause delay.

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

詳細については、「ALTER DATABASE」を参照してください。For details, see ALTER DATABASE.

サーバーレス コンピューティング レベルからプロビジョニングされたコンピューティング レベルにデータベースを移動するMove a database from the serverless compute tier into the provisioned compute tier

プロビジョニング済みコンピューティング データベースをサーバーレス コンピューティング レベルに移動するのと同じ方法で、サーバーレス データベースをプロビジョニング済みコンピューティング レベルに移動できます。A serverless database can be moved into a provisioned compute tier in the same way as moving a provisioned compute database into a serverless compute tier.

サーバーレス構成の変更Modifying serverless configuration

PowerShell の使用Use PowerShell

最大または最小の仮想コア、および自動一時停止遅延の変更は、PowerShell の Set-AzSqlDatabase コマンドと、 MaxVcoreMinVcore、および AutoPauseDelayInMinutes の引数を使用して実行されます。Modifying the maximum or minimum vCores, and autopause delay, is performed by using the Set-AzSqlDatabase command in PowerShell using the MaxVcore, MinVcore, and AutoPauseDelayInMinutes arguments.

Azure CLI の使用Use the Azure CLI

最大または最小の仮想コア、および自動一時停止遅延の変更は、Azure CLI の az sql db update コマンドと、 capacitymin-capacity、および auto-pause-delay の引数を使用して実行されます。Modifying the maximum or minimum vCores, and autopause delay, is performed by using the az sql db update command in Azure CLI using the capacity, min-capacity, and auto-pause-delay arguments.

監視Monitoring

使用済みおよび請求対象のリソースResources used and billed

サーバーレス データベースのリソースは、アプリ パッケージ、SQL インスタンス、およびユーザー リソース プール エンティティによってカプセル化されます。The resources of a serverless database are encapsulated by app package, SQL instance, and user resource pool entities.

アプリ パッケージApp package

アプリ パッケージは、データベースがサーバーレスまたはプロビジョニング済みのどちらのコンピューティング レベルであるかに関係なく、データベースに対する最も外側のリソース管理境界です。The app package is the outer most resource management boundary for a database, regardless of whether the database is in a serverless or provisioned compute tier. アプリ パッケージには SQL インスタンスと外部サービスが含まれ、両者によって SQL Database のデータベースによって使用されるすべてのユーザー リソースとシステム リソースのスコープが決まります。The app package contains the SQL instance and external services that together scope all user and system resources used by a database in SQL Database. 外部サービスの例としては、R やフルテキスト検索などがあります。Examples of external services include R and full-text search. 一般に、アプリ パッケージでの全体的なリソース使用量より、SQL インスタンスの方が優位です。The SQL instance generally dominates the overall resource utilization across the app package.

ユーザー リソース プールUser resource pool

ユーザー リソース プールは、データベースがサーバーレスまたはプロビジョニング済みのどちらのコンピューティング レベルであるかに関係なく、データベースに対する最も内側のリソース管理境界です。The user resource pool is the inner most resource management boundary for a database, regardless of whether the database is in a serverless or provisioned compute tier. ユーザー リソース プールのスコープは、DDL クエリ (CREATE、ALTER など) および DML クエリ (SELECT、INSERT、UPDATE、DELETE など) によって生成されるユーザー ワークロードに対する CPU と IO です。The user resource pool scopes CPU and IO for user workload generated by DDL queries such as CREATE and ALTER and DML queries such as SELECT, INSERT, UPDATE, and DELETE. これらのクエリは、一般に、アプリ パッケージでの使用量の最も大きな割合を表します。These queries generally represent the most substantial proportion of utilization within the app package.

メトリックMetrics

サーバーレス データベースのアプリ パッケージとユーザー プールのリソース使用量を監視するためのメトリックは、次の表のとおりです。Metrics for monitoring the resource usage of the app package and user pool of a serverless database are listed in the following table:

EntityEntity メトリックMetric 説明Description UnitsUnits
アプリ パッケージApp package app_cpu_percentapp_cpu_percent アプリに許可されている最大仮想コア数に対する、アプリによって使用された仮想コア数の割合。Percentage of vCores used by the app relative to max vCores allowed for the app. パーセントPercentage
アプリ パッケージApp package app_cpu_billedapp_cpu_billed レポート期間中にアプリに対して請求されるコンピューティングの量。The amount of compute billed for the app during the reporting period. この期間中に支払われる金額は、このメトリックと仮想コアの単位価格の積です。The amount paid during this period is the product of this metric and the vCore unit price.

このメトリックの値は、1 秒ごとに使用された CPU とメモリの最大値を時間で集計することによって決定されます。Values of this metric are determined by aggregating over time the maximum of CPU used and memory used each second. 使用された金額が、最小仮想コア数と最小メモリによって設定されるプロビジョニング済みの最低額より少ない場合、プロビジョニング済みの最低額が請求されます。If the amount used is less than the minimum amount provisioned as set by the min vCores and min memory, then the minimum amount provisioned is billed. 請求のために CPU とメモリを比較するため、メモリは GB 単位のメモリ量を仮想コアあたり 3 GB で再スケーリングすることによって、仮想コアの単位に正規化されます。 In order to compare CPU with memory for billing purposes, memory is normalized into units of vCores by rescaling the amount of memory in GB by 3 GB per vCore.
仮想コア秒数vCore seconds
アプリ パッケージApp package app_memory_percentapp_memory_percent アプリに許可されている最大メモリに対する、アプリによって使用されたメモリの割合。Percentage of memory used by the app relative to max memory allowed for the app. パーセントPercentage
ユーザー プールUser pool cpu_percentcpu_percent ユーザー ワークロードに許可されている最大仮想コア数に対する、ユーザー ワークロードによって使用された仮想コア数の割合。Percentage of vCores used by user workload relative to max vCores allowed for user workload. パーセントPercentage
ユーザー プールUser pool data_IO_percentdata_IO_percent ユーザー ワークロードに許可されている最大データ IOPS に対する、ユーザー ワークロードによって使用されたデータ IOPS の割合。Percentage of data IOPS used by user workload relative to max data IOPS allowed for user workload. パーセントPercentage
ユーザー プールUser pool log_IO_percentlog_IO_percent ユーザー ワークロードに許可されている最大ログ MB/秒に対する、ユーザー ワークロードによって使用されたログ MB/秒の割合。Percentage of log MB/s used by user workload relative to max log MB/s allowed for user workload. パーセントPercentage
ユーザー プールUser pool workers_percentworkers_percent ユーザー ワークロードに許可されている最大ワーカー数に対する、ユーザー ワークロードによって使用されたワーカー数の割合。Percentage of workers used by user workload relative to max workers allowed for user workload. パーセントPercentage
ユーザー プールUser pool sessions_percentsessions_percent ユーザー ワークロードに許可されている最大セッション数に対する、ユーザー ワークロードによって使用されたセッション数の割合。Percentage of sessions used by user workload relative to max sessions allowed for user workload. パーセントPercentage

一時停止と再開の状態Pause and resume status

Azure portal では、データベースの状態は、サーバーに含まれるデータベースの一覧が表示される概要ウィンドウで示されます。In the Azure portal, the database status is displayed in the overview pane of the server that lists the databases it contains. データベースの状態は、データベースの概要ウィンドウにも表示されます。The database status is also displayed in the overview pane for the database.

データベースの一時停止と再開の状態を照会するには、次のコマンドを使用します。Using the following commands to query the pause and resume status of a database:

PowerShell の使用Use PowerShell

Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

Azure CLI の使用Use the Azure CLI

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

リソース制限Resource limits

リソースの制限については、サーバーレス コンピューティング レベルをご覧ください。For resource limits, see serverless compute tier.

課金Billing

コンピューティング請求金額は、各秒に使用された CPU およびメモリの最大量です。The amount of compute billed is the maximum of CPU used and memory used each second. CPU とメモリの使用量がそれぞれのプロビジョニング済みの最小量より少ない場合、プロビジョニング済みの量が請求されます。If the amount of CPU used and memory used is less than the minimum amount provisioned for each, then the provisioned amount is billed. 請求のために CPU とメモリを比較するため、メモリは GB 単位のメモリ量を仮想コアあたり 3 GB で再スケーリングすることによって、仮想コアの単位に正規化されます。In order to compare CPU with memory for billing purposes, memory is normalized into units of vCores by rescaling the amount of memory in GB by 3 GB per vCore.

  • 請求されるリソース : CPU とメモリResource billed : CPU and memory
  • 請求される金額 : 仮想コア単位価格 * (最小仮想コア数、使用された仮想コア数、最小メモリ GB * 1/3、使用されたメモリ GB * 1/3) のうち最大の値Amount billed : vCore unit price * max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • 請求頻度 : 1 秒あたりBilling frequency : Per second

仮想コア単位価格は、1 秒あたり、仮想コアあたりのコストです。The vCore unit price is the cost per vCore per second. 特定のリージョンの特定の単位価格については、Azure SQL Database の価格に関するページをご覧ください。Refer to the Azure SQL Database pricing page for specific unit prices in a given region.

請求されるコンピューティングの金額は、次のメトリックで示されます。The amount of compute billed is exposed by the following metric:

  • メトリック : app_cpu_billed (仮想コア秒数)Metric : app_cpu_billed (vCore seconds)
  • 定義 : (最小仮想コア数、使用された仮想コア数、最小メモリ GB * 1/3、使用されたメモリ GB * 1/3) のうち最大の値Definition : max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • レポート頻度 : 1 分あたりReporting frequency : Per minute

この量が 1 秒ごとに計算され、1 分間について集計されます。This quantity is calculated each second and aggregated over 1 minute.

最小コンピューティング料金Minimum compute bill

サーバーレス データベースが一時停止された場合、コンピューティング料金は 0 になります。If a serverless database is paused, then the compute bill is zero. サーバーレス データベースが一時停止されていない場合、最小コンピューティング料金は、最大に基づく仮想コア以上になります (最少仮想コア、最少メモリ GB * 1/3)。If a serverless database is not paused, then the minimum compute bill is no less than the amount of vCores based on max (min vCores, min memory GB * 1/3).

例 :Examples:

  • サーバーレス データベースが一時停止しておらず、3.0 GB の最小メモリに対応して最大仮想コア数に 8、最少仮想コア数に 1 が構成されているとします。Suppose a serverless database is not paused and configured with 8 max vCores and 1 min vCore corresponding to 3.0 GB min memory. この場合、最小コンピューティング料金は、最大 (1 仮想コア、3.0 GB * 1 仮想コア/3 GB) = 1 仮想コアに基づきます。Then the minimum compute bill is based on max (1 vCore, 3.0 GB * 1 vCore / 3 GB) = 1 vCore.
  • サーバーレス データベースが一時停止しておらず、2.1 GB の最小メモリに対応して最大仮想コア数に 4、最少仮想コア数に 0.5 が構成されているとします。Suppose a serverless database is not paused and configured with 4 max vCores and 0.5 min vCores corresponding to 2.1 GB min memory. この場合、最小コンピューティング料金は、最大 (0.5 仮想コア、2.1 GB * 1 仮想コア/3 GB) = 0.7 仮想コアに基づきます。Then the minimum compute bill is based on max (0.5 vCores, 2.1 GB * 1 vCore / 3 GB) = 0.7 vCores.

サーバーレス用の Azure SQL Database 料金計算ツールを使用すると、構成された最大および最小の仮想コア数に基づいて構成可能な最小メモリを決定できます。The Azure SQL Database pricing calculator for serverless can be used to determine the min memory configurable based on the number of max and min vCores configured. ルールとして、構成された最小仮想コア数が 0.5 仮想コアを超える場合、最小コンピューティング料金は構成されている最小メモリには依存せず、構成された最小仮想コア数のみに基づいて計算されます。As a rule, if the min vCores configured is greater than 0.5 vCores, then the minimum compute bill is independent of the min memory configured and based only on the number of min vCores configured.

サンプル シナリオExample scenario

最小仮想コア数に 1、最大仮想コア数に 4 が指定されているサーバーレス データベースについて考えてみます。Consider a serverless database configured with 1 min vCore and 4 max vCores. この場合、最小メモリは約 3 GB、最大メモリは約 12 GB です。This corresponds to around 3 GB min memory and 12-GB max memory. 自動一時停止遅延が 6 時間に設定され、24 時間のうち最初の 2 時間だけデータベースのワークロードがアクティブで、それ以外の時間は非アクティブだとすると、Suppose the auto-pause delay is set to 6 hours and the database workload is active during the first 2 hours of a 24-hour period and otherwise inactive.

このデータベースは、最初の 8 時間はコンピューティングとストレージに対して課金されます。In this case, the database is billed for compute and storage during the first 8 hours. 2 時間を過ぎるとデータベースは非アクティブになりますがオンラインなので、その後の 6 時間については、プロビジョニングされた最小コンピューティングに基づいて、コンピューティングに対して引き続き課金されます。Even though the database is inactive starting after the second hour, it is still billed for compute in the subsequent 6 hours based on the minimum compute provisioned while the database is online. 24 時間のうち、データベースが一時停止中の残りの時間については、ストレージのみが課金されます。Only storage is billed during the remainder of the 24-hour period while the database is paused.

正確には、この例のコンピューティングに対する課金は次のように計算されます。More precisely, the compute bill in this example is calculated as follows:

期間Time Interval 使用された 1 秒あたりの仮想コア数vCores used each second 使用された 1 秒あたりの GB 数GB used each second 課金対象となるコンピューティング ディメンションCompute dimension billed 対象期間内で課金対象となる仮想コア秒数vCore seconds billed over time interval
0:00-1:000:00-1:00 44 99 使用された仮想コア数vCores used 4 個の仮想コア * 3,600 秒 = 14,400 仮想コア秒4 vCores * 3600 seconds = 14400 vCore seconds
1:00-2:001:00-2:00 11 1212 使用されたメモリMemory used 12 GB * 1/3 * 3,600 秒 = 14,400 仮想コア秒12 GB * 1/3 * 3600 seconds = 14400 vCore seconds
2:00-8:002:00-8:00 00 00 プロビジョニング済み最小メモリMin memory provisioned 3 GB * 1/3 * 21,600 秒 = 21,600 仮想コア秒3 GB * 1/3 * 21600 seconds = 21600 vCore seconds
8:00-24:008:00-24:00 00 00 一時停止中、コンピューティングには課金なしNo compute billed while paused 0 仮想コア秒0 vCore seconds
24 時間で課金対象となる合計仮想コア秒数Total vCore seconds billed over 24 hours 50,400 仮想コア秒50400 vCore seconds

コンピューティングの単位価格は $0.000145/仮想コア/秒とします。Suppose the compute unit price is $0.000145/vCore/second. この場合、この 24 時間で課金対象となるコンピューティングは、コンピューティング ユニット価格と課金対象の仮想コア秒数の積になります: $0.000145/仮想コア/秒 * 50,400 仮想コア秒 = 約 $7.31Then the compute billed for this 24-hour period is the product of the compute unit price and vCore seconds billed: $0.000145/vCore/second * 50400 vCore seconds ~ $7.31

Azure ハイブリッド特典と予約容量Azure Hybrid Benefit and reserved capacity

Azure ハイブリッド特典 (AHB) と予約容量の割引は、サーバーレス コンピューティング レベルには適用されません。Azure Hybrid Benefit (AHB) and reserved capacity discounts do not apply to the serverless compute tier.

対応リージョンAvailable regions

サーバーレス コンピューティング レベルは、次のリージョンを除く全世界で利用できます。中国東部、中国北部、ドイツ中部、ドイツ北東部、US Gov 中部 (アイオワ)。The serverless compute tier is available worldwide except the following regions: China East, China North, Germany Central, Germany Northeast, and US Gov Central (Iowa).

次のステップNext steps