dataiotech Labs
Runbook #45
oracle
PerformanceSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minsSYSDBA / DBA / SELECT_CATALOG_ROLE

Oracle Hard Parse Artışı ve Shared Pool Baskısı: Kök Neden

Hard parse oranını ve cursor çoğalmasını ölçerek bind variable, plan değişimi ve istatistik sorunlarını ayırır; shared pool'u boşaltmadan çözüm üretir.

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.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- M46 hard parse oranı baseline üstünde; CPU ve `library cache: mutex X`, `cursor: pin S wait on X` gibi beklemeler artabilir.

- Aynı sorgunun farklı literal değerlerle çok sayıda benzeri bulunur.

2. Etki / Impact

CPU parse işlemine harcanır, eşzamanlılık ve yanıt süreleri bozulur; shared pool alanı verimsiz kullanılır.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. Tek anlık toplam sayı yerine iki örnek arasında **delta** alın:
sql
SELECT name, value FROM v$sysstat
WHERE name IN ('parse count (hard)','parse count (total)','execute count')
ORDER BY name;
🟢 Salt Okunur2. S64 ile yüksek parse/versiyon sayılı SQL'leri bulun:
sql
SELECT * FROM (
  SELECT sql_id, executions, parse_calls, version_count,
         SUBSTR(sql_text,1,120) AS sql_text
  FROM v$sqlarea
  WHERE parse_calls > 100
  ORDER BY parse_calls DESC
) WHERE ROWNUM <= 20;
🟢 Salt Okunur3. S75 ile shared pool/SGA belleğini, S70 ile istatistikleri kontrol edin. `version_count` yüksekse bind değişken tipi, optimizer ortamı veya invalidation nedenlerini inceleyin.
🟢 Salt Okunur4. AWR/ASH kullanımı Diagnostics Pack lisansı gerektirir; lisans yoksa `v$sysstat`, `v$sqlarea`, `v$session`, `v$sgainfo` üzerinden devam edin. 12c/19c CDB/PDB'de SQL_ID ve `CON_ID` bağlamını ayırın.

4. Müdahale / Response

🟡 Geri Alınabilir1. Uygulama sorgularını **bind variable** kullanacak biçimde düzeltin; SQL metnini değiştiren gereksiz literal üretimini önleyin. Sürücü cursor/statement cache ayarını gözden geçirin.
🟡 Geri Alınabilir2. İstatistik gerçekten eskiyse hedef tabloya ait istatistiği planlı biçimde güncelleyin; değişiklik plan regresyonu yaratabilir (S70).
🟡 Geri Alınabilir3. `SESSION_CACHED_CURSORS` gibi ayarları ancak parse profilini ve bellek etkisini ölçerek değiştirin.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. **`ALTER SYSTEM FLUSH SHARED_POOL` uygulamayın:** tüm planları atar, hard parse fırtınasını büyütür. `CURSOR_SHARING=FORCE` kalıcı birinci çözüm değil; literal önlenemeyen uygulamalarda yan etkiler test edilerek geçici olarak değerlendirilebilir.

5. Doğrulama / Verification

- İki ölçüm arası hard parse / toplam parse oranı baseline'a döndü; CPU ve library cache beklemeleri azaldı, M46 düzeldi.

- Sorgu yanıt süresi iyileşti, plan regresyonu yok.

6. Geri Alma / Rollback

- Uygulama bind değişikliği önceki sürüme döndürülür; `SESSION_CACHED_CURSORS` eski değere alınır.

- İstatistik değişiklikleri için önceki istatistikleri yedeklemeden otomatik geri alma varsaymayın; eski/yeni planları karşılaştırın.

Mühendislik Triadı: Doğrudan Teşhis Scriptleri

Bu runbook kriz müdahalesinde darboğazı tespit etmek için önerilen hazır SQL / Shell scriptleri:

Tüm Scriptler (100)
#64 · SQLPerformance

Oracle En Pahalı SQL'ler: v$sqlstats ile Top 20

Geçen süreye göre en maliyetli SQL'leri çalışma sayısı, CPU ve I/O ile gösterir. Ayar için hangi SQL_ID'nin inceleneceğini belirler.

#70 · SQLMaintenance

Oracle'da Eski (Stale) Optimizer İstatistikleri

İstatistiği eski veya hiç toplanmamış tabloları bulur. Kötü execution plan'ların en yaygın sebebini yakalar.

#75 · SQLMonitoring

Oracle SGA ve PGA Bellek Kullanımı

SGA bileşenlerini ve PGA hedefi ile gerçek kullanımı gösterir. Bellek boyutlandırma kararlarının ilk verisidir.

Tetikleyen Alarmlar ve Metrikler
M46Oracle Hard Parse OranıOracle

Diğer ORACLE Runbook'ları