Cloud

CONTROLAR EL TAMAÑO DE NUESTRAS BASES DE DATOS

Controlar diariamente el tamaño de nuestras tablas y los ficheros de bases de datos es clave para poder afrontar en el futuro una posible incidencia de espacio en disco. Gracias a esta monitorización en nuestro SQL Server vamos a poder localizar que base de datos y que tabla es la que ha crecido hasta llenar el disco y provocarnos una incidencia. En ocasiones una tabla crece sin control hasta llenar el disco y gracias a esta monitorización del tamaño de las bases de datos y las tablas nos va a ser muy sencillo de localizar. No esperes a que sea tarde y no tengas las herramientas necesarias, monitoriza desde ya tus ficheros.

A continuación te dejo los scripts que he usado para monitorizar el tamaño en el video, recuerda adaptarlos a tu base de datos de monitorización y, en caso de ser necesario, cambiar la verificación de las tablas por un código compatible con tu versión de SQL (pídeme ayuda en los comentarios del video si lo necesitas).

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

Masterclass Niveles de Aislamiento en SQL Server

Como ya os anuncié la semana pasada, la madrugada del pasado jueves 23 (hora española) tuvo lugar el evento Noches de DBAs en el que, invitado por Alberto de Rossi, pude dar una masterclass sobre niveles de aislamiento en SQL Server para la comunidad Power BI User Group de Lima. Por suerte para todos, esta masterclass está grabada y publicada abiertamente en YouTube. A continuación os comparto la grabación y las diapositivas que vimos en la sesión.

Como sabéis, los niveles de aislamiento y los bloqueos son uno de los temas que más hemos tratado en el blog por lo que a continuación os voy a dejar varios de los artículos en los que podéis profundizar para encontrar más información sobre el tema:

Espero que os haya gustado esta sesión, y que sea la primera de muchas. Dejad vuestro me gusta y comentario para que desde la comunidad nos tengan en cuenta. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

¿Por qué NO debes USAR NoLOCK en tus consultas SQL?

En ocasiones podemos pensar en un nivel de aislamiento read uncommitted o en el uso de la clausula NoLOCK como la solución a nuestros problemas de bloqueos. Si a ti también te ha pasado este video es para ti. Vamos a ver como su uso tiene muchos riegos y hay resultados inesperados que, para mi, hacen que no sea la mejor de la soluciones.

Espero que te haya gustado esta demostración rápida de los problemas a los que nos podemos enfrentar por usar NoLOCK. Ahora que ya conoces los riegos te recomiendo valorar una solución como Read Committed Snapshot para tus transacciones. Si quieres saber más de niveles de aislamiento te recomiendo nuestros post sobre niveles de aislamiento, niveles de aislaminto – casos prácticos y el uso de nolock.

Banner-Telegram

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

Estimación de Cardinalidad en SQL Server

Como DBAs siempre nos encontramos en una constante búsqueda de optimización y mejora del rendimiento de nuestras bases de datos. Esto, antes o después nos lleva a encontrarnos con  un concepto fundamental pero que puede resultar complicado al principio: la estimación de cardinalidad. Este concepto, aunque pueda parecer magia interna de SQL Server, es esencial para entender cómo el motor de base de datos de SQL Server decide el mejor plan de ejecución para ejecutar nuestras consultas. Es decir, es la clave para elegir el camino más óptimo para resolver lo que le hemos pedido.

Estimación de Cardinalidad

Como hemos adelantado ya en la introducción ,la estimación de cardinalidad es el proceso mediante el cual SQL Server trata de predecir el número de filas a las que va a afectar una consulta. No sólo calcula el número total de filas afectadas sino que lo hace con una granularidad total, calculando cuántas filas pasarán por todos y cada uno de los distintos componentes de los planes de ejecución posibles para resolver la consulta. Este número, también conocido como cardinalidad, es crucial para el optimizador de consultas, ya que sin esta información el motor de base de datos no podría elegir el plan de ejecución más eficiente. SQL Server utiliza estadísticas para realizar estas estimaciones de cardinalidad. 

Estadísticas en SQL Server: La base de la cardinalidad

Como acabamos de ver, el optimizador de consultas utiliza las estadísticas para estimar la cardinalidad. Por ejemplo, si estamos buscando registros de en una tabla donde la columna ‘edad’ es mayor que 30, SQL Server utilizará las estadísticas para estimar cuántos registros cumplen con este criterio. Pero, ¿cómo funciona exactamente?

Las estadísticas en SQL Server son objetos que almacenan información sobre la distribución de los valores en una o más columnas de una tabla o vista indexada. Cada objeto de estadísticas está compuesto por un histograma que describe la distribución de los valores, y un vector de densidad que contiene información sobre la correlación de los valores en las columnas.

