アップグレード後のタスク(再コンパイル/統計)

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 する必要がある。

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 はスタンドアロンでのみ動作し、レプリカセットのメンバーでは使用できない。

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 で現在の形式に移行する必要がある。

DBAtlas で開く →