Задачи после обновления (перекомпиляция/анализ)

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 перекомпилирует пакеты/представления/триггеры, ставшие INVALID после обновления. Последующий сбор статистики по словарю и фиксированным объектам позволяет оптимизатору строить корректные планы в новой версии.

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 и ранее) не переносит статистику планировщика; analyze-in-stages быстро делает систему работоспособной, собирая сначала грубую, затем полную статистику. Расширения нужно обновить через ALTER EXTENSION ... UPDATE, а индексы — через REINDEX, если изменилась 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)

В MySQL 8.0.16 и новее функция mysql_upgrade перенесена в сервер, поэтому отдельно не запускается. После обновления обновление статистики через ANALYZE TABLE на больших/критичных таблицах сохраняет качество планов.

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;

После обновления DBCC UPDATEUSAGE исправляет неточные счётчики пространства/строк, унаследованные от старых версий, а sp_updatestats обновляет статистику. При повышении уровня совместимости отслеживайте регрессии планов, которые может вызвать новый 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

После мажорного обновления убедитесь, что FCV достиг целевой версии. Перестроение индексов — не штатный шаг обновления; если индекс упомянут в release notes или вызывает предупреждение в журнале, пересоздайте его через dropIndex + createIndex. В 6.0+ reIndex работает только на standalone и запрещён на членах набора реплик.

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

После обновления Redis задач компиляции/анализа схемы нет; нужно убедиться, что репликация восстановлена, сохранение RDB/AOF в порядке и число ключей не изменилось.

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

После обновления убедитесь, что статус кластера 'green' и все шарды размещены. Индексы в формате старше предыдущей мажорной версии в новой версии не читаются, поэтому их нужно перенести в текущий формат через _reindex.