SQL Server crea y actualiza automáticamente las estadísticas para las columnas indexadas en nuestras tablas y vistas. También podemos crear estadísticas para columnas no indexadas utilizando el comando CREATE STATISTICS, o podemos actualizar las estadísticas existentes utilizando el comando UPDATE STATISTICS.

Es importante tener en cuenta que las estadísticas pueden volverse obsoletas a medida que los datos en nuestras tablas cambian. Cuando esto sucede, las estimaciones de cardinalidad basadas en estas estadísticas pueden ser inexactas.  Esto puede llevar a SQL Server a elegir un plan de ejecución subóptimo, lo que puede resultar en un rendimiento deficiente de la consulta. Otro de los problemas comunes, aunque el plan de ejecución sea el correcto es una asignación de recursos no óptima para la resolución de las consultas lo que puede llevarnos a una profunda degradación de rendimiento.

Planes de Ejecución: El resultado de la estimación de cardinalidad

Un plan de ejecución es, en resumen, una serie de pasos que SQL Server sigue para ejecutar una consulta. Cada paso en el plan de ejecución tiene su propio componente que representa una operación atómica, como un escaneo de tabla, un join, o una operación de ordenación.

El optimizador de consultas de SQL Server utiliza las estadísticas para estimar la cardinalidad y elige el plan de ejecución que tiene el menor costo estimado. El costo de un plan de ejecución se mide en términos de la cantidad de recursos que se espera que consuma, como la CPU, la E/S de disco, y la memoria RAM.

Podemos ver el plan de ejecución de una consulta utilizando la opción SET SHOWPLAN_ALL ON. Esto nos proporcionará una representación gráfica del plan de ejecución, junto con información detallada sobre cada operación en el plan.

No vamos a profundizar mucho más en este sentido pues ya le hemos dedicado a este tema este artículo completo en este blog.

Conclusión

La estimación de cardinalidad es un aspecto esencial en la optimización de consultas en SQL Server. Aunque puede parecer un concepto complejo, entender cómo funciona puede ayudarnos a mejorar significativamente el rendimiento de nuestras bases de datos.

Es importante recordar que las estadísticas, que son la base de la estimación de cardinalidad, deben mantenerse actualizadas para garantizar estimaciones precisas. Como siempre, la clave está en conocer nuestras bases de datos, entender cómo se utilizan y aplicar este conocimiento para optimizar su rendimiento.

En resumen, la estimación de cardinalidad es una herramienta poderosa en nuestras manos. Con un buen entendimiento de cómo funciona, podemos hacer que nuestras bases de datos trabajen de manera más eficiente y efectiva. ¡Sigamos aprendiendo y mejorando juntos!

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, 0 comentarios

Recrear logins para Always On

Cuando movemos bases de datos entre entornos o, a la hora de tener un Always On moviendo bases de datos entre distintos servidores SQL Server, es común encontrarse con un problema de usuarios huérfanos ya que los sid de los logins pueden diferir entre los distintos servidores. Para evitar este problema vamos a usar el procedimiento almacenado sp_help_revlogin y así crear los logins con el mismo sid y contraseña.

Ahora ya sabes como recrear tus logins para no tener problemas de usuarios huerfanos en un grupo de alta disponibilidad Always On o cuando mueves bases de datos entre servidores. Recuerda también que tenemos un artículo explicando «como prevenir usuarios huérfanos» en el que explicamos otros métodos para evitar este problema.

Banner-Telegram

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

Importar y exportar de Excel a SQL en vídeo

En este octavo Video Blog vamos a ver de forma práctica una de las entradas del blog www.soydba.es que mejor resultado ha tenido y que más os interesa. La importación de Excel a SQL Server y viceversa. Excel es una de las herramientas para consumo de datos más utilizadas del mundo y en multitud de ocasiones nos veremos en la necesidad tanto de importar datos de Excel a SQL como al revés, de exportar de SQL a Excel. Gracias al asistente de import / export integrado en el SSMS esta tarea será casi como un juego de niños.

El asistente que hemos podido ver en el vídeo es muy versatil y no solo nos va a permitir importar o exportar datos entre SQL y Excel sino que también entre SQL y SQL u otros origenes o destinos como archivos de texto plano, CSV u otras bases de datos (siempre que tengamos los drivers correctos en el equipo).

Banner-Telegram

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

Perform volume maintenance tasks

Muchos me habéis preguntado por el permiso “Perform volume maintenance tasks” o “Realizar tareas de mantenimiento del equipo” por el que pregunta SQL Server al instalarse. Hay quien me ha dicho que siempre lo marca, otros que nunca pero en general existe cierto desconocimiento sobre sus pros y sus contras y lo que es más importante sobre lo que hace o no este permiso de Windows. En el artículo de hoy vamos a tratar de responder estas dudas.

Inicialización de archivos de base de datos

