SQL Server

Aquí encontraras todos nuestros post relacionados con SQL Server desde cero hasta un nivel avanzado. Desde infraestructura hasta modelado de datos.

Propiedades Extendidas en SQL Server

Hace unos días, en nuestro canal de telegram surgió un tema interesante sobre documentación de tablas y sus columnas en SQL Server. Una de las formas más sencillas para documentar nuestros objetos en SQL Server de forma nativa (sin recurrir a aplicaciones de terceros) es el uso de las propiedades extendidas. Personalmente pienso que, si no tienes una herramienta de documentación externa,  las propiedades extendidas son una alternativa indispensable para cualquier DBA o trabajador de datos. En este artículo, veremos qué son las propiedades extendidas, sus usos principales, y cómo podemos mejorar la gestión y documentación de nuestros entornos de SQL Server.

¿Qué son las Propiedades Extendidas en SQL Server?

En resumidas cuentas, las propiedades extendidas son metadatos adicionales que podemos asociar a objetos dentro de SQL Server. Estas propiedades, presentes en SQL Server desde SQL 2008, son unas etiquetas clave-valor que nos van a permitir almacenar información extra, como descripciones, anotaciones y cualquier dato relevante que consideremos útil para la administración y documentación de nuestra base de datos. No te creas que esto es todo, tú en tu escenario le vas a poder dar cualquier uso que te imagines y que sea compatible con una etiqueta clave-valor.

Usos Comunes de las Propiedades Extendidas

Como ya hemos adelantado, las propiedades extendidas tienen tantos usos como tu creatividad logre imaginar. Os voy a contar los principales con los que yo me he encontrado a lo largo de estos años.

  • Documentación de Objetos: Podemos usar las propiedades extendidas para la documentación de tablas, columnas, procedimientos almacenados, funciones y otros objetos de manera que esta tarea se vuelva más manejable y, sobre todo, la información se almacene en la propia base de datos.
  • Auditoría y Cumplimiento: De la misma manera, se pueden utilizar las propiedades extendidas para almacenar información de auditoría y cumplir con regulaciones específicas como etiquetado de datos confidenciales o sensibles.
  • Metadatos Personalizados: Más de lo mismo, podemos usar propiedades extendidas para agregar metadatos específicos de nuestra organización y que de otra manera no estarían cubiertos por los atributos estándar de SQL Server.

Documentando objetos en SQL Server con Propiedades Extendidas

Como hemos visto, uno de los usos más comunes y útiles de las propiedades extendidas es la documentación de objetos. Esta capacidad no solo nos facilita el mantenimiento, sino que también mejora la colaboración entre equipos de desarrollo y los administradores de las bases de datos. Al tener documentado quien creó una tabla o que proceso o persona se encarga de alimentar los datos, por ejemplo, los DBAs vamos a tener más fácil encontrar a las personas afectadas ante una incidencia. O, si sabemos quien desarrolló ese procedimiento que va lento, vamos a poder tomar medidas correctivas (siempre respetando los derechos humanos, recordad).

Documentación de Tablas y Columnas

Podemos agregar descripciones detalladas a nuestras tablas y columnas para aclarar su propósito y uso. Por ejemplo, podemos describir la función de una columna específica, lo que es particularmente útil en bases de datos grandes y complejas.

Ejemplo Práctico

Supongamos que tenemos una tabla Clientes y queremos documentar su columna EmailAlternativo. Podemos hacerlo con el siguiente script:

Con este script, hemos agregado una propiedad extendida a la columna EmailAlternativo de la tabla Clientes en el esquema dbo, describiendo que almacena el correo electrónico del cliente alternativo. Como siempre pasa, cuanto más descriptivas sean las descripciones más fácil será entenderlas.

Documentación de Vistas, Procedimientos Almacenados y Funciones

Las vistas, procedimientos almacenados y funciones también pueden beneficiarse de las propiedades extendidas. Podemos documentar su propósito, parámetros y cualquier otra información relevante que facilite su uso y mantenimiento.

Ejemplo Práctico

Consideremos un procedimiento almacenado llamado usp_ObtenerClientesActivos. Podemos documentar su propósito con el siguiente script:

Gestión de Propiedades Extendidas

La forma sencilla de gestionar las propiedades extendidas es a través del entorno gráfico, con un clic derecho sobre el objeto al que deseemos añadir una propiedad extendida podremos entrar en la ventana de propiedades y ahí encontraremos el apartado para las propiedades extendidas. Sin embargo esto no es rápido cuando tienes que ir columna a columna de una tabla documentando sus atributos. Para ello podremos usar los procedimientos almacenados de sistema.

Crear Propiedades Extendidas

Para añadir una propiedad extendida, utilizaremos el procedimiento almacenado sp_addextendedproperty. Este procedimiento nos permite especificar el nombre y el valor de la propiedad, así como el objeto al que se va a asociar.

Modificación de Propiedades Extendidas

Si necesitamos actualizar una propiedad extendida existente, utilizaremos el procedimiento sp_updateextendedproperty. Este procedimiento nos permite cambiar el valor de una propiedad extendida sin necesidad de eliminarla y volver a crearla.

Eliminación de Propiedades Extendidas

