仮想コア サービス レベルの中から選択し、DTU サービス レベルから移行するChoose among the vCore service tiers and migrate from the DTU service tiers

仮想コア (vCore) ベースの購入モデルでは、コンピューティング リソースとストレージ リソースを独立にスケーリングし、オンプレミスのパフォーマンスと一致させて、価格を最適化することができます。The virtual core (vCore)-based purchasing model lets you independently scale compute and storage resources, match on-premises performance, and optimize price. また、ハードウェアの世代を選択することもできます。It also lets you choose the generation of hardware:

  • Gen4: Intel E5-2673 v3 (Haswell) 2.4 GHz プロセッサに基づく最大 24 個の論理 CPU、仮想コア = 1 PP (物理コア)、7 GB/仮想コア、接続されている SSDGen4: Up to 24 logical CPUs based on Intel E5-2673 v3 (Haswell) 2.4-GHz processors, vCore = 1 PP (physical core), 7 GB per vCore, attached SSD
  • Gen5: Intel E5-2673 v4 (Broadwell) 2.3 GHz プロセッサに基づく最大 80 個の論理 CPU、仮想コア = 1 LP (ハイパースレッド)、プロビジョニングされたコンピューティングに 5.1 GB/仮想コア、サーバーレス コンピューティングに最大 24 GB/仮想コア、高速 eNVM SSDGen5: Up to 80 logical CPUs based on Intel E5-2673 v4 (Broadwell) 2.3-GHz processors, vCore = 1 LP (hyper-thread), 5.1 GB per vCore for provisioned compute and up to 24 GB per vCore for serverless compute, fast eNVM SSD

Gen4 ハードウェアでは、仮想コアあたり大幅に多くのメモリが提供されます。Gen4 hardware offers substantially more memory per vCore. 一方、Gen5 ハードウェアでは、コンピューティング リソースをはるかに高くまでスケールアップできます。However, Gen5 hardware allows you to scale up compute resources much higher.

重要

新しい Gen4 データベースは、オーストラリア東部とブラジル南部リージョンでサポートされなくなりました。New Gen4 databases are no longer supported in the Australia East or Brazil South regions.

注意

DTU ベースのサービス レベルについては、DTU ベースの購入モデルのサービス レベルに関するページを参照してください。For information about the DTU-based service tiers, see Service tiers for the DTU-based purchasing model. DTU ベースの購入モデルと仮想コアベースの購入モデルのサービス レベルの違いについては、Azure SQL Database の購入モデルに関するページを参照してください。For information about the differences between the service tiers for the DTU-based and the vCore-based purchasing models, see Azure SQL Database purchasing models.

サービス レベルの特性Service-tier characteristics

仮想コアベースの購入モデルには、General Purpose、Hyperscale、および Business Critical の 3 つのサービス レベルが用意されています。The vCore-based purchasing model provides three service tiers: general purpose, hyperscale, and business critical. これらのサービス レベルは、さまざまなコンピューティング サイズ、高可用性の設計、障害分離の方法、ストレージの種類とサイズ、および I/O 範囲によって区別されます。These service tiers are differentiated by a range of compute sizes, high-availability designs, fault-isolation methods, types and sizes of storage, and I/O ranges.

バックアップ用に必要なストレージと保有期間を個別に構成する必要があります。You must separately configure the required storage and retention period for backups. バックアップの保有期間を設定するには、Azure Portal を開いて (データベースではなく) サーバーに移動した後、 [Manage Backups] (バックアップの管理) > [ポリシーの構成] > [Point In Time Restore Configuration] (ポイントインタイム リストア構成) > [7 ~ 35 日] に移動します。To set the backup-retention period, open the Azure portal, go to the server (not the database), and then go to Manage Backups > Configure Policy > Point In Time Restore Configuration > 7 - 35 days.

次の表は、これらの 3 つのレベルの違いについて説明しています。The following table explains the differences between the three tiers:

