Yükseltme sonrası görevler (recompile/analyze)
Oracle
-- 1) Geçersiz nesneleri paralel derle:
@?/rdbms/admin/utlrp.sql
-- 2) Sözlük/sabit nesne istatistiklerini yenile:
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
-- Kalan geçersizleri denetle:
SELECT owner, object_name, object_type FROM dba_objects WHERE status='INVALID';utlrp.sql yükseltme sonrası INVALID duruma düşen paket/view/trigger'ları yeniden derler. Ardından sözlük ve sabit nesne istatistiklerinin toplanması, yeni sürümde optimizer'ın sağlıklı plan üretmesini sağlar.
PostgreSQL
# 1) pg_upgrade sonrası istatistikleri yeniden topla (zorunlu):
$ vacuumdb --all --analyze-in-stages
-- 2) Uzantıları yeni sürüme çek:
ALTER EXTENSION postgis UPDATE;
-- 3) Collation değiştiyse metin indekslerini yeniden oluştur (uzun sürebilir):
REINDEX DATABASE veritabani_adi;pg_upgrade (PG17 ve öncesi) planlayıcı istatistiklerini taşımaz; analyze-in-stages önce kaba, sonra tam istatistik toplayarak sistemi hızla kullanılır hale getirir. Uzantılar ALTER EXTENSION ... UPDATE ile, collation değişmişse index'ler REINDEX ile yenilenmelidir.
MySQL
-- 8.0+ sözlük yükseltmesi başlangıçta otomatik yapılır; ek olarak:
ANALYZE TABLE musteri; -- kritik tabloların istatistiklerini yenile
-- Eski 5.7 -> ilk açılışta gerekiyorsa:
-- $ mysql_upgrade -u root -p (8.0.16 öncesi)MySQL 8.0.16 ve sonrasında mysql_upgrade işlevi sunucuya taşındığından ayrı çalıştırılmaz. Yükseltme sonrası büyük/kritik tablolarda ANALYZE TABLE ile istatistikleri yenilemek plan kalitesini korur.
SQL Server
-- 1) Sayfa/satır kullanım sayaçlarını düzelt:
DBCC UPDATEUSAGE(Satis);
-- 2) İstatistikleri yenile (sp_updatestats örnekleme kullanır; kritik tablolarda FULLSCAN):
EXEC sp_updatestats;
-- UPDATE STATISTICS dbo.KritikTablo WITH FULLSCAN;
-- 3) Uyumluluk seviyesini yeni sürüme yükselt (izlenerek):
ALTER DATABASE Satis SET COMPATIBILITY_LEVEL = 160;Yükseltme sonrası DBCC UPDATEUSAGE eski sürümlerden gelen hatalı alan/satır sayaçlarını düzeltir, sp_updatestats istatistikleri tazeler. Uyumluluk seviyesi yükseltilirken yeni Kardinalite Tahmincisi'nin (CE) yol açabileceği plan gerilemeleri izlenmelidir.
MongoDB
// 1) FCV yükseltmesini doğrula:
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
// 2) İndeksleri ve sunucu loglarındaki uyumluluk uyarılarını denetle:
db.musteri.getIndexes()
// Uyumsuz bir indeks varsa: dropIndex + createIndex (rolling); reIndex KULLANMAYINBüyük yükseltme sonrası FCV'nin hedeflenen sürüme çıktığı doğrulanır. Index'leri yeniden kurmak rutin bir yükseltme adımı değildir; sürüm notlarında belirtilen ya da logda uyarı veren bir index varsa dropIndex + createIndex ile yeniden oluşturulur. reIndex 6.0+ sürümlerde yalnızca standalone'da çalışır, replica set üyelerinde izin verilmez.
Redis
# Genelde ek görev gerekmez. Öneri: kalıcılığı ve replikasyonu doğrula:
redis-cli INFO replication # master/replica bağlantısı sağlıklı mı
redis-cli INFO persistence # rdb_last_bgsave_status / aof_last_bgrewrite_status
redis-cli DBSIZE # anahtar sayısı beklendiği gibi miRedis yükseltmesi sonrası şema derleme/analiz gibi bir görev yoktur; yapılacak iş replikasyonun yeniden kurulduğunu, RDB/AOF kalıcılığının sağlıklı olduğunu ve anahtar sayısının korunduğunu doğrulamaktır.
Elasticsearch
# Kümenin sağlığını doğrula:
GET _cluster/health
# Eski büyük sürümde oluşturulmuş, artık okunamayan indeksleri taşı:
POST _reindex
{ "source": { "index": "eski_index" }, "dest": { "index": "yeni_index" } }Yükseltme sonrası küme durumunun 'green' olduğu ve tüm shard'ların atandığı doğrulanır. Bir önceki büyük sürümden daha eski biçimdeki index'ler yeni sürümde okunamayacağından _reindex ile güncel biçime taşınmalıdır.