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.

Modos de Recuperación: Guía Completa

Uno de los aspectos más cruciales de las bases de datos SQL Server y, a menudo, complejos para los que se están iniciando son los modos de recuperación. En este artículo, voy a tratar de profundizar en los detalles de los modos de recuperación de SQL Server, detallando sus características, usos y mejores prácticas para optimizar el rendimiento y la seguridad de nuestras bases de datos. Espero que tanto si estáis empezando a trabajar con bases de datos como si sois ya experimentados podáis aprender algo nuevo.

¿Qué son los Modos de Recuperación en SQL Server?

Empecemos por el principio, en SQL Server, los modos de recuperación determinan cómo se gestiona el log de transacciones y cómo se pueden restaurar las bases de datos tras un fallo. Comprender estos modos es esencial para garantizar la integridad de los datos y minimizar el tiempo de inactividad en caso de incidentes. En este sentido, vamos a poder trabajar con tres modos distintos, simple, full (completo) o bulk-logged (registro masivo).

Banner-Telegram

Tipos de Modos de Recuperación

Como acabamos de ver existen tres modos principales de recuperación en SQL Server: Simple, Full y Bulk-Logged. Cada uno de estos modos tiene sus propias características y escenarios de uso.

Modo de Recuperación Simple

El modo de recuperación simple es el más básico de los tres. En este modo, el espacio utilizado por el registro de transacciones se reutiliza automáticamente después de cada punto de control (checkpoint), lo que significa que no se requiere una gestión detallada del log.

Esto tiene una serie de ventajas como la simplicidad de no requerir una administración exhaustiva del log de transacciones o un menor tamaño del log al reutilizar el espacio. Siempre se mantiene el tamaño del log relativamente pequeño mientras no hagamos transacciones descomunales. Sin embargo, también tiene sus contras. Como desventajas nos vamos a encontrar con una menor capacidad de copias de seguridad ya que solo vamos a poder hacer copias completas o diferenciales. Esto, por supuesto, se traduce en una menor capacidad de recuperación a la hora de necesitar una restauración. En estos casos es probable que suframos una mayor pérdida de datos. En caso de fallo, los datos desde el último respaldo hasta el momento del fallo se perderán, esto es así siempre pero, en el caso de otros modos de recuperación con copias de logs, este tiempo suele ser menor.

Como habrás podido comprobar este modo es ideal para bases de datos que no necesitan un alto grado de recuperación de datos, como bases de datos de desarrollo o pruebas o entornos de producción sin gran cantidad de cambios o sin mucha criticidad.

Modo de Recuperación Full

El modo de recuperación completo, el modo por defecto de todas las nuevas bases de datos de SQL Server y Azure, ofrece el mayor nivel de protección para los datos. En este modo, cada transacción se registra completamente, y se puede realizar una restauración a cualquier punto en el tiempo. Para lograr esto el log de transacciones almacena las transacciones sin borrarlas incluso cuando han terminado y solo se borran cuando ya han sido salvadas en una copia de seguridad de log.

Como ventajas a este comportamiento podemos encontrar una capacidad de copias y por tanto de recuperación más granular. Una base de datos en modo de recuperación Full nos va a permitir la restauración de la base de datos a un punto concreto en el tiempo, minimizando la pérdida de datos. Por supuesto esta mayor capacidad de copias tiene otra ventaja añadida y es la flexibilidad a la hora de diseñar nuestra solución de backups. Al soportar backups completos, diferenciales y de log de transacciones vamos a poder adaptar nuestro plan de copias a nuestros procesos de manera que no interfieran en el rendimiento.

No todo es tan bonito, claro, a cambio tendremos una gestión de los log más compleja que requerirá más cuidado y vigilancia por nuestra parte para evitar que crezca demasiado.

Esto puede ser más complicado de administrar debido a la necesidad de realizar backups de log regulares.

Como ves, este modo es el indicado para bases de datos de producción críticas donde la pérdida de datos debe ser mínima y disponen de un administrador de base de datos que diseña y supervisa el plan de copias de seguridad para evitar incidencias. 

Modo de Recuperación por Bulk-Logged

El modo de recuperación de registro masivo, es una opción intermedia entre el Modo Simple y el Modo Completo. Está diseñado para optimizar las operaciones masivas de carga de datos. Este modo minimiza el uso del espacio del log de transacciones cuando se ejecutan operaciones masivas como BULK INSERT, SELECT INTO o CREATE INDEX. Funciona de manera similar al Modo de Recuperación Completo, con la excepción de que los registros de transacciones se registran mínimamente durante las operaciones masivas. Esta forma de registro mínimo ayuda a mantener el log más pequeño al no registrar tanta información.

