Nivel de proceso Sin servidor para Azure SQL Database

  • Artículo

Se aplica a:Azure SQL Database

Sin servidor es un nivel de proceso para las bases de datos únicas de Azure SQL Database que escala automáticamente el proceso en función de la demanda de carga de trabajo y se factura según la cantidad de proceso usada por segundo. El nivel de proceso sin servidor también detiene automáticamente las bases de datos durante períodos inactivos cuando solo se factura el almacenamiento y reanuda automáticamente las bases de datos cuando finaliza la actividad. El nivel de proceso sin servidor está disponible en el nivel de servicio De uso general y en el nivel de servicio Hiperescala.

Nota:

La pausa y reanudación automáticas solo se admiten de momento en el nivel de servicio De uso general.

Información general

Un intervalo de escalado automático de proceso y un retraso de pausa automática son parámetros importantes para el nivel de proceso sin servidor. La configuración de estos parámetros da forma a la experiencia de rendimiento de la base de datos y el costo de proceso.

Diagram indicating when serverless billing would stop incurring compute charges due to inactivity.

Configuración del rendimiento

  • Los valores mínimos de núcleos virtuales y los valores máximos de núcleos virtuales son parámetros configurables que definen el intervalo de capacidad de proceso disponible para la base de datos. Los límites de memoria y E/S son proporcionales al intervalo de núcleos virtuales especificado. 
  • La demora de pausa automática es un parámetro configurable que define el período de tiempo de que la base de datos debe estar inactiva antes de pausarse automáticamente. La base de datos se reanuda automáticamente cuando se produce el siguiente inicio de sesión u otra actividad. Como alternativa, se puede deshabilitar la pausa automática.

Coste

  • El coste de una base de datos sin servidor es la suma del coste de proceso y el coste de almacenamiento.
  • Cuando el uso de proceso se sitúa entre los límites mínimos y máximos configurados, el coste de proceso se basa en el núcleo virtual y la memoria utilizada.
  • Cuando el uso de proceso está por debajo de los límites mínimos configurados, el coste de proceso se basa en los núcleos virtuales mínimos y la cantidad mínima de memoria configurada.
  • Cuando se pausa la base de datos, el coste de proceso es cero y solo se incurre en costes de almacenamiento.
  • El coste de almacenamiento se determina de la misma manera que el nivel de proceso aprovisionado.

Para más detalles sobre costes, consulte Facturación.

Escenarios

Este nivel de proceso sin servidor ofrece una relación entre precio y rendimiento optimizada para bases de datos únicas con patrones de uso intermitentes e impredecibles, que pueden permitirse alguna demora en el calentamiento de los recursos de proceso después de períodos de inactividad. En cambio, el nivel de proceso aprovisionado ofrece una relación entre precio y rendimiento optimizada para bases de datos únicas o varias bases de datos en grupos elásticos con mayor uso medio que no pueden permitirse ninguna demora en el calentamiento de los recursos de proceso.

Escenarios adecuados para el proceso sin servidor

  • Bases de datos únicas con patrones de uso impredecibles e intermitentes, intercalados con períodos de inactividad y menor uso promedio de proceso a lo largo del tiempo.
  • Bases de datos únicas en el nivel de proceso aprovisionado con frecuentes cambios de escala y clientes que prefieren delegar el cambio de escala del proceso en el servicio.
  • Nuevas bases de datos únicas sin historial de uso donde el tamaño de proceso es difícil (o incluso imposible) de estimar antes de la implementación en una base de datos de Azure SQL.

Escenarios adecuados para el proceso aprovisionado

  • Bases de datos únicas con patrones de uso más regular y predecible y mayor uso promedio de proceso a lo largo del tiempo.
  • Bases de datos que no pueden tolerar compensaciones de rendimiento resultantes de recortes de memoria más frecuentes o de demoras en la reanudación automática desde un estado de pausa.
  • Varias bases de datos con patrones de uso impredecibles e intermitentes que se pueden consolidar en grupos elásticos para una mejor optimización de la relación precio-rendimiento.

Comparación de los niveles de proceso

La tabla siguiente resume las diferencias entre el nivel de proceso sin servidor y el nivel de proceso aprovisionado:

