Teoría BBDD

Bloqueos con un SPID negativo

Los bloqueos en SQL Server son un componente fundamental en la gestión de transacciones concurrentes, asegurando la integridad y consistencia de los datos. Sin embargo, algunos bloqueos pueden presentar características inusuales, como aquellos que involucran identificadores de sesión (SPID) negativos. Estos bloqueos negativos pueden generar confusión si no se comprenden a fondo, ya que están relacionados con operaciones internas de SQL Server o problemas específicos en el manejo de transacciones y recursos.

En este artículo, vamos a ver en profundidad los bloqueos con identificadores de sesión (SPID) negativos en SQL Server, incluyendo los valores del -1 al -5, explicando qué significan, qué los causa y cómo diagnosticarlos y resolverlos. Como vais a poder ver a lo largo del artículo, estos bloqueos no serán los más comunes que nos vamos a encontrar pero si que tienen una gran importancia y debemos conocerlos.

Introducción a los bloqueos en SQL Server

El sistema de gestión de bloqueos de SQL Server asegura que las transacciones accedan a los recursos de manera controlada, evitando conflictos que puedan comprometer la integridad de los datos. Los bloqueos suelen ser representados por un número positivo, que identifica la sesión (SPID) que sostiene el bloqueo. Sin embargo, en situaciones especiales, SQL Server puede mostrar bloqueos con identificadores de sesión negativos.

Estos SPID negativos no representan directamente sesiones de usuario, sino que están relacionados con tareas internas del motor de SQL Server, como la gestión de transacciones distribuidas (DTC), recuperación diferida, y la gestión de latches (mecanismos de sincronización de memoria). A continuación, vamos a explorar cada uno de estos identificadores negativos y sus implicaciones.

SPID -1: Bloqueo por Orphaned Lock (bloqueo huérfano)

El identificador -1 se asocia con bloqueos huérfanos (orphaned locks). Un bloqueo huérfano es un bloqueo que SQL Server ha perdido de vista, es decir, SQL Server ha perdido la referencia a qué sesión tenía el control de dicho bloqueo.

Descripción: El SPID -1 indica que el bloqueo ha sido dejado huérfano, lo que generalmente ocurre debido a errores en la gestión de bloqueos. En muchas ocasiones, este comportamiento es el resultado de un bug en SQL Server o de una desconexión inesperada de una sesión que estaba reteniendo el bloqueo.

Causas comunes: Esto puede suceder si una conexión de cliente se cierra inesperadamente mientras sostenía un bloqueo o si SQL Server experimenta un problema interno que afecta la gestión de los bloqueos. Estos bloqueos huérfanos pueden impedir que otros procesos accedan a los recursos bloqueados.

Diagnóstico y solución: En la mayoría de los casos, SQL Server debería liberar automáticamente los bloqueos huérfanos, pero si persisten, es recomendable revisar los registros de errores (SQL Server error logs) para identificar posibles fallos. Si el bloqueo huérfano afecta el rendimiento del servidor o causa problemas de acceso a los datos, es posible que se necesite reiniciar la instancia de SQL Server o aplicar parches que solucionen el problema.

SPID -2: Bloqueo por Pending DTC Transaction (transacción DTC pendiente)

El SPID -2 está relacionado con las transacciones distribuidas (DTC, Distributed Transaction Coordinator) que están pendientes de finalización. Esto ocurre cuando la conexión del cliente, que formaba parte de una transacción distribuida, se desconecta y la transacción queda en un estado incompleto, esperando que el administrador de DTC (MSDTC) procese el estado final de la transacción.

Descripción: Este identificador de sesión indica que SQL Server está esperando una notificación de cambio de estado por parte del coordinador de transacciones distribuidas (MSDTC). La transacción no puede completarse porque los clientes asociados con la transacción distribuida se han desconectado antes de invocar el commit o rollback.

Causas comunes: Esto suele ocurrir cuando una aplicación cliente que maneja transacciones DTC se desconecta inesperadamente sin finalizar correctamente la transacción. SQL Server queda a la espera de que el cliente confirme si debe comprometer o revertir la transacción.

Diagnóstico y solución: Para resolver el problema, el cliente debe reconectarse y completar la transacción invocando explícitamente un commit o rollback. En situaciones donde el cliente no puede reconectarse, el administrador de SQL Server puede finalizar la transacción manualmente utilizando las herramientas del coordinador de transacciones distribuidas (DTC). También es útil revisar los registros de errores de SQL Server y del DTC para identificar qué causó la desconexión.

SPID -3: Bloqueo por Deferred Recovery (recuperación diferida)

El SPID -3 está relacionado con transacciones diferidas. Una transacción diferida es una transacción que ha sido marcada para ser revertida o recuperada, pero que no puede completarse de inmediato debido a que los recursos necesarios no están disponibles.

Descripción: Este identificador indica que SQL Server mantiene el bloqueo porque una operación de recuperación o reversión ha sido pospuesta. Esto suele ocurrir cuando una transacción está en proceso de ser revertida (rollback), pero la operación no puede completarse debido a problemas con los recursos implicados, como archivos o tablas que ya no están disponibles.

Causas comunes: Las transacciones diferidas suelen ocurrir cuando SQL Server no puede acceder a los recursos necesarios para completar la reversión de la transacción. Un ejemplo sería si una tabla o índice fue eliminado mientras una transacción estaba activa sobre esos objetos. También puede ser resultado de problemas de espacio en disco o de memoria.

Diagnóstico y solución: Para diagnosticar este tipo de bloqueo, puedes utilizar la vista sys.dm_tran_active_transactions, que muestra información sobre las transacciones activas, incluidas las diferidas. Generalmente, SQL Server resolverá estas transacciones diferidas cuando los recursos se vuelvan disponibles, pero en algunos casos podría ser necesario realizar acciones manuales, como restaurar la base de datos o liberar espacio en disco.

SPID -4: Bloqueo por Latch Transition (transición de latch)

El SPID -4 se refiere a las transiciones de latch. Un latch es una estructura interna de sincronización que SQL Server utiliza para gestionar el acceso a los recursos en memoria, como las páginas de datos en la caché de búferes.

Descripción: Este SPID indica que SQL Server está en el proceso de liberar un latch, pero dicha liberación aún no ha finalizado. Estos bloqueos suelen aparecer cuando SQL Server está manejando una alta carga de trabajo que involucra operaciones intensivas de lectura o escritura en memoria.

Causas comunes: Las transiciones de latch son comunes en operaciones de alta concurrencia, como cuando múltiples sesiones intentan acceder a las mismas páginas en la caché de búferes. Esto puede ocurrir durante operaciones de entrada/salida intensivas o en escenarios donde se produce una contención por el acceso a recursos de memoria.

Diagnóstico y solución: Para diagnosticar estos bloqueos, puedes utilizar la vista sys.dm_os_latch_stats para monitorizar las estadísticas de latches. Si los bloqueos relacionados con latches son frecuentes, puede ser necesario optimizar las consultas, rediseñar los índices o ajustar los parámetros de configuración de memoria de SQL Server. También puedes revisar el tamaño de la caché de búferes para asegurarte de que SQL Server tenga suficientes recursos de memoria para manejar la carga de trabajo.

SPID -5: Bloqueo por Latch Task Releasor (liberación de latch)

El SPID -5 está relacionado con la liberación de latches en SQL Server, específicamente con tareas del sistema que están en proceso de liberar un latch. Los latches de entrada/salida (I/O) son los más comunes que se liberan bajo este identificador.

Descripción: Este identificador de sesión indica que SQL Server está esperando que una tarea del sistema libere un latch. Los I/O latches son los más comunes en este tipo de situación, protegiendo el acceso a las páginas de datos durante operaciones de lectura o escritura.

