Azure SQL Database を DTU ベースのモデルから仮想コアベースのモデルに移行する

[アーティクル]
07/25/2024

この記事では、DTU ベースの購入モデルから仮想コアベースの購入モデルに Azure SQL Database 内のデータベースを移行する方法について説明します。

データベースの移行

DTU ベースの購入モデルから仮想コアベースの購入モデルにデータベースを移行することは、期間と、移行プロセスの終了時の最小限のダウンタイムが似ている、Basic、Standard、および Premium サービスレベルのサービス目標間のスケーリングに似ています。仮想コアベースの購入モデルに移行されたデータベースは、同じ手順を使用して、いつでも DTU ベースの購入モデルに再び移行することができます。ただし、Hyperscale サービスレベルに移行されたデータベースは除きます。

Azure portal、PowerShell、Azure CLI、Transact-SQL を使用して、データベースを別の購入モデルに移行できます。

Azure portal を使用してデータベースを別の購入モデルに移行するには、次の手順に従います。

Azure portal で SQL データベースに移動します。
[設定] で、[コンピューティングとストレージ] を選択します。
サービスレベルのドロップダウンリストを使用して、新しい購入モデルとサービスレベルを選択します。

PowerShell を使用してデータベースを別の購入モデルに移行するには、次のサンプルのように Set-AzSqlDatabase を使用します。

$parameters = @{
     ResourceGroupName = "<resource group name>"
     DatabaseName = "<database name>"
     ServerName = "<server name>"
     Edition = "<service tier, such as Hyperscale>"
     RequestedServiceObjectiveName = "<hardware such as HS_Gen5_2>"
}

Set-AzSqlDatabase @parameters

Azure CLI を使用してデータベースを別の購入モデルに移行するには、次のサンプルのように az sql db update を使用します。

az sql db update --resource-group "<resource group name>" --server "<server name>" --name "<database name>" --edition <service tier, such as Hyperscale> --capacity 4 --family Gen5

Transact-SQL を使用してデータベースを別の購入モデルに移行するには、次の例のように ALTER DATABASE を使用します。

ALTER DATABASE <database name> MODIFY (EDITION = '<service tier, such as Hyperscale>');

仮想コアサービスレベルとサービス目標を選択する

DTU から仮想コアへの移行のほとんどのシナリオでは、Basic および Standard サービスレベルのデータベースとエラスティックプールは、General Purpose サービスレベルにマップされます。 Premium サービスレベルのデータベースとエラスティックプールは、Business Critical サービスレベルにマップされます。アプリケーションのシナリオや要件に応じて、Hyperscale サービスレベルは、多くの場合、すべての DTU サービスレベルでデータベースとエラスティックプールの移行先として使用できます。

仮想コアモデル内の移行されたデータベースのサービス目標 (コンピューティングサイズ) を選択するために、シンプルではあるが、大まかな目安を使用できます。Basic または Standard レベルでは 100 DTU ごとに "少なくとも" 1 つの仮想コア、Premium レベルでは 125 DTU ごとに "少なくとも" 1 つの仮想コアが必要になります。

ヒント

このルールは、DTU データベースまたはエラスティックプールに使用される特定の種類のハードウェアを考慮していないため、概算です。

DTU モデルでは、システムはデータベースまたはエラスティックプールに対して使用可能な任意のハードウェア構成を選択できます。さらに、DTU モデルでは、より高いまたは低い DTU あるいは eDTU 値を選択して仮想コア (論理 CPU) の数を間接的に制御することしかできません。

仮想コアモデルでは、お客様はハードウェア構成と仮想コア (論理 CPU) の数の両方を明示的に選択する必要があります。 DTU モデルではこのような選択肢は提供されませんが、ハードウェア型、およびすべてのデータベースとエラスティックプールに使用される論理 CPU の数は、動的管理ビューを介して公開されます。これにより、一致する仮想コアサービスの目標をより正確に特定することができます。

次の方法では、この情報を使用して、仮想コアモデルへの移行後に同様のレベルのパフォーマンスを得るために、リソースの割り当てが同様の仮想コアサービス目標を特定します。

DTU から仮想コアへのマッピング

次の Transact-SQL クエリは、移行する DTU データベースのコンテキストで実行されると、vCore モデル内の各ハードウェア構成の一致する (小数になる場合もある) 数の vCore を返します。仮想コアモデルの各ハードウェア構成では、データベースとエラスティックプールで使用可能な仮想コアの最も近い数にこの数を丸めることによって、お客様は DTU データベースまたはエラスティックプールに最も近い一致である仮想コアサービス目標を選択できます。

この方法を使用するサンプル移行シナリオについては、例に関するセクションを参照してください。

