Upgrade de versão / rollback de patch

Sintoma

Problemas após um upgrade/patch: regressão de desempenho, incompatibilidade com a aplicação ou o banco não abrindo.

1. Pare primeiro: você tem um plano de retorno?

Se você não fez um backup completo + (se possível) um snapshot do storage ANTES do upgrade em produção, o caminho mais seguro é corrigir para frente. Na maioria dos bancos, voltar atrás significa restaurar de backup. Este passo deveria ter sido planejado ANTES do upgrade.

2. Classifique o problema

É uma regressão de plano do otimizador (consultas ficaram lentas), uma incompatibilidade de aplicação/driver ou uma falha de abertura/corrupção? O caminho da solução varia muito conforme o caso.

3. Caminho de rollback por banco

Oracle: rollback do patch com datapatch, ou Flashback Database (se você criou um guaranteed restore point). PostgreSQL: rollback após pg_upgrade = binários antigos + backup do diretório de dados antigo. MySQL: DOWNGRADE in-place geralmente NÃO É SUPORTADO — restaure de backup. SQL Server: não há downgrade — restaure o backup anterior ao upgrade. Em todos os casos: o snapshot/backup é o seu seguro.

4. Se for regressão de plano: corrija sem rollback

Geralmente não é preciso reverter a versão inteira; só os planos mudaram.

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. Definitivo: na próxima vez

Teste o upgrade primeiro em staging com uma carga real, aplique upgrades canary/rolling, crie um guaranteed restore point / snapshot e documente o procedimento de retorno.