Roberto Carrancio

Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.
Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.

¿Es bueno comprimir los backups de SQL?

Cuando tenemos un SQL Server con licencia standard o enterprise tenemos la opción de comprimir las copias de seguridad. Pero, ¿realmente es buena idea comprimir los backups? ¿se reduce mucho el tamaño? ¿afecta al rendimiento? Eso es justo lo que os trato de demostrar en este video con varias pruebas para que podamos comprobarlo juntos. Si quieres jugar déjame un comentario con lo que crees que va a pasar antes de reproducir el vídeo.

Como has visto, aunque los backups comprimidos van a requerir más recursos de CPU tanto para hacerse como para restaurarse terminan tardando mucho menos. El almacenamiento SIEMPRE es el hardware más lento y por tanto cualquier ahorro en ese recurso se va a notar sobre cualquier otro aspecto. Y esta prueba ha sido con la copia en local, imaginaos que se tiene que llevar por red a un NAS o a la nube dependiendo de nuestra tasa de subida de la conexión a internet, la diferencia sería mucho mayor.

A no ser que tengas problemas de consumo de CPU en tu máquina y el consumo de E/S de disco en el dispositivo de backup no sea un problema para ti mi recomendación es que comprimas los backups.

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, Videos, 2 comentarios

Actualización Segura en Always On

Hoy vamos a aprovechar que recientemente se ha liberado SQL 2022 – CU13 para hablar de un proceso a simple vista trivial, pero que requiere de planificación, como es la actualización de SQL Server en los nodos de un grupo de disponibilidad Always On. No es la primera vez que comentamos en el blog la importancia de mantener nuestros SQL Server siempre actualizados para evitar vulnerabilidades graves como la que vimos aquí. En este sentido, nuestros Always On (que además suelen contener la información más crítica) son especialmente delicados. Y es que cualquiera puede ejecutar un parche de actualización y darle a siguiente hasta que termine pero, hacerlo bien, sobre todo en infraestructuras complejas como los Always On, requiere un cariño extra.

¿Qué es un Always On?

Si estás perdido en este punto no te preocupes, vamos a empezar por el principio, los grupos de disponibilidad Always On son una solución de alta disponibilidad que incorpora SQL Server en la que, por medio de un clúster de Windows (WSFC) varios servidores o nodos replican la información de nuestras bases de datos de manera síncrona o asíncrona. Esta es una breve pincelada (más bien un resumen a brocha gorda) de esta complejísima solución, si quieres saber más pásate por el artículo que le dedicamos a este tema.

El proceso de actualización

Cualquier proceso de actualización bien planeado debe constar de 3 fases principales, las pruebas previas (conocidas también como pre-checks), la actualización propiamente dicha y las pruebas finales o post-checks. Cuando hablamos de un Always On esto también va a ser así a grandes rasgos pero va a tener particularidades como pasos previos y posteriores específicos para cada uno de los nodos en función de su rol.

Pasos previos globales para la actualización

Antes de empezar a actualizar nuestros SQL Server del Always On, al igual que en cualquier proceso de actualización, deberemos revisar la documentación de la actualización en busca de errores conocidos o incompatibilidades que puedan hacer que abortemos el proceso antes de iniciarlo.

Una vez que sabemos que la actualización es teóricamente viable, vamos a verificar el entorno, en este punto verificaremos la salud de nuestro Always On (y su quórum) y comprobaremos que hay espacio suficiente en los discos para acometer con éxito el proceso de actualización. 

Con todas las comprobaciones finalizadas llega el momento de preparar el entorno, idealmente estaremos en un momento sin ninguna carga de trabajo aunque, en caso de los entornos críticos que requieren de un Always On, esto suele ser inviable. Igualmente nosotros haremos una copia de seguridad de los datos y deshabilitaremos los jobs no críticos para evitar en la medida de lo posible cualquier interferencia en el proceso. En este sentido, también es recomendable deshabilitar el balanceo automático durante todo el proceso.

Actualización paso a paso

