Introducción al modelo de compra basado en DTU
Se aplica a: 
Azure SQL Database
En este artículo, obtendrá información general sobre el modelo de compra basado en DTU para Azure SQL Database. El modelo de compra basado en DTU es una medida sencilla y agrupada de recursos de proceso, almacenamiento y E/S. Es más adecuado para la mayoría de los clientes con cargas de trabajo típicas. Los niveles de servicio Básico, Estándar y Premium están disponibles en el modelo de compra basado en DTU. El modelo de compra basado en DTU también está disponible para grupos elásticos.
El modelo de compra basado en DTU es diferente al modelo de compra basado en núcleo virtual, por lo que puede comparar los modelos de compra.
Unidades de transacción de base de datos (DTU)
Una unidad de transacción de base de datos (DTU) representa una medida combinada de CPU, memoria, lecturas y escrituras. Los niveles de servicio en el modelo de compra basado en DTU se diferencian por una variedad de tamaños de proceso con una cantidad fija de almacenamiento incluido, un período de retención fijo para copias de seguridad y un precio fijo. Todos los niveles de servicio del modelo de compra basado en DTU proporcionan flexibilidad de cambiar los tamaños de proceso con el mínimo tiempo de inactividad; sin embargo, hay un breve período de cambio en el que se pierde la conectividad a la base de datos, lo que se puede mitigar con la lógica de reintento. Las bases de datos únicas y los grupos elásticos se facturan por horas en función del nivel de servicio y el tamaño de proceso.
Para una base de datos única en un tamaño de proceso específico dentro de un nivel de servicio, Azure SQL Database garantiza determinado nivel de recursos para esa base de datos (independiente de cualquier otra base de datos). Esta garantía ofrece un nivel de rendimiento predecible. La cantidad de recursos asignada a una base de datos se calcula como un número de DTU y es una medida combinada de recursos de proceso, almacenamiento y E/S.
La relación entre estos recursos se determina originalmente mediante una carga de trabajo de prueba comparativa de procesamiento de transacciones en línea (OLTP) diseñada para representar las típicas cargas de trabajo OLTP reales. Cuando la carga de trabajo supera la cantidad de cualquiera de estos recursos, se limita el rendimiento, con lo que se obtiene un rendimiento y tiempos de espera más lentos.
En el caso de las bases de datos únicas, los recursos utilizados por la carga de trabajo no afectan a los recursos disponibles para otras bases de datos en la nube de Azure. Del mismo modo, los recursos utilizados por otras cargas de trabajo no afectan a los recursos disponibles para su base de datos.
Las DTU son especialmente útiles para comprender los recursos relativos que están asignados a las bases de datos en los diferentes tamaños de proceso y niveles de servicio. Por ejemplo:
- Duplicar el número de DTU al aumentar el tamaño de proceso de una base de datos equivale a duplicar el conjunto de recursos disponibles para esa base de datos.
- Una base de datos P11 de nivel de servicio Premium con 1750 DTU proporciona una potencia de proceso de DTU 350 veces mayor que una base de datos de nivel de servicio Básico con 5 DTU.
Para más información sobre el consumo de recursos (DTU) de la carga de trabajo, use la información de rendimiento de consultas para:
- Identificar las consultas principales por CPU, duración y recuento de ejecuciones, que se pueden ajustar para mejorar el rendimiento. Por ejemplo, una consulta que realiza muchas operaciones de E/S puede beneficiarse de las técnicas de optimización en memoria para hacer un mejor uso de la memoria disponible en determinado nivel de servicio y tamaño de proceso.
- Explorar en profundidad los detalles de una consulta, ver su texto e historial de uso de recursos.
- Vea las recomendaciones de ajuste del rendimiento que muestran las acciones realizadas por Database Advisor.
Unidades de transacción de base de datos elástica (eDTU)
En lugar de proporcionar un conjunto dedicado de recursos (DTU) que no siempre se puede necesitar, puede colocar estas bases de datos en un grupo elástico. Las bases de datos de un grupo elástico usan una única instancia del motor de base de datos y comparten el mismo grupo de recursos.
Los recursos compartidos de un grupo elástico se miden mediante unidades de transacción de base de dato elástica (eDTU). Los grupos elásticos proporcionan una solución sencilla y rentable para administrar los objetivos de rendimiento de varias bases de datos que tienen patrones de uso muy diferentes e imprevisibles. Un grupo elástico garantiza que una única base de datos del grupo no pueda consumir todos los recursos, mientras que asegura que cada base de datos del grupo tenga disponible siempre una cantidad mínima de recursos necesarios.
A un grupo se le asigna un número fijo de eDTU, por un precio fijo. En el grupo elástico, las bases de datos individuales se pueden escalar automáticamente dentro de los límites configurados. Una base de datos con cargas más elevadas consume más eDTU para satisfacer la demanda. Las bases de datos con cargas más bajas consumen menos eDTU. Las bases de datos sin cargas no consumen ningún eDTU. Como los recursos se aprovisionan para todo el grupo, en lugar de por base de datos, los grupos elásticos simplifican las tareas de administración, y proporcionan un presupuesto predecible para el grupo.
Puede agregar más eDTU a un grupo existente con un tiempo de inactividad mínimo de la base de datos. De forma similar, si ya no necesita eDTU adicionales, puede quitarlas de un grupo existente en cualquier momento. También puede agregar o quitar bases de datos de un grupo en cualquier momento. Para reservar eDTU para otras bases de datos, limite el número de eDTU que pueden usar las bases de datos con una carga elevada. Si una base de datos tiene una utilización alta de recursos de manera uniforme que afecta a otras bases de datos del grupo, muévela fuera del grupo y configúrela como una base de datos única con una cantidad predecible de recursos necesarios.
Cargas de trabajo que se benefician de un grupo elástico de recursos
Los grupos son adecuados para las bases de datos con un promedio de uso de recursos bajo y picos de uso relativamente poco frecuentes. Para obtener más información, consulte Grupos elásticos en Azure SQL Database.
Determinar el número de DTU necesarias para la carga de trabajo
Si desea migrar una carga de trabajo local existente o de máquina virtual con SQL Server a SQL Database, consulte las recomendaciones de SKU para hacer una estimación del número aproximado de DTU que se necesitan. Para las cargas de trabajo existentes de SQL Database, use la información de rendimiento de consultas para comprender el consumo de recursos de base de datos (DTU) y obtener información más detallada para optimizar la carga de trabajo. La vista de administración dinámica (DMV) sys.dm_db_resource_stats permite ver el consumo de recursos de la última hora. La vista de catálogo sys.resource_stats muestra el consumo de recursos de los últimos 14 días, aunque con una fidelidad inferior media de cinco minutos.
Determinación del uso de DTU
Para determinar el porcentaje medio de uso de DTU/eDTU, en relación con el límite de DTU/eDTU de una base de datos o un grupo de bases de datos elásticas, utilice esta fórmula:
avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)
Los valores de entrada de esta fórmula se pueden obtener de los DMV sys.dm_db_resource_stats, sys.resource_stats y sys.elastic_pool_resource_stats. En otras palabras, para determinar el porcentaje de uso de DTU/eDTU con respecto al límite de DTU/eDTU de una base de datos o un grupo de bases de datos elásticas, elija el valor porcentual mayor de los siguientes: avg_cpu_percent, avg_data_io_percent y avg_log_write_percent en un momento puntual.
Nota:
El límite de DTU de una base de datos lo determinan la CPU, las operaciones de lectura, las operaciones de escritura y la memoria disponible para la base de datos. Sin embargo, dado que el motor de SQL Database normalmente utiliza toda la memoria disponible para su caché de datos a fin de mejorar el rendimiento, el valor de avg_memory_usage_percent normalmente estará cerca del 100 %, independientemente de la carga actual de la base de datos. Por consiguiente, aunque la memoria realmente influye de manera indirecta en el límite de DTU, no se utiliza en la fórmula de uso de DTU.
Configuración de hardware
En el modelo de compra basado en DTU, los clientes no pueden elegir la configuración de hardware que se usa en sus bases de datos. Aunque las bases de datos suelen permanecer en un tipo específico de hardware durante mucho tiempo (normalmente durante varios meses), hay ciertos casos en los que se pueden mover a otro hardware.
Por ejemplo, una base de datos se puede mover a otro hardware si se escala vertical u horizontalmente a un objetivo de servicio diferente, si la infraestructura actual de un centro de datos se aproxima a sus límites de capacidad o si el hardware utilizado actualmente se va a retirar porque ha finalizado su vida útil.
Si se mueve una base de datos a un hardware diferente, el rendimiento de la carga de trabajo puede cambiar. El modelo de DTU garantiza que el rendimiento y el tiempo de respuesta de la carga de trabajo de la prueba comparativa de DTU sigan siendo prácticamente idénticos cuando la base de datos se mueve a un tipo de hardware diferente, siempre y cuando su objetivo de servicio (el número de DTU) permanezca igual.
Sin embargo, en el amplio espectro de cargas de trabajo de clientes que se ejecutan en Azure SQL Database, el efecto de usar hardware diferente para el mismo objetivo de servicio puede ser más pronunciado. Algunas cargas de trabajo pueden beneficiarse de ciertas características y configuraciones de hardware. Por lo tanto, es posible que en cargas de trabajo distintas de las de la prueba comparativa de DTU se aprecien diferencias en el rendimiento si la base de datos se mueve de un tipo de hardware a otro.
Los clientes pueden usar el modelo de núcleo virtual para elegir su configuración de hardware preferida durante la creación y el escalado de la base de datos. En el modelo de núcleo virtual, se documentan detalladamente los límites de recursos de cada objetivo de servicio en cada configuración de hardware. Esto incluye tanto a las bases de datos únicas como a los grupos elásticos. Para más información, vea Configuración de hardware.
Comparación de niveles de servicio
Nota:
Puede obtener una base de datos gratuita de Azure SQL Database en el nivel de servicio Básico con una cuenta gratuita de Azure. Para obtener información, consulte Cree una base de datos administrada en la nube con su cuenta gratuita de Azure.
La selección de un nivel de servicio depende sobre todo de los requisitos de continuidad del negocio, de almacenamiento y de rendimiento.
| Básico | Estándar | Premium | |
|---|---|---|---|
| Carga de trabajo de destino | Desarrollo y producción | Desarrollo y producción | Desarrollo y producción |
| SLA de tiempo de actividad | 99,99% | 99,99% | 99,99% |
| Backup | Una opción de almacenamiento de copia de seguridad con redundancia geográfica, con redundancia de zona o con redundancia local, retención de 1 a 7 días (valor predeterminado de 7 días). Retención a largo plazo disponible hasta un máximo de 10 años |
Una opción de almacenamiento de copia de seguridad con redundancia geográfica, con redundancia de zona o con redundancia local, retención de 1 a 35 días (valor predeterminado de 7 días) Retención a largo plazo disponible hasta un máximo de 10 años |
Una opción de almacenamiento con redundancia local (LRS), almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia geográfica (GRS) Retención de 1 a 35 días (7 días de manera predeterminada), con hasta 10 años de retención a largo plazo disponible |
| CPU | Bajo | Bajo, medio, alto | Medio, alto |
| IOPS (aproximado) 1 | 1-4 IOPS por DTU | 1-4 IOPS por DTU | >25 IOPS por DTU |
| Latencia de E/S (aproximada) | 5 ms (lectura), 10 ms (escritura) | 5 ms (lectura), 10 ms (escritura) | 2 ms (lectura/escritura) |
| Índice de almacén de columnas 2 | N/D | Estándar S3 y versiones posteriores | Compatible |
| OLTP en memoria | N/D | N/D | Compatible |
1 Todas las IOPS de lectura y escritura en archivos de datos, incluida la E/S en segundo plano (punto de comprobación y escritura diferida).
2 Para obtener más información, consulte Cambio de los niveles de servicio de las bases de datos que contienen índices de almacén de columnas.
Importante
Los objetivos del servicio Basic, S0, S1 y S2 proporcionan menos de un núcleo virtual (CPU). En el caso de las cargas de trabajo con un uso intensivo de CPU, se recomienda tener un objetivo de servicio S3 o superior.
En los objetivos de servicio de tipo Basic, S0 y S1, los archivos de base de datos se almacenan en Azure Standard Storage, que usa medios de almacenamiento basados en unidades de disco duro (HDD). Estos objetivos de servicio son más adecuados para el desarrollo, las pruebas y otras cargas de trabajo de acceso poco frecuente que no dan tanta importancia a la variabilidad del rendimiento.
Sugerencia
Para ver los límites reales de la gobernanza de recursos de una base de datos o un grupo elástico, consulte la vista sys.dm_user_db_resource_governance. Para una base de datos única, se devuelve una fila. Para una base de datos de un grupo elástico, se devuelve una fila para cada base de datos del grupo.
Límites de recursos
Los límites de recursos son diferentes para bases de datos únicas y agrupadas.
Límites de almacenamiento de las bases de datos únicas
En Azure SQL Database, los tamaños de proceso se expresan como unidades de transacción de base de datos (DTU) para las bases de datos únicas y como unidades de transacción de base de datos elásticas (eDTU) para los grupos elásticos. Para más información, consulte Límites de recursos de bases de datos únicas que usan el modelo de compra de DTU: Azure SQL Database.
| Básico | Estándar | Premium | |
|---|---|---|---|
| Tamaño máximo de almacenamiento | 2 GB | 1 TB | 4 TB |
| Cantidad máxima de DTU | 5 | 3000 | 4000 |
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 para bases de datos en Azure SQL Database.
Límites de los grupo elásticos
Para obtener más información, consulte Límites de recursos para grupos elásticos que utilizan el modelo de compra de DTU.
| Basic | Estándar | Premium | |
|---|---|---|---|
| Tamaño máximo de almacenamiento por base de datos | 2 GB | 1 TB | 1 TB |
| Tamaño máximo de almacenamiento por grupo | 156 GB | 4 TB | 4 TB |
| Cantidad máxima de eDTU por base de datos | 5 | 3000 | 4000 |
| Cantidad máxima de eDTU por grupo | 1600 | 3000 | 4000 |
| Cantidad máxima de bases de datos por grupo | 500 | 500 | 100 |
Importante
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. Para más información, consulte las limitaciones actuales de P11 y P15.
Importante
En algunas circunstancias, puede que deba reducir una base de datos para reclamar el espacio no utilizado. Para más información, consulte Administración del espacio de archivo en Azure SQL Database.
Prueba comparativa de DTU
Las características físicas (CPU, memoria, E/S) asociadas a cada medida de DTU se calibran con un punto de referencia que simula la carga de trabajo de base de datos real.
Consulte el siguiente artículo para obtener más información sobre el esquema, los tipos de transacción usados, la combinación de cargas de trabajo, los usuarios y el ritmo, las reglas de escalado y las métricas asociadas con el prueba comparativa de DTU.
Comparación de los modelos de compra basados en DTU y núcleos virtuales
El modelo de compra basado en DTU se basa en una medida agrupada de recursos de proceso, almacenamiento y E/S, mientras que el modelo de compra de núcleo virtual para Azure SQL Database permite elegir y escalar los recursos de proceso y almacenamiento de forma independiente.
El modelo de compra basado en núcleo virtual también permite usar la Ventaja híbrida de Azure para reducir los costes de SQL Server. Además, ofrece opciones de nivel de proceso sin servidor para Azure SQL Database y de hiperescala para Azure SQL Database no disponibles en el modelo de compra basado en DTU.
Para obtener más información, consulte en el artículo Comparación de los modelos de compra basados en núcleos virtuales y DTU de Azure SQL Database.