dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #38
oracle
AvailabilitySEV1 · KRİTİK KESİNTİ15-30 dakika / 15-30 minsSYSDBA / DBA / SELECT_CATALOG_ROLE

Oracle ORA-00020: Process Sınırı Dolduğunda Acil Müdahale

Processes sınırı dolduğunda sorumlu oturumları bulur, bağlantıları kontrollü azaltır ve yeniden başlatma gerektiren kalıcı kapasite ayarını planlar.

İlişkili Metrik:M37
İlişkili Script:S80S61
#ora-00020#processes#sessions#connection-pool#rac

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

- `ORA-00020: maximum number of processes exceeded` ve başarısız yeni bağlantılar; M37 kritik.

- Uygulama bağlantı havuzları zaman aşımına uğrar. Listener ve alert log'da bağlantı hataları görülebilir.

2. Etki / Impact

Yeni dedicated-server süreçleri oluşturulamaz; mevcut işlemler sürse de yeni iş yükü kabul edilemez. RAC'te sorun instance bazlıdır ve servis yönlendirmesini etkileyebilir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. Varsa açık bir DBA oturumunu kullanın; **yeni SYSDBA bağlantısının mutlaka başarılı olacağını varsaymayın**. Bağlanamazsanız OS'de süreçleri ve alert log'u inceleyin, yetkisiz `kill -9` yapmayın.
🟢 Salt Okunur2. S80 ile instance başına mevcut/zirve/sınır değerlerini ve S61 ile oturumları görün:
sql
SELECT inst_id, resource_name, current_utilization, max_utilization, limit_value
FROM gv$resource_limit
WHERE resource_name IN ('processes','sessions')
ORDER BY inst_id, resource_name;

SELECT inst_id, username, machine, program, status, COUNT(*) AS sessions
FROM gv$session
WHERE type = 'USER'
GROUP BY inst_id, username, machine, program, status
ORDER BY sessions DESC FETCH FIRST 30 ROWS ONLY;
🟢 Salt Okunur3. Belirgin tek bir uygulama/host'tan aşırı sayıda `INACTIVE` oturum mu var, yoksa aktif sorgular mı yığılıyor? `gv$session` oturum sayısı ile `gv$process` süreç sayısını karıştırmayın; arka plan süreçleri de `processes` kotasına dahildir.

4. Müdahale / Response

🟡 Geri Alınabilir1. Bağlantı açan uygulamanın havuzunda yeni bağlantı oluşturmayı durdurun veya havuz sınırını düşürün. Sorgu darboğazı varsa `oracle-high-db-time` runbook'una geçin.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ2. Yalnızca sahibi ve iş kritikliğini doğruladığınız **eski, etkin olmayan** oturumları tek tek sonlandırın. Önce adayları listeleyin; örnekteki kimlikleri gerçek sonuçlarla değiştirin:
sql
SELECT inst_id, sid, serial#, username, machine, last_call_et
FROM gv$session
WHERE type='USER' AND status='INACTIVE' AND last_call_et > 1800
ORDER BY last_call_et DESC;

-- Tek instance: ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;
-- RAC: ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id' IMMEDIATE;

Büyük açık transaction'ın rollback'i uzun sürebilir; **tüm INACTIVE oturumları körlemesine öldürmeyin**.

🔴 YÜKSEK RİSK / GERİ ALINAMAZ3. Sınır iş yüküne kalıcı olarak yetmiyorsa, bellek/OS süreç kapasitesi ve `sessions` etkisini hesaplayıp değişikliği bakım penceresinde uygulayın:
sql
ALTER SYSTEM SET processes=1200 SCOPE=SPFILE;
-- Etkinleşmesi için ilgili instance yeniden başlatılmalıdır; RAC'te her instance'ı ayrı değerlendirin.

12c/19c CDB ortamında `processes` instance parametresidir; PDB içinden değiştirmeyin.

5. Doğrulama / Verification

- M37 eşik altına indi, yeni uygulama bağlantıları açılıyor; `gv$resource_limit` tekrar tırmanmıyor.

- Kaynak uygulamadaki havuz limiti ve kapanmayan bağlantı hatası düzeltildi; alert log'da yeni ORA-00020 yok.

6. Geri Alma / Rollback

- Sonlandırılan oturumlar geri gelmez, açık işlemleri rollback olur ve uygulama yeniden denemelidir.

- `SCOPE=SPFILE` ile değişen değer henüz etkin değilse önceki değeri `SCOPE=SPFILE` ile yazın; yeniden başladıysa eski değere dönüş için tekrar restart gerekir. Yeni sınırı doğrulamadan uygulama havuzunu eski seviyeye çıkarmayın.

Diğer ORACLE Runbook'ları