Migración inversa de una base de datos desde Hiperescala

Se aplica a:Azure SQL Database

Puede migrar una base de datos de Hiperescala existente en Azure SQL Database al nivel de servicio De uso general mediante Azure Portal, la CLI de Azure, PowerShell o Transact-SQL.

La migración inversa al nivel de servicio De uso general permite a los clientes que han convertido recientemente una base de datos existente en Azure SQL Database a Hiperescala para volver a moverse en caso de emergencia, si Hiperescala no satisface sus necesidades. Aunque un cambio de nivel de servicio inicia la migración inversa, básicamente es un movimiento del tamaño de los datos entre diferentes arquitecturas.

Limitaciones de la migración inversa

La migración inversa está disponible en las siguientes condiciones:

La migración inversa solo está disponible en un plazo de 45 días a partir de la migración original a Hiperescala.
Las bases de datos creadas originalmente en el nivel de servicio Hiperescala no son válidas para la migración inversa.
Solo puede revertir la migración al nivel de servicio De uso general. La migración de Hiperescala a De uso general puede dirigirse a niveles de proceso sin servidor o aprovisionados. Si quiere migrar la base de datos a otro nivel de servicio, como Crítico para la empresa o un nivel de servicio basado en DTU, primero realice la migración inversa al nivel de servicio De uso general y, luego, cambie el nivel de servicio.
No se admite la migración inversa a bases de datos con menos de dos núcleos virtuales. Puede reducir verticalmente la base de datos a menos de dos núcleos virtuales una vez que se complete la migración.
No se admite la migración inversa directa a un grupo elástico ni desde uno. Solo puede realizar la migración inversa de una base de datos única de Hiperescala a una base de datos única De uso general.
- Si la base de datos Hiperescala forma parte de un grupo elástico de Hiperescala, primero tiene que eliminarla del grupo elástico de Hiperescala antes de realizar la migración inversa.
- Una vez completada la migración inversa, si es necesario, puede agregar la base de datos única De uso general a un grupo elástico De uso general.
En el caso de las bases de datos que no son válidas para la migración inversa, la única manera de migrar de Hiperescala a otro nivel de servicio es exportar o importar mediante un archivo bacpac u otras tecnologías de movimiento de datos (copia masiva, Azure Data Factory, Azure Databricks, SSIS, etc.). No se admite la exportación o importación de bacpac desde Azure Portal, desde PowerShell mediante New-AzSqlDatabaseExport o New-AzSqlDatabaseImport, desde la CLI de Azure con az sql db export y az sql db import ni desde la API REST. Se admite la importación y exportación de bases de datos de Hiperescala (150 GB como máximo) mediante SSMS y SqlPackage versión 18.4 y posteriores. En el caso de las bases de datos de mayor tamaño, la importación y exportación de bacpac puede tardar mucho tiempo y producir errores por diversos motivos.

Duración y tiempo de inactividad

A diferencia de las operaciones normales de cambio de objetivo de nivel de servicio de Hiperescala, la migración a Hiperescala y la migración inversa a De uso general son operaciones de tamaño de datos.

La duración de una operación de migración inversa depende principalmente del tamaño de la base de datos y de las actividades de escritura simultáneas que se producen durante la migración. El número de núcleos virtuales que asigne a la base de datos De uso general de destino también afecta a la duración de la migración inversa. Se recomienda que la base de datos De uso general de destino se aprovisione con un número de núcleos virtuales mayor o igual que el número de núcleos virtuales asignados a la base de datos de Hiperescala de origen para mantener cargas de trabajo similares.

Durante la migración inversa, la base de datos de Hiperescala de origen puede experimentar una degradación del rendimiento si está bajo una carga considerable. En concreto, se puede reducir (limitar) la tasa de registro de transacciones para garantizar que la migración inversa progrese.

Solo experimentará un breve período de tiempo de inactividad, normalmente unos minutos, durante la transición final a la nueva base de datos de destino De uso general.

