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.

FizzBuzz (T-SQL Reto). Típico en entrevistas de trabajo

Hoy me he encontrado en LinkedIn con una cosa que me ha llamado la atención, Antonio Jurado había publicado un post en el blog mundo-datos respondiendo a un video de Nacho Cardenal. Este último habría publicado hace unos días la resolución al reto de FizzBuzz en Excel. En los comentarios de su publicación original en LinkedIn, Juan José Luna proponía la solución al reto en Access. A esto se sumó Toni (en la publicación que yo vi) resolviendo el reto en DAX. Así que, no vamos a ser nosotros menos y vamos a resolverlo en SQL, ¿no?

El reto FizzBuzz

El reto FizzBuzz es un sencillo desafío de programación que se emplea en las entrevistas de trabajo técnicas para que el evaluador vea la capacidad de escribir código del candidato. 

Como digo, el reto es sencillo, debes codificar un algoritmo que, con los números del 1 al 100 devuelva la cadena “Fizz” si el número es múltiplo de 3, “Buzz” si es múltiplo de 5 o “FizzBuzz” si es múltiplo de 3 y de 5. 

Esto es lo que buscamos:

FizzBuzz-Resultado

FizzBuzz con T-SQL

Esto es sencillo, tenemos que crear una tabla con los números del 1 al 100 y una columna resultado que será FizzBuzz, Fizz, Buzz o el propio número. Vamos a ello.

Paso 1: Crear la tabla FizzBuzz

El primer paso es crear la tabla FizzBuzz, para ello vamos a comprobar primero si existe y en ese caso la borramos y creamos una nueva. Necesitamos un campo numérico que admita los valores del 1 al 100, con un tinyint nos vale, no vamos a usar más de lo necesario. Para el resultado tendremos que almacenar cadenas de texto pero, no siempre van a tener la misma longitud, podrán ser de 1 a 8 caracteres así que usaremos un varchar(8).

FizzBuzz-1

Paso 2: Cargar la secuencia de números

Con la tabla ya creada vamos a empezar a cargar los datos, lo primero será cargar los números que luego vamos a evaluar. Para ello empezamos con la sintaxis INSERT INTO ya que la tabla existe de antes. A este insert le vamos a pasar el resultado de una función de tabla que se ha introducido nueva en SQL Server 2022, GENERATE_SERIES. Esta función tendrá como primer parámetro el primer número de nuestra cadena, como segundo el último y, opcionalmente, como tercero el número en el que se va a incrementar el contador. Como este tercer parámetro es opcional y si no ponemos nada va de uno en uno lo vamos a omitir.

FizzBuzz-2

Paso 3: Algoritmo FizzBuzz

Llegó el momento de la verdad, hasta ahora solo habíamos preparado el escenario. Tenemos que actualizar nuestra tabla para poner los valores Fizz, Buzz o FizzBuzz cuando sea necesario. Lo primero que tendremos que saber es que en SQL Server podemos usar el operador % para devolver el resto de una división, por lo que si este es igual a 0 será que el número es múltiplo del dividendo que estemos comparando. Una vez tenemos eso resulto nos encontramos con el siguiente reto, para hacerlo de una sola vez tendremos que usar la sintaxis de UPDATE con un CASE dentro de la cláusula SET

Hacer correctamente el case será nuestro tercer desafío, como sabéis, esta operación evalúa las condiciones en orden y si la primera de ellas se cumple ya no va a pasar por las siguientes. Esto hace que si o si tengamos que empezar por el caso de que un número sea múltiplo de 3 y de 5. A continuación ya podremos evaluar que sea múltiplo de 3 o de 5 en orden indistinto. Para terminar tenemos que devolver el mismo valor si no se ha cumplido con ninguna de las tres condiciones anteriores lo que nos puede dar más de un quebradero de cabeza si no estamos atentos. El tipo de datos del valor que estamos evaluando (el número) no se puede insertar en un campo de texto, antes tendremos que convertirlo o nos encontraremos con un error en la ejecución.

FizzBuzz-3

Paso 4: Mostrar los resultados

Ya hemos hecho lo difícil, ahora solo nos queda mostrar los resultados de nuestro trabajo.

FizzBuzz-4

Código de FizzBuzz

Ahora que ya hemos resuelto el desafío te dejo el código completo que he utilizado para que lo puedas copiar, editar e investigar tu mismo otras variaciones.

Conclusión

Así, de una manera sencilla y eficiente hemos resuelto el reto FizzBuzz en T-SQL, espero que te haya servido para aprender aunque sea alguna sintaxis que no conocías. ¿Se te ocurre otra solución posible? ¿Te apetece que hagamos más desafíos de este tipo? Pónmelo en comentarios y lo tendré muy 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 y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 2 comentarios

Reducir el tamaño de bases de datos SQL

En esta ocasión vengo a explicaros como puedes hacer para reducir el espacio que ocupan nuestras bases de datos liberando el espacio libre que hay en los ficheros. Para ello, tendremos que hacer un Shrink de los ficheros de base de datos. Tendrás que hacerlo tanto en el ficheros de datos como en el de log (o en el que sepamos que existe un problema).

Evita siempre que puedas la operación de reducir de ficheros, sobre todo en los ficheros de datos, ya que consume muchos recursos del servidor y además va a empeorar el rendimiento de nuestra base de datos. Si no queda más remedio o si has eliminado tanta información que merezca la pena hacerlo, ten la precaución de programarlo fuera de horas de trabajo y de reconstruir los índices fragmentados una vez termines.

En los ficheros de log, como en los de TempDB no vas a tener los problemas de fragmentación pero si de consumo de recursos por lo que aunque no tengamos que ser tan estrictos si debemos intervenir con la debida precaución.

Puedes encontrar los script que he usado en el video aquí. 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

Migrar de Azure SQL DB a Azure Managed Instance

Te pongo en situación, tu empresa decidió hace tiempo empezar a desplegar servicios en la nube de azure. En una fase inicial del proyecto se decidió usar bases de datos de Azure SQL sin servidor, la gama de entrada a SQL en Azure. Ha pasado el tiempo y se ha descubierto que el proyecto no puede continuar debido a las limitaciones de esta solución SAAS. Hay que migrar las bases de datos.

¿Por qué migrar y donde?

Como ya te he adelantado en la descripción, el problema es que necesitas alguna de las características de SQL Server que no incluyen las bases de datos de Azure SQL. Sin embargo, sí que sigues convencido de que la mejor opción es un producto SaaS administrado en la nube, con un tiempo de disponibilidad del 99,99%, con actualizaciones automáticas, seguridad de datos avanzada y análisis de registros SQL de Azure. Básicamente no tener que administrar una máquina local o virtual IaaS.

Parece que la solución es clara, necesitas una instancia administrada de SQL en Azure. Las características de Azure MI que no tienen las bases de datos de Azure SQL son:

  • Consultas entre bases de datos 
  • Usar las bases de datos como publicadoras en replicación.
  • Copias de seguridad y restauraciones a petición por T-SQL.
  • Compatibilidad con .NET SQL CLR
  • Activadores de ámbito de servidor o triggers de inicio de sesión
  • Captura de datos modificados (CDC) 
  • Acceso a Resource Governor.
  • Agente de SQL.
  • Y más…

¿Cómo no migrar?

En este punto te piden a ti, DBA, llevar a cabo esta migración. Parece una tarea sencilla, ¿verdad? Pues vamos a ver que de eso nada. Como acabamos de ver en el apartado anterior, una de las limitaciones de las bases de datos de Azure SQL es que no permiten copias de seguridad por T-SQL. Aunque si tienen copias de seguridad automáticas por parte de Azure, estas solo se pueden restaurar como otra base de datos de Azure SQL, no las vas a poder llevar a una instancia.

Tampoco vas a poder usar una base de datos de Azure SQL como origen de datos en Azure Data Migration Service (DMS) ni en Data Migration Assistant (DMA). Y esto no es todo, tampoco admiten DB Mirroring, AlwaysOn, Log Shipping o Replicación. Estás perdido, solo te queda implementar una solución de copia de datos manual con T-SQL, SSIS o Azure Data Factory lo que te va a suponer mucho esfuerzo y una sobrecarga de trabajo difícil de asumir. Pero, no te preocupes, yo te voy a contar cómo hacerlo de manera fácil.

¿Qué opciones tienes?

