Tâches post-mise à niveau (recompilation/analyse)

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 recompile les packages/vues/triggers devenus INVALID après la mise à niveau. Collecter ensuite les statistiques du dictionnaire et des fixed objects permet à l'optimiseur de produire des plans sains dans la nouvelle 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 et antérieur) ne transfère pas les statistiques du planificateur ; analyze-in-stages rend le système vite utilisable en collectant d'abord des statistiques grossières, puis complètes. Les extensions doivent être actualisées avec ALTER EXTENSION ... UPDATE, et les index avec REINDEX si la collation a changé.

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)

Depuis MySQL 8.0.16, la fonction de mysql_upgrade a été intégrée au serveur et ne s'exécute donc plus séparément. Après la mise à niveau, actualiser les statistiques avec ANALYZE TABLE sur les tables volumineuses/critiques préserve la qualité des plans.

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;

Après la mise à niveau, DBCC UPDATEUSAGE corrige les compteurs d'espace/de lignes inexacts hérités des anciennes versions, et sp_updatestats actualise les statistiques. Lors de l'élévation du niveau de compatibilité, surveillez les régressions de plans que peut causer le nouveau 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

Après une mise à niveau majeure, vérifiez que la FCV a atteint la version cible. La reconstruction des index n'est pas une étape de routine ; si un index est mentionné dans les notes de version ou produit un avertissement dans le journal, recréez-le avec dropIndex + createIndex. En 6.0+, reIndex ne fonctionne que sur un standalone et est interdit sur les membres d'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

Après une mise à niveau Redis, il n'y a pas de tâche de compilation/analyse de schéma ; il s'agit de vérifier que la réplication est rétablie, que la persistance RDB/AOF est saine et que le nombre de clés est préservé.

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

Après la mise à niveau, vérifiez que l'état du cluster est 'green' et que tous les shards sont alloués. Les indices dans un format antérieur à la version majeure précédente ne sont pas lisibles dans la nouvelle version ; ils doivent être migrés au format actuel avec _reindex.