02.06.2021
Tiempo de lectura estimado: 10 minutos
Cuando asociado a una base de datos relacional el database administrator, más conocido como DBA, menciona el tema estadísticas -correr estadísticas, actualizar estadísticas- en general se generan dudas o malentendidos.
Para partir desde un mismo nivel, de forma muy simple, podemos definir qué entendemos por el mantenimiento de las estadísticas para la base de datos. La actualización de estas, ya sea de forma manual o automática, consiste en un proceso que recopila información con respecto a los datos -organizados en tablas y estas en registros-. Dichas estadísticas tienen relación, por ejemplo, con la cantidad de registros que cada tabla tiene, con la cantidad de valores diferentes de cada columna, valores máximos y mínimos de cada columna, etcétera.
¿Por qué mantenemos esa información?
Las sentencias SQL que llegan al motor de base de datos deben ser resueltas y es un componente llamado optimizador el que debe seleccionar el mejor camino posible para resolver esa consulta. Hablando claro, si una consulta a la base de datos busca a una persona por su número de pasaporte y existe un índice sobre la tabla –por ejemplo la tabla personas con millones de registros y con índice por número de pasaporte –, probablemente el mejor camino sea tomar ese índice definido.
Ahora bien, en términos teóricos, si esa tabla no tiene estadísticas actualizadas, es decir que las estadísticas no reflejan de forma aproximada la realidad –nunca fueron recolectadas o cuenta con un valor que esta muy lejos de la situación actual– el motor de base de datos u optimizador puede pensar que la tabla personas tiene pocos registros y no vale la pena utilizar un índice. La decisión del optimizador será entonces recorrer la tabla preguntando registro por registro si el número de pasaporte es el solicitado. Por lo tanto, el resultado es un desastre. El optimizador se equivoca en seleccionar el mejor camino para responder la consulta y la aplicación -asumamos de atención al público para darle más dramatismo- tiene tiempos muy malos.
Por otra parte, si nuestro negocio está funcionando perfectamente con las estadísticas de base de datos actuales, y por esto entendemos que todas las sentencias SQL se resuelven en tiempos óptimos y las aplicaciones están funcionando correctamente -entiéndase volver a actualizarlas por correr un proceso que las modifique, basado en la realidad o nueva realidad, y que una sentencia SQL que se resolvía óptimamente pase a resolverse de una forma que genere demoras en nuestra aplicación-; algunos lo llamarían comprarse un problema, ¿verdad?
¡Y qué difícil nos resulta defender la postura de hacer algo distinto a lo ya escrito en el manual de buenas prácticas o a lo que el soporte oficial de cualquier proveedor de software obliga a ejecutar cuando se presenta un problema! El DBA vive con una expresión futbolera -y el fútbol mucho tiene que ver con el título de este artículo- que dice “equipo que gana no se toca…”. Es decir, no actualizo las estadísticas si todo esta funcionando perfectamente.
Sin embargo, existen situaciones en las que algunos motores de base de datos permiten modificar las estadísticas manualmente: aumentar la cantidad de registros o columnas que declara tener la tabla, modificar valores máximos y mínimos o cantidad de valores diferentes que las estadísticas indican, etc. Básicamente se trata de mejorar la performance de una sentencia SQL que por los caminos normales no puede ser optimizada. De forma coloquial le llamamos “mentir las estadísticas” y puede lograr que “motivemos” al optimizador a considerar ese índice como la solución a nuestros problemas.
Pensemos como ejemplo en una tabla de millones de registros que tiene el campo llamado estado, el cual determina si el registro debe ser procesado o no. Los valores 0 de la columna estado indican que el registro debe ser procesado mientras que el valor 1 para la columna estado indica que el registro ya fue procesado anteriormente. En condiciones normales el valor 0 son pocos registros y el valor 1 más del 99% de los registros de la tabla.
Al ejecutar una consulta sobre la tabla intentando identificar los registros en estado con valor 0, el optimizador preguntará si hay índice para la columna estado, lo que es positivo, pero luego preguntará la cantidad de registros de la tabla -millones-. Dicho de otra forma, cuestionará la cantidad de valores diferentes del índice para saber qué tan selectivo es. El problema radica en que si una tabla de 10 millones de registros tiene un índice con 10 millones de valores diferentes se trata de un excelente índice, pero si tiene dos valores diferentes en realidad se trata de un mal índice -este es el caso, el campo estado tiene solo 0 y 1 como valores diferentes-. La selectividad aquí no es buena ni resulta útil porque la base puede pensar que, al tomar el índice, tendrá 5 millones de registros con un valor y 5 millones de registros con el otro.
El haber realizado un breve planteo de un ejemplo de lo que debe afrontar un DBA, al igual que lo complejo que es explicar el motivo por el cual en ocasiones no desea seguir una “buena práctica”, me permite a continuación comentar una situación vivida hace unos años, generada a partir del manejo de las estadísticas en la base de datos:
Trabajando de forma presencial en las oficinas de un cliente, mientras en ese momento transcurría la auditoría anual para la certificación ISO 27001 Seguridad de la Información -el estrés general se percibía en el aire-, sonó mi interno. Cuando atendí el teléfono me invitaron a contestar unas preguntas puntuales en la sala de reuniones, donde yo sabía que se encontraba el gerente de IT en conjunto con el resto de los gerentes, jefes de sección y auditor.
Lo primero que pensé no fue peinarme -por obvias razones- pero sí parecer más profesional, lo que me llevó a abandonar mi Coca Light, la cual me acompaña durante todo el día en el escritorio, y tomar mi agenda y una lapicera que no fuese la que muerdo habitualmente. Cuando entré en la sala de reuniones, luego de los saludos de rigor, observé que la pantalla mostraba una de las presentaciones que suelo enviarle al gerente de IT como resumen mensual y en la que se mencionaban las tareas desarrolladas por el DBA -o por Know-How en definitiva-.
El auditor me pidió que le explicara el significado de la frase, y cito textual, “mentir las estadísticas para que los reportes contables de la empresa funcionen bien”; agregando que nadie había podido explicar de qué se trataba dicha tarea y que incluso se encontraban sorprendidos de las implicancias que esta podría llegar a tener en el negocio -creo que el gerente financiero ya estaba pensando en que estábamos cooperando en la evasión de impuestos-. Mi primera reacción fue reírme, no sé si por los nervios acumulados o porque era una pregunta de examen que había estudiado, y luego procedí a exponer en un pizarrón el verdadero significado de la frase, explicación muy similar a lo relatado al inicio de este artículo respecto al motivo por el cual en ocasiones el DBA no desea seguir una “buena práctica”.
Mi salida de la sala fue elegante. No voy a exagerar, nadie aplaudió, pero nuestro contrato con la empresa se mantiene hasta el día de hoy.
La lección aprendida: nunca decir o dejar por escrito “mentir estadísticas”. Las estadísticas no se manchan.
Autor: Leonardo Mardero, Director de Know-How y DBA Sr.
