Compartir a través de

Eventos extendidos en Azure SQL

Se aplica a:Azure SQL DatabaseAzure SQL Managed InstanceBase de datos SQL en Fabric

Para obtener una introducción a los eventos extendidos, consulte:

El conjunto de características, la funcionalidad y los escenarios de uso para eventos extendidos en Azure SQL Database, SQL Database en Fabric e Instancia administrada de Azure SQL son similares a lo que está disponible en SQL Server. Las diferencias principales son:

  • En Azure SQL Database, SQL Database en Fabric y Azure SQL Managed Instance, el destino event_file siempre utiliza blobs en Azure Storage, en lugar de archivos en disco.
    • En SQL Server, el event_file destino puede usar archivos en disco o blobs en Azure Storage.
  • En Azure SQL Database y SQL Database en Fabric, las sesiones de eventos siempre tienen ámbito de base de datos. Esto significa que:
    • Una sesión de eventos en una base de datos no puede recopilar eventos desde otra base de datos.
    • Debe producirse un evento en el contexto de una base de datos de usuario que se incluirá en una sesión.
  • En Azure SQL Managed Instance, puede crear sesiones de eventos con ámbito de servidor y ámbito de base de datos. Se recomienda usar sesiones de eventos con ámbito de servidor para la mayoría de los escenarios.

Get started

Hay dos ejemplos detallados para ayudarle a comenzar rápidamente con Eventos Extendidos.

Los eventos extendidos se pueden usar para supervisar las réplicas de solo lectura. Para obtener más información, vea Lectura de consultas en réplicas.

procedimientos recomendados

Adopte los siguientes procedimientos recomendados para usar eventos extendidos de forma segura, confiable y sin afectar al rendimiento de la carga de trabajo y el estado del motor de base de datos.

  • Si usa el destino event_file:
    • En función de los eventos agregados a una sesión, los archivos generados por el event_file destino pueden contener datos confidenciales. Revise cuidadosamente las asignaciones de roles de RBAC y las listas de control de acceso (ACL) en la cuenta de almacenamiento y el contenedor, incluido el acceso heredado, para evitar conceder acceso de lectura innecesario. Siga el principio de privilegios mínimos.
    • Use una cuenta de almacenamiento en la misma región de Azure que la base de datos o la instancia administrada donde se crean sesiones de eventos.
    • Alinee la redundancia de la cuenta de almacenamiento con la redundancia de la base de datos, el grupo elástico o la instancia administrada. Para los recursos con redundancia local, use LRS, GRS o RA-GRS. Para los recursos con redundancia de zona, use ZRS, GZRS o RA-GZRS. Consulte Redundancia de Azure Storage para más detalles.
    • No use ningún nivel de acceso de blob distinto de Hot.
    • No habilite el espacio de nombres jerárquico para la cuenta de almacenamiento.
  • Si desea crear una sesión de eventos en ejecución continua que se inicie automáticamente después de cada reinicio de Motor de base de datos (por ejemplo, después de una conmutación por error o un evento de mantenimiento), incluya la opción de sesión de eventos de STARTUP_STATE = ON en las instrucciones CREATE EVENT SESSION o ALTER EVENT SESSION.
  • Por el contrario, use STARTUP_STATE = OFF para sesiones de eventos a corto plazo, como las que se usan en la solución de problemas ad hoc.
  • En la base de datos de Azure SQL, no leas los eventos de interbloqueo de la sesión de eventos integrada dl. Si hay un número grande de eventos de interbloqueo recopilados, leerlos con la función sys.fn_xe_file_target_read_file() puede provocar un error de memoria insuficiente en la base de datos master. Esto puede afectar al procesamiento de inicio de sesión y provocar una interrupción de la aplicación. Para conocer las formas recomendadas de supervisar interbloqueos, consulta Recopilación de gráficos de interbloqueo en la base de datos de Azure SQL con eventos extendidos.

Destinos de sesión de eventos

Para obtener más información sobre los destinos de eventos extendidos admitidos en Azure SQL Database, SQL Database en Fabric, Azure SQL Managed Instance y SQL Server, consulte Destinos para eventos extendidos.

Transact-SQL diferencias

Al ejecutar las instrucciones CREATE EVENT SESSION, ALTER EVENT SESSION y DROP EVENT SESSION en SQL Server y en Azure SQL Managed Instance, se usa la cláusula ON SERVER. En Azure SQL Database, se usa la cláusula ON DATABASE en su lugar, porque en las sesiones de eventos de Azure SQL Database están en el ámbito de la base de datos.

Vistas de catálogo de eventos extendidos

