Azure SQL Database で単一データベースのリソースをスケーリングするScale single database resources in Azure SQL Database

この記事では、プロビジョニングされたコンピューター レベルで Azure SQL データベース用に使用できるコンピューティング リソースとストレージ リソースをスケーリングする方法について説明します。This article describes how to scale the compute and storage resources available for an Azure SQL Database in the provisioned compute tier. また、サーバーレス コンピューティング レベルは、コンピューティングの自動スケーリングと、使用されたコンピューティングの 1 秒あたりの請求額を提供します。Alternatively, the serverless compute tier provides compute auto-scaling and bills per second for compute used.

コンピューティング サイズ (仮想コアまたは DTU) の変更Change compute size (vCores or DTUs)

最初に仮想コア数または DTU 数を選択すると、Azure portalTransact-SQLPowerShellAzure CLI、または REST API を使い、実際のエクスペリエンスに基づいて、単一データベースを動的にスケールアップまたはスケールダウンできます。After initially picking the number of vCores or DTUs, you can scale a single database up or down dynamically based on actual experience using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.

次のビデオでは、サービス レベルとコンピューティング サイズを動的に変更して単一データベースで使用可能な DTU を増やす方法を示します。The following video shows dynamically changing the service tier and compute size to increase available DTUs for a single database.

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。Under some circumstances, you may need to shrink a database to reclaim unused space. 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。For more information, see Manage file space in Azure SQL Database.

サービス レベルの変更またはコンピューティング サイズの再スケーリングの影響Impact of changing service tier or rescaling compute size

サービス レベルまたはコンピューティング サイズの変更には、主に次の手順を実行するサービスが含まれます。Changing the service tier or compute size of mainly involves the service performing the following steps:

  1. データベース用に新しいコンピューティング インスタンスを作成するCreate new compute instance for the database

    要求されたサービス レベルとコンピューティング サイズを持つ新しいコンピューティング インスタンスが作成されます。A new compute instance is created with the requested service tier and compute size. サービス レベルとコンピューティング サイズの変更の組み合わせの中には、新しいコンピューティング インスタンスにデータベースのレプリカを作成する必要があるものがあります。これにはデータのコピーも含まれ、全体の待機時間に大きく影響する場合があります。For some combinations of service tier and compute size changes, a replica of the database must be created in the new compute instance which involves copying data and can strongly influence the overall latency. いずれにしても、この手順の間、データベースはオンラインのままで、接続は元のコンピューティング インスタンスのデータベースに引き続き向けられます。Regardless, the database remains online during this step, and connections continue to be directed to the database in the original compute instance.

  2. 接続のルーティングを新しいコンピューティング インスタンスに切り替えるSwitch routing of connections to new compute instance

    元のコンピューティング インスタンス内のデータベースへの既存の接続が削除されます。Existing connections to the database in the original compute instance are dropped. 新しいコンピューティング インスタンス内のデータベースへの新しい接続が確立されます。Any new connections are established to the database in the new compute instance. サービス レベルとコンピューティング サイズの一部の組み合わせの変更では、データベース ファイルがデタッチされ、切り替え時に再アタッチされます。For some combinations of service tier and compute size changes, database files are detached and reattached during the switch. いずれにしても、切り替えにより、データベースが使用できなくなる短時間の中断が発生する場合があります。中断は通常は 30 秒未満で、多くの場合はほんの数秒です。Regardless, the switch can result in a brief service interruption when the database is unavailable generally for less than 30 seconds and often for only a few seconds. 接続が削除されたときに長時間実行されているトランザクションがあると、中断されたトランザクションを復旧するために、この手順の所要時間が長くなる場合があります。If there are long running transactions running when connections are dropped, the duration of this step may take longer in order to recover aborted transactions. 高速データベースの復旧により、長時間実行されているトランザクションの中断による影響を軽減できます。Accelerated Database Recovery can reduce the impact from aborting long running transactions.

重要

