Tomar el control de un servidor SQL Server que ya está en producción puede ser una experiencia emocionante y, a la vez, aterradora. No sabemos qué nos vamos a encontrar: puede ser un entorno bien gestionado con documentación clara, o un caos absoluto sin backups, sin índices adecuados y con consultas bloqueando todo. No importa si llegamos porque somos los nuevos en el equipo o porque heredamos la administración por un cambio organizativo, lo primero que necesitamos es hacernos una idea clara de la salud del sistema y las prácticas que se han seguido hasta ahora.
A lo largo de los años, he aprendido que hay ciertos aspectos clave que siempre reviso en los primeros días. No es solo cuestión de scripts, sino de hacer las preguntas adecuadas y entender la historia del servidor. Vamos a ello.
¿Qué hace este servidor realmente?
Antes de empezar a revisar configuraciones, lo primero es entender qué rol cumple este servidor en la empresa. He visto casos donde me decían que un servidor era “de pruebas” y resultó que alojaba un ERP en producción. Para evitar sorpresas desagradables, hago estas preguntas:
- ¿Qué aplicaciones dependen de esta base de datos?
- ¿Cuáles son las bases de datos críticas?
- ¿Hay procesos ETL corriendo aquí? ¿Data warehouses?
- ¿Cuántos usuarios concurrentes hay en las horas pico?
- ¿Es un servidor en alta disponibilidad (AlwaysOn, mirroring, log shipping)?
Esta información la consigo hablando con desarrolladores, analistas y el equipo de infraestructura. A veces la gente no es consciente de cómo están interconectadas las bases de datos y aplicaciones, así que es mejor corroborar antes de hacer cualquier cambio. Si vemos que no obtenemos las respuestas es el momento de ponernos en guardia y extremar la vigilancia en el resto de puntos.
¿Hay backups funcionando en el servidor? ¿y son recuperables?
Uno de los mayores sustos que he tenido en mi carrera fue encontrar un servidor con backups configurados… pero con el disco de destino lleno desde hacía meses. Nadie administraba ese servidor, alguien configuró los backups pero no se habían vuelto a revisar. Nadie se dio cuenta hasta que hizo falta restaurar algo y me llamaron a mi pero por desgracia no había nada usable. Desde entonces, cuando miro un servidor, aunque sea para otra cosa que no tiene nada que ver siempre reviso tres cosas fundamentales: ¿Se están haciendo backups regularmente? ¿Dónde están almacenados? ¿Hay espacio suficiente? ¿Se han probado las restauraciones recientemente?
Es increíble la cantidad de veces que la gente asume que los backups están bien solo porque el job del SQL Agent está habilitado. Pero una cosa es que el job se ejecute y otra que el backup sea recuperable. Si estoy ante un servidor nuevo siempre intento hacer una prueba de restauración en un entorno de pruebas lo antes posible.
¿Cómo está la seguridad del servidor?
Aquí me han tocado verdaderos horrores. En una ocasión, encontré un servidor donde el usuario sa tenía la contraseña “123456” y se usaba en aplicaciones en texto plano. Otra vez, vi un entorno con todos los usuarios como sysadmin, incluyendo cuentas de servicio. Al llegar a un servidor, una vez revisadas las copias de seguridad lo siguiente que reviso es esto, ¿Quién tiene acceso y qué permisos tiene? ¿Existen cuentas antiguas que ya no deberían estar? ¿Se usa sa en aplicaciones? (¡Grave error!) ¿Se están usando cuentas de servicio con permisos innecesarios? ¿Se están usando cuentas compartidas?
Una auditoría rápida puede salvarnos de una posible brecha de seguridad.
Rendimiento del servidor: ¿estamos en crisis o en calma?
Aquí es donde empiezo a ponerme técnico. No quiero pasarme horas buscando problemas uno a uno, así que uso herramientas que me den un diagnóstico rápido. Mi favorita es sp_BlitzFirst de Brent Ozar, que en pocos segundos me dice si hay bloqueos, CPU saturada, problemas de memoria, o cualquier anomalía de rendimiento. Esto me da una visión inmediata de qué está pasando en ese momento en el servidor. Si veo la CPU al 100% o demasiadas esperas (wait stats), ya sé que tengo que profundizar.
También uso sp_Blitz, otro script de Brent Ozar que me ayuda a detectar problemas más generales como configuraciones erróneas, falta de backups, bases de datos sin CHECKDB reciente, etc. Estos scripts son una joya porque, además de darme información, si tengo dudas tienen un enlace en cada registro donde se explica cada problema con recomendaciones claras.
¿Cómo están usando el almacenamiento?
Uno de los mayores cuellos de botella en SQL Server suele ser el almacenamiento. He visto servidores con discos SSD rapidísimos donde la gente se preocupaba por la CPU, y otros con discos mecánicos compartidos donde cada consulta grande era una pesadilla. Para hacerme una idea rápida miro cuánto espacio queda disponible en los discos, qué archivos de datos y logs están creciendo sin control y si hay problemas de IO (latencia alta en lectura/escritura). Si veo esperas en PAGEIOLATCH_XX, sé que la E/S está sufriendo y tal vez haya que distribuir archivos de otra manera o mejorar el almacenamiento.
Índices y planes de ejecución: ¿está todo optimizado?
Cuando un servidor tiene problemas de rendimiento, muchas veces la causa está en índices mal diseñados o estadísticas desactualizadas. SQL Server nos da una pista con la DMV sys.dm_db_missing_index_details, pero antes de tomar decisiones reviso no solo si hay índices faltantes recomendados por el motor sino también si hay índices que nunca se usan y están ocupando espacio innecesario o si las estadísticas se actualizan con frecuencia.
A veces encuentro servidores donde los índices parecen diseñados por un algoritmo aleatorio, con redundancias absurdas y claves ineficientes.
SQL Agent y tareas programadas: ¿hay procesos críticos fallando en el servidor?
En una ocasión, llegué a un servidor donde un job de ETL crítico fallaba todos los días… desde hacía 3 meses. Nadie se había dado cuenta porque no tenían alertas configuradas. Así que siempre reviso qué jobs están programados y cuáles fallan con frecuencia esto se ve claramente mirando cuales muestran errores recurrentes. También me gusta preguntar a los usuarios si hay jobs que tardan más de lo esperado en ejecutarse. Si veo problemas aquí, investigo con los desarrolladores para entender qué impacto tienen y si necesitan ajustes.
Logs de errores: ¿hay señales de alerta en el servidor?
Por último pero no menos importante está el log de errores. SQL Server guarda mucha información en los logs de errores, pero la gente rara vez los revisa. Me gusta echar un vistazo para ver si hay mensajes de corrupción de bases de datos (CHECKDB fallando), intentos de inicio de sesión fallidos, problemas de memoria o CPU o fallos en el mirroring, replicación o AlwaysOn. Esto me da pistas sobre problemas pasados que aún podrían estar afectando el sistema.
Conclusión
Cada vez que tomo control de un servidor SQL Server, mi objetivo es entender su estado lo más rápido posible. Hacer preguntas, revisar configuraciones clave y usar herramientas como sp_Blitz y sp_BlitzFirst me ayudan a identificar problemas críticos sin perder tiempo. A partir de ahí, ya puedo priorizar qué arreglar primero y comenzar a mejorar el rendimiento y la estabilidad. Al final, la experiencia me ha enseñado que no importa qué tan bueno o malo sea el estado inicial del servidor, siempre hay algo que podemos hacer para mejorarlo. Y cuanto antes empecemos, mejor.
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!
