Videos

¿Cómo usar QueryStore en SQL o Azure?

En este tercer Video Blog nos adentramos en QueryStore, una de las herramientas más potentes que Microsoft pone a nuestra disposición de manera nativa para monitorizar el rendimiento de nuestras bases de datos SQL ya sea en SQL Server o en Azure.

Como ya os prometí en el post de ayer donde vimos la teoría que rodea a esta herramienta, hoy vamos a aprovechar las ventajas del formato de Video Blog para ver todas las opciones de visualización de datos y configuración de la herramienta que necesitamos para convertirnos en verdaderos profesionales del rendimiento en SQL.

Vistas de QueryStore

QueryStore pone a nuestra disposición varias vistas con diferente información de lo más útil.

  • Regresed Queries: Nos va a permitir localizar las consultas que han sufrido una degradación de rendimiento.
  • Overall Resource Consumption: Muestra el consumo de los diferentes recursos a lo largo del tiempo en diferentes gráficos de barras.
  • Top Resource Consuming Queries: Nos va a mostrar las consultas que más recursos han consumido de un recurso que nosotros elijamos en un periodo a elegir entre 5 minutos y varios años.
  • Queries With Forced Plans: Aquí podremos encontrar las consultas a las que les hemos forzado un plan de ejecución en concreto.
  • Queries With High Variation: Esta vista nos mostrará las consultas con gran variación en su consumo de recursos, ya sea a mejor o peor.
  • Query Waits Statistics: Este informe es uno de los más importantes y por el que yo siempre empiezo a mirar. En el vamos a ver cuales son los recursos que causan cuellos de botella en el rendimiento de nuestras consultas.
  • Tracked Queries: En este último dashboard vamos a poder hacer seguimiento del rendimiento de una consulta en concreto que nosotros elijamos.

Objetivos de la optimización en QueryStore

El fin principal de esta herramienta no es otro que ayudarnos a mejorar el rendimiento de nuestras consultas. Es importante remarcar, que una buena optimización no solo mejorará los tiempos de nuestros procesos sino que, además, reducirá el consumo de recursos permitiéndonos un gran ahorro en infraestructura tanto si tenemos servidores locales como en la nube. En este último escenario, donde el pago por uso parece ya un estándar este ahorro de recursos puede marcar la diferencia entre que nuestro proyecto sea o no rentable.

Conclusión

QueryStore es una gran herramienta que nos va a permitir optimizar el rendimiento de las consultas y ahorrar costes tanto en SQL Server como en Azure SQL. A través de sus diferentes informes vamos a ser capaces de localizar y poner solución a los problemas de nuestro servidor. Espero que este artículo te haya proporcionado una visión profunda del almacén de consultas en SQL Server y Azure. Como siempre, estamos aquí para ayudarte. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, Videos, 1 comentario

¿Sirven de algo los bloqueos de recursos en Azure?

Volvemos con nuestros video blogs esta vez con un vídeo sobre los bloqueos de recursos en Azure. Esta opción nos va  a permitir generar un bloqueo sobre un objeto de Azure para evitar que se pueda borrar. De esta manera, cuando alguien intente borrar nuestra base de datos o instancia gestionada desde el portal de Azure obtendrá un error indicando que el recurso está bloqueado.

Bloqueo de Recursos en Azure

Azure ofrece una característica llamada bloqueos que nos permite proteger nuestros recursos contra modificaciones o eliminaciones accidentales. Los bloqueos de recursos pueden ser aplicados a cualquier recurso de Azure, desde suscripciones y grupos de recursos hasta servicios individuales.

Plano de Control y Plano de Datos

Para entender cómo funcionan los bloqueos de recursos, primero debemos entender la diferencia entre el plano de control y el plano de datos en Azure.

El plano de control es responsable de las operaciones de gestión en Azure. Esto incluye acciones como la creación, modificación y eliminación de recursos. Cuando aplicamos un bloqueo de recursos, estamos interactuando con el plano de control.

Por otro lado, el plano de datos se encarga de las operaciones que se realizan en los recursos una vez que están creados. Esto incluye acciones como la lectura y escritura de datos en una base de datos o el envío de mensajes a través de un bus de servicio. Este plano de datos queda fuera del «paraguas» de protección de los bloqueos de recursos.

Aplicando Bloqueos de Recursos

Los bloqueos de recursos se pueden configurar para permitir solo lecturas o para evitar todas las modificaciones. Un bloqueo de solo lectura permitirá que los usuarios vean y consulten los recursos, pero no podrán hacer cambios. Un bloqueo de no modificación, por otro lado, evitará cualquier cambio en el recurso, incluyendo la eliminación.

Conclusión

La protección de nuestros recursos en Azure es esencial para mantener la integridad y seguridad de nuestros datos. Los bloqueos de recursos nos ofrecen una forma eficaz de prevenir borrados y modificaciones no deseadas, asegurando que nuestros recursos permanezcan seguros y protegidos. Sin embargo, esto debe ser combinado por una buena política de permisos en SQL Server o, de lo contrario una operación desde el plano de datos acabará con nuestros sistemas.

Recuerda, como administradores de bases de datos, nuestra prioridad es siempre la seguridad y la protección de nuestros recursos. Asegúrate de utilizar todas las herramientas a tu disposición para mantener tus recursos de Azure seguros. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Videos, 0 comentarios

Configurar planes de mantenimiento en SQL Server y Azure

Hola a todos y bienvenidos a este nuevo formato de Video Blog que espero que os guste y que podamos ver por aquí más a menudo. Hoy vamos a ver un caso práctico sobre como configurar planes de mantenimiento en nuestro SQL Server o instancia administrada en Azure gracias a los script de Ola Hallengren. En todo este tiempo como DBA (más de 10 años) os aseguro que más del 90% de las incidencias por supuestos problemas de rendimiento a las que me he enfrentado eran siempre por lo mismo, una falta de mantenimiento correcto. Por esto es importante programar tareas de reconstrucción de índices y mantenimiento de estadísticas. Y ya de paso, aprovechamos y configuramos las copias de seguridad y comprobaciones de integridad que también nos ofrece esta solución gratuita. Pocas veces vas a encontrar más por menos.

Guía de capítulos

  • 00:00 Introducción
  • 00:39 Descarga
  • 01:20 Instalación
  • 05:42 Backups
  • 10:15 Integrity Check
  • 11:42 Index Optimize
  • 13:13 Limpieza
  • 13:54 Log de procesos

Configurar planes de mantenimiento

Como podemos ver en el vídeo para descargar los scripts de mantenimiento solo deberemos acudir a la web de Ola Hallengren y descargar el script que se llama «MaintenanceSolution.sql». Con el script ya abierto en nuestro SSMS podremos configurar la base de datos donde se van a crear los scripts y una serie de configuraciones importantes para los jobs.

Una vez instalada la solución de planes de mantenimiento vamos a poder configurar en los distintos jobs las tareas de copias de seguridad, supervisión de la integridad y reconstrucción y actualización de índices y estadísticas para las bases de datos de sistema y de usuario. También es importante que configuremos los trabajos que incluyen las tareas de mantenimiento para no encontrarnos con incidencias de espacio en disco en un futuro.

Esta solución, además, tiene la ventaja de dejar un log bastante completo en una tabla llamada CommandLog que estará en la misma base de datos que hayamos creado los procedimientos almacenados de mantenimiento. En esta tabla podremos encontrar todo el historia de ejecuciones de todos los comandos con su detalle, horas de inicio y de fin y, por supuesto, si ha dado un error veremos el por qué.

Publicado por Roberto Carrancio en Cloud, SQL Server, Videos, 0 comentarios