Para eliminar una propiedad extendida, utilizaremos el procedimiento sp_dropextendedproperty. Este procedimiento elimina completamente la propiedad especificada del objeto.

Consultar las Propiedades Extendidas existentes

La finalidad de las propiedades extendidas siempre va a ser poder consultarlas, si no para qué íbamos a estar haciendo todo este trabajo, ¿verdad?. En este sentido Microsoft pone a nuestra disposición la función sys.fn_listextendedproperty pero su uso está muy limitado y a mi no me gusta. Existen otras herramientas externas capaces de usar las propiedades extendidas para la generación automática de documentación, como SQL Server Data Tools (SSDT) y otros sistemas de documentación de bases de datos. Estas herramientas pueden extraer las propiedades extendidas y generar documentación completa y detallada de la base de datos. Sin embargo, como el objetivo de este post es no salirnos de SQL y cómo sabéis que yo soy partidario de usar las tablas y vistas de sistema, en este caso no iba a ser menos. Os dejo el script que yo uso:

Conclusión

Las propiedades extendidas en SQL Server son una opción muy útil y válida para la documentación de nuestras bases de datos. Nos permiten añadir metadatos personalizados a nuestros objetos, mejorando la claridad, la colaboración y el cumplimiento normativo. Ya sea que estemos documentando tablas, columnas, procedimientos almacenados, funciones o cualquier otro objeto, las propiedades extendidas nos facilitan una gestión más eficiente y eficaz de nuestros datos en SQL Server. Además, la capacidad de automatizar la adición y gestión de propiedades extendidas mediante scripts de SQL amplía aún más sus aplicaciones, permitiéndonos mantener nuestras bases de datos bien documentadas y organizadas sin un esfuerzo manual excesivo. Aprovechando estas características, podemos transformar nuestras bases de datos en repositorios de información clara y útil, accesibles para todos los miembros de nuestro equipo y para las aplicaciones que interactúan con ellas.

En resumen, no solo conocer sino dominar el uso de las propiedades extendidas es una habilidad importante para cualquiera que busque optimizar la gestión y documentación de sus bases de datos en SQL Server. 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

DBA vs IA: Fight! La prueba de si la IA te va a quitar el trabajo

Los avances en inteligencia artificial son imparables, eso está claro. Además está claro que son la tendencia en el mercado, parece que términos como big data, cloud o blockchain son cosa del pasado y ahora lo moderno es tener IA hasta en el inodoro. Todas las empresas compiten por añadir IA a sus productos a la par que apuestan por integrar asistentes como ChatGPT o Copilot a sus procesos para facilitar la vida de los trabajadores. Y ojo que a mi me parece muy bien el avance de la IA pero no debemos olvidarnos de nuestra propia inteligencia natural. Por lo menos hasta que esto avance un poco más y vivamos en un mundo donde trabajen robots con IA y nosotros podamos dedicarnos a la holganza más absoluta. No me enrollo más, que lo que os vengo a contar hoy es muy interesante, una prueba más de cómo está ahora la IA en el ámbito de la administración de base de datos. Que cada uno saque sus conclusiones de si puede o no abandonarse a la vida contemplativa gracias a que una máquina complete sus tareas.

Definiendo la prueba 

Os pongo en situación, me encontraba yo desempeñando mis labores diarias, por las que me pagan no estas tareas del blog que lo hago por amor al arte. En ese momento estaba empezando a tomar el control de una nueva instancia de SQL, en concreto una instancia administrada en Azure. Se trata de una instancia compartida por varios microservicios donde cada uno de ellos tiene su base de datos, en principio, totalmente independiente a las demás. Por lo que he podido ver en el resumen de consumo de recursos del portal web de Azure, el uso de CPU es elevado en esta instancia y, por desgracia, ahí se queda todo lo que puedes ver en esta ventana. Igual que cuando miras el activity monitor de un SQL en local la verdad.

Como es un servidor compartido y hay varias bases de datos debo priorizar por lo que lo lógico es empezar por la que mayor consumo hace de los recursos. Partimos de una gran ventaja, al ser Azure Query Store está habilitado por defecto en todas las bases de datos recolectando datos sin que yo haya tenido que decírselo pero, esta es una solución que muestra datos a nivel base de datos y no de instancia. No me sirve de primeras. Necesito otra solución y me parece una buena oportunidad de poner a prueba a la IA antes de tirar de mi navaja suiza de scripts. Como estamos hablando de Azure vamos a hacer que todo quede en casa y preguntar a Copilot.

Será Copilot un buen DBA, pongámoslo a prueba

Os dejo con lo que estáis todos esperando, la conversación íntegra con Copilot. Luego al final os daré mis conclusiones.

Round 1

Roberto:

Tengo una instancia administrada de sql en azure con una docena de bases de datos. Necesito saber cual de las bases de datos tiene un mayor consumo de recursos. ¿Cómo puedo hacerlo?

Copilot:

