Actualización de versión / reversión de parche

Síntoma

Problemas tras una actualización o parche: regresión de rendimiento, incompatibilidad con la aplicación o la base de datos no abre.

1. Primero, alto: ¿tiene un plan de vuelta atrás?

Si no tomó un backup completo + (si es posible) un snapshot de almacenamiento ANTES de la actualización en producción, el camino más seguro es corregir hacia adelante (fix forward). En la mayoría de las bases de datos, revertir significa restaurar desde backup. Este paso debería haberse planificado ANTES de la actualización.

2. Clasifique el problema

¿Es una regresión de planes del optimizador (consultas más lentas), una incompatibilidad de aplicación/driver o un fallo de apertura/corrupción? La vía de solución varía mucho según el caso.

3. Vía de reversión por base de datos

Oracle: reversión del parche con datapatch, o Flashback Database (si creó un guaranteed restore point). PostgreSQL: reversión tras pg_upgrade = binarios antiguos + backup del directorio de datos antiguo. MySQL: el DOWNGRADE in-place en general NO ESTÁ SOPORTADO; restaure desde backup. SQL Server: no hay downgrade; restaure desde el backup previo a la actualización. En todos los casos: el snapshot/backup es su seguro.

4. Si es una regresión de planes: corrija sin revertir

Normalmente no es necesario revertir toda la versión; solo han cambiado los planes.

Oracle

ALTER SYSTEM SET optimizer_features_enable='19.1.0';  -- pin to the old behavior
-- or lock in the good plan with a SQL Plan Baseline

PostgreSQL

ANALYZE;  -- fresh statistics first
-- if needed, temporarily: steer the plan with settings such as SET enable_nestloop=off;

5. Permanente: la próxima vez

Pruebe primero la actualización en staging con una carga real, aplique actualizaciones canary/rolling, tome un guaranteed restore point / snapshot y documente el procedimiento de vuelta atrás.