Finalmente, la anunciada y esperada funcionalidad de eventos extendidos está disponible en SQL Databases. No existe anuncio oficial por el momento y durante nuestras pruebas hemos encontrado algunos errores que producían que la sesión terminara de forma abrupta.  Por ahora la funcionalidad nos ofrece un conjunto de sesiones preconfiguradas que vienen desactivadas por defecto:

 

Eventos extendidos en SQL Databases

Únicamente podremos tener una sesión en marcha concurrentemente por base de datos, si intentamos poner en marcha otra simultáneamente obtendremos el siguiente error:

Eventos extendidos en SQL Databases

Una de las sesiones que creemos que puede ser más util es la llamada azure_xe_query_batch ya que nos ofrece los batch ejecutados de forma muy parecida a lo que nos permite una traza de SQL Profiler. El primer paso será arrancar la sesión:

Eventos extendidos en SQL Databases

 

A continuación configuramos el visor de datos en vivo para esta sesión:

Eventos extendidos en SQL Databases

 

Y lo que nos mostraría sería información sobre los batch ejecutados e información útil como el consumo de cpu, la duración, las lecturas, etc:

Eventos extendidos en SQL Databases

 

Aparecen un conjunto de dmvs nuevas alrededor de los eventos extendidos a nivel de base de datos. Podemos ver qué eventos se capturan en la sesión y que el filtro (cuarto resultset) filtra por nuestro db_id, de forma que no podemos ver de ninguna forma actividad del servidor fuera de nuestra base de datos:

select * from sys.dm_xe_database_sessions

select * from sys.dm_xe_database_session_targets

select * from sys.dm_xe_database_session_object_columns

select * from sys.dm_xe_database_session_events

select * from sys.dm_xe_database_session_event_actions

 Eventos extendidos en SQL Databases

 

Para manejar la sesión hemos descubierto que se pueden utilizar comandos de start-stop de sesión de xevents a nivel de base de datos (indicando ON DATABASE en vez de ON SERVER):

alter event session azure_xe_query_batch ON DATABASE STATE = START

alter event session azure_xe_query_batch ON DATABASE STATE = STOP

No hemos encontrado forma de poder modificar una de estas sesiones para añadir otro target, por ejemplo un ringbuffer, para permitir explotar esta información de forma más eficiente, almacenarla en una tabla, etc. Entendemos que estas posibilidades deberá Microsoft añadirlas con mucho cuidado para evitar que un usuario malintencionado pueda causar algún tipo de problemas en el servidor. Se me ocurren por ejemplo problemas de rendimiento globales o de excesivo uso de memoria.

El flujo de datos que utiliza el visor de eventos extendidos se obtiene con la siguiente llamada:

SELECT type, data FROM sys.fn_MSxe_read_event_stream (‘azure_xe_query_batch’,0)

Esta función devuelve datos en formato stream, en binario, sobre los eventos generados por la sesión de eventos extendidos pero no conocemos forma de  poder procesar esto desde T-SQL. Por tanto por ahora estamos limitados a usar esta funcionalidad sin poder volcar los datos a una tabla por ejemplo lo cual seria bastante más práctico para poder realizar análisis, normalizaciones, etc.

En conclusión, la funcionalidad de eventos extendidos parece que está a punto de hacer su aparición en SQL Databases, quizás en Preview, y ello traerá consigo nuevas posibilidades para la diagnosis de problemas en SQL Databases. En un primer momento las sesiones ofrecidas son fijas, no modificables, ni podemos tener varias en funcionamiento concurrentemente. Teniendo en cuenta que SQL Profiler está marcado como obsoleto y su sustituto son los eventos extendidos tiene sentido que Azure opte por añadir funcionalidad en esa dirección dejando las “trazas clásicas” sin soporte.

 

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like

Particionado de tablas en SQL Server 2014

Tradicionalmente el particionado de datos no ha sido muy de mi agrado por las implicaciones de mantenimiento que se tenian asociadas. Tareas como reindexar, mover particiones entre tablas, actualizar estadísticas,…no eran tarea sencilla en entornos con carga 24x7 en el momento en el que particionabas una tabla.