Migrer Azure SQL Database à partir du modèle DTU vers le modèle vCore
S’applique à : 
Azure SQL Database
Cet article explique comment migrer votre base de données dans Azure SQL Database du modèle d’achat DTU vers le modèle d’achat vCore.
Migrer une base de données
La migration d’une base de données du modèle d’achat DTU vers le modèle d’achat vCore est semblable à la mise à l’échelle entre les objectifs de service des niveaux de service De base, Standard et Premium, avec une durée similaire et un temps d’arrêt minimal au terme du processus de migration. Une base de données migrée vers le modèle d’achat vCore peut, à tout moment, être à nouveau migrée vers le modèle d’achat DTU en suivant les mêmes étapes, à l’exception des bases de données migrées vers le niveau de service Hyperscale.
Vous pouvez migrer votre base de données vers un modèle d’achat différent en utilisant le portail Azure, PowerShell, Azure CLI et Transact-SQL.
Pour migrer votre base de données vers un modèle d’achat différent en utilisant le portail Azure, procédez comme suit :
Accédez à votre SQL Database dans le portail Azure.
Sélectionnez Calcul + Stockage sous Paramètres.
Utilisez la liste déroulante sous Niveau de service pour sélectionner un nouveau modèle d’achat et un nouveau niveau de service :
Choisir le niveau de service et l’objectif de service vCore
Dans la plupart des scénarios de migration DTU vers vCore, les bases de données et les pools élastiques des niveaux de service De base et Standard sont mappés vers le niveau de service Usage général. Les bases de données et les pools élastiques du niveau de service Premium sont mappés vers le niveau de service Critique pour l’entreprise. Selon le scénario et la configuration requise de l’application, le niveau de service Hyperscale peut souvent être utilisé comme cible de migration pour les bases de données et pools élastiques dans tous les niveaux de service DTU.
Pour choisir l’objectif de service, ou la taille de calcul, pour la base de données migrée dans le modèle vCore, vous pouvez utiliser une règle basique mais approximative : chaque tranche de 100 DTU des niveaux De base ou Standard nécessite au moins 1 vCore, et chaque tranche de 125 DTU du niveau Premium nécessite au moins 1 vCore.
Conseil
Cette règle est approximative, car elle ne prend pas en compte le type spécifique de matériel utilisé pour la base de données ou le pool élastique DTU.
Dans le modèle DTU, le système pourrait sélectionner toute configuration de matériel disponible peut votre base de données ou pool élastique. En outre, dans le modèle DTU, vous disposez uniquement d’un contrôle indirect sur le nombre de vCores (processeurs logiques) en choisissant des valeurs DTU ou eDTU supérieures ou inférieures.
Dans le modèle vCore, les clients doivent faire un choix explicite en termes de configuration de matériel et de nombre de vCores (processeurs logiques). Le modèle DTU n’offre pas ces choix, mais le type de matériel et le nombre de processeurs logiques utilisés pour chaque base de données et pool élastique sont exposés dans les vues de gestion dynamique. Il est ainsi possible de déterminer de manière plus précise l’objectif de service vCore correspondant.
L’approche suivante utilise ces informations pour déterminer un objectif de service vCore avec une allocation de ressources semblable, afin d’obtenir un niveau de performance similaire après migration vers le modèle vCore.
Mappage DTU vers vCore
La requête Transact-SQL suivante, quand elle est exécutée dans le contexte d’une base de données DTU à migrer, retourne un nombre de vCores correspondant (éventuellement fractionnaire) dans chaque configuration de matériel du modèle vCore. En arrondissant ce nombre au nombre de vCores disponibles le plus proche pour les bases de données et pools élastiques dans chaque configuration de matériel du modèle vCore, les clients peuvent choisir l’objectif de service vCore qui correspond le mieux à la base de données ou au pool élastique DTU.
Les exemples de scénarios de migration utilisant cette approche sont décrits dans la section Exemples.
Exécutez cette requête dans le contexte de la base de données à migrer plutôt que dans la base de données master. Lorsque vous migrez un pool élastique, exécutez la requête dans le contexte d’une base de données du pool.
;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;
Autres facteurs
En plus du nombre de vCores (UC logiques) et du type de matériel, plusieurs autres facteurs pourraient influencer le choix de l’objectif de service vCore :
La requête Transact-SQL de mappage correspond aux objectifs de service DTU et vCore en termes de capacité d’UC. Dès lors, les résultats sont plus précis pour les charges de travail liées au processeur.
Pour le même type de matériel et le même nombre de vCores, les limites IOPS et de débit du journal des transactions des bases de données vCore sont souvent plus élevées que celles des bases de données DTU. Pour les charges de travail dépendantes des E/S, il pourrait être possible de réduire le nombre de vCores du modèle vCore afin d’obtenir le même niveau de performances. Les limites de ressources réelles des bases de données DTU et vCore sont exposées dans la vue sys.dm_user_db_resource_governance. La comparaison de ces valeurs entre le pool ou la base de données DTU à migrer et un pool ou une base de données vCore avec un objectif de service proche peut vous aider à sélectionner plus précisément l’objectif de service vCore.
La requête de mappage renvoie également la quantité de mémoire par cœur pour la base de données ou le pool élastique DTU à migrer, et pour chaque configuration de matériel du modèle vCore. Il convient d’obtenir une mémoire totale similaire ou supérieure après migration vers vCore pour les charges de travail nécessitant un cache de données important à des fins de performances suffisantes, ou pour les charges de travail nécessitant des allocations de mémoire importantes à des fins de traitement des requêtes. Pour ces charges de travail, en fonction des performances réelles, il pourrait s’avérer nécessaire d’augmenter le nombre de vCores afin d’obtenir suffisamment de mémoire totale.
L’utilisation des ressources d’historique de la base de données DTU doit être prise en compte lors du choix de l’objectif de service vCore. Les bases de données DTU présentant systématiquement des ressources processeur sous-exploitées pourraient nécessiter moins de vCores que le nombre renvoyé par la requête de mappage. À l’inverse, les bases de données DTU présentant une utilisation du processeur systématiquement élevée traduisant des performances de charge de travail inadaptées pourraient nécessiter plus de vCores que le nombre renvoyé par la requête.
Si vous migrez des bases de données avec des modèles d’utilisation intermittents ou imprévisibles, pensez à recourir au niveau de calcul Niveau de calcul serverless pour Azure SQL Database. Le nombre maximal de workers simultanés dans serverless est de 75 % la limite du calcul configurée pour le même nombre de vCores maximal configuré. En outre, la mémoire maximale disponible avec le niveau serverless est de 3 Go multipliés par le nombre maximal de vCores configurés, ce qui est inférieur à la mémoire par cœur pour le calcul provisionné. Par exemple, sur Gen5, la mémoire maximale est de 120 Go quand le nombre maximal de vCores configurés est 40 avec le niveau serverless et de 204 Go pour un calcul provisionné avec 40 vCores.
Dans le modèle vCore, la taille maximale de base de données prise en charge pourrait varier en fonction du matériel. Pour les bases de données volumineuses, vérifiez les tailles maximales prises en charge dans le modèle vCore pour les bases de données uniques et les pools élastiques.
Pour les pools élastiques, les modèles Limites de ressources pour des pools élastiques suivant le modèle d’achat DTU et vCore présentent des différences en termes de nombre maximal de bases de données par pool prises en charge. Cela doit être pris en compte lorsque vous migrez des pools élastiques avec de nombreuses bases de données.
Certaines configurations de matériel pourraient ne pas être disponibles dans toutes les régions. Vérifiez la disponibilité sous Configuration de matériel pour SQL Database.
Les instructions relatives au dimensionnement de DTU vers vCore fournies dans cette section vous aident à faire une estimation initiale de l’objectif de service de la base de données cible.
La configuration optimale de la base de données cible dépend de la charge de travail. Ainsi, pour bénéficier du rapport prix/performance optimal après la migration, vous devrez peut-être utiliser la flexibilité du modèle vCore pour ajuster le nombre de vCores, la configuration matérielle et les niveaux de service et de calcul. Vous devrez peut-être également ajuster les paramètres de configuration de base de données tels que le degré maximal de parallélisme et/ou modifier le niveau de compatibilité de base de données pour bénéficier des améliorations récentes du moteur de base de données.
Exemples de migration DTU vers vCore
Remarque
Les valeurs indiquées dans les exemples suivants sont présentées à des fins d’illustration uniquement. Les valeurs réelles renvoyées dans les scénarios décrits pourraient être différentes.
Migration d’une base de données S9 standard
La requête de mappage renvoie le résultat suivant (certaines colonnes ne sont pas affichées par souci de concision) :
| 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 |
Nous constatons que la base de données standard DTU dispose de 24 processeurs logiques (vCores), avec 5,4 Go de mémoire par vCore. La correspondance directe avec cela est une base de données Usage général à 2 vCores sur du matériel (Gen5) de la série standard, l’objectif de service vCore GP_Gen5_24.
Migration d’une base de données S0 Standard
La requête de mappage renvoie le résultat suivant (certaines colonnes ne sont pas affichées par souci de concision) :
| 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 |
Nous constatons que la base de données DTU dispose de l’équivalent de 0,25 processeur logique (vCore), avec 1,3 Go de mémoire par vCore. Les plus petits objectifs de service vCore dans les configurations du matériel de la série Standard (Gen5), GP_Gen5_2, fournissent davantage de ressources de calcul que la base de données S0 Standard, de sorte qu’une correspondance directe n’est pas possible. L’option GP_Gen5_2 est recommandée. En outre, si la charge de travail est bien adaptée au niveau de calcul Serverless, GP_S_Gen5_1 est une correspondance plus proche.
Migration d’une base de données P15 Premium
La requête de mappage renvoie le résultat suivant (certaines colonnes ne sont pas affichées par souci de concision) :
| 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 |
Nous constatons que la base de données DTU dispose de 42 processeurs logiques (vCores), avec 4,86 Go de mémoire par vCore. S’il n’existe pas d’objectif de service vCore avec 42 cœurs, l’objectif de service BC_Gen5_40 est quasiment équivalent en termes de capacité de mémoire et de processeur, et constitue une bonne correspondance.
Migration d’un pool élastique 200 eDTU De base
La requête de mappage renvoie le résultat suivant (certaines colonnes ne sont pas affichées par souci de concision) :
| 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 |
Nous constatons que le pool élastique DTU dispose de 4 processeurs logiques (vCores), avec 5,4 Go de mémoire par vCore. Le matériel de série standard appelle 4 vCores. Or, cet objectif de service prend en charge au maximum 200 bases de données par pool, tandis que le pool élastique 200 eDTU De base prend en charge jusqu’à 500 bases de données. Si le pool élastique à migrer contient plus de 200 bases de données, l’objectif de service vCore correspondant doit être GP_Gen5_6, qui prend en charge jusqu’à 500 bases de données.
Migration des bases de données géorépliquées
La migration du modèle DTU vers le modèle vCore est similaire à la mise à niveau (ou à la rétrogradation) des relations de géoréplication entre les bases de données dans les niveaux de service Standard et Premium. Pendant la migration, vous n’êtes pas obligé d’arrêter la géoréplication pour les niveaux de service Usage général et Critique pour l’entreprise, mais vous devez suivre ces règles de séquencement :
- Lors d’une mise à niveau, vous devez mettre à niveau la base de données secondaire, avant de mettre à niveau la base de données primaire.
- Lors d’une rétrogradation, inversez l’ordre : rétrogradez d’abord la base de données primaire, puis la base de données secondaire.
Pour migrer vers le niveau de service Hyperscale, la géoréplication doit être temporairement supprimée. Pour plus d’informations, consultez Migrer une base de données existante vers Hyperscale.
Lorsque vous utilisez la géoréplication entre deux pools élastiques, nous vous recommandons de désigner un pool comme le pool principal et l’autre comme le pool secondaire. Dans ce cas, lorsque vous effectuez une migration de pools élastiques, vous devez utiliser les mêmes recommandations de séquencement. Toutefois, si vous avez des pools élastiques qui contiennent des bases de données primaires et secondaire, traitez le pool le plus utilisé comme pool principal et suivez les règles de séquencement en conséquence.
Le tableau suivant fournit des conseils pour certains scénarios de migration :
| Niveau de service actuel | Niveau de service cible | Type de migration | Actions utilisateur |
|---|---|---|---|
| Standard | Usage général | Latéral | Peut effectuer la migration dans n’importe quel ordre, mais doit garantir un redimensionnement vCore, comme décrit précédemment |
| Premium | Critique pour l’entreprise | Latéral | Peut effectuer la migration dans n’importe quel ordre, mais doit garantir un redimensionnement vCore, comme décrit précédemment |
| Standard | Critique pour l’entreprise | Mettre à niveau | Doit d’abord effectuer la migration de la base de données secondaire |
| Critique pour l’entreprise | Standard | Rétrogradation | Doit d’abord effectuer la migration de la base de données primaire |
| Premium | Usage général | Rétrogradation | Doit d’abord effectuer la migration de la base de données primaire |
| Usage général | Premium | Mettre à niveau | Doit d’abord effectuer la migration de la base de données secondaire |
| Critique pour l’entreprise | Usage général | Rétrogradation | Doit d’abord effectuer la migration de la base de données primaire |
| Usage général | Critique pour l’entreprise | Mettre à niveau | Doit d’abord effectuer la migration de la base de données secondaire |
| Standard | Hyperscale | Latéral | La géoréplication doit être désactivée avant la migration vers Hyperscale |
| Premium | Hyperscale | Latéral | La géoréplication doit être désactivée avant la migration vers Hyperscale |
Migrer des groupes de basculement
La migration des groupes de basculement comprenant plusieurs bases de données nécessite que la base de données primaire et la base de données secondaire soient migrées séparément. Pendant ce processus, les mêmes recommandations et règles de séquencement s’appliquent. Une fois les bases de données converties au modèle d’achat vCore, le groupe de basculement reste actif, avec les mêmes paramètres de stratégie.
Créer une base de données secondaire de géoréplication
Vous pouvez créer une base de données secondaire géoréplication (réplica géosecondaire) uniquement dans le même niveau de service que celui utilisé pour la base de données primaire. Pour les bases de données avec un taux élevé de génération de journaux, nous vous recommandons de créer le réplica géosecondaire avec la même taille de calcul que le réplica principal.
Si vous créez une base de données secondaire de géoréplication dans le pool élastique pour une base de données primaire unique, le paramètre maxVCore du pool doit correspondre à la taille de calcul de la base de données primaire. Si vous créez une base de données secondaire de géoréplication pour une base de données primaire située dans un autre pool élastique, nous vous recommandons d’attribuer la même valeur au paramètre maxVCore des deux pools.
Utiliser la copie de base de données pour migrer de DTU vers vCore
La copie de base de données crée un instantané des données cohérent au niveau transactionnel à un moment donné après le démarrage de l’opération de copie. Elle ne synchronise pas les données entre la source et la cible après ce moment précis.
Vous pouvez copier n’importe quelle base de données avec une taille de calcul DTU vers une base de données avec une taille de calcul vCore en utilisant PowerShell, Azure CLI, ou Transact-SQL sans aucune restriction ni séquencement spécial, tant que la taille de calcul cible prend en charge la taille maximale de la base de données source. La copie d’une base de données vers un autre niveau de service n’est pas prise en charge dans le portail Azure.