Compartir a través de

Diagnóstico y solución de problemas elevados de CPU en Azure SQL Database y Base de datos SQL de Microsoft Fabric

  • Artículo

Se aplica a: Azure SQL Database Base de datos SQL en Fabric

Azure SQL Database y Base de datos SQL en Fabric proporcionan herramientas integradas para determinar las causas del uso elevado de la CPU y para optimizar el rendimiento de la carga de trabajo. Puede usar estas herramientas para solucionar problemas de uso elevado de la CPU mientras se produce, o reactivamente después de que el incidente haya tenido lugar. También puede habilitar el ajuste automático para reducir de forma proactiva el uso de la CPU a lo largo del tiempo para la base de datos. Este artículo le enseña a diagnosticar y solucionar problemas de uso elevado de la CPU con herramientas integradas en Azure SQL Database y explica cuándo agregar recursos de CPU.

Comprensión del número de núcleos virtuales

Es útil comprender el número de núcleos virtuales disponibles para la base de datos al diagnosticar un incidente de uso elevado de la CPU. Un núcleo virtual equivale a una CPU lógica. El número de núcleos virtuales le ayuda a comprender los recursos de CPU disponibles para la base de datos.

Identificación del número de núcleos virtuales en Azure Portal

Puede identificar rápidamente el número de núcleos virtuales para una base de datos en Azure Portal si usa un nivel de servicio basado en núcleos virtuales con el nivel de cálculo aprovisionado. En este caso, el plan de tarifa que aparece para la base de datos en su página de información general contendrá el número de núcleos virtuales. Por ejemplo, el plan de tarifa de una base de datos puede ser "Propósito general: Sin servidor, Serie estándar (Gen5), 16 núcleos virtuales".

Para las bases de datos del nivel de proceso sin servidor, el número de núcleos virtuales siempre será equivalente a la configuración máxima de núcleos virtuales de la base de datos. El número de núcleos virtuales aparecerá en el plan de tarifa indicado para la base de datos en su página de información general. Por ejemplo, el plan de tarifa de una base de datos puede ser "Propósito general: Sin servidor, serie estándar (Gen5), 16 núcleos virtuales".

Si usa una base de datos en el modelo de compra basado en DTU, deberá usar Transact-SQL para consultar el número de núcleos virtuales de la base de datos.

Identificación del número de núcleos virtuales con Transact-SQL

Puede identificar el número de núcleos virtuales actual para cualquier base de datos con Transact-SQL. Puede ejecutar Transact-SQL en Azure SQL Database con SQL Server Management Studio (SSMS), Azure Data Studio o el editor de consultas de Azure Portal.

Conéctese a la base de datos y ejecute la consulta siguiente:

SELECT 
    COUNT(*) as vCores
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE';
GO

Identificación de las causas del uso elevado de la CPU

Puede medir y analizar el uso de la CPU con Azure Portal, herramientas interactivas del Almacén de consultas en SSMS y consultas de Transact-SQL en SSMS y Azure Data Studio.

Azure Portal y el Almacén de consultas muestran estadísticas de ejecución, como métricas de CPU, para las consultas completadas. Si está experimentando un incidente actual de uso elevado de la CPU que puede deberse a una o más consultas en curso de ejecución prolongada, identifique las consultas que se están ejecutando actualmente con Transact-SQL.

Las causas comunes de un uso elevado de la CPU nuevo e inusual son:

  • Nuevas consultas en la carga de trabajo que usan una gran cantidad de CPU.
  • Un aumento de la frecuencia de las consultas que se ejecutan periódicamente.
  • Regresión del plan de consulta, incluida la regresión debido a problemas del plan de distinción de parámetros (PSP), que provoca que una o más consultas consuman más CPU.
  • Un aumento significativo en la compilación o recompilación de planes de consulta.
  • Bases de datos en las que las consultas usan paralelismo excesivo.

Para comprender qué es lo que causa el incidente de uso elevado de la CPU, identifique cuándo se está produciendo un uso elevado de la CPU en la base de datos y las consultas que usan más la CPU en ese momento.

Examine:

Nota:

Azure SQL Database requiere recursos de proceso para implementar las características principales del servicio, como la alta disponibilidad y la recuperación ante desastres, la copia de seguridad y la restauración de bases de datos, la supervisión, el Almacén de consultas, el ajuste automático, etc. El uso de estos recursos de proceso puede ser particularmente notable en bases de datos con pocos núcleos virtuales o bases de datos en densos grupos elásticos. Obtenga más información en Administración de recursos en Azure SQL Database.