Gracias a estas optimizaciones, mejora la eficiencia en las operaciones masivas como la carga de datos con BULK INSERT que serán más rápidas y generarán menos registros en el log. Todo esto lo consigue sin perder la flexibilidad ya que ofrece algunas capacidades de recuperación punto en el tiempo, similares al modo full. Es importante remarcar ese algunas capacidades ya que cuando estamos haciendo una operación de carga masiva de datos no vamos a tener registros en el log de transacciones de esa operación lo que va a afectar a la posibilidad de recuperar en ese punto en el tiempo en concreto. Además, aún  requiere una gestión adecuada del log de transacciones igual que el modo full. 

A tener en cuenta

A pesar de que las recuperaciones punto en el tiempo pueden realizarse en algunas situaciones, si la base de datos se daña mientras se realiza una operación de carga masiva, solo se puede recuperar hasta el último backup del log de transacciones creado antes de la operación masiva. Si no se realizan operaciones de carga masiva mientras se utiliza este modo, entonces se puede realizar una restauración punto en el tiempo de manera similar al modo de recuperación completo. Para que podamos minimizar la pérdida de datos al realizar operaciones de carga masiva, es recomendable realizar un backup del log de transacciones justo antes de la operación masiva y otro inmediatamente después de que la operación haya finalizado. De esta manera, se puede realizar una recuperación punto en el tiempo utilizando los backups del log de transacciones tomados antes y después de la operación de carga masiva.

Elección del Modo de Recuperación Adecuado

La elección del modo de recuperación adecuado depende de varios factores, incluyendo los requisitos de recuperación de datos, la frecuencia de cambios en los datos y la capacidad de gestionar los backups del log, como ya hemos comentado anteriormente.

  • Requisitos de Recuperación: Si necesitamos la capacidad de recuperar la base de datos hasta un punto específico en el tiempo, el modo full es imprescindible. Si la pérdida de algunos datos es aceptable, el modo simple puede ser suficiente y nos va a simplificar mucho la tarea.
  • Frecuencia de Cambios: Las bases de datos con cambios frecuentes pueden beneficiarse del modo completo, mientras que aquellas con menos cambios pueden utilizar el modo simple o el Modo en Bulk-Logged.
  • Capacidad de Gestión: La capacidad de gestionar backups regulares y el tamaño del log de transacciones también influye en la elección. El modo completo requiere una mayor gestión, mientras que el modo simple es más fácil de manejar.

Mejores Prácticas para la Gestión de Modos de Recuperación

Como con todos los temas importantes, existen una serie de buenas prácticas que no debemos descuidar. En el caso de los modos de recuperación estas recomendaciones pasan por:

  1. Realizar Backups Regulares: Independientemente del modo de recuperación, es crucial realizar backups completos de manera regular. Estos se podrán complementar con otros backups como diferenciales o log en función de las necesidades y del modo de recuperación elegido.
  2. Monitorizar el Tamaño del Log: Especialmente en el modo full y Bulk-Logged, es importante monitorear y gestionar el tamaño del log de transacciones para evitar que crezca descontroladamente.
  3. Probar Restauraciones: Realizar pruebas de restauración periódicas para asegurar que los backups son funcionales y los datos se pueden recuperar según lo planeado. Esto, que muchas veces se pasa por alto pues un backup no testeado puede dejarnos tirados cuando más lo necesitemos.
  4. Documentar Procedimientos: Mantener una documentación detallada de los procedimientos de backup y restauración para asegurar una respuesta rápida y efectiva en caso de fallo es clave, como ya vimos en el post sobre la recuperación ante desastres.

¿Qué modo estoy usando? ¿Cómo lo cambio?

Existen varios métodos para averiguar el modo de recuperación actual de una base de datos y poder cambiarlo. El primero y más sencillo es a través de la interfaz gráfica del SSMS. Para ello haremos clic derecho sobre una base de datos y abriremos sus propiedades. Ya en las propiedades nos dirigiremos a las opciones para encontrar el modo de recuperación actual y poder cambiarlo si lo deseamos. 

Modo-de-recuperacion

Otra forma de verlo es consultando la vista de sistema sys.databases donde vamos a encontrar una columna llamada recovery_mode_desc con esta información.

Si deseamos modificar el modo de recuperación por código T-SQL usaremos estas sintaxis para el modo simple, full o bulk-logged respectivamente

Conclusión

Los modos de recuperación en SQL Server son un aspecto clave en la estrategia de administración de bases de datos. Elegir el modo adecuado y gestionarlo de manera efectiva pueden marcar la diferencia entre una recuperación exitosa y una pérdida de datos importante. Comprender las ventajas y desventajas de cada modo y aplicar las mejores prácticas nos asegurará la integridad y disponibilidad de nuestros datos, garantizando así un rendimiento óptimo y una respuesta eficiente ante cualquier incidente.

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

Trabajando con Fecha y Hora

Saber trabajar correctamente con tipos de datos de fecha y hora es de las cualidades más importantes para cualquier trabajador de datos. En este video te cuento todos los secretos de los tipos de datos de fecha y hora en SQL Server así como las funciones disponibles para operar con nuestros datos y los problemas a los que te vas a poder enfrentar con las distintas conversiones.