Para monitorear el consumo de recursos de las bases de datos en una instancia administrada de SQL en Azure, puedes utilizar el servicio de Azure SQL Analytics en Azure Monitor. Aquí te dejo los pasos generales para hacerlo:
Habilita la supervisión de diagnóstico para tu instancia administrada de SQL Server en Azure. Esto se hace en la sección de “Diagnóstico” en la configuración de tu instancia en el portal de Azure.

  1. Configura la exportación de registros a un espacio de trabajo de Log Analytics. Durante la configuración del diagnóstico, puedes elegir enviar los datos a un espacio de trabajo de Log Analytics existente o crear uno nuevo.
  2. Instala la solución de Azure SQL Analytics desde la galería de soluciones en tu espacio de trabajo de Log Analytics.
  3. Una vez que la solución esté instalada y los datos comiencen a fluir, puedes ver los paneles de Azure SQL Analytics para obtener detalles sobre el consumo de recursos. Hay un panel específico llamado “SQL Managed Instance Resource Usage” que proporciona detalles sobre el uso de recursos a nivel de base de datos.

Recuerda que puede llevar algún tiempo hasta que los datos estén disponibles en los paneles después de habilitar la supervisión de diagnóstico.

Espero que esto te ayude a identificar la base de datos que consume más recursos. Si tienes más preguntas, no dudes en preguntar. 😊

Round 2

Roberto:

¿Hay manera de hacerlo desde las herramientas nativas de SQL en SSMS?

Copilot

Sí, puedes usar las herramientas nativas de SQL Server Management Studio (SSMS) para monitorear el consumo de recursos de las bases de datos en una instancia administrada de SQL en Azure. Aquí te dejo los pasos generales para hacerlo:

  1. Conéctate a tu instancia administrada de SQL Server en Azure usando SSMS.
  2. Abre una nueva consulta en la base de datos que deseas monitorear.
  3. Ejecuta una consulta de DMV (Dynamic Management View) para obtener información sobre el consumo de recursos. Por ejemplo, puedes usar la vista sys.dm_db_resource_stats para obtener estadísticas de uso de recursos a nivel de base de datos. Aquí tienes un ejemplo de cómo podría ser esta consulta:

SELECT 

    database_name, 

    avg_cpu_percent, 

    avg_data_io_percent, 

    avg_log_write_percent

FROM 

    sys.dm_db_resource_stats

ORDER BY 

    avg_cpu_percent DESC;

Esta consulta te dará el porcentaje promedio de CPU, I/O de datos y escritura de log utilizados por cada base de datos, ordenados por el uso de CPU.

Por favor, ten en cuenta que estas vistas de gestión dinámica solo mantienen datos de las últimas 2 horas, por lo que si necesitas un seguimiento a largo plazo, te recomendaría utilizar Azure SQL Analytics como mencioné anteriormente.

Espero que esto te ayude a identificar la base de datos que consume más recursos. Si tienes más preguntas, no dudes en preguntar. 😊

Round 3

Roberto:

Esa DMV no tiene database_name

Copilot:

Tienes razón, lamento el error. La vista de gestión dinámica sys.dm_db_resource_stats no incluye el nombre de la base de datos. En su lugar, puedes usar la vista sys.resource_stats para obtener estadísticas de uso de recursos a nivel de base de datos en una instancia administrada de SQL Server en Azure. Aquí tienes un ejemplo de cómo podría ser esta consulta:

SELECT 

    database_name, 

    avg_cpu_percent, 

    avg_data_io_percent, 

    avg_log_write_percent

FROM 

    sys.resource_stats

ORDER BY 

    avg_cpu_percent DESC;

Esta consulta te dará el porcentaje promedio de CPU, I/O de datos y escritura de log utilizados por cada base de datos, ordenados por el uso de CPU.

Por favor, ten en cuenta que sys.resource_stats solo mantiene datos de las últimas 14 días.

Espero que esto te ayude a identificar la base de datos que consume más recursos. Si tienes más preguntas, no dudes en preguntar. 😊

Round 4

Roberto:

El objeto sys.resource_stats al que haces referencia no existe ni en Azure MI ni en SQL Server

Copilot:

Mis disculpas por el error anterior. En las instancias administradas de Azure SQL, no se dispone directamente de una vista de gestión dinámica (DMV) que proporcione el uso de recursos a nivel de base de datos.

Sin embargo, puedes obtener información sobre el uso de recursos a nivel de instancia utilizando la DMV sys.dm_instance_resource_governor_workloads. Aunque esta DMV no desglosa el uso de recursos por base de datos, puede darte una idea del uso total de recursos de tu instancia administrada.

Si necesitas un desglose del uso de recursos a nivel de base de datos, te recomendaría considerar el uso de Azure SQL Insights, que es una característica de Azure Monitor. SQL Insights proporciona una visión más detallada del rendimiento y el uso de recursos a nivel de base de datos.

Lamento cualquier confusión causada y agradezco tu paciencia. Si tienes más preguntas o necesitas más ayuda, no dudes en preguntar. 😊

Round 5: KO

Roberto:

Yo creo que sí que se puede hacer usando esta consulta, ¿es cierto?

