Restablecer la contraseña de un usuario expirado sin conocer la clave actual en Oracle 12c / 19c

Restablecer la contraseña de un usuario expirado sin conocer la clave actual en Oracle 12c / 19c

   julio 20, 2026       Luis Felipe

---

En la administración diaria de bases de datos Oracle, es habitual encontrarnos con un escenario crítico: una cuenta de usuario (ya sea de aplicación, de servicio o de integración) pasa a estado EXPIRED debido a las políticas del perfil de seguridad asignado.

El verdadero problema surge cuando nadie recuerda la contraseña original. Si la cambiamos por una clave completamente nueva, interrumpiremos de inmediato el servicio de las aplicaciones o sistemas dependientes hasta que sus cadenas de conexión sean actualizadas, algo que no siempre es posible realizar de manera inmediata en entornos de producción.

Para resolver esta contingencia sin alterar la contraseña real y ganar tiempo para gestionar el cambio formal, podemos "refrescar" el estado de la cuenta (recomponiendo su estatus a OPEN) reasignando su mismo hash almacenado en el diccionario de datos.

En versiones antiguas de Oracle (10g / 11g), solía extraerse la columna PASSWORD de la tabla sys.user$. Sin embargo, a partir de Oracle 12c, 19c y versiones superiores, el motor utiliza algoritmos de cifrado más avanzados (SHA-2). Por ello, el hash activo para la autenticación se almacena en la columna SPARE4.

A continuación, se detalla el procedimiento paso a paso para realizar esta acción de contingencia en cualquier usuario de la base de datos.

Si estás trabajando en entornos Oracle 12c, 19c o superiores bajo la arquitectura Multitenant, recuerda que antes de ejecutar este procedimiento debes asegurarte de estar conectado en el contenedor correcto:

• Si el usuario afectado es un Common User (ej. C##APP_USER), deberás ejecutarlo desde el CDB$ROOT.

• Si es un usuario local de una aplicación, debes moverte primero a su PDB correspondiente: ALTER SESSION SET CONTAINER = mi_pdb;

Antes de realizar cualquier ajuste, confirmamos el estado de la cuenta y el perfil asociado consultando la vista DBA_USERS:

SELECT username, account_status, profile, expiry_date FROM dba_users WHERE username = 'USUARIO';

Para evitar el error ORA-28007: the password cannot be reused, debemos verificar si el perfil asignado permite la reasignación de la misma clave. Consultamos DBA_PROFILES:

SELECT resource_name, limit FROM dba_profiles WHERE profile = (SELECT profile FROM dba_users WHERE username = 'USUARIO') AND resource_name IN ('PASSWORD_REUSE_TIME', 'PASSWORD_REUSE_MAX');

• Si ambos valores son UNLIMITED: Se puede avanzar al siguiente paso.
• Si tienen un límite numérico restrictivo: Se pueden modificar temporalmente los parámetros del perfil antes de ejecutar el cambio, para este caso en particular tenia asignado el perfil "default":

ALTER PROFILE DEFAULT LIMIT PASSWORD_REUSE_TIME UNLIMITED PASSWORD_REUSE_MAX UNLIMITED;

Nota: Si tu usuario tiene un perfil personalizado, reemplaza DEFAULT por el nombre de su perfil para no alterar las políticas globales de la base de datos.

Consultamos la tabla interna sys.user$ filtrando por el nombre del usuario afectado:

SELECT spare4 FROM sys.user$ WHERE name = 'USUARIO';

La consulta devolverá la cadena alfanumérica completa correspondiente al hash de autenticación: 

Es importante copiar la cadena devuelta por SPARE4 en su totalidad (incluyendo prefijos como S: o T:), ya que especifica el tipo de algoritmo de cifrado empleado por la versión de la base de datos.

Ejecutamos la sentencia ALTER USER utilizando la cláusula IDENTIFIED BY VALUES. Esta sintaxis le indica a Oracle que registre directamente la clave procesada sin aplicar una nueva función de hashing sobre la cadena:

ALTER USER USUARIO IDENTIFIED BY VALUES 'S:A8B9C0D1E2F3...[HASH_COMPLETO_AQUÍ]...';

Nota: Si la cuenta también se encontraba bloqueada (LOCKED), se puede incluir la cláusula ACCOUNT UNLOCK en la misma sentencia

Con esto, el motor revalida el hash, calcula la nueva fecha de vencimiento según el perfil y cambia el estado de la cuenta a OPEN.




Validamos nuevamente la vista DBA_USERS para verificar que el procedimiento se haya completado exitosamente:

SELECT username, account_status, expiry_date FROM dba_users WHERE username = 'USUARIO';

El estado cambiará a OPEN y la columna EXPIRY_DATE reflejará la nueva fecha de vencimiento.

Si en los pasos anteriores modificaste los parámetros de reutilización de contraseña, no olvides regresar el perfil a sus valores originales para mantener el estándar de seguridad de la organización:

ALTER PROFILE DEFAULT LIMIT PASSWORD_REUSE_TIME 365 PASSWORD_REUSE_MAX 3;

Este procedimiento constituye una herramienta de contingencia fundamental para el DBA al momento de resolver bloqueos de servicio urgentes en aplicaciones cuyas contraseñas no puedan modificarse de forma inmediata.

Sin embargo, no debe adoptarse como una solución permanente. La buena práctica de administración dicta planificar ventanas de mantenimiento periódicas para la rotación formal de credenciales y la asignación de perfiles con la directiva PASSWORD_LIFE_TIME UNLIMITED exclusivamente a cuentas de servicio de aplicación debidamente auditadas.

Saludos.

Read More

El valor de los Backups Incrementales ante un borrado accidental de Archivelogs

El valor de los Backups Incrementales ante un borrado accidental de Archivelogs

   julio 01, 2026       Luis Felipe

---

Durante los procesos de migración de bases de datos Oracle, la gestión del espacio en la Flash Recovery Area (FRA) suele volverse crítica debido a la alta generación de Archive Logs. En escenarios de alta presión, es común recurrir a comandos manuales de depuración. Sin embargo, el uso descuidado de la cláusula FORCE puede derivar en un escenario catastrófico.

En este artículo analizaremos cómo un borrado forzado de secuencias de Archive Logs afectó un respaldo de migración en ejecución, y cómo la ejecución de un Backup Incremental Level 1 actuó como salvavidas para mantener la disponibilidad de los datos.

El objetivo era generar un respaldo completo para mover la base de datos hacia un nuevo servidor. Debido al alto volumen de transacciones, la FRA comenzó a quedarse sin espacio. Para mitigar esto, se procedió a respaldar los logs directamente hacia un Filesystem alterno para liberar espacio local.

Para acelerar la depuración, se optó por eliminar los Archive Logs basándose en rangos de secuencias (sequence) en lugar de la cláusula habitual por tiempo (BEFORE 'SYSDATE'), aplicando además el parámetro FORCE:

RMAN> DELETE FORCE ARCHIVELOG FROM SEQUENCE 12345 UNTIL SEQUENCE 12355;

⚠️ El Peligro del Modificador FORCE: > El parámetro FORCE de RMAN ejecuta un borrado físico e ignora si los archivos están catalogados correctamente o si residen en múltiples destinos. Al ejecutarlo, RMAN no solo eliminó las secuencias de la FRA, sino que también barrió con las copias de esos mismos Archive Logs que ya se habían respaldado en la ruta del Filesystem destinada a la migración.

Dado que en ese instante se estaba ejecutando el Backup Full (Level 0) base para la migración, la pérdida de estos Archive Logs comprometía la consistencia del respaldo para el posterior RESTORE y RECOVER en el destino. La ventana de mantenimiento parecía perdida.

Originalmente, la estrategia no contemplaba el uso de respaldos incrementales. Sin embargo, ante la crisis, se optó por una solución alternativa basada en la arquitectura de RMAN:

• Archive Logs: Registran de manera lineal y cronológica los cambios vectoriales aplicados en la base de datos.

• Backup Incremental Level 1: Captura el estado final de los bloques de datos que sufrieron modificaciones desde el último Level 0.

Para salvar la situación, inmediatamente después de que finalizó el Backup Full, se lanzó de manera manual un Backup Incremental:

RMAN>BACKUP INCREMENTAL LEVEL 1 DATABASE FORMAT '/ruta_de_backup/db_inc_%u';

Al ejecutarse en ese instante, el Level 1 escaneó los datafiles y capturó en un conjunto de respaldos consolidado los bloques que habían cambiado. De esta manera, los cambios atrapados en la brecha de los Archive Logs destruidos quedaron asegurados directamente a nivel de bloques de datos.

Al realizar la restauración en el nuevo servidor, la ausencia de las secuencias de Archive Logs eliminadas por error no detuvo el proceso.

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;

Durante el paso de RECOVER, RMAN detectó la existencia del Backup Incremental Level 1. En lugar de detenerse inmediatamente solicitando las secuencias perdidas, RMAN aplicó directamente los bloques modificados del archivo incremental sobre el Backup Level 0 restaurado.

Esto consolidó los cambios pendientes directamente en los datafiles, permitiendo alcanzar la consistencia requerida para abrir la base de datos de manera segura:

SQL> ALTER DATABASE OPEN RESETLOGS;

Este escenario demuestra que el Backup Incremental Level 1 es una excelente herramienta de contingencia para mitigar rupturas en la cadena de redo histórica, reduciendo drásticamente el RTO al consolidar cambios directamente a nivel de bloques. Sin embargo, para salvaguardar la integridad de la estrategia de recuperación, se debe desterrar el uso reactivo de DELETE FORCE para liberar espacio en la FRA durante operaciones en caliente, ya que RMAN puede eliminar copias válidas en otros destinos activos. En su lugar, la buena práctica exige dimensionar correctamente la FRA antes de la migración, priorizar comandos de cambio de catálogo (CROSSCHECK y DELETE EXPIRED) o reubicar temporalmente los destinos de los logs (LOG_ARCHIVE_DEST_n) hacia un storage externo sin romper la consistencia del respaldo base.

Saludos.

Read More

Cómo generar y analizar trazas en Oracle con DBMS_MONITOR y TKPROF

Cómo generar y analizar trazas en Oracle con DBMS_MONITOR y TKPROF

   mayo 18, 2026       Luis Felipe

---

En muchas ocasiones nos encontramos con problemas de rendimiento en nuestras aplicaciones y necesitamos saber con exactitud qué consultas SQL están consumiendo la mayor cantidad de recursos en nuestra base de datos Oracle.

Una de las herramientas más potentes y clásicas para resolver este rompecabezas es la combinación de DBMS_MONITOR (para capturar la actividad) y TKPROF (para formatear y entender el archivo de traza resultante).

A partir de las versiones modernas de Oracle, el uso de DBMS_SUPPORT o ALTER SESSION SET SQL_TRACE ha quedado en desuso en favor del paquete DBMS_MONITOR, el cual nos da un control mucho más granular.

Identificar y activar la traza

Para este ejemplo, identificaremos el SID y el SERIAL# de la sesión que queremos auditar desde la vista V$SESSION. Una vez obtenidos los valores, ejecutamos el siguiente bloque PL/SQL desde una cuenta con privilegios de Administrador (como SYS o SYSTEM):

BEGIN
  DBMS_MONITOR.session_trace_enable(
    session_id => &target_sid,
    serial_num => &target_serial,
    waits      => TRUE,   -- Captura de eventos en v$session_wait / Extended Trace
    binds      => TRUE    -- Captura el volcado de variables bind en el dump
  );
END;
/

A partir de este momento, toda la actividad de esa sesión se registrará en un archivo de traza (.trc) en el servidor.

Localizar el archivo generado (.trc)

Para encontrar el archivo generado en el servidor, podemos lanzar la siguiente consulta en SQL*Plus o SQL Developer mientras la sesión siga activa para conocer la ruta exacta del directorio de diagnóstico:

SELECT
    p.tracefile
FROM v$session s
JOIN v$process p ON s.paddr = p.addr
WHERE s.sid = &target_sid;

Activar la traza con binds => TRUE y waits => TRUE genera un impacto en el rendimiento de la sesión afectada y puede llenar rápidamente el sistema de archivos si el proceso procesa millones de filas. Úsalo con moderación en entornos de producción.

Desactivar el rastreo

Cuando la sesión termine de ejecutar los procesos lentos, debemos proceder a deshabilitar el rastreo para no saturar el almacenamiento:

BEGIN
  DBMS_MONITOR.session_trace_disable(session_id => &target_sid, serial_num => &target_serial);
END;
/

Formatear la traza con TKPROF

El archivo .trc original es difícil de leer directamente de forma manual. Aquí es donde entra TKPROF, una utilidad de línea de comandos del sistema operativo que convierte el archivo plano en un reporte legible.

Abrimos la terminal de nuestro servidor (Linux/Windows) y ejecutamos la sintaxis básica:

tkprof ora_12345_pdb.trc user_report.txt sys=no sort=prsela,exeela,fchela

• sys=no: Filtra y descarta las consultas recursivas del diccionario de datos ejecutadas por el usuario SYS, aislando únicamente el SQL emitido por la aplicación.
  
  
• sort=prsela,exeela,fchela: Ordena el archivo de salida priorizando las sentencias SQL que acumularon el mayor tiempo transcurrido (Elapsed Time) durante las fases de Parsing, Ejecución y Fetch.

Interpretación de los resultados

Al abrir nuestro archivo user_report.txt, veremos bloques de información para cada sentencia ejecutada, organizados en una tabla de estadísticas como esta:

• Elapsed: Es el tiempo total que tardó la consulta de cara al usuario. Si es muy alto comparado con el tiempo de CPU, significa que la consulta estuvo esperando por recursos (bloqueos, lectura de disco, etc.).
  
• Query: Representa las lecturas lógicas en memoria (Buffers). Un número extremadamente alto aquí suele indicar que a la consulta le falta un índice adecuado y está realizando un Full Table Scan.
• Disk: Lecturas físicas en el disco duro. Las lecturas en disco siempre penalizan el rendimiento.

El uso combinado de DBMS_MONITOR y TKPROF sigue siendo una de las metodologías más certeras y recomendadas por los expertos para realizar Tuning de SQL, ya que nos muestra la realidad de lo que ocurre sin suposiciones.

Saludos.

Read More

Evento enq: JQ - contention ¿Por qué se detienen mis Jobs?

Evento enq: JQ - contention ¿Por qué se detienen mis Jobs?

   mayo 13, 2026       Luis Felipe

---

Recientemente, me encontré con un escenario donde los procesos de Job Queue de una base de datos Oracle parecían no avanzar. Al revisar las vistas de rendimiento, identifiqué una espera prolongada en el evento enq: JQ - contention

Para entender el problema, primero debemos recordar cómo gestiona Oracle los jobs. A partir de Oracle 11g y 12c, la arquitectura de Oracle Scheduler separa la programación de la ejecución real mediante varios procesos de fondo:

• CJQ0 (Job Queue Coordinator): Es el director de orquesta. Lee la tabla de jobs, determina cuál debe ejecutarse y levanta procesos esclavos para realizar el trabajo.

• Jnnn / Wnnn (Job/Worker Slaves): Son los procesos que ejecutan el código PL/SQL del job.

El Enqueue JQ es un bloqueo de nivel de instancia utilizado para serializar el control de los trabajos. Oracle lo usa para asegurar que un job no sea ejecutado por dos procesos a la vez y para gestionar la creación/terminación de los procesos esclavos.

Cuando vemos el evento enq: JQ - contention, significa que hay una fila de procesos esperando por ese "permiso". Esto suele ocurrir por saturación del coordinador, límites bajos en JOB_QUEUE_PROCESSES o jobs "zombies" que mantienen el bloqueo sin liberar el recurso.

Al ejecutar una consulta a v$session para monitorear los procesos tipo Job (J001), observamos lo siguiente:

SELECT sid, serial#, event, p1, p2, p3, seconds_in_wait FROM v$session WHERE program LIKE '%(J001)%';

Observen la columna SECONDS_IN_WAIT. El proceso lleva más de 12 horas esperando. El valor de P1 (1246822406) traducido a ASCII corresponde precisamente a 'JQ'.

Podemos obtener el valor de P1 traducido a ASCII, con el siguiente query:

SELECT chr(bitand(1246822406,-16777216)/16777216)|| chr(bitand(1246822406,16711680)/65536) AS Enqueue_Type FROM dual;

Para identificar el SPID a nivel de sistema operativo:

SELECT s.sid, p.spid, s.program, s.event FROM v$session s JOIN v$process p ON s.paddr = p.addr WHERE s.program LIKE '%(J001)%';

 En este escenario, al revisar otros procesos esclavos (Workers W...), detectamos sesiones con un LAST_CALL_ET muy alto, lo que indica que están ejecutando tareas que se quedaron colgadas o son ineficientes:

 SELECT p.spid, s.username, s.program, s.last_call_et FROM v$session s JOIN v$process p ON s.paddr = p.addr WHERE s.sid = 4170;

Si la contención es crítica y los jobs están paralizados, la solución más efectiva es "resetear" el coordinador de jobs:

1. Verificamos el valor actual del parámetro job_queue_processes.
   

   sqlplus / as sysdba

   SHOW PARAMETER "job_queue_processes";

    

2. Establecemos el parámetro a cero.
   

   ALTER SYSTEM SET job_queue_processes=0;

3. Si existen procesos a nivel de OS que no mueren, identificarlos por su SPID y terminarlos.

4. Volvemos al valor original, en este caso teníamos lo establecido en 2000.
   

   ALTER SYSTEM SET job_queue_processes=2000;

Esto obliga al CJQ0 a reiniciarse y liberar los enqueues persistentes.

Como hemos visto, el evento enq: JQ - contention es una señal clara de que el motor de jobs está saturado o bloqueado por un proceso ineficiente. En entornos críticos, especialmente en RAC, no basta con aumentar el número de procesos; es fundamental monitorear el LAST_CALL_ET de los workers para identificar tareas "zombies" que secuestran al coordinador. Realizar un reseteo controlado de la cola de trabajos suele ser la solución más efectiva para normalizar el servicio sin afectar al resto de las instancias del cluster.

Read More

Configurar y Utilizar Oracle Flashback Technology

Configurar y Utilizar Oracle Flashback Technology

   mayo 05, 2026       Luis Felipe

---

Oracle Flashback es una de las herramientas más útiles para un DBA, ya que nos permite recuperar datos o estados de la base de datos sin necesidad de recurrir a backups (RMAN). A diferencia de RMAN, Flashback trabaja con los datos actuales para "deshacer" errores en segundos.

IMPORTANTE: Todos los ejemplos prácticos de esta guía han sido validados y probados en Oracle Database 23ai.

Para utilizar Flashback Database, la base de datos debe estar en modo ARCHIVELOG. Primero verificamos el estado:

SELECT log_mode, flashback_on FROM v$database;

En este caso no se encuentra activo ni el modo archivelog de la base por lo tanto tampoco el modo flashback. Procedemos con la configuración de la Fast Recovery Area (FRA), activamos ambos modos.

--Definir espacio y ruta de la FRA ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G; ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/opt/oracle/fast_recovery_area';

--Definir retención (ej. 24 horas en minutos) ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 1440;

--Activar modos (Requiere modo MOUNT) 

SHUTDOWN IMMEDIATE; 

STARTUP MOUNT; 

ALTER DATABASE ARCHIVELOG; 

ALTER DATABASE FLASHBACK ON; 

ALTER DATABASE OPEN;

No todos los Flashback funcionan igual. Se dividen principalmente por el origen de los datos que utilizan:

Basados en Segmentos de UNDO

Estos dependen del UNDO_TABLESPACE. Si los datos en el undo han sido sobrescritos, la operación fallará.

• Flashback Query: Permite consultar datos en un tiempo pasado (AS OF TIMESTAMP/SCN).

  
  
  

  

SELECT last_name, salary FROM hr.employees AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '5' MINUTE) WHERE department_id = 60;