En este video has podido ver las diferencias entre los tipos de datos Datetime, SmallDatetime, Date, Time, Datetime, Datetime2 y Datetiemoffset. También las funciones de obtención de fecha y hora actuales GETDATE, GETUTCDATE, SYSDATETIME y SYSDATETIMEOFFSET. Por si eso te parece poco, hablamos también de las funciones para operar con fechas y horas DAY, MONTH, YEAR, DATEPART, DATENAME, DATEADD y DATEDIFF.

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 quieres ver más videos como este puedes encontrarlos todos aquí. 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

NULL, un dato especial que debemos saber tratar

Cuando hablamos de datos, uno de los conceptos más interesantes y a menudo malinterpretados es el tratamiento del valor NULL. Nosotros, como DBAs, debemos comprender en profundidad cómo manejar estos valores especiales para asegurar la integridad y eficiencia de nuestras bases de datos. En este artículo, quiero profundizar en cómo SQL Server y las bases de datos SQL de Azure tratan los valores nulos, sus implicaciones y las mejores prácticas para su gestión. Por último compararemos este comportamiento con otros sistemas de gestión de bases de datos (SGBD) como PostgreSQL, MySQL y Oracle.

¿Qué significa NULL?

En el estándar SQL, NULL representa un valor desconocido o no aplicable. A diferencia de otros lenguajes de programación o de fórmulas, NULL no es igual a cero ni a una cadena vacía, en resumen, es simplemente la ausencia de un valor. Esta distinción es crucial, debemos interiorizarla y no olvidarla jamás, hazle un hueco en tu cerebro junto al recuerdo del gol de Iniesta en el minuto 116 de la final del Mundial de Sudáfrica 2010. Y no digo esto porque si, este comportamiento afecta a la forma en que las consultas se construyen y ejecutan. En entornos como SQL Server y Azure SQL, manejar correctamente los valores nulos puede marcar la diferencia entre una base de datos coherente y una llena de inconsistencias.

Tratamiento del valor NULL en SQL Server y Azure SQL

Lo primero que debemos recordar es que NULL no representa ningún valor y como tal no se va a comportar como un valor típico. En SQL Server, cualquier comparación lógica con NULL (por ejemplo, =, <, >, etc.) dará como resultado otro NULL. Esto se debe a que, al ser un valor desconocido, no se puede determinar con certeza si es igual o diferente a otro valor. Tenemos que pensar en que a la lógica de verdadero o falso (sí o no) se le va a sumar una tercera posibilidad, desconocido. Desconocido no es ni verdadero ni falso, ni sí ni no. Por esta razón, debemos utilizar el operador IS NULL o IS NOT NULL para verificar su existencia.

Efectos de NULL en las consultas

Cuando escribimos consultas, el manejo de los nulos es crucial. Vamos a verlo con un ejemplo, supongamos que tenemos una tabla Empleados y queremos encontrar a los que no tienen un jefe asignado. Podriamos pensar que esta consulta va a funcionar:

Sin embargo, esta consulta no devolverá ningún resultado, porque JefeID = NULL siempre es falso. La consulta correcta es:

Funciones de manejo de NULL

Para poder salvar estas limitaciones SQL Server y Azure SQL ofrecen varias funciones para tratar los valores nulos de manera efectiva. Algunas de las más útiles incluyen:

ISNULL(): Esta función reemplaza NULL con un valor especificado. Por ejemplo, para mostrar «N/A» en lugar de NULL en un campo de teléfono, usaríamos:

COALESCE(): Hemos visto que ISNULL() es una función que acepta dos valores y devuelve el primero que no sea NULL. Coalesce es igual, pero acepta múltiples argumentos y devuelve el primero que no sea NULL. Esto es especialmente útil cuando trabajamos con varias columnas que podrían contener valores nulos:

Tratamiento de NULL en funciones agregadas

Las funciones agregadas como SUM(), AVG(), MAX(), y MIN() directamente ignoran los valores nulos en sus cálculos. Esto es importante para evitar resultados inesperados. Por ejemplo, si queremos calcular el salario promedio de nuestros empleados, SQL Server excluirá automáticamente los valores nulos de la columna y podremos hacer esta consulta simple sin miedo a errores o resultados inesperados:

Tratamiento de NULL en Dynamic Data Masking (DDM)

DDM nos permite enmascarar la información sensible de nuestra base de datos y, en ocasiones, la propia ausencia de información es sensible en sí. Sin embargo, y esto es algo mejorable a mi parecer, DDM no nos permite ocultar valores NULL sensibles en nuestras tablas. Es decir, DDM solo enmascara datos conocidos, mostrando un valor NULL real a los usuarios sin privilegios igual que a los que sí tienen permiso de desenmascarar.

Implicaciones de NULL en índices y claves

