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.