Proceso sin servidor Proceso aprovisionado
Patrones de uso de bases de datos Uso intermitente e impredecible con menor uso promedio de proceso a lo largo del tiempo. Patrones de uso más regulares con mayor uso promedio de proceso a lo largo del tiempo, o varias bases de datos que usen grupos elásticos.
Trabajo de administración del rendimiento Inferior Superior
Escalado de proceso Automático Manual
Capacidad de respuesta del proceso Menor después de períodos de inactividad Inmediata
Granularidad de facturación Por segundo Por hora

Modelo de compra y nivel de servicio

En la tabla siguiente se describe la compatibilidad sin servidor en función del modelo de compra, los niveles de servicio y el hardware:

Categoría Compatible No compatible
Modelo de compra vCore DTU
Nivel de servicio Uso general
Hiperescala		 Crítico para la empresa
Hardware Serie estándar (Gen5) El resto de hardware

Escalado automático

Escalado de la capacidad de respuesta

Las bases de datos sin servidor se ejecutan en una máquina con capacidad suficiente para satisfacer la demanda de recursos sin interrupciones para cualquier cantidad de proceso solicitada dentro de los límites establecidos por el valor máximo de núcleos virtuales. En ocasiones, se produce automáticamente un equilibrio de carga si la máquina no puede satisfacer la demanda de recursos en cuestión de minutos. Por ejemplo, si la demanda de recursos es de 4 núcleos virtuales, pero solo hay 2 disponibles, puede que se tarde unos minutos en equilibrar la carga antes de que se proporcionen los 4 núcleos virtuales. La base de datos permanece en línea durante el equilibrio de carga excepto durante un breve período al final de la operación cuando se deshabilitan las conexiones.

Administración de memoria

En los niveles de servicio De uso general e Hiperescala, la memoria de las bases de datos sin servidor se reclama con mayor frecuencia que la de las bases de datos de proceso aprovisionadas. Este comportamiento es importante para controlar costos en el nivel de proceso sin servidor y puede afectar al rendimiento.

Reclamación de memoria caché

A diferencia de las bases de datos de proceso aprovisionadas, la memoria de la caché de SQL se reclama desde una base de datos sin servidor cuando el uso de CPU o de la memoria caché activa es bajo.

  • El uso de la memoria caché activa se considera bajo cuando el tamaño total de las entradas de caché más recientes está por debajo de un determinado umbral durante un periodo de tiempo.
  • Cuando se desencadena la reclamación de la memoria caché, el tamaño de la caché de destino se reduce de forma incremental a una fracción del tamaño anterior y la reclamación solo continúa si el uso sigue siendo bajo.
  • Cuando se produce la reclamación de memoria caché, la directiva para seleccionar las entradas de esta que se van a expulsar es la misma directiva de selección que para las bases de datos de proceso aprovisionadas cuando la presión de memoria es elevada.
  • El tamaño de la memoria caché no se reduce nunca por debajo del límite de memoria mínimo definido por el número mínimo de núcleos virtuales.

En el caso de las bases de datos sin servidor y las de proceso aprovisionadas, se pueden expulsar entradas de la caché si se usa toda la memoria disponible.

Cuando el uso de la CPU es bajo, la utilización de la caché activa puede ser alto en función del patrón de uso e impedir la reclamación de memoria. Además, puede haber otros retrasos después de que la actividad del usuario se detenga antes de que se produzca la reclamación de la memoria debido a los procesos en segundo plano periódicos que responden a la actividad anterior del usuario. Por ejemplo, las operaciones de eliminación y las tareas de limpieza del Almacén de consultas generan registros fantasma que se marcan para su eliminación, pero no se eliminan físicamente hasta que se ejecuta el proceso de limpieza de registros fantasma. La limpieza de registros fantasma puede suponer la lectura de páginas de datos en la caché.

Hidratación de la memoria caché

La memoria caché de SQL crece a medida que se capturan datos del disco de la misma manera y a la misma velocidad que para las bases de datos aprovisionadas. Cuando la base de datos está ocupada, la memoria caché puede crecer sin restricciones mientras haya memoria disponible.

Administración de la memoria caché de disco

En el nivel de servicio Hiperescala para los niveles de proceso aprovisionados y sin servidor, cada réplica de proceso usa una caché de la extensión del grupo de búferes resistentes (RBPEX), que almacena páginas de datos en el SSD local para mejorar el rendimiento de E/S. Sin embargo, en el nivel de proceso sin servidor para Hiperescala, la caché RBPEX para cada réplica de proceso crece y disminuye automáticamente en respuesta al aumento y la reducción de la demanda de la carga de trabajo. El tamaño máximo que puede alcanzar la caché RBPEX es tres veces la memoria máxima configurada para la base de datos. Para obtener más información sobre los límites de escalado automático de RBPEX y de memoria máximos si no hay servidor, consulte los límites de recursos de Hiperescala sin servidor.

