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

適用対象: Azure SQL データベース

この記事では、プロビジョニングされたコンピューティング レベルで Azure SQL Database 用に使用できるコンピューティング リソースとストレージ リソースをスケーリングする方法について説明します。 また、サーバーレス コンピューティング レベルは、コンピューティングの自動スケーリングと、使用されたコンピューティングの 1 秒あたりの請求額を提供します。

仮想コアまたは DTU の数を最初に選択した後は、次を使用して、実際のエクスペリエンスに基づいて、単一データベースを動的にスケールアップまたはダウンできます。

• Transact-SQL
• Azure Portal
• PowerShell
• Azure CLI
• REST API

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space for databases in Azure SQL Database」(Azure SQL Database でデータベースのファイル スペースを管理する) を参照してください。

Note

Microsoft Entra ID の、旧称は Azure Active Directory（Azure AD）です。

影響

サービス レベルまたはコンピューティング サイズの変更には、主に次の手順を実行するサービスが含まれます。

1. データベース用に新しいコンピューティング インスタンスを作成する

   要求されたサービス レベルとコンピューティング サイズを持つ新しいコンピューティング インスタンスが作成されます。 サービス レベルとコンピューティング サイズの変更の組み合わせの中には、新しいコンピューティング インスタンスにデータベースのレプリカを作成する必要があるものがあります。これにはデータのコピーも含まれ、全体の待機時間に大きく影響する場合があります。 いずれにしても、この手順の間、データベースはオンラインのままで、接続は元のコンピューティング インスタンスのデータベースに引き続き向けられます。

2. 接続のルーティングを新しいコンピューティング インスタンスに切り替えます。

   元のコンピューティング インスタンス内のデータベースへの既存の接続が削除されます。 新しいコンピューティング インスタンス内のデータベースへの新しい接続が確立されます。 サービス レベルとコンピューティング サイズの一部の組み合わせの変更では、データベース ファイルがデタッチされ、切り替え時に再アタッチされます。 いずれにしても、切り替えにより、データベースが使用できなくなる短時間の中断が発生する場合があります。中断は通常は 30 秒未満で、多くの場合はほんの数秒です。 接続が削除されたときに長時間実行されているトランザクションがあると、切断されたトランザクションを復旧するために、この手順の所要時間が長くなる場合があります。 Azure SQL の高速データベース復旧により、長時間実行されているトランザクションの中断による影響を軽減できます。

重要

ワークフローのいずれの手順でもデータが失われることはありません。 サービス レベルの変更中に Azure SQL Database を使用するアプリケーションとコンポーネントに、何らかの再試行ロジックを実装したことを確認してください。

Latency

サービス レベルの変更、単一データベースまたはエラスティック プールのコンピューティング サイズのスケーリング、エラスティック プールとの間のデータベースの移動、またはエラスティック プール間でのデータベースの移動に伴う推定待ち時間は、次のようにパラメーター化されます。

データベースのスケーリングの待機時間	Basic 単一データベース、 Standard 単一データベース (S0-S1) へ	Standard 単一データベース (S2-S12)、 General Purpose 単一データベース、 Basic エラスティック プール データベース、 Standard エラスティック プール データベース、 General Purpose プールされたデータベースへ	Premium 単一データベースまたはプールされたデータベース、 Business Critical 単一データベースまたはプールされたデータベースへ	Hyperscale 単一データベースまたはプールされたデータベース
Basic 単一データベース、 Standard 単一データベース (S0-S1)	• 使用される領域とは関係ない一定時間の待機時間 • 通常は 5 分未満	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満
Basic プールされたデータベース、 Standard 単一データベース (S2-S12) 、Standard プールされたデータベース、 General Purpose 単一データベース、またはプールされたデータベース	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満	• 単一データベースの場合は、使用される領域とは関係ない一定時間の待機時間 • 単一データベースの場合は、通常 5 分未満 • エラスティック プールの場合は、データベースの数に比例	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満
単一データベースまたはプールされたデータベースプレミアム、 Business Critical 単一データベースまたはプールされたデータベース	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満	• データのコピーのために使用されるデータベース領域に比例した待機時間 • 通常、使用される領域の GB あたり 1 分未満
Hyperscale 単一データベースまたはプールされたデータベースから	該当なし	サポートされているシナリオと制限については、「Hyperscale から逆に移行する」を参照してください。	該当なし	• 使用される領域とは関係ない一定時間の待機時間 • 通常は 2 分未満