SELECT 

        [Database],

        CONVERT (DECIMAL (6, 3), [CPUTimeInMiliSeconds] * 1.0 / 

        SUM ([CPUTimeInMiliSeconds]) OVER () * 100.0) AS [CPUTimeAsPercentage]

     FROM 

      (SELECT 

          dm_execplanattr.DatabaseID,

          DB_Name(dm_execplanattr.DatabaseID) AS [Database],

          SUM (dm_execquerystats.total_worker_time) AS CPUTimeInMiliSeconds

       FROM sys.dm_exec_query_stats dm_execquerystats

       CROSS APPLY 

        (SELECT 

            CONVERT (INT, value) AS [DatabaseID]

         FROM sys.dm_exec_plan_attributes(dm_execquerystats.plan_handle)

         WHERE attribute = N’dbid’

        ) dm_execplanattr

       GROUP BY dm_execplanattr.DatabaseID

      ) AS CPUPerDb

Copilot:

Sí, tienes razón. La consulta que has proporcionado utiliza las vistas de gestión dinámica sys.dm_exec_query_stats y sys.dm_exec_plan_attributes para obtener el tiempo total de CPU utilizado por cada consulta, agrupado por base de datos.

La parte interna de la consulta suma el tiempo de CPU para cada base de datos. La parte externa de la consulta convierte ese tiempo en un porcentaje del tiempo total de CPU.

Por lo tanto, esta consulta te dará una idea de qué bases de datos están consumiendo más tiempo de CPU en tu instancia administrada de SQL Server en Azure.

Gracias por compartir esta consulta, es un buen ejemplo de cómo se pueden utilizar las vistas de gestión dinámica para obtener información detallada sobre el uso de recursos. 😊

Conclusiones de esta prueba

Tontuna natural 1 – Inteligencia Artificial 0. 

Y digo tontuna natural porque he perdido mi tiempo hablando con una máquina cuando ya tenía la respuesta antes de empezar. Y peor aún, he hecho el intento de decirle como lo tiene que hacer como si estos modelos se alimentasen del feedback de los usuarios. Pero bueno, quedémonos con que por lo menos, la prueba me ha servido para llenar un artículo y entreteneros con esta lectura ligera.

Analizando los resultados lo que saco en claro es que Copilot me ha dado más caritas sonrientes que respuestas correctas y, al menos esta es mi impresión, esta es la tónica habitual en cuanto las preguntas se especializan y requieren de experiencia profesional. Y no solo lo digo yo, hablando con más gente el otro día todos comentaban como en fórmulas DAX por ejemplo, Copilot falla más que acierta cuando pasas de preguntas básicas y le exiges un poco. La IA es un gran aliado en tareas repetitivas o sencillas y yo la uso mucho pero siempre hay que tener claras sus limitaciones y supervisar todo lo que nos dice. No estamos aún en situación de poner en producción código generado por IA sin mirarlo y retocarlo.

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
Nueva actualización crítica SQL Server

Nueva actualización crítica SQL Server

Una versión anterior de este artículo fue publica el pasado mes de abril. El artículo de hoy es muy importante ya que Microsoft ha publicado ayer mismo una actualización de seguridad crítico para SQL Server. Esto me ha llevado a escribir esto y “colarlo” por delante de lo que ya estaba programado en el blog. Vamos a aprovechar esta oportunidad para descubrir todo lo que rodea a las actualizaciones de SQL y que debemos saber y por último ya descubriremos por qué es tan importante esto que os estoy compartiendo justo hoy. 

Como ya hemos dicho en muchas ocasiones, en todo lo relacionado con el mundo de la tecnología, el cambio es la única constante. Como profesionales de bases de datos, sabemos que mantener nuestros sistemas actualizados es crucial para garantizar su rendimiento, seguridad y eficiencia y por tanto para desempeñar correctamente nuestro trabajo. En este sentido SQL Server no se queda atrás y se renueva y mejora continuamente con actualizaciones. Recuerda que en el blog tenemos un artículo dedicado a la actualización segura de Always On.

¿Qué son las Actualizaciones de SQL Server?

Empecemos por el principio, ¿qué son las actualizaciones de SQL Server? Las actualizaciones de SQL Server son mejoras y correcciones que Microsoft lanza periódicamente para su sistema de gestión de bases de datos, SQL Server. Estas actualizaciones pueden incluir desde parches de seguridad hasta nuevas funcionalidades, pasando por mejoras de rendimiento y solución de incidencias.

Actualizar SQL Server trae consigo una serie de ventajas como ya hemos visto, no solo tendremos una mayor seguridad seguridad sino que se habilitarán nuevas funcionalidades, se mejorará el rendimiento y se solucionarán los errores.

Tipos de Actualización de SQL Server

Las actualizaciones de SQL Server se pueden clasificar en dos grandes grupos, y dentro de estos encontraremos varias categorías principales. Como grandes tipos podemos diferenciar las actualizaciones mayores, que implican un cambio de versión y las menores que no implican cambio de versión. Dentro de este último grupo tenemos actualizaciones de Service Packs, Acumulativas y de seguridad. 

Actualización Mayor de SQL Server

Las actualizaciones mayores de SQL Server son lanzamientos completos de nuevas versiones del sistema de gestión de bases de datos. Estas actualizaciones suelen incluir una gran cantidad de nuevas funcionalidades, mejoras de rendimiento y seguridad, y a veces cambios en la arquitectura del sistema.

