Hohe CPU
Die Server-CPU ist am Anschlag. Prüfe zuerst, ob wirklich die Datenbank sie verbraucht, und folge dann den Zweigen zur Ursache: schlecht geplante Abfragen, eine Planregression, übermäßige Parallelität oder ein Prozess außerhalb der DB.
Verbraucht wirklich die Datenbank die CPU?
Prüfe auf Betriebssystemseite, welcher Prozess CPU verbrennt. Liegt der Großteil der Last in DB-Prozessen oder in einem benachbarten Prozess (Backup, Antivirus, eine andere Anwendung)? Das teilt die Untersuchung in zwei Zweige.
-- OS side: top -o %CPU (or: top -c)
-- DB-side verification:
SELECT ROUND(value,1) AS host_cpu_util_pct FROM v$sysmetric WHERE metric_name='Host CPU Utilization (%)' AND rownum=1;- Ja, DB-Prozesse verbrauchen die CPU
- Nein, ein benachbarter Prozess / Backup-Job verbraucht sie
Wie ist die Last aufgetreten?
Verbraucht die DB die CPU, das Muster bestimmen: Dominieren einige schwere Abfragen, begann das Problem plötzlich nach einer Änderung, oder gibt es hohe Parallelität/Verbindungs-Contention?
- Einige schwere Abfragen verbrennen die CPU
- Plötzlich begonnen; es gab kürzlich ein Deployment / eine Parameteränderung
- Viele Verbindungen / Contention durch Parallelität
Die Abfragen mit dem höchsten CPU-Verbrauch finden
Die Top-Abfragen nach gesamtem CPU-Verbrauch abrufen. Dann entscheiden, ob jede pro Aufruf schwer ist (schlechter Plan) oder pro Aufruf günstig, aber sehr häufig aufgerufen.
SELECT sql_id, executions, ROUND(cpu_time/1e6,1) AS cpu_sec, ROUND(cpu_time/GREATEST(executions,1)/1000,2) AS cpu_ms_per_exec, sql_text
FROM v$sql ORDER BY cpu_time DESC FETCH FIRST 10 ROWS ONLY;- Schwer pro Aufruf; schlechter Plan / Full Scan
- Günstig pro Aufruf, aber sehr häufig aufgerufen
Ursache: Schlecht geplante Abfragen verbrennen CPU
Einige Abfragen verbrauchen pro Aufruf übermäßig CPU wegen Full Scans oder einer schlechten Join-Reihenfolge. Das Korrigieren ihrer Pläne ist die Kernlösung.
Ursache: Übermäßige Aufrufhäufigkeit
Die Abfragen sind einzeln günstig, werden aber tausendfach pro Sekunde aufgerufen; daher kommen die gesamten CPU-Kosten. Meist ein N+1-Muster oder ein nicht gecachter Hot Path.
Ursache: Planregression / veraltete Statistiken
Gestern war das System normal; nach einem Deployment, einer Parameteränderung oder einem Datenladevorgang ist die CPU sprunghaft gestiegen. Der Optimizer hat eventuell auf einen schlechteren Plan gewechselt.
Ursache: Hohe Parallelität / Verbindungs-Contention
Die einzelnen Abfragen sind akzeptabel, aber zu viele Sessions laufen gleichzeitig; mehr aktive Sessions als CPU-Kerne verursachen Kontextwechsel und Latch-/Spin-Contention.
Ursache: Ein Prozess außerhalb der DB verbraucht CPU
Nicht die Datenbank, sondern ein benachbarter Prozess verbraucht die CPU: ein Backup-/Kompressionsjob, ein Antivirus-Scan, ein Log Shipper oder eine andere Anwendung auf derselben Maschine.