Escalar recursos de base de datos única en Azure SQL Database

En este artículo se describe cómo escalar los recursos de proceso y almacenamiento disponibles para una instancia de Azure SQL Database en el nivel de proceso aprovisionado. Como alternativa, el nivel de proceso sin servidor proporciona escalado automático de proceso y se factura por segundo el proceso que se usa.

Después de elegir inicialmente el número de núcleos virtuales o de DTU, puede escalar o reducir verticalmente una base de datos única de forma dinámica en función de la experiencia real, para lo que puede usar:

• Transact-SQL
• Azure Portal
• PowerShell
• CLI de Azure
• REST API

Importante

En algunas circunstancias, puede que deba reducir una base de datos para reclamar el espacio no utilizado. Para obtener más información, consulte Administración del espacio de archivo en Azure SQL Database.

Nota:

Microsoft Entra ID era conocido anteriormente como Azure Active Directory (Azure AD).

Impacto

El cambio en el nivel de servicio o el tamaño de proceso implica principalmente que el servicio realice los pasos siguientes:

1. Cree una instancia de proceso nueva para la base de datos.

   Se crea una instancia de proceso nueva con el tamaño de proceso y el nivel de servicio solicitados. Para algunas combinaciones de cambios en el nivel de servicio y el tamaño de proceso, se debe crear una réplica de la base de datos en la nueva instancia de proceso, lo que implica copiar los datos y puede influir en gran medida en la latencia general. En cualquier caso, la base de datos permanece en línea durante este paso y las conexiones se continúan dirigiendo a la base de datos en la instancia de proceso original.

2. Cambie el enrutamiento de las conexiones a una nueva instancia de proceso.

   Se colocan las conexiones existentes en la base de datos en la instancia de proceso original. En la nueva instancia de proceso las nuevas conexiones se establecen en la base de datos. Para algunas combinaciones de cambios de nivel de servicio y de tamaño de proceso, los archivos de base de datos se desasocian y se vuelven a asociar durante la modificación. No obstante, el modificador puede provocar una breve interrupción del servicio cuando la base de datos no esté disponible de forma general durante menos de 30 segundos y, a menudo, durante solo unos segundos. Si hay transacciones de ejecución prolongada que se ejecutan cuando se eliminan las conexiones, la duración de este paso puede ser mayor con el fin de recuperar las transacciones anuladas. La Recuperación de base de datos acelerada puede reducir el impacto de la anulación de transacciones de larga duración.

Importante

Durante los pasos del flujo de trabajo no se pierden datos. Asegúrese de que ha implementado alguna lógica de reintento en las aplicaciones y los componentes que utilizan Azure SQL Database mientras se cambia el nivel de servicio.

Latencia

La latencia estimada para cambiar el nivel de servicio, escalar el tamaño de proceso de una sola base de datos o grupo elástico, trasladar una base de datos dentro o fuera de un grupo elástico o trasladar una base de datos entre grupos elásticos incluye los parámetros que se indican a continuación:

Latencia de escalado de bases de datos	A base de datos única básica, Base de datos única Estándar (S0-S1)	A base de datos única Estándar (S2-S12), Base de datos única de uso general, Base de datos agrupada elástica básica, Base de datos agrupada elástica Estándar Base de datos agrupada de uso general	A una base de datos única Premium o una base de datos agrupada, Base de datos única crítica para la empresa o base de datos agrupada	A base de datos única de Hiperescala o base de datos agrupada
Desde base de datos única básica, base de datos única Estándar (S0-S1)	• Latencia de tiempo constante independiente del espacio usado. • Normalmente, menos de 5 minutos.	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.
Desde base de datos agrupada básica, Base de datos única Estándar (S2-S12), Base de datos agrupada Estándar, Base de datos única de uso general o base de datos agrupada	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.	• Para bases de datos únicas, latencia de tiempo constante independiente del espacio usado. • Normalmente, menos de 5 minutos para bases de datos únicas. • Para grupos elásticos, proporcional al número de bases de datos.	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.
Desde una base de datos única premium o una base de datos agrupada, Base de datos única crítica para la empresa o base de datos agrupada	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.	• Latencia proporcional al espacio de base de datos usado debido a la copia de datos. • Normalmente, menos de 1 minuto por GB de espacio usado.
Desde una base de datos única de Hiperescala o una base de datos agrupada	N/D	Vea Migración inversa desde Hiperescala para obtener los escenarios y limitaciones admitidos.	N/D	• Latencia de tiempo constante independiente del espacio usado. • Normalmente, menos de 2 minutos.