Por ejemplo, SQL Server 2022, que se lanzó en noviembre de 2022, es la versión más reciente hasta la fecha. Esta versión continúa con las mejoras en seguridad y rendimiento, proporcionando una plataforma de datos moderna para escenarios híbridos.

Las actualizaciones mayores también pueden incluir cambios en la compatibilidad con versiones anteriores, por lo que es importante revisar cuidadosamente las notas de la versión antes de actualizar a una nueva versión mayor.

Actualización menores de SQL Server

Además de las actualizaciones mayores Microsoft proporciona un soporte continuo a las versiones de SQL Server que aún están dentro de los plazos de mantenimiento incluyendo las versiones generales de distribución (GDRs), los paquetes de servicio (SPs), y las actualizaciones acumulativas (CUs). Esto es lo que se conoce como actualizaciones menores y también es importante mantenernos al día con ellas.

  • Service Packs (SPs): Son colecciones de actualizaciones y correcciones de errores que se lanzan periódicamente. Los SPs suelen incluir todas las actualizaciones acumulativas y parches de seguridad lanzados hasta la fecha de su publicación. Este tipo de actualizaciones no se han vuelto a publicar desde el Service Pack 3 para SQL Server 2016, ninguna de las últimas versiones de SQL Server ha tenido más Service Pack. 
  • Actualizaciones acumulativas (CUs): Son conjuntos de actualizaciones y correcciones de errores que se lanzan más frecuentemente que los SPs. Las CUs incluyen todas las actualizaciones desde la última CU o SP. 
  • Parches de seguridad: Son actualizaciones críticas que se lanzan para corregir vulnerabilidades específicas de seguridad detectadas en SQL Server. Son las más importantes y como tal se actualizarán automáticamente desde Windows Update si tenemos marcada la opción de actualizar otros productos de Microsoft. Esto es un arma de doble filo pues la actualización requiere parada del servicio y personalmente no lo recomiendo. Yo prefiero actualizar manualmente los servidores de manera controlada, empezando por entornos de desarrollo y pruebas y terminando por los más críticos de producción.

Configuración de Base de Datos: Query_Hotfixes

La configuración de alcance de base de datos Query_Hotfixes es una característica introducida en SQL Server 2016. Esta configuración permite habilitar o deshabilitar las correcciones del optimizador de consultas a nivel de base de datos.

Las correcciones del optimizador de consultas son mejoras o cambios en el optimizador de consultas que se introducen en las actualizaciones de SQL Server CU o SP. Antes de SQL Server 2016, para aprovechar estas mejoras, era necesario habilitar la traza 41992. Sin embargo, a partir de SQL Server 2016, estas mejoras se habilitan en la configuración de la base de datos. Para habilitar las correcciones del optimizador de consultas, puedes usar el siguiente comando:

ALTER DATABASE SCOPED CONFIGURATION SET QUERY_OPTIMIZER_HOTFIXES = ON;

Este comando configura la base de datos para utilizar todas las correcciones del optimizador de consultas. Por esto, es importante recordar que cualquier cambio en esta configuración sólo afectará a la base de datos en la que se ejecuta el comando y que por defecto esta característica viene siempre deshabilitada.

El Último parche GDR: 09/07/2024

El pasado 9 de julio de 2024, Microsoft lanzó una actualización de seguridad para SQL Server 21016, 2017, 2019 y 2022. Esta actualización resuelve varias vulnerabilidades críticas, en particular en los controladores ODBC y OLE DB Nativos de Microsoft para SQL Server. Antes de esta actualización o si aún no la hemos instalado, estas vulnerabilidades podrían permitir la ejecución remota de código. Esto significa que un atacante podría tomar el control de nuestros sistemas, afectando gravemente a la integridad y confidencialidad de la información. Al instalar esta actualización, se protegen los sistemas contra estas amenazas, reforzando la seguridad de nuestras bases de datos. Es importante destacar que para aplicar esta actualización, debes tener instalado SQL Server 2016, 2017, 2019 o 2022. Se han publicado los parches para las versiones sin ninguna CU o para los sistemas actualizados a la última CU de cada versión.

Vulnerabilidades corregidas en esta actualización

Esta es la lista de CVEs corregidos en esta actualización:

Vulnerabilidades de ejecución remota de código en el controlador ODBC de Microsoft para SQL Server:

  • CVE-2024-28929
  • CVE-2024-28930
  • CVE-2024-28931
  • CVE-2024-28932
  • CVE-2024-28933
  • CVE-2024-28934
  • CVE-2024-28935
  • CVE-2024-28936
  • CVE-2024-28937
  • CVE-2024-28938
  • CVE-2024-28941
  • CVE-2024-28943
  • CVE-2024-29043

Vulnerabilidades del controlador OLE DB de Microsoft para la ejecución de código remoto de SQL Server:

  • CVE-2024-28939
  • CVE-2024-28940
  • CVE-2024-28942
  • CVE-2024-28944
  • CVE-2024-28945
  • CVE-2024-28927
  • CVE-2024-28909
  • CVE-2024-29044
  • CVE-2024-28906
  • CVE-2024-29045
  • CVE-2024-28908
  • CVE-2024-29046
  • CVE-2024-28926
  • CVE-2024-28909
  • CVE-2024-29047
  • CVE-2024-28911
  • CVE-2024-28912
  • CVE-2024-28914
  • CVE-2024-28913
  • CVE-2024-29048
  • CVE-2024-29982
  • CVE-2024-29983
  • CVE-2024-29984
  • CVE-2024-29985
  • CVE-2024-28915