Causas comunes: Los bloqueos con SPID -5 suelen aparecer cuando hay contención en la memoria, particularmente en las páginas de datos almacenadas en la caché de búferes. Si varios hilos intentan acceder a la misma página simultáneamente, SQL Server utiliza un latch para asegurar que sólo un hilo acceda a la página en un momento dado, lo que puede generar tiempos de espera.

Diagnóstico y solución: Para diagnosticar este tipo de bloqueo, puedes utilizar las vistas sys.dm_exec_requests y sys.dm_os_waiting_tasks para identificar las sesiones que están esperando la liberación de latches. Optimizar el diseño de índices o ajustar los patrones de acceso a los datos puede ayudar a reducir la contención por los latches. Además, monitorizar el uso de la memoria y evaluar si SQL Server tiene suficientes recursos para manejar la carga de trabajo puede ser necesario.

Conclusión

Los bloqueos con identificadores de sesión negativos en SQL Server son indicadores de operaciones internas y procesos de administración de recursos dentro del motor de la base de datos. Desde bloqueos huérfanos hasta problemas con transacciones distribuidas y latches, cada uno de estos SPIDs negativos tiene un significado específico y un impacto potencial en el rendimiento y la estabilidad del servidor.

Comprender la naturaleza de estos bloqueos y cómo diagnosticarlos es clave para asegurar el buen funcionamiento de SQL Server. Utilizar herramientas como las vistas de administración dinámica (DMVs) y monitorizar los registros de errores te permitirá identificar problemas antes de que afecten el rendimiento general del sistema. En muchos casos, las soluciones implican ajustes en la configuración de recursos, la optimización de consultas y, en situaciones más complejas, la intervención manual para liberar o resolver los bloqueos pendientes.

SQL Server proporciona un entorno robusto para la gestión de transacciones y acceso concurrente, pero la correcta interpretación de estos SPIDs negativos puede marcar la diferencia en la identificación temprana de problemas que podrían afectar el rendimiento de la base de datos.

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

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios
Vuelve SQL (DATA) Saturday a Madrid

Vuelve SQL (DATA) Saturday a Madrid

¡SQL Saturday Madrid está de vuelta, y lo hace con un nuevo nombre y una energía renovada! Después de la gran acogida de su edición anterior, y tras unos años de parón, SQL Saturday Madrid ahora se transforma en Data Saturday Madrid 2024, prometiendo ser el evento más destacado para todos los apasionados de los datos en España.

Este evento, que se celebrará el próximo 30 de noviembre de 2024 en la Universidad Politécnica de Madrid, Campus Sur, no solo retoma la esencia de las pasadas ediciones, sino que amplía su enfoque para cubrir las últimas tendencias y tecnologías del universo de los datos. Con el objetivo de reunir a profesionales y entusiastas del mundo de SQL, Big Data, la Inteligencia Artificial, la Ingeniería de Datos y todo lo relacionado con la plataforma de datos de Microsoft, Data Saturday Madrid viene cargado de novedades y sorpresas para todos los asistentes.

Un evento global para la comunidad de datos

Data Saturday Madrid 2024 es mucho más que un evento local; es parte de la iniciativa internacional Data Saturdays, que surge como una evolución del clásico SQL Saturday. Esta serie de eventos globales tiene como propósito reunir a la comunidad de profesionales de datos en distintos puntos del mundo, brindándoles la oportunidad de aprender, compartir y conectar en torno a las últimas tecnologías y tendencias en el mundo de la gestión de datos.

El evento de Madrid, al igual que otros Data Saturdays en ciudades de todo el mundo, se centra en temas como la ingeniería de datos, Big Data, inteligencia artificial y soluciones en la nube de Microsoft, como Azure y Power BI. Es un espacio que busca impulsar el crecimiento profesional de los asistentes a través de sesiones formativas de alto nivel y talleres prácticos que permiten una inmersión profunda en los conceptos más actuales​

Un evento para todos los niveles y en dos idiomas

Una de las grandes fortalezas de Data Saturday Madrid 2024 es su compromiso con la accesibilidad y la diversidad. Las sesiones y talleres, que se impartirán inglés o en español, están diseñadas para todos los niveles de experiencia, desde aquellos que recién comienzan en el mundo de los datos hasta los expertos que buscan profundizar en temas avanzados. La agenda del evento incluye 33 sesiones en distintos tracks, permitiendo que cada participante personalice su experiencia según sus intereses y necesidades.

Innovación y conocimiento de la mano de expertos

La jornada del sábado promete ser intensa y emocionante, con ponencias de reconocidos MVPs, MCMs, mentores, ingenieros de Microsoft y especialistas técnicos de renombre. Entre los temas que se abordarán, destacan el ecosistema completo de Power BI, la Inteligencia Artificial Generativa (como Copilot y modelos de lenguaje), SQL Server, Azure SQL, Microsoft Fabric, y muchas más tecnologías que integran el ecosistema de datos de Microsoft, como Snowflake y Power Platform​.

Pero eso no es todo. En los días previos, el 28 y 29 de noviembre, se realizarán talleres especializados de cuatro horas, diseñados para profundizar en temas específicos. Estas sesiones prácticas brindan una oportunidad única de aprender de la mano de expertos y explorar a fondo las herramientas y técnicas que están transformando la manera en que gestionamos y analizamos los datos.

Networking, premios y la tradición de #sqlbeers

Más allá del conocimiento técnico, Data Saturday Madrid 2024 también es un punto de encuentro para la comunidad. Después de una intensa jornada de charlas y aprendizaje, los asistentes podrán disfrutar de momentos de networking, incluyendo el clásico DataBeers, donde la comunidad se reúne para compartir experiencias de forma más relajada. Y, como en ediciones anteriores, no faltarán los sorteos de premios, entre los que destaca la codiciada Xbox Series.

Un evento de la comunidad para la comunidad

Este evento, organizado por y para la comunidad, es una oportunidad excepcional para conectar, aprender y compartir con otros profesionales del sector. La pasión y el entusiasmo de los organizadores se refleja en cada detalle, desde la selección de los ponentes hasta la planificación de las actividades paralelas. No importa si eres un veterano de SQL Saturday o si es tu primera vez asistiendo a un evento de este tipo, Data Saturday Madrid 2024 promete ser una experiencia inolvidable.

En resumen, si te apasiona el mundo de los datos y quieres estar al día con las últimas novedades y tendencias, no puedes perderte Data Saturday Madrid 2024. ¡Nos vemos el 30 de noviembre para celebrar el regreso de la comunidad de datos más grande de España, ahora con un nombre renovado, pero con el mismo espíritu de siempre!

Cartel Data Saturday

PREGUNTAS FRECUENTES

¿Qué es el Data Saturday?

Es un evento para profesionales y futuros profesionales relacionados con Big Data, Business Intelligence y Artificial Intelligence.

¿Dónde y cuando?

El evento se celebrará los días 28, 29 y 30 de Noviembre en la Escuela Técnica Superior de Ingeniería de Sistemas Informáticos UPM ETSI de Madrid (Calla de Alan Turing s/n , 28031 Madrid).
Los días 28 y 29 están destinados a talleres prácticos con una duración de 4 horas y el sábado 30 a las 33 charlas.

¿Cuánto cuesta?

El evento es gratuito. A la hora de reservar la entrada se pedirá una donación mínima de 1€ que irá íntegramente destinada a una ONG de la zona.
Los workshop (talleres de 4 horas) tienen un coste de 49€.

¿De qué temas se hablarán?

