Todo DBA tiene su límite. Esa delgada línea entre la paciencia infinita y querer estampar el teclado contra la pared. El día del que os hablo fue uno de esos. Un día que empezó tranquilo y terminó en una lucha encarnizada entre el servidor, el Optimizer y mi cordura.
Os cuento lo que ocurrió: un desplome monumental de rendimiento, misterios sin resolver y consultas que me hicieron replantear mi carrera profesional.
9:00 AM: La CPU al 100% y el misterio del índice fantasma
Llego a la oficina con mi café recién hecho y veo las alertas parpadeando como luces de Navidad: “CPU al 100%. El servidor está llorando”.
Abro el Activity Monitor y ahí está. Una consulta devorando recursos como si no hubiera mañana. La autora de semejante hazaña es la tabla Sales.OrderDetail, que por algún motivo ha pasado de ser una tabla tranquila a Satán hecho tabla.
La consulta en cuestión es:
SELECT OrderID, SUM(TotalAmount) AS Total
FROM Sales.OrderDetail
GROUP BY OrderID;Aparentemente inocente, ¿verdad? Pues no. Esta tabla tiene 50 millones de registros y sin ningún índice útil. Le pregunto al equipo:
– “¿Dónde están los índices?”
– “Los quitamos ayer porque ralentizaban las inserciones”, responden orgullosos.
Respirando hondo, les explico que quitar índices no soluciona los problemas de rendimiento. Es como quitar los frenos del coche para ir más rápido: técnicamente es cierto, pero no saldrá bien.
Solución: Creamos un índice adecuado:
CREATE INDEX IX_SalesOrderDetail_OrderID_TotalAmount
ON Sales.OrderDetail(OrderID, TotalAmount);Ejecuto la consulta de nuevo y, ¡milagro! La CPU se relaja. El servidor me guiña un ojo en señal de agradecimiento.
11:00 AM: La «Optimización» del Query Planner
Todo iba bien hasta que mi compañero Pepe —que jura que el Query Optimizer es inteligente— decidió lanzar su joyita del día.
– “He usado un HINT para asegurarme de que use el índice correcto”, dice, mientras me enseña esta aberración:
SELECT *
FROM Sales.Customers WITH (INDEX(0))
WHERE Country = 'Spain';Sí, habéis leído bien: INDEX(0). El equivalente SQL a decirle al Optimizer: «Da igual que lo sepas hacer bien, quiero que me compliques la vida».
– “Pepe, eso no optimiza nada. Has forzado al Optimizer a usar una estrategia peor”.
Pepe, con cara de no entender nada, me pide una explicación. Así que se la doy:
El Optimizer no es un enemigo, es un colega que necesita que le demos buenos datos. WITH (INDEX(0)) indica al motor de base de datos que no tiene que usar ningún índice. Si la tabla es un HEAP hará un table scan aunque haya índices nonclustered. Si la tabla tiene un cluster jamás hará un seek y siempre hará un scan. Si lo que queremos es que use el índice clustered deberíamos usar WITH (INDEX(1)) que dejará que el motor use lo más eficiente, un seek o un scan, depende del caso. Pero rara vez vas a tener que usarlo, si tus estadísticas están actualizadas y tus índices bien creados, SQL Server tomará la mejor decisión posible.
Actualizo las estadísticas:
UPDATE STATISTICS Sales.Customers;Le muestro cómo forzar buenos resultados sin jugar a ciegas con los HINTs:
SELECT *
FROM Sales.Customers
WHERE Country = 'Spain'
OPTION (RECOMPILE);Resultado: La consulta se ejecuta en 0.2 segundos sin INDEX(0) ni tonterías. Pepe asiente. Creo que hoy hemos ganado una pequeña batalla.
2:00 PM: El Desastre del «Top 1» sin orden
Después de comer, el desarrollador novato —al que llamaremos Juanito— me lanza una consulta de soporte urgente:
– “Necesito el último pedido. Lo he arreglado con un TOP 1”.
Cuando veo la consulta, siento una punzada en el estómago:
SELECT TOP 1 OrderID, TotalAmount
FROM Sales.Orders;– “¿Y dónde está el ORDER BY?” —pregunto yo, temblando.
– “¿Hace falta?”, responde Juanito, con una inocencia que me desarma.
Le explico que TOP 1 sin ORDER BY no garantiza el «último» ni el «primero». Solo devuelve el primero que pille, que puede ser cualquier registro según el orden físico de la tabla.
Solución:
SELECT TOP 1 OrderID, TotalAmount
FROM Sales.Orders
ORDER BY OrderDate DESC;– “¿Y si quiero asegurarme de que sea rápido?”, me pregunta.
– “Pon un índice en OrderDate. Tu servidor te lo agradecerá”.
CREATE INDEX IX_Orders_OrderDate ON Sales.Orders(OrderDate);La consulta ahora funciona como debe. Juanito toma notas en su libreta titulada “SQL para Torpes”.
5:00 PM: El plan de backup olvidado
Pensaba que el día había terminado cuando, de repente, entra en mi despacho el jefe:
-“¿Hiciste un backup esta mañana? Necesitamos restaurar la base de datos de ventas de ayer”.
Aquí el humor negro se hace real. Porque claro, en esta oficina, el backup se convierte en un problema solo cuando hace falta. Le miro fijamente:
– “¿Sabes qué es un backup, jefe?”.
Silencio incómodo. Por suerte, en esta ocasión sí tenemos backup diferencial. Aprovecho para darle una lección. Sin backups no hay paraíso. El desastre es cuestión de tiempo.
Ejecutamos la restauración:
RESTORE DATABASE SalesDB
FROM DISK = 'C:\Backups\SalesDB_Full.bak'
WITH REPLACE, NORECOVERY;
RESTORE DATABASE SalesDB
FROM DISK = 'C:\Backups\SalesDB_Differential.bak'
WITH RECOVERY;El jefe respira aliviado. Yo termino el día con la satisfacción de que los backups me salvaron el pellejo.
Conclusión: El servidor puede fallar, yo no
La vida de un DBA está llena de desafíos. Desde índices borrados hasta HINTs absurdos y consultas sin ORDER BY. Pero si algo aprendemos con el tiempo es que el desastre no es opcional; la preparación sí lo es.
Cierro mi sesión, guardo los logs y me despido del servidor, que hoy ha sobrevivido gracias a mí. Y mañana… mañana será otro día lleno de misterios.
Como dice el viejo refrán de DBA: «No hay problema en SQL Server que no pueda arreglarse con índices, backups y un buen café«.
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.