Conclusión

Mantener SQL Server actualizado es una tarea esencial para cualquier profesional de bases de datos. No solo nos ayuda a mantener nuestras bases de datos seguras, sino que también nos permite aprovechar las últimas mejoras y funcionalidades. Así que, recordemos siempre mantener un ojo en las últimas actualizaciones de SQL Server 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 LinkedIn 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

SQL vs DAX ¿Quién es más rápido?

El pasado viernes andaba yo absorto en la masterclass de Salvador Ramos en Nasmasdata cuando, de repente, una diapositiva salvaje apareció. Salva nos hablaba de un cálculo de stock acumulado con su fórmula en DAX porque según ponía en SQL era un cálculo imposible. ¿IMPOSIBLE? Eso era un reto para mí, así que, raudo tomé una captura de pantalla y acepté ese reto. No hubo que esperar mucho, hoy sábado, de buena mañana me he sentado delante del ordenador, he creado una tabla con los datos necesarios para la prueba y me he puesto manos a la obra. No sin antes contactar a Salva e informarle de lo que estaba aconteciendo porque sí amigos, Salva sabe de la existencia de este artículo días antes que vosotros, para la próxima que el reto venga de vosotros y estaréis informados antes. 

SQL-vs-DAX_1

Entendiendo el reto en DAX

Lo primero que tenemos que entender es lo que nos propone el reto, la medida DAX que se ve en la imagen es esta:

Por un lado CALCULATE es una función que cambia una expresión en un contexto de filtro modificado. Como parámetros le hemos pasado [Stock Final] que es una medida o una calculada que nos sumariza los movimientos de stock. Para el segundo parámetro hemos pasado la función FILTER con dos parámetros más, el resultado es que filtra la tabla Fecha para incluir solo las filas donde la fecha es menor o igual a la fecha máxima en el contexto actual.

Convirtiendo el DAX a T-SQL

Ahora que ya sabemos lo que tenemos que obtener vamos a ver como debemos hacerlo en SQL Server, a ver si realmente era imposible o no. He de deciros que mi tabla solo tiene dos columnas fecha y stock. Podriamos haber complicado el escenario añadiendo artículos pero para la demo nos vale sin eso, supongamos que tenemos solo uno. Como luego vamos a llevarnos estas tablas a Power BI tal como están en SQL no hay problema, en DAX vamos a jugar en las mismas condiciones.

Para empezar vamos a tener que totalizar por dias para saber cuantos movimientos hemos tenido ese día. Luego tenemos que hacer una suma de los valores desde la primera fecha hasta la fecha actual. Eso lo podremos lograr con una función de ventana. Esta sería la consulta imposible:

Vamos a verla paso a paso. En lo primero que nos tenemos que fijar es en la subconsulta del FROM. Es justo lo que comentábamos antes, la suma de los movimientos de stock agrupados por día. Luego, en la consulta principal, estamos utilizando una función de ventana para calcular el Stock_Acumulado. Esta función de ventana SUM() OVER (ORDER BY Fecha ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) suma los valores de Stock_Final en todas las filas desde el inicio de la tabla (UNBOUNDED PRECEDING) hasta la fila actual (CURRENT ROW), ordenadas por Fecha. Esto da como resultado un total acumulativo de Stock_Final hasta la fecha actual.

SQL-vs-DAX_2

Ya lo tenemos, no era imposible. Sin embargo, a lo que Salva se refería era los inconvenientes de realizar los cálculos en SQL por tiempos. Y realmente este es un pensamiento muy extendido en el sector. DAX es más rápido realizando cálculos que SQL Server. Pero, ¿realmente es cierto? Vamos a verlo.

Comparativas de rendimiento DAX vs SQL

Para que los resultados puedan ser representativos, vamos a hacer las pruebas sobre una tabla con algo más de 1 millón de registros, algo normal en una empresa pequeña. Vamos a analizar dos años de datos de movimientos de stock. Para medir los tiempos de la consulta DAX he sacado la consulta de la tabla y la he llevado a DAX Studio. En SQL vamos a usar las estadísticas de tiempo que podemos sacar con SET STATISTICS TIME ON.

SQL-vs-DAX_3

Como vemos los resultados son demoledores y para nada lo esperado. Analizando 1.010.000 registros repartidos en 1096 fechas distintas SQL Server se ha demorado 85 milisegundos de los cuales 78 ms han sido CPU. En DAX Studio podemos ver que la fórmula DAX para la tabla ha tardado 180 milisegundos, repartidos entre 175 ms del motor de fórmulas (FE) y 5 ms del motor de almacenamiento (SE). 

Complicando el escenario

Vamos a pasar de 1 millón a 15 millones de registros a ver si los resultados son distintos. Todos sabemos que el fuerte de Power BI reside en su motor Vertipaq y su gran capacidad de trabajar con grandes cantidades de datos.

SQL-vs-DAX_4