Visto lo visto, partiendo de las premisas anteriores lo primero que tienes que asumir es que esto va a ser un proceso manual. Podrías automatizarlo con las alternativas que hemos mencionado antes de T-SQL, SSIS o Data Factory pero eso no es lo que buscas. Necesitas una solución simple, mover los datos y ya está. Para eso tenemos dos opciones o usar el asistente de Import/Export con SSIS en SSMS o usar el asistente para importar/exportar aplicaciones de capa de datos, también en SSMS.

Asume que durante la migración vas a tener un tiempo de inactividad total de las bases de datos. Realmente vas a poder seguir leyendo la base de datos Azure SQL de origen pero si haces cambios es posible que luego no los veas replicados en la Azure MI. 

Ahora bien, puedes reducir el tiempo de inactividad migrando las tablas por partes siempre que tu aplicación lo permita. Si tienes unos datos “frios”, una especie de diccionarios con pocos o ningún cambio puedes migrar esas primero sin parar la aplicación para luego reducir el tiempo al migrar solo el resto de tablas.

Migrar con el asistente de import/export de SSIS en SSMS

Este asistente, lo puedes ejecutar desde SSMS y genera un paquete de SSIS básico para la copia de datos. OJO, solo para la copia de datos. Si las tablas no existen si que las va a crear pero no va a crear ningún otro objeto, ni siquiera los índices. No, ni los índices clustered ni las PK ni nada. Por supuesto tampoco va a crear vistas, triggers, funciones, procedimientos, etc…

Paso 1

Como este asistente solo copia datos lo primero que tienes que hacer es crear en tu instancia administrada de Azure la base de datos con todos los objetos de la base de datos. Sin embargo, en este punto no te recomiendo crear ni los triggers ni las Foreign Keys para evitar problemas con la copia de datos. Para generar los script de creación de objetos puedes usar el asistente que incluye el propio SSMS.

migrar 1

Paso 2

Ahora que ya tienes toda la estructura de tu base de datos creada en Azure MI puedes usar el asistente de importación y exportación para copiar los datos. No vamos a profundizar en este punto porque ya lo hemos explicado en este artículo y en este vídeo. Solo vas a tener que elegir el origen y el destino correctos.

Paso 3

Ahora que ya tienes todos los datos copiados es el momento de crear los triggers y las FK que antes hemos dejado pendientes. También debes validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.

Migrar con el asistente de import/export de aplicaciones de capa de datos en SSMS

Este asistente, lo puedes ejecutar desde SSMS y genera un archivo bacpac que luego vas a poder importar sobre la base de datos de tu instancia administrada usando el mismo asistente. Es muy parecido a una copia de seguridad tradicional aunque no es exactamente lo mismo. Vas a ver que los pasos son muy simples.

Paso 1

A diferencia del anterior, este asistente no solo copia datos sino que te va a migrar también los objetos. Además, para importarlo, solo vas a poder hacerlo sobre una base de datos nueva así que en este paso vas a exportar directamente los datos de origen en formato bacpac desde tu SSMS. Haz clic derecho sobre la base de datos, ve al menú tareas y ahí a la opción Exportar aplicación de capa de datos…

migrar 2

Paso 2

Es el momento de restaurar en el destino. Conectate con SSMS a tu instancia administrada de Azure y con clic derecho sobre “bases de datos” ve a restaurar aplicación de capa de datos. Sigue los pasos del asistente para importar tu archivo bacpac.

migrar 3

Paso 3

Ahora que ya tienes todos los datos copiados es el momento de validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.

Otras opciones

Existe un tercer método simple que no te había comentado hasta ahora pero que también te puede servir para migrar tus datos. Es bastante más sencillo que los anteriores pero su uso queda limitado a bases de datos realmente pequeñas. Esta tercera opción consiste en generar los scripts de base de datos igual que has hecho en el primer paso de la primera solución que te he enseñado pero, en las opciones avanzadas, seleccionar también que genere los script para migrar los datos. De esta manera te generará los scripts con un insert por cada registro de cada tabla que tengas. Como ves te va a mover los datos pero es del todo ineficiente y solo es para bases de datos con pocas tablas y muy pocos registros.

Conclusión

