Introducción
Una base de datos puede funcionar durante meses sin recibir apenas atención y, aun así, estar acumulando problemas lentamente: tablas que crecen más de lo previsto, índices que ya no responden al patrón real de consultas, tareas internas que dejaron de ejecutarse, registros temporales que nunca se eliminan, estadísticas desactualizadas, espacio libre cada vez menor o procedimientos que solo existen en la memoria de quien administra el sistema.
Una política de mantenimiento preventivo convierte estas revisiones en un proceso periódico, proporcionado y verificable antes de que aparezca una incidencia. Su objetivo no es intervenir continuamente ni ejecutar tareas de mantenimiento porque “siempre se ha hecho así”. Consiste en decidir qué merece comprobarse, con qué frecuencia, bajo qué condiciones debe actuarse y qué evidencia debe quedar después.
El mantenimiento preventivo tampoco sustituye a la monitorización, las copias de seguridad, las actualizaciones del motor o el diagnóstico de rendimiento. Son disciplinas relacionadas, pero distintas. La monitorización observa señales; el backup protege la capacidad de recuperación; las actualizaciones gestionan cambios de versión; el diagnóstico investiga problemas concretos. La política preventiva organiza una rutina que utiliza esas señales para evitar que pequeños deterioros se conviertan en problemas operativos.
Para una pequeña empresa o un entorno técnico con recursos limitados, esta distinción es especialmente importante. Una política demasiado ambiciosa genera tareas que nadie mantiene. Una política demasiado débil deja que la base envejezca sin control. El objetivo es encontrar un nivel sostenible: pocas revisiones bien elegidas, calendarios claros, criterios de actuación y un registro que permita saber qué se hizo y por qué.
Este artículo explica cómo construir esa política desde cero: clasificar bases por criticidad, definir frecuencias, establecer rutinas diarias, semanales, mensuales y trimestrales, revisar almacenamiento y crecimiento, controlar mantenimiento interno del motor, tratar tablas e índices, gestionar datos temporales e históricos, validar tareas programadas, preparar ventanas de intervención y revisar periódicamente si la política sigue siendo adecuada.
Índice
- Qué es una política de mantenimiento preventivo
- Qué debe conseguir
- Qué no debe intentar cubrir
- Empezar por un inventario fiable
- Clasificar bases de datos por criticidad
- Crear una línea base de funcionamiento
- Definir frecuencias de mantenimiento
- Rutina diaria
- Rutina semanal
- Rutina mensual
- Rutina trimestral o semestral
- Controlar almacenamiento y crecimiento
- Revisar tablas y estructuras que crecen
- Mantener índices con criterio
- Mantener estadísticas y metadatos del optimizador
- Diseñar tareas de housekeeping
- Gestionar datos históricos y retención
- Comprobar integridad y coherencia
- Verificar tareas programadas
- Definir ventanas de mantenimiento
- Controlar cambios realizados durante el mantenimiento
- Conservar evidencias y resultados
- Qué conviene automatizar
- Cuándo una revisión preventiva debe convertirse en una intervención
- Gestionar varias bases sin multiplicar burocracia
- Plan práctico de implantación
- Errores frecuentes
- Lista de comprobación
- Preguntas frecuentes
- Conclusión
Qué es una política de mantenimiento preventivo
Una política de mantenimiento preventivo es un conjunto de reglas periódicas para conservar una base de datos dentro de condiciones operativas conocidas. Define qué revisar, cuándo hacerlo, qué resultado se considera normal y qué acción corresponde cuando aparece una desviación.
La diferencia respecto a una lista de tareas aisladas es importante. Una lista puede decir “revisar índices”. Una política debe responder además:
- qué índices;
- con qué frecuencia;
- qué información se utilizará para decidir;
- qué umbral obliga a investigar;
- quién realiza la revisión;
- cómo se registra el resultado;
- qué procedimiento se sigue si hace falta intervenir.
Por ejemplo, una tarea preventiva no debería consistir en reconstruir todos los índices cada domingo. Debería consistir en revisar qué estructuras necesitan realmente mantenimiento y actuar cuando las métricas y el motor lo justifican.
Preventivo no significa intervenir constantemente
Una base estable puede necesitar menos intervención que otra con alta escritura o crecimiento rápido. El mantenimiento correcto evita tanto la negligencia como el exceso de actividad.
La política debe ser repetible
Una revisión hecha “cuando alguien se acuerda” no es una política. Debe existir una frecuencia suficientemente clara para que otra persona pueda continuarla.
La política debe producir evidencia
Después de una revisión debería quedar algún registro: fecha, alcance, resultado, anomalías y acciones. No hace falta un sistema complejo; una tabla de mantenimiento, un registro versionado o un documento estructurado pueden ser suficientes.
Qué debe conseguir
Una política preventiva bien diseñada debería reducir principalmente cinco tipos de riesgo.
Detectar deterioro gradual
Algunos problemas no aparecen de golpe. Una tabla puede crecer un 5 % cada semana, una tarea puede tardar cada vez más o un volumen puede acercarse lentamente a su límite.
Evitar acumulación de residuos
Datos temporales, registros de sesiones, colas antiguas, tablas de staging o históricos sin política pueden crecer indefinidamente.
Mantener previsibilidad
Una base mantenida de forma regular es más fácil de dimensionar, actualizar y recuperar.
Reducir intervenciones urgentes
Actuar con margen permite programar cambios, probarlos y disponer de recuperación. Esperar al límite obliga a intervenir bajo presión.
Conservar conocimiento operativo
El calendario y los registros de mantenimiento permiten comprender la evolución del sistema sin depender exclusivamente de la memoria de una persona.
Este enfoque complementa las buenas prácticas para administrar bases de datos durante muchos años. Aquel enfoque es general y de largo plazo; aquí se concreta cómo convertir esa filosofía en revisiones periódicas.
Qué no debe intentar cubrir
Una política preventiva se vuelve confusa cuando intenta absorber todos los procedimientos de administración.
No sustituye a la monitorización
La monitorización responde a qué está ocurriendo y cómo detectar desviaciones. El artículo cómo monitorizar bases de datos de forma sencilla desarrolla específicamente esa disciplina.
No sustituye a la política de backup
El mantenimiento debe comprobar que las copias esperadas existen y que no hay señales de fallo, pero frecuencia, retención, destinos y restauración pertenecen a la política de copias de seguridad para bases de datos.
No sustituye al diagnóstico de rendimiento
Una revisión puede detectar consultas lentas o crecimiento anormal. Investigar la causa requiere un análisis específico, relacionado con cómo detectar problemas de rendimiento en una base de datos.
No sustituye a las actualizaciones
Revisar versiones y fin de soporte forma parte del mantenimiento preventivo, pero planificar una actualización de motor necesita su propio procedimiento.
No sustituye a la documentación técnica
La política debe generar registros mínimos, pero la arquitectura, dependencias y procedimientos del servidor necesitan documentación propia.
Separar responsabilidades hace que cada documento sea más claro y evita repetir el mismo contenido en varios artículos o procedimientos.
Empezar por un inventario fiable
No se puede mantener preventivamente lo que no se conoce. Antes de fijar calendarios conviene disponer de un inventario mínimo.
Para cada base resulta útil registrar:
- nombre;
- motor;
- versión;
- servidor o instancia;
- entorno;
- aplicación o aplicaciones que dependen de ella;
- responsable;
- tamaño actual;
- criticidad;
- método de backup;
- ventana de mantenimiento disponible;
- principales tareas programadas.
Identificar bases olvidadas
En servidores antiguos pueden existir bases de pruebas, migraciones, copias manuales o proyectos abandonados. Antes de eliminarlas hay que confirmar su finalidad y dependencia.
Distinguir instancia y base
Un mismo motor puede alojar varias bases. Algunas tareas afectan a toda la instancia y otras son específicas de una base concreta.
Registrar entorno
Producción, pruebas y desarrollo no deberían recibir automáticamente el mismo nivel de mantenimiento.
Asignar responsable
Incluso en una empresa de una sola persona merece la pena indicar quién revisa el sistema. Facilita delegación y continuidad futura.
Clasificar bases de datos por criticidad
La frecuencia de mantenimiento debería depender de las consecuencias de un fallo.
Una clasificación sencilla puede utilizar cuatro niveles:
| Nivel | Descripción | Ejemplo de tratamiento |
|---|---|---|
| Crítica | Su indisponibilidad detiene una actividad esencial o puede producir pérdidas relevantes. | Revisión frecuente, alertas, recuperación probada y ventanas planificadas. |
| Importante | El negocio puede continuar temporalmente, pero con degradación significativa. | Revisión periódica y recuperación documentada. |
| Auxiliar | Facilita trabajo interno y puede permanecer indisponible durante más tiempo. | Mantenimiento simplificado. |
| Reproducible | Puede reconstruirse a partir de scripts o fuentes externas. | Prioridad baja; proteger principalmente esquema y configuración. |
La clasificación debería afectar a:
- frecuencia de revisión;
- urgencia ante anomalías;
- ventanas;
- nivel de evidencia;
- pruebas de recuperación;
- tolerancia a crecimiento o degradación.
No conviene marcar todo como crítico. Si todo recibe máxima prioridad, la clasificación deja de servir.
Crear una línea base de funcionamiento
El mantenimiento necesita conocer qué es normal. Sin una referencia, cualquier cifra puede parecer preocupante o pasar inadvertida.
Una línea base inicial puede incluir:
- tamaño total;
- crecimiento mensual aproximado;
- tablas principales;
- índices más grandes;
- número habitual de conexiones;
- duración típica de backup;
- duración de tareas de mantenimiento;
- espacio libre;
- consultas o cargas conocidas;
- errores recurrentes ya entendidos.
La línea base cambia
Un sistema que crece de forma saludable puede duplicar tamaño en un año. La referencia debe actualizarse cuando cambia la actividad.
Comparar tendencia, no solo valor absoluto
Una base de 50 GB no es necesariamente problemática. Más importante puede ser que haya pasado de 20 a 50 GB en un mes sin explicación.
Registrar cambios estructurales
Si se añade un módulo, se migra información o cambia la retención, la línea base debe reflejarlo.
Definir frecuencias de mantenimiento
No existe una frecuencia universal. El calendario debe adaptarse a criticidad, volumen y ritmo de cambio.
Una estructura práctica puede dividirse en:
- revisión diaria;
- revisión semanal;
- revisión mensual;
- revisión trimestral o semestral;
- revisión extraordinaria después de cambios importantes.
Evitar frecuencias por costumbre
“Todos los domingos” no es una justificación. Cada tarea debería tener un motivo: detectar ausencia de backup, controlar crecimiento, revisar mantenimiento interno o eliminar datos temporales.
Ajustar por riesgo
Una base que recibe miles de operaciones diarias necesita más vigilancia que otra que cambia una vez al mes.
Revisar el calendario
La política no debe permanecer congelada durante años. Si cambia el uso, deben cambiar las frecuencias.
Rutina diaria
La revisión diaria debería ser breve y centrarse en señales que necesitan respuesta rápida.
Puede incluir:
- confirmar disponibilidad;
- revisar errores importantes del motor;
- comprobar que las tareas críticas programadas terminaron;
- verificar la edad de la última copia válida;
- comprobar espacio libre si existe crecimiento rápido;
- detectar acumulaciones anormales de colas o procesos internos.
La revisión diaria no debe convertirse en análisis profundo
Si se detecta una desviación, se abre una investigación. La rutina debe poder completarse rápidamente en condiciones normales.
Automatizar la ausencia
Es especialmente útil detectar tareas que no se ejecutaron. La falta de un error explícito no significa que todo haya funcionado.
Rutina semanal
La revisión semanal puede concentrarse en tendencias y tareas que no necesitan atención diaria.
- comparar crecimiento de la base;
- revisar tablas que aumentan más rápido;
- observar uso de conexiones;
- revisar tiempos de tareas internas;
- comprobar registros temporales;
- revisar fallos repetidos;
- confirmar que automatizaciones de housekeeping siguen funcionando.
Buscar cambios, no perfección
La pregunta útil suele ser “¿qué cambió respecto a semanas anteriores?” más que “¿está cada métrica en un valor ideal?”.
Anotar anomalías explicadas
Una importación extraordinaria puede justificar crecimiento. Registrar esa explicación evita investigarla de nuevo.
Rutina mensual
La revisión mensual permite tomar perspectiva sobre capacidad y mantenimiento estructural.
Puede incluir:
- comparar crecimiento mensual;
- revisar tablas e índices de mayor tamaño;
- comprobar tendencia de espacio libre;
- revisar estadísticas del optimizador;
- comprobar fragmentación o estructuras que el motor indique como problemáticas;
- revisar retención de datos temporales;
- verificar cuentas o permisos técnicos obsoletos;
- revisar versión y soporte del motor;
- comprobar duración de backups y restauraciones de referencia;
- actualizar el registro de mantenimiento.
No ejecutar tareas invasivas por calendario
La revisión mensual debe decidir si hace falta intervenir. No obliga a reconstruir índices, reorganizar tablas ni purgar información si no existe una razón.
Rutina trimestral o semestral
Las revisiones menos frecuentes deberían centrarse en decisiones de evolución.
- revisar capacidad a seis o doce meses;
- confirmar que la política de retención sigue siendo válida;
- revisar bases, tablas o índices abandonados;
- revisar usuarios técnicos;
- comprobar dependencias y documentación;
- evaluar versiones próximas a fin de soporte;
- revisar ventanas de mantenimiento;
- comprobar si alguna tarea preventiva ya no aporta valor;
- actualizar criticidad.
Revisar la política, no solo la base
Una tarea que tenía sentido hace un año puede ser innecesaria hoy. El mantenimiento también debe eliminar burocracia obsoleta.
Controlar almacenamiento y crecimiento
Quedarse sin espacio es una de las incidencias más evitables si el crecimiento se observa con margen.
Medir tendencia
Conviene registrar:
- tamaño actual;
- crecimiento por periodo;
- espacio libre;
- tablas responsables del crecimiento;
- volumen de índices;
- espacio ocupado por temporales cuando sea relevante.
Estimar horizonte
Si existen 200 GB libres y el sistema crece 20 GB al mes, el margen teórico es de diez meses. No debería esperarse al noveno mes para actuar.
Separar crecimiento esperado y anormal
Más clientes pueden justificar más datos. Una tabla temporal que crece indefinidamente no.
Para profundizar en esta disciplina específica puede consultarse cómo controlar el crecimiento de una base de datos.
Revisar tablas y estructuras que crecen
El tamaño total puede ocultar dónde se concentra realmente el problema.
Identificar las mayores
Conviene conocer qué tablas concentran más datos y cuáles están creciendo más rápido.
Distinguir información activa e histórica
Una tabla de operaciones actuales puede necesitar acceso rápido. Una tabla histórica puede tolerar otro tratamiento.
Detectar temporales permanentes
Tablas de importación, staging, logs internos o colas pueden quedar abandonadas después de proyectos.
Revisar grandes objetos
Cuando el motor almacena BLOB u objetos grandes, conviene confirmar que su crecimiento sigue respondiendo a una necesidad.
Mantener índices con criterio
Los índices son esenciales para el rendimiento, pero también consumen espacio y añaden trabajo a las escrituras.
No reconstruir todos los índices por rutina
La necesidad depende del motor, tipo de índice, patrón de actualización y grado de degradación real. Las recomendaciones genéricas pueden ser contraproducentes.
Buscar índices inútiles
Un índice creado para una consulta que ya no existe puede seguir ocupando espacio y ralentizando escrituras.
Buscar índices duplicados o solapados
Dos índices muy similares pueden no aportar valor adicional.
Revisar índices grandes
Un crecimiento desproporcionado puede justificar análisis.
Medir antes y después
Si se modifica un índice, conviene registrar qué problema se pretendía resolver y comprobar el resultado.
La política preventiva debe decidir cuándo revisar índices; el diagnóstico concreto de una consulta lenta pertenece al análisis de rendimiento.
Mantener estadísticas y metadatos del optimizador
Los motores utilizan estadísticas para decidir cómo ejecutar consultas. Si no representan adecuadamente los datos actuales, el optimizador puede elegir planes poco eficientes.
Conocer el mecanismo del motor
PostgreSQL, MariaDB, MySQL, SQL Server y otros motores gestionan estas tareas de forma distinta. La política debe apoyarse en procedimientos soportados por la tecnología utilizada.
Revisar automatismos internos
Muchos motores ya actualizan estadísticas automáticamente. Antes de añadir tareas manuales, conviene comprobar si el sistema existente funciona correctamente.
Actuar tras cambios masivos
Importaciones, borrados o transformaciones grandes pueden justificar una actualización extraordinaria según el motor.
No ejecutar mantenimiento redundante
Duplicar procesos automáticos del motor con scripts propios puede aumentar carga sin beneficio.
Diseñar tareas de housekeeping
Housekeeping es el conjunto de tareas que elimina o archiva información operativa que ya no debe permanecer indefinidamente en la capa activa.
Ejemplos:
- sesiones caducadas;
- tokens expirados;
- colas completadas;
- datos temporales de importación;
- registros de staging;
- logs internos antiguos;
- resultados intermedios reproducibles.
Definir retención explícita
No debería depender de una decisión improvisada cada vez que falta espacio.
Eliminar en lotes
Borrar millones de filas de una sola vez puede generar bloqueos, logs de transacción o picos de I/O. Las tareas periódicas pequeñas suelen ser más predecibles.
Registrar resultado
Una tarea automática debería indicar cuántos registros procesó y si terminó correctamente.
Evitar borrar información empresarial por error
Los datos temporales deben estar claramente diferenciados de los históricos con valor.
Gestionar datos históricos y retención
Una política preventiva debe saber qué datos pueden crecer indefinidamente y qué estrategia existe para ellos.
Definir por qué se conserva cada histórico
Puede existir valor:
- operativo;
- analítico;
- contractual;
- legal;
- de auditoría;
- de aprendizaje.
No usar la falta de espacio como política de retención
El momento de decidir qué conservar es antes de necesitar borrar urgentemente.
Archivar cuando sea razonable
Los datos antiguos pueden permanecer en la misma base mientras el rendimiento sea adecuado. Cuando el volumen lo justifique pueden estudiarse tablas históricas, particionado o capas separadas.
Mantener trazabilidad
Archivar no debería destruir las relaciones necesarias para interpretar el pasado.
Comprobar integridad y coherencia
Una base puede estar disponible y responder consultas mientras acumula problemas de coherencia.
Restricciones
Las claves foráneas y restricciones deberían impedir muchos errores desde el diseño. La política puede revisar excepciones allí donde existan importaciones o procesos que operen fuera de esas garantías.
Registros huérfanos
En sistemas antiguos o migrados puede haber referencias a entidades inexistentes.
Valores imposibles
Fechas inconsistentes, estados desconocidos o importes fuera de rango pueden indicar fallos de aplicación o integración.
Conteos de control
Algunas operaciones críticas pueden disponer de comprobaciones sencillas: número de registros esperados, sumas de importes o reconciliación con otro sistema.
No convertir la política en una auditoría completa de datos
El mantenimiento preventivo debe incluir controles de alto valor, no revisar exhaustivamente cada registro.
Verificar tareas programadas
Una tarea automática puede dejar de ejecutarse sin generar un error visible. Por eso no basta con programarla una vez.
Conviene inventariar:
- backups;
- housekeeping;
- actualización de estadísticas cuando proceda;
- procesos de importación;
- sincronizaciones;
- archivado;
- recolección de métricas.
Comprobar última ejecución correcta
Es mejor medir la edad del último éxito que confiar únicamente en avisos de fallo.
Registrar duración
Una tarea que antes tardaba cinco minutos y ahora tarda una hora puede estar avisando de crecimiento o degradación.
Evitar solapamiento
Si una tarea tarda más que su frecuencia, pueden acumularse ejecuciones simultáneas.
Conservar un resultado resumido
Fecha, duración, registros procesados y estado suelen ser suficientes para una primera revisión.
Definir ventanas de mantenimiento
Algunas tareas consumen recursos o pueden requerir bloqueo. La política debería decidir cuándo pueden ejecutarse.
Conocer horas de menor actividad
La ventana debe adaptarse al uso real, no únicamente al horario laboral teórico.
Estimar duración
Una intervención que antes cabía en una hora puede dejar de hacerlo cuando la base crece.
Definir qué tareas pueden ejecutarse en línea
Los motores modernos permiten muchas operaciones sin parada total, pero el comportamiento depende de versión y tecnología.
Preparar reversión
Las intervenciones que cambian estructura o configuración deberían tener un plan de recuperación adecuado.
No mezclar demasiados cambios
Si en una ventana se actualiza el motor, se reconstruyen índices, se cambia configuración y se migra información, resulta difícil saber qué provocó un problema.
Controlar cambios realizados durante el mantenimiento
El mantenimiento preventivo no debería convertirse en una oportunidad para modificar producción sin control.
Un cambio, una razón
Cada intervención debería responder a una observación concreta.
Registrar antes y después
Si se elimina un índice, cambia una configuración o se archiva información, conviene conservar:
- motivo;
- fecha;
- responsable;
- estado anterior;
- cambio;
- resultado;
- forma de revertir cuando aplique.
No cambiar configuración por recomendaciones genéricas
Parámetros copiados de Internet pueden ser inadecuados para otro hardware, otra versión o otra carga.
Evitar optimización permanente
Una base no necesita ser afinada continuamente si cumple los objetivos. El mantenimiento busca estabilidad, no perseguir pequeñas mejoras sin valor operativo.
Conservar evidencias y resultados
Una política que no deja rastro acaba dependiendo de memoria.
Un registro sencillo podría contener:
| Fecha | Base | Revisión | Resultado | Acción |
|---|---|---|---|---|
| 2026-08-01 | produccion_app | Crecimiento mensual | +7 %, esperado | Ninguna |
| 2026-08-01 | produccion_app | Tabla temporal | Retención no ejecutada | Revisar tarea |
No registrar ruido
No es necesario documentar cientos de valores si la monitorización ya los conserva. El registro de mantenimiento debería resumir decisiones y excepciones.
Conservar contexto
“Todo correcto” aporta menos que “crecimiento dentro de línea base, espacio para 14 meses, tareas completadas”.
Facilitar comparación
Un formato constante permite revisar varios meses y detectar cambios de tendencia.
Qué conviene automatizar
Muchas revisiones preventivas pueden automatizarse parcialmente.
Recogida de información
Tamaño, crecimiento, espacio, edad de backup, duración de tareas y errores pueden recopilarse automáticamente.
Comprobación de ausencia
Es útil alertar cuando una tarea esperada no aparece.
Housekeeping repetitivo
La limpieza de datos claramente temporales puede automatizarse con límites y registro.
Informes periódicos
Un resumen semanal o mensual puede reducir trabajo manual.
Qué no conviene automatizar a ciegas
Acciones como eliminar índices, cambiar parámetros, borrar grandes volúmenes o reorganizar estructuras deberían requerir una justificación y, según impacto, revisión humana.
La automatización debe recoger señales y ejecutar tareas deterministas, no sustituir decisiones técnicas que necesitan contexto.
Cuándo una revisión preventiva debe convertirse en una intervención
La política necesita criterios para dejar de observar y empezar a actuar.
Ejemplos:
- el espacio disponible cae por debajo del margen definido;
- una tarea tarda más que su ventana;
- la tasa de crecimiento cambia de forma sostenida;
- una tabla temporal supera su retención;
- aparecen errores de integridad;
- un índice o consulta se degrada significativamente;
- una versión se acerca al fin de soporte;
- la copia ya no puede completarse dentro del periodo previsto;
- la restauración supera el objetivo del negocio.
Definir acción siguiente
Un umbral sin procedimiento genera alertas sin respuesta. Cada condición importante debería indicar qué hacer: investigar, ampliar capacidad, abrir una ventana o ejecutar un procedimiento específico.
No usar umbrales universales
El 80 % de disco puede ser urgente en un sistema que crece 5 % al día y completamente manejable en otro que no crece.
Gestionar varias bases sin multiplicar burocracia
Cuando existen varias bases, conviene normalizar la política sin forzar que todas sean iguales.
Conjunto mínimo común
Para todas puede revisarse:
- disponibilidad;
- crecimiento;
- espacio;
- tareas programadas;
- backup;
- errores;
- versión.
Añadir controles específicos por motor
Después pueden incorporarse tareas propias de PostgreSQL, MariaDB u otros motores.
Usar criticidad para reducir esfuerzo
No todas las bases necesitan revisión diaria.
Plantilla común
Una misma estructura de registro ayuda a comparar sistemas y delegar mantenimiento.
Plan práctico de implantación
1. Crear el inventario
Lista todas las bases, versiones, entornos y responsables.
2. Clasificar criticidad
Decide qué impacto tendría una indisponibilidad.
3. Crear una línea base
Registra tamaño, crecimiento, tareas y tiempos normales.
4. Definir cinco comprobaciones esenciales
Empieza por pocas señales: disponibilidad, espacio, crecimiento, tareas y backup.
5. Crear calendario
Distribuye revisiones diarias, semanales y mensuales.
6. Identificar housekeeping
Define datos temporales que deben caducar.
7. Registrar resultados
Crea una plantilla sencilla.
8. Automatizar recogida
Reduce trabajo manual sin automatizar decisiones complejas.
9. Definir umbrales y acciones
Cada desviación importante necesita un siguiente paso.
10. Revisar la política
Cada trimestre o semestre elimina tareas inútiles y ajusta frecuencias.
Una política sostenible puede empezar con una página y unos pocos scripts. El objetivo no es crear documentación extensa, sino conseguir una rutina que realmente se ejecute.
Errores frecuentes
Hacer mantenimiento solo cuando aparece un problema
Eso es mantenimiento reactivo, no preventivo.
Ejecutar tareas porque siempre se han hecho
Cada tarea debería tener una necesidad actual.
Reconstruir todos los índices periódicamente
Puede consumir recursos sin aportar beneficio y depende mucho del motor.
Confundir monitorización con mantenimiento
Observar una señal no equivale a definir una intervención.
No medir duración
Las tareas pueden crecer hasta salirse silenciosamente de su ventana.
No revisar housekeeping
Las tablas temporales pueden convertirse en las mayores de la base.
Borrar histórico para liberar espacio
La retención debe definirse por valor y obligaciones, no por urgencia.
Aplicar recomendaciones genéricas
Una configuración óptima para otra base puede ser perjudicial.
Automatizar acciones destructivas sin límites
Los errores de lógica pueden multiplicarse rápidamente.
No conservar evidencia
Sin histórico resulta difícil conocer tendencias o justificar cambios.
Crear una política demasiado compleja
Si nadie puede mantenerla, terminará abandonada.
No revisar la propia política
Los sistemas evolucionan y el calendario también debe hacerlo.
Lista de comprobación
- ¿existe inventario de bases e instancias?
- ¿cada base tiene criticidad?
- ¿se conoce su tamaño y crecimiento habitual?
- ¿se conoce el espacio libre?
- ¿se identifican las tablas que más crecen?
- ¿las tareas automáticas tienen registro de última ejecución?
- ¿se comprueba la edad de la última copia válida?
- ¿los datos temporales tienen retención?
- ¿se revisan índices con métricas y no por costumbre?
- ¿se conoce cómo mantiene estadísticas el motor?
- ¿existen controles básicos de integridad?
- ¿las tareas tienen una ventana adecuada?
- ¿se registra la duración de tareas importantes?
- ¿los cambios de mantenimiento quedan documentados?
- ¿existen criterios para escalar una anomalía?
- ¿la política diferencia producción, pruebas y desarrollo?
- ¿las automatizaciones destructivas tienen límites?
- ¿se revisa periódicamente la versión del motor?
- ¿se revisa la política al menos varias veces al año?
Preguntas frecuentes
¿Cada cuánto hay que hacer mantenimiento de una base de datos?
No existe una frecuencia única. Las comprobaciones críticas pueden ser diarias, las tendencias semanales o mensuales y las revisiones estructurales trimestrales. La frecuencia debe adaptarse a criticidad, volumen y ritmo de cambio.
¿Hay que reconstruir los índices periódicamente?
No como regla universal. Depende del motor y del estado real de los índices. Es mejor medir y utilizar los mecanismos recomendados por la tecnología concreta que reconstruir todo por calendario.
¿Monitorización y mantenimiento preventivo son lo mismo?
No. La monitorización recoge señales y detecta anomalías. El mantenimiento preventivo define revisiones y acciones periódicas para conservar el sistema dentro de condiciones conocidas.
¿El backup forma parte del mantenimiento?
La política preventiva debe comprobar que el proceso de backup sigue funcionando, pero la estrategia de frecuencia, retención, destinos y restauración pertenece a una política específica de copias.
¿Qué debería revisar diariamente?
En bases importantes suele bastar con disponibilidad, errores graves, tareas críticas, edad de la última copia válida y capacidad cuando exista crecimiento rápido.
¿Qué conviene revisar mensualmente?
Crecimiento, tablas e índices grandes, espacio libre, duración de tareas, housekeeping, estadísticas, versiones y tendencias que no necesitan una respuesta inmediata.
¿Una base pequeña necesita una política formal?
Sí, pero puede ser muy sencilla. Un inventario, un calendario corto y un registro de resultados pueden ser suficientes para evitar que el mantenimiento dependa de memoria.
¿Qué es housekeeping?
Son tareas que retiran, archivan o limpian información operativa que ya no necesita permanecer en la capa activa, como sesiones caducadas, staging, colas terminadas o temporales.
¿Debo borrar los datos históricos cuando la base crece?
No automáticamente. Primero hay que definir su valor y la retención necesaria. Después puede decidirse si permanecen, se archivan o se mueven a otra estructura.
¿Cómo sé si una tarea de mantenimiento tarda demasiado?
Conviene comparar su duración con la línea base y con la ventana disponible. Un crecimiento sostenido del tiempo de ejecución es una señal que merece investigación.
¿Qué tareas merece la pena automatizar?
La recogida de métricas, comprobación de ejecuciones, housekeeping determinista e informes periódicos suelen ser buenos candidatos. Las acciones destructivas o que cambian estructura requieren más control.
¿Qué hago si una revisión detecta una anomalía?
La política debería indicar el siguiente paso: investigar, abrir incidencia, ejecutar un procedimiento, programar una ventana o escalar la capacidad. Detectar sin definir acción genera ruido.
¿Cómo se mantiene una política con varias bases diferentes?
Conviene definir un conjunto común de comprobaciones y añadir después controles específicos por motor y criticidad. Así se evita crear un sistema totalmente distinto para cada base.
¿Hace falta una herramienta especializada?
No necesariamente. Una pequeña empresa puede empezar con scripts, tareas programadas, consultas del motor y un registro sencillo. Las herramientas avanzadas tienen sentido cuando reducen trabajo real o mejoran visibilidad.
¿Cuál es la señal de que la política está bien diseñada?
Que las revisiones se ejecutan de forma regular, requieren un esfuerzo proporcional, detectan desviaciones con margen y permiten explicar qué se hizo sin depender de memoria.
Conclusión
Definir una política de mantenimiento preventivo para bases de datos significa transformar una serie de revisiones técnicas dispersas en una rutina operativa previsible. El objetivo no es intervenir más, sino intervenir mejor: observar deterioros con margen, evitar acumulaciones innecesarias y saber cuándo una desviación exige una acción específica.
La política debe comenzar por un inventario, una clasificación de criticidad y una línea base. A partir de ahí pueden definirse frecuencias realistas: comprobaciones breves diarias, revisión de tendencias semanal, análisis de capacidad mensual y una revisión estructural cada varios meses.
El mantenimiento debe vigilar almacenamiento, crecimiento, tablas, índices, estadísticas, housekeeping, integridad, tareas programadas y ventanas. Sin embargo, cada disciplina conserva sus límites: la monitorización, el backup, el diagnóstico de rendimiento, las actualizaciones y la documentación necesitan procedimientos propios.
Una buena política preventiva no ejecuta tareas por superstición técnica. Cada acción debe responder a una señal, una necesidad o un riesgo conocido. Reconstruir índices sin medir, borrar históricos por falta de espacio o cambiar parámetros por recomendaciones genéricas puede causar más problemas que beneficios.
La automatización resulta útil para recoger información, detectar ausencias y ejecutar tareas repetitivas seguras, pero las decisiones de impacto elevado deben conservar controles adecuados. Además, cada revisión importante debería dejar evidencia suficiente para comparar tendencias y explicar cambios meses después.
Para una pequeña organización, una política eficaz puede ser sorprendentemente sencilla: unas pocas comprobaciones, un calendario, scripts fiables, umbrales razonados y una tabla de resultados. Si puede mantenerse durante años y detectar problemas antes de que se conviertan en urgencias, está cumpliendo su función.
El resultado es una base de datos que envejece de manera controlada. El crecimiento deja de ser una sorpresa, las tareas internas no quedan olvidadas, los residuos no se acumulan indefinidamente y las intervenciones pueden planificarse con tiempo. Esa previsibilidad es una de las diferencias fundamentales entre una base que simplemente sigue funcionando y una base realmente administrada.