Nota:

• Además, en el caso de las bases de datos Estándar (S2-S12) y De uso general, la latencia para mover una base de datos dentro o fuera de un grupo elástico o entre grupos elásticos será proporcional al tamaño de la base de datos si esta usa almacenamiento de recursos compartidos de archivos Premium (PFS).
• En caso de mover una base de datos a un grupo elástico o desde este, solo el espacio que usa la base de datos, y no el del grupo elástico, afecta a la latencia.
• Para determinar si una base de datos usa el almacenamiento PFS, ejecute la siguiente consulta en el contexto de la base de datos. Si el valor de la columna AccountType es PremiumFileStorage o PremiumFileStorage-ZRS, la base de datos usa almacenamiento PFS.

SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

Nota:

• La propiedad con redundancia de zona seguirá siendo la misma de forma predeterminada al escalar del nivel Crítico para la empresa al nivel De uso general.
• La latencia de la operación de escalado cuando se cambia la redundancia de zona para una base de datos única de uso general es proporcional al tamaño de la base de datos.

Sugerencia

Para supervisar las operaciones en curso, consulte: Administración de operaciones mediante la API REST de SQL, Administración de operaciones mediante la CLI, Supervisión de operaciones mediante T-SQL y estos dos comandos de PowerShell: Get-AzSqlDatabaseActivity y Stop AzSqlDatabaseActivity.

Supervisión o cancelación de cambios de escalado

Un cambio del nivel de servicio o una operación de cambio de escala del proceso se puede supervisar y cancelar.

Azure Portal

En la página Información general de SQL Database, busque el banner que indica que una operación de escalado está en curso y seleccione el vínculo Ver más para la implementación en curso.

En la página Operaciones en curso, seleccione Cancelar esta operación.

PowerShell

Para invocar los comandos de PowerShell en un ordenador, el paquete Az versión 9.7.0 o una versión más reciente debe estar instalado localmente. O bien, considere la posibilidad de usar Azure Cloud Shell para ejecutar Azure PowerShell en shell.azure.com.

En primer lugar, inicie sesión en Azure y establezca el contexto adecuado para la suscripción:

Login-AzAccount
$SubscriptionID = "<YourSubscriptionIdHere>"
Select-AzSubscription -SubscriptionName $SubscriptionID

Para supervisar las operaciones en una base de datos, incluidas las operaciones de escalado, use Get-AzSqlDatabaseActivity. En el ejemplo siguiente se devuelve un valor de OperationId para cada operación que se está ejecutando actualmente.

Get-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01"

Para cancelar una operación asincrónica como una escala de base de datos, identifique la operación y, a continuación, use Stop-AzSqlDatabaseActivity con un valor de OperationId específico, como en el ejemplo siguiente.

Stop-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" -OperationId af97005d-9243-4f8a-844e-402d1cc855f5

CLI de Azure

Desde un terminal de Cloud Shell, use el siguiente comando de ejemplo para identificar las operaciones que se están ejecutando actualmente. Desde un terminal de Cloud Shell, establezca las variables $resourceGroupName, $serverName y $databaseName, y, a continuación, ejecute el siguiente comando:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv

Para detener una operación asincrónica como un escalado de base de datos, desde un terminal de Cloud Shell, establezca las variables $resourceGroupName, $serverName y $databaseName, y, a continuación, ejecute el siguiente comando:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

Permisos

Para escalar bases de datos a través de Transact-SQL, se usa ALTER DATABASE. Para escalar una base de datos, el inicio de sesión debe ser el del administrador del servidor (creado al aprovisionar el servidor lógico de Azure SQL Database), el administrador de Microsoft Entra del servidor, un miembro del rol de base de datos dbmanager en master, un miembro del rol de base de datos db_owner en la base de datos actual, o dbo de la base de datos. Para más información, consulte ALTER DATABASE.

Para escalar bases de datos a través de Azure Portal, PowerShell, la CLI de Azure o la API REST, se necesitan permisos de RBAC de Azure, específicamente el Colaborador, el rol Colaborador de base de datos SQL o roles RBAC de Azure Colaborador de SQL Server. Para obtener más información, visite la sección sobre roles integrados RBAC de Azure.

Consideraciones adicionales