Prerrequisitos

Antes de iniciar una migración inversa del nivel de servicio Hiperescala a De uso general, debe asegurarse de que la base de datos cumple las limitaciones de la migración inversa y que:

Que la base de datos no tenga habilitada la replicación geográfica.
Que la base de datos no tenga réplicas con nombre.
La base de datos (tamaño asignado) sea lo suficientemente pequeña como para ajustarse al nivel de servicio de destino.
Si especifica el tamaño máximo de base de datos para la base de datos de destino De uso general, asegúrese de que el tamaño asignado de la base de datos sea lo suficientemente pequeño como para ajustarse a ese tamaño máximo.

Las comprobaciones de requisitos previos se producen antes de que se inicie la operación de migración inversa. Si no se cumplen los requisitos previos, inmediatamente se produce un error en la operación de migración inversa.

Directivas de copia de seguridad

Se le cobran los precios normales de todas las copias de seguridad de base de datos existentes del período de retención configurado. Se le facturan las instantáneas de almacenamiento de copia de seguridad de Hiperescala y los blobs de almacenamiento de tamaño de datos que se deban conservar para poder restaurar la copia de seguridad.

Puede convertir una base de datos a Hyperscale y revertir la migración a General Purpose varias veces. Solo las copias de seguridad del nivel actual y del anterior de su base de datos están disponibles para su restauración. Si ha pasado del nivel de servicio De uso general a Hiperescala y de nuevo a De uso general, las únicas copias de seguridad disponibles son las de la base de datos De uso general actual y la base de datos de Hiperescala inmediatamente anterior. Estas copias de seguridad retenidas se facturan según la facturación de Azure SQL Database. Los niveles anteriores probados no tendrán copias de seguridad disponibles y no se facturarán.

Por ejemplo, podría migrar entre los niveles de servicio Hiperescala y no Hiperescala:

Uso general
Conversión a Hiperescala
Migración inversa a De uso general
Cambio del nivel de servicio a Crítico para la empresa
Conversión a Hiperescala
Migración inversa a De uso general

En este caso, las únicas copias de seguridad disponibles serían las de los pasos 5 y 6 de la escala de tiempo, si siguen dentro del período de retención configurado. Las copias de seguridad de los pasos anteriores no estarían disponibles. Preste especial atención a la disponibilidad de las copias de seguridad al intentar realizar varias migraciones de la misma base de datos entre los niveles de servicio Hiperescala y De uso general. Las copias de seguridad de bases de datos anteriores a la base de datos inmediatamente anterior no están disponibles en cuanto se inicia una migración inversa y permanecen no disponibles incluso si se cancela la migración.

Migración inversa de una base de datos de Hiperescala al nivel de servicio De uso general

Para realizar la migración inversa de una base de datos de Hiperescala existente en Azure SQL Database al nivel de servicio De uso general, primero identifique el objetivo de servicio de destino en el nivel de servicio De uso general y si quiere que la migración sea a los niveles de proceso aprovisionados o sin servidor. Si no está seguro de qué objetivo de servicio es adecuado para la base de datos, revise los límites de recursos para bases de datos únicas.

Si desea realizar un cambio de nivel de servicio adicional después de la migración inversa a Uso general, identifique el objetivo de servicio de destino final. Asegúrese de que el tamaño asignado de la base de datos sea lo suficientemente pequeño como para ajustarse a ese objetivo de servicio.

Seleccione la pestaña del método preferido para realizar la migración inversa de la base de datos:

Azure Portal permite realizar la migración inversa al nivel de servicio De uso general modificando el plan de tarifa de la base de datos.