Seguramente te suene este concepto, la inicialización de archivos de base de datos es el proceso por el que SQL Server crea y dimensiona los archivos de bases de datos y logs ya sea de manera manual o con el crecimiento automático. Desde los inicios del SQL moderno que conocemos hoy en día (SQL 2005) esto implica crear o redimensionar los ficheros para reservar ese espacio para la base de datos. Durante este proceso SQL Server pone a 0 todos los sectores del disco duro a nivel físico para posteriormente ir rellenandolos con datos. Esto es un proceso lento y pesado que demora las operaciones de escritura, por eso las buenas prácticas siempre recomiendan tener todos los ficheros dimensionados previamente a la hora de trabajar para evitar el crecimiento automático.

Banner-Telegram

Ahora bien, existe una excepción que nos permitirá saltarnos este paso y dimensionar los ficheros de datos sin tener que modificar los sectores del disco para establecerlos a 0 y es lo que se conoce como inicialización instantánea de base de datos gracias al privilegio “perform volume maintenance task”. Esto también afecta a los archivos de base de datos de Analysis Service. Esta configuración también se aplica en los ficheros de log desde SQL Server 2022 y está disponible también en las bases de datos y en las instancias administradas de Azure. 

Perform volume maintenance tasks

Este permiso, asignado por directiva de windows por defecto a los usuarios administradores del equipo, permite realizar las tareas de mantenimiento típicas sobre los discos duros tales como desfragmentar, crear y modificar nuevos volúmenes o ejecutar el asistente de limpieza. Esto es lo que dice la teoría, pero como hemos visto, a nosotros como DBAs nos interesa porque es lo que nos va a permitir la inicialización instantánea de los archivos de bases de datos.

Consideraciones de seguridad

Como hemos visto, esta política por defecto otorga el permiso a los administradores del equipo, sin embargo, vosotros que sois buenos DBAs, sabréis que no es conveniente que la cuenta de servicio de SQL Server sea administradora local. O eso dicen las buenas prácticas de seguridad. 

Además, ten en cuenta que, gracias a este permiso es posible ver el valor de los sectores de disco y recuperar información eliminada, lo que también puede ser un problema de seguridad. En este sentido, tendremos que valorar junto con el equipo de ciberseguridad de nuestra empresa, la ganancia que vamos a sacar de este privilegio frente a los posibles riesgos de seguridad.

Por un lado, si tenemos bien dimensionados los archivos de datos para nuestro crecimiento y podemos hacer redimensionamiento manuales en ventanas de mantenimiento fuera de las horas de mayor carga de trabajo es probable que no sea necesario. Si esto no es así y tenemos muchos crecimientos automáticos sin, además, tener este privilegio concedido, podremos experimentar grandes caídas del rendimiento e incluso encontrarnos en el log de errores de SQL los errores 5144 y 5145 de timeout al redimensionar los ficheros. En estos casos será recomendable conceder el permiso siempre reduciendo al mínimo los riesgos de seguridad, por ejemplo, usando para SQL Server cuentas de servicio administradas gMSA.

Como asignar el permiso Perform volume maintenance tasks

Ahora que ya sabes lo que implica la asignación de este privilegio de Windows vamos a ver como concederlo. Como ya hemos visto, durante la instalación tenemos un check que nos lo asignará automáticamente pero, si no lo hemos hecho, o si hemos cambiado la cuenta de servicio de SQL Server, será necesario hacerlo manualmente. Hemos visto que se otorga a través de las directivas de windows por lo que, lo primero que necesitaremos será abrir la consola gpedit.msc. Una vez en el editor de directivas nos iremos a Configuración del equipo – Configuración de Windows – Configuración de seguridad – Directivas locales – Asignación de derechos de usuario. En este apartado encontraremos el permiso “Realizar tareas de mantenimiento del equipo” al que añadiremos nuestra cuenta de servicio de SQL Server. Una vez cambiado esto será necesario reiniciar el servicio de SQL Server para aplicar los cambios.

Perform-volume-maintenance-tasks

Pruebas de rendimiento

Para terminar quiero compartir con vosotros una prueba de rendimiento que he hecho en mi equipo. Para la prueba, sin haber asignado el permiso a la cuenta de SQL, he creado unas bases de datos de 10 Gb de tamaño inicial en 3 discos duros, un M2, un SSD y un HDD. Luego he realizado la misma prueba pero con el privilegio otorgado. Estos son los resultados: 

 M2SSDHDD
CON Inicialización instantánea86 ms127ms852 ms
SIN Inicialización instantánea88 ms174 ms1118 ms

Conclusión

Configurar el permiso para realizar tareas de mantenimiento sobre los volúmenes puede tener mejoras sustanciales en la creación o redimensionamiento de los ficheros de bases de datos. Sin embargo, tiene implicaciones de seguridad que es necesario conocer y valorar previamente. Además, aunque la mejora de rendimiento sea notable, sigue sin ser recomendable confiar en el crecimiento automático, siendo necesario dimensionar previamente los ficheros para evitar problemas. 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, 1 comentario