Abfrageplan hat sich verschlechtert (plötzlich langsam)

Eine Abfrage, die gestern schnell war, ist heute plötzlich langsam. Meist ist der Optimizer auf einen schlechteren Plan umgestiegen. Wir finden die Ursache zwischen veralteten Statistiken, Parameterempfindlichkeit, Datenwachstum oder einem plötzlichen Planwechsel und stabilisieren den Plan.

Hat sich der Plan wirklich geändert, und wann?

Gibt es für dieselbe Abfrage mehrere Pläne (plan_hash/plan_generation), und wann begann die Verlangsamung? Fällt sie mit einem kürzlichen Deploy, Upgrade, einer Parameteränderung oder einem großen Datenladevorgang zusammen?

SELECT sql_id, plan_hash_value, executions, ROUND(elapsed_time/GREATEST(executions,1)/1e6,3) AS sec_per_exec, first_load_time
FROM v$sql WHERE sql_id='&sqlid' ORDER BY first_load_time;

• Statistiken sind möglicherweise veraltet
• Dieselbe Abfrage verhält sich je nach Parameter anders (Sniffing/Peeking)
• Das Datenvolumen ist deutlich gewachsen
• Der Plan hat sich nach einem Upgrade/Flush plötzlich geändert

Sind die Statistiken aktuell?

Der Optimizer stützt seine Entscheidungen auf Statistiken. Ist das letzte Analyze-Datum alt oder der Änderungszähler hoch, können die Schätzungen tatsächlich abgedriftet sein, was zu einem schlechten Plan führt.

SELECT table_name, num_rows, last_analyzed, stale_stats
FROM dba_tab_statistics WHERE table_name='T';

• Statistiken sind veraltet/fehlen
• Statistiken sind aktuell, aber der Plan ist weiterhin parameterempfindlich

Gibt es eine Parameterempfindlichkeit?

Die Abfrage wählt und cacht einen Plan anhand des Parameterwerts ihrer ersten Ausführung (MSSQL Parameter Sniffing / Oracle Bind Peeking). Dieser Plan kann für andere Werte bei schiefer Verteilung schlecht sein.

SELECT sql_id, child_number, plan_hash_value, is_bind_sensitive, is_bind_aware
FROM v$sql WHERE sql_id='&sqlid';

• Ja, der Plan wechselt je nach Parameter zwischen gut und schlecht
• Der richtige Plan ist bekannt, ich will ihn dauerhaft fixieren

Ursache: veraltete / fehlende Statistiken

Auf Basis alter, nicht der Realität entsprechender Statistiken hat der Optimizer die Zeilenzahl falsch geschätzt und einen schlechten Plan gewählt. Das ist die häufigste Ursache für Planregressionen.

Ursache: Parameterempfindlichkeit (Sniffing / Bind Peeking)

Der gecachte Plan wurde für den zuerst eingetroffenen Parameterwert gewählt und ist für andere Werte bei schiefer Verteilung schlecht. Ziel ist sicherzustellen, dass ein zum Wert passender Plan gewählt wird.

Lösung: den richtigen Plan fixieren (Baseline / Force Plan)

Gibt es einen bekannten guten Plan, stoppt seine Fixierung — damit der Optimizer nicht davon abweicht — die Regression dauerhaft.

Ursache: Das Datenvolumen ist gewachsen, der Plan passt nicht mehr

Mit wachsender Tabelle skaliert ein früher idealer Plan (z. B. Nested Loop) nun schlecht; der Optimizer braucht Statistiken und Zugriffspfade, die das Wachstum korrekt abbilden.

Ursache: plötzlicher Planwechsel (Upgrade / Cache-Flush)

Der Plan hat sich nach einem Versionsupgrade, einer Parameteränderung oder dem Leeren des Plan-Cache plötzlich geändert. Das Verhalten des Optimizers oder die Umgebungsbedingungen haben sich verschoben.