このクエリは、master データベースではなく、移行されるデータベースのコンテキストで実行します。エラスティックプールを移行する場合は、プール内の任意のデータベースのコンテキストでクエリを実行します。

;WITH dtu_vcore_map
AS (
    SELECT rg.slo_name,
        CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS NVARCHAR(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
        CASE 
            WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
            END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
        s.scheduler_count * CAST(rg.instance_cap_cpu / 100. AS DECIMAL(3, 2)) AS dtu_logical_cpus,
        CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS DECIMAL(4, 2)) AS dtu_memory_per_core_gb
    FROM sys.dm_user_db_resource_governance AS rg
    CROSS JOIN (
        SELECT COUNT(1) AS scheduler_count
        FROM sys.dm_os_schedulers
        WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE'
        ) AS s
    CROSS JOIN sys.dm_os_job_object AS jo
    CROSS APPLY (SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name) slo
    WHERE rg.dtu_limit > 0
        AND DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
        AND rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
    dtu_memory_per_core_gb,
    dtu_service_tier,
    CASE 
        WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
        WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
        WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
        END AS vcore_service_tier,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
        END AS standard_series_vcores,
    5.05 AS standard_series_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
        END AS Fsv2_vcores,
    1.89 AS Fsv2_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
        END AS M_vcores,
    29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

その他の要因

仮想コア (論理 CPU) の数とハードウェアの型以外にも、仮想コアサービス目標の選択に影響する可能性がある他の要因がいくつかあります。

マッピング Transact-SQL クエリは、CPU 容量の観点から DTU および vCore サービスの目標と一致するため、CPU にバインドされたワークロードの結果はより正確になります。
同じハードウェア型および同じ数の仮想コアについては、多くの場合、仮想コアデータベースの IOPS とトランザクションログのスループットリソース制限が DTU データベースよりも高くなります。 IO バウンドのワークロードの場合、vCore モデルの vCore の数を減らすことで、同じレベルのパフォーマンスを実現できる可能性があります。 DTU および仮想コアデータベースの実際のリソース制限は、sys.dm_user_db_resource_governance ビューで公開されます。移行される DTU データベースまたはプールと、ほぼ一致するサービス目標がある仮想コアデータベースまたはプールとの間でこれらの値を比較すると、仮想コアサービスの目標をより正確に選択するのに役立ちます。
また、マッピングクエリでは、移行される DTU データベースまたはエラスティックプールのコアあたりのメモリ量、および仮想コアモデルの各ハードウェア構成の、コアあたりのメモリ量を返します。十分なパフォーマンスを実現するために大量のメモリデータキャッシュを必要とするワークロード、またはクエリ処理に大量のメモリ許可を必要とするワークロードでは、仮想コアへの移行後に、同様のあるいはそれ以上の合計メモリを確保することが重要です。このようなワークロードでは、実際のパフォーマンスに応じて、十分な合計メモリを確保するために vCore の数を増やす必要がある場合があります。
仮想コアサービスの目標を選択する際には、DTU データベースのリソース使用率の履歴を考慮する必要があります。 CPU リソースの使用率が常に低い DTU データベースでは、マッピングクエリで返されるよりも少ない仮想コアが必要になることがあります。逆に、CPU 使用率が常に高いためにワークロードのパフォーマンスが不十分になる DTU データベースでは、クエリで返されるよりも多い仮想コアが必要になることがあります。
断続的または予測不可能な使用パターンを持つデータベースを移行する場合は、Azure SQL Database コンピューティングレベルにサーバーレスコンピューティングレベルの使用を検討してください。サーバーレスでの同時実行ワーカーの最大数は、構成されている同じ最大仮想コア数に対してプロビジョニングされたコンピューティングの上限の 75% であることにご注意ください。また、サーバーレスで使用できる最大メモリは、構成されている最大仮想コア数に 3 GB を乗算したものになります。これは、プロビジョニングされたコンピューティングのコアあたりのメモリよりも少なくなります。たとえば、Gen5 の最大メモリ容量は、40 の最大仮想コア数がサーバーレスで構成されている場合は 120 GB になり、40 の仮想コアでプロビジョニングされたコンピューティングの場合は 204 GB になります。
vCore モデルでは、サポートされる最大データベースサイズはハードウェアによって異なる場合があります。大規模なデータベースの場合は、単一データベースとエラスティックプールの仮想コアモデルでサポートされる最大サイズを確認してください。
エラスティックプールの場合、DTU 購入モデルと vCore モデルを使用するエラスティックプールのリソース制限では、プールごとにサポートされるデータベースの最大数が異なります。多数のデータベースを含むエラスティックプールを移行する場合は、この点を考慮する必要があります。
一部のハードウェア構成は、すべての地域で利用できない場合があります。可用性については、SQL Database のハードウェア構成に関するセクションを参照してください。

このセクションで提供される DTU から vCore へのサイズ設定のガイドラインは、ターゲットデータベースサービスの目標の初期見積もりに役立ちます。

ターゲットデータベースの最適な構成はワークロードに依存します。したがって、移行後に最適な価格/パフォーマンス比を実現するには、vCore モデルの柔軟性を利用して、vCore の数、ハードウェア構成、サービスおよびコンピューティング層を調整する必要がある場合があります。また、並列処理の最大限度などのデータベース構成パラメーターを調整したり、データベース互換レベルを変更して、データベースエンジンの最近の改善を有効にする必要がある場合もあります。

DTU から仮想コアへの移行例

Note

以下の例の値は説明のみを目的としています。説明したシナリオで返される実際の値は異なる場合があります。

Standard S9 データベースの移行

マッピングクエリでは次の結果が返されます (簡潔にするために一部の列は表示されていません)。

dtu_logical_cpus	dtu_memory_per_core_gb	standard_series_vcores	standard_series_memory_per_core_gb
24.00	5.40	24.000	5.05

DTU 標準データベースは、24 個の論理 CPU (仮想コア) と、仮想コアあたり 5.4 GB のメモリを備えていることがわかります。それと直接一致するのは、Standard シリーズ (Gen5) のハードウェア上の General Purpose 2 仮想コアデータベース、つまり GP_Gen5_24 仮想コアサービス目標です。

Standard S0 データベースの移行

マッピングクエリでは次の結果が返されます (簡潔にするために一部の列は表示されていません)。

dtu_logical_cpus	dtu_memory_per_core_gb	standard_series_vcores	standard_series_memory_per_core_gb
0.25	1.3	0.500	5.05

DTU データベースは、0.25 個に相当する論理 CPU (仮想コア) と、仮想コアあたり 1.3 GB のメモリを備えていることがわかります。 Standard シリーズ (Gen5) ハードウェア構成の最小の仮想コアサービス目標 (GP_Gen5_2) では、Standard S0 データベースより多くのコンピューティングリソースが提供されるため、直接一致させることはできません。 GP_Gen5_2 オプションをお勧めします。さらに、ワークロードがサーバーレスコンピューティングレベルに最適である場合は、GP_S_Gen5_1 がより近い一致になります。

Premium P15 データベースの移行

マッピングクエリでは次の結果が返されます (簡潔にするために一部の列は表示されていません)。

dtu_logical_cpus	dtu_memory_per_core_gb	standard_series_vcores	standard_series_memory_per_core_gb
42.00	4.86	42.000	5.05

DTU データベースは、42 個の論理 CPU (仮想コア) と、仮想コアあたり 4.86 GB のメモリを備えていることがわかります。 42 コアの仮想コアサービス目標はありませんが、BC_Gen5_40 サービス目標は、CPU とメモリ容量においてほぼ同じであり、適切な一致となります。

Basic 200 eDTU エラスティックプールの移行

マッピングクエリでは次の結果が返されます (簡潔にするために一部の列は表示されていません)。

dtu_logical_cpus	dtu_memory_per_core_gb	standard_series_vcores	standard_series_memory_per_core_gb
4.00	5.40	4.000	5.05

DTU エラスティックプールは、4 個の論理 CPU (仮想コア) と、仮想コアあたり 5.4 GB のメモリを備えていることがわかります。 Standard シリーズのハードウェアには 4 個の仮想コアが必要ですが、このサービス目標ではプールあたり最大 200 個のデータベースがサポートされている一方、Basic 200 eDTU エラスティックプールでサポートされるデータベースは 500 個までとなっています。移行されるエラスティックプールに 200 個を超えるデータベースがある場合、一致する仮想コアサービスの目標は GP_Gen5_6 である必要があります。これにより、500 個までのデータベースがサポートされます。

geo レプリケーション対応データベースを移行する

DTU ベースのモデルから仮想コアベースの購入モデルへの移行は、Standard サービスレベルと Premium サービスレベルのデータベース間で geo レプリケーションのリレーションシップをアップグレードまたはダウングレードすることに似ています。移行中、General Purpose および Business Critical Service 層の geo レプリケーションを停止する必要はありませんが、次のシーケンスルールに従う必要があります。

アップグレードの場合は、最初にセカンダリデータベースをアップグレードしてから、プライマリをアップグレードする必要があります。
ダウングレードは逆の順序で行います。つまり、最初にプライマリデータベースをダウングレードしてから、セカンダリをダウングレードします。

Hyperscale サービスレベルに移行するには、geo レプリケーションを一時的に削除する必要があります。詳細については、「既存のデータベースを Hyperscale に移行するを参照してください。

2 つのエラスティックプール間で geo レプリケーションを使用する場合は、1 つのプールをプライマリとして指定し、もう 1 つをセカンダリとして指定することをお勧めします。その場合、エラスティックプールを移行するときに、同じシーケンスガイダンスを使用する必要があります。ただし、プライマリデータベースとセカンダリデータベースの両方を含むエラスティックプールがある場合は、使用率が高い方のプールをプライマリとして扱い、それに応じてシーケンス処理のルールに従ってください。

次の表は、特定の移行シナリオのためのガイダンスを示しています。

現在のサービスレベル	移行先のサービスレベル	移行の種類	ユーザー操作
Standard	General Purpose	ラテラル	任意の順序で移行できますが、前述のように適切な vCore サイズを確保する必要があります。
Premium	Business Critical	ラテラル	任意の順序で移行できますが、前述のように適切な vCore サイズを確保する必要があります。
Standard	Business Critical	アップグレード	セカンダリを最初に移行する必要があります
Business Critical	Standard	ダウングレード	プライマリを最初に移行する必要があります
Premium	General Purpose	ダウングレード	プライマリを最初に移行する必要があります
General Purpose	Premium	アップグレード	セカンダリを最初に移行する必要があります
Business Critical	General Purpose	ダウングレード	プライマリを最初に移行する必要があります
General Purpose	Business Critical	アップグレード	セカンダリを最初に移行する必要があります
Standard	Hyperscale	ラテラル	Hyperscale への移行前に geo レプリケーションをオフにする
Premium	Hyperscale	ラテラル	Hyperscale への移行前に geo レプリケーションをオフにする

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

複数のデータベースが含まれるフェールオーバーグループの移行では、プライマリデータベースとセカンダリデータベースを個別に移行する必要があります。その処理中は、同じ考慮事項とシーケンス処理ルールが適用されます。データベースが仮想コアベースの購入モデルに変換された後も、フェールオーバーグループでは同じポリシー設定が引き続き有効です。

geo レプリケーションのセカンダリデータベースを作成する

geo レプリケーションのセカンダリデータベース (geo セカンダリ) は、プライマリデータベースに対して使用したのと同じサービスレベルを使用してのみ作成できます。ログ生成速度が速いデータベースの場合は、プライマリと同じコンピューティングサイズを持つ geo セカンダリを作成することをお勧めします。

単一のプライマリデータベースのエラスティックプールに geo セカンダリを作成する場合は、プールの maxVCore 設定がプライマリデータベースのコンピューティングサイズと一致していることを確認してください。別のエラスティックプールのプライマリの geo セカンダリを作成する場合は、プールの maxVCore 設定を同じにすることをお勧めします。

データベースコピーを使用して DTU から仮想コアに移行する

データベースコピーでは、コピー操作が開始された後の特定の時点でトランザクション上一貫性のあるデータのスナップショットが作成されます。その時点以降、コピー元とコピー先の間でデータは同期されません。

PowerShell、Azure CLI、または Transact-SQL を使用して、DTU ベースコンピューティングサイズのデータベースを仮想コアベースコンピューティングサイズのデータベースにコピーする場合、コピー先のコンピューティングサイズが、コピー元データベースの最大データベースサイズをサポートしている限り、制限や特別なシーケンス処理は伴いません。データベースを別のサービスレベルにコピーすることは、Azure portal ではサポートされていません。

次の方法で共有

Azure SQL Database を DTU ベースのモデルから仮想コアベースのモデルに移行する

データベースの移行

仮想コアサービスレベルとサービス目標を選択する

DTU から仮想コアへのマッピング

その他の要因

DTU から仮想コアへの移行例

geo レプリケーション対応データベースを移行する

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

geo レプリケーションのセカンダリデータベースを作成する

データベースコピーを使用して DTU から仮想コアに移行する

フィードバック

フィードバック

その他のリソース

次の方法で共有

Azure SQL Database を DTU ベースのモデルから仮想コア ベースのモデルに移行する

データベースの移行

仮想コア サービス レベルとサービス目標を選択する

DTU から仮想コアへのマッピング

その他の要因

DTU から仮想コアへの移行例

geo レプリケーション対応データベースを移行する

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

geo レプリケーションのセカンダリ データベースを作成する

データベース コピーを使用して DTU から仮想コアに移行する

関連するコンテンツ

フィードバック

フィードバック

その他のリソース

Azure SQL Database を DTU ベースのモデルから仮想コアベースのモデルに移行する

仮想コアサービスレベルとサービス目標を選択する

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

geo レプリケーションのセカンダリデータベースを作成する

データベースコピーを使用して DTU から仮想コアに移行する