• Si va a actualizar a un nivel de servicio o tamaño de proceso más elevado, el tamaño máximo de la base de datos no aumenta a menos que especifique un tamaño mayor (maxsize).
• Para cambiar una base de datos a una versión anterior, su espacio usado no debe alcanzar el tamaño máximo permitido del nivel de servicio de destino y del tamaño de proceso.
• Al pasar del nivel Premium al nivel Estándar, se aplica un costo de almacenamiento adicional si (1) el tamaño máximo de la base de datos es compatible con el tamaño de proceso de destino y (2) el tamaño máximo supera la cantidad de almacenamiento incluido del tamaño de proceso de destino. Por ejemplo, si una base de datos P1 con un tamaño máximo de 500 GB se reduce a S3, se aplica un costo de almacenamiento adicional porque S3 admite un tamaño máximo de 1 TB y su cantidad de almacenamiento incluido es solo de 250 GB. Por lo tanto, la cantidad de almacenamiento adicional es 500 GB – 250 GB = 250 GB. Para conocer el precio del almacenamiento adicional, consulte los precios de Azure SQL Database. Si la cantidad de espacio real utilizada es menor que la cantidad de almacenamiento incluido, este costo adicional puede evitarse si se reduce el tamaño máximo de la base de datos a la cantidad incluida.
• Al actualizar una base de datos con la replicación geográfica habilitada, actualice sus bases de datos secundarias al nivel de servicio y al tamaño de proceso deseados antes de actualizar la base de datos principal (instrucciones generales para mejorar el rendimiento). Si se realiza la actualización a una edición diferente, es necesario actualizar primero la base de datos secundaria.
• Al cambiar a una versión anterior la base de datos con la replicación geográfica habilitada, se cambian también sus bases de datos principales al nivel de servicio y tamaño de proceso deseados antes de cambiar a una versión anterior la base de datos secundaria (regla general para un mejor rendimiento). Si se realiza la actualización a una edición diferente, es necesario actualizar primero la base de datos secundaria.
• Las ofertas del servicio de restauración son diferentes para los distintos niveles de servicio. Si va a cambiar al nivel Básico, hay un período de retención de copia de seguridad más bajo. Consulte el artículo sobre Copias de seguridad de Azure SQL Database.
• Las nuevas propiedades de la base de datos no se aplican hasta que se completan los cambios.
• Cuando es necesario copiar datos para escalar una base de datos (consulte Latencia) al cambiar el nivel de servicio, el uso elevado de recursos simultáneamente a la operación de escalado puede dar lugar a tiempos de escalado más largos. Con la recuperación acelerada de la base de datos (ADR), la reversión de las transacciones de larga duración no es una causa de retraso significativa, pero el uso elevado de recursos simultáneamente puede dejar menos recursos de proceso, almacenamiento y ancho de banda de red para el escalado, especialmente para tamaños de proceso más pequeños.

Facturación

Se le cobrará por cada hora que una base de datos exista con el mayor nivel de servicio + tamaño de proceso aplicable durante esa hora, independientemente del uso o de si la base de datos estuvo activa durante menos de una hora. Por ejemplo, si crea una base de datos única y la elimina a los cinco minutos, se le efectuará un cargo de una hora por usar la base de datos.

Modificar el tamaño de almacenamiento

Modelo de compra basado en núcleo virtual

• Se puede aprovisionar el almacenamiento hasta el límite máximo de tamaño del almacenamiento de datos con incrementos de 1 GB. El almacenamiento de datos mínimo configurable es 1 GB. Para conocer los límites máximos de tamaño del almacenamiento de datos de cada objetivo de servicio, consulte las páginas de documentación de los límites de recursos en Límites de recursos para bases de datos únicas que utilizan el modelo de compra en núcleos virtuales y Límites de recursos de bases de datos únicas que usan el modelo de compra de DTU: Azure SQL Database.

• Se puede aprovisionar almacenamiento de datos para una base de datos única mediante el aumento o disminución de su tamaño máximo con Azure Portal, Transact-SQL, PowerShell, la CLI de Azure o la API de REST. Si el valor de tamaño máximo se especifica en bytes, debe ser un múltiplo de 1 GB (1073741824 bytes).

• La cantidad de datos que se pueden almacenar en los archivos de datos de una base de datos está limitada por el tamaño máximo del almacenamiento de datos configurado. Además de ese almacenamiento, Azure SQL Database añade automáticamente un 30 % de almacenamiento adicional que se va a usar para el registro de transacciones. El precio de almacenamiento para una única base de datos o un grupo elástico es la suma de las cantidades de almacenamiento de datos y de registros de transacciones, multiplicada por el precio de la unidad de almacenamiento del nivel de servicio. Por ejemplo, si el almacenamiento de datos se establece en 10 GB, el almacenamiento del registro de transacciones adicional es de 10 GB * 30 % = 3 GB y la cantidad total de almacenamiento facturable es de 10 GB + 3 GB = 13 GB.

  Nota:

  El tamaño máximo del archivo de registro de transacciones se administra automáticamente y, en algunos casos, puede ser mayor que el 30 % del tamaño máximo del almacenamiento de datos. Esto no aumenta el precio del almacenamiento de la base de datos.