汎用General purpose Business CriticalBusiness critical HyperscaleHyperscale
最適な用途Best for 予算重視のバランスの取れたコンピューティングおよびストレージ オプションを提供します。Offers budget oriented balanced compute and storage options. トランザクション レートが高く IO 待ち時間が低い OLTP アプリケーション。OLTP applications with high transaction rate and low IO latency. 同期的に更新された複数のレプリカを使用して、最高の耐障害性と高速フェールオーバーを提供します。Offers highest resilience to failures and fast failovers using multiple synchronously updated replicas. ほとんどのビジネス ワークロード。Most business workloads. 最大 100 TB までのストレージ サイズの自動スケーリング、垂直および水平方向へのなめらかなコンピューティング スケーリング、データベースの高速復元。Auto-scaling storage size up to 100 TB, fluid vertical and horizontal compute scaling, fast database restore.
ComputeCompute プロビジョニングされるコンピューティング:Provisioned compute:
Gen4:1 ~ 24 の仮想コアGen4: 1 to 24 vCores
Gen5:2 ~ 80 の仮想コアGen5: 2 to 80 vCores
サーバーレス コンピューティング:Serverless compute:
Gen5:0.5 - 16 の仮想コアGen5: 0.5 - 16 vCores
プロビジョニングされるコンピューティング:Provisioned compute:
Gen4:1 ~ 24 の仮想コアGen4: 1 to 24 vCores
Gen5:2 ~ 80 の仮想コアGen5: 2 to 80 vCores
プロビジョニングされるコンピューティング:Provisioned compute:
Gen4:1 ~ 24 の仮想コアGen4: 1 to 24 vCores
Gen5:2 ~ 80 の仮想コアGen5: 2 to 80 vCores
メモリMemory プロビジョニングされるコンピューティング:Provisioned compute:
Gen4:仮想コアあたり 7 GBGen4: 7 GB per vCore
Gen5:仮想コアあたり 5.1 GBGen5: 5.1 GB per vCore
サーバーレス コンピューティング:Serverless compute:
Gen5:仮想コアあたり最大 24 GBGen5: Up to 24 GB per vCore
プロビジョニングされるコンピューティング:Provisioned compute:
Gen4:仮想コアあたり 7 GBGen4: 7 GB per vCore
Gen5:仮想コアあたり 5.1 GBGen5: 5.1 GB per vCore
プロビジョニングされるコンピューティング:Provisioned compute:
Gen4:仮想コアあたり 7 GBGen4: 7 GB per vCore
Gen5:仮想コアあたり 5.1 GBGen5: 5.1 GB per vCore
StorageStorage リモート ストレージを使用します。Uses remote storage.
単一データベースとエラスティック プールにプロビジョニングされるコンピューティング:Single database and elastic pool provisioned compute:
5 GB – 4 TB5 GB – 4 TB
サーバーレス コンピューティング:Serverless compute:
5 GB - 3 TB5 GB - 3 TB
マネージド インスタンス:32 GB ~ 8 TBManaged instance: 32 GB - 8 TB
ローカル SSD ストレージを使用します。Uses local SSD storage.
単一データベースとエラスティック プールにプロビジョニングされるコンピューティング:Single database and elastic pool provisioned compute:
5 GB – 4 TB5 GB – 4 TB
マネージド インスタンス:Managed instance:
32 GB ~ 4 TB32 GB - 4 TB
必要に応じた、ストレージの柔軟な自動拡張。Flexible autogrow of storage as needed. 最大 100 TB のストレージをサポートします。Supports up to 100 TB of storage. ローカル バッファー プール キャッシュとローカル データ ストレージにローカル SSD ストレージを使用します。Uses local SSD storage for local buffer-pool cache and local data storage. 最終的な長期間のデータ ストアとして Azure リモート ストレージを使用します。Uses Azure remote storage as final long-term data store.
I/O スループット (概算)I/O throughput (approximate) 単一データベースとエラスティック プール:仮想コアあたり 500 IOPS (最大 40000 IOPS)。Single database and elastic pool: 500 IOPS per vCore up to 40000 maximum IOPS.
マネージド インスタンス:ファイルのサイズに依存します。Managed instance: Depends on size of file.
コアあたり 5000 IOPS (最大 200,000 IOPS)。5000 IOPS per core up to 200,000 maximum IOPS Hyperscale は、複数のレベルのキャッシュが存在する複数レベル アーキテクチャです。Hyperscale is a multi-tiered architecture with caching at multiple levels. 有効な IOPS はワークロードによって異なります。Effective IOPs will depend on the workload.
可用性Availability 1 レプリカ、読み取りスケール レプリカなし1 replica, no read-scale replicas 3 レプリカ、1 読み取りスケール レプリカ3 replicas, 1 read-scale replica,
ゾーン冗長高可用性 (HA)zone-redundant high availability (HA)
1 読み取り/書き込みレプリカ、および 0 ~ 4 読み取りスケール レプリカ 1 read-write replica, plus 0-4 read-scale replicas
バックアップBackups 読み取りアクセス geo 冗長ストレージ (RA-GRS)、7 ~ 35 日 (既定では 7 日)Read-access geo-redundant storage (RA-GRS), 7-35 days (7 days by default) RA-GRS、7 ~ 35 日 (既定では 7 日)RA-GRS, 7-35 days (7 days by default) Azure リモート ストレージでのスナップショット ベースのバックアップ。Snapshot-based backups in Azure remote storage. このようなスナップショットを使用して復元することで、高速復元が可能になります。Restores use these snapshots for fast recovery. バックアップは瞬時であり、コンピューティング I/O パフォーマンスには影響を与えません。Backups are instantaneous and don't impact compute I/O performance. 復元は高速であり、データ サイズに左右される操作ではありません (数時間または数日ではなく、数分で完了)。Restores are fast and aren't a size-of-data operation (taking minutes rather than hours or days).
メモリ内In-memory サポートされていませんNot supported サポートされていますSupported サポートされていませんNot supported