Vaya a la base de datos en Azure Portal.
En la barra de navegación de la izquierda, seleccione Proceso y almacenamiento.
Seleccione la lista desplegable Nivel de servicio para expandir las opciones de los niveles de servicio.
Seleccione De uso general (opciones de proceso y almacenamiento escalables) en el menú de la lista desplegable.
Revise la configuración de hardware que aparece. Si lo desea, seleccione Cambiar configuración para seleccionar la configuración de hardware adecuada para la carga de trabajo.
Seleccione el control deslizante Núcleos virtuales si quiere cambiar el número de núcleos virtuales disponibles para la base de datos en el nivel de servicio De uso general.
Selecciona Aplicar.
Supervise la conversión en Azure Portal.
1. Vaya a la base de datos en Azure Portal.
2. En la barra de navegación de la izquierda, seleccione Información general.
3. Revise la sección Notificaciones en la parte inferior del panel derecho. Si hay operaciones en curso, aparece un cuadro de notificación.
4. Para ver los detalles, seleccione el cuadro de notificación.
5. El panel Operaciones en curso se abre. Revise los detalles de las operaciones en curso.

En este ejemplo de código se llama a az sql db update para realizar la migración inversa de una base de datos de Hiperescala existente al nivel de servicio De uso general. Debe especificar tanto la edición como el objetivo de servicio. Puede seleccionar Provisioned o Serverless para el modelo de proceso de destino.

Reemplace resourceGroupName, serverName, databaseName y serviceObjective por los valores adecuados antes de ejecutar el ejemplo de código siguiente:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

Tiene la opción de incluir el argumento maxsize. Si el valor de maxsize supera el tamaño máximo válido para el objetivo de servicio de destino, se devuelve un error. Si no se especifica el argumento maxsize, la operación tiene como valor predeterminado el tamaño máximo disponible para el objetivo de servicio especificado. En el siguiente ejemplo se especifica maxsize:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

Supervise la operación en curso con az sql db op list. Para devolver operaciones recientes o en curso para una base de datos en Azure SQL Database:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName -n $databaseName

En este ejemplo de código se usa el cmdlet Set-AzSqlDatabase para revertir la migración de una base de datos existente de Hiperescala al nivel de servicio De uso general. Debe especificar tanto la edición como el objetivo de servicio. Puede seleccionar Provisioned o Serverless para el nivel de proceso de destino.

Antes de ejecutar este ejemplo de código, reemplace $resourceGroupName, $serverName, $databaseName, $serviceObjective y $computeModel por los valores adecuados:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

Supervise la operación en curso con el cmdlet Get-AzSqlDatabaseActivity , que devuelve operaciones recientes o en curso para una base de datos de Azure SQL Database. Antes de ejecutar el código de ejemplo, establezca los parámetros $resourceGroupName, $serverName y $databaseName en los valores adecuados para la base de datos:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName

Para migrar de forma inversa una base de datos de Hiperescala al nivel de servicio De uso general con Transact-SQL, primero conéctese a la base de datos en el masterservidor SQL lógico mediante SQL Server Management Studio (SSMS).

Debe especificar tanto la edición como el objetivo de servicio en la instrucción ALTER DATABASE.

Esta instrucción de ejemplo migra una base de datos denominada mySampleDatabase al nivel de servicio De uso general con el objetivo de servicio GP_Gen5_4. Reemplace el nombre de la base de datos y el objetivo de servicio por los valores adecuados antes de ejecutar la instrucción.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

Para supervisar las operaciones de una base de datos de Hiperescala, conéctese a la master base de datos del servidor lógico mediante SQL Server Management Studio (SSMS),la extensión mssql para Visual Studio Code o el cliente de su elección para ejecutar comandos Transact-SQL.

Consulte la vista de administración dinámica de sys.dm_operation_status para revisar la información sobre las operaciones recientes realizadas en las bases de datos del servidor lógico.

La sys.dm_operation_status vista de administración dinámica devuelve operaciones ordenadas por la más reciente. Reemplace el nombre de la base de datos por el valor adecuado antes de ejecutar el ejemplo de código.

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-07-17