Roberto Carrancio

Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.
Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.

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

¿Cómo no hacer un DWH? (Parte 1 de 2)

Hoy vamos a viajar al pasado para recuperar un artículo de Ralph Kimball escrito en 2001 pero que aún, 23 años después, sigue estando muy presente. El artículo recoge los 12 errores más comunes (y más perjudiciales) que se cometen a la hora de diseñar un DataWareHouse (DWH). Si ya tienes experiencia en este tipo de entornos vas a notar que son errores que a menudo podemos cometer pero que necesariamente tenemos que corregir al poco tiempo. En estos entornos no valen las cosas a medias, para un buen rendimiento es necesario hacer las cosas bien desde el principio o la bola crecerá tanto que será ingestionable.

¿Qué es un DWH?

Empecemos por el principio, un almacén de datos, datawarehouse o DWH es un sistema diseñado para almacenar y, posteriormente, analizar datos. No es un sistema cualquiera y tiene sus particularidades ya que en él, vamos a integrar todos los datos de los distintos orígenes de nuestra organización, incluso de orígenes externos. Por ejemplo, en nuestro DWH tendremos los datos de nuestra aplicación de ventas, contabilidad, tienda web y, en ocasiones, incluso la base de datos de artículos de nuestros proveedores.

Banner-Telegram

Los DWH se caracterizan por contener grandes cantidades de información histórica permitiendo a los analistas de datos realizar análisis temporales y crear predicciones de tendencias a futuro. Como podrás imaginar, para que todo esto funcione, tiene que estar todo muy organizado, estructurado y optimizado para el acceso y análisis rápido de la información. Gracias a procesos ETL (extracción, transformación y carga por sus siglas en inglés) vamos a cargar las tablas de dimensiones y de hechos del modelo de estrella de nuestro DWH,

Errores comunes cuando creamos un DWH

Ahora si, después de esta pequeña introducción vamos al lío, estos son los doce errores más comunes definidos por Kimball.

Error 12: Incluir campos de texto en tablas de hechos para filtrar u ordenar

En un modelo dimensional, las tablas de hecho y de dimensiones se diferencian por contener indicadores numéricos y atributos respectivamente. A veces, la clasificación de un dato puede ser ambigua, como la hora de una venta o el nombre del transportista que nos entrega un pedido. En caso de duda, os recomiendo evitar textos largos en las tablas de hecho para optimizar el espacio y el rendimiento, y considerar como dimensión cualquier dato compartido entre varias tablas de hecho. Al fin y al cabo el almacenamiento es barato en precio pero costoso a la hora de leerlo, las tablas de hechos pueden llegar a tener millones de registros y debemos evitar poner en ellas cualquier texto que pueda ser común a varias tablas o registros. Eso será siempre una dimensión.

Error 11: Escatimar en la información de nuestras dimensiones para ahorrar espacio.

La información es poder y aunque en este momento podamos pensar que no necesitamos ciertos datos y que podemos prescindir de ellos siempre es importante guardarlos por si en un futuro los necesitamos. Esa es la idea detrás de las primeras capas bronce de los data lakes pero, llevado al caso que nos ocupa, en nuestro DWH es una buena idea almacenar esa información si se refiere a dimensiones. El tamaño de las tablas de dimensiones con cientos o pocos miles de registros será despreciable al lado de las grandes tablas de hechos con millones de registros por lo que no debemos preocuparnos por ese aspecto. Otra cosa será que saquemos los datos en la capa de presentación si no se nos solicita pero tenerlo siempre será una buena idea.

Error 10: Dividir las jerarquías y en varias dimensiones

Las dimensiones se agrupan en jerarquías que tienen una relación de uno a muchos. En un país existen muchas provincias y en cada una de esas provincias muchas poblaciones. Cada población a su vez tiene muchos clientes. Podemos pensar en que es una buena idea tener las tablas normalizadas como nos enseñaron en la universidad y crear una tabla por cada una de esas dimensiones.

Eso es lo idea para un modelo transaccional pero cuando hablamos de un DWH donde las lecturas priman sobre las escrituras y el almacenamiento, en la última capa de nuestro DWH el modelo debe ser puramente de estrella y no de copo de nieve por lo que en una sola tabla para esa jerarquía. Es importante aquí destacar de esta última frase la referencia a esa última capa que consumen los reportes ya que nuestro DWH tendrá otras capas inferiores donde sí tendremos normalizados los datos.

Error 9: No enfrentar las dimensiones lentamente cambiantes