Ahora sí que vemos la gran diferencia de tiempos de la que todo el mundo habla en DAX y Power BI. Con 15 millones de registros los tiempos en SQL Server se han disparado a 1219 milisegundos de CPU aunque paralelizando la consulta se ha resulto en 186 ms. En DAX tenemos un tiempo total de 193 milisegundos repartidos en 175 ms del motor de fórmulas (FE) y 18 ms del motor de almacenamiento (SE). Aunque los tiempos de DAX son mayores a los de SQL no hay tanta diferencia y teniendo en cuenta el paralelismo de SQL podemos deducir un mayor consumo de recursos si ejecutamos los cálculos en origen.

Mejorando los tiempos de SQL

Ya sabemos el objetivo a batir en DAX 193 ms. Veamos qué podemos hacer en SQL. Para empezar vamos a probar con un índice columnar sobre la tabla, al fin y al cabo los índices columnares son la misma tecnología que el motor vertipaq de Power BI.

SQL-vs-DAX_5

Ahí lo tenemos, ahora sí. Nuestra consulta sobre la tabla con índices columnares ha tardado 155 milisegundos de CPU y solo 56 ms totales al paralelizar. Aun así esto todavía se puede mejorar, ¿recordáis las vistas indexadas? Vamos a probarlo.

SQL-vs-DAX_6

¿Qué os parece el resultado? ¿Os lo esperabais? Con la combinación de índice columnar más vista indexada hemos podido ejecutar la consulta pesada sobre 15 millones de registros en menos de un milisegundo. A mi me ha sorprendido la verdad. No esperaba tanta mejoría.

Es importante destacar que esto es una prueba de concepto en un entorno de laboratorio sin carga de trabajo donde puedo hacer todos los cambios que quiero sobre el SQL sin afectar a ningún otro proceso. Esto es un escenario muy simplificado para la DEMO sin ningún parecido con una base de datos de un ERP de producción. Como siempre digo, primero válida en tus servidores de pruebas y luego, si ves que va bien y no da problemas, piensa en aplicarlo en producción.

Conclusión

SQL sigue más vivo que nunca. Es verdad que DAX es muy potente y seguro que tiene un montón más de optimizaciones de las que yo he sido capaz de aplicar. Os diré que para las pruebas estaba la inteligencia de tiempos desactivada y como dimensión de tiempos estaba usando la plantilla que Salva proporciona gratuitamente en su web que entiendo que es la que usa él. 

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!

PD.: Salva, no me importa el resultado de estas pruebas, tu sigues siendo un referente para mi 🙂.

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

Anti-Patterns : Nuestro mayor enemigo.

Como DBAs, lo más normal va a ser encontrarnos con consultas que, aunque devuelven el resultado esperado, no están optimizadas y pueden llevar a problemas de rendimiento muy serios. Estos patrones de diseño ineficaces son conocidos como «Query Anti-Patterns» y por muy bien diseñada y optimizada que esté tu base de datos van a dilapidar su rendimiento. Vamos a explorar algunos de los Anti-Patterns más comunes y cómo evitarlos para asegurarnos de que nuestras consultas SQL sean lo más eficientes posible.

Anti-Patterns Comunes y Cómo Evitarlos

La optimización de consultas SQL es una mezcla de arte y ciencia. La habilidad para identificar y corregir anti-patterns en nuestras consultas puede marcar la diferencia entre una base de datos que funciona sin problemas y una que causa dolores de cabeza constantes. Aunque algunos anti-patterns pueden parecer inofensivos a primera vista, su impacto acumulativo, cuando se repiten mucho o se solapan puede ser devastador. En este artículo, vamos a ver varios de estos anti-patterns con ejemplos concretos y soluciones prácticas.

El más común: Select *

Uno de los anti-patterns más comunes y dañinos es el uso de SELECT *. Al seleccionar todas las columnas de una tabla, no solo estamos recuperando datos innecesarios, sino que también podemos estar comprometiendo la seguridad y el rendimiento de nuestra consulta. Este problema se agrava si estamos ante una tabla de un modelo tabular optimizada con índices columnares pues perderemos su gran potencial propio de su diseño, la capacidad de leer solo las columnas necesarias.

Ejemplo:

Solución:

Especificar sólo las columnas necesarias, de esta manera, reducimos la cantidad de datos transferidos y hacemos que nuestra consulta sea más clara y manejable. Además podremos aprovecharnos de índices que cubran completamente nuestras consultas.

Funciones en las Columnas

Usar funciones en las columnas dentro de las cláusulas WHERE es otro anti-pattern que puede degradar significativamente el rendimiento. Las funciones en las columnas evitan que SQL Server use índices, resultando en escaneos de tabla completos. Es lo que se conoce como problemas de sargabilidad de los índices, y consiste en que, al usar un filtro de búsqueda que no se puede aplicar a todos los niveles de la estructura B-tree (árbol invertido), el motor de base de datos tiene que recorrer completamente el nivel hoja buscando coincidencias.

Ejemplo:

Solución:

Reescribir la consulta para evitar la función en la columna. Con esta modificación, permitimos que SQL Server utilice índices sobre OrderDate, mejorando notablemente el rendimiento.

Subconsultas Correlacionadas en el WHERE