Pausa automática y reanudación automática

De momento, la pausa y reanudación automáticas solo se admiten en el nivel De uso general.

Pausa automática

La pausa automática se desencadena si todas las condiciones siguientes se cumplen durante la demora de pausa automática:

  • Número de sesiones = 0
  • CPU = 0 para la carga de trabajo de usuario que se ejecuta en el grupo de usuarios

Hay disponible una opción para deshabilitar la pausa automática si se desea.

Las características siguientes no admiten la pausa automática, pero admiten el escalado automático. Si se utiliza cualquiera de las siguientes características, la pausa automática debe estar desactivada y la base de datos permanece en línea, independientemente de la duración de la inactividad de la base de datos:

Se impide temporalmente la pausa automática durante la implementación de algunas actualizaciones de servicio, que requiere que la base de datos esté en línea. En tales casos, se vuelve a permitir la pausa automática una vez finalizada la actualización del servicio.

Solución de problemas de la pausa automática

Si la pausa automática está habilitada y no se utilizan las características que bloquean la pausa automática, pero una base de datos no se pausa automáticamente después del periodo de retraso, la aplicación o las sesiones de usuario pueden estar impidiendo esta característica.

Para ver si hay alguna aplicación o sesión de usuario conectada actualmente a la base de datos, conéctese a la base de datos mediante cualquier herramienta de cliente y ejecute la consulta siguiente:

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
          (
          wg.name like 'UserPrimaryGroup.DB%'
          AND
          TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
          )
      OR
      wg.name = 'DACGroup'
      );

Sugerencia

Después de ejecutar la consulta, asegúrese de desconectarse de la base de datos. De lo contrario, la sesión abierta usada por la consulta impedirá la pausa automática.

  • Si el conjunto de resultados no está vacío, significa que hay sesiones que impiden la pausa automática.
  • Si el conjunto de resultados está vacío, todavía es posible que las sesiones estuvieran abiertas, posiblemente durante un corto periodo de tiempo, en algún momento anterior durante el periodo de retraso de la pausa automática. Para comprobar si se ha producido actividad durante el periodo de retraso, puede usar Auditoría de Azure SQL y examinar los datos de auditoría del periodo pertinente.

Importante

La presencia de sesiones abiertas, con o sin uso simultáneo de CPU en el grupo de recursos de usuario, es la razón más común de que una base de datos sin servidor no se pause automáticamente según lo previsto.

Reanudación automática

La reanudación automática se desencadena si se cumple cualquiera de las siguientes condiciones en cualquier momento:

Característica Desencadenador de reanudación automática
Autenticación y autorización Inicio de sesión
Detección de amenazas Habilitación o deshabilitación de la configuración de detección de amenazas en el nivel de base de datos o servidor.
Modificación de la configuración de detección de amenazas en el nivel de base de datos o servidor.
Clasificación y detección de datos Adición, modificación, eliminación o visualización de las etiquetas de confidencialidad
Auditoría Visualización de registros de auditoría
Actualización o visualización de la directiva de auditoría.
Enmascaramiento de datos Adición, modificación, eliminación o visualización de reglas de enmascaramiento de datos
Cifrado de datos transparente Visualización del estado del cifrado de datos transparente
Evaluación de vulnerabilidades Exámenes ad hoc y exámenes periódicos si están habilitados
Almacén de datos de consulta (rendimiento) Modificación o visualización de la configuración del almacén de consulta
Recomendaciones de rendimiento Visualización o aplicación de recomendaciones de rendimiento
Ajuste automático Aplicación y comprobación de recomendaciones de ajuste automático, como la indexación automática
Copia de base de datos Creación de base de datos como copia.
Exportación a un archivo BACPAC.
Sincronización de datos SQL Sincronización entre la base de datos central y las bases de datos miembro que se ejecutan según una programación configurable o bien de forma manual
Modificación de algunos metadatos de base de datos Adición de nuevas etiquetas de base de datos.
Cambio del número máximo de núcleos virtuales, el número mínimo de núcleos virtuales y el retraso de la pausa automática.
SQL Server Management Studio (SSMS) Al usar las versiones de SSMS anteriores a 18.1 y abrir una nueva ventana de consulta para cualquier base de datos en el servidor, se reanudará cualquier base de datos en pausa automática en el mismo servidor. Este comportamiento no se produce si se usa SSMS versión 18.1 o posterior.
  • La supervisión, la administración u otras soluciones que realicen cualquiera de las operaciones indicadas anteriormente desencadenarán la reanudación automática.
  • También se desencadena la reanudación automática durante la implementación de algunas actualizaciones de servicio que requieren que la base de datos esté en línea.

