Druck auf Undo / TempDB / temporären Speicher

Undo-/Rollback-Bereich, temporärer Speicher (temp) oder TempDB stehen unter Druck. Wir bestimmen, wo der Druck liegt, und arbeiten uns zur Ursache vor, etwa ein großer Sort/Hash, eine lange Abfrage/Transaktion oder ein Speicherleck.

Wo liegt der Druck: Undo, Temp oder TempDB-Konkurrenz?

Klassifiziere die Quelle des Drucks anhand der Speichernutzung: Läuft der Undo-/Rollback-Tablespace voll, der allgemeine temporäre Speicher (temp), oder ist es in MSSQL eine Latch-Konkurrenz bei der Seitenzuweisung in TempDB?

SELECT tablespace_name, ROUND(used_percent,1) AS used_pct
FROM dba_tablespace_usage_metrics
WHERE tablespace_name LIKE '%UNDO%' OR tablespace_name LIKE 'TEMP%';

• Undo-/Rollback-Bereich läuft voll (ORA-01555 / ORA-30036)
• Temporärer Speicher (temp) läuft voll (Sort-/Hash-Auslagerung)
• Latch-Konkurrenz bei der TempDB-Zuweisung (PFS/GAM/SGAM)

Was verbraucht Undo?

Undo-Druck ist typischerweise eine von zwei Arten: Eine lange ABFRAGE braucht alten Undo für das konsistente Lesen zu ihrem Startzeitpunkt (ORA-01555), oder eine lange/offene TRANSAKTION erzeugt so viel Undo, dass der Bereich vollläuft und es zu ORA-30036 kommt.

SELECT s.sid, s.username, t.used_ublk*8/1024 AS undo_mb, s.status, t.start_time
FROM v$transaction t JOIN v$session s ON s.taddr=t.addr
ORDER BY undo_mb DESC;
SELECT MAX(maxquerylen) AS longest_query_sec, MAX(tuned_undoretention) AS tuned_retention FROM v$undostat;

• Eine lange Abfrage braucht alten Undo (ORA-01555)
• Eine lange/offene Transaktion häuft Undo an (ORA-30036)

Was füllt den temporären Speicher?

Temp-Druck entsteht entweder durch eine große Sort-/Hash-Operation, die auf die Disk ausgelagert wird (normal, aber riesig), oder durch eine einzelne Session, die dauerhaft Temp belegt (offener Cursor, Leck, endlose Abfrage).

SELECT s.sid, s.username, u.tablespace, u.blocks*8/1024 AS temp_mb, u.sqladdr
FROM v$tempseg_usage u JOIN v$session s ON s.saddr=u.session_addr
ORDER BY temp_mb DESC;

• Eine große Sort-/Hash-Operation wird auf die Disk ausgelagert
• Eine einzelne Session belegt Temp (Leck/offener Cursor)

Geht es bei der TempDB-Konkurrenz um Zuweisung oder Volumen?

In MSSQL TempDB treten zwei verschiedene Probleme auf: PAGELATCH-Konkurrenz auf PFS-/GAM-/SGAM-Seiten (viele kleine temporäre Objekte) oder ein großer Sort/Version Store, der TempDB volumenmäßig füllt.

SELECT session_id, wait_type, wait_duration_ms, resource_description
FROM sys.dm_os_waiting_tasks
WHERE wait_type LIKE 'PAGELATCH%' AND resource_description LIKE '2:%';
SELECT COUNT(*) AS tempdb_data_files FROM sys.master_files WHERE database_id=2 AND type=0;

• PFS-/GAM-/SGAM-Latch-Konkurrenz
• Ein großer Sort/Version Store füllt TempDB

Ursache: lange Abfrage + zu wenig Undo (ORA-01555)

Der alte Undo, den die lange Abfrage für ein konsistentes Lesen braucht, wurde überschrieben, weil die Retention abgelaufen war oder der Platz nicht reichte.

Ursache: Eine lange/offene Transaktion hat den Undo gefüllt (ORA-30036)

Eine einzelne riesige DML oder eine offene Transaktion mit verzögertem Commit hat zu viel Undo erzeugt; der UNDO-Tablespace konnte nicht wachsen und ORA-30036 wurde ausgelöst.

Ursache: Ein großer Sort/Hash füllt den temporären Speicher

Große Sort-/Hash-/Group-by-Operationen, die nicht in den Speicher passen, werden in den temporären Speicher ausgelagert und können ihn füllen.

Ursache: Eine Session belegt temporären Speicher (Leck)

Eine einzelne Session gibt temporären Speicher wegen nicht geschlossener Cursor, einer endlosen Abfrage oder offener temporärer Tabellen nicht frei.

Ursache: TempDB-PFS-/GAM-/SGAM-Latch-Konkurrenz

Wenn viele Sessions gleichzeitig kleine temporäre Objekte anlegen, entsteht PAGELATCH-Konkurrenz auf den Allocation-Map-Seiten von TempDB (PFS/GAM/SGAM).