Aufgaben nach dem 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 kompiliert Packages/Views/Trigger neu, die nach dem Upgrade INVALID geworden sind. Werden danach Dictionary- und Fixed-Object-Statistiken erhoben, erzeugt der Optimizer in der neuen Version solide Pläne.

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 und früher) übernimmt keine Planner-Statistiken; analyze-in-stages macht das System schnell nutzbar, indem zuerst grobe, dann vollständige Statistiken erhoben werden. Extensions müssen mit ALTER EXTENSION ... UPDATE aktualisiert werden, Indizes bei geänderter Collation mit REINDEX.

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)

Ab MySQL 8.0.16 ist die Funktion von mysql_upgrade in den Server gewandert und wird daher nicht separat ausgeführt. Nach dem Upgrade erhält ein Aktualisieren der Statistiken mit ANALYZE TABLE auf großen/kritischen Tabellen die Planqualität.

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;

Nach dem Upgrade korrigiert DBCC UPDATEUSAGE aus älteren Versionen übernommene ungenaue Speicher-/Zeilenzähler, sp_updatestats aktualisiert die Statistiken. Beobachte beim Anheben des Kompatibilitätsgrads Plan-Regressionen, die der neue Cardinality Estimator (CE) verursachen kann.

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

Prüfe nach einem Major-Upgrade, ob die FCV die Zielversion erreicht hat. Das Neuaufbauen von Indizes ist kein routinemäßiger Upgrade-Schritt; wird ein Index in den Release Notes genannt oder erzeugt er eine Warnung im Log, lege ihn mit dropIndex + createIndex neu an. Ab 6.0 funktioniert reIndex nur auf einem Standalone und ist auf Replica-Set-Mitgliedern nicht erlaubt.

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

Nach einem Redis-Upgrade gibt es keine Schema-Compile-/Analyze-Aufgabe; zu prüfen ist, ob die Replikation wiederhergestellt ist, die RDB-/AOF-Persistenz fehlerfrei läuft und die Schlüsselanzahl erhalten geblieben ist.

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

Prüfe nach dem Upgrade, ob der Clusterstatus 'green' ist und alle Shards zugewiesen sind. Indizes in einem Format, das älter als die vorherige Major-Version ist, sind in der neuen Version nicht lesbar und müssen daher mit _reindex in das aktuelle Format überführt werden.