Mes: enero 2025

15
Ene
2025

Compresión en Azure SQL Managed Instance

Azure SQL Managed Instance (MI) es una plataforma para la gestión de bases de datos en la nube con un equilibrio perfecto entre la administración manual y delegada en el proveedor, pero es esencial comprender sus características y limitaciones para optimizar su rendimiento. Hoy vamos a hablar de la compresión de datos, de la que ya hablamos detenidamente en otro artículo, como estrategia para mitigar limitaciones relacionadas con los recursos de IO, RAM y CPU. En este artículo, exploraremos cómo la compresión de datos puede ayudar a superar estas limitaciones, proporcionando datos objetivos sobre las especificaciones de Azure MI y los precios (en la región de España Central a modo de ejemplo).

Características y limitaciones de Azure SQL Managed Instance

Lo primero que tenemos que tener claro es el terreno de juego en el que estamos, la nube es teóricamente escalable sin límite, sin embargo, tanto los proveedores como, sobre todo, nuestro bolsillo va a ser el principal limitante. Veamos qué es lo que nos ofrece Azure para el caso de las Managed Instance.

Niveles de servicio y recursos asignados:

Azure MI ofrece principalmente dos niveles de servicio el de uso general y el crítico. Además, dentro de estos niveles de servicio vamos a poder elegir tres tipos de hardware diferente. Parece un poco lioso, y realmente lo es, así que vamos a tratar de hacerlo fácil.

Lo primero que tenemos que conocer son los niveles de servicio que son:

  • De uso general (General Purpose): Diseñado para cargas de trabajo empresariales comunes con requisitos de rendimiento moderados y alta disponibilidad.
  • Crítico para la empresa (Business Critical): Orientado a aplicaciones de misión crítica que requieren alta velocidad de transacciones y baja latencia.

Estos niveles de servicio van a marcar los límites de recursos que podemos asignar a nuestra instancia, pero además de estos tenemos que tener en cuenta el tipo de hardware. Por ejemplo en el nivel de uso general el límite de CPUs que podemos asignar es de 80 cores para el hardware estándar y el serie premium pero solo hasta 64 cores en el hardware optimizado para memoria. Es el nivel crítico para la empresa el hardware estándar tendrá un máximo de 80 cores mientras que el hardware premium y el optimizado para memoria podrá tener hasta 128.

Compresión para salvar los límites de RAM para Azure MI

Una de las cosas curiosas de Azure SQL MI es que la asignación de recursos de memoria RAM no es seleccionable y depende directamente de la cantidad de núcleos virtuales que tengamos.

  • Hardware de la serie estándar: 5,1 GB de RAM por vCore con un máximo de 480 Gb. Por ejemplo, 16 vCore = 81,6 GB de RAM.
  • Hardware de la serie Premium: 7 GB de RAM por vCore con un máximo de 560 Gb. Por ejemplo, 16 vCore = 112 GB de RAM.
  • Hardware optimizado para memoria: 13,6 GB de RAM por vCore con un máximo de 870,4 Gb. Por ejemplo, 16 vCore=217 GB de RAM.

Como podéis ver, la cantidad máxima de RAM es muy limitada y más cuando no nos dejamos el presupuesto de toda la empresa en núcleos de Azure MI. Por esta razón es fundamental habilitar la compresión en todas las tablas e índices de nuestras bases de datos. Cuantos más datos podamos cachear mejor, recordad que para que SQL tenga un rendimiento decente tiene que ser capaz de tener en memoria la información a la que se accede frecuentemente además de espacio suficiente para cachear planes de ejecución y demás operaciones que se hacen en memoria.

Almacenamiento en Azure MI

Ahora vamos con una de las cosas que menos me gustan de este modelo de dimensionamiento que tiene Azure MI y es que la capacidad de almacenamiento está limitada por la cantidad de núcleos adquirida. De esta manera, en el nivel de uso general con menos de 8 núcleos no puedes tener más de 2 Tb de datos, con menos de 16 núcleos no puedes tener más de 8 Tb de datos y para llegar hasta el máximo de 16 Tb de datos vas a necesitar 16 núcleos o más. Veamos esto en precios con el hardware estándar para que nos duela menos al ver los costes.