• Flashback Version Query: Ideal para auditoría, permite ver los cambios de una fila.

--Muestra todas las versiones de una fila en un intervalo

SELECT versions_starttime, versions_operation, salary

FROM hr.employees

VERSIONS BETWEEN TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' HOUR) AND MAXVALUE

WHERE employee_id = 101;

• Flashback Table: Revierte una tabla completa. (Ojo: requiere Row Movement).

-- Indispensable para evitar error ORA-08189 

ALTER TABLE hr.employees ENABLE ROW MOVEMENT; 

-- Revertir tabla a un punto exacto FLASHBACK TABLE hr.employees TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '10' MINUTE);

Basados en Flashback Logs (FRA)

Dependen de la Fast Recovery Area y capturan cambios a nivel de bloque físico.

• Flashback Database: Revierte toda la base de datos. Es la opción más drástica y rápida ante errores masivos de despliegue.

-- Si estás en un entorno PDB (CDB/PDB), primero cierra la PDB: 

ALTER PLUGGABLE DATABASE FREEPDB1CLOSE; 

-- Ejecuta el retroceso 

FLASHBACK PLUGGABLE DATABASE FREEPDB1TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '30' MINUTE); 

-- Abre con resetlogs para fijar la nueva línea de tiempo 

ALTER PLUGGABLE DATABASE FREEPDB1OPEN RESETLOGS;