ワークフローのいずれの手順でもデータが失われることはありません。No data is lost during any step in the workflow. サービス レベルの変更中に Azure SQL Database を使用するアプリケーションとコンポーネントに、何らかの再試行ロジックを実装したことを確認してください。Make sure that you have implemented some retry logic in the applications and components that are using Azure SQL Database while the service tier is changed.

サービス レベルの変更またはコンピューティング サイズの再スケーリングの待機時間Latency of changing service tier or rescaling compute size

単一データベースまたはエラスティック プールのサービス レベルを変更またはコンピューティング サイズを変更する推定待機時間は、次のようにパラメーター化されます。The estimated latency to change the service tier or rescale the compute size of a single database or elastic pool is parameterized as follows:

サービス階層Service tier Basic 単一データベース、Basic single database,
Standard (S0-S1)Standard (S0-S1)
Basic エラスティック プール、Basic elastic pool,
Standard (S2-S12)、Standard (S2-S12),
ハイパースケール、Hyperscale,
汎用の単一データベースまたはエラスティック プールGeneral Purpose single database or elastic pool
Premium または Business Critical の単一データベースまたはエラスティック プールPremium or Business Critical single database or elastic pool
Basic 単一データベース、
Standard (S0-S1)
Basic single database,
Standard (S0-S1)
•  使用される領域とは関係ない一定時間の待機時間•  Constant time latency independent of space used
•  通常は 5 分未満•  Typically, less than 5 minutes
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  Latency proportional to database space used due to data copying
•  通常、使用される領域の GB あたり 1 分未満•  Typically, less than 1 minute per GB of space used
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  Latency proportional to database space used due to data copying
•  通常、使用される領域の GB あたり 1 分未満•  Typically, less than 1 minute per GB of space used
Basic エラスティック プール、
Standard (S2-S12)、
ハイパースケール、
汎用の単一データベースまたはエラスティック プール
Basic elastic pool,
Standard (S2-S12),
Hyperscale,
General Purpose single database or elastic pool
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  Latency proportional to database space used due to data copying
•  通常、使用される領域の GB あたり 1 分未満•  Typically, less than 1 minute per GB of space used
•  使用される領域とは関係ない一定時間の待機時間•  Constant time latency independent of space used
•  通常は 5 分未満•  Typically, less than 5 minutes
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  Latency proportional to database space used due to data copying
•  通常、使用される領域の GB あたり 1 分未満•  Typically, less than 1 minute per GB of space used
Premium または Business Critical の単一データベースまたはエラスティック プールPremium or Business Critical single database or elastic pool •  データのコピーのために使用されるデータベース領域に比例した待機時間•  Latency proportional to database space used due to data copying
•  通常、使用される領域の GB あたり 1 分未満•  Typically, less than 1 minute per GB of space used
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  Latency proportional to database space used due to data copying
•  通常、使用される領域の GB あたり 1 分未満•  Typically, less than 1 minute per GB of space used
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  Latency proportional to database space used due to data copying
•  通常、使用される領域の GB あたり 1 分未満•  Typically, less than 1 minute per GB of space used

ヒント

実行中の操作の監視については、SQL REST API を使った操作の管理CLI を使った操作の管理T-SQL を使った操作の管理に関する各ページと、2 つの PowerShell コマンド Get-AzSqlDatabaseActivityStop-AzSqlDatabaseActivityTo monitor in-progress operations, see: Manage operations using the SQL REST API, Manage operations using CLI, Monitor operations using T-SQL and these two PowerShell commands: Get-AzSqlDatabaseActivity and Stop-AzSqlDatabaseActivity.

サービス レベルの変更またはコンピューティングの再スケーリング操作の取り消しCancelling service tier changes or compute rescaling operations

サービス レベルの変更またはコンピューティングの再スケーリング操作を取り消すことができます。A service tier change or compute rescaling operation can be canceled.

Azure ポータルAzure portal

