Tarefas pós-upgrade (recompile/analyze)

Oracle

-- 1) Compile invalid objects in parallel:
@?/rdbms/admin/utlrp.sql
-- 2) Refresh dictionary/fixed object statistics:
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
-- Check remaining invalid objects:
SELECT owner, object_name, object_type FROM dba_objects WHERE status='INVALID';

utlrp.sql recompila packages/views/triggers que ficaram INVALID após o upgrade. Coletar em seguida as estatísticas do dicionário e dos fixed objects permite que o otimizador produza planos adequados na nova versão.

PostgreSQL

# 1) Regather statistics after pg_upgrade (mandatory):
$ vacuumdb --all --analyze-in-stages
-- 2) Bring extensions to the new version:
ALTER EXTENSION postgis UPDATE;
-- 3) If the collation changed, rebuild text indexes (can take long):
REINDEX DATABASE database_name;

O pg_upgrade (PG17 e anteriores) não transfere as estatísticas do planner; analyze-in-stages torna o sistema utilizável rapidamente, coletando primeiro estatísticas grosseiras e depois as completas. As extensões devem ser atualizadas com ALTER EXTENSION ... UPDATE, e os índices com REINDEX se a collation mudou.

MySQL

-- 8.0+ dictionary upgrade happens automatically at startup; additionally:
ANALYZE TABLE customer;   -- refresh statistics of critical tables
-- Legacy 5.7 -> if needed on first startup:
-- $ mysql_upgrade -u root -p   (before 8.0.16)

No MySQL 8.0.16 e posteriores, a função do mysql_upgrade passou para o servidor, então ele não é executado separadamente. Após o upgrade, atualizar as estatísticas com ANALYZE TABLE nas tabelas grandes/críticas preserva a qualidade dos planos.

SQL Server

-- 1) Correct page/row usage counters:
DBCC UPDATEUSAGE(Sales);
-- 2) Refresh statistics (sp_updatestats uses sampling; FULLSCAN for critical tables):
EXEC sp_updatestats;
-- UPDATE STATISTICS dbo.CriticalTable WITH FULLSCAN;
-- 3) Raise the compatibility level to the new version (while monitoring):
ALTER DATABASE Sales SET COMPATIBILITY_LEVEL = 160;

Após o upgrade, DBCC UPDATEUSAGE corrige contadores imprecisos de espaço/linhas herdados de versões antigas, e sp_updatestats atualiza as estatísticas. Ao elevar o compatibility level, monitore as regressões de plano que o novo Cardinality Estimator (CE) pode causar.

MongoDB

// 1) Verify the FCV upgrade:
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
// 2) Check indexes and compatibility warnings in the server logs:
db.customer.getIndexes()
// If an index is incompatible: dropIndex + createIndex (rolling); do NOT use reIndex

Após um upgrade major, verifique se o FCV chegou à versão alvo. Reconstruir índices não é uma etapa rotineira do upgrade; se um índice for citado nas release notes ou gerar aviso no log, recrie-o com dropIndex + createIndex. No 6.0+, reIndex só funciona em standalone e não é permitido em membros de replica set.

Redis

# Usually no extra task is needed. Recommended: verify persistence and replication:
redis-cli INFO replication   # is the master/replica link healthy
redis-cli INFO persistence   # rdb_last_bgsave_status / aof_last_bgrewrite_status
redis-cli DBSIZE             # is the key count as expected

Após um upgrade do Redis, não há tarefa de compile/analyze de schema; o trabalho é verificar se a replicação foi restabelecida, se a persistência RDB/AOF está saudável e se a contagem de chaves foi preservada.

Elasticsearch

# Verify cluster health:
GET _cluster/health
# Move indices created in an old major version that can no longer be read:
POST _reindex
{ "source": { "index": "old_index" }, "dest": { "index": "new_index" } }

Após o upgrade, verifique se o status do cluster está 'green' e se todos os shards estão alocados. Índices em formato anterior à versão major anterior não podem ser lidos na nova versão, então devem ser movidos para o formato atual com _reindex.