Al definir índices y claves, debemos tener en cuenta cómo los valores nulos afectan a estas estructuras. Por ejemplo, en SQL Server, un índice único permite múltiples valores nulos, lo cual puede ser útil pero también peligroso si no se entiende y maneja correctamente. Veamos ahora 

Claves Primarias

Las claves primarias (PK) no admiten valores nulos. Esto es lógico, una clave primaria debe identificar de manera única cada fila en una tabla, y un valor nulo, al ser desconocido, no puede cumplir con esta restricción de unicidad. Por lo tanto, al diseñar nuestras tablas, debemos asegurarnos de que las columnas definidas como clave primaria siempre contengan valores no nulos. Realmente, SQL Server hará esto por nosotros y solo nos dejará definir como campos clave de una PK aquellas columnas definidas como NOT NULL, es decir, que no admiten valores nulos. 

En el ejemplo anterior, EmpleadoID no puede contener valores nulos, garantizando así la unicidad y la identificabilidad de cada registro. Gracias a esa restricción podemos definir la columna como clave primaria.

Claves Foráneas

Las claves foráneas (FK), por el contrario, sí pueden admitir valores nulos. Un valor nulo en una clave foránea indica que no hay una relación con la tabla referenciada. Esto puede ser útil para representar situaciones donde una relación no es obligatoria. Por ejemplo, si un empleado no tiene un jefe designado, el campo JefeID puede ser NULL.

En este caso, JefeID puede ser nulo, lo que indica que un empleado no tiene jefe.

Mejores prácticas para manejar NULL

Para mantener la integridad y eficiencia de nuestras bases de datos, debemos seguir algunas mejores prácticas en el uso y control de nulos. Siempre que sea posible, definiremos valores por defecto en nuestras columnas para evitar NULL. Por ejemplo, en lugar de permitir NULL en una columna de estado, podríamos definir «Desconocido» como valor por defecto. Los valores por defecto son aquellos que se van a poner en nuestra base de datos cuando insertamos un registro y no especificamos manualmente otra cosa. Por ejemplo:

No solo los nulos pueden ser un problema, también es posible que un dato técnicamente válido no tenga sentido de negocio. Para estos casos podemos utilizar restricciones CHECK y NOT NULL para asegurarnos de que nuestras columnas contengan siempre valores válidos. Por ejemplo, la siguiente restricción se asegura de que el salario de un empleado siempre sea un número mayor que 0. Como hemos visto antes, esta restricción también invalidará los valores NULL de forma intrínseca.

Por último, debemos documentar claramente cuándo y por qué permitimos nulos en nuestras tablas y asegurarnos de que todos los desarrolladores sigan las mismas buenas prácticas a la hora de crear tablas.

Comparación con otros SGBD

Como este tema es importante vamos a ver el comportamiento de NULL cuando trabajamos con otros de los principales motores de base de datos presentes en el mercado.

  • PostgreSQL maneja los valores nulos de manera similar a SQL Server. Al igual que en SQL Server, las comparaciones directas con NULL siempre devuelven NULL, y se utilizan IS NULL y IS NOT NULL para verificar la existencia de valores NULL. PostgreSQL también soporta funciones como COALESCE() y NULLIF() para manejar NULL. Una diferencia notable es que PostgreSQL permite definir restricciones más avanzadas usando expresiones booleanas, lo que puede ser útil para controles más complejos sobre los valores NULL.
  • MySQL, el manejo de nulos es también bastante similar. Las comparaciones directas con NULL resultan en NULL, y se usan IS NULL y IS NOT NULL para las verificaciones. MySQL proporciona las funciones IFNULL() y COALESCE() para manejar valores NULL. Un aspecto distintivo de MySQL es que, en ciertos modos de SQL, puede comportarse de manera más laxa con los valores nulos en índices únicos, permitiendo múltiples entradas NULL, lo cual es similar a SQL Server.
  • Oracle maneja los nulos de manera muy coherente con el estándar SQL. Las comparaciones con NULL devuelven NULL, y se utilizan IS NULL y IS NOT NULL. Oracle también ofrece funciones como NVL() (que es equivalente a ISNULL() en SQL Server) y COALESCE(). Una característica única de Oracle es su uso de NULLS FIRST y NULLS LAST en las cláusulas ORDER BY, permitiendo un control más granular sobre el orden de los valores NULL en los resultados de las consultas.

Comparación con DAX

Ya hemos hablado de DAX (Data Analysis Expressions) en el blog. DAX es un lenguaje de fórmulas utilizado en Power BI, Analysis Services y Power Pivot para realizar cálculos y consultas de datos. DAX tiene su propia forma de manejar valores nulos, conocida como BLANK. En DAX, el equivalente de NULL es BLANK. El manejo de valores BLANK en DAX difiere de los NULL en SQL en varios aspectos clave

Comparaciones

En DAX, una comparación directa con BLANK no devuelve BLANK. En lugar de eso, BLANK es tratado como 0 (cero) en comparaciones numéricas y como una cadena vacía en comparaciones de texto. Por ejemplo:

Funciones de manejo de BLANK

DAX proporciona varias funciones para manejar valores BLANK, incluyendo BLANK(), ISBLANK(), y COALESCE(). La función COALESCE() en DAX es similar a su homóloga en SQL, devolviendo el primer valor que no sea BLANK.

Impacto en cálculos agregados

Las funciones agregadas en DAX, como SUM(), AVERAGE(), MAX(), y MIN(), manejan los valores BLANK de manera similar a SQL, ignorándolos en los cálculos. Sin embargo, es importante saber que en DAX, un BLANK en una medida puede tener implicaciones diferentes dependiendo del contexto del cálculo. Supongamos que tenemos una tabla de ventas en Power BI y queremos calcular el total de ventas, tratando los valores nulos en la columna Cantidad como ceros:

En este ejemplo, la función SUMX recorre cada fila en la tabla Ventas y utiliza COALESCE para tratar los valores BLANK en la columna Cantidad como 0.

Diferencias clave DAX vs SQL

Como hemos visto el tratamiento de los valores nulos en DAX difiere del de SQL. Podríamos resumir las diferencias así:

  • Manejo en comparaciones: Mientras que en SQL, NULL no se puede comparar directamente y cualquier comparación devuelve NULL, en DAX el valor BLANK se trata como 0 o una cadena vacía, dependiendo del contexto.
  • Funciones específicas: DAX tiene funciones específicas para trabajar con BLANK, y estas funciones son esenciales para manejar datos en contextos de análisis y cálculos complejos.
  • Contexto de cálculo: En DAX, el contexto de cálculo puede afectar cómo se manejan los valores BLANK, especialmente en modelos de datos complejos donde se utilizan múltiples tablas y relaciones.

Conclusión

El manejo de valores nulos es una característica fundamental  cuando trabajamos con datos, ya sea en SQL Server, Azure SQL, otros SGBD como PostgreSQL, MySQL y Oracle o con herramientas de BI como Power BI. Aunque las diferencias en el comportamiento son sutiles, cada SGBD ofrece herramientas y funciones específicas para tratar con valores NULL de manera eficiente. 

Comprender estas diferencias y mejores prácticas es imprescindible para diseñar y gestionar nuestras bases de datos de manera más efectiva, asegurando la integridad y eficiencia de nuestros sistemas. 

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

Servidores SQL administrándose solos con políticas

Amigo DBA, vete de vacaciones tranquilo. Crea políticas (directivas) para que tus servidores SQL Server se administren por si solos. En este video te muestro las políticas que yo tengo en mis servidores y como crear las tuyas personalizadas.

Gracias a las políticas de SQL Server vamos a poder exigir el cumplimiento de las directivas que nosotros definamos para que todo siga funcionando como debería en nuestra ausencia. Podremos elegir entre evaluar cada una de las políticas a petición o bajo demanda y su comportamiento, por ejemplo, si van a dejar un log o a prevenir el cambio directamente.

Una vez creadas tus políticas podrás exportarlas e importarlas en el resto de tus servidores para no tener que repetir el trabajo. Esto último te lo muestro en el artículo de la semana pasada que puedes encontrar aquí. No esperes más y toma el control de tus servidores. Usa estas políticas para mantener la coherencia en tus esquemas, asegurar el cumplimiento de normativas internas o automatizar tus tareas.

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 quieres ver más videos como este puedes encontrarlos todos aquí. 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 SQL Server, Videos, 0 comentarios

Consultar datos con DAX

Voy a empezar por el final este artículo: Tenemos que saber DAX. No digo que seamos expertos en la materia pero sí ser capaces de entender y aconsejar en un momento dado a los usuarios. Y ahora que ya lo he dicho, y antes de ganarme más de un enemigo, os voy a explicar por qué.

Dentro de la estructura empresarial, los DBAs somos una grupo en ocasiones difícil de encajar. Nuestro trabajo se divide entre varios departamentos más asentados históricamente como sistemas, IT o infraestructura y los consumidores de los datos que acostumbraban a ser desarrolladores. Es raro que el DBA tenga relación directa con el usuario final de los datos. En los últimos años, cada vez cobra más fuerza un subgrupo que inicialmente podríamos encajar dentro de desarrollo pero que, por su importancia en las organizaciones, cada vez tiene más peso e independencia, los trabajadores de datos. Estamos hablando de analistas, ingenieros, científicos de datos, etc… Esto nos lleva a tener que entendernos con ellos también, y cuanto mejor sea este entendimiento mejor podremos desarrollar nuestro trabajo. 

Veamos cómo trabaja esta gente: primero de todo conectan sus herramientas de ETLs a los orígenes de datos para extraer información que alimente sus modelos. Una vez hecho eso, tratan esa información para extraer las métricas de negocio que importan a los usuarios finales de estos reportes. Igual que sabemos como funciona un servidor y una red para entendernos con los compañeros de infraestructura, igual que sabemos SQL para entendernos con los compañeros consumidores de los datos, tenemos que saber cómo funciona una herramienta de ETLs, por ejemplo SSIS, y cómo tratar los datos en herramientas de BI (por ejemplo DAX en Power BI).