Conectividad

Si una base de datos sin servidor está en pausa, cuando se produce la primera actividad de inicio de sesión, se reanuda la base de datos y se devuelve un error con el código 40613 que indica que la base de datos no está disponible. Una vez que se reanude la base de datos, se puede intentar iniciar sesión de nuevo para establecer la conectividad. No es necesario modificar los clientes de la base de datos con una lógica de reintento de conexión recomendada. Para conocer los patrones recomendados para la lógica de reintento de conexión, consulte:

Latencia

La latencia de la reanudación y la pausa automáticas de una base de datos sin servidor es, por lo general, de 1 minuto para la reanudación automática y de 1 a 10 minutos para la pausa automática.

Cifrado de datos transparente administrado por el cliente (BYOK)

Eliminación o revocación de claves

Si se usa el cifrado de datos transparente administrado por el cliente (BYOK) y la base de datos sin servidor se pausa automáticamente cuando se produce la eliminación o la revocación de claves, la base de datos permanece en estado de pausa automática. En este caso, después de que la base de datos se reanude la próxima vez, esta dejará de estar accesible en aproximadamente 10 minutos. Si la base de datos pasa a ser inaccesible, el proceso de recuperación es el mismo que para las bases de datos de proceso aprovisionadas. Si la base de datos sin servidor está en línea cuando se produce la eliminación o la revocación de claves, la base de datos también pasa a ser inaccesible en el plazo de unos 10 minutos, como sucede con las bases de datos de proceso aprovisionadas.

Rotación de claves

Si se usa el cifrado de datos transparente administrado por el cliente (BYOK) y la base de datos sin servidor se pausa automáticamente, la rotación automática de claves se aplaza hasta que la base de datos se reanude automáticamente.

Creación de una base de datos sin servidor nueva

La creación de una nueva base de datos o el cambio de una base de datos existente a un nivel de proceso sin servidor siguen el mismo patrón que la creación de una nueva base de datos en el nivel de proceso aprovisionado y constan de los dos pasos siguientes:

  1. Especifique el objetivo de servicio. El objetivo de servicio preceptúa el nivel de servicio, la configuración de hardware y el máximo de núcleos virtuales. Para ver las opciones de objetivo de servicio, consulte Límites de los recursos sin servidor

  2. Opcionalmente, especifique el número mínimo de núcleos virtuales y el retraso de la pausa automática para cambiar sus valores predeterminados. En la siguiente tabla se muestran los valores disponibles para estos parámetros.

    Parámetro Opciones de valores Valor predeterminado
    Mínimo de núcleos virtuales Depende de la cantidad máxima de núcleos virtuales configurada; consulte Límites de los recursos. 0,5 núcleos virtuales
    Retraso de pausa automática Mínimos: 60 minutos (1 hora)
    Máximo: 10 080 minutos (7 días)
    Incrementos: 10 minutos
    Deshabilitar la pausa automática: -1    		 60 minutos

En el siguiente ejemplo se crea una base de datos en el nivel de proceso sin servidor.

Usar Azure Portal

Consulte Quickstart: Creación de una base de datos única en Azure SQL Database con Azure Portal.

Uso de PowerShell

Cree una base de datos De uso general sin servidor nueva con el siguiente ejemplo de PowerShell:

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720

Uso de CLI de Azure

