Anterior

Siguientes

Supervisión y solución de problemas de rendimiento

Completado

La supervisión y la solución de problemas son elementos clave para ofrecer un rendimiento estable. Azure SQL tiene las mismas herramientas y características que SQL Server para supervisar y solucionar problemas de rendimiento, y otras funcionalidades. Esto incluye características como las vistas de administración dinámica (DMV), los eventos extendidos y Azure Monitor. También es importante saber usar estas herramientas y funcionalidades en diversos escenarios de rendimiento de Azure SQL, Estos escenarios incluyen un uso elevado de la CPU o la espera de un recurso.

Herramientas y funciones para supervisar el rendimiento

Azure SQL proporciona funcionalidades de supervisión y solución de problemas en el ecosistema de Azure, así como herramientas conocidas que se incluyen en SQL Server. En las siguientes secciones las describiremos someramente.

Azure Monitor

Azure Monitor forma parte del ecosistema de Azure, y Azure SQL está integrado para admitir métricas, alertas y registros de Azure. Los datos de Azure Monitor se pueden ver en Azure Portal y las aplicaciones pueden acceder a estos datos a través de Azure Event Hubs o de diversas API. De forma bastante parecida al Monitor de rendimiento de Windows, Azure Monitor ayuda a acceder a las métricas de uso de recursos de Azure SQL sin usar herramientas de SQL Server.

Vistas de administración dinámica (DMV)

Azure SQL proporciona casi la misma infraestructura de DMV que SQL Server, con algunas diferencias. Las DMV son fundamentales en la supervisión del rendimiento, ya que podemos ver datos de rendimiento clave de SQL Server a través de consultas T-SQL estándar. Así, se puede consultar información como las consultas activas, el uso de recursos, los planes de consulta y los tipos de espera de recursos. Más adelante en esta unidad obtendrá más información sobre las DMV con Azure SQL.

Eventos extendidos

Azure SQL proporciona casi la misma infraestructura de eventos extendidos que SQL Server, con algunas diferencias. Los eventos extendidos que se usan en Azure SQL ofrecen la posibilidad de realizar un seguimiento de los eventos de ejecución clave en SQL Server. Para el rendimiento, los eventos extendidos permiten realizar el seguimiento de la ejecución de consultas individuales. Más adelante en esta unidad tendrá más información sobre los eventos extendidos con Azure SQL.

Generación de perfiles de consulta ligera

La generación de perfiles ligera es un método avanzado para solucionar problemas de escenarios que requieran la recuperación del plan de ejecución real para solicitudes en curso y consultas de alto valor. Debido a su baja sobrecarga, cualquier servidor que aún no esté enlazado a la CPU puede ejecutar la generación de perfiles ligera continuamente y permitir que los profesionales de la base de datos accedan a cualquier ejecución que se esté ejecutando en cualquier momento. Por ejemplo: mediante el Monitor de actividad en SQL Server Management Studio (SSMS) o consultando directamente sys.dm_exec_query_profiles o sys.dm_exec_query_statistics_xml.

La generación de perfiles de consulta ligera se puede usar para examinar el plan de consulta y el estado de ejecución de una consulta activa. Se trata de una característica clave para depurar el rendimiento de las consultas en las instrucciones mientras se ejecutan. Esto reduce el tiempo de resolución de problemas de rendimiento en comparación con el uso de herramientas como los eventos extendidos para realizar el seguimiento del rendimiento de las consultas. El acceso a la generación de perfiles de consulta ligera se realiza a través de DMV y está activado de forma predeterminada en Azure SQL, como en SQL Server 2019 y versiones posteriores.

Funciones de depuración del plan de consulta

En algunas situaciones, es posible que se necesiten más detalles sobre el rendimiento de la consulta de una instrucción T-SQL individual. Las instrucciones SET de T-SQL, como SHOWPLAN y STATISTICS, pueden proporcionar estos detalles y son totalmente compatibles tanto en Azure SQL como en SQL Server.

Almacén de consultas

Almacén de consultas es un registro histórico de la ejecución de rendimiento de las consultas almacenadas en la base de datos de usuario. Almacén de consultas está activado de forma predeterminada para Azure SQL y se usa para proporcionar funcionalidades como la corrección automática del plan y el ajuste automático. Los informes de SQL Server Management Studio (SSMS) relativos a este almacén están disponibles en Azure SQL. Use estos informes para buscar las consultas que consumen más recursos, incluidas las diferencias de los planes de consulta y los principales tipos de espera que examinar en escenarios de espera de recursos.

Visualizaciones de rendimiento

Respecto a Azure SQL Database, la información de rendimiento de Almacén de consultas integrada se puede consultar en Azure Portal a través de visualizaciones. Así, se pueden ver algunos de los mismos datos del Almacén de consultas que veríamos con una herramienta de cliente como SSMS. Use las opciones Información general del rendimiento e Información de rendimiento de consultas en Azure Portal.

