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

Se aplica a: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 DTU, puede escalar una sola base de datos hacia arriba o hacia abajo de forma dinámica según la experiencia de uso real mediante:

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

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 informática.

   Las conexiones existentes con la base de datos en la instancia de procesamiento original se cierran. Las nuevas conexiones con la base de datos se establecen en la nueva instancia de computación. 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 cambio puede provocar una breve interrupción del servicio cuando la base de datos no está disponible, por lo general durante menos de 30 segundos y, a menudo, solo durante 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 acelerada de bases de datos puede reducir el impacto de abortar transacciones de larga duración.

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:

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');

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.

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

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

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

$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

$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 corresponder al del administrador del servidor (que se creó cuando se aprovisionó el servidor lógico de Azure SQL Database), al administrador de Microsoft Entra del servidor, a un miembro del rol de base de datos dbmanager en master, a un miembro del rol de base de datos db_owner en la base de datos actual, o a dbo de la base de datos. Para más información, consulte ALTER DATABASE.

Para escalar bases de datos mediante el portal de Azure, PowerShell, la CLI de Azure o la API REST: se necesitan permisos de Azure RBAC, concretamente el rol Colaborador, el rol Colaborador de SQL DB o el rol Colaborador de SQL Server. Para más información, consulte Roles integrados de Azure RBAC.

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 reducir la versión de una base de datos con la replicación geográfica habilitada, reduzca primero sus bases de datos primarias al nivel de servicio y la capacidad de proceso deseados antes de reducir la versión de la base de datos secundaria (recomendación general para obtener el 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 plan inferior Básico, el período de retención de las copias de seguridad es menor. Consulte Copias de seguridad automatizadas en 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 recuperación acelerada de la base de datos, la reversión de las transacciones de larga duración no supone una fuente significativa de retraso, pero un uso elevado y simultáneo de recursos podría dejar menos recursos de capacidad de proceso, almacenamiento y ancho de banda de red para escalar, especialmente en tamaños de proceso más reducidos.

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 vCore

• 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 de almacenamiento de datos para cada objetivo de servicio, consulte las páginas de documentación sobre límites de recursos para bases de datos únicas que utilizan el modelo de compra de núcleo virtual y bases de datos únicas que utilizan el modelo de compra de DTU.

• 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 del tamaño máximo se especifica en bytes, debe ser un múltiplo de 1 GB (1.073.741.824 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.

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.

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. Más adelante, la base de datos puede reescalarse a un tamaño de cálculo diferente siempre que la cantidad de espacio asignada en el momento de la operación de reescalado no supere los límites máximos del nuevo tamaño de cálculo.
• 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 más pequeños se rechazan como secundarios, 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 completarse correctamente para que el cambio en el sistema 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

• Límites de recursos para bases de datos individuales que utilizan el modelo de compra basado en vCore
• Límites de recursos para bases de datos únicas mediante el modelo de compra de DTU: Azure SQL Database