Note

• さらに、Standard (S2-S12) データベースと General Purpose データベースでは、データベースで Premium ファイル共有 (PFS) ストレージが使用されている場合、エラスティック プールとの間、またはエラスティック プール間でデータベースを移動するための待ち時間は、データベース サイズに比例します。
• エラスティック プールとの間でデータベースを移動する場合、エラスティック プールで使用される領域ではなく、データベースの使用領域のみが待機時間に影響します。
• データベースで PFS ストレージが使用されているかどうかを確認するには、データベースのコンテキストで次のクエリを実行します。 AccountType 列の値が PremiumFileStorage または PremiumFileStorage-ZRS の場合、データベースでは PFS ストレージが使用されています。

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');

Note

• 単一データベースを Business Critical サービス レベルから General Purpose サービス レベルにスケーリングする場合、ゾーン冗長プロパティは既定で同じままになります。
• General Purpose 単一データベースのゾーン冗長性が変更されたときのスケーリング操作の待機時間は、データベース サイズに比例します。

ヒント

実行中の操作の監視については、SQL REST API を使った操作の管理、CLI を使った操作の管理、T-SQL を使った操作の管理に関する各ページと、2 つの PowerShell コマンド Get-AzSqlDatabaseActivity と Stop-AzSqlDatabaseActivity。

スケーリングの変更を監視または取り消す

サービス レベルの変更またはコンピューティングの再スケーリング操作を監視し、また取り消すことができます。

Azure Portal

進行中のデプロイについては、SQL Database の [概要] ページで、スケーリング操作が進行中であることを示すバナーを探し、[詳細を表示] リンクを選択します。

結果の [進行中の操作] ページで、[この操作を取り消す] を選択します。

PowerShell

コンピューターで PowerShell コマンドを呼び出すには、Az パッケージ バージョン 9.7.0 かそれ以降のバージョンをローカルでインストールする必要があります。 または、Azure Cloud Shell を使用して shell.azure.com で Azure PowerShell を実行することを検討してください。

まず、Azure にログインし、サブスクリプションに適切なコンテキストを設定します。

Login-AzAccount
$SubscriptionID = "<YourSubscriptionIdHere>"
Select-AzSubscription -SubscriptionName $SubscriptionID

スケーリング操作を含むデータベースに対する操作を監視するには、Get-AzSqlDatabaseActivity を使用 します。 次の例では、現在実行中の各操作に対して OperationId を返します。

Get-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01"

データベース スケールなどの非同期操作を取り消すには、次の例のように、操作を特定し、特定のOperationIdで Stop-AzSqlDatabaseActivity を使用します。

Stop-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" -OperationId af97005d-9243-4f8a-844e-402d1cc855f5

Azure CLI

Cloud Shell ターミナルから、次のサンプル コマンドを使用して、現在実行中の操作を識別します。 Cloud Shell ターミナルから、$resourceGroupName、$serverName、および $databaseName 変数を設定し、次のコマンドを実行します。

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv

データベース スケールなどの非同期処理を停止するには、Cloud Shell ターミナルから $resourceGroupName、$serverName、$databaseName 変数を設定し、次のコマンドを実行します。

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
$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"
}

アクセス許可

Transact-SQL を使用したデータベースのスケーリング方法: ALTER DATABASE を使用します。 データベースをスケーリングするには、ログインがサーバー管理者のログイン (Azure SQL Database 論理サーバーのプロビジョニング時に作成されたもの)、サーバーの Microsoft Entra 管理者、master の dbmanager データベース ロールのメンバー、現在のデータベースの db_owner データベース ロールのメンバー、またはデータベースの dbo のいずれかである必要があります。 詳細については、[ALTER DATABASE](/sql/t-sql/statements/alter-database-transact-sql-file-and-filegroup-options) に関する記事をご覧ください。

Azure portal、PowerShell、Azure CLI、または REST API を使用したデータベースのスケーリング方法: Azure RBAC のアクセス許可 (特に共同作成者、SQL DB 共同作成者ロール、または SQL Server 共同作成者 Azure RBAC ロール) が必要です。 詳細については、Azure RBAC: 組み込みのロールに関するページをご覧ください。