¿Qué es DAX?

Lo primero que tenemos que aclarar es que DAX no es un lenguaje de programación. Al contrario de lo que mucha gente puede llegar a pensar, DAX es un lenguaje de fórmulas. Similar a excel si lo queréis ver así. Es más. si sabemos algo de excel vamos a tener mucho ganado a la hora de empezar con DAX. Eso no quiere decir que sea lo mismo que Excel, DAX es mucho más potente (para llevarlo a nuestro terreno es como comparar Access y SQL). Por ejemplo, una de las características de DAX más potentes es el contexto de filtro para realizar cálculos dinámicos basados en los datos filtrados.

Herramientas para Usar DAX

Antes de meternos con los detalles técnicos de DAX y aprender a usarlo, es importante conocer las herramientas que podemos utilizar para escribir y ejecutar expresiones DAX (que no código, ya hemos dicho que DAX no es un lenguaje de programación).

Power BI Desktop

Power BI Desktop es la herramienta más popular para trabajar con DAX. Permite a los usuarios crear informes interactivos y visualizaciones a partir de varios orígenes de datos. Desde hace poco, incluye un editor de DAX integrado que facilita la creación y prueba de fórmulas DAX.

DAX Studio

DAX Studio es una herramienta gratuita y de código abierto diseñada para ejecutar y analizar consultas. Se puede integrar con Power BI como herramienta externa y es ideal para depurar y optimizar las fórmulas DAX. DAX Studio nos va a permitir conectarnos directamente a modelos de datos en Power BI, Analysis Services y Power Pivot.

SQL Server Management Studio (SSMS)

Nuestro querido SSMS es principalmente una herramienta para trabajar con bases de datos SQL Server pero, también puede conectarse a instancias de Analysis Services para ejecutar consultas DAX. Esto es útil para los usuarios de bases de datos que desean integrar DAX en sus flujos de trabajo aunque su uso es residual ya que Analysis Services está siendo sustituido por otras herramientas de modelado tabular.

Excel con Power Pivot

Excel, junto con el complemento Power Pivot, va a permitir a los usuarios crear modelos de datos complejos y utilizar DAX para realizar cálculos avanzados. Esto es especialmente útil para los usuarios de Excel que están familiarizados con las fórmulas y desean aprovechar las capacidades avanzadas de DAX aunque nunca va a llegar a la potencia de una herramienta de BI como Power BI.

Trabajar con DAX

Ahora si, después de esta introducción tan larga vamos a ver como empezar a trabajar con DAX. Dada la temática principal del blog voy a suponer que los que leéis estas líneas estáis familiarizados con el lenguaje SQL por lo que vamos a ir viendo cómo hacer operaciones en DAX en comparación a SQL. 

Lectura simple de datos

Empecemos con lo más básico, lo primero que aprendemos cuando empezamos con SQL es a leer datos de una tabla así que con DAX no podía ser de otra manera. Para leer datos de una tabla vamos a usar la función EVALUATE que sería como select * from en SQL.

DAX-1

Ahora bien, normalmente no vamos a necesitar todos las columnas de una tabla, y menos cuando estamos hablando de un entorno analítico. Igual que en SQL declaramos las columnas que queremos seleccionar vamos a ver como hacerlo en DAX.

DAX-2

También vamos a poder poner un alias a las columnas si queremos otro nombre para mostrar. Veamos cómo:

DAX-3

Ya hemos visto cómo filtrar solo las columnas que necesitamos, ahora vamos a ver otro de los casos más comunes. Filtrar las filas en base a una condición. Normalmente en SQL usamos la cláusula WHERE, en DAX vamos a usar la función FILTER.

DAX-4

Operaciones de agregación

Otra de las cosas básicas más comunes son las agregaciones de datos para sumar o calcular mínimos, máximos, promedios y conteos. Veamos cómo lo hacemos

DAX-5

Funciones avanzadas de filtrado y contexto en DAX

Como hemos comentado al inicio, una de las ventajas del uso de DAX es que nos permite “jugar” con el contexto de los filtros. Así, vamos a ser capaces de realizar funciones con un contexto distinto a lo filtrado en nuestro informe. Gracias al uso de la función CALCULATE vamos a poder realizar nuestros cálculos en un contexto de filtros definido en la propia fórmula y sin tener en cuenta el resto de filtros del informe (excepto RLS pero eso ya es otra cosa)

DAX-6

También, podemos combinar CALCULATE con las funciones ALL o REMOVEFILTERS para que en estos cálculos no intervengan filtros, muy útil cuando queremos usar estos valores totales o promedios en un informe sin que sufran variación por los filtros.