Has visto las formas sencillas de migrar tus datos de una base de datos de Azure SQL a una instancia administrada de Azure. Con estos métodos vas a poder salir airoso de esta difícil tarea. Ahora ya si te quieres complicar te recomiendo crear un paquete SSIS que copie los datos con un bucle por cada una de las bases de datos en tu servidor de bases de datos de Azure SQL y lo que se te ocurra. A mi es la solución que más me gusta pero, cierto es, que solo merece la pena si las que tienes que migrar son muchas bases de datos.

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

Detectando BLOQUEOS en SQL Server y Azure SQL

Cuando trabajamos con bases de datos SQL Server, los bloqueos pueden ser una de las características de implementación que más dolores de cabeza nos pueden dar como DBAs. A los usuarios también, por supuesto, pero ellos trasladarán sus quejas a nosotros.

Por esto, en el vídeo de hoy, te enseño a detectar bloqueos en SQL Server o Azure SQL. Gracias a procedimientos integrados de sistema como sp_who o sp_who2 podremos verlo de una forma muy básica. Si queremos más nivel de detalle podremos recurrir a procedimientos de terceros como sp_who3, sp_whoisactive o sp_BlitzWho.

Si queremos detectar un bloqueo de una forma rápida y ligera, los procedimientos de sistema sp_who y sp_who2 son un gran aliado. Sin embargo, la información que nos van a mostrar es más bien justa. Si tenemos ocasión, siempre será recomendable de recurrir a procedimientos más completos como los citados en el vídeo.

También podremos hacer uso del siguiente script que nos muestra los procesos con bloqueos:

Como ves, el script hace uso de las vistas de administración dinámica de sistema sys.dm_exec_request y sys.sysprocesses para localizar los bloqueos. Además de la función sys.dm_exec_sql_text para devolver el texto de la consulta que está ejecutando esa sesión. En determinadas ocasiones, dependiendo del bloqueo, es posible que este script no resuelva debido a la función. En esos casos comenta esa parte del código para por lo menos localizar los bloqueos.

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

Remote Dedicated Admin Conection (R DAC). Vas a querer habilitarlo en tus SQL Server.

¿Sabías que SQL Server implementa un sistema de conexiones de emergencia para cuando todo lo demás falla? Se llama DAC (Dedicated Admin Connection) y es una las puertas traseras que todo DBA tiene que habilitar en sus servidores SQL para poder acceder cuando el servidor está tan saturado que no responde. Más bien podríamos considerarlo una entrada de emergencia, si es que el término existe.

¿Qué es DAC y cómo funciona?

Como hemos comentado en la introducción DAC es una conexión dedicada para administradores que nos va a permitir acceder a nuestro servidor SQL Server aun cuando los problemas de rendimiento sean tan graves que nada más responda. Cuando habilitamos DAC y abrimos una conexión de esta manera, lo que realmente estamos haciendo es decirle a SQL Server que se reserve un hilo de proceso para nosotros, sea lo que sea que esté corriendo en otros procesos. Como habrás intuido, tiene un problema, no paraleliza, el hecho de reservar un único hilo de procesos va a hacer que si una consulta necesita paralelizar de error. Aun así, con un hilo de proceso va a ser suficiente para localizar la consulta o consultas que están saturando el servidor y poder detenerlas.

¿Tipos de DAC?

Antes de nada, DAC es un acrónimo común, en este artículo siempre nos referimos a las Dedicated Admin Connection. SQL Server también implementa una cosa llamada Aplicaciones de Capa de Datos que llama DAC Package pero no estamos hablando de eso, no tiene nada que ver con esto.

Ahora que tenemos esto claro, tenemos dos tipos de conexiones dedicadas para administradores y son en local o remotas. Cuando hablamos de conexiones DAC remotas vamos a verlo como RDAC o Remote Dedicated Admin Connection. DAC siempre está habilitado en SQL Server y no lo podemos deshabilitar, sin embargo, RDAC por defecto no lo está y tendremos que habilitarlo nosotros manualmente.

¿Por qué necesitas habilitar RDAC?