[データベースの概要] ブレードで、 [通知] に移動し、進行中の操作があることを示すタイルをクリックします。In the database overview blade, navigate to Notifications and click on the tile indicating there is an ongoing operation:

進行中の操作

次に、 [この操作を取り消す] というラベルのボタンをクリックします。Next, click on the button labeled Cancel this operation.

進行中の操作の取り消し

PowerShellPowerShell

PowerShell コマンド プロンプトで $resourceGroupName$serverName、および $databaseName を設定した後、次のコマンドを実行します。From a PowerShell command prompt, set the $resourceGroupName, $serverName, and $databaseName, and then run the following command:

$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

サービス レベルを変更またはコンピューティング サイズを再スケーリングする場合の追加の考慮事項Additional considerations when changing service tier or rescaling compute size

  • より上位のサービス レベルまたはコンピューティング サイズにアップグレードしても、より大きなサイズ (最大サイズ) を明示的に指定しない限り、データベースの最大サイズは増加しません。If you are upgrading to a higher service tier or compute size, the database max size does not increase unless you explicitly specify a larger size (maxsize).
  • データベースをダウングレードするには、データベースで使われている領域がダウングレード後のサービス レベルとコンピューティング サイズで許可されている最大サイズより小さい必要があります。To downgrade a database, the database used space must be smaller than the maximum allowed size of the target service tier and compute size.
  • Premium から Standard レベルにダウングレードするときは、(1) データベースの最大サイズがターゲットのコンピューティング サイズでサポートされていて、かつ、(2) 最大サイズがターゲットのコンピューティング サイズで付属のストレージ容量を超えている場合、追加ストレージ コストが適用されます。When downgrading from Premium to the Standard tier, an extra storage cost applies if both (1) the max size of the database is supported in the target compute size, and (2) the max size exceeds the included storage amount of the target compute size. たとえば、最大サイズ 500 GB の P1 データベースを S3 にダウンサイズする場合、S3 がサポートする最大サイズは 1 TB であり、S3 で付属のストレージ容量は 250 GB だけなので、追加ストレージ コストが適用されます。For example, if a P1 database with a max size of 500 GB is downsized to S3, then an extra storage cost applies since S3 supports a max size of 1 TB and its included storage amount is only 250 GB. したがって、追加ストレージ容量は 500 GB – 250 GB = 250 GB になります。So, the extra storage amount is 500 GB – 250 GB = 250 GB. 追加ストレージの価格については、「SQL Database の価格」をご覧ください。For pricing of extra storage, see SQL Database pricing. 実際に使われる領域の量が付属のストレージの量より少ない場合、データベースの最大サイズを付属の量に減らすことで、この追加コストを回避できます。If the actual amount of space used is less than the included storage amount, then this extra cost can be avoided by reducing the database max size to the included amount.
  • geo レプリケーションが有効な状態でデータベースをアップグレードする場合、そのセカンダリ データベースを目的のサービス レベルとコンピューティング サイズにアップグレードしてから、プライマリ データベースをアップグレードします (パフォーマンスを最大にするための一般的なガイダンス)。When upgrading a database with geo-replication enabled, upgrade its secondary databases to the desired service tier and compute size before upgrading the primary database (general guidance for best performance). 別のエディションにアップグレードする場合は、最初にセカンダリ データベースのアップグレードが必要です。When upgrading to a different, upgrading the secondary database first is required.
  • geo レプリケーションが有効な状態でデータベースをダウングレードする場合、そのプライマリ データベースを目的のサービス レベルとコンピューティング サイズにダウングレードしてから、セカンダリ データベースをダウングレードします (パフォーマンスを最大にするための一般的なガイダンス)。When downgrading a database with geo-replication enabled, downgrade its primary databases to the desired service tier and compute size before downgrading the secondary database (general guidance for best performance). 別のエディションにダウングレードする場合は、最初にプライマリ データベースのダウングレードが必要です。When downgrading to a different edition, downgrading the primary database first is required.
  • サービス階層によって、提供されている復元サービスは異なります。The restore service offerings are different for the various service tiers. Basic レベルにダウングレードする場合は、バックアップのリテンション期間が短くなります。If you are downgrading to the Basic tier, there is a lower backup retention period. Azure SQL Database のバックアップに関する記事をご覧ください。See Azure SQL Database Backups.
  • データベースに対する新しいプロパティは、変更が完了するまで適用されません。The new properties for the database are not applied until the changes are complete.

