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

  • [アーティクル]

適用対象:Azure SQL Database

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

データベースの移行

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

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

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

  1. Azure portal で SQL データベースに移動します。

  2. [設定] で、[コンピューティングとストレージ] を選択します。

  3. [サービス レベル] のドロップダウンを使用して、新しい購入モデルとサービス レベルを選択します。

    サービス レベルが選択されている Azure portal の SQL Database の [コンピューティングとストレージ] ページのスクリーンショット。

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

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 から仮想コアへのマッピング

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

重要

上記の DTU から仮想コアへのサイズ変更のガイドラインは、ターゲット データベース サービス目標の最初の見積もりに役立つように提供されています。

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

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 レプリケーションのリレーションシップをアップグレードまたはダウングレードすることに似ています。 移行中に geo レプリケーションを停止する必要はありませんが、次のシーケンス処理のルールに従う必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