Cree una base de datos De uso general sin servidor con el siguiente ejemplo de la CLI de Azure:

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose --compute-model Serverless -f Gen5 `
  --min-capacity 0.5 -c 2 --auto-pause-delay 720

Uso de Transact-SQL (T-SQL)

Cuando se usa T-SQL para crear una base de datos sin servidor, se aplican valores predeterminados de núcleos virtuales mínimos y retraso de pausa automática. Más adelante se pueden cambiar desde Azure Portal o a través de otras API de administración (PowerShell, CLI de Azure, API de REST).

Para más información, consulte CREATE DATABASE.

Cree una base de datos sin servidor De uso general nueva con el siguiente ejemplo de T-SQL:

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

Movimiento de una base de datos entre niveles de proceso

Es posible mover la base de datos del nivel de proceso aprovisionado al nivel de proceso sin servidor, y viceversa.

Nota

También es posible actualizar la base de datos en el nivel De uso general al nivel Hiperescala. Consulte Administración de bases de datos de Hiperescala para obtener más información.

Al mover la base de datos entre niveles de proceso, proporcione el parámetro Modelo de proceso como Serverless o Provisioned cuando use PowerShell y la CLI de Azure, y el tamaño de proceso de la opción SERVICE_OBJECTIVE cuando use T-SQL. Consulte los límites de recursos para identificar el tamaño de proceso adecuado.

En los ejemplos de esta sección se muestra cómo mover la base de datos aprovisionada a sin servidor. Modifique el objetivo de servicio según sea necesario, ya que estos ejemplos establecen el número máximo de núcleos virtuales en 4.

Uso de PowerShell

Mueva una base de datos De uso general de proceso aprovisionada al nivel de proceso sin servidor con el siguiente ejemplo de PowerShell:

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440

Uso de CLI de Azure

Mueva una base de datos De uso general de proceso aprovisionada al nivel de proceso sin servidor con el siguiente ejemplo de la CLI de Azure:

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --compute-model Serverless --family Gen5 `
  --min-capacity 1 --capacity 4 --auto-pause-delay 1440

Uso de Transact-SQL (T-SQL)

Cuando se usa T-SQL para mover una base de datos entre niveles de proceso, se aplican valores predeterminados de núcleos virtuales mínimos y retraso de pausa automática. Más adelante se pueden cambiar desde Azure Portal o a través de otras API de administración (PowerShell, CLI de Azure, API de REST). Para más información, consulte ALTER DATABASE.

Mueva una base de datos De uso general de proceso aprovisionada al nivel de proceso sin servidor con el siguiente ejemplo de T-SQL:

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

Modificación de la configuración sin servidor

Uso de PowerShell

Use Set-AzSqlDatabase para modificar el número máximo o mínimo de núcleos virtuales y el retraso de la pausa automática. Use los argumentos MaxVcore, MinVcore y AutoPauseDelayInMinutes. La pausa automática sin servidor no se admite actualmente en el nivel Hiperescala, por lo que el argumento de demora de pausa automática solo se aplica al nivel De uso general.

Uso de CLI de Azure

Use az sql db update para modificar el número máximo o mínimo de núcleos virtuales y el retraso de la pausa automática. Use los argumentos capacity, min-capacity y auto-pause-delay. La pausa automática sin servidor no se admite actualmente en el nivel Hiperescala, por lo que el argumento de demora de pausa automática solo se aplica al nivel De uso general.

Monitor

Recursos utilizados y facturados

Los recursos de una base de datos sin servidor contienen el paquete de la aplicación, la instancia de SQL y las entidades de grupo de recursos del usuario.

Paquete de aplicaciones

El paquete de aplicaciones es el límite de administración de recursos más externo de una base de datos, independientemente de si la base de datos se encuentra en un nivel de proceso sin servidor o aprovisionado. El paquete de la aplicación contiene la instancia de SQL y servicios externos (como la búsqueda de texto completo) que, en conjunto, abarcan todos los recursos de usuario y del sistema que utiliza una base de datos en SQL Database. Generalmente, la instancia de SQL domina el uso de recursos global en el paquete de aplicaciones.

Grupo de recursos de usuario

El grupo de recursos de usuario es un límite interno de administración de recursos para una base de datos, independientemente de si la base de datos está en un nivel de proceso sin servidor o aprovisionado. El grupo de recursos de usuario abarca la CPU y la E/S de las cargas de trabajo de usuario generadas por consultas de DDL (CREATE y ALTER) y consultas DML (INSERT, UPDATE, DELETE y MERGE y SELECT). Por lo general, estas consultas representan la proporción de uso dentro del paquete de aplicaciones más importante.

Métricas

En la siguiente tabla se recogen las métricas para supervisar el uso de recursos del paquete de la aplicación y el grupo de recursos de usuario de una base de datos sin servidor, incluidas todas las réplicas geográficas:

Entity Métrica Descripción Unidades
Paquete de aplicaciones app_cpu_percent Porcentaje de núcleos virtuales utilizado por la aplicación respecto al máximo de núcleos virtuales permitido para la aplicación. Para Hiperescala sin servidor, esta métrica se expone para todas las réplicas principales, con nombre y geográficas. Porcentaje
Paquete de aplicaciones app_cpu_billed La cantidad de procesos que se facturan para la aplicación durante el período de informe. El importe pagado durante este período es el producto de esta métrica por el precio de la unidad de núcleo virtual.

Los valores de esta métrica se determinan al agregar el máximo de CPU utilizada y la memoria usada por segundo. Si la cantidad utilizada es menor que la cantidad mínima aprovisionada definida por el mínimo de núcleos virtuales y la memoria mínima, se factura la cantidad mínima aprovisionada. Para comparar la CPU y la memoria con fines de facturación, la memoria se normaliza en unidades de núcleos virtuales cambiando la escala de la cantidad de GB de memoria en 3 GB por núcleo virtual. Para Hiperescala sin servidor, esta métrica se expone para la réplica principal y cualquier réplica con nombre.		 Segundos de núcleo virtual
Paquete de aplicaciones app_cpu_billed_HA_replicas Solo se aplica a Hiperescala sin servidor. Suma del proceso facturado en todas las aplicaciones para las réplicas de alta disponibilidad durante el período de notificación. Esta suma tiene como ámbito las réplicas de alta disponibilidad que pertenecen a la réplica principal o las réplicas de alta disponibilidad que pertenecen a una réplica con nombre determinada. Antes de calcular esta suma entre réplicas de alta disponibilidad, se determina la cantidad de proceso facturada para una réplica de alta disponibilidad individual de la misma manera que para la réplica principal o una réplica con nombre. Para Hiperescala sin servidor, esta métrica se expone para todas las réplicas principales, con nombre y geográficas. El importe pagado durante el período de notificación es el producto de esta métrica por el precio de la unidad de núcleo virtual. Segundos de núcleo virtual
Paquete de aplicaciones app_memory_percent Porcentaje de memoria utilizada por la aplicación respecto a la memoria máxima permitida para la aplicación. Para Hiperescala sin servidor, esta métrica se expone para todas las réplicas principales, con nombre y geográficas. Porcentaje
Grupo de recursos de usuario cpu_percent Porcentaje de núcleos virtuales utilizado por la carga de trabajo de usuario respecto al máximo de núcleos virtuales permitido para la carga de trabajo de usuario. Porcentaje
Grupo de recursos de usuario data_IO_percent Porcentaje de IOPS de datos utilizado por la carga de trabajo de usuario respecto al máximo de IOPS de datos permitido para la carga de trabajo de usuario. Porcentaje
Grupo de recursos de usuario log_IO_percent Porcentaje de MB/s de registro utilizado por la carga de trabajo de usuario respecto al máximo de MB/s de registro permitido para la carga de trabajo de usuario. Porcentaje
Grupo de recursos de usuario workers_percent Porcentaje de trabajos utilizado por la carga de trabajo de usuario respecto al máximo de trabajos permitido para la carga de trabajo de usuario. Porcentaje
Grupo de recursos de usuario sessions_percent Porcentaje de sesiones utilizado por la carga de trabajo de usuario respecto al máximo de sesiones permitido para la carga de trabajo de usuario. Porcentaje

Estado de pausa y reanudación

En Azure Portal, se muestra el estado de la base de datos en el panel de información general del servidor que enumera las bases de datos que contiene. El estado de la base de datos también se muestra en el panel de información general de la base de datos.

Con los siguientes comandos para consultar el estado de pausa y reanudación de una base de datos:

Uso de PowerShell

Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

Uso de CLI de Azure

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

Límites de recursos

Para ver los límites de recursos, consulte Nivel de proceso sin servidor.

Facturación

La cantidad de proceso que se factura para una base de datos sin servidor es el máximo de CPU y memoria usado en cada segundo. Si la cantidad de CPU y memoria usadas es inferior a la cantidad mínima aprovisionada para cada recurso, se factura la cantidad aprovisionada. Para comparar la CPU y la memoria con fines de facturación, la memoria se normaliza en unidades de núcleos virtuales cambiando la escala del número de GB en 3 GB por núcleo virtual.

  • Recurso facturado: CPU y memoria
  • Importe facturado: precio de la unidad de núcleo virtual * máximo (mínimo de núcleos virtuales, núcleos virtuales usados, GB de memoria mínima * 1/3, GB de memoria usada * 1/3)
  • Frecuencia de facturación: Por segundo

