En SolidQ estamos a punto de lanzar una nueva herramienta y queremos darte la oportunidad de que la pruebes antes que nadie. Su nombre en clave es TSQL-CSI-DW y es ni mas ni menos que el datawarehouse de análisis de rendimiento de tus consultas. La idea es sencilla: activas una traza de eventos extendidos con el template que te diremos, y nosotros lo procesamos dentro de un Datawarehouse para que lo explotes tú desde un PowerBI que te expondremos para ello.

Aquí te dejo dos casos de uso de la aplicación:

  • Qué patrones de consultas son culpables de una regresión de rendimiento en tu servidor
    [vimeo 219348773 w=425 h=350]
  • ¿Los cambios aplicados en mi servidor han tenido algún efecto en el rendimiento?
    [vimeo 219349269 w=425 h=350]

 

A continuación puedes ver algunos de los visualizadores por los que podrás navegar libremente utilizando PowerBI (ver los videos anteriores para entender cómo utilizarlos):

Prueba gratis la herramienta que analiza el rendimiento de tus consultasPrueba gratis la herramienta que analiza el rendimiento de tus consultasPrueba gratis la herramienta que analiza el rendimiento de tus consultas[box type=”info”] Naturalmente, los datos mostrados están ofuscados[/box]

Los puntos clave de esta primera versión son los siguientes:

  • Todas las ediciones de SQL Server compatibles
    • Cuando decimos todas, decimos TODAS. Desde SQL Server 2000 en adelante, pasando por Azure SQL Database. Tanto PaaS como IaaS.
  • Multi-instancia y BBDD
    • Permite analizar varias instancias y BBDD en un mismo dashboard.
  • Granularidad al segundo
    • Todo lo puedes analizar con granularidad de segundo, para ver qué ocurrió en cualquier segundo concreto del pasado.
  • Filtro por cualquier campo
    • Todas las dimensiones expuestas sirven para filtrar, no solo fecha y hora. Podrás hacer búsquedas complejas por:
      • Instancia
      • Login del usuario que lanzó la consulta
      • Aplicación que lanzó la consulta
      • Texto contenido en la consulta
      • Hostname desde el que salió la consulta
      • BBDD afectada por la consulta
  • Ratios de compression elevadísimos:
    • Hemos conseguido un ratio de compresión de entre 7,5 y 13.5 bytes por consulta (si, lees bien :)), lo que nos permite almacenar miles de millones de peticiones con granularidad al segundo, para que puedas ver el detalle completo de tus consultas durante mucho tiempo
  • Comparativas de cargas de trabajo
    • Puedes ver la evolución de los consumos desde muchos puntos de vista (lecturas, escrituras, duración y cpu) para ver la evolución del rendimiento que tienen las consultas de BBDD  Comparativas de rendimiento
    • Puedes marcar cargas de trabajo y comparar ratios de mejora fácilmente para ver diferencias de rendimiento entre tus marcas.
      • OnPremise vs Cloud
      • PRO vs PRE
      • Antes de cambios vs después de cambios
  • Origen de datos compatible con XEvent y profiler
    • Puedes cargar en un mismo DW orígenes de datos de profiler y XEvents. Esto te permitirá analizar por ejemplo tus instancias SQL 2000 junto a tus instancias Azure SQL Database.
  • PaaS e IaaS
    • Se puede explotar información proveniente de tus instancias OnPremise como de tus instancias Azure SQL Database
  • Detección de anomalías
    • Próximamente…
[box type=”info”] Si quieres participar en esta beta abierta ponte en contacto con Enrique Catalá ecatala@solidq.com . Esta beta pública estará disponible hasta Agosto. [/box]

 

 

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
Leer más

Expresiones, parámetros y funciones en Azure Data Factory

Hay ocasiones, cuando estamos construyendo pipelines con Azure Data Factory, que queremos repetir patrones para extraer y procesar la información cambiando de manera dinámica, en tiempo de ejecución, valores, orígenes/destinos de los datasets, incluso los mismos linked services. Esto es posible mediante el uso de parámetros, expresiones y funciones. Vamos a ver cómo implementarlo con un ejemplo práctico en el que se nos plantea el siguiente supuesto. Se nos ha pedido que extraigamos todos los días los datos del día anterior de distintas tablas del DW a ficheros en un blob storage que además se nombre como la tabla de origen. Si no pudiéramos utilizar contenido dinámico tendríamos que crear dos datasets (uno de origen y otro de destino) y añadir una actividad de copia por cada tabla a exportar.