Infra

19
Ago
2024

Comprendiendo los servicios de SQL Server

Cuando instalamos SQL Server en nuestro ordenador o en un servidor vamos a ver que se instalan varios servicios que no teníamos antes. Esto es porque SQL Server es mucho más que un motor de base de datos relacional (RDBMS) sino que hay todo un ecosistema a su alrededor que hace posible la ejecución de todas las capacidades adicionales de las que dispondremos. Estos servicios trabajan en conjunto para proporcionarnos las capacidades de automatización, escalabilidad, seguridad, y analítica avanzada, permitiendo que SQL Server sea más que un simple motor de base de datos, como decíamos antes. A continuación, vamos a ver en detalle cada uno de estos servicios y componentes, desglosando su rol dentro del ecosistema de SQL Server para que como administradores de base de datos tengáis un mayor control.

Servicios SQL Server: El motor de base de datos 

El motor de base de datos es el núcleo sobre el que se sustentan todas las operaciones en SQL Server, el motor relacional propiamente dicho. Su principal función es el almacenamiento, procesamiento y seguridad de los datos. Este servicio maneja la ejecución de consultas SQL y la gestión de transacciones, así como  la administración de la integridad referencial y la seguridad. Este motor está diseñado para manejar desde pequeños hasta grandes volúmenes de datos y soportar entornos de gran concurrencia, proporcionándonos un rendimiento constante y confiable. Además, es responsable de la ejecución de procedimientos almacenados, funciones y triggers (desencadenadores), lo que permite la automatización de tareas dentro de la base de datos. Veremos un servicio de SQL Server por cada una de las instancias que tengamos instalada en nuestra máquina y detener estos servicios implica detener esas instancias de SQL Server.

Servicios SQL Server agent: automatización y programación de tareas

El agente de SQL Server es un servicio clave para la administración eficiente de las bases de datos. Su función principal es la automatización de tareas rutinarias, como la ejecución de scripts y la programación de copias de seguridad, lo que nos permite a los administradores mantener la continuidad del servicio y asegurar la optimización y seguridad de las bases de datos. A través de la programación de trabajos, el agente nos permite ejecutar tareas de manera recurrente o en respuesta a eventos específicos, minimizando la intervención manual y asegurando que las bases de datos se mantengan en condiciones óptimas. Además, cuenta con un sistema de alertas que nos notifica a los administradores sobre eventos críticos, como fallos en los trabajos o problemas de rendimiento, lo que facilita una respuesta proactiva.

Este servicio está disponible para todas las instalaciones de SQL Server que no sean una edición Express y veremos uno de ellos por cada una de las instancias que cumplan esa condición. Si detenemos este servicio SQL Server seguirá funcionando pero no el agente de SQL por lo que no podremos hacer uso de jobs ni de alertas.

Servicio SQL Server browser: gestión de conexiones en múltiples instancias

El servicio SQL Server Browser es esencial en entornos donde coexisten múltiples instancias de SQL Server o cuando tenemos una instancia con nombre. Este servicio gestiona las conexiones a las distintas instancias, resolviendo el nombre de la instancia y redirigiendo al cliente al puerto correspondiente. Es particularmente útil en entornos que utilizan instancias con nombres o puertos dinámicos, ya que facilita la administración de las conexiones sin necesidad de configurar manualmente cada una. El Browser también proporciona información sobre las instancias disponibles en una máquina, mejorando la flexibilidad y simplicidad en la conexión a SQL Server.

Se trata de un servicio común para todas las instancias de SQL Server por lo que solo veremos uno por cada servidor, tengamos las instancias que tengamos. Si este servicio está detenido, SQL Server seguirá funcionando pero podemos encontrarnos con problemas de conexión desde los equipos de la red si nuestras instancias tienen nombre o si tienen configurado el puerto dinámico.

Servicios Full-text engine y los servicios SQL full-text filter daemon launcher

El Full-text Engine y su servicio asociado, el Full-text Filter Daemon Launcher, proporcionan capacidades avanzadas de búsqueda en texto completo dentro de SQL Server. Este servicio permite realizar búsquedas complejas en grandes volúmenes de datos textuales, utilizando criterios como palabras clave, frases, y proximidad de términos. Es especialmente útil en aplicaciones que manejan datos no estructurados, como documentos y correos electrónicos, permitiendo a los usuarios realizar consultas sofisticadas que van más allá de las capacidades de búsqueda estándar de SQL. La combinación del Full-text Engine con el motor de base de datos permite realizar consultas mixtas que integran búsquedas textuales y estructuradas, proporcionando un alto nivel de flexibilidad en la recuperación de información. Veremos un servicio SQL Full-text Filter Daemon Launcher por cada una de las instancias que tengamos instalada en nuestra máquina y podremos detenerlo siempre y cuando no usemos estas características.

Servicios PolyBase: integración y análisis de datos externos

PolyBase es una tecnología dentro de SQL Server que nos facilita la consulta de datos almacenados en sistemas externos, como Hadoop o Azure Blob Storage, utilizando T-SQL. Los servicios asociados a PolyBase, como PolyBase Data Movement y PolyBase Engine son los que nos permiten mover y procesar datos entre diferentes nodos en una configuración distribuida. Esto es especialmente relevante cuando trabajamos en entornos de Big Data, donde nos es necesario manejar grandes volúmenes de datos que residen fuera del ecosistema tradicional de SQL Server. En estos entornos, PolyBase nos permite integrar y analizar datos de diversas fuentes sin necesidad de moverlos físicamente a SQL Server, lo que optimiza el rendimiento y reduce los costes de almacenamiento.