Propósito general:

  • ¿Necesitas menos de 2 TB? Puedes dimensionar 4 núcleos, 1.013,99 € mensuales.
  • ¿Necesitas más de 2 TB? Necesitas mínimo de 8 núcleos, 2.569,88 € mensuales.
  • ¿Necesitas más de 8 TB? Necesitas mínimo de 16 núcleos, 5.143,85 € mensuales.
  • ¿Necesitas más de 16 TB? Lo siento, no puedes tener esa cantidad. (Puedes tener más núcleos pagando más, pero esta lista se basa en los tamaños de disco).

Veamos también cómo va el almacenamiento en el nivel crítico para la empresa (esta vez en hardware premium que es más flexible):

  • ¿Necesitas menos de 1 TB? Puedes dimensionar 4 núcleos virtuales, 2.614,23 € mensuales.
  • ¿Necesitas más de 1 TB? Mínimo de 8 núcleos, 5.237,48 € mensuales.
  • ¿Necesitas más de 2 TB? Mínimo de 16 núcleos, 10.483,97 € mensuales.
  • ¿Necesitas más de 4 TB? Mínimo de 24 núcleos, 15.584,32 € mensuales.
  • ¿Necesitas más de 5,5 TB? En España no se puede.

Os dejo ahora una imagen extraída de la documentación oficial sobre las limitaciones de espacio. Para el cálculo de precios podéis usar la calculadora oficial.

Compresión Limites disco Azure MI

Velocidad de los discos

Si todo esto que hemos visto no es un problema para vosotros esperad porque ahora viene lo realmente “problemático” en Azure MI. La velocidad de estos discos, medida en IOPS (E/S por segundo), es realmente baja y, aunque va aumentando con el tamaño de los archivos, no llega a ser comparable a sistemas tradicionales On-Prem. Además de que escalar los ficheros nos va a implicar necesidades extra de tamaño y por tanto de cores y, si lo habéis adivinado, de más dinero todos los meses. Veamos esta otra imagen de la misma documentación que comentábamos antes: 

Compresión velocidades disco Azure

Ahora os voy a dejar otra imagen de Kingston sobre las velocidades de sus discos actuales

Compresión Velocidad Kingston

Como veis, en el mejor de los casos, un archivo de Azure MI de más de 4 Tb tendría una velocidad de 250 Mib/s (Mebibits por segundo) o lo que es lo mismo 32,7 MB/s (Megabytes por segundo). Un SSD M2 NVME actual de cuatro canales nos está dando 8000. 

Recuerda que para tener 4Tb (32,7 MB/s) en una instancia de nivel crítico para la empresa estamos hablando de más de 15.000 € al mes, eso sin contar con dimensionar también el fichero de log que, en este nivel de servicio y en España, ni podríamos llevarlo a este tamaño. En el nivel propósito general si podemos pero, estamos hablando de 5.100 € al mes para tener 8 Tb (4 para datos y 4 para log). 

Nada más que decir.

Conclusión: Compresión para reducir las lecturas

Lo que os quería hacer ver con todo este texto que os he puesto hasta ahora es que en Azure MI las reglas del juego cambian y reducir las lecturas en disco y maximizar el tiempo que los datos permanecen en caché es clave para el rendimiento. Por este motivo necesitarás una buena política de indexación, comprimir los datos y, si es posible, eliminar todos los datos que ya no sean necesarios. 

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
13
Ene
2025

Compresión en SQL Server

La compresión de datos en SQL Server es una funcionalidad clave que permite optimizar el almacenamiento y mejorar el rendimiento de entrada/salida (E/S) en bases de datos con grandes volúmenes de información. SQL Server ofrece dos tipos principales de compresión: a nivel de fila y a nivel de página. En este artículo veremos ambos métodos así como sus ventajas y casos de uso, y mostraremos cómo evaluar el impacto de estas técnicas en el almacenamiento mediante herramientas nativas de SQL Server.

Compresión de fila

La compresión de fila elimina redundancias en datos almacenados en columnas de tipos de datos de longitud fija, como CHAR e INT. Además, optimiza el almacenamiento de valores NULL y ceros.

Características principales:

Como no podía ser de otra manera, la principal característica de este tipo de compresión es la optimización ligera de espacio. Con esto quiero decir que reduce el tamaño al eliminar espacios en blanco innecesarios y valores repetitivos pero sin mucho impacto en el sistema. No es una compresión muy intrusiva, lo que nos lleva a su segunda característica principal, la compatibilidad. La compresión a nivel de fila es transparente para las operaciones de lectura y escritura, ya que no requiere descompresión y tiene un impacto bajo en la CPU (tercera característica). Esto la hace una solución ideal para sistemas con limitaciones de procesamiento.

Casos de uso:

Como ya hemos dicho esta solución es la más recomendada en tablas con numerosos valores NULL o ceros o tablas con columnas de tipos de datos de longitud fija donde tengamos limitaciones o estemos cerca del límite de la CPU. Si no tenemos problemas de CPU podremos optar por el siguiente tipo de compresión como vamos a ver ahora mismo.

Compresión de página

La compresión de página es la más completa, combina la compresión de fila con técnicas de codificación más avanzadas, como el uso de diccionarios para reducir patrones repetitivos dentro de las páginas de datos. Es decir, además de toda la compresión que ya teníamos a nivel de fila elimina los datos duplicados en disco para reducir así el espacio. Es como una “deduplicación” de los datos de la tabla, así entre comillas pero para entendernos.

Características principales:

Lo estarás ya imaginando, la principal característica de la compresión a nivel de página es la reducción significativa del espacio. Es ideal para tablas con datos repetitivos o históricos. Por contra tiene un mayor uso de CPU ya que requiere más procesamiento, especialmente durante la compresión inicial. Hay que poner en una balanza este coste extra de CPU al comprimir con la eficiencia en almacenamiento. En teoría reduce los costes al minimizar el espacio físico necesario pero carga la CPU. 

Ahora bien, si no tenemos tantas escrituras y nuestro consumo de CPU es mayoritariamente en lecturas podemos llevarnos una sorpresa. Comprimir los datos hace que podamos almacenar más datos en RAM, incluso en la caché del procesador y puede darse el caso que lo que notemos sea justo lo contrario, una reducción del uso de la CPU. Si lo piensas no es tan descabellado, es la manera de trabajar de los índices.

Casos de uso:

En este caso, los casos de uso son un poco más específicos que en el anterior tipo. Usaremos la compresión a nivel de página en tablas de archivos históricos y tablas de solo lectura. También nos lo podemos plantear en bases de datos con grandes tablas con volúmenes de datos repetitivos siempre y cuando el consumo de CPU no sea un problema para nosotros. Por último, en servidores donde el principal cuello de botella sea la E/S de disco (ejem, Azure, ejem) el beneficio también será sustancial.

Evaluación del impacto en el almacenamiento

Antes de implementar la compresión, es fundamental evaluar el impacto potencial en el almacenamiento para entender los beneficios que puede ofrecer. SQL Server proporciona el procedimiento almacenado de sistema sp_estimate_data_compression_savings, que permite estimar el ahorro de espacio para diferentes tipos de compresión.

Sintaxis del procedimiento:

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'NombreEsquema',
    @object_name = 'NombreTabla',
    @index_id = 0, -- 0 para todos los índices
    @partition_number = NULL, -- NULL para todas las particiones
    @data_compression = 'PAGE'; -- Alternativas: ROW, NONE

Ejemplo práctico:

Supongamos que tenemos una tabla Ventas en el esquema dbo y queremos evaluar el impacto de habilitar compresión de página:

EXEC sp_estimate_data_compression_savings 
    @schema_name = 'dbo',
    @object_name = 'Ventas',
    @index_id = 1, -- Índice específico
    @partition_number = NULL, -- Todas las particiones
    @data_compression = 'PAGE';

Resultado:

El procedimiento devuelve una estimación del espacio actual y el espacio proyectado después de aplicar la compresión. Esto incluye:

  • size_with_current_compression_setting: Tamaño actual.
  • size_with_requested_compression_setting: Tamaño estimado con la compresión solicitada.
  • savings_in_bytes: Ahorro en bytes.

Implementación de la compresión

Una vez evaluado el impacto, podemos habilitar la compresión mediante las siguientes instrucciones:

-- Compresión de fila
ALTER TABLE dbo.Ventas
REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = ROW);
-- Compresión de página
ALTER TABLE dbo.Ventas
REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = PAGE);
-- Deshabilitar la compresión
ALTER TABLE dbo.Ventas
REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = NONE);

