Oracle Yüksek DB Time ve AAS: Yavaşlık İçin Sorgu ve Bekleme Triyajı
Yüksek aktif oturum sayısını CPU, I/O, kilit ve ağ beklemelerine ayırır; pahalı SQL'i bulup güvenli iyileştirme planı oluşturur.
Operasyonel Güvenlik ve Risk Uyarısı
Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.
1. Belirti / Symptom
- M40 (AAS) iş yükü baseline'ının ve CPU kapasitesinin üstünde; kullanıcı işlemleri yavaş.
- M48 buffer cache hit oranı düşebilir, ancak **tek başına** kök neden kanıtı değildir.
2. Etki / Impact
İşlemler uzar, oturumlar yığılır, bağlantı ve uygulama zaman aşımı oluşabilir.
3. Teşhis / Diagnosis
SELECT inst_id,
CASE WHEN state='WAITING' THEN wait_class ELSE 'ON CPU' END AS activity,
COUNT(*) AS sessions
FROM gv$session
WHERE type='USER' AND status='ACTIVE'
GROUP BY inst_id, CASE WHEN state='WAITING' THEN wait_class ELSE 'ON CPU' END
ORDER BY sessions DESC;
SELECT inst_id, sid, serial#, sql_id, event, wait_class, state, blocking_session
FROM gv$session
WHERE type='USER' AND status='ACTIVE'
ORDER BY inst_id, sid FETCH FIRST 30 ROWS ONLY;4. Müdahale / Response
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'APP', tabname=>'ORDERS', cascade=>TRUE);4. 19c'de SQL plan değişikliklerini dikkatle inceleyin; farklı PDB'lerin aynı instance kaynaklarını paylaşabileceğini unutmayın. 12c/19c çok kiracılı sistemlerde `CON_ID` ile sorumlu PDB'yi ayırın.
5. Doğrulama / Verification
- AAS, CPU ve gecikme baseline'a döndü; M40 normale indi, M48 tek başına başarı ölçütü yapılmadı.
- En pahalı SQL'in elapsed/CPU ve bekleme sınıfında düzelme var; uygulama hata oranı azaldı.
6. Geri Alma / Rollback
- Toplu iş yavaşlatması geri açılabilir, ancak tamamlanmamış işler uygulamada yeniden planlanmalıdır.
- `DBMS_STATS` öncesi istatistikler önceden yedeklenmediyse otomatik ve güvenilir geri alma yoktur; planları eski/yeni şekilde test ederek yönetin. Sonlandırılan işlem yeniden denenmelidir.