Como hemos visto, RDAC es lo mismo que DAC solo que de forma remota. Si podemos entrar al servidor de manera local y conectar por DAC, ¿por qué deberíamos habilitar RDAC? Muy fácil, estamos hablando de una puerta trasera para emergencias, casos en los que el servidor va a estar tan saturado que es posible que ni podamos conectar de manera local por terminal server. En esta situación, tener un endpoint a la escucha de manera remota que siempre está habilitado para acceder por muy mal que esté el servidor puede ser la diferencia entre tener que reiniciar el servidor o no. Y nunca querremos tener que llegar a reiniciar el servidor, ¿verdad?

Habilitar Remote DAC

A nivel de instancia, habilitar RDAC es tan sencillo como ejecutar el siguiente comando de configuración:

Sin embargo, depende de la seguridad de tu red es probable que tengas que hablar con el administrador de redes para que te permita estas conexiones. Como hemos comentado antes por encima, Remote DAC usa un endpoint específico, lo que significa que no está a la escucha por el mismo puerto que las conexiones normales. Normalmente usará el puerto 1434 en vez del 1433. Asegúrate que el administrador de red te permite esas conexiones en el firewall antes de que tengas que echar mano de ellas y no vayas a poder.

Limitaciones de DAC

Tanto DAC como RDAC tienen las mismas limitaciones, y es normal, en el fondo son el mismo tipo de conexión. Esta limitación básica es que solo reserva un hilo de procesamiento por lo que solo vamos a poder tener una conexión abierta y ejecutar consultas sin paralelismo. Puedes pensar que es un gran hándicap pero, te aseguro que no. DAC no está pensado para trabajar normalmente ni para ejecutar planes de mantenimiento ni nada parecido. Solo es un método de acceso de emergencia para casos puntuales y, en esos casos, aun con esta limitación, es más que suficiente.

Por último, otra limitación es que solo van a poder usar este tipo de conexiones los usuarios sysadmin. Es lógico también, otro tipo de usuarios, aunque pudiesen acceder, no iban a poder solucionar la incidencia.

¿Cómo conectar usando DAC?

Ya sabemos casi todo lo necesario sobre DAC y por qué lo necesitamos, ahora bien, nos falta lo más importante, ¿cómo se usa?. Primero de todo dejame decirte que ojalá tengas la suerte de no necesitarlo nunca pero, como esto no es un mundo de fantasía, vamos a ver cómo vamos a tener que conectarnos. En este sentido tanto para conexiones en local (DAC) como para remotas (RDAC) es exactamente igual. En principio esta solución está pensada para conectarse desde una ventana de comandos con SQLCMD y para ello en la cadena de conexión usaremos el modificador -A. Sin embargo, tenemos la posibilidad de conectar también desde el SSMS con el prefijo “Admin:” antes del nombre del servidor.

El uso de SSMS tiene sus pegas, por un lado, aunque no es una limitación real, queda prácticamente limitado a conexiones RDAC ya que con el servidor completamente saturado rara vez vamos a poder ejecutar SSMS en local en un tiempo razonable. La segunda pega del uso de SSMS tiene que ver con el límite de sólo una conexión DAC simultánea y es que, SSMS, en concreto el explorador de objetos, ya consume más de una conexión. Por este motivo, su uso queda limitado a una conexión de una ventana de consultas exclusivamente.

DAC

Para conectar por una ventana de comandos usaremos los siguientes comandos:

Local (DAC):

Remoto (RDAC):

Es importante tanto el modificador -A para usar la conexión DAC como el “-d master” para especificar que conecte a esta base de datos. Esto se debe a que si la base de datos por defecto del usuario está offline la conexión va a fallar. De esta manera nos aseguramos que conectemos a la master y nos evitamos ese problema.

Conclusión

Gracias a las conexiones dedicadas para administradores DAC y RDAC vamos a poder garantizarnos un acceso de emergencia a nuestros servidores en caso de que todo lo demás esté fallando. Dedica unos minutos a habilitar RDAC en tus servidores y a validar su funcionamiento, así como, a familiarizarte con su uso por SQLCMD. No esperes a tener un problema para probar porque, en ese caso, es probable que el estrés del momento te juegue una mala pasada.

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

Plegado de consultas en Power BI