Llega el momento de empezar a actualizar, empezaremos siempre por las réplicas secundarias externas de nuestro Always On (en caso de tenerlas) o por las que tengan replicación asíncrona. Estas réplicas tienen la ventaja de no estar sincronizadas en tiempo real con la réplica principal por lo que si algo sale mal el impacto será menor. Empezaremos validando nuevamente el estado de la sincronización (idealmente verificaremos el failover) y deteniendo la replicación de datos para las bases de datos de la réplica a actualizar. Con la replicación detenida aplicaremos el parche de actualización.Una vez aplicado el parche podremos reanudar la sincronización y verificar que todo ha salido bien. Repetiremos estos pasos por todas las réplicas secundarias. Comprobaremos que todas las réplicas tienen los datos actualizados y están sincronizando al finalizar el proceso.

Con todas las réplicas secundarias actualizadas y verificado que no ha habido ningún problema llega el momento más crítico: actualizar el nodo primario. Empezaremos verificando la replicación para garantizar que no haya pérdida de datos y realizando un failover (balanceo) del rol a otro nodo. En este momento el rol principal ya será uno de los actualizados por lo que podremos proceder en este como en los anteriores. Detendremos la replicación, aplicaremos el parche, reanudaremos la sincronización y verificaremos que todo está correcto. En caso de que sea necesario realizaremos otro failover para devolver el rol al nodo principal inicial.

Pasos posteriores a la actualización

Una vez que ya tenemos todos los nodos actualizados es el momento de las comprobaciones finales. Comprobaremos la versión de SQL y que todos los nodos están sincronizando. MUY IMPORTANTE, volveremos a habilitar los jobs que hayamos deshabilitado al inicio y el balanceo automático . Con esto ya habría finalizado el proceso, recuerda que debes prestar especial atención a que las aplicaciones vuelvan a conectar correctamente y al rendimiento global tras la actualización.

¿Por qué detener la sincronización durante la actualización?

Hemos comentado que cuando aplicas un parche a una réplica, ya sea sincrónica o asincrónica, es recomendable parar la replicación de esa réplica durante el proceso de actualización. Os he dicho que antes de aplicar el proceso de actualización de cada nodo debíamos detener la sincronización para habilitarla de nuevo después, justo al terminar ese nodo y antes de empezar con los siguientes. Esto se debe a que la aplicación de un parche puede causar cambios en la base de datos que podrían interrumpir la replicación si ésta sigue activa. Al parar la replicación, te aseguras de que cualquier cambio realizado por el parche no afecte a las otras réplicas hasta que hayas verificado que el parche se ha aplicado correctamente y que la réplica actualizada está funcionando como se espera.

Esto también tiene un punto negativo, cuando detienes la replicación de una base de datos, el nodo principal sigue acumulando los cambios en sus ficheros de log de transacciones por lo que asegúrate de tener suficiente espacio y mantén vigilado en todo momento el crecimiento de los ficheros.

Conclusión

Aplicar un parche de actualización a nuestros servidores siempre es una tarea delicada pero, con una buena planificación y siguiendo los pasos correctos podremos hacerlo sin mayor problema. Recuerda que lo que hemos comentado en este post son una guia de recomendaciones para una actualización perfecta en un entorno ideal, la vida real no siempre es tan idílica y puede que tengamos que prescindir de alguno de los pasos. Sin embargo hay que conocerlos y entender bien el por qué están en esta guía para poder valorar el riesgo de no acometerlos. Y si tienes tus SQL en la nube como bases de datos o instancias administradas de Azure, enhorabuena, te has ahorrado para siempre todos estos pasos.

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 Alta Disponibilidad, SQL Server, 2 comentarios

CONTROLAR EL TAMAÑO DE NUESTRAS BASES DE DATOS

Controlar diariamente el tamaño de nuestras tablas y los ficheros de bases de datos es clave para poder afrontar en el futuro una posible incidencia de espacio en disco. Gracias a esta monitorización en nuestro SQL Server vamos a poder localizar que base de datos y que tabla es la que ha crecido hasta llenar el disco y provocarnos una incidencia. En ocasiones una tabla crece sin control hasta llenar el disco y gracias a esta monitorización del tamaño de las bases de datos y las tablas nos va a ser muy sencillo de localizar. No esperes a que sea tarde y no tengas las herramientas necesarias, monitoriza desde ya tus ficheros.

A continuación te dejo los scripts que he usado para monitorizar el tamaño en el video, recuerda adaptarlos a tu base de datos de monitorización y, en caso de ser necesario, cambiar la verificación de las tablas por un código compatible con tu versión de SQL (pídeme ayuda en los comentarios del video si lo necesitas).

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

Masterclass Niveles de Aislamiento en SQL Server

Como ya os anuncié la semana pasada, la madrugada del pasado jueves 23 (hora española) tuvo lugar el evento Noches de DBAs en el que, invitado por Alberto de Rossi, pude dar una masterclass sobre niveles de aislamiento en SQL Server para la comunidad Power BI User Group de Lima. Por suerte para todos, esta masterclass está grabada y publicada abiertamente en YouTube. A continuación os comparto la grabación y las diapositivas que vimos en la sesión.

Como sabéis, los niveles de aislamiento y los bloqueos son uno de los temas que más hemos tratado en el blog por lo que a continuación os voy a dejar varios de los artículos en los que podéis profundizar para encontrar más información sobre el tema:

Espero que os haya gustado esta sesión, y que sea la primera de muchas. Dejad vuestro me gusta y comentario para que desde la comunidad nos tengan en cuenta. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

¿Qué son las bases de datos NoSQL?

Recientemente vi un vídeo corto en TikTok en el que el creador del lenguaje SQL se hacía eco de las novedades de las bases de datos NoSQL y, al contrario de lo que podéis estar pensando, alababa sus bondades. 

Menos mal que habló de bases de datos NoSQL porque si llega a decir algo parecido sobre Excel yo pierdo la fe en esto que hacemos y me convierto en monje de clausura con voto de silencio de por vida.

Pero, no perdamos el foco, la verdad es que el paradigma en cuanto a consumo de información está cambiando y esto nos está llevando a un escenario en el que nos encontramos constantemente con nuevos desafíos y oportunidades. Uno de estos desafíos es que cada vez es más común encontrarnos con entornos en los que las restricciones de una base de datos relacional limitarían su usabilidad. De ahí ha surgido una gran oportunidad y no es otra que el surgimiento de las bases de datos NoSQL. Pero, ¿qué son exactamente las bases de datos NoSQL y por qué son importantes?

¿Qué son las bases de datos NoSQL?

Debemos leer NoSQL como Not Only SQL o “No Solo SQL” en español, son un tipo de sistema de gestión de bases de datos que permite el almacenamiento y la recuperación de datos que se modelan de formas distintas a las tabulares utilizadas en las bases de datos relacionales. Estas bases de datos surgieron en respuesta a las limitaciones de las bases de datos SQL tradicionales, especialmente para manejar grandes cantidades de datos distribuidos o para trabajar con archivos de distinto formato en la era del contenido multimedia.

Características de las bases de datos NoSQL

Las bases de datos NoSQL tienen varias características que las distinguen de las bases de datos SQL tradicionales. Algunas de estas características incluyen:

  • Escalabilidad horizontal: Las bases de datos NoSQL están diseñadas para expandirse fácilmente a través de múltiples servidores sin interrupciones de servicio. Esto las hace ideales para aplicaciones con grandes volúmenes de datos y muchas operaciones de lectura y escritura.
  • Flexibilidad de esquemas: A diferencia de las bases de datos SQL, que requieren que defina un esquema antes de insertar datos, las bases de datos NoSQL suelen ser “sin esquema”. Esto significa que puede insertar datos sin definir primero qué tipo de datos va a insertar.
  • Alta disponibilidad: Las bases de datos NoSQL utilizan una variedad de técnicas para garantizar la redundancia y la distribución de los datos, lo que las hace muy resistentes a los fallos y asegura que los datos estén siempre disponibles cuando se necesiten.

Bases de datos distribuidas

Las bases de datos distribuidas son sistemas en los que los datos no están todos almacenados en un solo lugar, sino que están repartidos por varios servidores, a menudo en diferentes ubicaciones físicas. Este tipo de bases de datos son comunes en las bases de datos NoSQL.

La distribución de los datos tiene varias ventajas, como la escalabilidad (puedes añadir más servidores para manejar más datos) y la disponibilidad (si un servidor falla, los datos todavía están disponibles en otros servidores). Sin embargo, también presenta desafíos, como la necesidad de manejar la consistencia de los datos entre los servidores y la gestión de altas latencias cuando las ubicaciones de los servidores están muy separadas entre sí.

Tipos de bases de datos NoSQL

Existen varios tipos de bases de datos NoSQL, cada una con sus propias características y ventajas. Algunos de los tipos más comunes incluyen:

  • Bases de datos clave-valor: Estas bases de datos almacenan datos como un conjunto de pares clave-valor. Son altamente escalables y se utilizan en sistemas de almacenamiento en caché, sesiones de usuario y más.
  • Bases de datos de documentos: Estas bases de datos almacenan datos en documentos, normalmente en formato JSON. Son flexibles y se utilizan en aplicaciones de contenido, catálogos y más.
  • Bases de datos de columnas: Estas bases de datos organizan los datos por columnas en lugar de filas. Son eficientes y se utilizan en análisis de datos, sistemas de recomendación y más.
  • Bases de datos de grafos: Estas bases de datos utilizan estructuras de grafo para representar y almacenar datos. Son útiles para trabajar con datos interconectados, como redes sociales, sistemas de recomendación y más.

SQL-Like en bases de datos NoSQL

Aunque las bases de datos NoSQL se alejan del modelo relacional y del lenguaje SQL, algunas de ellas ofrecen interfaces de consulta que son similares a SQL, a menudo denominadas “SQL-Like”. Estas interfaces permiten a los desarrolladores que están familiarizados con SQL trabajar con bases de datos NoSQL con una curva de aprendizaje más suave.

Por ejemplo, Cassandra ofrece un lenguaje de consulta llamado CQL (Cassandra Query Language) que es muy similar a SQL. Permite a los usuarios realizar consultas de selección, inserción, actualización y eliminación de manera similar a como lo harían en una base de datos SQL.

MongoDB y otras soluciones NoSQL

MongoDB es una base de datos de documentos NoSQL muy popular. Almacena los datos en un formato similar a JSON llamado BSON, que permite una gran flexibilidad en la estructura de los datos. MongoDB es conocido por su escalabilidad horizontal y su rendimiento en aplicaciones con grandes volúmenes de datos.

Otra solución NoSQL popular es Redis, una base de datos en memoria que se utiliza principalmente como sistema de almacenamiento en caché. Redis almacena los datos en estructuras de datos simples como cadenas, listas, conjuntos, conjuntos ordenados con consultas de rango, mapas, HyperLogLogs, índices de bits y flujos.

Conclusión

Las bases de datos NoSQL ofrecen una serie de ventajas sobre las bases de datos SQL tradicionales, incluyendo flexibilidad, escalabilidad y alta disponibilidad. Aunque no son la solución adecuada para todas las situaciones, en los casos correctos pueden proporcionar un rendimiento y una eficiencia significativamente mejores. Como siempre, la elección de la tecnología adecuada depende de las necesidades específicas de su aplicación y su equipo.

En resumen, las bases de datos NoSQL ofrecen soluciones poderosas para manejar los desafíos de los grandes volúmenes de datos y las altas tasas de lectura y escritura. Aunque no son adecuadas para todas las situaciones, pueden ser una excelente opción para ciertas aplicaciones. Como siempre, la elección de la tecnología adecuada depende de las necesidades específicas de nuestra aplicación y el equipo de trabajo.

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

¿Por qué NO debes USAR NoLOCK en tus consultas SQL?

En ocasiones podemos pensar en un nivel de aislamiento read uncommitted o en el uso de la clausula NoLOCK como la solución a nuestros problemas de bloqueos. Si a ti también te ha pasado este video es para ti. Vamos a ver como su uso tiene muchos riegos y hay resultados inesperados que, para mi, hacen que no sea la mejor de la soluciones.

Espero que te haya gustado esta demostración rápida de los problemas a los que nos podemos enfrentar por usar NoLOCK. Ahora que ya conoces los riegos te recomiendo valorar una solución como Read Committed Snapshot para tus transacciones. Si quieres saber más de niveles de aislamiento te recomiendo nuestros post sobre niveles de aislamiento, niveles de aislaminto – casos prácticos y el uso de nolock.

Banner-Telegram

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

Estimación de Cardinalidad en SQL Server

Como DBAs siempre nos encontramos en una constante búsqueda de optimización y mejora del rendimiento de nuestras bases de datos. Esto, antes o después nos lleva a encontrarnos con  un concepto fundamental pero que puede resultar complicado al principio: la estimación de cardinalidad. Este concepto, aunque pueda parecer magia interna de SQL Server, es esencial para entender cómo el motor de base de datos de SQL Server decide el mejor plan de ejecución para ejecutar nuestras consultas. Es decir, es la clave para elegir el camino más óptimo para resolver lo que le hemos pedido.

Estimación de Cardinalidad

Como hemos adelantado ya en la introducción ,la estimación de cardinalidad es el proceso mediante el cual SQL Server trata de predecir el número de filas a las que va a afectar una consulta. No sólo calcula el número total de filas afectadas sino que lo hace con una granularidad total, calculando cuántas filas pasarán por todos y cada uno de los distintos componentes de los planes de ejecución posibles para resolver la consulta. Este número, también conocido como cardinalidad, es crucial para el optimizador de consultas, ya que sin esta información el motor de base de datos no podría elegir el plan de ejecución más eficiente. SQL Server utiliza estadísticas para realizar estas estimaciones de cardinalidad. 

Estadísticas en SQL Server: La base de la cardinalidad

Como acabamos de ver, el optimizador de consultas utiliza las estadísticas para estimar la cardinalidad. Por ejemplo, si estamos buscando registros de en una tabla donde la columna ‘edad’ es mayor que 30, SQL Server utilizará las estadísticas para estimar cuántos registros cumplen con este criterio. Pero, ¿cómo funciona exactamente?

Las estadísticas en SQL Server son objetos que almacenan información sobre la distribución de los valores en una o más columnas de una tabla o vista indexada. Cada objeto de estadísticas está compuesto por un histograma que describe la distribución de los valores, y un vector de densidad que contiene información sobre la correlación de los valores en las columnas.

SQL Server crea y actualiza automáticamente las estadísticas para las columnas indexadas en nuestras tablas y vistas. También podemos crear estadísticas para columnas no indexadas utilizando el comando CREATE STATISTICS, o podemos actualizar las estadísticas existentes utilizando el comando UPDATE STATISTICS.

Es importante tener en cuenta que las estadísticas pueden volverse obsoletas a medida que los datos en nuestras tablas cambian. Cuando esto sucede, las estimaciones de cardinalidad basadas en estas estadísticas pueden ser inexactas.  Esto puede llevar a SQL Server a elegir un plan de ejecución subóptimo, lo que puede resultar en un rendimiento deficiente de la consulta. Otro de los problemas comunes, aunque el plan de ejecución sea el correcto es una asignación de recursos no óptima para la resolución de las consultas lo que puede llevarnos a una profunda degradación de rendimiento.

Planes de Ejecución: El resultado de la estimación de cardinalidad

Un plan de ejecución es, en resumen, una serie de pasos que SQL Server sigue para ejecutar una consulta. Cada paso en el plan de ejecución tiene su propio componente que representa una operación atómica, como un escaneo de tabla, un join, o una operación de ordenación.

El optimizador de consultas de SQL Server utiliza las estadísticas para estimar la cardinalidad y elige el plan de ejecución que tiene el menor costo estimado. El costo de un plan de ejecución se mide en términos de la cantidad de recursos que se espera que consuma, como la CPU, la E/S de disco, y la memoria RAM.

Podemos ver el plan de ejecución de una consulta utilizando la opción SET SHOWPLAN_ALL ON. Esto nos proporcionará una representación gráfica del plan de ejecución, junto con información detallada sobre cada operación en el plan.

No vamos a profundizar mucho más en este sentido pues ya le hemos dedicado a este tema este artículo completo en este blog.

Conclusión

La estimación de cardinalidad es un aspecto esencial en la optimización de consultas en SQL Server. Aunque puede parecer un concepto complejo, entender cómo funciona puede ayudarnos a mejorar significativamente el rendimiento de nuestras bases de datos.

Es importante recordar que las estadísticas, que son la base de la estimación de cardinalidad, deben mantenerse actualizadas para garantizar estimaciones precisas. Como siempre, la clave está en conocer nuestras bases de datos, entender cómo se utilizan y aplicar este conocimiento para optimizar su rendimiento.

En resumen, la estimación de cardinalidad es una herramienta poderosa en nuestras manos. Con un buen entendimiento de cómo funciona, podemos hacer que nuestras bases de datos trabajen de manera más eficiente y efectiva. ¡Sigamos aprendiendo y mejorando juntos!

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