Migración de Azure SQL Database del modelo basado en DTU al modelo basado en núcleo virtual.
Se aplica a: 
Azure SQL Database
En este artículo se describe cómo migrar la base de datos de Azure SQL Database del modelo de compra basado en DTU al modelo de compra basado en núcleo virtual.
Migración de bases de datos
La migración de una base de datos del modelo de compra basado en DTU al modelo de compra basado en núcleo virtual es similar al escalado entre los objetivos de servicio de los niveles de servicio básico, estándar y prémium, con una duración similar y un tiempo de inactividad mínimo al final del proceso de migración. Una base de datos migrada al modelo de compra basado en núcleo virtual se puede volver a migrar al modelo de compra basado en DTU en cualquier momento de la misma manera, con la excepción de las bases de datos que se han migrado al nivel de servicio Hiperescala.
Puede migrar la base de datos a otro modelo de compra mediante Azure Portal, PowerShell, la CLI de Azure y Transact-SQL.
Para migrar la base de datos a otro modelo de compra mediante Azure Portal, siga estos pasos:
Vaya a la base de datos SQL en Azure Portal.
Seleccione Proceso y almacenamiento bajo Configuración.
Use la lista desplegable en Nivel de servicio para seleccionar un nuevo modelo de compra y un nivel de servicio:
Elecció del nivel de servicio y el objetivo de servicio de núcleo virtual
Para la mayoría de los escenarios de migración de DTU a núcleo virtual, las bases de datos y los grupos elásticos de los niveles de servicio básico y estándar se asignan al nivel de servicio De uso general. Las bases de datos y los grupos elásticos del nivel de servicio prémium se asignan al nivel de servicio Crítico para la empresa. Según los requisitos y el escenario de la aplicación, a menudo se puede usar el nivel de servicio Hiperescala como destino de migración para bases de datos y grupos elásticos en todos los niveles de servicio de DTU.
Para elegir el objetivo del servicio, o el tamaño de proceso, para la base de datos migrada del modelo de núcleo virtual, puede usar una regla general básica pero aproximada: cada 100 DTU en los niveles básico o estándar requieren al menos 1 núcleo virtual y cada 125 DTU del nivel prémium requieren al menos 1 núcleo virtual.
Sugerencia
Esta regla es aproximada porque no tiene en cuenta el tipo específico de hardware utilizado para el grupo elástico o la base de datos de DTU.
En el modelo de DTU, el sistema podría seleccionar cualquier configuración de hardware disponible para la base de datos o el grupo elástico. Además, en el modelo de DTU, solo tiene control indirecto sobre el número de núcleos virtuales (CPU lógicas) si elige valores más altos o más bajos de DTU o eDTU.
En el modelo de núcleo virtual, los clientes deben tomar una decisión explícita de la configuración de hardware y el número de núcleos virtuales (CPU lógicas). Mientras que el modelo de DTU no ofrece estas opciones, el tipo de hardware y el número de CPU lógicas que se usan para cada base de datos y cada grupo elástico se exponen a través de vistas de administración dinámicas. Esto permite determinar el objetivo de servicio de núcleo virtual coincidente con más precisión.
El siguiente enfoque usa esta información para determinar un objetivo de servicio de núcleo virtual con una asignación similar de recursos, para obtener un nivel de rendimiento similar después de la migración al modelo de núcleo virtual.
Asignación de DTU a núcleo virtual
La consulta de Transact-SQL siguiente, si se ejecuta en el contexto de una base de datos de DTU que se va a migrar, devuelve un número coincidente (posiblemente fraccionario) de núcleos virtuales en cada configuración de hardware del modelo de núcleo virtual. Se puede redondear este número al número más cercano de núcleos virtuales disponibles para las bases de datos y los grupos elásticos en cada configuración de hardware del modelo de núcleo virtual; los clientes pueden elegir el objetivo de servicio de núcleo virtual que sea la coincidencia más exacta para su grupo elástico o base de datos de DTU.
Los escenarios de migración de ejemplo que usan este enfoque se describen en la sección Ejemplos.
Ejecute esta consulta en el contexto de la base de datos que se va a migrar, en lugar de en la base de datos master. Al migrar un grupo elástico, ejecute la consulta en el contexto de cualquier base de datos del grupo.
;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;
Factores adicionales
Además del número de núcleos virtuales (CPU lógicas) y el tipo de hardware, varios factores diferentes pueden influir en la elección del objetivo de servicio de núcleo virtual:
La consulta de Transact-SQL de asignación coincide con los objetivos de servicio de DTU y núcleo virtual en cuanto a su capacidad de CPU, por lo que los resultados son más precisos para las cargas de trabajo enlazadas a la CPU.
Para el mismo tipo de hardware y el mismo número de núcleos virtuales, los límites de recursos de rendimiento del registro de transacciones e IOPS para las bases de datos de núcleo virtual suelen ser mayores que para las bases de datos de DTU. En el caso de las cargas de trabajo enlazadas a E/S, es posible reducir el número de núcleos virtuales en el modelo de núcleo virtual para lograr el mismo nivel de rendimiento. Los límites de recursos reales para las bases de datos de DTU y núcleo virtual se exponen en la vista sys.dm_user_db_resource_governance. La comparación de estos valores entre la base de datos de DTU o el grupo que se van a migrar y una base de datos de núcleo virtual o un grupo con un objetivo de servicio de coincidencia aproximada le puede ayudar a seleccionar el objetivo de servicio de núcleo virtual con mayor precisión.
La consulta de asignación también devuelve la cantidad de memoria por núcleo para el grupo elástico o la base de datos de DTU que se va a migrar, y para cada configuración de hardware del modelo de núcleo virtual. Garantizar una memoria total similar o superior después de la migración a núcleo virtual es importante para las cargas de trabajo que requieren una memoria caché de datos de gran tamaño para lograr un rendimiento suficiente o para cargas de trabajo que requieren concesiones de memoria grandes para el procesamiento de consultas. En el caso de estas cargas de trabajo, en función del rendimiento real, puede ser necesario aumentar el número de núcleos virtuales para obtener suficiente memoria total.
La utilización de recursos históricos de la base de datos de DTU se debe tener en cuenta al elegir el objetivo de servicio de núcleo virtual. Es posible que las bases de datos de DTU con recursos de CPU infrautilizados de forma constante necesiten menos núcleos virtuales que el número devuelto por la consulta de asignación. Por el contrario, las bases de datos de DTU en las que el uso de CPU elevado constante provoca un rendimiento inadecuado de la carga de trabajo pueden requerir más núcleos virtuales de los que devuelve la consulta.
Si migra bases de datos con patrones de uso intermitentes o imprevisibles, tenga en cuenta el uso del nivel de proceso Nivel de proceso sin servidor para Azure SQL Database. El número máximo de trabajos simultáneos en la opción sin servidor es el 75 % del límite en el proceso aprovisionado para el mismo número de núcleos virtuales máximo configurado. Además, la memoria máxima disponible en la opción sin servidor expresada en GB es 3 veces el número máximo de núcleos virtuales configurados, lo que es menor que la memoria por núcleo para el proceso aprovisionado. Por ejemplo, en Gen5, la memoria máxima será de 120 GB cuando se configura un máximo de 40 núcleos virtuales como máximo en la opción sin servidor, frente a 204 GB para un proceso aprovisionado de 40 núcleos virtuales.
En el modelo de núcleo virtual, el tamaño máximo admitido de la base de datos puede variar en función del hardware. En el caso de las bases de datos de gran tamaño, compruebe los tamaños máximos admitidos en el modelo de núcleo virtual para bases de datos únicas y grupos elásticos.
En el caso de los grupos elásticos, los modelos de Límites de recursos para grupos elásticos que utilizan el modelo de compra de DTU y núcleo virtual presentan diferencias en el número máximo de bases de datos admitidas por grupo. Esto se debe tener en cuenta al migrar grupos elásticos con muchas bases de datos.
Es posible que algunas configuraciones de hardware no estén disponibles en todas las regiones. Compruebe la disponibilidad en Configuración de hardware para SQL Database.
Las directrices de ajuste de tamaño de DTU a núcleo virtual se proporcionan en esta sección para ayudarle en la estimación inicial del objetivo de servicio de base de datos de destino.
La configuración óptima de la base de datos de destino depende de la carga de trabajo. Por lo tanto, para lograr una relación óptima entre el precio y el rendimiento después de la migración, es posible que tenga que usar la flexibilidad del modelo de núcleo virtual para ajustar el número de núcleos virtuales, la configuración de hardware y los niveles de servicio y proceso. También puede que tenga que ajustar los parámetros de configuración de la base de datos, como el grado máximo de paralelismo, o cambiar el nivel de compatibilidad de la base de datos para habilitar mejoras recientes en el motor de base de datos.
Ejemplos de migración de DTU a núcleo virtual
Nota:
Los valores de los ejemplos siguientes son para fines ilustrativos solamente. Los valores reales devueltos en los escenarios descritos pueden ser diferentes.
Migración de una base de datos S9 estándar
La consulta de asignación devuelve el resultado siguiente (algunas columnas no se muestran por motivos de brevedad):
| 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 |
Vemos que la base de datos estándar de DTU tiene 24 CPU lógicas (núcleos virtuales), con 5,4 GB de memoria por núcleo virtual. La coincidencia directa correspondiente es una base de datos De uso general y 2 núcleos virtuales en hardware de serie estándar (Gen5), el objetivo de servicio de núcleo virtual GP_Gen5_24.
Migración de una base de datos S0 estándar
La consulta de asignación devuelve el resultado siguiente (algunas columnas no se muestran por motivos de brevedad):
| 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 |
Vemos que la base de datos de DTU tiene el equivalente de 0,25 CPU lógicas (núcleos virtuales), con 1,3 GB de memoria por núcleo virtual. Los objetivos de servicio de núcleo virtual inferiores de las configuraciones de hardware de serie estándar (Gen5), GP_Gen5_2, proporcionan más recursos de proceso que la base de datos S0 estándar, por lo que no es posible una coincidencia directa. Se prefiere la opción GP_Gen5_2. Además, si la carga de trabajo es adecuada para el nivel de proceso Sin servidor, GP_S_Gen5_1 sería una coincidencia más aproximada.
Migración de una base de datos P15 prémium
La consulta de asignación devuelve el resultado siguiente (algunas columnas no se muestran por motivos de brevedad):
| 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 |
Vemos que la base de datos de DTU tiene 42 CPU lógicas (núcleos virtuales), con 4,86 GB de memoria por núcleo virtual. Aunque no hay ningún objetivo de servicio de núcleo virtual con 42 núcleos, el objetivo de servicio BC_Gen5_40 es casi equivalente en términos de capacidad de CPU y de memoria, y es una buena coincidencia.
Migración de un grupo elástico básico de 200 eDTU
La consulta de asignación devuelve el resultado siguiente (algunas columnas no se muestran por motivos de brevedad):
| 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 |
Vemos que el grupo elástico de DTU tiene 4 CPU lógicas (núcleos virtuales), con 5,4 GB de memoria por núcleo virtual. El hardware de serie estándar requiere 4 núcleos virtuales, sin embargo, este objetivo de servicio admite un máximo de 200 bases de datos por grupo, mientras que el grupo elástico básico de 200 eDTU admite hasta 500 bases de datos. Si el grupo elástico que se va a migrar tiene más de 200 bases de datos, el objetivo de servicio de núcleo virtual coincidente tendría que ser GP_Gen5_6, que admite hasta 500 bases de datos.
Migración de bases de datos con replicación geográfica
La migración desde el modelo basado en DTU al modelo basado en núcleos virtuales es similar a la actualización o degradación de las relaciones de replicación geográfica entre las bases de datos en los niveles de servicio Estándar y Premium. Durante la migración, no tendrá que detener la replicación geográfica para los niveles de servicio de uso general y crítico para la empresa, pero tiene que seguir estas reglas de secuenciación:
- Al actualizar, debe actualizar primero la base de datos secundaria y luego la principal.
- Al degradar, invierta el orden; es decir, debe degradar primero la base de datos principal y luego la secundaria.
Para migrar al nivel de servicio Hiperescala, se debe quitar temporalmente la replicación geográfica. Para obtener más información, consulte Migración de una base de datos existente a Hiperescala.
Cuando se usa la replicación geográfica entre dos grupos elásticos, se recomienda designar un grupo como principal y otro como secundario. En ese caso, cuando migre grupos elásticos debe usar la misma guía de secuenciación. Sin embargo, si tiene grupos elásticos que contienen bases de datos principales y secundarias, trate al grupo con la utilización más alta como principal y siga las reglas de secuenciación como corresponda.
En la tabla siguiente se proporciona una guía para escenarios de migración específicos:
| Nivel de servicio actual | Nivel de servicio de destino | Tipo de migración | Acciones del usuario |
|---|---|---|---|
| Estándar | Uso general | Lateral | Puede realizar la migración en cualquier orden, pero debe asegurarse de tener un tamaño adecuado de núcleo virtual como hemos descrito anteriormente. |
| Premium | Crítico para la empresa | Lateral | Puede realizar la migración en cualquier orden, pero debe asegurarse de tener un tamaño adecuado de núcleo virtual como hemos descrito anteriormente. |
| Estándar | Crítico para la empresa | Actualizar | Debe migrar primero la secundaria |
| Crítico para la empresa | Estándar | Degradar | Debe migrar primero la principal |
| Premium | De uso general | Degradar | Debe migrar primero la principal |
| Uso general | Premium | Actualizar | Debe migrar primero la secundaria |
| Crítico para la empresa | De uso general | Degradar | Debe migrar primero la principal |
| Uso general | Crítico para la empresa | Actualizar | Debe migrar primero la secundaria |
| Estándar | Hiperescala | Lateral | Replicación geográfica que se desactivará antes de la migración a Hiperescala |
| Premium | Hiperescala | Lateral | Replicación geográfica que se desactivará antes de la migración a Hiperescala |
Migración de grupos de conmutación por error
La migración de grupos de conmutación por error con varias bases de datos requiere la migración individual de las bases de datos principales y secundarias. Durante ese proceso, se aplican las mismas consideraciones y reglas de secuenciación. Después de que las bases de datos se convierten al modelo de compra basado en núcleo virtual, el grupo de conmutación por error permanecerá en vigor con la misma configuración de directiva.
Creación de una base de datos secundaria de replicación geográfica
Puede crear una base de datos secundaria de replicación geográfica (geo-secundaria) solo con el mismo nivel de servicio que utilizó para la base de datos principal. Para las bases de datos con una tasa alta de generación de registro, se recomienda crear la replicación geográfica secundaria con el mismo tamaño de proceso que la principal.
Si crea una base de datos secundaria de replicación geográfica en el grupo elástico para una única base de datos principal, asegúrese de que el valor maxVCore del grupo coincida con el tamaño de proceso de la base de datos principal. Si crea una base de datos secundaria de replicación geográfica para una principal en otro grupo elástico, se recomienda que los grupos tengan la misma configuración de maxVCore.
Uso de la copia de base de datos para la migración de DTU a núcleo virtual
La copia de la base de datos crea una instantánea transaccionalmente coherente de los datos en un momento dado después de que se inicie la operación de copia. No sincroniza los datos entre el origen y el destino después de ese momento dado.
Puede copiar cualquier base de datos con un tamaño de proceso basado en DTU a una base de datos con un tamaño de proceso basado en núcleos virtuales mediante PowerShell, la CLI de Azure o Transact-SQL sin restricciones ni secuencias especiales, siempre y cuando el tamaño de proceso de destino admita el tamaño máximo de base de datos de la base de datos de origen. En Azure Portal no se admite la copia de una base de datos en otro nivel de servicio.