Podremos encontrar sesiones relativas a :
– Power BI (todo el ecosistema, todos los niveles)
– Microsoft Fabric
– Generative AI (Copilot, LLM, RAG, OpenAI)
– Motor relacional (cloud, optimización, bloqueos, índices)
– Azure Data Platform
– Azure Databricks
– Integracion con Snowflake
– Integration Services, Analysis Services, Paginated Reports, Data Warehousing
– Big Data, Python, PySpark
– Artificial Intelligence
– Streaming de datos y arquitecturas Lambda
– Machine Learning
– IoT
– Datos en la nube
– Y muchos más!

¿Cómo puedo participar?

Si quieres es asistir y disfrutar aprendiendo, puedes adquirir tu entrada aquí:
https://www.eventbrite.com/e/registro-data-saturday-madrid-2024-sqlsaturdaymadrid-1037072881907

Publicado por Roberto Carrancio en Otros, 0 comentarios
El problema de Halloween

El problema de Halloween

El problema de Halloween es una anécdota clásica en el ámbito de las bases de datos y la informática, que además de ser técnicamente relevante, tiene una historia curiosa detrás de su descubrimiento. A menudo se lo menciona en el contexto de las transacciones concurrentes y la consistencia en los sistemas de bases de datos relacionales. En este artículo, y ya que mañana celebraremos Halloween, quiero contaros en detalle la historia de este problema, y que veamos cómo eso afectó a los sistemas actuales con los que trabajamos. Sentaos y poneos cómodos amigos que este joven aprendiz de abuelo cebolleta os va a contar una historia de los inicios de las bases de datos relacionales.

Historia del problema de Halloween

Era 1976, y en los laboratorios de IBM en San José, California, un grupo de ingenieros trabajaba en el desarrollo de uno de los primeros sistemas de bases de datos relacionales: System R. Entre ellos estaban Don Chamberlin, Pat Selinger, Raymond Boyce y varios otros miembros de un equipo pionero. Su objetivo era crear un sistema eficiente que pudiera manejar grandes volúmenes de datos con integridad y consistencia, un reto tecnológico sin precedentes en aquella época.

La tarde de un viernes a finales de Octubre, mientras experimentaban con actualizaciones masivas de datos, Don Chamberlin, uno de los co-creadores del lenguaje SQL, notó un comportamiento extraño en una consulta que estaban probando. La consulta parecía simple: querían aumentar el salario de todos los empleados que ganaban menos de 3000 dólares. Así que Don escribió algo parecido a esto:

Esperaba que la consulta incrementara el salario de cada empleado que ganara menos de 3000 dólares, pero lo que vio fue desconcertante. Los sueldos de algunos empleados no solo se habían incrementado una vez, sino varias veces en la misma ejecución. Los salarios de los empleados que inicialmente ganaban 2800 dólares, por ejemplo, terminaron siendo mucho mayores de lo esperado.

¿Qué estaba pasando?

Don llamó a Pat Selinger, la ingeniera encargada de la optimización de consultas en System R, y juntos comenzaron a investigar qué estaba pasando. Descubrieron que el problema radicaba en cómo el motor de la base de datos estaba gestionando el índice de salarios. El sistema estaba utilizando el índice para seleccionar las filas que debían ser actualizadas, pero cada vez que se actualizaba el salario de un empleado, el índice no se actualizaba inmediatamente.

Esto significaba que el motor seguía viendo las mismas filas como si aún cumplieran la condición Salario < 3000, incluso después de que el salario ya hubiera sido incrementado. Así, el sistema volvía a seleccionar esas filas y aplicaba otra actualización, lo que provocaba un aumento repetido e inesperado de los salarios.

Pat, quien ya tenía una gran reputación por su trabajo en la optimización de bases de datos, se dio cuenta de que esto no era un simple error; era un problema fundamental en cómo las operaciones de actualización y selección interactuaban cuando se usaban índices. Rápidamente comprendieron que este problema podía ocurrir en cualquier situación donde los datos modificados afectaran al criterio de selección.

Al darse cuenta de la magnitud del problema, y siendo ya altas horas de la noche, el equipo decidió que no iban a poder dar una solución sencilla y que ya trabajarían en una solución al problema pasadas las fiestas de acción de gracias y Halloween, no sin antes poner un nombre al marrón que acababan de descubrir: “El problema de Halloween”.

Origen del nombre

Como acabamos de ver, el problema fue identificado por Don Chamberlin y otros miembros del equipo de investigación, quienes estaban analizando cómo el índice de salario se comportaba de manera inesperada. Curiosamente, este comportamiento erróneo fue descubierto en octubre de 1976, cerca de la fecha de Halloween. A partir de ese momento, el equipo decidió bautizarlo como el problema de Halloween, en honor a la época del año en que fue detectado.

El descubrimiento marcó un hito en la comprensión de cómo los sistemas de bases de datos podían comportarse de manera incorrecta bajo ciertas condiciones de concurrencia y actualización. Desde entonces, el problema de Halloween se convirtió en un caso de estudio clásico sobre los peligros de las transacciones concurrentes mal gestionadas.

Impacto técnico del problema de Halloween

Ya hemos contado historias, ahora pongámonos técnicos para entender por qué esto si da miedo. El problema de Halloween tiene lugar debido a la interacción entre el acceso a los datos mediante índices y las operaciones de actualización que afectan a los mismos índices. Al realizar una operación como la actualización de un campo indexado, el índice puede cambiar, lo que provoca que el plan de ejecución de la consulta vuelva a seleccionar las mismas filas que ya han sido modificadas. Esto es particularmente peligroso en operaciones que implican modificaciones masivas de registros, como las sentencias UPDATE o DELETE, ya que pueden conducir a un bucle interminable de modificaciones.

Uno de los aspectos más críticos del problema de Halloween es que afecta tanto a la consistencia de los datos como al rendimiento de la transacción. En un escenario en el que no se gestiona correctamente este problema, una operación de actualización podría realizar más cambios de los esperados, lo que lleva a resultados incorrectos. Además, la transacción podría consumir más recursos del sistema de los previstos, lo que degrada el rendimiento general.

Soluciones al problema de Halloween

Con el tiempo, los desarrolladores de motores de bases de datos han ideado varias soluciones para mitigar el problema de Halloween. Desde los bloqueos de claves y operadores de bloqueos de rango hasta el uso de los spools en los planes de ejecución de las consultas.

Bloqueos de claves

El bloqueo de claves es una técnica que asegura que las filas que están siendo leídas o modificadas en una transacción no puedan ser afectadas por otras transacciones concurrentes. En el contexto del problema de Halloween, el bloqueo de claves se utiliza para prevenir que una fila que ha sido modificada vuelva a ser seleccionada por la misma transacción. Pero, ¿Cómo funciona?

Cuando una transacción selecciona una fila basada en un índice, el motor de la base de datos coloca un bloqueo en la clave de índice asociada con esa fila. Este bloqueo persiste hasta que la transacción termina, lo que garantiza que ninguna otra transacción o la misma transacción pueda seleccionar o modificar esa fila hasta que el bloqueo se libere. Esto evita que una fila que ha sido actualizada vuelva a ser seleccionada, ya que la clave correspondiente al índice sigue bloqueada durante la ejecución de la transacción.

Operadores de bloqueos de rango

Los bloqueos de rango (range locks) son otra técnica avanzada que utilizan algunos motores de bases de datos, como SQL Server, para evitar el problema de Halloween. Estos bloqueos no solo afectan a las filas individuales, sino que bloquean un rango completo de valores de un índice para evitar que otras transacciones modifiquen o inserten filas en ese rango.

En lugar de bloquear solo una fila específica, el sistema bloquea un rango de valores en el índice. De esta manera, se garantiza que ninguna otra transacción pueda modificar o insertar nuevas filas en ese rango hasta que la transacción actual se complete.

Los bloqueos de rango previenen que las filas modificadas vuelvan a seleccionarse en la misma transacción y aseguran que las operaciones concurrentes no interfieran con la transacción actual.

Operadores Spool

El spool es un operador que actúa como una especie de «almacén temporal» de los datos que han sido leídos durante la ejecución de una consulta. Su principal función es almacenar los resultados intermedios de una operación, de modo que el motor de base de datos pueda trabajar con ellos sin necesidad de volver a acceder a la fuente de datos original. Esto es particularmente útil en casos donde la selección y la actualización de las filas podrían interactuar de manera perjudicial, como ocurre en el problema de Halloween. Existen varios tipos de spools que se utilizan en SQL Server, no vamos a entrar en detalle ahora pues ya le dedicamos un artículo completo.

Cuando SQL Server detecta que una consulta tiene el potencial de sufrir el problema de Halloween, el optimizador de consultas puede introducir un spool en el plan de ejecución para evitar que las filas modificadas sean seleccionadas de nuevo. El spool actúa como una «instantánea» de las filas seleccionadas al inicio de la transacción, de modo que las actualizaciones no afecten a la selección de filas en curso.

Dicho de otra forma, en un escenario donde SQL Server detecta el riesgo de un problema de Halloween, el plan de ejecución podría incluir un Table Spool para garantizar que las filas se procesen de forma correcta, almacenando temporalmente las filas que cumplen con la condición inicial (por ejemplo Salario < 3000). Una vez que todas las filas han sido seleccionadas, el motor aplica la actualización sin el riesgo de que las filas se vuelvan a seleccionar debido a la modificación del índice.

MVCC, la solución de Oracle

El Control de Concurrencia por Múltiples Versiones (MVCC) es un enfoque utilizado por varios sistemas de bases de datos, como PostgreSQL y Oracle. MVCC permite que múltiples versiones de las filas coexistan, lo que permite que las transacciones lean los datos sin interferir con las modificaciones de otras transacciones y así evitar el problema de Halloween.

Cuando una transacción modifica una fila, se crea una nueva versión de esa fila. Las otras transacciones que están leyendo los datos continúan accediendo a la versión anterior de la fila, mientras que la transacción que la está modificando trabaja con la nueva versión. Esto previene que las modificaciones concurrentes afecten a las lecturas en curso.

De esta manera, MVCC elimina el riesgo de que las filas actualizadas sean seleccionadas de nuevo dentro de la misma transacción, ya que las transacciones no leen las versiones modificadas hasta que estén completamente confirmadas (commit). Esto previene el problema de Halloween sin necesidad de bloqueos explícitos.

Conclusión

El problema de Halloween es un claro recordatorio de cómo los detalles técnicos de la ejecución de consultas y las actualizaciones concurrentes pueden generar comportamientos inesperados en los sistemas de bases de datos. A lo largo de los años, los avances en los motores de bases de datos han permitido mitigar este problema, y uno de los mecanismos más efectivos es el uso de operadores spool en los planes de ejecución.

Aunque el problema de Halloween fue descubierto hace más de cuatro décadas, sigue siendo relevante en los sistemas modernos que manejan grandes volúmenes de datos y transacciones concurrentes. Con el uso de operadores como los spools, los motores de bases de datos garantizan que las actualizaciones se realicen de manera eficiente y sin comprometer la consistencia de los datos, lo que permite a los desarrolladores y administradores de bases de datos centrarse en mejorar el rendimiento y la escalabilidad de sus sistemas sin preocuparse por este problema clásico.

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

La pronunciación de SQL: ¿Es-kiu-el o Sicuel?

Una de las discusiones más recurrentes cuando hablamos de bases de datos es cómo se debe pronunciar «SQL» cuando hablamos en inglés: ¿deberíamos decir es-kiu-el o, como mucha gente pronuncia, sicuel? Aunque a primera vista pueda parecer un tema trivial, la evolución de este debate está profundamente entrelazada con la historia de uno de los lenguajes más importantes para la gestión de bases de datos. En este artículo, vamos a hablar de la historia del origen de SQL y su impacto en sistemas como SQL Server y PostgreSQL, mientras aclaramos cómo y por qué se originaron estas dos pronunciaciones.

Orígenes de SQL: El nacimiento de SEQUEL

El lenguaje SQL, que significa Structured Query Language (Lenguaje de Consulta Estructurado), fue desarrollado a principios de la década de 1970 en los laboratorios de IBM por Donald D. Chamberlin y Raymond F. Boyce, basándose en las teorías relacionales de Edgar F. Codd. Inicialmente, el lenguaje se llamaba SEQUEL (Structured English Query Language). El nombre SEQUEL, en inglés, se asemeja fonéticamente a sicuel, por no decir que es prácticamente igual.

Este término refleja la idea original del lenguaje de ser una herramienta de consulta para gestionar bases de datos relacionales. Sin embargo, debido a problemas legales con una empresa británica que ya tenía registrada la marca SEQUEL, IBM decidió cambiar el nombre a SQL. A pesar de este cambio, muchos de los primeros usuarios continuaron usando la pronunciación sicuel, que evocaba al nombre original.

El cambio a SQL y la aparición de es-kiu-el

Aunque el nombre oficial pasó a ser SQL, la pronunciación original sicuel permaneció en uso, especialmente entre aquellos que ya estaban familiarizados con SEQUEL. Sin embargo, también comenzó a surgir una nueva pronunciación: es-kiu-el, que es simplemente el resultado de pronunciar las letras «S-Q-L» por separado en inglés (S es «es», Q es «kiu», L es «el»). Este enfoque más literal se volvió popular, especialmente en entornos más técnicos y entre usuarios que preferían la claridad de pronunciar las siglas tal cual.

Con el tiempo, ambas pronunciaciones coexistieron. La pronunciación sicuel estaba más arraigada entre quienes habían empezado a trabajar con el lenguaje en sus primeros días, mientras que es-kiu-el comenzó a ganar popularidad entre generaciones posteriores y en entornos donde era común pronunciar las siglas una a una.

SQL Server y el debate sobre la pronunciación

SQL Server, desarrollado por Microsoft, ha sido uno de los actores clave en la popularización de SQL a nivel mundial. Lanzado en 1989, este sistema de gestión de bases de datos relacional ha jugado un papel crucial en el crecimiento de SQL como estándar global. A lo largo de su historia, el equipo de SQL Server ha utilizado ambas pronunciaciones de SQL.

Si no me cree mira este vídeo de un anuncio de SQL Server protagonizado por Ed Esber y el mismo Bill Gates en 1989. En el video podemos ver cómo ambas pronunciaciones, sicuel y es-kiu-el, se utilizan de manera intercambiable. Esta falta de un consenso claro refleja cómo las dos formas han coexistido a lo largo del tiempo, sin una regla estricta que indique cuál es la «correcta».

PostgreSQL: Su influencia en la pronunciación

PostgreSQL, a menudo abreviado como Postgres, es otro sistema de gestión de bases de datos relacional que ha jugado un papel importante en la historia de SQL. Al igual que SQL Server, PostgreSQL ha influido profundamente en la evolución de SQL, aunque su origen es independiente.

PostgreSQL fue desarrollado en la Universidad de California en Berkeley en 1986 como parte del proyecto POSTGRES, liderado por el profesor Michael Stonebraker. Inicialmente, Postgres no estaba diseñado para utilizar SQL, sino que empleaba su propio lenguaje de consultas llamado QUEL. No fue hasta 1994 cuando PostgreSQL adoptó SQL como lenguaje estándar, lo que permitió que el sistema ganara popularidad en el ámbito empresarial.

En la comunidad de PostgreSQL, la pronunciación sicuel es también común, ya que se remonta al origen de SQL como SEQUEL. Sin embargo, al igual que con SQL Server, muchos usuarios optan por la pronunciación es-kiu-el, especialmente en países donde es común leer las siglas de manera literal, como ocurre en gran parte del mundo hispanohablante.

El impacto de PostgreSQL en la estandarización

PostgreSQL no solo adoptó SQL, sino que ha jugado un papel crucial en su estandarización y expansión. A lo largo de los años, ha implementado una serie de características avanzadas que luego se han incorporado al estándar SQL, lo que ha reforzado su posición como uno de los motores más potentes y completos. Entre sus aportaciones destacan:

  • CTEs recursivos (Common Table Expressions): Que permiten realizar consultas jerárquicas complejas.
  • Soporte avanzado para JSON: PostgreSQL fue pionero en el manejo de datos no estructurados con JSON, una capacidad que luego se ha vuelto esencial en otros sistemas.
  • Herencia de tablas: Una característica única que extiende el modelo relacional tradicional.

Estas características han influido significativamente en la dirección del estándar SQL y han ayudado a que PostgreSQL sea ampliamente reconocido como uno de los sistemas más avanzados y robustos.

La influencia cultural y regional en la pronunciación de SQL

La elección entre sicuel y es-kiu-el no solo refleja preferencias personales o generacionales, sino también influencias culturales y regionales. En muchos países de habla hispana, es más común escuchar es-kiu-el, ya que esta pronunciación se ajusta mejor a las reglas fonéticas del español. En cambio, en el mundo angloparlante, sicuel sigue siendo predominante, sobre todo entre aquellos que conocieron el lenguaje en su versión original como SEQUEL.

Este fenómeno se observa también en empresas globales, yo lo he visto hasta en Microsoft, donde las pronunciaciones varían incluso entre los empleados. La alternancia entre es-kiu-el y sicuel, como se muestra en el vídeo de SQL Server, subraya que ambas formas son aceptables, y la preferencia suele depender del contexto o de las personas involucradas en la conversación.

Conclusión

No existe una pronunciación «correcta» de SQL. Tanto es-kiu-el como sicuel son formas válidas de referirse al lenguaje. La pronunciación que elijas dependerá de factores como tu trasfondo, la región en la que trabajas y las preferencias de tu entorno. SQL, ya sea pronunciado como sicuel o es-kiu-el, sigue siendo el estándar indiscutible para la gestión de bases de datos relacionales y continuará evolucionando gracias a sistemas como SQL Server y PostgreSQL.

Este debate sobre la pronunciación es solo una pequeña parte de la rica historia de SQL, un lenguaje que ha transformado el mundo de los datos y que sigue siendo fundamental para la infraestructura tecnológica moderna. Lo importante, más allá de cómo lo pronuncies, es la capacidad que ofrece SQL para gestionar y manipular datos de manera eficiente y robusta.

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

KQL y Kusto DB para análisis Real-Time

Hoy quiero hablaros de KQL (Kusto Query Language) y las bases de datos Kusto disponibles en Azure y en el ecosistema de Microsoft Fabric. Estas bases de datos KQL son una herramienta clave para el análisis de grandes volúmenes de datos en tiempo real. Estas tecnologías están diseñadas para gestionar datos masivos de forma eficiente, permitiendo a los usuarios realizar consultas rápidas y complejas sobre registros de datos, logs y telemetría.

Introducción a KQL y Kusto DB en Fabric

Primero de todo, si es la primera vez que oyes hablar de esto, veamos que es KQL. KQL es el lenguaje de consulta utilizado por Azure Data Explorer y las bases de datos Kusto, especialmente útiles en escenarios como monitorización, análisis de logs y análisis de grandes conjuntos de datos. Microsoft Fabric, que incluye servicios como Synapse y Power BI, ha integrado estas herramientas para potenciar su capacidad de análisis en tiempo real. Esta tecnología permite a los usuarios realizar consultas y análisis de registros masivos con eficiencia, algo crítico para sistemas con grandes volúmenes de datos, como aplicaciones empresariales, infraestructuras TI y soluciones de IoT.

Una de las principales ventajas de KQL es su simplicidad y velocidad. A diferencia de SQL, que está optimizado para operaciones transaccionales, KQL se especializa en análisis y consultas sobre flujos masivos de datos. La base de datos Kusto, que soporta KQL, es una base de datos columnar altamente optimizada para la ingesta rápida de datos y consultas ad-hoc.

Fundamentos de KQL

KQL es un lenguaje declarativo y, aunque tiene similitudes con SQL en cuanto a la estructura de las consultas, es mucho más adecuado para escenarios de análisis de grandes volúmenes de datos. Las consultas en KQL siguen un flujo lógico que permite filtrar, agregar, ordenar y transformar datos de manera eficiente.

  • Filtros: La capacidad de filtrar grandes volúmenes de datos rápidamente es fundamental en KQL. A través de operadores como where, es posible reducir drásticamente el conjunto de datos con condiciones sencillas o complejas.
  • Agregación: KQL soporta agregaciones avanzadas como sumas, conteos y promedios, utilizando funciones como summarize para realizar análisis rápidos sobre millones de registros.
  • Uniones y Transformaciones: Con join, se pueden realizar combinaciones entre tablas, algo esencial para análisis más detallados que requieren cruzar múltiples fuentes de datos.

Por ejemplo, una consulta básica para filtrar y agregar datos en KQL podría verse así:

En este ejemplo, se filtran los registros de logs de las últimas 24 horas, se agrupan en intervalos de un día y se ordenan por el tiempo.

Kusto DB: La base de datos columnar en Fabric

Kusto es la base de datos subyacente que soporta las consultas en KQL. Esta tecnología se desarrolló para gestionar grandes cantidades de datos de telemetría y logs, proporcionando respuestas rápidas y escalabilidad masiva.

Kusto está optimizado para la ingesta rápida de datos, permitiendo el almacenamiento columnar y la compresión eficiente. Su diseño está pensado para consultas sobre millones de filas de datos de manera eficiente, algo que no siempre es posible con bases de datos relacionales tradicionales.

Ingesta y procesamiento en tiempo real con KQL

Una de las principales fortalezas de Kusto DB es su capacidad para la ingesta de datos en tiempo real. Esta característica es crucial en escenarios donde los datos se generan continuamente, como en la monitorización de aplicaciones, la ciberseguridad o el seguimiento de infraestructuras. Kusto utiliza tecnologías avanzadas de almacenamiento columnar, permitiendo la segmentación eficiente de los datos y consultas optimizadas.

Microsoft Fabric aprovecha esta tecnología para análisis de datos en tiempo real, lo cual es vital para empresas que necesitan monitorizar sistemas críticos o tomar decisiones basadas en flujos de datos en tiempo real.

Escalabilidad Horizontal

Kusto es una base de datos distribuida que, igual que la mayoría de soluciones de servicios en la nube, está diseñada para escalar horizontalmente de manera eficiente. Esto significa que a medida que aumenta el volumen de datos, Kusto puede expandirse fácilmente para manejar la carga adicional sin sacrificar el rendimiento. Esta arquitectura es ideal para grandes implementaciones empresariales donde el volumen de datos crece de manera exponencial.

En Microsoft Fabric, Kusto se integra perfectamente con otros servicios, como Azure Synapse y Power BI, lo que permite crear soluciones de análisis completas que van desde la ingesta de datos hasta la visualización y el análisis en tiempo real.

Integración de Kusto DB con Microsoft Fabric

En Microsoft Fabric, Kusto DB no actúa de manera aislada, sino que está profundamente integrado con otros componentes clave de la plataforma de datos de Microsoft. Esto incluye la capacidad de ingerir datos desde múltiples fuentes con Dataflows Gen2, procesarlos con notebooks y visualizarlos en herramientas como Power BI o Microsoft Synapse, por ejemplo.

Sinergia con Power BI y Synapse

Power BI, la plataforma de visualización de datos de Microsoft, se puede conectar directamente a Kusto DB, permitiendo crear dashboards y reportes interactivos en tiempo real basados en los datos almacenados. Además, KQL puede utilizarse dentro de Synapse para análisis más detallados, integrando las capacidades de análisis en tiempo real de Kusto con los procesos de análisis de datos más tradicionales.

Por ejemplo, un escenario común es el análisis de logs de ciberseguridad en una gran infraestructura. Los datos de los logs se ingieren en tiempo real en Kusto DB, donde se procesan utilizando KQL. Los resultados pueden visualizarse directamente en Power BI, lo que permite a los equipos de seguridad reaccionar rápidamente ante cualquier anomalía o amenaza detectada.

Casos de uso de KQL en el mundo real

El uso de KQL y Kusto DB en Fabric está especialmente extendido en industrias que necesitan monitorización y análisis en tiempo real de grandes volúmenes de datos. Algunos ejemplos clave incluyen:

  • Monitorización de Aplicaciones en la Nube: Las empresas que gestionan aplicaciones distribuidas en la nube pueden utilizar Kusto DB para almacenar y analizar logs de rendimiento y errores en tiempo real.
  • Seguridad y Cumplimiento: Como ya hemos visto, las organizaciones pueden usar KQL para analizar logs de seguridad, identificando patrones de acceso no autorizados o ataques potenciales. El análisis en tiempo real es esencial para minimizar el impacto de brechas de seguridad.
  • IoT y Telemetría Industrial: Con cada vez más datos provenientes de dispositivos IoT, Kusto permite gestionar y analizar grandes flujos de datos generados por sensores industriales, permitiendo a las empresas mejorar su eficiencia operativa y detectar fallos antes de que se conviertan en problemas.

Conclusión

KQL y Kusto DB son herramientas poderosas dentro del ecosistema de Microsoft Fabric, ofreciendo capacidades de análisis en tiempo real que son esenciales para las empresas modernas. La capacidad de manejar grandes volúmenes de datos, junto con la integración con otras herramientas como Power BI y Synapse, hace que Kusto sea una opción ideal para escenarios de monitorización y análisis de datos masivos. A medida que las empresas continúan generando más datos, tecnologías como KQL y Kusto seguirán desempeñando un papel crucial en la transformación digital.

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, Otros, Power BI, 1 comentario

UPDATE STATISTICS vs sp_updatestats en SQL Server

Como vimos en el pasado artículo, cuando gestionamos bases de datos en SQL Server, uno de los aspectos más importantes es asegurarnos de que las estadísticas están actualizadas. Las estadísticas son fundamentales para que el optimizador de consultas del motor de SQL Server pueda tomar decisiones eficientes sobre cómo ejecutar las consultas. SQL Server nos proporciona varias formas de actualizar estas estadísticas, y dos de las más comunes son el comando UPDATE STATISTICS y el procedimiento almacenado sp_updatestats. En este artículo, vamos a analizar a fondo las diferencias entre ambos, cómo y cuándo utilizarlos, y qué impacto tienen en el rendimiento general de nuestras bases de datos.

Importancia de las estadísticas en SQL Server

Las estadísticas en SQL Server son colecciones de datos que describen la distribución de valores en una o más columnas de una tabla o índice. Estas estadísticas ayudan al optimizador de consultas a estimar la cantidad de filas que devolverá una consulta, lo que a su vez le permite seleccionar los planes de ejecución más eficientes.

Cuando las estadísticas están desactualizadas, el optimizador puede tomar decisiones incorrectas sobre los planes de ejecución, lo que provoca un rendimiento deficiente en las consultas. De ahí la importancia de mantenerlas actualizadas, especialmente en bases de datos con un alto volumen de inserciones, actualizaciones o eliminaciones de datos.

¿Qué es UPDATE STATISTICS?

El comando UPDATE STATISTICS es una instrucción explícita que actualiza las estadísticas para una tabla o índice en particular. Nos ofrece un control muy granular sobre qué estadísticas actualizar y cómo hacerlo. Podemos especificar un conjunto de opciones que nos permiten, por ejemplo, actualizar las estadísticas basadas en un muestreo de datos o una recolección completa de todos los datos.

Sintaxis básica de UPDATE STATISTICS

Para actualizar una estadística en concreto podemos usar el comando UPDATE STATISTICS con la siguiente sintaxis:

Sin embargo, podemos necesitar actualizar todas las estadísticas de una tabla llamada en concreto, en ese caso escribiremos:

Y si queremos actualizar una estadística específica de un índice, podríamos usar el nombre del indice en vez de el nombre de la estadística:

El comando UPDATE STATISTICS también nos permite utilizar varias opciones avanzadas como FULLSCAN, SAMPLE, y RESAMPLE, que determinan el método que SQL Server utiliza para actualizar las estadísticas.

  • FULLSCAN fuerza a SQL Server a leer todas las filas de la tabla para actualizar las estadísticas.
  • SAMPLE nos permite definir un porcentaje o número de filas de la tabla que se usarán para actualizar las estadísticas.
  • RESAMPLE reutiliza las configuraciones de muestreo anteriores para actualizar las estadísticas.

Casos de uso de UPDATE STATISTICS

El uso de UPDATE STATISTICS es apropiado cuando necesitamos un control fino sobre el proceso de actualización de estadísticas. Por ejemplo en bases de datos críticas. En entornos de producción donde el rendimiento es crucial, y necesitamos asegurarnos de que las estadísticas de ciertas tablas grandes o muy consultadas se actualizan con precisión. Otro caso de uso es con tablas con datos muy volátiles. Si tenemos tablas que cambian frecuentemente, como las que contienen datos transaccionales, las estadísticas pueden quedar obsoletas rápidamente. En estos casos, podemos forzar la actualización periódica de las estadísticas con UPDATE STATISTICS.

Limitaciones de UPDATE STATISTICS

La principal desventaja de UPDATE STATISTICS es que requiere que seleccionemos manualmente las tablas o índices que deben ser actualizados. Esto puede ser laborioso en bases de datos con muchas tablas y estadísticas. Además, si no seleccionamos las estadísticas adecuadas, podríamos pasar por alto aquellas que se han desactualizado, lo que afectaría el rendimiento.

¿Qué es sp_updatestats?

sp_updatestats es un procedimiento almacenado proporcionado por SQL Server que actualiza todas las estadísticas en la base de datos actual que hayan sido marcadas como obsoletas. Este procedimiento es mucho más conveniente cuando queremos actualizar las estadísticas de toda la base de datos de forma masiva y automática, sin tener que preocuparnos por cada tabla o índice en particular.

Cómo funciona sp_updatestats

Cuando ejecutamos sp_updatestats, SQL Server examina todas las tablas y determina qué estadísticas deben actualizarse en función de la propiedad modification_counter (contador de modificaciones). Solo las estadísticas que hayan sufrido cambios significativos (según los algoritmos internos de SQL Server) serán actualizadas, lo que optimiza el uso de los recursos del servidor. Para ejecutarlo simplemente usamos:

Al hacerlo, SQL Server actualiza automáticamente las estadísticas necesarias sin necesidad de especificar tablas, índices o configuraciones adicionales.

Casos de uso de sp_updatestats

El uso de sp_updatestats es más apropiado cuando necesitamos realizar una actualización general de las estadísticas en toda la base de datos. Algunos ejemplos de uso incluyen el mantenimiento periódico o las bases de datos con poca actividad.

En bases de datos grandes, donde no queremos revisar manualmente todas las tablas o índices, podemos usar sp_updatestats como parte de nuestras tareas programadas de mantenimiento para asegurarnos de que las estadísticas estén razonablemente actualizadas. Por el contrario, si nuestras bases de datos no experimentan muchos cambios de datos, sp_updatestats puede sernos suficiente para mantener las estadísticas actualizadas sin un impacto significativo en el rendimiento.

Limitaciones de sp_updatestats

Aunque sp_updatestats es conveniente, no nos ofrece el mismo nivel de control que UPDATE STATISTICS. Al ser un procedimiento almacenado, SQL Server decide qué estadísticas actualizar basándose en su propio criterio, lo que puede no ser siempre ideal en situaciones donde necesitamos precisión y control. Además, puede no actualizar todas las estadísticas que en realidad lo necesitan si los cambios en los datos no alcanzan los umbrales establecidos por SQL Server.

Diferencias clave entre UPDATE STATISTICS y sp_updatestats

Como acabamos de ver, los métodos de actualización manual de estadísticas tienen sus diferencias, lo que hace que cada uno sea indicado para un caso concreto. 

Mientras que UPDATE STATISTICS nos permite un control muy específico sobre qué estadísticas actualizar, sp_updatestats es una solución más generalizada.

Por otro lado, sp_updatestats es menos intensivo en términos de recursos, ya que solo actualiza las estadísticas que SQL Server considera desactualizadas, mientras que UPDATE STATISTICS puede ser más intensivo, especialmente si usamos opciones como FULLSCAN.

En cuanto a la sencillez, sp_updatestats es mucho más sencillo de utilizar en escenarios donde no necesitamos un control tan granular sobre las estadísticas. Sin embargo, si necesitamos actualizar solo ciertas tablas o índices críticos, UPDATE STATISTICS es la mejor opción.

Por último, sp_updatestats, gracias a sus características, es más adecuado para procesos automáticos de mantenimiento, mientras que UPDATE STATISTICS puede necesitar más intervención manual, dependiendo del caso de uso.

Cuándo utilizar cada uno

La elección entre UPDATE STATISTICS y sp_updatestats depende de las necesidades específicas de nuestro entorno de base de datos. Si estamos administrando una base de datos crítica con muchas consultas y necesitamos un rendimiento óptimo en tablas específicas, UPDATE STATISTICS con opciones avanzadas como FULLSCAN es la mejor opción. Esto garantiza que las estadísticas se actualicen con precisión y se basen en datos reales y completos pero tendrá un alto coste en recursos.

Por otro lado, si buscamos un enfoque menos manual y necesitamos actualizar las estadísticas de toda la base de datos sin dedicar demasiado tiempo a configurar el proceso, sp_updatestats es una opción rápida y eficaz, especialmente cuando se utiliza en combinación con tareas programadas de mantenimiento.

Conclusión

Mantener las estadísticas actualizadas en SQL Server es una parte fundamental del mantenimiento de la base de datos para asegurar el rendimiento óptimo de las consultas. Mientras que UPDATE STATISTICS nos da un control detallado sobre qué estadísticas actualizar y cómo hacerlo, sp_updatestats ofrece una solución más automatizada y general para mantener la base de datos en buen estado.

La clave está en conocer cuándo utilizar cada enfoque. Si gestionamos bases de datos con altos volúmenes de datos o con requisitos específicos de rendimiento, optar por UPDATE STATISTICS puede ser lo más adecuado. Sin embargo, en escenarios de mantenimiento general, sp_updatestats nos proporciona una forma conveniente y eficaz de mantener las estadísticas actualizadas sin esfuerzo manual adicional. Como siempre, es fundamental realizar pruebas y monitorear el impacto de estas operaciones en el rendimiento de nuestras consultas y en el uso de los recursos del sistema.

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

Actualización de estadísticas en SQL Server

Las estadísticas en SQL Server son fundamentales para que el optimizador de consultas pueda generar planes de ejecución eficientes. Sin ellas, el rendimiento de las consultas se vería gravemente afectado, ya que el motor de base de datos se basa en estas estadísticas para estimar cuántas filas serán procesadas, seleccionar los índices correctos, y en general, tomar decisiones optimizadas. En este artículo, veremos los diferentes tipos de actualización de estadísticas en SQL Server: las actualizaciones automáticas, las automáticas asimétricas y las manuales.

¿Qué son las estadísticas en SQL Server?

Antes de entrar en los tipos de actualización de estadísticas, es importante tener claro qué son las estadísticas en SQL Server. Estas, son colecciones de metadatos que describen la distribución de los valores en una o más columnas de una tabla o índice. SQL Server crea y mantiene estas estadísticas para ayudar al optimizador de consultas a evaluar de manera precisa el costo de ejecutar una consulta.

Una estadística consta de un histograma, que es un resumen de los valores en la columna, junto con un conjunto de densidades que indican cuán distribuidos están esos valores. Esto le permite a SQL Server hacer predicciones precisas sobre las operaciones de búsqueda, escaneo y uniones entre tablas.

Actualización automática de estadísticas en SQL Server

SQL Server incluye una opción que permite que las estadísticas se actualicen automáticamente cuando el sistema detecta que han quedado desfasadas. Esta es la opción, configurable a nivel de base de datos, y se conoce como AUTO_UPDATE_STATISTICS y está activada por defecto.

¿Cuándo se actualizan automáticamente?

Las estadísticas se actualizan automáticamente cuando SQL Server detecta que ha habido un cambio significativo en la distribución de los datos en una tabla o índice. De manera general, SQL Server utiliza un umbral basado en el número de filas modificadas:

  1. Si una tabla tiene menos de 500 filas, las estadísticas se actualizan después de que 500 modificaciones ocurran en la tabla.
  2. Si una tabla tiene más de 500 filas, se actualizan cuando el número de filas modificadas supera el 20% de la tabla más 500 filas.

En versiones anteriores a SQL Server 2016, este umbral era distinto y podía ser bastante ineficiente, especialmente en tablas grandes, ya que requería una cantidad considerable de cambios en los datos para activar la actualización automática. Esto significaba que las estadísticas podían quedarse desactualizadas por un largo tiempo si los cambios en los datos eran graduales.

Beneficios de la actualización automática

El mayor beneficio de las estadísticas automáticas es que reduce la necesidad de intervención manual. El sistema se encarga de mantener las estadísticas al día, lo que es útil en entornos donde no se dispone de un DBA que monitorice constantemente las operaciones. Sin embargo, en ciertas situaciones, especialmente cuando el volúmen de datos empieza a crecer, este mecanismo puede no ser suficiente para garantizar el rendimiento óptimo, lo que nos obliga a añadir otros mecanismos de actualización adicionales.

Actualización automática asimétrica de estadísticas

SQL Server introdujo en versiones recientes una característica conocida como Asynchronous Statistics Update o AUTO_UPDATE_STATISTICS_ASYNC, que se traduce en actualizaciones automáticas de estadísticas en segundo plano. Esta característica permite que las estadísticas se actualicen de manera asíncrona, es decir, sin detener la ejecución de la consulta que disparó la necesidad de actualización.

¿Cómo funcionan las actualizaciones asimétricas?

Cuando el modo AUTO_UPDATE_STATISTICS_ASYNC está habilitado, SQL Server no espera a que las estadísticas se actualicen antes de ejecutar la consulta. En lugar de detenerse y esperar a que las estadísticas se regeneren, la consulta se ejecuta utilizando el plan basado en las estadísticas antiguas. Luego, en segundo plano, SQL Server actualiza las estadísticas para futuras consultas.

Este enfoque tiene varias ventajas, ya que evita que las consultas sufran retardos debido a la actualización de estadísticas en tablas grandes, lo que puede ser un proceso costoso y demorado. Sin embargo, estaremos ejecutando las consultas con un plan subóptimo que podría afectar gravemente al rendimiento.

Cuándo utilizar las actualizaciones asimétricas

Las actualizaciones asimétricas son especialmente útiles en escenarios donde se prioriza la latencia de las consultas sobre la exactitud inmediata de las estadísticas. Por ejemplo, en sistemas OLTP de alta concurrencia donde la velocidad de respuesta es crítica, habilitar las actualizaciones asimétricas puede mejorar la experiencia del usuario.

No obstante, hay que tener cuidado, ya que la primera consulta que se ejecute con estadísticas obsoletas podría tener un plan de ejecución subóptimo, lo que afectaría el rendimiento de esa consulta específica. Sin embargo, consultas posteriores, que se ejecuten una vez que esa actualización de estadística haya concluido, deberían beneficiarse de las estadísticas actualizadas.

Actualización manual de estadísticas

Por último, tenemos la opción de actualizar las estadísticas de manera manual. Esto se hace cuando el DBA o el equipo de desarrollo tenemos un control más preciso sobre cuándo y cómo deben actualizarse las estadísticas en el sistema. Las actualizaciones manuales se realizan mediante el comando UPDATE STATISTICS, o utilizando los procedimientos almacenados del sistema como sp_updatestats.

¿Cuándo realizar actualizaciones manuales?

Es recomendable hacer actualizaciones manuales en los siguientes escenarios:

  • Carga masiva de datos: Cuando se insertan, actualizan o eliminan grandes cantidades de datos en una tabla, es probable que las estadísticas se queden desactualizadas antes de que el umbral de actualización automática se alcance. En este caso, actualizar las estadísticas manualmente puede mejorar drásticamente el rendimiento de las consultas subsiguientes.
  • Procesos de ETL: En operaciones de ETL donde se transforman y mueven grandes volúmenes de datos, realizar una actualización manual de estadísticas al final del proceso puede ayudar a asegurar que las consultas que utilicen esos datos optimicen su ejecución.
  • Consultas de bajo rendimiento: Si observamos un descenso significativo en el rendimiento de ciertas consultas, puede ser útil actualizar manualmente las estadísticas para asegurarnos de que el optimizador de consultas tiene información precisa y actualizada sobre la distribución de los datos.

Estrategias de actualización manual

Existen diferentes estrategias para realizar actualizaciones manuales. Una opción es usar el comando UPDATE STATISTICS directamente sobre tablas específicas o sobre todas las tablas de una base de datos. Otra opción más eficiente es utilizar sp_updatestats, que actualiza las estadísticas de todas las tablas que hayan sufrido modificaciones, evitando el coste innecesario de actualizar estadísticas que no requieren actualización.

Además, SQL Server permite configurar el grado de muestreo en las estadísticas mediante el parámetro WITH FULLSCAN, que obliga a SQL Server a escanear todas las filas en lugar de hacer un muestreo. Esto es especialmente útil cuando queremos asegurar la mayor precisión posible, aunque puede ser más costoso en términos de tiempo.

Actualización de estadísticas como parte de un plan de mantenimiento

Aunque las actualizaciones automáticas funcionan bien en la mayoría de los casos sencillos, en cuanto la base de datos y los requerimientos crecen, puede ser recomendable que incluyamos la actualización de estadísticas como parte de nuestros planes de mantenimiento. Esta práctica asegura que las estadísticas estén siempre actualizadas de forma programada, evitando que se queden obsoletas y afecten el rendimiento del sistema.

Implementación de un plan de mantenimiento

El uso de planes de mantenimiento en SQL Server es una estrategia común para tareas recurrentes como la reconstrucción de índices, la limpieza de la base de datos y la actualización de estadísticas. Sin embargo, los planes de mantenimiento estándar de SQL Server a menudo carecen de la flexibilidad y optimización que muchos entornos requieren. Es aquí donde entran los scripts de mantenimiento de Ola Hallengren, ampliamente reconocidos en la comunidad SQL Server por su robustez y capacidad de personalización.

Ola Hallengren ofrece un conjunto de scripts que permiten configurar tareas de mantenimiento, incluida la actualización de estadísticas, de manera muy eficiente. Estos scripts ofrecen un control avanzado sobre cómo y cuándo se deben actualizar las estadísticas, permitiendo especificar opciones como:

  • Tablas específicas: Se pueden actualizar solo las estadísticas de las tablas que lo necesiten, en lugar de hacer un barrido completo de todas las tablas.
  • Opciones de muestreo: El script permite configurar el tipo de muestreo para las estadísticas, lo que ofrece un mayor control sobre el rendimiento y precisión de las actualizaciones.
  • Actualización condicional: El script de Ola Hallengren también permite que las estadísticas se actualicen solo cuando las tablas hayan alcanzado un cierto umbral de modificaciones, lo que evita actualizaciones innecesarias.

Si estás buscando una solución integral y flexible para el mantenimiento de estadísticas, puedes consultar los scripts de Ola Hallengren en su página oficial.

Configuración del script de Ola Hallengren para estadísticas

El script de mantenimiento de Ola Hallengren nos permite programar la actualización de estadísticas con una sintaxis sencilla y múltiples opciones. Un ejemplo básico de uso para actualizar estadísticas sería:

En este ejemplo, se actualizan todas las estadísticas de la base de datos especificada, pero solo aquellas que hayan sido modificadas. Esta opción es excelente para evitar el coste innecesario de actualizar estadísticas que no lo requieren.

Consideraciones y mejores prácticas

El uso adecuado de las actualizaciones automáticas, asimétricas, manuales y mediante planes de mantenimiento depende del contexto y la carga de trabajo del sistema. Algunas recomendaciones incluyen:

  • Mantener activadas las actualizaciones automáticas: En la mayoría de los casos, es recomendable dejar activada la opción AUTO_UPDATE_STATISTICS para que SQL Server mantenga las estadísticas actualizadas sin intervención manual. Esto cubre dignamente la mayoría de los escenarios diarios sin añadir carga administrativa adicional.
  • Utilizar actualizaciones asimétricas en entornos de alta concurrencia: Las actualizaciones asíncronas pueden mejorar el rendimiento en algunos sistemas OLTP donde la velocidad de respuesta es crucial, aunque deben usarse con precaución para evitar planes de ejecución subóptimos. Antes de activar esta opción te recomiendo probarla y ver si realmente es beneficiosa para ti..
  • Incluir las actualizaciones en planes de mantenimiento: Utilizar herramientas avanzadas como los scripts de Ola Hallengren para actualizar estadísticas de forma regular y controlada es una práctica recomendada en entornos críticos o con grandes volúmenes de datos. Esto nos asegura que las estadísticas estén siempre actualizadas, reduciendo el riesgo de que las consultas sufran debido a información desactualizada.

Conclusión

Las estadísticas en SQL Server son fundamentales para el rendimiento de las consultas, y mantenerlas actualizadas es clave para que el optimizador de consultas genere planes de ejecución eficientes. Ya sea que optemos por actualizaciones automáticas, asimétricas, manuales o basadas en un plan de mantenimiento, tener una estrategia clara es esencial para asegurar un rendimiento óptimo en la base de datos.

Si deseas más detalles sobre cómo implementar planes de mantenimiento efectivos o utilizar los scripts de Ola Hallengren para optimizar tus estadísticas, consulta nuestro artículo sobre planes de mantenimiento en SQL Server para obtener una visión completa de cómo automatizar y mejorar estas tareas rutinarias.

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