Beneficios adicionales de la compresión

En líneas generales, sea cual sea el tipo de compresión que utilicemos, hay una serie de ventajas que son comunes. El principal beneficio que podemos destacar es la reducción de espacio físico en disco o en almacenamiento en la nube lo que implica directamente una reducción de costes. Por otro lado, vamos a encontrarnos con mejoras en E/S lo que se traduce en operaciones más rápidas al transferir menos datos. 

Por último, debemos hablar de la compatibilidad. La compresión no es solo a nivel tabla, también se aplica a índices, optimizando consultas.

Conclusión

La compresión en SQL Server es una herramienta poderosa para reducir costes y mejorar el rendimiento de bases de datos. Evaluar previamente el impacto con sp_estimate_data_compression_savings asegura que tomemos decisiones informadas, maximizando los beneficios en almacenamiento y rendimiento. Ya sea con compresión de fila o de página, estas técnicas pueden adaptarse a una amplia gama de necesidades y escenarios empresariales.

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
10
Ene
2025

¿Por qué usar una red aislada para la comunicación de Always On (heartbeat network)?

La implementación de una arquitectura de alta disponibilidad en SQL Server Always On es un elemento clave para garantizar la continuidad del negocio y la disponibilidad de los datos. Mucho hemos hablado ya de este tema en el blog pero, si queremos ir un paso más allá, uno de los aspectos fundamentales en esta configuración es la red de comunicación entre los nodos de un grupo de disponibilidad o una instancia de clúster de conmutación por error. En este contexto, el uso de una red aislada para la comunicación de Always On, conocida como heartbeat network, juega un papel esencial en la estabilidad y rendimiento de la solución.

En este artículo, veremos por qué es recomendable utilizar una red dedicada para la comunicación de Always On, sus beneficios, y las mejores prácticas para su implementación.

Importancia de la comunicación en Always On

Always On en SQL Server nos permite la creación de entornos de alta disponibilidad y recuperación ante desastres mediante grupos de disponibilidad o clústeres de conmutación por error. Cuando lo configuramos, los nodos intercambian información de estado para determinar si uno de los servidores está en funcionamiento o si ha fallado y es necesario realizar una conmutación por error (failover).

Este intercambio de información se realiza a través de un mecanismo denominado heartbeat, que envía señales de estado periódicas entre los nodos del clúster. Si un nodo deja de responder en un tiempo determinado, el sistema automáticamente asume que ha fallado y puede desencadenar una conmutación automática al nodo secundario si así lo hemos configurado.

Además de la señal de heartbeat, en un Grupo de Disponibilidad Always On, esta misma red puede utilizarse para la sincronización de datos entre réplicas. Esto es especialmente crítico en entornos con replicación síncrona, donde la latencia y la estabilidad de la red influyen directamente en el rendimiento del sistema.

¿Por qué usar una red aislada para el heartbeat en Always On?

Como acabamos de ver, el tráfico de comunicación de Always On es crítico para mantener la estabilidad del clúster. Sin una red dedicada, esta comunicación puede verse afectada por la congestión de la red principal, lo que podría provocar falsos positivos en la detección de fallos y generar conmutaciones innecesarias. Además el rendimiento de SQL podría verse afectado sobre todo en replicaciones síncronas donde todos los nodos tienen que confirmar la escritura del dato antes de aplicarse. A continuación, analizamos las razones principales por las que una red aislada es recomendada.

1. Optimización del rendimiento en la replicación de datos

En configuraciones de Grupos de Disponibilidad Always On, los datos pueden replicarse de forma síncrona o asíncrona entre los nodos.En la replicación asíncrona, el rendimiento no se ve tan afectado por la latencia de la red, ya que el nodo primario no espera confirmación antes de continuar procesando transacciones. Sin embargo, en la replicación síncrona, cada transacción debe confirmarse en todas las réplicas antes de considerarse completada. Si la red es lenta o está congestionada, la latencia de confirmación aumentará, ralentizando drásticamente el rendimiento de las aplicaciones que dependen de la base de datos.

Utilizar una red dedicada para la sincronización de Always On reduce la latencia y garantiza tiempos de respuesta óptimos, evitando que la red de producción interfiera en la replicación de datos.