DAX-7

Conclusión

El uso de DAX para leer y filtrar datos nos permite realizar análisis extremadamente detallados y personalizados en Power BI y otras herramientas de Microsoft. Desde funciones básicas de agregación hasta técnicas avanzadas de filtrado y manipulación del contexto de filtro, DAX es una herramienta indispensable para cualquier trabajador de datos.

Hoy solo hemos visto lo más básico, esto es solo la punta del iceberg, a medida que nos familiarizamos con estas funciones y conceptos, podemos desbloquear todo el potencial de nuestros datos, obteniendo métricas valiosas que de otro modo pasarían desapercibidos. Fijaos si este tema es extenso que existen multitud de libros completos solo de DAX como este de José Manuel Pomares que es una auténtica maravilla.

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

Políticas de SQL. Creando servidores Autoadministrados

Una de las mejores características de un buen profesional es que siempre busca formas de hacer su trabajo más eficiente y efectivo. Los administradores de base de datos no estamos exentos de esta norma y, una de las herramientas que tenemos a nuestra disposición para lograr esto es el uso de políticas en SQL Server. Si no habías oído hablar antes de esto no te preocupes, es una opción de SQL Server a menudo subestimada pero al final de este artículo vas a poder ver su gran potencial. Durante las próximas líneas explicaremos cómo las políticas pueden facilitarnos la vida a la hora de gestionar nuestras bases de datos, garantizando tanto el cumplimiento de normas como la eficiencia y el buen rendimiento.

Imaginemos un escenario donde gestionamos múltiples instancias de SQL Server, cada una con sus propias configuraciones, niveles de seguridad y requisitos de rendimiento. No es dificil verdad, es nuestro pan de cada día. Sabrás entonces que mantener la coherencia y el cumplimiento normativo en un entorno así puede ser una tarea exigente. Pues bien, aquí es donde las políticas de administración de SQL Server entran en juego y nos permiten definir, aplicar y automatizar reglas y directrices de una manera estructurada y eficiente.

¿Qué son las Políticas en SQL Server?

Las políticas en SQL Server son un componente del Policy-Based Management (PBM), introducido por primera vez en SQL Server 2008. Esta funcionalidad nos permite definir reglas y condiciones para nuestros servidores y bases de datos, asegurando que cumplan con ciertos estándares de configuración y rendimiento. En términos simples, una política es un conjunto de reglas que se aplican a los objetos de SQL Server para garantizar que se comporten de una manera específica. Estas reglas pueden abarcar desde la configuración del servidor hasta el diseño de la base de datos, y pueden ayudarnos a mantener un alto nivel de calidad y consistencia en nuestras bases de datos.

Por ejemplo, podríamos crear una política que fuerce a que todas las tablas tengan una PK (clave primaria). Esta política se aplicaría a todas las bases de datos en el servidor, y cualquier usuario intente crear una tabla sin PK recibiría un bonito error.

Otra política común es obligar a que todas las bases de datos tengan copias de seguridad regulares. Esta política la podremos configurar para verificar que se haya realizado un backup en las últimas 24 horas, y si no es así, que genere una alerta (que nos envía un correo) para que nosotros como administradores de la base de datos tomemos medidas.

Las políticas también nos pueden ser útiles para mantener la seguridad de nuestras bases de datos. Podríamos tener una política que fuerce a que todas las conexiones al servidor se realicen a través de una conexión segura, o que todas las contraseñas cumplan con ciertos requisitos de complejidad

Componentes Clave de una Política

Antes de ver cómo tenemos que hacer para crear una política personalizada tenemos que tener claros una serie de conceptos que vamos a necesitar. En concreto vamos a estar trabajando con condiciones, facetas y modos de evaluación además de las propias políticas. Veamos que son cada uno de ellos.

  • Condición (Condition): Una condición es un conjunto de expresiones que definen un estado deseado o un comportamiento que queremos comprobar. Por ejemplo, podríamos tener una condición que verifique si la recuperación de base de datos está configurada como «FULL».
  • Facetas (Facets): Las facetas son conjuntos predefinidos de propiedades de los objetos de SQL Server. Por ejemplo, hay facetas para bases de datos, servidores, procedimientos almacenados, entre otros. Cada faceta contiene varias propiedades que podemos utilizar en nuestras condiciones.
  • Política (Policy): Una política combina una condición con una faceta y define cómo y cuándo se debe evaluar esta combinación. Las políticas pueden ser evaluadas bajo demanda, de forma programada o en respuesta a eventos específicos.
  • Modo de Evaluación (Evaluation Mode): Este define cuándo y cómo se evaluará una política. Existen varios modos, incluyendo «On Demand», «On Schedule», «On Change – Prevent» y «On Change – Log Only».

Creando y Administrando Políticas

Para implementar políticas en SQL Server, utilizamos la característica de Administración Basada en Políticas (PBM, por sus siglas en inglés). Como ya hemos visto, PBM nos permite definir políticas, verificar su cumplimiento y aplicarlas automáticamente. Lo primero que deberemos hacer es definir una condición. Una vez que hayamos definido una condición, ya podremos crear una política que utilice esa condición. Por último definiremos su modo de evaluación.

Paso 1: Definir una Condición

El primer paso para crear una política es definir una condición. Supongamos que queremos asegurarnos de que todas nuestras bases de datos estén en modo de recuperación FULL. Para ello, primero definimos una condición:

Abrimos SQL Server Management Studio (SSMS) y navegamos hasta «Management» -> «Policy Management». Hacemos clic derecho en «Conditions» y seleccionamos «New Condition». Le damos un nombre a nuestra condición, por ejemplo, «Database Recovery Full». En «Facet», seleccionamos «Database». En «Expression», añadimos una nueva condición: @RecoveryModel = ‘FULL’.

Paso 2: Crear la Política

Con la condición definida, procedemos a crear la política que la usará:

Hacemos clic derecho en «Policies» y seleccionamos «New Policy». Le damos un nombre, como «Ensure Full Recovery Mode». Asignamos la condición «Database Recovery Full» que creamos anteriormente. En «Against Targets», especificamos los objetos a los que se aplicará esta política, en este caso, todas las bases de datos. Elegimos el modo de evaluación. Para este ejemplo, seleccionamos «On Change – Log Only» para registrar cualquier incumplimiento sin impedir cambios.

Paso 3: Evaluar y Aplicar la Política

Una vez creada la política, podemos evaluarla inmediatamente:

Hacemos clic derecho en la política y seleccionamos «Evaluate». SQL Server nos mostrará todas las bases de datos que no cumplen con la política. Podemos tomar acciones correctivas directamente desde el cuadro de diálogo de evaluación si es necesario.

Paso Extra: Exporta tus políticas

Cuando ya tengas todas tus políticas creadas en uno de tus servidores, no es necesario que las recrees en el resto, simplemente podemos exportarlas y volverlas a importar en tantos servidores como queramos. Para ello solo tendremos que dar clic derecho sobre nuestra política y dar a exportar. Para importar haremos clic derecho sobre la carpeta políticas en nuestro SSMS y le daremos a importar política.

Beneficios del Uso de Políticas

Como venimos comentando, las políticas nos permiten estandarizar configuraciones y prácticas en todas nuestras instancias de SQL Server. De esta manera vamos a lograr asegurar el cumplimiento de normas corporativas y regulatorias. Esto es especialmente importante en entornos que deben cumplir estándares y leyes como GDPR, HIPAA o SOX.

Además, al definir políticas que se evalúan automáticamente, podemos reducir nuestra carga de trabajo y minimizar el riesgo de errores humanos. Por ejemplo, podemos programar evaluaciones periódicas para asegurar que todas nuestras configuraciones de seguridad y rendimiento se mantengan conforme a las políticas definidas.

Pero esto no es todo, las políticas también nos ayudan a identificar y corregir problemas potenciales antes de que se conviertan en problemas mayores. Al tener visibilidad continua de cómo se comportan nuestros servidores y bases de datos en relación con nuestras políticas, podemos ser proactivos en la gestión y el mantenimiento.

Conclusión

El uso de políticas para administrar SQL Server es una práctica que nos permite mantener el control y la coherencia en nuestros entornos de bases de datos. Al definir y aplicar políticas claras, podemos asegurar el cumplimiento normativo, automatizar tareas administrativas y mantener un alto nivel de rendimiento y seguridad. En resumen, las políticas no solo simplifican la administración de SQL Server, sino que también nos permiten ser más eficientes en nuestro trabajo como DBAs. Así que, no esperes más. Pruébalo y considera aprovechar el poder de las políticas para facilitarte la vida.

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, 1 comentario

SQL Ledger en video

Ya hablamos en este blog de la funcionalidad Ledger o Libro de Contabilidad de las bases de datos SQL aquí. Por eso, hoy he decidido dedicarle un vídeo para que podáis verlo en acción y comprobar como de útil puede ser para vosotros.

La función ledger o «libro de contabilidad» en SQL Server y Azure SQL registra operaciones de datos, incluyendo detalles del usuario, fecha, hora y tipo de operación. Cada registro está enlazado criptográficamente al anterior, creando una cadena inalterable. Cada registro tiene una firma digital, lo que previene modificaciones sin rastro. Esto permite auditar y verificar la historia de los datos, detectar manipulaciones y cumplir con normativas de seguridad. En Azure SQL, se ofrece un servicio adicional, Azure SQL Ledger, que añade una capa de seguridad almacenando los hashes del libro de contabilidad en un servicio externo basado en blockchain. Esto lo hace especialmente útil en entornos donde, por su criticidad, tenemos que llevar un control exhaustivo de los cambios realizados en los datos.

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 quieres ver más videos como este puedes encontrarlos todos aquí. 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