Ya explicamos en nuestro artículo sobre el modelo de estrella lo que es una dimensión de variación lenta o lentamente cambiante. Es importante que anticipemos estos cambios desde el inicio del diseño de nuestro modelo o en un futuro tendremos problemas. Por ejemplo, no os imagináis el caos que se me montó una vez a mi cuando un NIE de un cliente extranjero cambió a DNI al obtener la nacionalidad y yo no había pensado que ese dato era cambiante. 

Error 8: No crear foreign keys específicas en tu DWH

En ocasiones podemos pensar que un valor intrínseco de nuestras dimensiones puede actuar como clave y cometemos el error de no crear una clave dedicada para esos registros. Sin embargo, a la larga eso puede llegar a ser un problema y para evitarlo es aconsejable crear nuestros propios identificadores numéricos para los registros de nuestras dimensiones y enlazar con ellos las tablas de hechos. Pensad en el ejemplo del error anterior, el NIE o DNI puede parecer un identificador personal válido pero cuando no lo es puede ser un verdadero quebradero de cabeza. 

Error 7: Añadir dimensiones a la tabla de hechos del DWH

Esto puede parecer básico, pero si ya os habéis enfrentado a varios modelos de DWH sabréis que es más común de lo que parece. En un modelo de estrella todas las dimensiones deben estar en sus tablas de dimensiones y las tablas de hechos solo deben tener relación con esas dimensiones o jerarquía. Caer en este error nos llevará a un mayor tamaño de nuestra tabla de hechos lo que repercutirá directamente en el consumo de E/S de nuestras consultas y empeorará el rendimiento.  

Conclusión

Hemos visto la mitad de los errores más comunes descritos por Kimball, como el artículo si no iba a quedar muy grande vamos a dejar los 6 siguientes errores (y los más graves) para una segunda parte. Espero que os esté gustando, que os sea de utilidad y por supuesto que a partir de ahora no caigáis en estos errores. Si al leer esto has pensado en algo que tienes mal en tu DWH solucionalo antes de que sea tarde, vas a ver que, a la larga, la ganancia es sustancial. 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 Rendimiento, 1 comentario

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

JOIN: La guía definitiva

¿Sabes qué son y cuándo usar cada tipo de JOIN? Esta es la base de cualquier consulta SQL que empieza a volverse compleja. Seguro que a ninguno os sorprende que os diga que, hoy en día, el conocimiento de SQL es una de las habilidades más demandadas en el mercado laboral. Cualquiera que trabaje con datos, a casi cualquier nivel, va a necesitar en algún momento consultar información y en este aspecto el lenguaje SQL es clave. No solo lo usan todas las bases de datos relacionales, sino que hasta las bases de datos NoSQL o descentralizadas han terminado admitiendo este lenguaje de consultas. O, al menos, un  lenguaje “SQL Like” para la consulta de sus datos no estructurados o semiestructurados.

Por todo esto, se hace muy importante para los profesionales de datos tener la capacidad de escribir consultas complejas con cláusulas JOIN que nos permitan unir la información de varias tablas. 

Joins en SQL

Los joins en SQL son la base de cualquier consulta compleja. Como su propio nombre indica, nos permiten combinar filas de dos o más tablas basándonos en una columna relacionada entre ellas. Suele ser una Foreing Key pero realmente no es necesario que exista esa restricción entre las tablas para hacer la consulta con un join. 

Banner-Telegram

Tipos de Join

Como hemos podido ver, los joins son una de las cláusulas más importantes que podemos usar en nuestra consulta de SQL. Además existen varios tipos de joins y cada uno de ellos tiene una función y un uso específico.

INNER JOIN

El INNER JOIN es la operación más básica. Algunos SGBD como SQL Server o Azure SQL admiten la sintaxis JOIN a secas sin especificar el INNER. Con este join seleccionaremos registros que tienen valores coincidentes en ambas tablas. Es el más común de los joins y se utiliza con frecuencia para combinar filas de dos o más tablas.

LEFT (OUTER) JOIN

El LEFT JOIN nos devuelve todos los registros de la tabla izquierda y los registros coincidentes de la tabla derecha. Si no hay una coincidencia, el resultado es NULL en el lado derecho.

RIGHT (OUTER) JOIN

El RIGHT JOIN nos va a devolver todos los registros de la tabla derecha y los registros coincidentes de la tabla izquierda. Si no hay una coincidencia, el resultado es NULL en el lado izquierdo.

FULL (OUTER) JOIN

El FULL JOIN devuelve todos los registros cuando hay una coincidencia en cualquiera de las tablas izquierda o derecha. Si no hay una coincidencia, el resultado es NULL en ambos lados.

Usos avanzados de JOINS