その他の注意点

• より上位のサービス レベルまたはコンピューティング サイズにアップグレードしても、より大きなサイズ (最大サイズ) を明示的に指定しない限り、データベースの最大サイズは増加しません。
• データベースをダウングレードするには、データベースで使われている領域がダウングレード後のサービス レベルとコンピューティング サイズで許可されている最大サイズより小さい必要があります。
• Premium から Standard レベルにダウングレードするときは、(1) データベースの最大サイズがターゲットのコンピューティング サイズでサポートされていて、かつ、(2) 最大サイズがターゲットのコンピューティング サイズで付属のストレージ容量を超えている場合、追加ストレージ コストが適用されます。 たとえば、最大サイズ 500 GB の P1 データベースを S3 にダウンサイズする場合、S3 がサポートする最大サイズは 1 TB であり、S3 で付属のストレージ容量は 250 GB だけなので、追加ストレージ コストが適用されます。 したがって、追加ストレージ容量は 500 GB – 250 GB = 250 GB になります。 追加ストレージの価格については、「Azure SQL Database の価格」を参照してください。 実際に使われる領域の量が付属のストレージの量より少ない場合、データベースの最大サイズを付属の量に減らすことで、この追加コストを回避できます。
• geo レプリケーションが有効な状態でデータベースをアップグレードする場合、そのセカンダリ データベースを目的のサービス レベルとコンピューティング サイズにアップグレードしてから、プライマリ データベースをアップグレードします (パフォーマンスを最大にするための一般的なガイダンス)。 別のエディションにアップグレードするには、セカンダリ データベースを先にアップグレードする必要があります。
• geo レプリケーションが有効な状態でデータベースをダウングレードする場合、そのプライマリ データベースを目的のサービス レベルとコンピューティング サイズにダウングレードしてから、セカンダリ データベースをダウングレードします (パフォーマンスを最大にするための一般的なガイダンス)。 別のエディションにダウングレードするには、プライマリ データベースを先にダウングレードする必要があります。
• サービス階層によって、提供されている復元サービスは異なります。 Basic レベルにダウングレードする場合は、バックアップのリテンション期間が短くなります。 「Azure SQL データベースの自動バックアップ」を参照してください。
• データベースに対する新しいプロパティは、変更が完了するまで適用されません。
• サービス レベルを変更するときにデータベースをスケーリングする ( 「待機時間」を参照) 必要がある場合は、スケール操作と並列のリソース使用率が高いと、スケーリング時間が長くなる可能性があります。 高速データベース復旧 (ADR) では、長期にわたるトランザクションのロールバックが遅延の主な原因になることはありませんが、並列のリソース使用率が高いと、特に、コンピューティングのサイズが小さい場合に、スケーリングのために残されるコンピューティング、ストレージ、ネットワーク帯域幅のリソースが減ってしまうことがあります。

請求

使用状況や、データベースのアクティブな期間が 1 時間未満だったかどうかには関係なく、データベースが存在する 1 時間ごとに、その 1 時間の間に適用された最も高いサービス レベル + コンピューティング サイズを使用して課金されます。 たとえば、Single Database を作成し、それを 5 分後に削除した場合、請求書にはデータベース時間として 1 時間の請求が表示されます。

ストレージ サイズの変更

仮想コアベースの購入モデル

• ストレージは、1 GB の増分値を使用して、データ ストレージの最大サイズの上限までプロビジョニングできます。 構成可能な最小データ ストレージは 1 GB です。 各サービス目標のデータ ストレージの最大サイズ制限については、「仮想コア購入モデルを使用した単一データベースに対するリソース制限」と「DTU 購入モデルを使用した単一データベースに対するリソース制限」のリソース制限に関するドキュメント ページを参照してください。

• 単一データベースのストレージは、Azure portal、Transact-SQL、PowerShell、Azure CLI、または REST API を使って最大サイズを増減してプロビジョニングできます。 バイトで指定する最大サイズの値は、1 GB (1073741824 バイト) の倍数である必要があります。

