Presión en undo / TempDB / espacio temporal

El espacio de undo/rollback, el espacio temporal (temp) o TempDB está bajo presión. Determinamos dónde está la presión y profundizamos hasta la causa raíz, como una ordenación/hash grande, una consulta/transacción larga o una fuga de espacio.

¿Dónde está la presión: undo, temp o contención en tempdb?

Clasifique el origen de la presión observando el uso del espacio: ¿se está llenando el tablespace de undo/rollback, el espacio temporal (temp) general o, en MSSQL, se trata de contención de latches en la asignación de páginas de 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%';

• El espacio de undo/rollback se está llenando (ORA-01555 / ORA-30036)
• El espacio temporal (temp) se está llenando (desbordamiento de sort/hash)
• Contención de latches de asignación en TempDB (PFS/GAM/SGAM)

¿Qué está consumiendo el undo?

La presión de undo suele ser de uno de dos tipos: una CONSULTA larga necesita undo antiguo para la lectura consistente a partir de su hora de inicio (ORA-01555), o una TRANSACCIÓN larga/abierta genera tanto undo que llena el espacio y provoca ORA-30036.

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;

• Una consulta larga necesita undo antiguo (ORA-01555)
• Una transacción larga/abierta está acumulando undo (ORA-30036)

¿Qué está llenando el espacio temporal?

La presión de temp proviene de una gran operación de sort/hash que se desborda a disco (normal pero enorme) o de una sola sesión que retiene temp de forma continua (cursor abierto, fuga, consulta interminable).

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;

• Una gran operación de sort/hash se desborda a disco
• Una sola sesión retiene temp (fuga/cursor abierto)

¿La contención en TempDB es de asignación o de volumen?

En MSSQL TempDB se dan dos problemas distintos: contención PAGELATCH en las páginas PFS/GAM/SGAM (muchos objetos temporales pequeños), o una gran ordenación/version store que llena TempDB por volumen.

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;

• Contención de latches PFS/GAM/SGAM
• Una gran ordenación/version store está llenando TempDB

Causa raíz: consulta larga + undo insuficiente (ORA-01555)

El undo antiguo que la consulta larga necesita para una lectura consistente se sobrescribió porque expiró la retención o el espacio era insuficiente.

Causa raíz: una transacción larga/abierta llenó el undo (ORA-30036)

Un único DML enorme o una transacción abierta con un commit retrasado generó demasiado undo; el tablespace UNDO no pudo extenderse y se produjo ORA-30036.

Causa raíz: una ordenación/hash grande está llenando el espacio temporal

Las grandes operaciones de sort/hash/group by que no caben en memoria se desbordan al espacio temporal y pueden llenarlo.

Causa raíz: una sesión retiene espacio temporal (fuga)

Una sola sesión no libera el espacio temporal por cursores sin cerrar, una consulta interminable o tablas temporales abiertas.

Causa raíz: contención de latches PFS/GAM/SGAM en TempDB

Cuando muchas sesiones crean objetos temporales pequeños al mismo tiempo, surge contención PAGELATCH en las páginas del mapa de asignación de TempDB (PFS/GAM/SGAM).