Si ya has trabajado alguna vez con Power BI, sobre todo si te has interesado por su rendimiento, te sonará el concepto plegado de consultas (query folding en inglés). Este concepto es clave en el rendimiento de power BI y sin embargo a mucha gente se le escapa o no lo comprende muy bien. Hoy, voy a intentar arrojar algo de luz sobre este tema de manera sencilla y para todos los públicos aunque, ya os adelanto que el tema da para mucho y si os interesa al final del artículo os dejo alguna recomendación extra para continuar aprendiendo. 

¿Qué es el plegado de consultas?

Empecemos por el principio, el plegado de consultas, o “Query Folding”, es un proceso por el cual el motor de Power Query (mashup engine) intenta llevar a cabo la mayor cantidad de transformaciones de datos posible en los sistemas de origen origen, en lugar de hacerlo después de que los datos se hayan cargado en la memoria. Esto puede resultar en una mejora significativa del rendimiento de Power BI, especialmente cuando se trabaja con grandes volúmenes de datos.

¿Qué es Power Query?

¡Quieto Roberto! A más de uno le acaba de volar la cabeza con el párrafo anterior. He introducido el concepto Power Query sin explicaros lo que es, perdonadme. Power Query es una característica de Power BI que cumple las funciones de ETL (extraer, transformar y cargar datos). Gracias al motor mashup engine es capaz de extraer datos de varios orígenes, transformar lo que sea necesario y por último cargarlos en un destino. Principalmente vamos a poder encontrar esta función en Power BI, en los flujos de datos de Power BI (dataflows) y en Microsoft Excel 2016 o superiores. Adicionalmente vamos a poder usar Power Query en Excel 2010 y 2013 si descargamos e instalamos manualmente el componente.

¿Cómo funciona el plegado de consultas?

Cuando creamos una consulta con lenguaje M en Power Query, estamos definiendo una serie de pasos para obtener y transformar nuestros datos. Estos pasos pueden incluir filtrado, agrupación, unión de tablas, entre otros. Idealmente, queremos que estos pasos se realicen en el origen de los datos. Esto es lo que se conoce como plegado de consultas y se podrá llevar a cabo en la mayoría de los casos si los orígenes admiten lenguaje SQL y, siempre y cuando, la instrucción M se traduzca en una sola select con funciones que existan en el lenguaje SQL.

El siguiente diagrama de la documentación oficial de microsoft explica el proceso paso a paso:

Diagrama-plegado-consultas
  1. Power Query recibe el script en código M desde el editor avanzado.
  2. El mecanismo de plegado de consultas envía una consulta de metadatos al origen de datos para evaluar sus características.
  3. El mecanismo de plegado de consultas determina qué información extraer del origen de datos y qué conjunto de transformaciones deben producirse dentro del motor de Power Query. 
  4. Power Query consulta el origen de datos mediante una consulta nativa.
  5. El origen de datos devuelve los datos al motor de Power Query.
  6. Una vez que los datos están en Power Query, el motor de transformación de Power Query (también conocido como motor de mashup) realizará las transformaciones que no se pudieron plegar ni descargar en el origen de datos.
  7. Carga en el modelo de Power BI (o en excel) de los datos extraídos y transformados.

¿Por qué es importante?

El plegado de consultas es especialmente útil cuando trabajamos con grandes conjuntos de datos. Al realizar las transformaciones en el origen de los datos, reducimos la cantidad de datos que necesitamos cargar en la memoria, lo que puede resultar en un rendimiento significativamente mejorado. Si por ejemplo solo necesitamos unas pocas filas y columnas de la tabla de origen, gracias al plegado de consultas no vamos a tener que traer todos los datos para luego filtrarlos. Igualmente si, podemos realizar las uniones entre tablas, agregaciones y ordenados en el origen (que está optimizado para ello) es trabajo que le quitamos a nuestro Power BI.

Tiene otras ventajas, como que Power BI optimizará en gran medida las cargas incrementales de los datos cuando las consultas son 100% plegables ya que si no habría que leer todo el origen y cargarlo en memoria para que el mashup engine cribe las filas nuevas de las ya existentes.

¿Cómo saber si se está realizando el plegado de consultas?

Power Query Dataflows proporciona indicadores visuales que nos permiten saber si se está realizando el plegado de consultas. Estos indicadores se encuentran en la ventana de Power Query y nos muestran qué pasos se están plegando a través de iconos. Esto está muy bien resumido en la documentación oficial así que os dejo directamente el extracto.

