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 autoscaling and bills per second for compute used.

最初に仮想コア数または 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

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

  1. データベース用に新しいコンピューティング インスタンスを作成するCreate a 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 a 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.

LatencyLatency

サービス レベルの変更、単一データベースまたはエラスティック プールのコンピューティング サイズのスケーリング、エラスティック プールとの間のデータベースの移動、またはエラスティック プール間でのデータベースの移動に伴う推定待ち時間は、次のようにパラメーター化されます。The estimated latency to change the service tier, scale the compute size of a single database or elastic pool, move a database in/out of an elastic pool, or move a database between elastic pools 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),
汎用の単一データベースまたはエラスティック プールGeneral Purpose single database or elastic pool
Premium または Business Critical の単一データベースまたはエラスティック プールPremium or Business Critical single database or elastic pool ハイパースケールHyperscale
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
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  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),
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
•  単一データベースの場合は、使用される領域とは関係ない一定時間の待機時間•  For single databases, constant time latency independent of space used
•  単一データベースの場合は、通常 5 分未満•  Typically, less than 5 minutes for single databases
•  エラスティック プールの場合は、データベースの数に比例•  For elastic pools, proportional to the number of databases
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  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
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
•  データのコピーのために使用されるデータベース領域に比例した待機時間•  Latency proportional to database space used due to data copying
•  通常、使用される領域の GB あたり 1 分未満•  Typically, less than 1 minute per GB of space used
HyperscaleHyperscale 該当なしN/A 該当なしN/A 該当なしN/A •  使用される領域とは関係ない一定時間の待機時間•  Constant time latency independent of space used
•  通常は 2 分未満•  Typically, less than 2 minutes

注意

さらに、Standard (S2-S12) データベースと General Purpose データベースでは、データベースで Premium ファイル共有 (PFS) ストレージが使用されている場合、エラスティック プールとの間、またはエラスティック プール間でデータベースを移動するための待ち時間は、データベース サイズに比例します。Additionally, for Standard (S2-S12) and General Purpose databases, latency for moving a database in/out of an elastic pool or between elastic pools will be proportional to database size if the database is using Premium File Share (PFS) storage.

データベースで PFS ストレージが使用されているかどうかを確認するには、データベースのコンテキストで次のクエリを実行します。To determine if a database is using PFS storage, execute the following query in the context of the database. AccountType 列の値が PremiumFileStorage または PremiumFileStorage-ZRS の場合、データベースでは PFS ストレージが使用されています。If the value in the AccountType column is PremiumFileStorage or PremiumFileStorage-ZRS, the database is using PFS storage.

SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

ヒント

実行中の操作の監視については、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 changes

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

Azure ポータルThe Azure portal

[データベースの概要] ブレードで、 [通知] に移動し、進行中の操作があることを示すタイルをクリックします。In the database overview blade, navigate to Notifications and click on the tile indicating there's 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

  • より上位のサービス レベルまたはコンピューティング サイズにアップグレードしても、より大きなサイズ (最大サイズ) を明示的に指定しない限り、データベースの最大サイズは増加しません。If you're upgrading to a higher service tier or compute size, the database max size doesn't 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. 追加ストレージの価格については、「Azure SQL Database の価格」を参照してください。For pricing of extra storage, see Azure 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 edition, it's a requirement that the secondary database is upgraded first.
  • 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, it's a requirement that the primary database is downgraded first.
  • サービス階層によって、提供されている復元サービスは異なります。The restore service offerings are different for the various service tiers. Basic レベルにダウングレードする場合は、バックアップのリテンション期間が短くなります。If you're downgrading to the Basic tier, there's a lower backup retention period. Azure SQL Database のバックアップに関する記事をご覧ください。See Azure SQL Database Backups.
  • データベースに対する新しいプロパティは、変更が完了するまで適用されません。The new properties for the database aren't applied until the changes are complete.

課金Billing