El precio de unidad de núcleo virtual es el costo por núcleo virtual por segundo. Para Hiperescala, el precio de la unidad de núcleo virtual para una réplica de alta disponibilidad o réplica con nombre es inferior al de la réplica principal.

Consulte la página de precios de Azure SQL Database para conocer los precios de unidad específicos de una región determinada.

La cantidad de proceso facturada si no hay servidor para una base de datos De uso general o una réplica principal o con nombre de Hiperescala se expone mediante la métrica siguiente:

  • Métrica: app_cpu_billed (segundos de núcleo virtual)
  • Definición: máximo (mínimo de núcleos virtuales, núcleos virtuales usados, GB de memoria mínima * 1/3, GB de memoria usada * 1/3)
  • Frecuencia de informes: por minuto en función de las medidas por segundo agregadas en un intervalo de 1 minuto.

La cantidad de proceso facturada si no hay servidor para las réplicas de alta disponibilidad de Hiperescala que pertenecen a la réplica principal o cualquier réplica con nombre se expone mediante la métrica siguiente:

  • Métrica: app_cpu_billed_HA_replicas (segundos de núcleo virtual)
  • Definición: suma del número máximo (número mínimo de núcleos virtuales, núcleos virtuales usados, GB de memoria mínima * 1/3, GB de memoria usada * 1/3) para cualquier réplica de alta disponibilidad que pertenezca a su recurso principal.
  • Punto de conexión de métrica y recurso principal: la réplica principal y cualquier réplica con nombre exponen cada una por separado esta métrica que mide el proceso facturado para cualquier réplica de alta disponibilidad asociada.
  • Frecuencia de informes: por minuto en función de las medidas por segundo agregadas en un intervalo de 1 minuto.

Factura de proceso mínimo

Si una base de datos sin servidor está en pausa, la factura de proceso es cero. Si una base de datos sin servidor no está en pausa, la factura de proceso mínimo no es inferior a la cantidad de núcleos virtuales basada en el número máximo (número mínimo de núcleos virtuales, GB de memoria mínima * 1/3).

Ejemplos:

  • Supongamos que una base de datos sin servidor en el nivel De uso general no está en pausa y está configurada con 8 núcleos virtuales como máximo y 1 núcleo virtual como mínimo, lo que corresponde a 3,0 GB de memoria mínima. La factura de proceso mínimo se basa entonces en el número máximo (1 núcleo virtual, 3,0 GB * 1 núcleo virtual/3 GB) = 1 núcleo virtual.
  • Supongamos que una base de datos sin servidor en el nivel De uso general no está en pausa y está configurada con 4 núcleos virtuales como máximo y 0,5 núcleos virtuales como mínimo, lo que corresponde a 2,1 GB de memoria mínima. La factura de proceso mínimo se basa entonces en el número máximo (0,5 núcleos virtuales, 2,1 GB * 1 núcleo virtual/3 GB) = 0,7 núcleos virtuales.
  • Supongamos que una base de datos sin servidor en el nivel Hiperescala tiene una réplica principal con una réplica de alta disponibilidad y una réplica con nombre sin réplicas de alta disponibilidad. Supongamos que cada réplica está configurada con 8 núcleos virtuales como máximo y 1 núcleo virtual como mínimo, lo que corresponde a 3 GB de memoria mínima. A continuación, la factura de proceso mínima para la réplica principal, la réplica de alta disponibilidad y la réplica con nombre se basan cada una en el número máximo (1 núcleo virtual, 3 GB * 1 núcleo virtual / 3 GB) = 1 núcleo virtual.

La calculadora de precios de Azure SQL Database para escenarios sin servidor se puede usar para determinar la cantidad mínima de memoria configurable en función del número de núcleos virtuales máximos y mínimos configurados. Por norma general, si el número mínimo de núcleos virtuales configurado es superior a 0,5 núcleos virtuales, la factura de proceso mínimo es independiente de la memoria mínima configurada y solo se basa en el número mínimo de núcleos virtuales configurado.

Ejemplos de escenarios

Considere la posibilidad de una base de datos sin servidor en el nivel De uso general configurada con 1 núcleo virtual como mínimo y 4 como máximo. Esta configuración equivale aproximadamente a 3 GB de memoria como mínimo y a 12 GB de memoria como máximo. Supongamos que la demora de la pausa automática se establece en 6 horas y la carga de trabajo de la base de datos está activa durante las primeras 2 horas de un período de 24 horas e inactiva el resto del tiempo.