Use Azure Portal para realizar un seguimiento de varias métricas de CPU, incluido el porcentaje de CPU disponible que usa la base de datos a lo largo del tiempo. Azure Portal combina métricas de CPU con información del Almacén de consultas de la base de datos, lo que le permite identificar qué consultas consumieron CPU en la base de datos en un momento determinado.

Siga estos pasos para buscar métricas de porcentaje de CPU.

  1. Vaya a la base de datos en Azure Portal.
  2. En Rendimiento inteligente, en el menú de la izquierda, seleccione Información de rendimiento de consultas.

La vista predeterminada de Información de rendimiento de consultas muestra 24 horas de datos. El uso de la CPU se muestra como un porcentaje del total de CPU disponible que se usa para la base de datos.

Las cinco consultas principales que se ejecutan en ese período se muestran en barras verticales encima del gráfico de uso de CPU. Seleccione una banda de tiempo en el gráfico o use el menú Personalizar para explorar períodos de tiempo específicos. También puede aumentar el número de consultas que se muestran.

La captura de pantalla muestra Información de rendimiento de consultas en Azure Portal.

Seleccione cada identificador de consulta que muestra un uso elevado de CPU para abrir los detalles de la consulta. Los detalles incluyen el texto de la consulta junto con su historial de rendimiento. Examine si la CPU ha aumentado para la consulta recientemente.

Tome nota del identificador de la consulta para investigar más a fondo el plan de consulta utilizando el Almacén de consultas en la siguiente sección.

Revise los planes de consulta para las principales consultas identificadas en Azure Portal.

Siga estos pasos para usar un identificador de consulta en las herramientas interactivas del Almacén de consultas de SSMS para examinar el plan de ejecución de la consulta a lo largo del tiempo.

  1. Abra SSMS.
  2. Conéctese a Azure SQL Database en el Explorador de objetos.
  3. Expanda el nodo de bases de datos en el Explorador de objetos.
  4. Expanda la carpeta Almacén de consultas.
  5. Abra el panel Consultas con seguimiento.
  6. Escriba el identificador de consulta en el cuadro Consulta de seguimiento en la parte superior izquierda de la pantalla y presione Entrar.
  7. Si es necesario, seleccione Configurar para ajustar el intervalo de tiempo para que coincida con la hora en la que se estaba produciendo un uso elevado de la CPU.

La página mostrará los planes de ejecución y las métricas relacionadas de la consulta durante las últimas 24 horas.

Identifique las consultas que se están ejecutando actualmente con Transact-SQL

Transact-SQL permite identificar las consultas que se están ejecutando actualmente con el tiempo de CPU que han usado hasta el momento. También puede usar Transact-SQL para consultar el uso reciente de la CPU en la base de datos, las consultas principales por CPU y las consultas que compilaban con más frecuencia.

Puede consultar las métricas de la CPU con SQL Server Management Studio (SSMS), Azure Data Studio o el editor de consultas de Azure Portal. Al usar SSMS o Azure Data Studio, abra una nueva ventana de consulta y conéctela a la base de datos (no a la base de datos master).

Busque las consultas que se están ejecutando actualmente con el uso de la CPU y los planes de ejecución ejecutando la siguiente consulta. El tiempo de CPU se devuelve en milisegundos.

SELECT
    req.session_id,
    req.status,
    req.start_time,
    req.cpu_time AS 'cpu_time_ms',
    req.logical_reads,
    req.dop,
    s.login_name,
    s.host_name,
    s.program_name,
    object_name(st.objectid,st.dbid) 'ObjectName',
    REPLACE (REPLACE (SUBSTRING (st.text,(req.statement_start_offset/2) + 1,
        ((CASE req.statement_end_offset    WHEN -1    THEN DATALENGTH(st.text) 
        ELSE req.statement_end_offset END - req.statement_start_offset)/2) + 1),
        CHAR(10), ' '), CHAR(13), ' ') AS statement_text,
    qp.query_plan,
    qsx.query_plan as query_plan_with_in_flight_statistics
