CASOS REALES: PROBLEMAS DE RENDIMIENTO DESPUÉS DE UN PARCHE EN ORACLE 19C

A continuación, veremos casos típicos de problemas de rendimiento después de aplicar un patch y cómo solucionarlos:
✅ Caso 1: Consultas más lentas después del parche
✅ Caso 2: Alto consumo de CPU después del patching
✅ Caso 3: Contención en bloqueos después del parche
✅ Caso 4: Problemas con el Plan de Ejecución (SQL Plan Baseline afectado)
✅ Caso 5: Problemas de I/O después de un parche en Oracle ASM

CASO 1: Consultas más lentas después del parche

Escenario:

Después de aplicar un parche de seguridad en Oracle 19c (Patch 33828591), algunas consultas clave que antes tardaban 2 segundos, ahora tardan 20 segundos o más.

Diagnóstico: Verificar el historial de ejecución

Identificar la consulta afectada usando V$SQL

SELECT SQL_ID, EXECUTIONS, ELAPSED_TIME/EXECUTIONS AS AVG_ELAPSED_TIME
FROM V$SQL
WHERE SQL_TEXT LIKE '%FROM EMPLOYEES%'
ORDER BY ELAPSED_TIME DESC;

Salida antes del patch:

Salida después del patch:

Solución: Forzar un nuevo cálculo de estadísticas

BEGIN
   DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => 'HR', TABNAME => 'EMPLOYEES');
END;
/

Verificar nuevamente el tiempo de ejecución.
Si sigue lento, forzar un nuevo plan de ejecución:

ALTER SYSTEM FLUSH SHARED_POOL;

CASO 2: Alto consumo de CPU después del patching

Escenario:

Después de aplicar el parche Patch 33568938, el uso de CPU en el servidor aumentó del 30% al 90%, afectando el rendimiento de la base de datos.

Diagnóstico: Ver qué procesos consumen más CPU

SELECT SID, SERIAL#, SQL_ID, SQL_TEXT
FROM V$SESSION
WHERE STATUS = 'ACTIVE'
AND USERNAME IS NOT NULL
AND SID IN (SELECT SID FROM V$SESSTAT WHERE STATISTIC# = (SELECT STATISTIC# FROM V$STATNAME WHERE NAME='CPU used by this session'))
ORDER BY SID;

Salida:

Solución: Identificar el SQL y optimizarlo

Obtener el plan de ejecución

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('4df9a2j8', NULL, 'ALLSTATS LAST'));

Si se observa un Full Table Scan inesperado, crear un índice o recomputar estadísticas

CREATE INDEX IDX_LARGE_TABLE ON LARGE_TABLE(COLUMN_A);

CASO 3: Contención en bloqueos después del parche

Escenario:

Después de un parche de seguridad, varias sesiones quedan bloqueadas en espera de recursos.

Diagnóstico: Identificar bloqueos activos

SELECT blocking_session, sid, serial#, wait_class, seconds_in_wait
FROM V$SESSION
WHERE blocking_session IS NOT NULL;

Salida:

Solución: Verificar qué SQL está causando el bloqueo y actuar

Identificar el SQL bloqueante

SELECT SQL_TEXT FROM V$SQL WHERE SQL_ID = (SELECT SQL_ID FROM V$SESSION WHERE SID = 123);

Si es seguro, matar la sesión bloqueante

ALTER SYSTEM KILL SESSION '123,45678' IMMEDIATE;

CASO 4: Problemas con SQL Plan Baseline después del parche

Escenario:

Después del parche, una consulta dejó de usar un índice y comenzó a hacer un Full Table Scan, causando lentitud.

Diagnóstico: Revisar el plan de ejecución antes y después

SELECT * FROM DBA_HIST_SQL_PLAN
WHERE SQL_ID = '4df9a2j8'
AND OBJECT_NAME IS NOT NULL;

Salida antes del parche:

Salida después del parche:

Solución: Forzar el plan anterior

BEGIN
   DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(sql_id => '4df9a2j8');
END;
/

CASO 5: Problemas de I/O después de un parche en Oracle ASM

Escenario:

Después de aplicar el parche Patch 32842214, se observa un alto tiempo de espera en I/O.

Diagnóstico: Revisar tiempos de espera en I/O

SELECT EVENT, TOTAL_WAITS, TIME_WAITED/100 AS AVG_WAIT_TIME_MS
FROM V$SYSTEM_EVENT
WHERE EVENT LIKE 'db file%read%'
ORDER BY AVG_WAIT_TIME_MS DESC;

Salida:

Antes del parche, el tiempo era 2-3 ms.

Solución: Verificar configuración de ASM y reubicar datos

Ver qué discos están siendo más utilizados

SELECT GROUP_NUMBER, DISK_NUMBER, TOTAL_MB, FREE_MB
FROM V$ASM_DISK;

Rebalancear los discos

ALTER DISKGROUP DATA REBALANCE POWER 10;

Si es un problema de latencia, habilitar Adaptive I/O

ALTER SYSTEM SET DBWR_ADAPTIVE_FLUSHING=TRUE;

De Males y Maleficios para el DBA