Además de los usos básicos de JOIN que ya hemos visto, podemos combinarlos con el uso del filtro IS NULL para obtener otro tipo de datos. Por ejemplo combinando LEFT JOIN 

con un filtro ISNULL cuando la clave de la tabla derecha es nulo podremos sacar solo los registros de una tabla que no tienen relaciones con otra. Igual pero al revés podemos hacerlo con RIGHT JOIN. Combinando un FULL JOIN con un filtro que nos garantice que las claves por las que enlazamos son nulas podremos sacar los registros de ambas tablas que no tienen relación con la otra.

Se que todo esto os puede parecer un poco lioso así contado pero seguro que con esta infografía lo vais a ver más claro. Ya sabéis, una imagen vale más que mil palabras (600 a estas alturas del artículo 🤣 ).

join

Escrituras con JOINS

Esto no sería la guía definitiva de los joins si no mencionamos también la sintaxis de las operaciones de escritura. Obviamente no tiene sentido unir varias tablas en una consulta de inserción ya que los insert son en una sola tabla pero sí que podremos querer actualizar o borrar datos de una tabla cruzando con otras para asignar un valor presente en otra tabla o para alguna validación extra. 

Update con JOIN

Es un escenario bastante común, en ocasiones queremos actualizar un valor de una tabla tal como lo tenemos en otra. Para eso podemos hacer un update con join tal como vemos aquí.

Como veis en este caso, tenemos una tabla de backup y queremos restaurar el valor de CustomerID desde el backup. Este es uno de los usos más comunes de este tipo de sintaxis.

Delete con JOIN

Existen varios escenarios en los que vamos a necesitar un join en una clausula delete. El más sencillo será borrar los registros de una tabla que tengan coincidencia en otra tabla. Sin embargo también podemos, por ejemplo, querer borrar solo los registros que no existen en la segunda tabla. Vamos a ver estos y otro ejemplo extra

Ejemplo sencillo de borrado de registros de una tabla origen que tengan coincidencia en una tabla filtro. En este caso vamos a borrar todos los pedidos de clientes con una nacionalidad en concreto:

Otro ejemplo muy común como ya hemos visto es el de borrar datos de una tabla que no tengan relaciones con otras. Por ejemplo, queremos borrar todas las líneas de una factura que no tengan cabecera.

Por último, para cerrar ya esta guía vamos a ver un ejemplo especial que no todos los sistemas de bases de datos admiten que es el uso de join para borrados en cascada. Esta sintaxis, no la vais a poder usar en SQL Server o Azure SQL pero si, por ejemplo, en MySQL.

Conclusión

Los joins son una herramienta esencial en SQL que nos permite combinar datos de diferentes tablas de manera eficiente. Aunque puede parecer complicado al principio, con práctica y experiencia, se convertirán en una parte integral de tus consultas SQL. No en vano son imprescindibles para todo DBA o trabajador de datos. Recuerda, la mejor manera de aprender es practicando, usa tus datos de demo para hacer pruebas e interiorizar los conceptos. 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, SQL Server, 0 comentarios

Descifrar contraseñas de usuarios de SQL

En el video de hoy vamos a ver como funciona la función PWDCOMPARE. Como sabeís SQL Server almacena las contraseñas de los usuarios en un hash que podemos ver pero no descifrar. Aquí es donde entra en juego PWDCOMPARE, gracias a esta poderosa función de SQL Server vamos a poder comparar los hash de contraseñas almacenados en SQL Server con cadenas de caracteres en texto plano. Esto nos va a permitir simular ataques de diccionario o fuerza bruta para comprobar la seguridad de las contraseñas nuestros usuarios.

Dejadme en comentarios si os interesa que dediquemos un post a crear un script para validar automáticamente las palabras de un diccionario, los nombres de los usuarios y del servidor como contraseñas y así auditar mejor la seguridad de vuestra instalación de SQL Server o Azure SQL.

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

Optimización de Consultas con OPTION RECOMPILE

Cuando hablamos de consultas sobre las bases de datos, la eficiencia es clave. Como DBAs siempre buscamos formas de mejorar el rendimiento de las consultas. Pero no solo nosotros, los DBAs, nos vemos en esta necesidad, cualquier desarrollador que trabaje con bases de datos también debe perseguir el mismo objetivo. En este contexto, a veces, la solución puede ser tan simple como usar la sugerencia de consulta OPTION RECOMPILE. Pero, ¿qué es exactamente y cómo puede ayudarnos en SQL Server y Azure SQL? ¿Realmente es una solución mágica que podemos usar siempre como una carta comodín? Durante estas líneas voy a tratar de dar respuesta a estas preguntas.

¿Qué es OPTION RECOMPILE?