2. Evita congestión en la red de producción

Si la red de Always On comparte infraestructura con la red utilizada por los clientes y aplicaciones, el tráfico de consultas, backups y cargas de datos puede afectar negativamente la comunicación entre los nodos. Una red separada para heartbeat y sincronización de datos garantiza que las señales críticas del clúster no se pierdan ni se retrasen debido a otras cargas de trabajo.

3. Reduce los falsos positivos en la detección de fallos

Si los paquetes de heartbeat se retrasan o se pierden por congestión en la red, el clúster podría interpretar que un nodo ha fallado y desencadenar una conmutación innecesaria. Esto no solo interrumpe el servicio, sino que también puede generar pérdida de rendimiento o afectar transacciones en curso. Con una red dedicada, el tráfico de heartbeat permanece estable, minimizando estos riesgos.

4. Mayor estabilidad en entornos de “misión crítica”

En sectores críticos como finanzas, salud o comercio electrónico, donde SQL Server gestiona transacciones en tiempo real, cualquier interrupción puede tener un impacto severo. Una red dedicada para la sincronización y el heartbeat de Always On ayuda a mantener la estabilidad operativa, asegurando que la replicación de datos no se vea afectada por otros procesos.

5. Mejor eficiencia en la recuperación ante desastres

En escenarios donde Always On se extiende a un sitio de recuperación ante desastres (DR), la replicación de datos entre ubicaciones puede beneficiarse de una red dedicada para evitar problemas de latencia y pérdida de paquetes. Al separar el tráfico de sincronización, se mejora la eficiencia de la conmutación a los servidores de respaldo, reduciendo el tiempo de recuperación en caso de fallos.

6. Mayor seguridad en la comunicación entre nodos

Al utilizar una red aislada, los paquetes de comunicación de Always On quedan protegidos de posibles ataques de red o interferencias de otras aplicaciones. Esto es especialmente importante en entornos donde se manejan datos sensibles o regulados. 

Buenas prácticas para implementar una red de heartbeat en Always On

Para aprovechar al máximo los beneficios de una red dedicada en Always On, es recomendable seguir algunas buenas prácticas:

Utilizar interfaces de red dedicadas para la red heartbeat 

Cada nodo del clúster debe contar con al menos dos interfaces de red, una para la red de producción y otra exclusivamente para la comunicación de Always On (heartbeat + sincronización de datos). Esto permite segmentar el tráfico y garantizar que los paquetes críticos siempre tengan prioridad.

Configurar métricas de latencia adecuadas

Ajustar los valores de timeout y umbrales de latencia en el clúster es clave para evitar falsos positivos en la detección de fallos. Dependiendo de la infraestructura, puede ser necesario aumentar los valores predeterminados para optimizar la replicación.

Implementar calidad de servicio (QoS)

Si la red dedicada no es una opción viable, se pueden aplicar reglas de Quality of Service (QoS) para priorizar el tráfico de Always On sobre otros tipos de tráfico en la red de producción.

Monitorizar constantemente la red heartbeat de Always On

La monitorización activa de la red de comunicación y replicación de Always On es crucial para detectar anomalías antes de que afecten la estabilidad del clúster. Herramientas como SQL Server Management Studio (SSMS) y System Center Operations Manager (SCOM) pueden ayudar en esta tarea.

Usar VLANs y segmentación de red para heartbeat 

Si no es posible contar con una red física dedicada, una alternativa viable es configurar una VLAN (Virtual LAN) para separar lógicamente el tráfico de Always On del resto del tráfico de la red.

Configurar múltiples rutas de comunicación

Para entornos de alta disponibilidad extrema, es recomendable configurar múltiples rutas de comunicación entre los nodos utilizando distintas interfaces de red y switches redundantes. Esto permite continuar la comunicación en caso de fallos en una de las rutas.

Conclusión

El uso de una red aislada para la comunicación de Always On no solo garantiza una mayor estabilidad en la detección de fallos, sino que también optimiza el rendimiento en la replicación de datos, especialmente en configuraciones síncronas. Al reducir la latencia y evitar interferencias con el tráfico de producción, se mejora significativamente la eficiencia del clúster y se minimiza el riesgo de interrupciones.