Los eventos extendidos proporcionan vistas de catálogos. Las vistas de catálogo le indican los metadatos o la definición de la sesión de eventos. Estas vistas no devuelven información acerca de las instancias de sesiones de eventos activas.

Para obtener una lista de vistas de catálogo para cada plataforma, consulte Vistas de catálogo de eventos extendidos.

Vistas de administración dinámica de eventos extendidos

Los eventos extendidos proporcionan varias vistas de administración dinámica (DMV). Las DMV devuelven información sobre las sesiones de eventos iniciadas.

Para obtener una lista de DMV para cada plataforma, consulte Vistas de administración dinámica de eventos extendidos.

DMV comunes

Hay DMV de eventos extendidos adicionales que son comunes a Azure SQL Database, Azure SQL Managed Instance y SQL Server:

Eventos, acciones y destinos disponibles

Puede obtener eventos, acciones y destinos disponibles mediante esta consulta:

SELECT o.object_type,
       p.name AS package_name,
       o.name AS db_object_name,
       o.description AS db_obj_description
FROM sys.dm_xe_objects AS o
INNER JOIN sys.dm_xe_packages AS p
ON p.guid = o.package_guid
WHERE o.object_type IN ('action','event','target')
ORDER BY o.object_type,
         p.name,
         o.name;

Permissions

Consulte permisos para obtener permisos detallados por plataforma.

Autorización de contenedor de almacenamiento y control

Cuando se utiliza el event_file como destino con blobs de Azure Storage, el motor de base de datos que ejecuta la sesión de eventos debe tener un acceso específico al contenedor de blobs. Puede conceder este acceso de una de las maneras siguientes:

  • Asigne el rol RBAC de colaborador de datos de Storage Blob a la identidad administrada del servidor lógico de Azure SQL o de la instancia administrada de Azure SQL en el contenedor y cree una credencial para indicar al motor de base de datos que use la identidad administrada para la autenticación.

    Como alternativa a la asignación del rol RBAC de colaborador de datos de Storage Blob, puede asignar las siguientes acciones de RBAC:

    Namespace Action
    Microsoft.Storage/storageAccounts/blobServices/containers/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ delete
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ write

  • Cree un token de SAS para el contenedor y almacene el token en una credencial.

    En base de datos de Azure SQL, debe usar una credencial con ámbito de base de datos. En Azure SQL Managed Instance y SQL Server, use una credencial con ámbito de servidor.

    El token de SAS que cree para el contenedor de Azure Storage debe cumplir los siguientes requisitos:

    • Tenga los rwdl permisos (Read, Write, Delete, List).
    • Tener la hora de inicio y expiración que abarcan la duración de la sesión de eventos.
    • No tener restricciones de direcciones IP.

Gobernanza de recursos

En Azure SQL Database, el consumo de memoria por sesiones de eventos extendidos se controla dinámicamente mediante el Motor de base de datos para minimizar la contención de recursos.

Hay un límite en la memoria disponible para las sesiones de eventos:

  • En una base de datos única, la memoria total de sesión se limita a 128 MB.
  • En un grupo elástico, las bases de datos individuales están limitadas por los límites de base de datos única y, en total, no pueden superar los 512 MB.

Si recibe un mensaje de error que hace referencia a un límite de memoria, las acciones correctivas que puede realizar son:

  • Ejecutar menos sesiones de eventos simultáneas.
  • Con instrucciones CREATE y ALTER para sesiones de eventos, reduzca la cantidad de memoria que especifique en la cláusula MAX_MEMORY para la sesión.

Note

En eventos extendidos, la cláusula MAX_MEMORY aparece en dos contextos: al crear o modificar una sesión (en el nivel de sesión) y al usar el destino ring_buffer (en el nivel de destino). Los límites anteriores se aplican a la memoria de nivel de sesión.

Hay un límite en el número de sesiones de evento iniciadas en Azure SQL Database:

  • El límite es de 100 en una base de datos única.
  • En un grupo elástico, el límite es de 100 sesiones con ámbito de base de datos por grupo.

En grupos elásticos densos, puede producirse un error al iniciar una nueva sesión de eventos extendidos debido a las restricciones de memoria incluso cuando el número total de sesiones iniciadas es inferior a 100.

Para buscar la memoria total consumida por una sesión de eventos, ejecute la consulta siguiente mientras está conectada a la base de datos donde se inicia la sesión de eventos:

SELECT name AS session_name,
       total_buffer_size + total_target_memory AS total_session_memory
FROM sys.dm_xe_database_sessions;

Para buscar la memoria total de la sesión de eventos de un grupo elástico, esta consulta debe ejecutarse en todas las bases de datos del grupo.

Contenido relacionado

  • Last updated on