• Azure SQL Database asigna automáticamente 32 GB por núcleo virtual para la base de datos tempdb. tempdb se encuentra en el almacenamiento local de SSD en todos los niveles de servicio. El coste de tempdb se incluye en el precio de una base de datos única o un grupo elástico.

• Para más información sobre el precio del almacenamiento, consulte los precios de Azure SQL Database.

Importante

En algunas circunstancias, puede que deba reducir una base de datos para reclamar el espacio no utilizado. Para obtener más información, consulte Administración del espacio de archivo en Azure SQL Database.

Modelo de compra basado en DTU

• El precio de la DTU para una base de datos única incluye una cierta cantidad de almacenamiento sin costo adicional. El almacenamiento adicional que supere la cantidad incluida se puede aprovisionar por un costo extra hasta el límite de tamaño máximo en incrementos de 250 GB hasta 1 TB, y luego en incrementos de 256 GB superando 1 TB. Para más información sobre los límites de tamaño máximo y las cantidades de almacenamiento incluidas, consulte Base de datos única: tamaños de almacenamiento y tamaños de proceso.
• Se puede aprovisionar almacenamiento adicional para una base de datos única aumentando su tamaño máximo con Azure Portal, Transact-SQL, PowerShell, la CLI de Azure o la API de REST.
• El precio del almacenamiento adicional para una base de datos única es la cantidad de almacenamiento adicional multiplicado por el precio de la unidad de almacenamiento adicional del nivel de servicio. Para más información sobre el precio del almacenamiento adicional, consulte los precios de Azure SQL Database.

Importante

En algunas circunstancias, puede que deba reducir una base de datos para reclamar el espacio no utilizado. Para obtener más información, consulte Administración del espacio de archivo en Azure SQL Database.

Base de datos con replicación geográfica

Para cambiar el tamaño de una base de datos secundaria replicada, cambie el tamaño de la base de datos principal. A continuación, este cambio se replicará y se implementará también en la base de datos secundaria.

P11 y P15 se restringen cuando el tamaño máximo es mayor de 1 TB

Existe más de 1 TB de almacenamiento en el nivel Premium actualmente disponible en todas las regiones excepto: Este de China, Norte de China, Centro de Alemania y Noreste de Alemania. En estas regiones, el almacenamiento máximo en el nivel Prémium está limitado a 1 TB. Las siguientes consideraciones y limitaciones se aplican a las bases de datos P11 y P15 con un tamaño máximo mayor de 1 TB:

• Si el tamaño máximo de una base de datos P11 o P15 nunca se estableció en un valor mayor que 1 TB, entonces solo puede restablecerse o copiarse a una base de datos P11 o P15. Posteriormente, la base de datos puede escalarse de nuevo a un tamaño de proceso diferente siempre que la cantidad de espacio asignado en el momento de la operación de cambio de escala no supere los límites de tamaño máximo con el nuevo tamaño de proceso.
• En escenarios de replicación geográfica activa:
  • Configuración de una relación de replicación geográfica: Si la base de datos principal es P11 o P15, las secundarias también deben ser P11 o P15. Los tamaños de proceso menores se rechazan como secundarias, ya que no admiten más de 1 TB.
  • Actualización de la base de datos principal en una relación de replicación geográfica: al cambiar el tamaño máximo a 1 TB en una base de datos principal, se desencadenará el mismo cambio en la base de datos secundaria. Ambas actualizaciones deben realizarse correctamente para que el cambio en la principal surta efecto. Se aplican limitaciones por región para la opción de más de 1 TB. Si la base de datos secundaria está en una región que no admite más de 1 TB, no se actualizará la principal.
• No se admite el uso del servicio Import/Export para cargar bases de datos P11 y P15 con más de 1 TB. Use SqlPackage para importar y exportar datos.

Contenido relacionado

Para conocer los límites de recursos globales, consulte Límites de recursos basados en núcleos virtuales de Azure SQL Database para bases de datos únicas y Límites de recursos de bases de datos únicas que usan el modelo de compra de DTU: Azure SQL Database.