注意

Azure 無料アカウントと組み合わせて Basic サービス レベルで無料の Azure SQL データベースを取得できます。You can get a free Azure SQL database at the basic service tier in conjunction with an Azure free account. 詳細については、「Azure の無料アカウントでマネージド クラウド データベースを作成する」を参照してください。For more information, see Create a managed cloud database with your Azure free account.

Azure ハイブリッド特典Azure Hybrid Benefit

仮想コアベースの購入モデルのプロビジョニングされたコンピューティング レベルでは、SQL Server 向けの Azure ハイブリッド特典を使用して、既存のライセンスを SQL Database の割引料金で交換できます。In the provisioned compute tier of the vCore-based purchasing model, you can exchange your existing licenses for discounted rates on SQL Database by using Azure Hybrid Benefit for SQL Server. この Azure 特典では、ソフトウェア アシュアランスを含むオンプレミスの SQL Server ライセンスを使用して、Azure SQL Database について最大 30 % 節約できます。This Azure benefit allows you to save up to 30 percent on Azure SQL Database by using your on-premises SQL Server licenses with Software Assurance.

価格

Azure ハイブリッド特典では、SQL データベース エンジン自体には既存の SQL Server ライセンスを使用して、基になる Azure インフラストラクチャに対してのみ支払うか (基本コンピューティングの価格)、または基になるインフラストラクチャと SQL Server ライセンスの両方に対して支払うか (ライセンス込みの価格) を選択できます。With Azure Hybrid Benefit, you can choose to pay only for the underlying Azure infrastructure by using your existing SQL Server license for the SQL database engine itself (Base Compute pricing), or you can pay for both the underlying infrastructure and the SQL Server license (License-Included pricing).

Azure Portal または次のいずれかの API を使用して、ライセンス モデルを選択または変更できます。You can choose or change your licensing model by using the Azure portal or by using one of the following APIs:

DTU ベースのモデルから仮想コア ベースのモデルに移行するMigrate from the DTU-based model to the vCore-based model

データベースの移行Migrate a database

DTU ベースの購入モデルから仮想コアベースの購入モデルへのデータベースの移行は、DTU ベースの購入モデルでの Standard および Premium サービス レベル間のアップグレードまたはダウングレードに似ています。Migrating a database from the DTU-based purchasing model to the vCore-based purchasing model is similar to upgrading or downgrading between the standard and premium service tiers in the DTU-based purchasing model.

DTU ベースのモデルから仮想コアベースの購入モデルへの移行は、Standard および Premium サービス レベルでのデータベース間の geo レプリケーションのリレーションシップのアップグレードまたはダウングレードに似ています。Migrating from the DTU-based model to the vCore-based purchasing model is similar to upgrading or downgrading the geo-replication relationships between databases in the standard and premium service tiers. 移行中に geo レプリケーションを停止する必要はありませんが、次のシーケンス処理のルールに従う必要があります。During migration, you don't have to stop geo-replication, but you must follow these sequencing rules:

  • アップグレードの場合は、最初にセカンダリ データベースをアップグレードしてから、プライマリをアップグレードする必要があります。When upgrading, you must upgrade the secondary database first, and then upgrade the primary.
  • ダウングレードは逆の順序で行います。つまり、最初にプライマリ データベースをダウングレードしてから、セカンダリをダウングレードします。When downgrading, reverse the order: you must downgrade the primary database first, and then downgrade the secondary.

2 つのエラスティック プール間で geo レプリケーションを使用している場合は、1 つのプールをプライマリとして、もう一方をセカンダリとして指定することをお勧めします。When you're using geo-replication between two elastic pools, we recommend that you designate one pool as the primary and the other as the secondary. その場合、エラスティック プールを移行するときは、同じシーケンス処理のガイダンスを使用する必要があります。In that case, when you're migrating elastic pools you should use the same sequencing guidance. ただし、プライマリ データベースとセカンダリ データベースの両方を含むエラスティック プールがある場合は、使用率が高い方のプールをプライマリとして扱い、それに応じてシーケンス処理のルールに従ってください。However, if you have elastic pools that contain both primary and secondary databases, treat the pool with the higher utilization as the primary and follow the sequencing rules accordingly.