Para cualquier organización que dependa de SQL Server Always On, implementar una red dedicada para heartbeat y sincronización es una estrategia clave para mantener un rendimiento óptimo y asegurar la continuidad del servicio en entornos críticos.

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, Rendimiento, SQL Server, 0 comentarios
08
Ene
2025

¿Hasta qué punto ayuda el conocimiento del negocio a un DBA?

El papel del administrador de bases de datos (DBA) ha evolucionado considerablemente con el tiempo. Si bien sus responsabilidades fundamentales siguen siendo la administración de sistemas, optimización del rendimiento y mantenimiento de la disponibilidad, el contexto en el que operan los datos ha adquirido una relevancia creciente. El conocimiento del negocio no solo potencia la eficiencia de un DBA, sino que también le permite aportar soluciones alineadas con los objetivos estratégicos de la organización.

Diseño y modelado de bases de datos con propósito de negocio

El diseño de bases de datos es una de las áreas donde más se nota la diferencia entre un DBA con conocimientos técnicos y otro que, además, entiende el negocio. Cuando un administrador comprende los procesos empresariales, como la estructura de ventas, el control de inventario o los flujos de producción, el modelado de datos se vuelve más coherente y efectivo. Este conocimiento permite crear esquemas que reflejan la operativa real, optimizando no sólo la integridad de los datos, sino también la capacidad del sistema para dar respuesta a las necesidades de la organización.

Por ejemplo, en un escenario donde los reportes financieros son fundamentales para la toma de decisiones, un DBA con visión de negocio podrá anticipar qué tablas y consultas son críticas. Esto le permitirá definir índices, particiones y optimizaciones específicas para esas áreas, asegurando que los procesos clave se ejecuten con rapidez. Por el contrario, un diseño basado exclusivamente en criterios técnicos puede generar soluciones rígidas que dificultan la adaptación a los cambios en los requisitos del negocio.

Todo esto es importante aunque el DBA no sea quien define y modela ya que, aun en estos casos, su supervisión es crítica. Además esta visión global le facilitará anticiparse a problemas causados por un fallo en este sentido.

Optimización de rendimiento alineada con el negocio

El conocimiento del negocio también desempeña un papel clave en la optimización del rendimiento. Aunque las métricas técnicas son esenciales para medir la eficiencia de una base de datos, estas carecen de sentido si no están alineadas con las prioridades de la empresa. Cuando los DBA entendemos el impacto real de un proceso podemos enfocarnos en optimizar las consultas o tareas que realmente afectan al negocio.

Cuando una consulta tarda demasiado en ejecutarse, es fundamental comprender cómo se utilizan esos datos. Si el rendimiento afecta directamente a la generación de reportes de ventas o análisis de inventario, nuestras acciones como DBA deberán enfocarse en resolver ese problema con la mayor prioridad. Al conocer la operativa, podemos tomar decisiones más acertadas, como proponer estrategias de ColumnStore, particionado o ajustes de índices específicos, sabiendo que estas optimizaciones repercutirán directamente en la eficiencia operativa de la organización.

Por último también podremos anticiparnos y preparar el servidor para momentos de especial carga de trabajo como periodos de ofertas en tiendas, cierres fiscales en sistemas contables o cualquier eventualidad propia de nuestra empresa.

Resolución de incidencias y priorización de tareas acorde a las necesidades de negocio

La resolución de incidencias es otra área donde el conocimiento del negocio puede marcar una gran diferencia. Un DBA experimentado sabe que no todas las consultas o procesos tienen el mismo impacto. La comprensión de los procesos críticos, como el cierre contable mensual o los análisis de producción, nos permite a los administradores priorizar las tareas según su urgencia y relevancia para el negocio.

Por ejemplo, durante un cierre financiero, un problema en las consultas que alimentan los reportes puede paralizar decisiones clave de la alta dirección. Un DBA que entiende la importancia de estos procesos actuará con celeridad, enfocando sus esfuerzos en identificar y resolver la causa raíz del problema. Esta capacidad para priorizar no solo mejora la eficiencia del administrador, sino que también garantiza que el negocio continúe funcionando sin interrupciones.

Migraciones y rediseños orientados a las necesidades de negocio