コンピューティングの再スケーリング時の課金Billing during compute rescaling

使用状況やデータベースがアクティブであったのが 1 時間未満であったことに関係なく、データベースが存在していた 1 時間単位で、その時間に使用された最上位のサービス階層とコンピューティング サイズで課金は行われます。You are billed for each hour a database exists using the highest service tier + compute size that applied during that hour, regardless of usage or whether the database was active for less than an hour. たとえば、Single Database を作成し、それを 5 分後に削除した場合、請求書にはデータベース時間として 1 時間の請求が表示されます。For example, if you create a single database and delete it five minutes later your bill reflects a charge for one database hour.

ストレージ サイズの変更Change storage size

仮想コアベースの購入モデルvCore-based purchasing model

  • 1 GB の増分を使用して最大サイズの上限に達するまでストレージをプロビジョニングすることができます。Storage can be provisioned up to the max size limit using 1GB increments. 構成可能な最小データ ストレージは 5 GB ですThe minimum configurable data storage is 5 GB
  • 単一データベースのストレージは、Azure PortalTransact-SQLPowerShellAzure CLI、または REST API を使って最大サイズを増減することでプロビジョニングできます。Storage for a single database can be provisioned by increasing or decreasing its max size using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.
  • SQL Database は自動的に追加ストレージの 30% をログ ファイルに割り当て、TempDB の仮想コアごとに 32 GB を割り当てますが、384 GB を超えることはありません。SQL Database automatically allocates 30% of additional storage for the log files and 32GB per vCore for TempDB, but not to exceed 384GB. TempDB は、すべてのサービス レベルの接続されている SSD にあります。TempDB is located on an attached SSD in all service tiers.
  • 単一データベースのストレージの料金は、データ ストレージとログ ストレージの容量の合計にサービス レベルのストレージ単価を掛けて計算します。The price of storage for a single database is the sum of data storage and log storage amounts multiplied by the storage unit price of the service tier. TempDB のコストは仮想コア価格に含まれています。The cost of TempDB is included in the vCore price. 追加ストレージの価格について詳しくは、「SQL Database の価格」をご覧ください。For details on the price of extra storage, see SQL Database pricing.

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。Under some circumstances, you may need to shrink a database to reclaim unused space. 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。For more information, see Manage file space in Azure SQL Database.

DTU ベースの購入モデルDTU-based purchasing model

  • 単一データベースの DTU 価格には、追加コストなしで一定量のストレージが含まれます。The DTU price for a single database includes a certain amount of storage at no additional cost. 付属の容量を超える分のストレージについては、追加費用を払うことで、1 TB までは 250 GB 単位で、1 TB 以降は 256 GB 単位で、最大サイズ制限までプロビジョニングできます。Extra storage beyond the included amount can be provisioned for an additional cost up to the max size limit in increments of 250 GB up to 1 TB, and then in increments of 256 GB beyond 1 TB. 付属するストレージ容量と最大サイズ制限については、「単一データベース: ストレージ サイズとコンピューティング サイズ」をご覧ください。For included storage amounts and max size limits, see Single database: Storage sizes and compute sizes.
  • 単一データベースの追加ストレージは、Azure portal、Transact-SQLPowerShellAzure CLI、または REST API を使ってサイズを最大に増やすことでプロビジョニングできます。Extra storage for a single database can be provisioned by increasing its max size using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.
  • 単一データベースの追加ストレージの料金は、追加ストレージ容量にサービス レベルの追加ストレージ単価を掛けて計算します。The price of extra storage for a single database is the extra storage amount multiplied by the extra storage unit price of the service tier. 追加ストレージの価格について詳しくは、「SQL Database の価格」をご覧ください。For details on the price of extra storage, see SQL Database pricing.

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。Under some circumstances, you may need to shrink a database to reclaim unused space. 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。For more information, see Manage file space in Azure SQL Database.