使用状況や、データベースのアクティブな期間が 1 時間未満だったかどうかには関係なく、データベースが存在する 1 時間ごとに、その 1 時間の間に適用された最も高いサービス レベル + コンピューティング サイズを使用して課金されます。You're 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 data storage max size limit using 1-GB increments. 構成可能な最小データ ストレージは 1 GB です。The minimum configurable data storage is 1 GB. リソース制限のドキュメント ページにて、単一データベースおよびエラスティック プールの各サービス目標におけるデータ ストレージの最大サイズの制限をご確認ください。See resource limit documentation pages for single databases and elastic pools for data storage max size limits in each service objective.
  • 単一データベースのストレージは、Azure portalTransact-SQLPowerShellAzure CLI、または REST API を使って最大サイズを増減してプロビジョニングできます。Data storage for a single database can be provisioned by increasing or decreasing its max size using the Azure portal, Transact-SQL, PowerShell, Azure CLI, or REST API. バイトで指定する最大サイズの値は、1 GB (1073741824 バイト) の倍数である必要があります。If the max size value is specified in bytes, it must be a multiple of 1 GB (1073741824 bytes).
  • データベースのデータ ファイルに格納できるデータ量は、データ ストレージに構成されている最大サイズによって制限されます。The amount of data that can be stored in the data files of a database is limited by the configured data storage max size. Azure SQL Database では、この記憶域のほかに 30% さらに多いストレージを、トランザクション ログで使用するために自動的に割り当てます。In addition to that storage, Azure SQL Database automatically allocates 30% more storage to be used for the transaction log.
  • Azure SQL Database では、tempdb データベースの仮想コアごとに 32 GB が自動的に割り当てられます。Azure SQL Database automatically allocates 32 GB per vCore for the tempdb database. tempdb は、すべてのサービス レベルのローカル SSD ストレージにあります。tempdb is located on the local SSD storage in all service tiers.
  • 単一データベースまたはエラスティック プールのストレージ料金は、データ ストレージとトランザクション ログ ストレージの容量の合計にサービス レベルのストレージ ユニットを掛けて計算します。The price of storage for a single database or an elastic pool is the sum of data storage and transaction log storage amounts multiplied by the storage unit price of the service tier. tempdb のコストは価格に含まれています。The cost of tempdb is included in the price. ストレージの価格について詳しくは、「Azure SQL Database の価格」を参照してください。For details on storage price, see Azure 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. 追加ストレージの価格について詳しくは、「Azure SQL Database の価格」を参照してください。For details on the price of extra storage, see Azure 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.

Geo レプリケートされたデータベースGeo-replicated database

レプリケートされたセカンダリ データベースのデータベース サイズを変更するには、プライマリ データベースのサイズを変更します。To change the database size of a replicated secondary database, change the size of the primary database. この変更がセカンダリ データベースでもレプリケートされて実装されます。This change will then be replicated and implemented on the secondary database as well.

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

現在、1 TB を超える Premium レベルのストレージは、中国東部、中国北部、ドイツ中部、ドイツ北東部、を除くすべてのリージョンで利用できます。More than 1 TB of storage in the Premium tier is currently available in all regions except: China East, China North, Germany Central, and Germany Northeast. これらのリージョンでは、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 doesn't exceed max size limits of the new compute size.
  • アクティブ geo レプリケーションのシナリオの場合:For active geo-replication scenarios:
    • geo レプリケーションのリレーションシップの設定:プライマリ データベースが P11 または P15 である場合は、セカンダリも P11 または P15 である必要があります。Setting up a geo-replication relationship: If the primary database is P11 or P15, the secondary(ies) must also be P11 or P15. コンピューティング サイズが小さい場合は、1 TB を超える領域をサポートできないため、セカンダリとして拒否されます。Lower compute size are rejected as secondaries since they aren't 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 doesn't support more than 1 TB, the primary isn't upgraded.
  • 1 TB を超える P11/P15 データベースの読み込みに Import/Export サービスを使用することはサポートされていません。Using the Import/Export service for loading P11/P15 databases with more than 1 TB isn't supported. SqlPackage.exe を使用して、データをインポートおよびエクスポートしてください。Use SqlPackage.exe to import and export data.

次のステップNext steps

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