FROM sys.dm_exec_requests as req  
JOIN sys.dm_exec_sessions as s on req.session_id=s.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as st
OUTER APPLY sys.dm_exec_query_plan(req.plan_handle) as qp
OUTER APPLY sys.dm_exec_query_statistics_xml(req.session_id) as qsx
ORDER BY req.cpu_time desc;
GO

Esta consulta devuelve dos copias del plan de ejecución. La columna query_plan contiene el plan de ejecución de sys.dm_exec_query_plan. Esta versión del plan de consulta contiene solo estimaciones de recuentos de filas y no contiene ninguna estadística de ejecución.

Si la columna query_plan_with_in_flight_statistics devuelve un plan de ejecución, este plan proporciona más información. La columna query_plan_with_in_flight_statistics devuelve datos de sys.dm_exec_query_statistics_xml, que incluye estadísticas de ejecución "en proceso", como el número real de filas devueltas hasta ahora por una consulta en ejecución.

Revisión de las métricas de uso de la CPU durante la última hora

La consulta siguiente en sys.dm_db_resource_stats devuelve el uso medio de la CPU en intervalos de 15 segundos durante aproximadamente la última hora.

SELECT
    end_time,
    avg_cpu_percent,
    avg_instance_cpu_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC; 
GO

Es importante no centrarse solo en la columna avg_cpu_percent. La columna avg_instance_cpu_percent incluye la CPU utilizada tanto por el usuario como por las cargas de trabajo internas. Si avg_instance_cpu_percent se acerca al 100 %, los recursos de la CPU están saturados. En este caso, debe solucionar problemas de CPU elevada si el rendimiento de la aplicación es insuficiente o si la latencia de la consulta es alta.

Obtenga más información en Administración de recursos en Azure SQL Database.

Para otras consultas, consulte los ejemplos de sys.dm_db_resource_stats.

Consulta de las 15 consultas más recientes por uso de la CPU

El Almacén de consultas realiza un seguimiento de las estadísticas de ejecución, incluido el uso de la CPU, para las consultas. La consulta siguiente devuelve las 15 consultas principales que se han ejecutado en las últimas 2 horas, ordenadas por el uso de la CPU. El tiempo de CPU se devuelve en milisegundos.

WITH AggregatedCPU AS 
    (SELECT
        q.query_hash, 
        SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_ms, 
        SUM(count_executions * avg_cpu_time / 1000.0)/ SUM(count_executions) AS avg_cpu_ms, 
        MAX(rs.max_cpu_time / 1000.00) AS max_cpu_ms, 
        MAX(max_logical_io_reads) max_logical_reads, 
        COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans, 
        COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids, 
        SUM(CASE WHEN rs.execution_type_desc='Aborted' THEN count_executions ELSE 0 END) AS aborted_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Regular' THEN count_executions ELSE 0 END) AS regular_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Exception' THEN count_executions ELSE 0 END) AS exception_execution_count, 
        SUM(count_executions) AS total_executions, 
        MIN(qt.query_sql_text) AS sampled_query_text
    FROM sys.query_store_query_text AS qt
    JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
    JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id
    JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=rs.runtime_stats_interval_id
    WHERE 
            rs.execution_type_desc IN ('Regular', 'Aborted', 'Exception') AND 
        rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
     GROUP BY q.query_hash), 
OrderedCPU AS 
    (SELECT *, 
    ROW_NUMBER() OVER (ORDER BY total_cpu_ms DESC, query_hash ASC) AS RN
    FROM AggregatedCPU)
SELECT *
FROM OrderedCPU AS OD
WHERE OD.RN<=15
ORDER BY total_cpu_ms DESC;
GO

Esta consulta agrupa por un valor hash de la consulta. Si encuentra un valor alto en la columna number_of_distinct_query_ids, investigue si una consulta de ejecución frecuente no tiene parámetros adecuados. Las consultas sin parámetros se pueden compilar en cada ejecución, lo que consume CPU significativa y afecta al rendimiento del Almacén de consultas.

Para obtener más información sobre una consulta individual, anote el hash de la consulta y úselo para identificar el uso de la CPU y el plan de consulta para un hash de consulta determinado.

Consulta de las consultas compiladas con más frecuencia mediante el hash de consulta

La compilación de un plan de consulta es un proceso que consume una gran cantidad de CPU. Azure SQL Database almacena los planes en la memoria caché para su reutilización. Algunas consultas pueden compilarse con frecuencia si no están parametrizadas o si las sugerencias de RECOMPILE fuerzan la recompilación.

