Post-upgrade tasks (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 recompiles packages/views/triggers that became INVALID after the upgrade. Gathering dictionary and fixed object statistics afterwards lets the optimizer produce sound plans in the new version.

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;

pg_upgrade (PG17 and earlier) does not carry over planner statistics; analyze-in-stages makes the system usable quickly by gathering coarse statistics first, then full ones. Extensions must be refreshed with ALTER EXTENSION ... UPDATE, and indexes with REINDEX if the collation changed.

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)

In MySQL 8.0.16 and later, the mysql_upgrade function has moved into the server, so it is not run separately. After the upgrade, refreshing statistics with ANALYZE TABLE on large/critical tables preserves plan quality.

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;

After the upgrade, DBCC UPDATEUSAGE corrects inaccurate space/row counters carried over from older versions, and sp_updatestats refreshes statistics. When raising the compatibility level, monitor plan regressions that the new Cardinality Estimator (CE) may cause.

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

After a major upgrade, verify that the FCV has reached the target version. Rebuilding indexes is not a routine upgrade step; if an index is called out in the release notes or produces a warning in the log, recreate it with dropIndex + createIndex. On 6.0+, reIndex works only on a standalone and is not allowed on replica set members.

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

After a Redis upgrade there is no schema compile/analyze task; the job is to verify that replication has been re-established, RDB/AOF persistence is healthy, and the key count is preserved.

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" } }

After the upgrade, verify that the cluster status is 'green' and all shards are allocated. Indices in a format older than the previous major version cannot be read in the new version, so they must be moved to the current format with _reindex.