• データベースのデータ ファイルに格納できるデータ量は、データ ストレージに構成されている最大サイズによって制限されます。 そのストレージのほかに、Azure SQL データベースは、トランザクション ログで使用するためにStorageを 30% 自動的に追加します。 単一データベースまたはエラスティック プールのストレージ料金は、データ ストレージとトランザクション ログ ストレージの容量の合計にサービス レベルのストレージ ユニットを掛けて計算します。 たとえば、データ ストレージが 10 GB に設定されている場合、追加のトランザクション ログ ストレージは 10 GB * 30% = 3 GB、課金対象ストレージの合計量は 10 GB + 3 GB = 13 GB となります。

  Note

  トランザクション ログ ファイルの最大サイズは自動的に管理され、場合によってはデータ ストレージの最大サイズの 30% を超える場合があります。 これによって、データベースのストレージの価格が上がることはありません。

• Azure SQL Database では、tempdb データベースの仮想コアごとに 32 GB が自動的に割り当てられます。 tempdb は、すべてのサービス レベルのローカル SSD ストレージにあります。 tempdb のコスト は、単一データベースまたはElastic Poolの価格に含まれています。

• ストレージの価格について詳しくは、「Azure SQL Database の価格」を参照してください。

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space for databases in Azure SQL Database」(Azure SQL Database でデータベースのファイル スペースを管理する) を参照してください。

DTU ベースの購入モデル

• 単一データベースの DTU 価格には、追加コストなしで一定量のストレージが含まれます。 付属の容量を超える分のストレージについては、追加費用を払うことで、1 TB までは 250 GB 単位で、1 TB 以降は 256 GB 単位で、最大サイズ制限までプロビジョニングできます。 付属するストレージ容量と最大サイズ制限については、「単一データベース: ストレージ サイズとコンピューティング サイズ」をご覧ください。
• 単一データベースの追加ストレージは、Azure portal、Transact-SQL、PowerShell、Azure CLI、または REST API を使ってサイズを最大に増やすことでプロビジョニングできます。
• 単一データベースの追加ストレージの料金は、追加ストレージ容量にサービス レベルの追加ストレージ単価を掛けて計算します。 追加ストレージの価格について詳しくは、「Azure SQL Database の価格」を参照してください。

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space for databases in Azure SQL Database」(Azure SQL Database でデータベースのファイル スペースを管理する) を参照してください。

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

レプリケートされたセカンダリ データベースのデータベース サイズを変更するには、プライマリ データベースのサイズを変更します。 この変更がセカンダリ データベースでもレプリケートされて実装されます。

最大サイズが 1 TB を超える場合の P11 と P15 の制約

現在、1 TB を超える Premium レベルのストレージは、中国東部、中国北部、ドイツ中部、ドイツ北東部、を除くすべてのリージョンで利用できます。 これらのリージョンでは、Premium レベルのストレージの最大容量は 1 TB です。 最大サイズが 1 TB を超える P11 および P15 データベースには、次の考慮事項と制限事項が適用されます。

• P11 または P15 のデータベースの最大サイズが 1 TB を超える値に設定されていた場合、P11 または P15 のデータベースにしか復元またはコピーできません。 その後、再スケーリング操作の時点で割り当てられた領域の量が新しいコンピューティング サイズの最大サイズの上限を超えなければ、データベースを異なるコンピューティング サイズに再スケーリングできます。
• アクティブ geo レプリケーションのシナリオの場合:
  • geo レプリケーションのリレーションシップの設定:プライマリ データベースが P11 または P15 である場合は、セカンダリも P11 または P15 である必要があります。 コンピューティング サイズが小さい場合は、1 TB を超える領域をサポートできないため、セカンダリとして拒否されます。
  • geo レプリケーションのリレーションシップでのプライマリ データベースのアップグレード:プライマリ データベースで最大サイズを 1 TB 超に変更すると、セカンダリ データベースでも同じ変更がトリガーされます。 プライマリに対する変更を有効にするには、両方のアップグレードが正常に完了する必要があります。 1 TB を超えるオプションに関するリージョンの制限が適用されます。 セカンダリが 1 TB を超える領域をサポートしないリージョンにある場合、プライマリはアップグレードされません。
• 1 TB を超える P11/P15 データベースの読み込みに Import/Export サービスを使用することはサポートされていません。 SqlPackage を使用して、データをインポートおよびエクスポートしてください。

関連するコンテンツ

• 仮想コア購入モデルを使用した単一データベースに対するリソース制限
• DTU 購入モデルを使用した単一データベースに対するリソース制限