OPTION RECOMPILE es una directiva que podemos agregar al final de nuestras consultas en SQL Server para indicar que queremos que se recompile el plan de ejecución cada vez que se ejecuta la consulta. Esto puede ser útil en situaciones donde los datos subyacentes cambian con frecuencia y queremos asegurarnos de que estamos utilizando el plan de ejecución más eficiente posible.

Banner-Telegram

¿Cómo funciona OPTION RECOMPILE?

Para entender este concepto, es importante recordar algunos de los conceptos que hemos discutido en artículos anteriores. En concreto hablo de los planes de ejecución de las consultas y de la caché de planes de ejecución.

Planes de ejecución

En nuestro artículo sobre planes de ejecución, exploramos cómo SQL Server y Azure SQL crean y utilizan estos planes para llevar a cabo las consultas de manera eficiente. Estos planes son esenciales para entender cómo OPTION RECOMPILE puede mejorar el rendimiento de nuestras consultas.

Caché de planes de ejecución

Además, en nuestro artículo sobre la caché de planes, vimos cómo SQL Server y Azure SQL almacenan los planes de ejecución para su reutilización. Este almacenamiento en caché puede ser muy eficiente, pero también puede llevar a problemas si los datos subyacentes cambian con frecuencia, lo que nos lleva de nuevo a la utilidad de OPTION RECOMPILE.

Option Recompile

Ahora sí, vamos a dar respuesta a la pregunta ¿cómo funciona OPTION RECOMPILE?

Ya sabemos que la primera vez que ejecutamos una consulta en SQL Server o Azure SQL, el motor de la base de datos crea un plan de ejecución. Este plan es básicamente una serie de pasos que la base de datos seguirá para recuperar los datos solicitados. Una vez que se ha creado un plan, además de usarse para la consulta en curso, se almacena en caché para su uso en futuras ejecuciones de la misma consulta. 

Sin embargo, esto que la mayoría de las veces es una ventaja, puede no serlo si los datos subyacentes cambian significativamente. En estos casos el plan almacenado en caché puede no ser el más eficiente. También puede pasar que las estadísticas de la tabla no estuvieran bien actualizadas al momento de compilar el primer plan de ejecución y no este sea del todo correcto. Aquí es donde entra en juego OPTION RECOMPILE. Al agregar esta directiva a nuestra consulta, le estamos diciendo al motor de base de datos de SQL Server que ignore cualquier plan almacenado en caché y genere uno nuevo. 

Esto no quiere decir que se vaya a usar un plan de ejecución distinto, simplemente el motor de base de datos va a analizar todas las opciones posibles para resolver la consulta y a elegir el que le parezca más óptimo. Puede ser que vuelva a elegir el mismo, sobre todo si tenemos un problema con las estadísticas.

¿Cuándo deberíamos usar OPTION RECOMPILE?

Aunque OPTION RECOMPILE puede ser una herramienta poderosa, no siempre es la mejor opción. La recompilación de un plan de ejecución tiene un coste en términos de recursos, en concreto en consumo de CPU, por lo que si una consulta se ejecuta con mucha frecuencia, el coste de la recompilación puede superar cualquier beneficio de rendimiento que obtengamos.

Por lo tanto, OPTION RECOMPILE es más adecuado para consultas que se ejecutan con poca frecuencia, pero que son críticas para el rendimiento, o para consultas donde los datos subyacentes cambian con tanta frecuencia que un plan almacenado en caché se vuelve ineficiente rápidamente. En esta línea, otro posible escenario son las consultas de procedimientos almacenados que interactúan con datos con gran variación entre un parámetro y otro. Para estos casos de gran desigualdad en los volúmenes de datos puede ser una gran alternativa a la utilización tradicional de planes en caché.

Personalmente también me gusta mucho utilizar esta opción de consulta cuando me enfrento a un problema de rendimiento de una consulta. En estas situaciones puede ser de gran ayuda, localizar a tiempo que el problema está en un plan de ejecución no óptimo cacheado puede ahorrarnos mucho tiempo y esfuerzo en la optimización.

Conclusión

En resumen, OPTION RECOMPILE es un truco muy potente y valioso en nuestra caja de herramientas de optimización de consultas. Aunque no es una solución para todos los problemas de rendimiento, y hay que medir muy bien su uso para no caer en problemas mayores, puede ser extremadamente útil en las circunstancias adecuadas. Como siempre, la clave es entender cómo funciona y cuándo usarlo. Y como digo siempre, solo plantéate este tipo de soluciones si realmente tienes un problema, las soluciones “por si acaso” nunca suelen ser una buena idea.  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 Rendimiento, SQL Server, 0 comentarios