Las subconsultas correlacionadas dentro de una cláusula WHERE pueden ser extremadamente costosas, ya que la subconsulta se ejecuta una vez por cada fila en la tabla externa.

Ejemplo:

Solución:

Utilizar un JOIN o CROSS APPLY para evitar la subconsulta correlacionada. Aunque puede haber excepciones en función del tamaño de las tablas, esta aproximación es generalmente más eficiente, ya que la subconsulta se ejecuta una sola vez y los resultados se unen a la tabla principal reduciendo drásticamente el número de lecturas en disco.

Subconsultas en el SELECT

Las subconsultas en la cláusula SELECT pueden causar problemas similares a las subconsultas en WHERE, ya que se ejecutan por cada fila de la tabla principal.

Ejemplo:

Solución:

Usar un JOIN para incluir la información necesaria. De esta forma, la subconsulta se elimina y la consulta puede beneficiarse de una menor cantidad de lecturas.

UNION en Lugar de UNION ALL

El uso de UNION en lugar de UNION ALL puede resultar en un rendimiento deficiente, ya que UNION elimina duplicados, lo cual requiere una operación adicional de ordenación y comparación para lo que es necesario cargar todos los datos en memoria. Es común encontrarse con consultas con UNION por pereza y no escribir los 4 carácteres extra pero, si no es estrictamente necesario nunca es una buena idea.

Ejemplo:

Solución:

Si estamos seguros de que no hay duplicados, usar UNION ALL. De esta manera, evitamos el trabajo adicional de eliminar duplicados y mejoramos la eficiencia de la consulta.

Conversiones Implícitas

Las conversiones implícitas ocurren cuando SQL Server necesita convertir los tipos de datos de una columna o variable para que coincidan. Esto puede tener un impacto negativo en el rendimiento, especialmente cuando involucra columnas indexadas, ya que puede evitar que los índices se utilicen de manera eficiente.

Ejemplo:

En este ejemplo, si OrderID es un entero y estamos comparándolo con una cadena, SQL Server tendrá que convertir OrderID a una cadena para realizar la comparación, lo que puede evitar el uso de índices.

Solución:

Asegurarse de que los tipos de datos coincidan. De esta manera, evitamos la conversión implícita y permitimos que SQL Server utilice los índices de manera eficiente.

Localizando Anti-Patterns con X-Events (ojo, esto ya es muy friki)

Los eventos extendidos son una herramienta muy poderosa en nuestra búsqueda de problemas. Gracias a su capacidad de capturar, en tiempo real, consultas que cumplan unos requisitos establecidos y, a una novedad introducida en SQL Server 2022 como es el evento query_antipattern, nos van a permitir localizar estas consultas mal diseñadas de una manera sencilla. O eso dice la teoría. Os dejo por aquí el script que he usado yo para generar esta sesión de x-events:

Probando los Anti-Patterns X-Events

Ahora que ya hemos visto la teoría vamos a volver al mundo real. Podemos localizar los anti-patterns detectados por este evento extendido si miramos en la DMV sys.dm_xe_map_values que registra los distintos tipos de eventos.

xevents-anti-patterns

Como ves, hay 5 antipatrones, el quinto es el único que coincide con alguno de los que hemos visto nosotros en este artículo. Sobre el resto no hay más documentación, Microsoft ha decidido sacar esta novedad en X-Events pero no lo ha documentado. 

En mis pruebas, he conseguido generar una consulta que active el primero de los tipos de antipatrón, el LargeIn, pero os voy a ser sinceros, no ha sido fácil. Para lograrlo he escrito una consulta con un filtro where CustomerID IN y a continuación le he pasado 2500 parámetros separados por comas. Con menos parámetros no he conseguido hacer saltar la alerta. El antipatrón de conversiones que impiden el Seek sí que es relativamente sencillo verlo y salta ante cualquier consulta con un error de conversión. 

xevents-anti-patterns_2

Sobre el resto no os puedo decir más, llevo más de una semana con este artículo escrito, buscando información y haciendo pruebas pero no lo he conseguido ver. En algún sitio he visto que han conseguido el fallo por un antipatrón LargeNumberOfOrInPredicate con las pruebas que a mi me han dado el LargeIn pero yo no lo he podido reproducir. Igual que ellos no pudieron reproducir el LargeIn. Sobre el resto de tipos de Anti-Patterns no he conseguido más información. No sé qué significa Max en este contexto. En el caso de NonOptimalOrLogic he llegado a pensar que es un problema con las lógicas OR pero no he conseguido reproducirlo ni con 21.500 OR en una misma consulta. Es más, ni con 21.500 OR en una misma consulta mostró ninguno de los otros Anti-Patterns.

Conclusión

Identificar, resolver y evitar estos anti-patterns en nuestras consultas T-SQL puede suponer una mejora significativa en el rendimiento de nuestras bases de datos. Es crucial siempre revisar y optimizar las consultas en ejecución, especialmente en sistemas críticos donde el rendimiento es esencial.Al aplicar buenas prácticas y evitar estos anti-patterns, no solo mejoramos la eficiencia de nuestras consultas, sino que también contribuimos a la estabilidad a largo plazo de nuestras aplicaciones. 

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

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

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