Plegado-de-consultas

En Power BI Desktop no va a ser tan sencillo verlo como mirar los iconos al lado de los pasos de la transformación, sin embargo, eso no significa que no podamos verlo. Simplemente con hacer clic derecho sobre el paso y verificar si nos está ofreciendo ver la consulta nativa podremos saber si se mantiene o no el plegado de consultas.

Andrés en nuestro grupo de Telegram añade: «Otra de las formas de saber si el plegado se mantiene, es con la función Value.Metadata (tabla). Devuelve información sobre si existe o no el plegado. Del mismo modo, podemos usar una instrucción para mantener el plegado, es con la función Value.NativeQuery() y con el parámetro EnableFolding=true. Esto nos permitirá enviar una consulta directa a SQL Server, mantener el plegado y poder seguir realizando pasos que mantengan el plegado. El problema es que cuando escribes directamente la consulta desde el conector a SQL Server, la consulta ya no seguirá plegando de ahí en adelante. Por suerte, la función Value.NativeQuery(…), si nos permite esto.«

Niveles de plegado de consulta

Como hemos visto a lo largo de este artículo, existen ciertas operaciones de transformación de datos incompatibles con el plegado de consultas. A esto se le llama romper el plegado de consultas y deberemos evitarlo en la medida de lo posible. Aun así, esto no quiere decir que la consulta ya no se vaya a plegar por tener un paso incompatible, la optimización del motor de Power Query sabrá plegar todos los pasos posibles y solo efectuar en el motor de transformaciones lo estrictamente necesario. En este sentido, nos vamos a encontrar con tres niveles de plegado de consultas:

  • Plegado de consultas completo: Todas las transformaciones de consulta se delegan en el origen de datos. El motor de Power Query realiza un procesamiento mínimo y muy eficiente.
  • Plegado parcial de consultas: Una parte de las transformaciones de la consulta, y no todas, se pueden delegar en el origen de datos. En este caso, una parte de las transformaciones las realiza el origen de datos y el resto se producen en el motor de transformaciones de Power Query.
  • Sin plegado de consultas: La consulta no se puede plegar. Normalmente contiene transformaciones que no se pueden traducir al lenguaje de consulta nativo del origen de datos, ya sea porque las transformaciones no son compatibles o porque el conector no admite el plegado de consultas. En este caso, Power Query obtiene los datos sin procesar del origen de datos y utiliza el motor de Power Query para lograr los datos deseados mediante el procesamiento de las transformaciones necesarias a nivel del motor de Power Query.

Conclusión

El plegado de consultas es un concepto complejo pero crucial para el rendimiento en Power BI. Si trabajas a menudo con Power Query dedica tiempo a entender en profundidad esta funcionalidad y así mejorar considerablemente tus resultados. Por mi parte no me queda más que, como os había prometido al inicio, recomendaros el libro “Power BI Dataflows” de Francisco Mullor para convertiros en unos verdaderos maestros de la herramienta. Si solo os interesa este tema que hemos tratado hoy o si queréis usarlo como aproximación al libro, Fran ha publicado el capítulo dedicado al plegado de consultas de manera que está accesible de manera gratuita aquí. También podéis pasar por la academia virtual de Alex Ayala donde encontraréis cursos de Power BI de gran calidad.

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 Power BI, Rendimiento, 0 comentarios

SQL AVANZADO – Agrupaciones con Cube y Rollup

Continuamos con los videos de T-SQL avanzado con los modificadores WITH CUBE y WITH ROLLUP. Estos son modificadores de la cláusula GROUP BY. Gracias a WITH CUBE vamos a poder totalizar nuestras agrupaciones junto a los resultados de nuestras consultas y con WITH ROLLUP podremos ver solo totales agrupados por varios campos.

Al igual que comentamos en nuestro anterior video de T_SQL Avanzado el uso de este tipo de consultas en vistas que luego se consumirán desde Power BI nos va a evitar caer en el error de romper el plegado de consultas. También vamos a conseguir con una sola consulta los resultados que, de otra manera, necesitaríamos por lo menos dos consultas, con el doble de lecturas sobre los datos y, por tanto, con mayor consumo de recursos.

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