업그레이드 후 작업(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은 업그레이드 후 INVALID가 된 패키지/뷰/트리거를 재컴파일한다. 이후 딕셔너리 및 fixed object 통계를 수집하면 옵티마이저가 새 버전에서 올바른 실행 계획을 생성한다.

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로, collation이 바뀐 경우 인덱스는 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)

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가 목표 버전에 도달했는지 확인한다. 인덱스 재구축은 일상적인 업그레이드 단계가 아니다. 릴리스 노트에 언급되었거나 로그에 경고를 남기는 인덱스는 dropIndex + createIndex로 다시 생성한다. 6.0+에서 reIndex는 standalone에서만 동작하며 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

Redis 업그레이드 후에는 스키마 compile/analyze 작업이 없다. 복제가 다시 수립되었는지, 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로 현재 형식으로 옮겨야 한다.