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

適用対象:Azure SQL Database

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

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

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

影響

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

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

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

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

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

待機時間

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

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

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

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

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

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

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

$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

$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」を参照してください。

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 であり、それに付属のストレージ容量は 250 GB だけなので、追加ストレージ コストが適用されます。 したがって、追加ストレージ容量は 500 GB – 250 GB = 250 GB になります。 追加ストレージの価格については、「Azure SQL Database の価格」を参照してください。 実際に使われる領域の容量が付属のストレージ容量より少ない場合、データベースの最大サイズを付属の容量に減らすことで、この追加コストを回避できます。
• geo レプリケーションが有効な状態でデータベースをアップグレードする場合、そのセカンダリ データベースを目的のサービス レベルとコンピューティング サイズにアップグレードしてから、プライマリ データベースをアップグレードします (パフォーマンスを最大にするための一般的なガイダンス)。 別のエディションにアップグレードするには、セカンダリ データベースを先にアップグレードする必要があります。
• geo レプリケーションが有効な状態でデータベースをダウングレードする場合、そのプライマリ データベースを目的のサービス レベルとコンピューティング サイズにダウングレードしてから、セカンダリ データベースをダウングレードします (パフォーマンスを最大にするための一般的なガイダンス)。 別のエディションにダウングレードするには、プライマリ データベースを先にダウングレードする必要があります。
• 各種サービス レベルに応じて、復元サービスの内容は異なります。 Basic レベルにダウングレードする場合は、バックアップ保有期間が短くなります。 「Azure SQL Database の自動バックアップ」を参照してください。
• データベースに対する新しいプロパティは、変更が完了するまで適用されません。
• サービス レベルを変更するときにデータベースをスケーリングするためにデータのコピーが必要な場合 (「待機時間」を参照)、スケーリング操作と並行してリソース使用率が高いと、スケーリング時間が長くなる可能性があります。 高速データベース復旧では、実行時間の長いトランザクションのロールバックは大きな遅延の原因ではありませんが、リソースの同時使用量が多いほど、スケーリングのためのコンピューティング、ストレージ、ネットワーク帯域幅のリソースが少なくなる可能性があります(特に、コンピューティング サイズが小さい場合)。

課金

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

ストレージ サイズの変更

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

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

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

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

  注

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

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

• ストレージの価格の詳細については、「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 の価格」を参照してください。

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 購入モデルを使用した単一データベースのリソース制限 - Azure SQL Database