En proyectos de migración o rediseño de bases de datos, el conocimiento del negocio es aún más relevante. Estos procesos suelen implicar cambios estructurales y la adopción de nuevas tecnologías, lo que requiere una planificación detallada y un entendimiento claro de las necesidades empresariales. Un DBA que domina el contexto del negocio será capaz de proponer soluciones que no solo mejoren el rendimiento técnico, sino que también aporten valor a la organización. Por no hablar de que sin conocimiento de lo que pasa en el negocio solo vamos a poder cubrir las necesidades actuales que vemos sin ser capaces de prever lo que pasará en un futuro cercano. ¿Cómo vamos a poder dimensionar así correctamente un servidor nuevo?

Durante una migración de SQL Server 2019 a 2022, por ejemplo, los administradores con esta perspectiva no nos limitaremos a realizar una actualización técnica. Evaluaremos el modelo de datos, identificaremos oportunidades de optimización y propondremos mejoras que beneficien a los procesos críticos del negocio. Esto puede incluir desde la implementación de nuevas funcionalidades del motor a ajustes en el almacenamiento de datos o la adopción de estrategias más eficientes para la gestión de consultas complejas.

Colaboración entre equipos y comunicación efectiva

Como DBA el conocimiento del negocio también nos facilita la colaboración con otros equipos, como desarrolladores, analistas de negocio y administradores de sistemas. Al actuar como un puente entre el lenguaje técnico y las necesidades empresariales, el administrador de bases de datos puede contribuir a la creación de soluciones más efectivas y alineadas con los objetivos de la organización. Esta comunicación fluida permite anticipar problemas, evitar malentendidos y asegurar que los esfuerzos propios del DBA tengan un impacto positivo en el funcionamiento global del negocio.

Conclusión

El conocimiento del negocio es una herramienta imprescindible para un administrador de bases de datos que aspire a aportar valor más allá de sus competencias técnicas. Esta comprensión le permite diseñar bases de datos eficientes, optimizar procesos clave y resolver problemas con mayor rapidez y eficacia. Además, facilita la colaboración con otros equipos y asegura que las decisiones del DBA estén siempre alineadas con los objetivos estratégicos de la organización. Al entender el contexto empresarial, el administrador no solo gestiona datos, sino que se convierte en un aliado fundamental para el éxito y la competitividad del negocio.

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
03
Ene
2025

Un día en la vida de un DBA: Consultas, Caos y Dudosa Capacidad Técnica (Artículo de HUMOR)

Como DBA de SQL Server, mi día es una mezcla de comedia, drama y suspense, con algunos toques de terror. Aquí os presento cómo transcurrió un día cualquiera en mi vida, repleto de personajes inolvidables, cada uno con su consulta particular y su manera única de contribuir al colapso del servidor. Abrid vuestra mente… y vuestro SQL Server Management Studio.

8:00 AM: Paco “El SELECTor” y la Consulta Infinita

Nada más abrir mi sesión, mi querido compañero Paco, el SELECTor (porque selecciona todo sin filtro), aparece con su ya clásica sonrisa de inocencia. Paco es de los que todavía piensan que SQL Server es algo mágico y que “si no devuelves todas las columnas, seguro te dejas algo importante”.

Me encuentro con su obra maestra, digna de un Anti Premio a la peor consulta del año:

SELECT *
FROM Sales.SalesOrderDetail SOD
JOIN Production.Product P ON SOD.ProductID = P.ProductID
WHERE YEAR(SOD.ModifiedDate) = 2024;

-“¡No entiendo por qué tarda tanto! ¡Si son solo los pedidos del año!”, exclama Paco, mientras agita su taza de café de “No es magia, soy desarrollador”.

Le explico con calma (una vez más) que cada vez que usa SELECT * en producción muere un gatito y que filtrar con funciones como YEAR() no permite que SQL Server use los índices. Con cara de «eso me lo enseñaron en un curso de YouTube», Paco se compromete a mejorar. Mientras tanto, optimizo la consulta:

Optimización: índice + eliminación de funciones

CREATE INDEX IX_SalesOrderDetail_ModifiedDate 
ON Sales.SalesOrderDetail(ModifiedDate)
WITH (ONLINE=ON, FILLFACTOR=100);