Basados en Metadata (Recycle Bin)

• Flashback Drop: Recupera tablas borradas con DROP. Oracle simplemente renombra el objeto en el diccionario de datos.

-- Si borraste la tabla por accidente: 

DROP TABLE hr.locations CASCADE CONSTRAINTS; 

-- Recupérala de la "papelera" 
FLASHBACK TABLE hr.locations TO BEFORE DROP;

TIP: A veces, recordar una fecha exacta o un SCN es complicado. Puedes crear un "alias" para el estado actual de tu base de datos antes de realizar cambios importantes.

-- Crear un punto de retorno normal 

CREATE RESTORE POINT antes_del_cambio;

Puedes consultar los puntos guardados

SELECT name, scn, time, guarantee_flashback_database FROM v$restore_point; 

Para regresar al punto especifico creado

-- Para una tabla específica 
FLASHBACK TABLE hr.locations TO RESTORE POINT antes_del_cambio;  

Recuerda que la tecnología Flashback no es solo una funcionalidad de recuperación, sino una estrategia de continuidad de negocio. Mientras que un backup tradicional en RMAN es tu seguro de vida ante un desastre físico o de hardware, Flashback es tu mejor aliado contra el error humano cotidiano.

Read More

Uso de Hints de Paralelismo en grandes volúmenes de datos

Uso de Hints de Paralelismo en grandes volúmenes de datos

   abril 27, 2026       Luis Felipe

---

Bajo el ecosistema de Oracle Database, es habitual lidiar con procesos que manejan millones de registros (Batch, ETL o reportes pesados). Cuando el tiempo de respuesta es fundamental, el procesamiento en paralelo se convierte en nuestra mejor herramienta.

Sin embargo, el Optimizador de Oracle (CBO) no siempre elige el paralelismo de forma automática. En este post, veremos cómo forzarlo correctamente y qué consideraciones debemos tener.

Cuando usamos un hint de paralelismo, Oracle divide una tarea grande en piezas más pequeñas. Un Query Coordinator (QC) coordina a varios procesos esclavos (Parallel Execution Servers) que trabajan simultáneamente.

La forma más común de implementarlo es a través del hint /*+ PARALLEL(alias, degree) */. El degree o grado define cuántos procesos esclavos vamos a solicitar.

SELECT /*+ PARALLEL(ventas, 4) */ 
       producto_id, SUM(monto)
FROM fact_ventas ventas
GROUP BY producto_id;

En este caso, estamos solicitando 4 procesos esclavos para escanear la tabla y realizar la agregación.

Este es un punto donde muchos fallan. Para que un INSERT funcione realmente rápido, debemos combinar el paralelismo con el Direct Path Load mediante el hint APPEND. Esto hace que Oracle escriba directamente al final de la tabla, saltándose el Buffer Cache y generando mucho menos Redo Log.

ALTER SESSION ENABLE PARALLEL DML;

INSERT /*+ APPEND PARALLEL(destino, 8) */ INTO table_final destino
SELECT /*+ PARALLEL(origen, 8) */ * FROM table_staging origen;
COMMIT;

Para confirmar que el hint está funcionando, debemos generar el plan de ejecución (EXPLAIN PLAN). Debemos identificar las siguientes operaciones:

• PX COORDINATOR: El proceso principal que une los resultados.
• PX SEND / PX RECEIVE: Indica que los datos se están moviendo entre procesos esclavos.
• PX BLOCK ITERATOR: Oracle ha dividido la tabla en bloques para los esclavos.
• LOAD AS SELECT (HIGH WATER MARK): Indica que el APPEND y el paralelismo de escritura están activos.

Si el plan de ejecución muestra estas líneas (comenzando con "PX"), el paralelismo se está aplicando correctamente.

Este plan de ejecución representa una carga de datos de alto rendimiento (Full Parallel Stack) que utiliza el paralelismo tanto para leer como para escribir. En lugar de procesar los datos fila por fila, el (PX Coordinator) divide la tarea entre 4 procesos esclavos que filtran los duplicados simultáneamente y realizan una inserción directa al disco (Direct Path Load), saltándose la memoria intermedia y escribiendo los datos al final de la tabla de forma masiva. Además, el plan incluye el mantenimiento de índices en paralelo, lo que evita que la base de datos se ralentice al actualizar los índices después de la carga, garantizando la máxima velocidad posible y un uso mínimo de los logs de transacciones.

IMPORTANTE:

No se debe abusar del paralelismo. Aquí mis recomendaciones:

1. Costo de CPU: Cada proceso paralelo consume CPU. Si el servidor tiene 8 núcleos y lanzas un PARALLEL 32, causarás una degradación general del sistema.
2. Uso de Memoria: El paralelismo utiliza la PGA de forma intensiva para los ordenamientos y joins. Asegúrate de tener suficiente PGA_AGGREGATE_TARGET.
3. Tablas pequeñas: No utilices este hint en tablas de pocos registros. El tiempo que le toma a Oracle gestionar los procesos esclavos será mayor que la ganancia de velocidad.

El uso de hints de paralelo es fundamental para grandes volúmenes, pero un grado de paralelismo mal calculado puede afectar a todos los usuarios. ¡Úsalo con cautela y siempre verifica tu plan de ejecución!

Read More

Resolviendo el error ORA-1652: unable to extend temp segment by 128 in tablespace TEMP

Resolviendo el error ORA-1652: unable to extend temp segment by 128 in tablespace TEMP

   abril 09, 2026       Luis Felipe

---

El error ORA-1652 es uno de los incidentes más temidos por los DBAs. La reacción más común suele ser añadir más archivos de datos (Tempfiles), pero la experiencia demuestra que el aumento en el consumo de espacio temporal es debido a un proceso o consulta ineficiente.

Cuando el error ocurre, el espacio en TEMP se libera automáticamente al fallar la sesión, borrando los registros en las vistas de tiempo real. Para investigar, debemos consultar el historial de sesiones activas (ASH) para encontrar el pico máximo de consumo de cada consulta.

SELECT 
    sql_id,
    user_id,
    program,
    round(MAX(temp_space_allocated)/1024/1024/1024,2) AS max_temp_gb,
    MIN(sample_time) AS inicio,
    MAX(sample_time) AS fin
FROM v$active_session_history
WHERE temp_space_allocated > 0
  AND sql_id IS NOT NULL
--Aqui colocamos la fecha y hora relacionada al error ORA-1652  
  AND sample_time BETWEEN TO_TIMESTAMP('08/04/2026 08:00', 'DD/MM/YYYY HH24:MI') 
                      AND TO_TIMESTAMP('08/04/2026 08:30', 'DD/MM/YYYY HH24:MI')
GROUP BY sql_id, user_id, program
ORDER BY max_temp_gb DESC;

En nuestro caso, encontramos que el SQL_ID 85v0ju71vfphg alcanzó un pico de 370 GB. Al revisar el reporte AWR (Automatic Workload Repository), la sección "Top SQL with Top Events" reveló lo siguiente:

• Evento: direct path write temp

• Wait Class: User I/O

• Top Row Source: HASH JOIN / HASH GROUP BY

¿Por qué una consulta necesitaría tanto espacio? Al obtener el plan con DBMS_XPLAN.DISPLAY_AWR, detectamos dos problemas críticos:

1. MERGE JOIN CARTESIAN: El motor intentó realizar un producto cartesiano (unir cada fila con todas las filas de otra tabla) debido a una condición de unión mal definida con una tabla. Esto multiplicó exponencialmente el set de datos intermedio.

2. SORT UNIQUE: El uso de UNION (en lugar de UNION ALL) obligó a un ordenamiento masivo para eliminar duplicados de un set de datos que ya estaba inflado por el cartesiano.

Para solucionar esto, el primer paso es auditar la lógica de las uniones (JOINs): asegurar que todas las tablas tengan su predicado de unión correspondiente en el WHERE o en la cláusula ON.

Si la lógica es correcta pero el optimizador sigue eligiendo un cartesiano por un error de estimación en las estadísticas, podemos intervenir usando el hint /*+ NO_CARTESIAN */. Asimismo, evaluamos cambiar UNION por UNION ALL si sabemos que los resultados de ambas consultas son disjuntos o si los duplicados son aceptables.

El ORA-1652 no se resuelve simplemente asignando más disco. Antes de ampliar, identifica el pico (ASH), confirma el evento (AWR) y audita la lógica (Plan de Ejecución). Optimizar el código es, en la gran mayoría de los casos, la forma más eficiente y profesional de resolver este error.

Read More

Dimensionamiento de Memoria en Oracle

Dimensionamiento de Memoria en Oracle

   marzo 31, 2026       Luis Felipe

---

El rendimiento de una base de datos Oracle no depende de cuánta RAM tengas, sino de cómo la distribuyes. En un entorno de producción, la memoria es un recurso finito y costoso; asignarla en exceso es tan peligroso como quedarse corto, ya que puede inducir problemas de paginación a nivel de OS o enmascarar consultas ineficientes que deberían ser optimizadas en código.

En esta guía aprenderemos a interpretar los Advisors para ajustar la SGA y la PGA utilizando los componentes internos del motor.

Antes de tocar parámetros, debemos entender que es SGA y PGA:

• SGA (System Global Area): Memoria compartida. Su objetivo es minimizar la I/O física (lectura de disco).

• PGA (Program Global Area): Memoria privada por proceso. Su objetivo es realizar ordenamientos y uniones "In-Memory".

• db file sequential read (11.4% del tiempo): Es el tiempo que la base de datos pasa esperando a que el disco le entregue un bloque de datos que no encontró en la memoria. La SGA es demasiado pequeña para el volumen de datos que consultamos. El motor está "trabajando de más" yendo al disco por información que debería estar ya en la RAM.

• acknowledge over PGA limit: Este es un evento "semáforo". Aparece cuando Oracle detiene un proceso porque ya se alcanzó el límite máximo de memoria RAM permitido. El sistema está asfixiado. Literalmente está "poniendo en cola" a los usuarios porque no hay más memoria disponible para procesar sus consultas. Es la confirmación de que nuestra PGA necesita crecer urgentemente.

Diagnostico SGA (V$SGA_TARGET_ADVICE):
Ejecuta la siguiente consulta:

SELECT sga_size, sga_size_factor, estd_db_time, estd_physical_reads
FROM v$sga_target_advice
ORDER BY sga_size_factor;

Si aumentamos la SGA de 30 GB a 45 GB (Factor 1.5):

• Lecturas Físicas: Bajan de 170B a 149B (Una reducción del ~12%).
• Tiempo de DB: Baja de 118M a 114M (Una mejora de apenas el 3.4%).

Necesitamos invertir 15 GB adicionales de RAM para obtener una mejora de velocidad que el usuario final probablemente ni siquiera notará.

Diagnostico PGA(V$PGA_TARGET_ADVICE):
Ejecuta la siguiente consulta:

SELECT pga_target_for_estimate/1024/1024 AS target_mb, 
       pga_target_factor, 
       estd_extra_bytes_rw,
       estd_pga_cache_hit_percentage
FROM v$pga_target_advice;

Si aumentamos la PGA de 10 GB a 18 GB (Factor 1.8):

• Tráfico en Disco (Extra Bytes RW): Baja de 186 TB a 182 TB. Ahorramos 4 Terabytes de escritura innecesaria en el TEMP.

• Eficiencia (Cache Hit %): Sube del 91% al 92%.

Es una inversión inteligente. Con solo 8 GB adicionales de RAM, eliminamos el cuello de botella que causa el evento acknowledge over PGA limit y estabilizamos las operaciones pesadas.

Una vez identificado el tamaño óptimo, aplica los cambios. Recuerda que si usas ASMM (Automatic Shared Memory Management), solo ajustas los targets.

Puedes usar esta consulta para verificar:

SELECT 
    name, 
    value/1024/1024 AS mbytes, 
    CASE 
        WHEN name = 'sga_target' AND value > 0 THEN 'ASMM: Gestión Automática de SGA'
        WHEN name = 'pga_aggregate_target' AND value > 0 THEN 'PGA: Gestión Automática de Procesos'
        WHEN name = 'memory_target' AND value > 0 THEN 'AMM: Gestión Total (SGA + PGA)'
        ELSE 'Gestión Manual / Límite Estricto'
    END AS modo_gestion
FROM v$parameter 
WHERE name IN ('sga_target', 'pga_aggregate_target', 'memory_target', 'pga_aggregate_limit');

En este caso solo redimensionaremos la PGA, dado que tenemos mayor beneficio por un bajo costo (8GB de RAM).

-- 1. Subir el Target
ALTER SYSTEM SET pga_aggregate_target = 18G SCOPE=BOTH;

-- 2.  Lo ideal es que el limit sea al menos 2x el target
ALTER SYSTEM SET pga_aggregate_limit = 36G SCOPE=BOTH; 

La PGA es mucho más flexible. Puedes aplicar los cambios y tendrán efecto inmediato, pero cuidado con el límite (limit), debe ser siempre mayor al target.

IMPORTANTE:

No redimensiones sin validar estos tres puntos:

1. Evitar el Paging: La suma de SGA + PGA + SO nunca debe superar el 80% de la RAM física. Si el SO empieza a usar Swap, el rendimiento de Oracle colapsará.

2. HugePages (Solo Linux): Si tu SGA es mayor a 8GB, asegúrate de configurar HugePages a nivel de kernel para evitar que el proceso vktm consuma demasiada CPU gestionando tablas de páginas.

3. Monitoreo Post-Cambio: Tras el ajuste, monitorea V$SQL_WORKAREA_ACTIVE para confirmar que las operaciones pasaron de MULTI-PASS a OPTIMAL.

La mejor optimización de memoria no es comprar más módulos de RAM, sino reducir la necesidad de ella mediante la indexación correcta y el tuning de sentencias SQL.

Read More

Resolviendo las limitaciones del Auto Optimizer Stats Collection en Oracle

Resolviendo las limitaciones del Auto Optimizer Stats Collection en Oracle

   marzo 20, 2026       Luis Felipe

---

En el mundo de la administración de bases de datos, las estadísticas son la ruta de acceso que el optimizador (CBO) elegirá para ejecutar una sentencia SQL. Sin ellas, hasta la consulta más simple puede convertirse en una pesadilla de rendimiento. Oracle nos ofrece por defecto el Auto Optimizer Stats Collection, un job diseñado gestionar la recolección de estadísticas de forma integral y desatendida. Sin embargo, en entornos de Data Warehouse con volúmenes masivos de datos esto suele ser insuficiente.

Recientemente, en una de las bases de datos que administro, me enfrenté a un escenario crítico: el mantenimiento nativo de Oracle no lograba concluir dentro de la ventana programada de 4 horas. Esto derivaba en la presencia de estadísticas obsoletas (STALE) y el bloqueo de estadísticas en objetos específicos, provocando una degradación progresiva en el rendimiento global de la base de datos.

• El proceso se interrumpía dejando gran parte de los objetos sin procesar.

• Las estadísticas quedaban en un estado inconsistente, impidiendo actualizaciones manuales y disparando errores como el ORA-20005.

• Sin datos frescos, el optimizador elegía rutas de acceso ineficientes, aumentando drásticamente la latencia global del sistema.

Para romper este ciclo, decidimos tomar el control total mediante una automatización personalizada. Nuestra lógica aplica reglas de ingeniería de datos claras:

• El procedimiento identifica si el esquema contiene tablas particionadas o normales para aplicar el método de recolección correcto.

• Priorizamos la última partición vigente, asegurando que el optimizador (CBO) siempre tenga datos frescos de la carga reciente sin desperdiciar recursos en datos históricos estáticos.

• Implementamos una tabla de control para registrar cada inicio, fin y duración, permitiendo una auditoría que el job nativo no ofrece de forma tan detallada.

Importante: Antes de implementar esta solución es necesario desactivar la recolección automática de estadísticas de Oracle. 

Pero antes verificamos el estado actual de la tarea de recolección de estadísticas.

select client_name,status from dba_autotask_client where client_name='auto optimizer stats collection';

Procedemos a desactivar la tarea de recolección automática de Oracle.

BEGIN
  DBMS_AUTO_TASK_ADMIN.DISABLE(
    client_name => 'auto optimizer stats collection',
    operation   => NULL,
    window_name => NULL
  );
END;
/

Verificamos nuevamente el estado actual de la tarea de recolección de estadísticas.

He compartido la solución completa (DDL de bitácora, procedimiento PL/SQL y configuración del Job) en mi repositorio de GitHub para que la comunidad pueda adaptarlo:

🔗Oracle-Stats-Automation

Puedes consultar el estado de tus estadísticas y el rendimiento del job mediante la tabla de bitácora:

select * from sys.gbd_bitacora_estat where grupo=5 order by 1,2 asc;

Esta solución fue desarrollada y validada con éxito en un entorno Oracle Database 12c, demostrando una estabilidad total tanto en la gestión de objetos particionados como en la integración con el Oracle Scheduler. Aunque el enfoque es estándar, se recomienda realizar pruebas previas en entornos de desarrollo antes de pasar a producción.

Read More