最大サイズが 1 TB を超える場合の P11 と P15 の制約P11 and P15 constraints when max size greater than 1 TB

現在、1 TB を超える Premium レベルのストレージは、中国東部、中国北部、ドイツ中部、ドイツ北東部、米国中西部、米国 DoD の各リージョンと、米国政府中部を除くすべてのリージョンで利用できます。More than 1 TB of storage in the Premium tier is currently available in all regions except: China East, China North, Germany Central, Germany Northeast, West Central US, US DoD regions, and US Government Central. これらのリージョンでは、Premium レベルのストレージの最大容量は 1 TB です。In these regions, the storage max in the Premium tier is limited to 1 TB. 最大サイズが 1 TB を超える P11 および P15 データベースには、次の考慮事項と制限事項が適用されます。The following considerations and limitations apply to P11 and P15 databases with a maximum size greater than 1 TB:

  • P11 または P15 のデータベースの最大サイズが 1 TB を超える値に設定されていた場合、P11 または P15 のデータベースにしか復元またはコピーできません。If the max size for a P11 or P15 database was ever set to a value greater than 1 TB, then can it only be restored or copied to a P11 or P15 database. その後、再スケーリング操作の時に割り当てられた領域の量が新しいコンピューティング サイズの最大サイズ制限を超えなければ、データベースを異なるコンピューティング サイズに再スケーリングすることができます。Subsequently, the database can be rescaled to a different compute size provided the amount of space allocated at the time of the rescaling operation does not exceed max size limits of the new compute size.
  • アクティブ geo レプリケーションのシナリオの場合:For active geo-replication scenarios:
    • geo レプリケーションのリレーションシップの設定:プライマリ データベースが P11 または P15 の場合は、セカンダリも P11 または P15 である必要があります。つまり、下位のコンピューティング サイズは、1 TB を超えるサイズをサポートできないため、セカンダリとして拒否されます。Setting up a geo-replication relationship: If the primary database is P11 or P15, the secondary(ies) must also be P11 or P15; lower compute size are rejected as secondaries since they are not capable of supporting more than 1 TB.
    • geo レプリケーションのリレーションシップでのプライマリ データベースのアップグレード:プライマリ データベースで最大サイズを 1 TB 超に変更すると、セカンダリ データベースでも同じ変更がトリガーされます。Upgrading the primary database in a geo-replication relationship: Changing the maximum size to more than 1 TB on a primary database triggers the same change on the secondary database. プライマリに対する変更を有効にするには、両方のアップグレードが正常に完了する必要があります。Both upgrades must be successful for the change on the primary to take effect. 1 TB を超えるオプションに関するリージョンの制限が適用されます。Region limitations for the more than 1-TB option apply. 1 TB 超をサポートしていないリージョンにセカンダリが存在する場合、プライマリはアップグレードされません。If the secondary is in a region that does not support more than 1 TB, the primary is not upgraded.
  • 1 TB を超える P11/P15 データベースの読み込みに Import/Export サービスを使うことはサポートされていません。Using the Import/Export service for loading P11/P15 databases with more than 1 TB is not supported. SqlPackage.exe を使用して、データをインポートおよびエクスポートしてください。Use SqlPackage.exe to import and export data.

次の手順Next steps

全体的なリソースの制限については、SQL Database の仮想コアペースのリソース制限 - 単一データベースおよび SQL Database の DTU ベースのリソース制限 - エラスティック プールに関するページを参照してください。For overall resource limits, see SQL Database vCore-based resource limits - single databases and SQL Database DTU-based resource limits - elastic pools.