次の表は、特定の移行シナリオのためのガイダンスを示しています。The following table provides guidance for specific migration scenarios:

現在のサービス レベルCurrent service tier 移行先のサービス レベルTarget service tier 移行の種類Migration type ユーザー操作User actions
標準Standard 汎用General purpose ラテラルLateral 任意の順序で移行できますが、適切な仮想コア サイズを確保する必要があります*Can migrate in any order, but need to ensure appropriate vCore sizing*
PremiumPremium Business CriticalBusiness critical ラテラルLateral 任意の順序で移行できますが、適切な仮想コア サイズを確保する必要があります*Can migrate in any order, but need to ensure appropriate vCore sizing*
StandardStandard Business CriticalBusiness critical アップグレードUpgrade セカンダリを最初に移行する必要がありますMust migrate secondary first
Business CriticalBusiness critical StandardStandard ダウングレードDowngrade プライマリを最初に移行する必要がありますMust migrate primary first
PremiumPremium 汎用General purpose ダウングレードDowngrade プライマリを最初に移行する必要がありますMust migrate primary first
汎用General purpose PremiumPremium アップグレードUpgrade セカンダリを最初に移行する必要がありますMust migrate secondary first
Business CriticalBusiness critical 汎用General purpose ダウングレードDowngrade プライマリを最初に移行する必要がありますMust migrate primary first
汎用General purpose Business CriticalBusiness critical アップグレードUpgrade セカンダリを最初に移行する必要がありますMust migrate secondary first

* Standard レベルでは 100 DTU ごとに少なくとも 1 つの仮想コアが必要であり、Premium レベルでは 125 DTU ごとに少なくとも 1 つの仮想コアが必要です。* Every 100 DTUs in the standard tier require at least 1 vCore, and every 125 DTUs in the premium tier require at least 1 vCore.

フェールオーバー グループを移行するMigrate failover groups

複数のデータベースが含まれるフェールオーバー グループの移行では、プライマリ データベースとセカンダリ データベースを個別に移行する必要があります。Migration of failover groups with multiple databases requires individual migration of the primary and secondary databases. その処理中は、同じ考慮事項とシーケンス処理ルールが適用されます。During that process, the same considerations and sequencing rules apply. データベースが仮想コアベースの購入モデルに変換された後も、フェールオーバー グループでは同じポリシー設定が引き続き有効です。After the databases are converted to the vCore-based purchasing model, the failover group will remain in effect with the same policy settings.

geo レプリケーションのセカンダリ データベースを作成するCreate a geo-replication secondary database

geo レプリケーションのセカンダリ データベース (geo セカンダリ) は、プライマリ データベースに対して使用したのと同じサービス レベルを使用してのみ作成できます。You can create a geo-replication secondary database (a geo-secondary) only by using the same service tier as you used for the primary database. ログ生成速度が速いデータベースの場合は、プライマリと同じコンピューティング サイズを持つ geo セカンダリを作成することをお勧めします。For databases with a high log-generation rate, we recommend creating the geo-secondary with the same compute size as the primary.

geo セカンダリを単一プライマリ データベースのエラスティック プール内に作成している場合は、そのプールの maxVCore 設定がプライマリ データベースのコンピューティング サイズに一致していることを確認してください。If you're creating a geo-secondary in the elastic pool for a single primary database, make sure the maxVCore setting for the pool matches the primary database's compute size. プライマリの geo セカンダリを別のエラスティック プール内に作成している場合は、そのプールに同じ maxVCore 設定を割り当てることをお勧めします。If you're creating a geo-secondary for a primary in another elastic pool, we recommend that the pools have the same maxVCore settings.

データベースのコピーを使用して DTU ベースのデータベースを仮想コア ベースのデータベースに変換するUse database copy to convert a DTU-based database to a vCore-based database

DTU ベース コンピューティング サイズのデータベースを、仮想コアベース コンピューティング サイズのデータベースにコピーする場合、コピー先のコンピューティング サイズが、コピー元データベースの最大データベース サイズをサポートしている限り、制限や特別なシーケンス処理は伴いません。You can copy any database with a DTU-based compute size to a database with a vCore-based compute size without restrictions or special sequencing as long as the target compute size supports the maximum database size of the source database. データベースのコピーでは、コピー操作が開始された時点のデータのスナップショットが作成され、ソースとターゲットの間でデータは同期されません。The database copy creates a snapshot of the data as of the starting time of the copy operation and doesn't synchronize data between the source and the target.

次の手順Next steps