Los servicios de PolyBase son comunes para todas las instancias del servidor por lo que solo veremos uno de cada y ya que tienen una funcionalidad muy específica podremos detenerlos si no hacemos uso de ella.

Servicio SQL Server vss writer: copias de seguridad consistentes

El servicio SQL Server VSS Writer es fundamental para la realización de copias de seguridad consistentes de las bases de datos mientras están en uso. Este servicio interactúa con la tecnología de copia de sombra de volumen de Windows (Volume Shadow Snapshot) para asegurar que las copias de seguridad sean coherentes y confiables, incluso en entornos de producción donde las bases de datos están activas. La capacidad de realizar copias de seguridad en vivo sin afectar el rendimiento del sistema es crucial para garantizar la disponibilidad y la integridad de los datos en SQL Server. Además, este tipo de copias de seguridad por snapshot suelen ser instantáneas a la hora de realizarse y mucho (pero muchísimo) más rápidas a la hora de restaurarse.

Se trata, nuevamente, de un servicio común para todas las instalaciones de SQL Server por lo que solo veremos uno y podremos detenerlo si tenemos claro que en ningún caso se realizan este tipo de copias. Sin embargo, este es uno de esos servicios que yo recomiendo tener siempre en ejecución.

Servicios SQL Server launchpad: integración con lenguajes de análisis de datos

SQL Server Launchpad es un servicio que habilita la ejecución de scripts en lenguajes de análisis de datos, como R y Python, directamente dentro de SQL Server. Este servicio permite integrar el análisis avanzado y el machine learning en el entorno de SQL Server, sin necesidad de mover los datos a plataformas externas. La ejecución de modelos de análisis directamente sobre los datos almacenados en SQL Server optimiza el rendimiento y simplifica el flujo de trabajo, lo que es esencial en aplicaciones que requieren un análisis en tiempo real o procesamientos estadísticos complejos. Esta capacidad se puede elegir a nivel de instancia por lo que cada una que tengamos instalada tendrá su servicio y podremos detenerlos si no los necesitamos.

Servicios de otros productos de la familia SQL Server

Como ya sabéis, SQL Server incluye otros servicios además del motor de bases de datos, estos son SSAS, SSRS y SSIS. La integración de SQL Server con estos otros servicios nos permite construir soluciones BI completas y robustas.

Servicios de SSAS

SQL Server Analysis Services (SSAS) es un servicio crucial para la creación de soluciones de inteligencia de negocios (BI). SSAS permite la creación de modelos de datos complejos que pueden ser consultados eficientemente, ofreciendo soporte tanto para modelos multidimensionales (OLAP) como tabulares. Este servicio es la columna vertebral de las capacidades analíticas de SQL Server, permitiendo a las organizaciones realizar análisis profundos de sus datos, identificar patrones y tendencias, y tomar decisiones basadas en datos. Al igual que con SQL Server, podemos tener varias instancias de SSAS y veremos un servicio en ejecución por cada una de ellas.

Servicios de SSIS

SQL Server Integration Services (SSIS) es la plataforma de SQL Server para la integración y transformación de datos. SSIS permite ejecutar complejas operaciones ETL (Extract, Transform, Load), integrando datos de diversas fuentes y transformándolos para su análisis o almacenamiento en bases de datos. Además del servicio del motor de SSIS vamos a encontrar los servicios de escalado de SSIS, como el Scale Out Master y Scale Out Worker que permiten distribuir la carga de trabajo entre múltiples servidores, mejorando el rendimiento y la eficiencia en la ejecución de paquetes SSIS. Esta capacidad de escalabilidad es fundamental en entornos que requieren procesar grandes volúmenes de datos de manera rápida y eficiente. Como solo se puede tener una instalación de SSIS por máquina solo vamos a ver uno de cada uno de estos tres servicios.

Servicio de SSRS

SQL Server Reporting Services (SSRS) es el componente que permite la creación, distribución y administración de informes empresariales. SSRS proporciona herramientas para diseñar informes detallados, que pueden incluir gráficos, tablas y otros elementos visuales, facilitando la interpretación de los datos. Además, SSRS permite automatizar la distribución de informes, asegurando que los responsables de tomar decisiones tengan acceso a la información más actualizada. La capacidad de personalizar y programar informes según las necesidades específicas de la organización hace de SSRS una herramienta indispensable en el ecosistema de SQL Server. SSRS ya ha dejado de distribuirse junto con SQL Server por lo que para instalarlo tendremos que buscar un instalador independiente.

Servicios CEIP en SQL Server, SSAS y SSIS

Los servicios CEIP (Customer Experience Improvement Program) en SQL Server SQL Server Integration Services (SSIS) y SQL Server Analysis Services (SSAS) recolectan información sobre cómo utilizamos estas herramientas, incluyendo estadísticas de rendimiento y uso. Esta información se envía a Microsoft para contribuir a la mejora del producto en futuras versiones. Aunque estos servicios no son críticos para la operación diaria de SQL Server, SSIS o SSAS, pueden ser útiles para los que deseamos contribuir al desarrollo y mejora del software y obtener recomendaciones sobre cómo optimizar su uso.

Conclusión

SQL Server es una plataforma integral que va más allá de ser simplemente un motor de base de datos relacional. Sus diversos servicios, desde la automatización de tareas con el agente de SQL Server hasta las capacidades analíticas avanzadas de SSAS, y la integración de datos externos con PolyBase, permiten a las organizaciones construir soluciones completas y optimizadas para manejar grandes volúmenes de datos. Comprender y aprovechar estos servicios es fundamental para maximizar el rendimiento, la seguridad y la eficiencia en cualquier implementación de SQL Server. La correcta configuración y gestión de estos componentes garantiza que SQL Server no solo cumpla con las demandas actuales, sino que esté preparado para enfrentar los desafíos del futuro en el manejo y análisis de datos.

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

No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo.

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
09
Ago
2024

Mantenimiento imprescindible en SQL Server

El mantenimiento de bases de datos en SQL Server, como en todos los sistemas de bases de datos, es una actividad crítica para garantizar el rendimiento y la estabilidad de las aplicaciones que dependen de ellas. Un enfoque proactivo en la gestión de índices, estadísticas, integridad y copias de seguridad nos permite a los administradores evitar problemas potenciales antes de que se conviertan en fallos costosos. En este artículo, profundizaremos en cada uno de estos aspectos, proporcionando una visión detallada y práctica para mantener nuestras bases de datos en condiciones óptimas.

Mantenimiento de índices para mejorar el rendimiento

Los índices son componentes esenciales en nuestras bases de datos, ya que nos permiten un acceso rápido a los datos y mejoran significativamente el rendimiento de nuestras consultas. Prueba de ello es la cantidad de artículos que les hemos dedicado en el blog. Sin embargo, la eficiencia de los índices puede deteriorarse con el tiempo debido a la fragmentación, que ocurre cuando las páginas de datos se desorganizan. Este fenómeno afecta negativamente la rapidez de las búsquedas y actualizaciones y tenemos que prevenirlo y ponerle solución.

Para mantener un rendimiento óptimo, es crucial que monitoricemos y gestionemos los índices de forma periódica. No vamos a entrar en muchos más detalles pues ya le dedicamos un artículo completo a este tema. Simplemente vamos a ver que tenemos dos opciones de mantenimiento, la reorganización y la reconstrucción. La reorganización de índices es una técnica por la cual el motor de base de datos ajusta los índices sin necesidad de reconstruirlos completamente, lo que es en sí un proceso menos intensivo en recursos. Cuando la fragmentación es alta, la reorganización ya no es tan efectiva y debemos recurrir a la reconstrucción de índices, aunque sea un proceso más costoso en términos de tiempo y recursos. Deberemos planificar estas actividades de mantenimiento durante periodos sin uso o de baja actividad para minimizar el impacto a los usuarios.

Mantenimiento de estadísticas

Las estadísticas en SQL Server proporcionan al optimizador de consultas la información necesaria para decidir cuál es el mejor plan de ejecución posible para nuestra consulta, es decir, cómo ejecutar una consulta de la manera más eficiente posible. Sin datos actualizados, el optimizador puede hacer estimaciones inexactas, lo que lleva a un mal rendimiento.

La actualización regular de las estadísticas es una práctica recomendada para mantener el rendimiento del sistema. SQL Server ofrece opciones de actualización automática, pero en entornos con alta carga de trabajo o donde el rendimiento es crítico, puede ser más efectivo realizar actualizaciones manuales programadas. Esto asegura que las estadísticas reflejen con precisión la distribución actual de los datos, lo que es esencial para que el optimizador pueda generar planes de ejecución óptimos. Además no olvidéis que una actualización de estadísticas fuerza la recopilación de los planes de ejecución por lo que tenemos que buscar el equilibrio para mantenerlas actualizadas sin provocar un exceso de recompilaciones de los planes en caché.

Chequeo de integridad de las bases de datos

La integridad de los datos es un aspecto fundamental en la administración de bases de datos. Gracias a las herramientas de SQL Server, como DBCC CHECKDB, vamos a poder verificar la consistencia física de las bases de datos y de sus datos internos. Esta verificación es crucial para identificar y corregir errores en las estructuras de datos, que pueden surgir por diversas razones, desde fallos del hardware de almacenamiento hasta errores humanos o de consistencia en los datos.

Realizar verificaciones de integridad de manera regular ayuda a detectar problemas antes de que afecten la disponibilidad del sistema o provoquen pérdidas de datos. En caso de encontrarnos con corrupción, deberemos tomar acciones inmediatamente para reparar los daños antes de que puedan ir a más. Para esto intentaremos usar las herramientas disponibles como DBCC CHECKDB y, si no es posible restauraremos los datos desde una copia de seguridad anterior al incidente. 

Una vez resuelta la corrupción tendremos que buscar el origen del problema para evitar que se vuelva a repetir. Las causas más comunes de corrupción son fallos en el almacenamiento o interrupciones inesperadas del servicio (como fallos de alimentación). Es común encontrarse con problemas de corrupción también en instalaciones en sistemas operativos de escritorio que, para ahorrar energía, desconectan la alimentación de los discos duros. Esta configuración debe ser deshabilitada si se instala SQL Server en un sistema operativo de escritorio.

Copias de seguridad como medida de protección esencial

Las copias de seguridad deberían ser la piedra angular de cualquier estrategia de administración de bases de datos. Gracias a estas copias vamos a poder recuperar datos en caso de fallos o desastres, asegurando la continuidad del negocio. Es crucial diseñar un plan de copias de seguridad que considere la frecuencia de los respaldos, la retención y el almacenamiento seguro de los mismos.

Como ya vimos en el artículo que les dedicamos, existen diferentes tipos de copias de seguridad, como completas, diferenciales y de log de transacciones, cada una con su propia función y aplicabilidad. También es vital que realicemos pruebas de restauración periódicas para asegurarnos de que los procedimientos de recuperación funcionarán correctamente cuando sean necesarios. Además, es aconsejable que almacenemos las copias de seguridad en ubicaciones seguras y, si es posible, en lugares distintos geográficamente para protegernos contra desastres locales.

Soluciones de mantenimiento para bases de datos en SQL Server

Para que podamos gestionar eficazmente el mantenimiento de bases de datos en SQL Server podemos contar con herramientas y soluciones que automatizan y optimizan estas tareas. SQL Server ofrece varias herramientas nativas, mientras que otros desarrolladores han creado soluciones adicionales que pueden complementar o incluso superar las capacidades integradas. 

Herramientas nativas de SQL Server para el mantenimiento

SQL Server incluye varias características y herramientas integradas que facilitan la gestión del mantenimiento de bases de datos. Entre ellas, el Mantenimiento de Bases de Datos (Database Maintenance) y el Asistente para Mantenimiento (Maintenance Plan Wizard) son particularmente útiles para automatizar tareas como la reorganización y reconstrucción de índices, la actualización de estadísticas, la verificación de integridad y la realización de copias de seguridad.

Estas herramientas nos permiten a los DBAs configurar trabajos programados (jobs) de manera sencilla, utilizando una interfaz gráfica o scripts Transact-SQL. Sin embargo, aunque son bastante flexibles y suficientes para escenarios no muy complejos, es común encontrarnos con que estas herramientas pueden estar limitadas en cuanto a personalización y control exhaustivo sobre nuestras tareas de mantenimiento.

Soluciones avanzadas de Ola Hallengren

Una de las soluciones más reconocidas y ampliamente utilizadas en la comunidad SQL Server es el conjunto de scripts de mantenimiento desarrollado por Ola Hallengren. Estos scripts son muy configurables y nos proporcionan una solución completa para el mantenimiento de índices, copias de seguridad y verificación de integridad. De esta manera, nos permiten adaptar nuestras tareas de mantenimiento a las necesidades específicas de cada entorno.

Yo siempre recomiendo los scripts de Ola Hallengren ya que destacan por su eficiencia frente a las soluciones nativas. Además tienen una integración con el agente de SQL Server que nos facilita la programación y monitorización de las tareas de mantenimiento. Por último, pero no menos importante, estos scripts son gratuitos y se actualizan regularmente, lo que los convierte en una opción robusta y confiable.

Conclusión

Un mantenimiento adecuado y constante de las bases de datos en SQL Server es esencial para garantizar su rendimiento, disponibilidad y seguridad. La gestión eficiente de índices, la actualización estadísticas, las verificaciones regulares de integridad y una estrategia eficaz de copias de seguridad son pilares fundamentales en esta tarea. Adoptar un enfoque proactivo y planificado nos permite evitar problemas antes de que se conviertan en crisis, asegurando que nuestras bases de datos funcionen de manera óptima y que los datos estén siempre disponibles y protegidos.

 

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

Reducir bases de datos (shrink)

En nuestro pasado artículo hablamos del crecimiento de las bases de datos. Entre otras cosas, os expliqué las diferencias entre espacio utilizado y espacio total del fichero y a que eran debidas. También vimos los errores más comunes que nos pueden llevar a que nuestras bases de datos crezcan más de lo necesario. En el artículo de hoy vamos a ver las técnicas de reducción de espacio de una base de datos con la operación shrink. El objetivo es que entendamos cuándo y por qué usar esta herramienta y si tienes que usarla, al final del artículo te diré cómo.

Espacio ocupado y utilizado

Como explicamos en el pasado artículo, aunque muy por encima, el espacio que ocupan nuestras bases de datos SQL Server en disco no es el tamaño real que tienen ocupado los datos. Por temas de rendimiento, el espacio que se asigna al fichero es mayor, o debería serlo, al que realmente ocupan los datos. Esto es así porque los tiempos de las operaciones de escritura podemos dividirlos en dos, por un lado reservar el espacio necesario en disco para los datos y por último escribir los datos. Aunque con técnicas como la inicialización instantánea de ficheros podemos agilizar mucho el proceso de crecimiento de los ficheros, si el espacio ya está previamente reservado, es decir, ocupado por el fichero pero no utilizado, será mucho más rápido el proceso de escritura. 

Reducir una base de datos

Cuando hablamos de reducir una base de datos, lo único que vamos a poder hacer sin eliminar datos es liberar ese espacio que tenía el fichero reservado pero no en uso. Es decir, reducir el tamaño del fichero hasta como mínimo el tamaño máximo de los datos. En el pasado artículo ya hablamos de las técnicas para que los datos ocupen menos y esto nos puede servir para reducir su tamaño, sin embargo, ninguna de estas técnicas va a reducir por sí misma el tamaño de los ficheros, para eso tenemos que recurrir a una reducción de ficheros o de base de datos también conocida como shrink.

¿Qué es el shrink?

El shrink es un proceso mediante el cual se reduce el tamaño físico de un archivo de base de datos, ya sea de datos o de log. Este comando libera espacio no utilizado y lo devuelve al sistema operativo. Aunque a primera vista puede parecer una herramienta útil para gestionar el espacio en disco, es fundamental entender cómo funciona realmente y los efectos que puede tener en el rendimiento de la base de datos. Empecemos por el principio, podemos hacer un shrink de toda la base de datos o de solo unos ficheros (ya sean de datos o de log), esta última opción es la más recomendable ya que nos permite un mayor control sobre la operación. 

Tipos de Shrink

Por otro lado, existen tres tipos de shrink, debido a que solo se puede liberar el espacio libre al final del fichero nos encontramos con un shrink truncateonly donde solo se libera ese espacio libre al final del fichero pero el espacio que hay entre los datos (fragmentación) sigue ocupado, este tipo de shrink es el más rápido y menos invasivo. 

El tipo más efectivo para liberar espacio es cuando definimos un tamaño que será el tamaño total que ocupe el fichero tras el proceso, en este caso, para conseguir liberar todo el espacio, SQL Server moverá físicamente los datos dentro del fichero eliminando los espacios libres y dejándolos al final para así poder liberar todo ese espacio. Esta operación en ficheros de datos es complicada, no solo por lenta, sino porque desfragmenta los índices. Al mover los datos de sitio los índices ya no apuntan al sitio correcto y hay que reconstruirlos después o no serán usables. El problema con esto, es que al reconstruir los índices, SQL Server crea un nuevo índice y al terminar borra el antiguo y si, durante este proceso vuelve a consumir espacio del fichero de datos. En concreto el espacio que ocupa el índice. 

Por último, cuando tenemos varios ficheros de base de datos del mismo filegroup podemos hacer un shrink en uno de ellos que lo vacíe por completo moviendo los datos al resto de ficheros. Esto también nos va a generar los problemas de fragmentación comentados anteriormente.

Ventajas del Uso del Shrink

Una de las ventajas más obvias del shrink es la liberación de espacio en disco. Esto nos será especialmente útil en situaciones donde el almacenamiento sea limitado o costoso. Además, el shrink puede ser una solución rápida para situaciones de emergencia en las que se necesita liberar espacio inmediatamente. Podemos ejecutar un shrink de forma fácil, incluso podemos programarlo en jobs para que se ejecute automáticamente. Incluso podemos configurar nuestras bases de datos para que liberen el espacio libre por defecto de manera automática.

Otra ventaja es que el shrink puede ayudar en la gestión de archivos de log de transacciones, que a menudo crecen considerablemente en bases de datos con muchas transacciones. En este contexto, el shrink puede reducir el tamaño de estos archivos después de una copia de seguridad del log, evitando así que ocupen espacio innecesario. En este mismo contexto, podemos hacer un shrink sobre la base de datos tempdb cuando haya crecido más de la cuenta debido a una transacción grande.

Inconvenientes y Riesgos del Shrink

A pesar de sus ventajas aparentes, como ya hemos comentado, nos podemos encontrar con muchos inconvenientes si ejecutamos un shrink sin ser cuidadosos. Uno de los principales problemas es la fragmentación de los índices. El proceso de shrink puede reorganizar los datos de manera que los índices queden fragmentados, lo que puede degradar significativamente el rendimiento de las consultas. La fragmentación aumenta el tiempo de respuesta de las consultas y la carga sobre el sistema, lo cual es contraproducente en entornos de alta demanda.

Además, el shrink es un proceso que consume recursos, muchos recursos. Durante su ejecución, puede aumentar la carga de trabajo del servidor, afectando a otras operaciones. Tendremos que tener un especial cuidado en bases de datos grandes o en sistemas con recursos limitados. También es importante mencionar que el espacio liberado por el shrink no se puede recuperar sin expandir el archivo nuevamente, lo cual podría ser necesario si la base de datos vuelve a crecer rápidamente.

Prácticas Recomendadas para el Uso del Shrink

Dado que el shrink puede tener efectos adversos en el rendimiento, es crucial seguir ciertas prácticas recomendadas para minimizar sus desventajas. Primero, no debemos usar el shrink como una solución de gestión de espacio a largo plazo. Normalmente si ya hemos utilizado un espacio vamos a necesitarlo en un futuro. Por tanto, es mejor emplearlo en situaciones específicas, como después de la eliminación masiva de datos o en la gestión de archivos de log de transacciones. Como ya habrás adivinado, cuando hacemos un shrink del log de transacciones o de la tempdb no vamos a vernos afectados por la fragmentación de índices.

También es recomendable realizar el shrink en momentos de baja actividad para minimizar el impacto en el rendimiento del sistema. Posteriormente, deberemos realizar una reconstrucción de índices para solucionar la fragmentación causada por el proceso de shrink. Esto ayuda a restaurar el rendimiento óptimo de las consultas.

Por último, debemos tener una previsión del espacio que van a necesitar nuestros ficheros de bases de datos y reducirlos siempre dejando el suficiente espacio libre para unas escrituras óptimas.

Alternativas al Shrink

El shrink más eficiente es el que no se hace. En este sentido, existen alternativas que pueden ser más adecuadas en ciertas circunstancias. La gestión proactiva del espacio, como la eliminación de datos obsoletos o el archivo de datos antiguos, puede reducir la necesidad de realizar un shrink. Además, la implementación de prácticas de mantenimiento regulares, como el reindexado y la actualización de estadísticas, puede ayudar a mantener la base de datos en buen estado sin los efectos adversos del shrink.

Conclusión

El shrink en SQL Server es una herramienta que debe ser utilizada con precaución y entendimiento. Aunque puede ofrecer una solución rápida para liberar espacio en disco, sus efectos secundarios, como la fragmentación de índices y el consumo de recursos, deben ser cuidadosamente gestionados. Es fundamental considerar el shrink como una herramienta de última instancia y explorar alternativas y prácticas de mantenimiento regulares para mantener una base de datos saludable y eficiente. La clave está en el balance y en la planificación proactiva, asegurando que el rendimiento y la integridad de los datos no se vean comprometidos.

Si has llegado hasta aquí esperando ver cómo hacer un shrink te diré que este no era el objetivo de este artículo, tienes eso en un vídeo aquí. Hoy quería contarte todo lo que rodea a esta operación, para mi, es más importante saber cuándo y por que hacer un shrink que saber hacerlo.

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!

No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo.

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

¿A qué se debe el crecimiento excesivo de bases de datos?

El crecimiento descontrolado de las bases de datos es una preocupación común para los administradores de sistemas y bases de datos. El aumento natural de los datos puede ser una explicación pero, en ocasiones, este crecimiento puede estar influenciado por errores de modelado, configuraciones inadecuadas y prácticas de gestión poco eficaces. En este artículo, abordaremos algunos errores comunes que contribuyen a este problema y veremos soluciones prácticas para tratar de evitarlo.

Crecimiento normal de los datos

Antes de entrar en detalles sobre cómo controlar el crecimiento de nuestros datos tenemos que dejar clara una cosa. Tu base de datos va a crecer, es el comportamiento común. El crecimiento natural y orgánico de las bases de datos es un fenómeno esperado en cualquier sistema en funcionamiento. A medida que se almacenan más datos, ya sea por la expansión de la empresa, el aumento de las operaciones o la recopilación de información de clientes y transacciones, es normal que las bases de datos crezcan. Este crecimiento, aunque esperado, debe ser gestionado adecuadamente para evitar problemas de rendimiento y costes innecesarios.

Crecimiento por errores de modelado de bases de datos

Una de las áreas fundamentales donde se pueden originar problemas de crecimiento en bases de datos es en el diseño y modelado de la propia base de datos. Errores como la falta de normalización adecuada o la sobrecarga de índices pueden llevar a un uso ineficiente del espacio y un crecimiento innecesario de la base de datos.

Falta de normalización adecuada

Una de las causas más frecuentes del crecimiento innecesario de bases de datos que he podido contemplar a lo largo de los años es una falta de normalización adecuada. La normalización ayuda a minimizar la redundancia de datos y garantiza la integridad referencial. Sin embargo, cuando no se aplica correctamente, puede resultar en la duplicación de datos a lo largo de varias tablas, inflando el tamaño total de la base de datos.

Para ponerle solución, es recomendable revisar el diseño de las bases de datos para asegurar que estén normalizadas correctamente. Aunque en algunas situaciones específicas pueda ser necesario que  desnormalicemos los datos para mejorar el rendimiento, sobre todo en entornos analíticos y de BI, esta decisión debemos tomarla con precaución y basándonos en un análisis sólido de las necesidades de la aplicación.

Sobrecarga de índices

Otro de los errores que más se cometen es el uso excesivo de índices. Es tan común ver bases de datos con índices innecesarios o duplicados como bases de datos sin índices. Este es otro problema que puede contribuir al crecimiento de las bases de datos ya que los índices nonclustered son objetos separados de la tabla que requieren su propio almacenamiento duplicando los datos en cada índice que aparezcan. Aunque los índices son fundamentales para acelerar las consultas, mantener demasiados puede llevar a un aumento innecesario en el tamaño de la base de datos, además de afectar el rendimiento durante las operaciones de inserción, actualización y eliminación.

La solución es sencilla, revisar los índices que no se utilizan y eliminarlos, pero a la vez requiere de conocimientos avanzados tanto de administración como del uso de la base de datos para no eliminar un índice que sí sea importante para el rendimiento. Otra buena práctica es usar índices filtrados cuando sea posible ya que pueden proporcionar beneficios de rendimiento específicos sin un aumento significativo en el espacio de almacenamiento.

Crecimiento por configuraciones inadecuadas en SQL Server

Además del diseño de la base de datos, la configuración del servidor SQL también puede influir significativamente en el tamaño y rendimiento de la base de datos. Configuraciones inadecuadas, como el modo de recuperación FULL sin una correcta gestión de los logs de transacciones, o una configuración incorrecta del tamaño del archivo, pueden provocar un crecimiento inesperado y descontrolado.

Modo de recuperación FULL y log de transacciones

El modo de recuperación FULL es esencial para una recuperación completa en caso de desastres, ya que registra todas las transacciones. Sin embargo, si no se gestionan adecuadamente, los logs de transacciones pueden crecer de forma incontrolada, ocupando mucho espacio en disco. Cuando configuras este modo de recuperación tienes que habilitar una buena política de backups con backup log frecuentes o vas a encontrarte con problemas de crecimiento del log descontrolado.

Como hemos dicho la solución es sencilla en este caso, basta con implementar una estrategia de backups regulares de los logs de transacciones. Esto no solo controla el tamaño del log, sino que también es crucial para la recuperación de datos. Es importante revisar la frecuencia de los backups y ajustar las políticas de recuperación según las necesidades de la organización. Si no es necesario este tipo de copias regulares deberías replantearte el modo de recuperación de tu base de datos.

Configuración inadecuada del tamaño del archivo

Es importante entender la diferencia entre el tamaño del fichero y el tamaño de los datos, ya que esta distinción puede proporcionar una visión más clara sobre cómo se está utilizando el espacio en la base de datos y qué medidas pueden ser necesarias para optimizar su rendimiento y almacenamiento. En SQL Server los archivos de base de datos se dimensionan más allá del tamaño real que tienen ocupado por los datos para que las futuras escrituras sean más rápidas. Este espacio libre en los ficheros es importante, por tanto, para el rendimiento pero hay que saber gestionarlo. Una configuración inicial incorrecta del tamaño de los archivos de datos y logs, junto con opciones de autogrowth mal configuradas, puede resultar en un crecimiento fragmentado y subóptimo de los archivos. Esto puede llevar a un uso ineficiente del espacio en disco y afectar negativamente el rendimiento. 

Para evitar estos problemas debemos configurar adecuadamente el tamaño inicial de los archivos de datos y logs basándonos en las previsiones de crecimiento de la base de datos. Sin embargo, las bases de datos cambian con el tiempo y deberemos ajustar los incrementos de autogrowth para minimizar la fragmentación y asegurar un uso eficiente del espacio en disco.

Crecimiento por errores de aplicación

Los errores en el diseño y configuración no son las únicas fuentes de problemas. Las aplicaciones que interactúan con la base de datos pueden causar un crecimiento descontrolado, especialmente si no gestionan adecuadamente las transacciones o si insertan datos de manera ineficiente. 

Errores de aplicación en la gestión de transacciones

Uno de los errores más comunes que puede llevar al crecimiento descontrolado de los logs de transacciones es el manejo inadecuado de las transacciones por parte de las aplicaciones. Esto incluye transacciones que permanecen abiertas por mucho tiempo o que no se cierran correctamente, lo cual puede causar un aumento innecesario en el tamaño del log.

Debemos revisar y optimizar el código de la aplicación para asegurarnos de que las transacciones se manejen de manera eficiente. Es crucial que las transacciones sean lo más cortas posibles y que se cierren correctamente para evitar el crecimiento innecesario del log. Prestaremos una atención especial a las transacciones de larga duración o aquellas que se producen con demasiada frecuencia.

Errores por insertar datos erróneamente

Otra causa de crecimiento desmedido es la inserción de datos redundantes debido a errores de lógica en la aplicación o a escrituras descontroladas en tablas de log de actividad de las aplicaciones o procesos. Esto puede suceder cuando las aplicaciones insertan datos duplicados debido a fallos en la validación o la falta de controles adecuados para evitar duplicados.

Para evitarlo, deberemos implementar mecanismos de validación en el nivel de la aplicación para prevenir la inserción de datos redundantes. Además, utilizar restricciones de unicidad y primary keys en la base de datos para garantizar la unicidad de los registros. Las tablas de auditoría o de log deberán limpiarse frecuentemente y revisar que la información registrada es útil. Por ejemplo, una buena práctica si un proceso tiene una lógica de reintentos es solo registrar una vez el error y poner una columna con un contador de repeticiones si el error es el mismo en cada reintento.

Evitar el crecimiento con mantenimiento

La gestión y mantenimiento regulares de nuestros datos es fundamental para controlar el tamaño de las bases de datos SQL Server. Esto incluye la limpieza de datos obsoletos y una monitorización constante del rendimiento y el uso del almacenamiento. Sin una gestión adecuada, es fácil que el crecimiento se descontrole, afectando el rendimiento y la eficiencia del sistema.

Limpieza de datos obsoletos

Las bases de datos tienden a acumular datos obsoletos o redundantes que ya no son útiles para la operación actual, contribuyendo al crecimiento desmedido. Esto es especialmente problemático en sistemas que carecen de políticas de limpieza o archivado de datos. Establecer procedimientos regulares de limpieza para eliminar registros obsoletos y/o implementar políticas de retención de datos y archivado que permitan gestionar los datos históricos de manera eficiente, liberará espacio en nuestras bases de datos más activas.

Monitorización y mantenimiento

Para terminar con este artículo, y aunque esto no es un error como tal no quería dejar de comentar que la falta de monitorización y mantenimiento adecuado puede permitir que problemas de crecimiento pasen desapercibidos. Esto incluye no solo el seguimiento del tamaño de los datos y logs, sino también la identificación de problemas de rendimiento que pueden indicar un uso ineficiente de recursos. Utilizar herramientas de monitorización propias o de terceros y establecer alertas ante crecimientos inusuales de bases de datos y logs puede evitarnos el problema de que el servidor termine quedándose sin espacio y deje de admitir nuevas transacciones. 

Conclusión

El crecimiento excesivo de las bases de datos SQL Server a menudo se debe a una combinación de errores de modelado, configuraciones inadecuadas y prácticas de gestión insuficientes. Abordar estos problemas con soluciones prácticas, como la normalización adecuada, la gestión eficiente de índices, y la implementación de políticas de mantenimiento y backups, puede ayudar a controlar el tamaño de la base de datos y asegurar un rendimiento óptimo. Con un enfoque proactivo en estas áreas, seremos capaces de manejar el crecimiento de las bases de datos de manera más efectiva y evitar problemas futuros relacionados con el almacenamiento y el rendimiento.

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!

No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo. 

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario
02
Ago
2024

Mover BBDD de sistema

A lo largo de nuestra experiencia como administradores de bases de datos, en ocasiones nos vamos a  encontrar con la necesidad de mover las bases de datos de sistema en SQL Server. Ya sea por motivos de rendimiento, capacidad, o mantenimiento, saber realizar esta tarea de manera segura y eficiente es crucial para garantizar la integridad y disponibilidad del sistema tras el cambio. En este artículo quiero detallaros el proceso de reubicación de las bases de datos de sistema master, model, msdb, tempdb, distribution, y SSISDB, desde las consideraciones previas, pasando por los pasos detallados, hasta las mejores prácticas para minimizar riesgos.

Consideraciones Previas al Mover las Bases de Datos de Sistema

Estamos hablando de un gran cambio y tenemos que actuar como tal. Antes de proceder con el movimiento de las bases de datos de sistema, es fundamental entender que estos componentes son críticos para el funcionamiento de SQL Server, no es una intervención sin importancia. Un error en este proceso puede dejar el servidor de base de datos como un caro pisapapeles incapaz de arrancar o llevarnos a una pérdida de datos. Por lo tanto, debemos asegurarnos de tener una copia de seguridad completa y actualizada de todas las bases de datos de sistema y de usuario. Además, es recomendable realizar este tipo de operaciones en periodos sin actividad o durante ventanas de mantenimiento planificadas ya que van a requerir de paradas del servicio.

Requisitos Previos

Como acabamos de ver, un cambio de esta índole requiere de mucha preparación, a continuación os dejo una lista de pasos que para mi son imprescindibles antes de acometer este tipo de intervenciones:

  1. Notificar de la parada: Debemos asegurarnos de que todos los usuarios están informados de que el servicio de bases de datos no va a estar disponible durante el tiempo que dure la intervención y de que deben parar sus aplicaciones.
  2. Detener la monitorización: Es crucial detener la monitorización sobre el servidor durante la intervención para evitar la saturación por falsas alarmas. 
  3. Copia de Seguridad Completa: Como en toda intervención, debemos asegurarnos de disponer de una copia de seguridad completa tanto de los datos de usuario como de las bases de datos de sistema para poder volver atrás en caso de problemas.
  4. Plan de Recuperación: Muy ligado con el anterior punto, de nada nos sirve tener las copias sin un plan de recuperación bien documentado y probado en caso de que algo salga mal.
  5. Documentación del Sistema: Durante el proceso tan crítico que vamos a llevar a cabo no hay lugar para la duda, es mejor dedicar unos minutos antes de empezar a anotar la ubicación actual de los archivos de base de datos y logs de transacciones así como sus nombres que luego nos van a hacer falta.

Mover la Base de Datos master

La base de datos master es el corazón del sistema de SQL Server, ya que contiene información sobre la configuración del servidor, inicios de sesión, y otros metadatos críticos. Para mover esta base de datos, seguiremos estos pasos:

  1. Modificar la Ruta del Archivo de la Base de Datos: Utilizaremos el comando ALTER DATABASE para cambiar la ruta de los archivos de datos (MDF) y de registro (LDF).
    ALTER DATABASE master MODIFY FILE (NAME = master, FILENAME = 'NuevaRuta\master.mdf');
    ALTER DATABASE master MODIFY FILE (NAME = mastlog, FILENAME = 'NuevaRuta\mastlog.ldf');

    2. Detener el Servicio de SQL Server: Deteneremos el servicio de SQL Server desde el Administrador de Servicios o mediante una línea de comandos con el comando net

      net stop MSSQLSERVER.

      3. Mover los Archivos: C1opiaremos los archivos MDF y LDF a la nueva ubicación especificada.

      4. Modificar los Parámetros de Inicio del Servicio: Actualizaremos los parámetros de inicio del servicio SQL Server para reflejar la nueva ubicación de los archivos master y mastlog.

      5. Iniciar el Servicio de SQL Server: Finalmente, reiniciamos el servicio y verificaremos que SQL Server se inicia correctamente.

         

        Mover Otras Bases de Datos de Sistema

        Mover las base de datos Model y msdb

        El procedimiento para mover las bases de datos model y msdb es similar al de la base de datos master, pero con algunas diferencias clave ya que no será necesario configurar ningún parámetro del servicio. En ambos casos, usaremos ALTER DATABASE para modificar la ubicación de los archivos de datos y log, luego detendremos el servicio de SQL Server, moveremos los archivos manualmente y finalmente reiniciaremos el servicio.

        ALTER DATABASE model MODIFY FILE (NAME = modeldev, FILENAME = 'NuevaRuta\model.mdf');
        ALTER DATABASE model MODIFY FILE (NAME = modellog, FILENAME = 'NuevaRuta\modellog.ldf');
        ALTER DATABASE msdb MODIFY FILE (NAME = MSDBData, FILENAME = 'NuevaRuta\MSDBData.mdf');
        ALTER DATABASE msdb MODIFY FILE (NAME = MSDBLog, FILENAME = 'NuevaRuta\MSDBLog.ldf');

        Mover la tempdb

        La base de datos tempdb es una base de datos de sistema especial utilizada para operaciones temporales y almacenamiento de datos de trabajo. A diferencia de las otras bases de datos, tempdb se reconstruye cada vez que SQL Server se reinicia, lo que hace que su reubicación sea más simple. Aquí están los pasos:

        1. Modificar la Ruta de los Archivos: Utilizamos ALTER DATABASE para modificar la ruta de los archivos de datos y registro.
        ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'NuevaRuta\tempdb.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'NuevaRuta\templog.ldf');

        2. Reiniciar el Servicio de SQL Server: Al reiniciar SQL Server, los archivos de tempdb serán recreados en la nueva ubicación.

        3. Borrar los antiguos archivos de tempdb de la ruta original.

          Mover las bases de datos Distribution y SSISDB

          Estas bases de datos son específicas para ciertas características como la replicación y la integración de servicios. Los pasos para mover estas bases de datos son generalmente similares a los descritos anteriormente, pero es crucial entender las dependencias y servicios asociados, ya que esto puede afectar la replicación y la ejecución de paquetes SSIS.

          Conclusión

          Mover las bases de datos de sistema en SQL Server es una tarea que requiere precaución y planificación. Asegurarse de tener copias de seguridad actualizadas, seguir los pasos cuidadosamente, y verificar cada cambio es esencial para el éxito de la operación. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

          Publicado por Roberto Carrancio en SQL Server, 0 comentarios
          12
          Jul
          2024
          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
          02
          Jul
          2024

          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