El Almacén de consultas realiza un seguimiento del número de veces que se compilan las consultas. Ejecute la siguiente consulta para identificar las 20 principales consultas en el Almacén de consultas por número de compilaciones, junto con el número medio de compilaciones por minuto:

SELECT TOP (20)
    query_hash,
    MIN(initial_compile_start_time) as initial_compile_start_time,
    MAX(last_compile_start_time) as last_compile_start_time,
    CASE WHEN DATEDIFF(mi,MIN(initial_compile_start_time), MAX(last_compile_start_time)) > 0
        THEN 1.* SUM(count_compiles) / DATEDIFF(mi,MIN(initial_compile_start_time), 
            MAX(last_compile_start_time)) 
        ELSE 0 
        END as avg_compiles_minute,
    SUM(count_compiles) as count_compiles
FROM sys.query_store_query AS q
GROUP BY query_hash
ORDER BY count_compiles DESC;
GO

Para obtener más información sobre una consulta individual, anote el hash de la consulta y úselo para identificar el uso de la CPU y el plan de consulta para un hash de consulta determinado.

Identificación del uso de la CPU y el plan de consulta para un hash de consulta determinado

Ejecute la consulta siguiente para buscar el id. de consulta individual, el texto de la consulta y los planes de ejecución de la consulta para un query_hash determinado. El tiempo de CPU se devuelve en milisegundos.

Reemplace el valor de la variable @query_hash por un query_hash válido para la carga de trabajo.

declare @query_hash binary(8);

SET @query_hash = 0x6557BE7936AA2E91;

with query_ids as (
    SELECT
        q.query_hash,
        q.query_id,
        p.query_plan_hash,
        SUM(qrs.count_executions) * AVG(qrs.avg_cpu_time)/1000. as total_cpu_time_ms,
        SUM(qrs.count_executions) AS sum_executions,
        AVG(qrs.avg_cpu_time)/1000. AS avg_cpu_time_ms
    FROM sys.query_store_query q
    JOIN sys.query_store_plan p on q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats qrs on p.plan_id = qrs.plan_id
    WHERE q.query_hash = @query_hash
    GROUP BY q.query_id, q.query_hash, p.query_plan_hash)
SELECT qid.*,
    qt.query_sql_text,
    p.count_compiles,
    TRY_CAST(p.query_plan as XML) as query_plan
FROM query_ids as qid
JOIN sys.query_store_query AS q ON qid.query_id=q.query_id
JOIN sys.query_store_query_text AS qt on q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan AS p ON qid.query_id=p.query_id and qid.query_plan_hash=p.query_plan_hash
ORDER BY total_cpu_time_ms DESC;
GO

Esta consulta devuelve una fila por cada variación de un plan de ejecución para query_hash en todo el historial del Almacén de consultas. Los resultados se ordenan por tiempo total de CPU.

Uso de herramientas interactivas del Almacén de consultas para realizar un seguimiento del uso histórico de la CPU

Si prefiere usar herramientas gráficas, siga estos pasos para usar las herramientas interactivas del Almacén de consultas en SSMS.

  1. Abra SSMS y conéctese a la base de datos en el Explorador de objetos.
  2. Expanda el nodo de bases de datos en el Explorador de objetos.
  3. Expanda la carpeta Almacén de consultas.
  4. Abra el panel Consumo total de recursos.

El tiempo total de la CPU para la base de datos durante el último mes en milisegundos se muestra en la parte inferior izquierda del panel. En la vista predeterminada, el tiempo de la CPU se agrega por día.

La captura de pantalla muestra la vista del Consumo general de recursos del Almacén de consultas en SSMS.

Seleccione Configurar en la parte superior derecha del panel para seleccionar un período de tiempo diferente. También puede cambiar la unidad de agregación. Por ejemplo, puede elegir ver los datos de un intervalo de fechas específico y agregar los datos por hora.

Uso de las herramientas interactivas del Almacén de consultas para identificar las consultas principales por tiempo de CPU

Seleccione una barra del gráfico para explorar en profundidad y ver las consultas que se ejecutan en un período de tiempo específico. Se abrirá el panel Consultas que consumen más recursos. También puede abrir las Consultas que consumen más recursos desde el nodo Almacén de consultas, en la base de datos en el Explorador de objetos directamente.

La captura de pantalla muestra el panel de Consultas que consumen más recursos para el Almacén de consultas en S S M S.

