Tareas posteriores a la actualización (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 los paquetes/vistas/triggers que quedaron INVALID tras la actualización. Recopilar después las estadísticas del diccionario y de los fixed objects permite al optimizador generar planes correctos en la nueva versión.

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 y anteriores) no traslada las estadísticas del planificador; analyze-in-stages hace que el sistema sea utilizable rápidamente recopilando primero estadísticas aproximadas y luego las completas. Las extensiones deben actualizarse con ALTER EXTENSION ... UPDATE, y los índices con REINDEX si cambió la collation.

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)

En MySQL 8.0.16 y posteriores, la función de mysql_upgrade se ha integrado en el servidor, por lo que no se ejecuta por separado. Tras la actualización, refrescar las estadísticas con ANALYZE TABLE en las tablas grandes/críticas preserva la calidad de los planes.

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;

Tras la actualización, DBCC UPDATEUSAGE corrige los contadores de espacio/filas inexactos heredados de versiones anteriores y sp_updatestats refresca las estadísticas. Al subir el nivel de compatibilidad, vigile las regresiones de planes que pueda provocar el nuevo Cardinality Estimator (CE).

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

Tras una actualización mayor, verifique que el FCV ha alcanzado la versión de destino. Reconstruir los índices no es un paso rutinario de la actualización; si las release notes mencionan un índice o este genera una advertencia en el log, vuelva a crearlo con dropIndex + createIndex. En 6.0+, reIndex solo funciona en un standalone y no se permite en miembros de un 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

Tras actualizar Redis no hay tareas de compilación/análisis de esquema; se trata de verificar que la replicación se ha restablecido, que la persistencia RDB/AOF está sana y que se conserva el número de claves.

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

Tras la actualización, verifique que el estado del clúster es 'green' y que todos los shards están asignados. Los índices con un formato anterior a la versión mayor previa no se pueden leer en la nueva versión, por lo que deben pasarse al formato actual con _reindex.