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

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

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

データベースの移行

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

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

$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

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

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 あるいは 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 から仮想コアへの移行例

Standard S9 データベースの移行

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

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

Standard S0 データベースの移行

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

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

Premium P15 データベースの移行

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連するコンテンツ

• 仮想コア購入モデルを使用した単一データベースに対するリソース制限
• 仮想コア購入モデルを使用したエラスティック プールに対するリソース制限