En la vista predeterminada, el panel Consultas que consumen más recursos muestra las consultas por Duración (ms). La duración a veces puede ser inferior al tiempo de la CPU: las consultas que usan paralelismo pueden usar mucho más tiempo de CPU que su duración general. La duración también puede ser mayor que el tiempo de CPU si los tiempos de espera eran significativos. Para ver las consultas por tiempo de CPU, seleccione la lista desplegable Métrica en la parte superior izquierda del panel y seleccione Tiempo de CPU (ms).

Cada barra del cuadrante superior izquierdo representa una consulta. Seleccione una barra para ver los detalles de esa consulta. El cuadrante superior derecho de la pantalla muestra cuántos planes de ejecución hay en el Almacén de consultas para esa consulta y los asigna en función de cuándo se ejecutaron y cuánto se utilizó de la métrica seleccionada. Seleccione cada identificador de plan para controlar el plan de ejecución de la consulta que se muestra en la mitad inferior de la pantalla.

Nota:

Para una guía de interpretación de las vistas del Almacén de consultas y de las formas que aparecen en la vista Principales consumidores de recursos, consulte Procedimientos recomendados con el Almacén de consultas.

Reducción del uso de la CPU

Parte de la solución de problemas debe incluir la información sobre las consultas identificadas en la sección anterior. Puede reducir el uso de la CPU ajustando índices, modificando los patrones de aplicación, ajustando consultas y optimizando la configuración relacionada con la CPU para la base de datos.

Tenga en cuenta las siguientes estrategias en esta sección.

Reducción del uso de la CPU con ajuste automático del índice

Una optimización eficaz del índice reduce el uso de la CPU para muchas consultas. Los índices optimizados reducen las lecturas lógicas y físicas de una consulta, lo que suele dar como resultado que la consulta necesite hacer menos trabajo.

Azure SQL Database ofrece administración automática de índices para cargas de trabajo en las réplicas principales. La administración automática de índices usa el aprendizaje automático para supervisar la carga de trabajo y optimizar los índices no agrupados basados en disco del almacén de filas para la base de datos.

Revise las recomendaciones de rendimiento, incluidas las recomendaciones de índice, en Azure Portal. Puede aplicar estas recomendaciones manualmente o habilitar la opción de ajuste automático CREATE INDEX para crear y verificar el rendimiento de los nuevos índices en su base de datos.

Reducción del uso de la CPU con la corrección automática del plan (forzar plan)

Otra causa común de incidentes elevados de CPU es la regresión de la elección del plan de ejecución. Azure SQL Database ofrece la opción de ajuste automático forzar plan para identificar regresiones en los planes de ejecución de consultas en cargas de trabajo de réplicas primarias. Con esta característica de ajuste automático habilitada, Azure SQL Database comprobará si forzar un plan de ejecución de consulta da como resultado un rendimiento mejorado confiable para las consultas con regresión del plan de ejecución.

Si la base de datos se creó después de marzo de 2020, la opción de ajuste automático forzar plan estaba habilitada automáticamente. Si la base de datos se creó antes de ese momento, es posible que desee habilitar la opción de ajuste automático forzar plan.

Ajuste manual de índices

Use los métodos descritos en Identificación de las causas del uso elevado de la CPU para identificar los planes de consulta para las consultas que consumen más CPU. Estos planes de ejecución le ayudarán a identificar y agregar índices no agrupados para acelerar las consultas.

Cada índice no agrupado basado en disco de la base de datos requiere espacio de almacenamiento y debe mantenerse por el motor de SQL. Modifique los índices existentes en lugar de agregar nuevos índices cuando sea posible y asegúrese de que los nuevos índices reduzcan correctamente el uso de la CPU. Para obtener información general sobre los índices no agrupados, consulte Directrices para diseñar índices no agrupados.

Para algunas cargas de trabajo, los índices de almacén de columnas pueden ser la mejor opción para reducir la CPU de consultas de lectura frecuentes. Vea Guía de diseño de índices de almacén de columnas para recomendaciones de alto nivel sobre escenarios en los que los índices de almacén de columnas pueden ser adecuados.

Ajuste de la configuración de la aplicación, las consultas y la base de datos