En este caso, la base de datos se facturará por proceso y almacenamiento durante las primeras 8 horas. Aunque la base de datos está inactiva después de la segunda hora, se le seguirá facturando por el proceso de las 6 horas siguientes en función del proceso mínimo aprovisionado mientras la base de datos está en línea. Solo se facturará por el almacenamiento el resto del período de 24 horas mientras la base de datos está en pausa.

Más concretamente, la facturación del proceso en este ejemplo se calcula como sigue:

Intervalo de tiempo Núcleos virtuales que se usan cada segundo GB que se usan cada segundo Dimensión del proceso facturado Segundos de núcleo virtual facturados a lo largo de un intervalo de tiempo
0:00-1:00 4 9 Núcleos virtuales usados 4 núcleos virtuales * 3600 segundos = 14 400 segundos de núcleo virtual
1:00-2:00 1 12 Memoria usada 12 GB * 1/3 * 3600 segundos = 14 400 segundos de núcleo virtual
2:00-8:00 0 0 Memoria mínima aprovisionada 3 GB * 1/3 * 21 600 segundos = 21 600 segundos de núcleo virtual
8:00-24:00 0 0 No se factura ningún proceso mientras la base de datos está en pausa 0 segundos de núcleo virtual
Número total de segundos de núcleo virtual facturados durante 24 horas 50 400 segundos de núcleo virtual

Suponga que el precio de la unidad de proceso es 0,000145 $/núcleo virtual/segundo. El proceso que se factura en este período de 24 horas es igual al producto del precio por unidad de proceso por los segundos de núcleo virtual facturados: 0,000145 USD/núcleo virtual/segundo * 50400 segundos de núcleo virtual = aproximadamente 7,31 USD.

Ventaja híbrida de Azure y capacidad reservada

Los descuentos de Ventaja híbrida de Azure (AHB) y capacidad reservada no se aplican al nivel de proceso sin servidor.

Regiones disponibles

Instancias sin servidor de los niveles Uso general e Hiperescala, con compatibilidad de hasta un máximo de 40 núcleos virtuales, está disponible en todo el mundo, excepto en las siguientes regiones:

  • Este de China
  • Norte de China
  • Centro de Alemania
  • Nordeste de Alemania
  • US Gov Central (Iowa)

Regiones que admiten un máximo de 80 núcleos virtuales sin zonas de disponibilidad para Hiperescala y Uso general

Actualmente, se admite un máximo de 80 núcleos virtuales en instancias sin servidor de los niveles Hiperescala y Uso general en las siguientes regiones:

  • Este de Australia
  • Sudeste de Australia
  • Sur de Brasil
  • Centro de Canadá
  • Centro de EE. UU.
  • Este de Asia
  • Este de EE. UU.
  • Este de EE. UU. 2
  • Centro de Francia
  • Sur de Francia
  • Centro-oeste de Alemania
  • India central
  • Sur de India
  • Japón Oriental
  • Japón Occidental
  • Centro-Norte de EE. UU
  • Norte de Europa
  • Este de Noruega
  • Centro de Catar
  • Norte de Sudáfrica
  • Centro-sur de EE. UU.
  • Norte de Suiza
  • Sur de Reino Unido 2
  • Oeste de Reino Unido
  • Oeste de Europa
  • Centro-Oeste de EE. UU.
  • Oeste de EE. UU.
  • Oeste de EE. UU. 2
  • Oeste de EE. UU. 3

Regiones que admiten un máximo de 80 núcleos virtuales con zonas de disponibilidad para Uso general

Actualmente, se proporciona un máximo de 80 núcleos virtuales en compatibilidad con zonas de disponibilidad sin servidor para el nivel Uso general en las siguientes regiones, con más regiones planeadas:

  • Este de EE. UU.
  • Norte de Europa
  • Oeste de Europa
  • Oeste de EE. UU. 2

Regiones que admiten un máximo de 80 núcleos virtuales con zonas de disponibilidad para Hiperescala

Actualmente, se proporciona un máximo de 80 núcleos virtuales en compatibilidad con zonas de disponibilidad sin servidor para el nivel Hiperescala en las siguientes regiones, con más regiones planeadas:

  • Centro de EE. UU.
  • Este de EE. UU.
  • Norte de Europa
  • Oeste de Europa
  • Oeste de EE. UU. 2
  • Oeste de EE. UU. 3

Contenido relacionado