Detalles de DMV

Durante muchos años, las DMV han sido el motor para la supervisión y solución de problemas de rendimiento en SQL Server. Hay DMV comunes de SQL Server disponibles para Azure SQL y algunas son específicas de Azure.

Azure SQL Managed Instance

Todas las DMV para SQL Server están disponibles para SQL Managed Instance. Las DMV clave, como sys.dm_exec_requests y sys.dm_os_wait_stats, se usan normalmente para examinar el rendimiento de las consultas.

La vista sys.server_resource_stats del sistema es específica de Azure SQL Managed Instance y muestra el uso histórico de los recursos. Se trata de una herramienta valiosa para ver el uso de los recursos, ya que no tenemos acceso directo a herramientas del sistema operativo como, por ejemplo, el Monitor de rendimiento.

Azure SQL Database

La mayoría de las DMV comunes que se necesitan para el rendimiento están disponibles, incluyendo sys.dm_exec_requests y sys.dm_os_wait_stats. Hay que tener en cuenta que estas DMV solo proporcionan información específica de la base de datos, y no de todas las bases de datos de un servidor lógico.

La DMV sys.dm_db_resource_stats es específica de Azure SQL Database y es posible usarla para ver el historial de uso de recursos de la base de datos. Use esta DMV de manera similar a como usaría sys.server_resource_stats en una instancia de Managed Instance.

La DMV sys.elastic_pool_resource_stats es similar a sys.dm_db_resource_stats, pero puede usarla para ver el uso de recursos de las bases de datos del grupo elástico.

DMV que son necesarias

Las siguientes DMV son necesarias para solucionar algunos escenarios de rendimiento de Azure SQL:

• sys.dm_io_virtual_file_stats es importante, ya que no tenemos acceso directo a las métricas del sistema operativo sobre el rendimiento de E/S por cada archivo.
• sys.dm_os_performance_counters está disponible para Azure SQL Database y SQL Managed Instance para ver las métricas de rendimiento de SQL Server más comunes. Use esta DMV para ver la información del contador de rendimiento de SQL Server que normalmente está disponible en el Monitor de rendimiento.
• sys.dm_instance_resource_governance permite ver los límites de recursos de una instancia de Managed Instance. Puede examinar esta información para ver cuáles deben ser los límites de recursos esperados sin usar Azure Portal.
• sys.dm_user_db_resource_governance permite ver los límites de recursos comunes según la opción de implementación, el nivel de servicio y el tamaño de la implementación de Azure SQL Database. Puede examinar esta información para ver cuáles deben ser los límites de recursos esperados sin usar Azure Portal.

DMV para conclusiones más detalladas

Estas DMV proporcionan conclusiones más detalladas de los límites y la gobernanza de los recursos de Azure SQL. No están diseñadas para usarse en escenarios comunes, pero pueden ser útiles a la hora de examinar problemas de rendimiento complejos con profundidad. Consulte la documentación para obtener todos los detalles de estas DMV:

• sys.dm_user_db_resource_governance_internal (solo SQL Managed Instance)
• sys.dm_resource_governor_resource_pools_history_ex
• sys.dm_resource_governor_workload_groups_history_ex

Detalles de eventos extendidos

La característica de eventos extendidos es el mecanismo de seguimiento de SQL Server. En Azure SQL, los eventos extendidos se basan en el motor de SQL Server y, por lo tanto, son casi los mismos con algunas diferencias notables. que describiremos en las secciones siguientes.

Eventos extendidos de Azure SQL Database

Los eventos extendidos se pueden usar en Azure SQL Database de la misma forma que en SQL Server, creando sesiones y usando eventos, acciones y destinos. Tenga en cuenta estos puntos importantes al crear sesiones de eventos extendidos:

• Se admiten los eventos y las acciones usados con más frecuencia.
• Se admiten los destinos de archivo, ring_buffer y contador.
• Los destinos de archivo se admiten en Azure Blob Storage, ya que los usuarios no tienen acceso a los discos del sistema operativo subyacente.

Puede usar SSMS o T-SQL para crear e iniciar sesiones. Use SSMS para ver los datos de destino de la sesión de eventos extendidos o la función del sistema sys.fn_xe_file_target_read_file.

Nota:

No es posible usar SSMS para ver los datos activos de Azure SQL Database.

Es importante saber que los eventos extendidos desencadenados en las sesiones son específicos de la base de datos y no se pueden usar en el servidor lógico.

Eventos extendidos de Azure SQL Managed Instance

Los eventos extendidos se pueden usar en Azure SQL Managed Instance, igual que en SQL Server, creando sesiones y usando eventos, acciones y destinos. Tenga en cuenta estos puntos importantes al crear sesiones de eventos extendidos:

• Se admiten todos los eventos, destinos y acciones.
• Los destinos de archivo se admiten en Azure Blob Storage, ya que los usuarios no tienen acceso a los discos del sistema operativo subyacente.
• Algunos eventos específicos se agregan para SQL Managed Instance para llevar un seguimiento de eventos específicos de la administración y ejecución de la instancia.

Puede usar SSMS o T-SQL para crear e iniciar sesiones. Use SSMS para ver los datos de destino de la sesión de eventos extendidos o la función del sistema sys.fn_xe_file_target_read_file. La capacidad de SSMS para ver datos en directo es compatible con SQL Server y Azure SQL Managed Instance.

Escenarios de rendimiento de Azure SQL

Para decidir cómo aplicar las herramientas y funciones de supervisión y solución de problemas de rendimiento, es importante examinar el rendimiento de Azure SQL a través de escenarios.

Escenarios de rendimiento comunes

Una técnica común para la solución de problemas de rendimiento de SQL Server consiste en examinar si un problema de rendimiento está En ejecución (uso elevado de CPU) o En espera (en espera de un recurso). En el siguiente diagrama se muestra un árbol de decisión para determinar si un problema de rendimiento de SQL Server está en ejecución o en espera, y cómo usar las herramientas de rendimiento para determinar la causa y la solución.

Ahora se profundizará en los detalles de cada aspecto del diagrama.

Diferencias entre en ejecución y en espera

En primer lugar, examinemos el uso general de los recursos. En una implementación estándar de SQL Server, es posible usar herramientas como el Monitor de rendimiento en Windows o top en Linux. En el caso de Azure SQL, puede usar los métodos siguientes:

• Azure Portal, PowerShell o alertas

  Azure Monitor tiene métricas integradas para ver el uso de los recursos de Azure SQL. También se pueden configurar alertas para buscar condiciones de uso de recursos.

• sys.dm_db_resource_stats

  Para Azure SQL Database, puede examinar esta DMV para ver el uso de los recursos de CPU, memoria y E/S para la implementación de base de datos. En esta DMV se toma una instantánea de estos datos cada 15 segundos.

• sys.server_resource_stats

  Esta DMV se comporta como sys.dm_db_resource_stats, pero sirve para ver el uso de recursos de CPU, memoria y E/S de SQL Managed Instance. En esta DMV también se toma una instantánea cada 15 segundos.

• sys.dm_user_db_resource_governance

  En Azure SQL Database, esta DMW devuelve la configuración real y los valores de capacidad que usan los mecanismos de regulación de recursos en la base de datos o el grupo elástico actual.

• sys.dm_instance_resource_governance

  En Azure SQL Managed Instance, esta DMV devuelve información similar a sys.dm_user_db_resource_governance, pero para la instancia actual de SQL Managed Instance.

En ejecución

Si ha determinado que el problema es un uso elevado de la CPU, esto se denomina escenario en ejecución. Un escenario en ejecución puede implicar consultas que consumen recursos a través de la compilación o la ejecución. Use las siguientes herramientas para realizar un análisis más exhaustivo:

• Almacén de consultas

  Use los informes de recursos de mayor consumo en SSMS, las vistas de catálogo del Almacén de consultas o Información de rendimiento de consultas de Azure Portal (solo para Azure SQL Database) a fin de encontrar las consultas que más recursos de CPU consumen.

• sys.dm_exec_requests

  Use esta DMV en Azure SQL para obtener una instantánea del estado de las consultas activas. Busque consultas que tengan un estado de RUNNABLE y un tipo de espera de SOS_SCHEDULER_YIELD para ver si tiene suficiente capacidad de CPU.

• sys.dm_exec_query_stats

  Esta DMV se puede usar de forma muy parecida a Almacén de consultas para encontrar las consultas que consumen más recursos. Tenga en cuenta que solo está disponible en los planes de consulta que se almacenan en la memoria caché, mientras que Almacén de consultas proporciona un registro histórico de rendimiento persistente. Esta DMV también permite buscar el plan de consulta de una consulta en caché.

• sys.dm_exec_procedure_stats

  Esta DMV proporciona información similar a sys.dm_exec_query_stats, salvo que la información de rendimiento se puede ver en el nivel de procedimiento almacenado.

  Después de averiguar qué consulta o consultas consumen más recursos, puede que sea necesario examinar si disponemos de suficientes recursos de CPU para la carga de trabajo. Podemos depurar planes de consulta con herramientas como la generación de perfiles de consulta ligera, instrucciones SET, Almacén de consultas o el seguimiento de eventos extendidos.

En espera

Si el problema de rendimiento no parece ser un uso elevado de recursos de CPU, se podría deber a que implica la espera por un recurso. Los escenarios que implican la espera por recursos incluyen los siguientes:

• Esperas de E/S
• Esperas de bloqueo
• Tiempos de espera de bloqueo temporal
• Límites del grupo de búferes
• Concesiones de memoria
• Expulsión de la memoria caché de planes

Para realizar análisis en escenarios en espera, se suelen examinar las siguientes herramientas:

• sys.dm_os_wait_stats

  Use esta DMV para ver los tipos de espera principales de la base de datos o la instancia. Esto puede guiarle para elegir la acción siguiente en función de los tipos de espera principales.

• sys.dm_exec_requests

  Use esta DMV para buscar tipos de espera específicos para consultas activas y ver a qué recurso esperan. Puede tratarse de un escenario de bloqueo estándar que espera a los bloqueos de otros usuarios.

• sys.dm_os_waiting_tasks

  Use esta DMV para buscar tipos de espera para una tarea determinada de una consulta específica que se esté ejecutando en ese momento como, quizás, para ver por qué tarda más de lo normal. sys.dm_os_waiting_tasks contiene las estadísticas de espera en directo que sys.dm_os_wait_stats agrega a lo largo del tiempo.

• Almacén de consultas

  Almacén de consultas proporciona informes y vistas de catálogo que muestran una agregación de las esperas principales de la ejecución del plan de consulta. Es importante saber que una espera de CPU es equivalente a un problema en ejecución.

Sugerencia

Los eventos extendidos se pueden usar en cualquier escenario en ejecución o en espera. Para ello, se debe configurar una sesión de eventos extendidos que permita realizar un seguimiento de las consultas. Este método para depurar un problema de rendimiento es más avanzado y devuelve una gran cantidad de información a cambio de una mayor sobrecarga de rendimiento que las DMV.

Escenarios específicos de Azure SQL

Existen algunos escenarios de rendimiento, tanto en ejecución como en espera, que son específicos de Azure SQL, como la gobernanza de registros, los límites de trabajo, las esperas detectadas en los niveles de servicio Crítico para la empresa y las esperas específicas de una implementación de hiperescala.

Gobernanza de registros

Azure SQL puede usar la gobernanza de frecuencia de registros para aplicar límites de recursos al uso del registro de transacciones. Esto puede ser necesario para garantizar los límites de recursos y cumplir el acuerdo de nivel de servicio prometido. La gobernanza de registros puede aparecer en los tipos de espera siguientes:

• LOG_RATE_GOVERNOR: espera a Azure SQL Database
• POOL_LOG_RATE_GOVERNOR: espera a grupos elásticos
• INSTANCE_LOG_GOVERNOR: espera a Azure SQL Managed Instance
• HADR_THROTTLE_LOG_RATE*: espera a la latencia crítica para la empresa y de replicación geográfica

Límites de trabajo

SQL Server usa un grupo de trabajo de subprocesos pero tiene límites sobre el número máximo de trabajos. Las aplicaciones con un gran número de usuarios simultáneos podrían abordar los límites de trabajo aplicados para Azure SQL Database y Azure SQL Managed Instance:

• Azure SQL Database tiene límites basados en el nivel de servicio y el tamaño. Si supera este límite, una consulta nueva recibe un error.
• Actualmente, SQL Managed Instance usa max worker threads para que los trabajos que superen este límite puedan ver las esperas THREADPOOL.

Esperas de alta disponibilidad y recuperación ante desastres críticas para la empresa

Si se usa un nivel de servicio Crítico para la empresa, es posible que aparezcan los siguientes tipos de espera de forma inesperada:

• HADR_SYNC_COMMIT
• HADR_DATABASE_FLOW_CONTROL
• HADR_THROTTLE_LOG_RATE_SEND_RECV

Si bien estas esperas no ralentizarán la aplicación, posiblemente no esté previsto que aparezcan. Por lo general, son específicas del uso de un grupo de disponibilidad de Always On. Los niveles Crítico para la empresa usan la tecnología de los grupos de disponibilidad para implementar el SLA y las características de disponibilidad de un nivel de servicio Crítico para la empresa, por lo que estos tipos de espera deben estar previstos. Tenga en cuenta que un tiempo de espera prolongado puede ser indicio de un cuello de botella como, por ejemplo, de latencia de E/S o de réplica.

Hiperescala

La arquitectura Hiperescala puede generar algunos tipos de espera únicos con el prefijo RBIO (un posible indicador de la gobernanza de registros). Además, las DMV, las vistas de catálogo y los eventos extendidos se han mejorado para mostrar métricas de las lecturas del servidor de páginas.

En el ejercicio siguiente, aprenderá a supervisar y solucionar un problema de rendimiento de Azure SQL usando las herramientas y conocimientos adquiridos en esta unidad.

Continuar