Administración de una base de datos de Hiperescala

Se aplica a:Azure SQL Database

El nivel de servicio de Hperescala proporciona un nivel de rendimiento de proceso y almacenamiento muy escalable que aprovecha la arquitectura de Azure para escalar horizontalmente los recursos de proceso y almacenamiento para conseguir una instancia de Azure SQL Database que traspase considerablemente los límites disponibles para los niveles de servicio De uso general y Crítico para la empresa. En este artículo se describe cómo llevar a cabo tareas de administración esenciales para bases de datos de Hiperescala, incluida la migración de una base de datos existente a Hiperescala, la restauración de una base de datos de Hiperescala a otra región, la migración inversa de Hiperescala a otro nivel de servicio y la supervisión del estado de las operaciones en curso y recientes en una base de datos de Hiperescala.

Aprenda a crear una nueva base de datos de Hiperescala en Inicio rápido: Creación de una base de datos de Hiperescala en Azure SQL Database.

Sugerencia

Precios simplificados para Hiperescala de SQL Database en diciembre de 2023. Revise el blog de precios de Hiperescala para más información.

Migración de una base de datos existente a Hiperescala

Puede migrar bases de datos existentes en Azure SQL Database a Hiperescala mediante Azure Portal, la CLI de Azure, PowerShell o Transact-SQL.

El tiempo necesario para mover una base de datos existente a Hiperescala consta del tiempo para copiar los datos y el tiempo para reproducir los cambios realizados en la base de datos de origen mientras se copian los datos. El tiempo de la copia de datos es proporcional al tamaño de los datos. Se recomienda migrar a Hiperescala durante un período de actividad de escritura menor para que el tiempo de reproducción de los cambios acumulados sea más corto.

Solo experimentará un breve período de tiempo de inactividad, normalmente unos minutos, durante la transición final al nivel de servicio Hiperescala.

Requisitos previos

Para mover una base de datos que forma parte de una relación de replicación geográfica, ya sea como principal o como secundaria, a Hiperescala, debe terminar primero la replicación de datos entre la réplica principal y la secundaria. Las bases de datos de un grupo de conmutación por error deben quitarse primero del grupo.

Una vez que se ha trasladado una base de datos a Hiperescala, puede crear una nueva replicación geográfica de Hiperescala de esa base de datos.

Migración de una base de datos al nivel de servicio Hiperescala

Para migrar una base de datos existente en Azure SQL Database al nivel de servicio Hiperescala, primero identifique el objetivo de servicio de destino. 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. En muchos casos, puede elegir un objetivo de servicio con el mismo número de núcleos virtuales y la misma generación de hardware que la base de datos original. Si es necesario, puede cambiar el objetivo de servicio con un tiempo de inactividad mínimo.

Seleccione la pestaña de su herramienta preferida para migrar la base de datos:

Portal

Azure Portal permite migrar al nivel de servicio Hiperescala modificando el plan de tarifa de la base de datos.

1. Vaya a la base de datos que quiere migrar en Azure Portal.
2. En la barra de navegación de la izquierda, seleccione Proceso y almacenamiento.
3. Seleccione la lista desplegable Nivel de servicio para expandir las opciones de los niveles de servicio.
4. Seleccione Hiperescala (almacenamiento escalable a petición) en el menú de la lista desplegable.
5. 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.
6. Seleccione el control deslizante Núcleos virtuales si desea cambiar el número de núcleos virtuales disponibles para la base de datos en el nivel de servicio Hiperescala.
7. Seleccione el control deslizante High-AvailabilitySecondaryReplicas si quiere cambiar el número de réplicas en el nivel de servicio Hiperescala.
8. Seleccione Aplicar.

Puede supervisar las operaciones de una base de datos de Hiperescala mientras la operación está en curso.

CLI de Azure

En este ejemplo de código se llama a az sql db update para migrar una base de datos existente en Azure SQL Database al nivel de servicio Hiperescala. Debe especificar tanto la edición como el objetivo de servicio.

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="HS_Gen5_2"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition Hyperscale --service-objective $serviceObjective

Puede supervisar las operaciones de una base de datos de Hiperescala mientras la operación está en curso.

PowerShell

En el ejemplo siguiente se usa el cmdlet Set-AzSqlDatabase para migrar una base de datos existente en Azure SQL Database al nivel de servicio Hiperescala. Debe especificar tanto la edición como el objetivo de servicio.

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

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

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "Hyperscale" `
    -RequestedServiceObjectiveName $serviceObjective

Puede supervisar las operaciones de una base de datos de Hiperescala mientras la operación está en curso.

Transact-SQL

Para migrar una base de datos existente en Azure SQL Database al nivel de servicio Hiperescala con Transact-SQL, primero conéctese a la base de datos master en su servidor lógico de SQL mediante el Editor de consultas de Azure Portal para Azure SQL Database, SQL Server Management Studio (SSMS) o Azure Data Studio.

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 Hiperescala con el objetivo de servicio HS_Gen5_2. Reemplace el nombre de la base de datos por el valor adecuado antes de ejecutar la instrucción.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_2');
GO

Puede supervisar las operaciones de una base de datos de Hiperescala mientras la operación está en curso.

Migración inversa desde Hiperescala

La migración inversa al nivel de servicio De uso general permite a los clientes que han migrado recientemente una base de datos existente de Azure SQL Database al nivel de servicio Hiperescala para retroceder en caso de emergencia si Hiperescala no satisface sus necesidades. Aunque la migración inversa comienza con un cambio de nivel de servicio, básicamente es un movimiento de tamaño de 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 de Hiperescala forma parte de un grupo elástico de Hiperescala (versión preliminar), primero debe quitarla del grupo elástico de Hiperescala antes de la migración inversa.
  • Una vez completada la migración inversa, puede agregar opcionalmente la base de datos única de uso general a un grupo elástico de uso general si es necesario.
• 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 de 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.

Requisitos previos

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 migrar una base de datos a Hiperescala y realiza la migración inversa a De uso general 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:

1. De uso general
2. Migración a Hiperescala
3. Migración inversa a De uso general
4. Cambio del nivel de servicio a Crítico para la empresa
5. Migración a Hiperescala
6. 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 quiere realizar un cambio de nivel de servicio adicional después de realizar la migración inversa a De uso general, identifique también el objetivo de servicio de destino final y 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:

Portal

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.

1. Vaya a la base de datos que quiere migrar en Azure Portal.
2. En la barra de navegación de la izquierda, seleccione Proceso y almacenamiento.
3. Seleccione la lista desplegable Nivel de servicio para expandir las opciones de los niveles de servicio.
4. Seleccione De uso general (opciones de proceso y almacenamiento escalables) en el menú de la lista desplegable.
5. 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.
6. 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.
7. Seleccione Aplicar.

CLI de Azure

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

Puede supervisar las operaciones de una base de datos de Hiperescala mientras la operación está en curso.

PowerShell

En este ejemplo de código se usa el cmdlet Set-AzSqlDatabase para realizar la migración inversa de una base de datos existente del nivel de servicio 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

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"
$maxSizeBytes = "268435456000"

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

Puede supervisar las operaciones de una base de datos de Hiperescala mientras la operación está en curso.

Transact-SQL

Para realizar la migración inversa de una base de datos de Hiperescala al nivel de servicio De uso general con Transact-SQL, primero conéctese a la base de datos master en el servidor de SQL lógico mediante SQL Server Management Studio (SSMS), Azure Data Studio.

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

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:

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

Puede supervisar las operaciones de una base de datos de Hiperescala mientras la operación está en curso.

Supervisión de operaciones para una base de datos de Hiperescala

Puede supervisar el estado de las operaciones en curso o completadas recientemente para una instancia de Azure SQL Database mediante Azure Portal, la CLI de Azure, PowerShell o Transact-SQL.

Seleccione la pestaña del método preferido para supervisar las operaciones.

Portal

Azure Portal muestra una notificación para la base de datos en Azure SQL Database cuando hay una operación, por ejemplo, una migración, una migración inversa o una restauración en curso.

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. Seleccione el cuadro de notificación para ver los detalles.
5. El panel Operaciones en curso se abre. Revise los detalles de las operaciones en curso.

CLI de Azure

En este ejemplo de código se llama a az sql db op list para devolver las operaciones recientes o en curso para una base de datos de Azure SQL Database.

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"

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

PowerShell

El cmdlet Get-AzSqlDatabaseActivity 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

Transact-SQL

Para supervisar las operaciones de una base de datos de Hiperescala, primero conéctese a la base de datos master en el servidor lógico mediante SQL Server Management Studio (SSMS), Azure Data Studio o el cliente de su elección para ejecutar comandos de 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](logical-servers.md].

En este ejemplo de código se devuelven todas las entradas de sys.dm_operation_status para la base de datos especificada, ordenada por las operaciones que comenzaron más recientemente. 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

Visualización de bases de datos en el nivel de servicio Hiperescala

Después de migrar una base de datos a Hiperescala o volver a configurar una base de datos dentro del nivel de servicio Hiperescala, es posible que quiera ver o documentar la configuración de la base de datos de Hiperescala.

Portal

Azure Portal muestra una lista de todas las bases de datos de un servidor lógico. La columna Plan de tarifa incluye el nivel de servicio para cada base de datos.

1. Vaya al servidor lógico en Azure Portal.
2. En la barra de navegación de la izquierda, seleccione Información general.
3. Desplácese hasta la lista de recursos en la parte inferior del panel. En la ventana se muestran los grupos elásticos y las bases de datos de SQL que hay en el servidor lógico.
4. Revise la columna Plan de tarifa para identificar las bases de datos en el nivel de servicio Hiperescala.

CLI de Azure

En este ejemplo de código de la CLI de Azure se llama a az sql db list para enumerar las bases de datos de Hiperescala en un servidor lógico con su nombre, ubicación, objetivo de nivel de servicio, tamaño máximo y número de réplicas de alta disponibilidad.

Antes de ejecutar el ejemplo de código siguiente, reemplace resourceGroupName y serverName por los valores adecuados:

resourceGroupName="myResourceGroup"
serverName="server01"

az sql db list -g $resourceGroupName -s $serverName --query "[].{Name:name, Location:location, SLO:currentServiceObjectiveName, Tier:currentSku.tier, maxSizeBytes:maxSizeBytes,HAreplicas:highAvailabilityReplicaCount}[?Tier=='Hyperscale']" --output table

PowerShell

El cmdlet Get-AzSqlDatabase de Azure PowerShell devuelve una lista de bases de datos de Hiperescala en un servidor lógico con su nombre, ubicación, objetivo de nivel de servicio, tamaño máximo y número de réplicas de alta disponibilidad.

Antes de ejecutar el código de ejemplo, establezca los parámetros $resourceGroupName y $serverName en los valores adecuados:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"

Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName | `
    Where-Object { $_.Edition -eq 'Hyperscale' } | `
        Select-Object DatabaseName, Location, currentServiceObjectiveName, Edition, `
        MaxSizeBytes, HighAvailabilityReplicaCount | `
            Format-Table

Revise la columna Edición para identificar las bases de datos en el nivel de servicio Hiperescala.

Transact-SQL

Para revisar los niveles de servicio de todas las bases de datos de Hiperescala en un servidor lógico con Transact-SQL, primero conéctese a la base de datos master mediante SQL Server Management Studio (SSMS) o Azure Data Studio.

Consulte la vista de catálogo del sistema sys.database_service_objectives para revisar las bases de datos en el nivel de servicio Hiperescala:

SELECT d.name, dso.edition, dso.service_objective
FROM sys.database_service_objectives AS dso
JOIN sys.databases as d on dso.database_id = d.database_id
WHERE dso.edition = 'Hyperscale';
GO

Contenido relacionado

Puede encontrar más información sobre las bases de datos de Hiperescala en los siguientes artículos:

• Inicio rápido: Creación de una base de datos de Hiperescala en Azure SQL Database
• Nivel de servicio Hiperescala
• Preguntas más frecuentes sobre Hiperescala de Azure SQL Database
• Réplicas secundarias de Hiperescala
• Preguntas frecuentes sobre réplicas con nombre de Hiperescala de Azure SQL Database