SELECT SOD.SalesOrderID, P.Name, SOD.OrderQty
FROM Sales.SalesOrderDetail SOD
JOIN Production.Product P ON SOD.ProductID = P.ProductID
WHERE SOD.ModifiedDate >= '2024-01-01' AND SOD.ModifiedDate < '2025-01-01';

Resultado: Consulta en segundos. Paco asiente con admiración y anota algo en su libreta, probablemente «Pedir más memoria al DBA».

10:00 AM: Toñi “SinWHERE” y el Script Nuclear

Toñi es de esas desarrolladoras que tienen una relación tóxica con el entorno de producción. Tiene un lema: «Si funciona en mi local, funciona en producción». Y hoy, decidió demostrarlo.

Recibo una alerta: «La tabla Employee está vacía». Con el corazón encogido, abro los logs y ahí está el script más temido:

DELETE FROM HumanResources.Employee;

-“¡Uy! Me olvidé el WHERE. Pero no pasa nada, para eso están los backups, ¿no?”, dice Toñi con una sonrisa que desearía no ver nunca más.

Intento explicarle que “no pasa nada” es lo que dice un soldado cuando pisa una mina. Mientras recupero los datos, aplico medidas preventivas:

ALTER ROLE db_datawiter DROP MEMBER [Toñi.SinWHERE]

ATPC. No me fío ni un pelo.

1:00 PM: Manolo “El Shuffle” y el Caos Aleatorio

Manolo, alias “El Shuffle”, es el encargado de los informes y estadísticas. Es fan del “orden aleatorio” porque, según él, “las listas aburren a la gente”. Y claro, cuando quiere algo “aleatorio”, lanza lo siguiente:

SELECT TOP 10 PERCENT *
FROM Sales.Customer
ORDER BY NEWID();

-“Es que así queda guay, aleatorio, como mi lista de Spotify”, argumenta Manolo mientras hace girar su silla de oficina cual plato de mesa de mezclas de DJ.

Le explico (otra vez) que NEWID() obliga a SQL Server a generar GUIDs para todas las filas de la tabla y luego ordenarlos. Todas estas operaciones se hacen en memoria y con su maravillosa tabla de 200 millones de registros eso no es una buena idea. Así que le doy una alternativa más eficiente para obtener una muestra aleatoria:

SELECT *
FROM Sales.Customer
TABLESAMPLE (10 PERCENT);

¡Magia! “¿Ves? Es que tú lo complicas todo”, dice con su típica confianza de «yo lo leí en Stack Overflow».

4:00 PM: Javi “El SinÍndices” y la Carga Masiva

Cuando el servidor ya está medio recuperado, aparece Javi, “El SinÍndices”. Su teoría es que los índices ralentizan la carga de datos (y no le falta razón… a medias). Así que en su infinita sabiduría, ha borrado todos los índices de la tabla Invoices para cargar más rápido.

– “¡La carga ha ido como un rayo!”, dice orgulloso.

– “¿Y las consultas que dependen de esa tabla? ¿Les has preguntado cómo van?”, respondo yo con una mirada de fuego.

Para evitar futuros desastres, le tatuo en el antebrazo que si vuelve a borrar índices no respetaré los derechos humanos y recurriré a la tortura en nuestra próxima interacción.

6:00 PM: El Jefe “Sin Backup no Hay Paraíso”

Justo cuando creo que puedo irme, mi jefe aparece con cara de preocupación:

– “¿Tenemos backup de todo esto, verdad?”.

Le muestro mi carpeta de backups, replicados hasta en la luna si es necesario. Porque si algo tengo claro después de años de sufrimiento es que sin backup, no hay DBA que sobreviva.

Conclusión: La vida del DBA es un Reality Show

Un día más salvando a Paco, Toñi, Manolo y Javi de ellos mismos. Un día más optimizando consultas, corrigiendo scripts desastrosos y asegurando que el servidor no arda en llamas. La próxima vez que escuches «¿pero qué hace un DBA?», recuérdales que sin nosotros, el caos reinaría en el mundo de los datos.

Y si alguno de estos personajes te suena… ¡ánimo! Seguro que en tu día a día también te encuentras con alguno de ellos.

Espero que este artículo te haya resultado divertido y ameno. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Publicado por Roberto Carrancio en Otros, 1 comentario