Sorgu planı bozuldu (aniden yavaşladı)
Dün hızlı olan bir sorgu bugün aniden yavaşladı. Genelde optimizer daha kötü bir plana geçmiştir. Bayat istatistik, parametre duyarlılığı, veri hacmi artışı veya ani plan değişimi arasından kök nedeni bulup planı stabilize ediyoruz.
Plan gerçekten değişti mi, ne zaman?
Aynı sorgu için birden fazla plan (plan_hash/plan_generation) var mı ve yavaşlama ne zaman başladı? Son deploy, upgrade, parametre değişimi ya da büyük veri yüklemesiyle örtüşüyor mu?
SELECT sql_id, plan_hash_value, executions, ROUND(elapsed_time/GREATEST(executions,1)/1e6,3) AS sec_per_exec, first_load_time
FROM v$sql WHERE sql_id='&sqlid' ORDER BY first_load_time;- İstatistikler bayat olabilir
- Aynı sorgu parametreye göre farklı davranıyor (sniffing/peeking)
- Veri hacmi belirgin biçimde arttı
- Plan bir upgrade/flush sonrası aniden değişti
İstatistikler güncel mi?
Optimizer kararlarını istatistiklere dayanarak verir. Son analiz tarihi eski ya da değişiklik sayacı yüksekse tahminler gerçekten sapmış olabilir; bu da kötü plana yol açar.
SELECT table_name, num_rows, last_analyzed, stale_stats
FROM dba_tab_statistics WHERE table_name='T';- İstatistik bayat/eksik
- İstatistik güncel ama plan yine parametreye duyarlı
Parametre duyarlılığı var mı?
Sorgu ilk çalıştırıldığındaki parametre değerine göre bir plan seçip önbelleğe alıyor (MSSQL parameter sniffing / Oracle bind peeking). O plan, çarpık dağılımlı başka değerler için kötü olabiliyor.
SELECT sql_id, child_number, plan_hash_value, is_bind_sensitive, is_bind_aware
FROM v$sql WHERE sql_id='&sqlid';- Evet, parametreye göre plan iyi/kötü değişiyor
- Doğru plan belli, kalıcı olarak sabitlemek istiyorum
Kök neden: Bayat / eksik istatistik
Optimizer, gerçekle uyuşmayan eski istatistiklere göre satır sayısını yanlış tahmin edip kötü plan seçti. En sık görülen plan regresyonu nedenidir.
Kök neden: Parametre duyarlılığı (sniffing / bind peeking)
Önbelleğe alınan plan, ilk gelen parametre değerine göre seçildi ve çarpık dağılımlı diğer değerler için kötü. Amaç, değere uygun planın seçilmesini sağlamak.
Çözüm: Doğru planı sabitle (baseline / force plan)
Bilinen iyi plan mevcutsa optimizer'ın ondan sapmaması için planı sabitlemek regresyonu kalıcı olarak durdurur.
Kök neden: Veri hacmi arttı, plan artık uygun değil
Tablo büyüdükçe eskiden ideal olan plan (ör. nested loop) artık kötü ölçekleniyor; optimizer büyümeyi doğru yansıtan istatistik ve erişim yollarına ihtiyaç duyuyor.
Kök neden: Ani plan değişimi (upgrade / cache flush)
Plan bir sürüm yükseltmesi, parametre değişikliği ya da plan önbelleğinin boşalması sonrası aniden değişti. Optimizer davranışı ya da ortam koşulları kaymış.