Al examinar sus principales consultas, puede encontrar antipatrones de la aplicación, como un comportamiento "locuaz", cargas de trabajo que se beneficiarían del particionamiento y un diseño de acceso a la base de datos subóptimo. Para las cargas de trabajo de lectura intensiva, considere las réplicas de solo lectura para descargar las cargas de trabajo de consulta de solo lectura y el almacenamiento en caché de nivel de aplicación como estrategias a largo plazo para escalar horizontalmente los datos de lectura frecuente.

También puede optar por ajustar manualmente la CPU principal con las consultas identificadas en la carga de trabajo. Las opciones de ajuste manual incluyen reescribir instrucciones de Transact-SQL, forzar planes en el Almacén de consultas y aplicar sugerencias de consulta.

Si identifica casos en los que las consultas a veces usan un plan de ejecución que no es óptimo para el rendimiento, revise las soluciones de las consultas que tienen problemas con el plan de distinción de parámetros (PSP).

Si identifica consultas no parametrizadas con un alto número de planes, considere la posibilidad de parametrizar estas consultas, asegurándose de declarar completamente los tipos de datos de los parámetros, incluida la longitud y la precisión. Esto puede hacerse modificando las consultas, creando una guía de plan para forzar la parametrización de una consulta específica o habilitando la parametrización forzada a nivel de la base de datos.

Si identifica consultas con altas tasas de compilación, identifique las causas de la compilación frecuente. La causa más común de compilación frecuente son las sugerencias de RECOMPILE. Siempre que sea posible, identifique cuándo se agregó la sugerencia RECOMPILE y qué problema se pretendía resolver. Investigue si se puede implementar una solución alternativa de ajuste de rendimiento para proporcionar un rendimiento coherente para consultas que se ejecutan con frecuencia sin una sugerencia RECOMPILE.

Reducción del uso de la CPU ajustando el grado máximo de paralelismo

El ajuste grado máximo de paralelismo (MAXDOP) controla el paralelismo entre consultas en el motor de base de datos. Los valores MAXDOP más altos suelen dar lugar a más subprocesos paralelos por consulta y a una ejecución de consultas más rápida.

En algunos casos, un gran número de consultas paralelas que se ejecutan simultáneamente puede ralentizar una carga de trabajo y causar un uso elevado de la CPU. Es más probable que el paralelismo excesivo se produzca en bases de datos con un gran número de núcleos virtuales donde MAXDOP se establece en un número alto o en cero. Si MAXDOP se establece en cero, el motor de base de datos establece el número de programadores que usarán los subprocesos paralelos en el número total de núcleos lógicos o en 64, el que sea menor.

Puede identificar el grado máximo de paralelismo de la base de datos con Transact-SQL. Conéctese a su base de datos con SSMS o Azure Data Studio y ejecute la siguiente consulta:

SELECT 
    name, 
    value, 
    value_for_secondary, 
    is_value_default 
FROM sys.database_scoped_configurations
WHERE name=N'MAXDOP';
GO

Considere la posibilidad de experimentar con pequeños cambios en la configuración MAXDOP en el nivel de base de datos o modificar consultas problemáticas individuales para usar un MAXDOP no predeterminado con una sugerencia de consulta. Para obtener más información, consulte los ejemplos en Configuración del grado máximo de paralelismo.

Adición de recursos de CPU

Es posible que encuentre que las consultas e índices de la carga de trabajo están correctamente ajustados, o que el ajuste del rendimiento requiere cambios que no puede realizar a corto plazo debido a procesos internos u otros motivos. La adición de más recursos de CPU puede resultar beneficiosa para estas bases de datos. Puede escalar recursos de base de datos con un tiempo de inactividad mínimo.

Puede agregar más recursos de CPU a su instancia de Azure SQL Database configurando el número de núcleos virtuales o la configuración de hardware para bases de datos con el modelo de compra de núcleos virtuales.

En el modelo de compra basado en DTU, puede aumentar el nivel de servicio y aumentar el número de unidades de transacción de base de datos (DTU). Las DTU se basan en una medición combinada de CPU, memoria y número de lecturas y escrituras. Una ventaja del modelo de compra de núcleos virtuales es que permite un control más granular sobre el hardware en uso y el número de núcleos virtuales. Puede migrar Azure SQL Database del modelo basado en DTU al modelo basado en núcleo virtual para completar la transición entre modelos de compra.

Contenido relacionado

Obtenga más información sobre la supervisión y el ajuste del rendimiento de Azure SQL Database en los siguientes artículos: