Mes: junio 2024

Jun

2024

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:

EXEC sp_configure 'remote admin connections', 1;
GO
RECONFIGURE
GO

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.

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

Local (DAC):

sqlcmd -S servername -U sa -P <12ContraseñaUltra$egurisimaDeLaMuerte34> -A -d master

Remoto (RDAC):

sqlcmd -S servername,1434 -U sa -P <12ContraseñaUltra$egurisimaDeLaMuerte34> -A -d master

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!

Jun

2024

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:

Power Query recibe el script en código M desde el editor avanzado.
El mecanismo de plegado de consultas envía una consulta de metadatos al origen de datos para evaluar sus características.
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.
Power Query consulta el origen de datos mediante una consulta nativa.
El origen de datos devuelve los datos al motor de Power Query.
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.
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.

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.

Jun

2024

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.

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!

Jun

2024

Optimizaciones en la administración de SSIS

Os voy a contar un caso real. Hace años, trabajando yo en un cliente, empezamos a notar una degradación de rendimiento en determinadas operaciones sobre la base de datos. Pero solo pasaba con las consultas que se ejecutaban desde determinados paquetes SQL Server Integration Services (SSIS). Antes de que podáis pensar que esas consultas no estaban optimizadas os diré que lo estaban, las mismas consultas ejecutadas directamente contra la base de datos funcionaban. Entonces, el problema tenía que estar en SSIS.

La siguiente prueba fue validar la ejecución de un paquete manualmente desde visual estudio y uno ya desplegado en el catálogo.El primero de ellos funcionaba como se esperaba mientras que el ya desplegado tardaba mucho más. ¿Qué estaba pasando? Pues no me enrollo más.

El problema era el mantenimiento (concretamente la falta de mantenimiento) en la base de datos del catálogo SSIS, la SSISDB. Además todo esto se agravaba debido a una mala elección en el nivel de detalle de los logs que deja el catálogo de SSIS.

¿Qué es la SSISDB?

Como hemos dicho, la SSISDB es la base de datos del catálogo de SQL Server Integration Services. En ella se van a desplegar los paquetes, va a almacenar todos sus metadatos (proyectos, entornos, parámetros, etc…) y, además, todo el historial de ejecuciones.

¿Qué mantenimiento necesita la SSISDB?

Como toda base de datos en SQL Server, las tablas sufren variaciones que conlleva fragmentación de los índices. Por este motivo, como cualquier otra base de datos, vamos a tener que implementar un mantenimiento de índices y de estadísticas de las tablas. Además, aunque algunos datos son fácilmente recuperables desplegando de nuevo los proyectos, por seguridad debemos programar chequeos de integridad y copias de seguridad frecuentes.

Mantenimientos específicos de SSISDB

Vale, la SSISDB necesita el mismo mantenimiento que el resto de mis bases de datos pero, además de los mantenimientos de una base de datos normal, existen una serie de consideraciones específicas que debemos tener en cuenta. Como hemos visto, entre otras cosas esta base de datos almacena el historial de ejecuciones de nuestros paquetes y, como todas las tablas de log, estas deben ser purgadas regularmente.

Si accedemos a las propiedades de nuestro catálogo de SSIS vamos a ver que por defecto está habilitada la limpieza de registros antiguos de log con un periodo de retención de un año. Pero, ¿realmente necesitamos un año de log? Para mi la respuesta es no. Y es que yo siempre hablo con mis clientes y nunca hemos considerado necesario más de una semana o un mes a lo sumo. Otra de las opciones que vamos a encontrar en este apartado es el nivel de log que se va a almacenar pero, esto es más extenso y luego volvemos sobre ello.

Antes de meternos de lleno con el nivel de log vamos a ver otra de las opciones de purgado de datos que podemos encontrar en las propiedades del catálogo, el número de versiones de los proyectos. El catálogo de SSIS por defecto almacena un máximo de 10 versiones por proyecto y va limpiando las anteriores. Esta cantidad puede ser correcta o no para ti, valora con el equipo de desarrolladores de los paquetes y ten en cuenta si ya existe otro control de versiones a nivel de desarrollo como un Git.

Nivel de log de SSIS

Como hemos visto antes, el nivel de registro de SSIS es una característica que nos permite a los administradores de bases de datos elegir el nivel de verbosidad del log de ejecuciones de los paquetes SSIS almacenados en el catálogo de integration services. Por defecto consta de cuatro niveles que son Ninguno, Básico, Rendimiento y Detallado.

Ninguno: Como su nombre indica, este nivel no registra ninguna información. Es útil cuando se tiene confianza en el rendimiento del paquete y no se requiere seguimiento.
Básico:Este es el nivel predeterminado y proporciona suficiente información para entender el flujo de ejecución y solucionar problemas comunes.
Rendimiento: Este nivel está diseñado para registrar información que ayuda a solucionar problemas de rendimiento. Registra sólo los eventos necesarios para proporcionar información sobre el rendimiento.
Detallado: Este nivel registra información detallada sobre la ejecución del paquete. Aunque puede ser útil para solucionar problemas complejos, también puede generar una gran cantidad de datos de registro.

Bajo mi punto de vista, y siendo totalmente sincero con vosotros, ninguno de estos 4 niveles se adapta a las necesidades reales de un entorno de producción. No registrar eventos es un peligro y no seríamos capaces de depurar un error, el nivel básico (el predeterminado) almacena demasiada información inutil (he visto hasta reportes de cientos de hojas para una única ejecución de un paquete). Lo mismo me pasa con el nivel de rendimiento que, me da datos que no necesito en mi dia a dia de un servidor productivo. El detallado es para ni plantearselo, para mi, solamente tiene sentido en un servidor de pruebas si estás depurando la ejecución de los paquetes.

Por suerte para nosotros, existe la posibilidad de crear un nivel de registro personalizado solo con los eventos y las estadísticas que queramos ver. En mi caso, acostumbro a crear un nivel “Solo Errores” que es lo único que me interesa en la mayoría de los casos.

Niveles de log personalizados en SSIS

Para crear un nivel de log personalizado lo primero que haremos será acceder a la opción dedicada a este fin en el menú contextual que se abre al hacer clic derecho sobre nuestro catálogo. En la ventana que se nos abrirá podremos crear uno o varios niveles personalizados. En las imágenes os muestro como lo suelo hacer yo.

Una vez creado el nivel personalizado, iremos a las propiedades del catálogo y lo configuraremos como nivel por defecto. Esto hará que todos los nuevos jobs que creemos para ejecutar los paquetes o todas las nuevas ejecuciones manuales de este paquete se hagan bajo este nivel de registro. Sin embargo, todos los jobs que ya existieran antes de cambiar el nivel de log seguirán con el antiguo nivel por defecto (básico si no lo habíais cambiado) por lo que habrá que cambiarlos a mano.

Cambiar el nivel de log para los jobs de SSIS existentes

Uno que ya es perro viejo pero sobre todo es vago, no suele estar por la labor de cambiar cosas a mano en todos los jobs. Sobre todo en entornos donde la cantidad de paquetes es elevada por este motivo tengo una manera de proceder para automatizar el proceso. Os detallo los pasos.

Elijo un paso de un job de ejemplo.
Localizo el paso seleccionado en la tabla msdb.dbo.sysjobstesps y copio el campo command.
Cambio a mano el nivel de log para ese paso.
Vuelvo a la tabla msdb.dbo.sysjobstesps y copio nuevamente el campo command.
Creo un script para reemplazar en todos los pasos tipo ‘SSIS’ los cambios que he observado en el campo.

Por ejemplo:

UPDATE msdb.dbo.sysjobsteps 
SET command = REPLACE(command, '$ServerOption::LOGGING_LEVEL(Int16)\"";1 ','$ServerOption::LOGGING_LEVEL(Int16)\"";100 /Par "\"$ServerOption::CUSTOMIZED_LOGGING_LEVEL\"";ErrorOnly ')
WHERE subsystem='SSIS'

Conclusión

Una buena gestión y administración de nuestro catálogo SSIS es crucial para su futuro rendimiento. Dedica el tiempo que necesites a estas optimizaciones, los usuarios lo van a agradecer. Por otro lado, puede ser interesante configurar niveles con más detalle de log en tus servidores de pruebas para facilitar el debugueado a los desarrolladores. Solo tu conoces tu entorno, comentalo con los usuarios y, seguro, conseguirás el equilibrio perfecto.

Jun

2024

Tipos de dato Fecha y Hora

Uno de los retos más importantes que vamos a enfrentar cuando trabajamos con datos es la gestión de las fechas y horas. Al igual que nos pasaba con los datos numéricos, elegir el tipo de datos de fecha y/o hora correcto es de vital importancia y no debe ser ignorado. En SQL Server, tenemos a nuestra disposición varios tipos de datos para manejar la fecha y la hora. Pero, ¿sabemos realmente cuándo y cómo utilizar cada uno de ellos? En este artículo, vamos a profundizar en este tema pues no es solo tarea del diseñador de la base de datos sino que, como DBAs tendremos que asesorar al usuario para evitar incidencias con las conversiones de datos en un futuro.

Tipos de Datos de Fecha y Hora

Tanto SQL Server como Azure SQL ofrecen varios tipos de datos para trabajar con fechas y horas: datetime, smalldatetime, date, time, datetime2 y datetimeoffset. Cada uno de ellos tiene unas particularidades y responde a unas necesidades concretas que deberemos conocer para una elección correcta del tipo de dato llegado el momento.

Datetime y SmallDatetime (fecha y hora)

Datetime y SmallDatetime son los tipos de datos más antiguos y existen desde las primeras versiones de SQL Server. Nos van a permitir manejar las fechas y las horas sin demasiada complicación aunque por contra perderemos detalle comparado con otros tipos más modernos. En concreto, Datetime tiene una precisión de hasta 3 milisegundos, mientras que SmallDatetime tiene una precisión de hasta un minuto.

Date y Time (solo fecha y solo hora)

Con la llegada al mercado de SQL Server 2008 se introdujeron los tipos de datos Date y Time. Estos tipos de datos nos permiten almacenar únicamente la fecha o la hora, respectivamente respondiendo así a una necesidad hasta entonces sin cubrir.

Datetime2 (fecha y hora)

Datetime2 es una evolución del tipo de datos datetime que tiene una mayor precisión y un rango de fechas más amplio. Puede tener una precisión de hasta 100 nanosegundos lo que lo convierte en compatible con los estándares ANSI e ISO 8601. Es el tipo de datos que yo te recomendaría usar si estás diseñando una nueva base de datos desde el principio y no te quieres complicar en exceso.

Datetimeoffset (fecha, hora y zona horaria)

Por último, Datetimeoffset es el tipo de datos de fecha y hora más completo que ofrecen SQL Server y Azure SQL. Es similar a datetime2, pero incluye información sobre la zona horaria. Es útil cuando se trabaja con diferentes zonas horarias pero, si no es nuestro caso, este extra de información solo va a conllevar más consumo de espacio y, por tanto, de recursos a la hora de trabajar.

Ejemplos

Veamos todos estos tipos de datos en un ejemplo para que se entienda mejor:

Datetime vs Datetime2: Conversiones entre tipos de datos

Como ya hemos visto, Datetime2 es especialmente interesante debido a su gran precisión y rango. Esto, que a priori es una ventaja, puede llevarnos a errores cuando convertimos a Datetime2 desde Datetime. Si os fijáis en la captura del apartado anterior yo he usado la función SYSDATETIME() que devuelve un resultado Datetime2 y no GETDATE() que devuelve Datetime. Veamos el mismo ejemplo con la función GETDATE()

Como veis, al convertir un valor Datetime a Datetime2 no se rellena con 0 la precisión faltante sino que, en este caso, se ha rellenado con un 3 periódico. Si volvéis a leer ahora lo que os he contado de Datetime veréis que os he dicho que la precisión es de hasta 3 milisegundos y en ningún momento os he dicho que tenga una precisión de milisegundos. Es decir, la precisión es de uno entre 300 fracciones de segundo y no de 1/1000 segundos.

Al convertir ese valor Datetime a Datetime2 no tenemos información para completar ese extra de precisión. Además, es imposible representar en un número en base 10 el valor 1/300 por eso vemos ese 333 de manera infinita en los decimales.

Estilos de fecha y hora

Además de los tipos de datos, un aspecto clave en la representación de las fechas almacenadas en la base de datos es el estilo. Por defecto, se muestra en formato Año, Mes y Dia seguido de la hora en Horas, Minutos, Segundos y Milisegundos. Sin embargo, podremos actuar sobre este comportamiento y elegir el estilo que deseemos con unos valores a la hora de convertir los datos de fecha a texto para su representación.

Podéis encontrar todos los estilos disponibles en esta documentación oficial.

Conclusión

Manejar correctamente los tipos de datos de fecha y hora en SQL Server o Azure SQL es esencial para mantener la integridad de los datos y realizar cálculos precisos. Aunque puede parecer un tema sencillo al principio es más complejo cuando empiezas a trabajar con ello y a profundizar. Sin embargo, como todo, con un poco de práctica y estudio, se puede dominar. Espero que este artículo te haya ayudado en el dominio de los tipos de datos de fecha en SQL Server y Azure SQL. 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!

Mes: junio 2024

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

¿Qué es DAC y cómo funciona?

¿Tipos de DAC?

¿Por qué necesitas habilitar RDAC?

Habilitar Remote DAC

Limitaciones de DAC

¿Cómo conectar usando DAC?

Conclusión

Plegado de consultas en Power BI

¿Qué es el plegado de consultas?

¿Qué es Power Query?

¿Cómo funciona el plegado de consultas?

¿Por qué es importante?

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

Niveles de plegado de consulta

Conclusión

SQL AVANZADO – Agrupaciones con Cube y Rollup

Optimizaciones en la administración de SSIS

¿Qué es la SSISDB?

¿Qué mantenimiento necesita la SSISDB?

Mantenimientos específicos de SSISDB

Nivel de log de SSIS

Niveles de log personalizados en SSIS

Cambiar el nivel de log para los jobs de SSIS existentes

Conclusión

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes