El matiz: ¿Global o Local?

Si estuviéramos ante un índice Global, la solución sería inmediata y elegante: ALTER INDEX IDX_GLOBAL REBUILD ONLINE NOREVERSE;

Pero, ¿qué pasa si el índice es LOCAL y la tabla está particionada? Aquí la sintaxis de Oracle nos limita, y no podemos usar la cláusula NOREVERSE en un rebuild de este tipo. Por ello, debemos recurrir a una estrategia de reconstrucción completa.

La Estrategia: Creación online e Invisible

Para evitar el error ORA-01408 (columna ya indexada) y no degradar rendimiento, el flujo de trabajo ideal es el siguiente:

Preparación del terreno (TEMP y Monitorización)

Dado que moveremos grandes volúmenes de datos (en mi caso, más de 100 GB), es vital asegurar que el tablespace temporal aguante el "sort". SQL

-- Monitorización del consumo de TEMP durante la creación en entorno de prueba
SELECT ROUND(SUM(blocks)*8/1024, 2) MB_REAL FROM v$sort_usage;

Creación del nuevo índice "en la sombra"

Utilizamos las cláusulas ONLINE para no bloquear DML e INVISIBLE ya que si no nos encontraríamos el error: ORA-01408: such column list already indexed.

Oracle permite tener dos índices sobre las mismas columnas siempre y cuando solo uno de ellos sea visible para el optimizador y una estructura física distinta,

CREATE INDEX XXX.IDX_LOG_ENV_PERF 
ON XXX.LOG_ENTREGAS (ID_DISPOSITIVO, FECHA_LOG) 
LOCAL 
ONLINE 
INITRANS 50 
PCTFREE 20 
TABLESPACE TBS_INDEXES 
PARALLEL 8 -- Aprovechamos la potencia del server 
INVISIBLE;

ALTER INDEX XXX.IDX_LOG_ENV_PERF NOPARALLEL;

Compruebo que ambos conviven:

Nota importante sobre el rendimiento: Ten en cuenta que mientras ambos índices convivan (el antiguo Reverse y el nuevo Normal), cada operación de INSERT, UPDATE o DELETE tendrá que actualizar ambos. Esto supone una penalización temporal en las operaciones DML, por lo que se recomienda realizar el cambio en horas de menor carga.

El Switch de Visibilidad

Una vez creado, el cambio es instantáneo a ojos de la aplicación. Pasamos el índice antiguo a modo invisible y activamos el nuevo. Esto nos da un plan de rollback inmediato: si algo falla, solo hay que revertir la visibilidad.

ALTER INDEX XXX.IDX_ORIGINAL_REVERSE INVISIBLE; 
ALTER INDEX XXX.IDX_LOG_ENV_PERF VISIBLE;

Va todo bien? Liberamos espacio una vez validado el cambio .

DROP INDEX XXX.IDX_ORIGINAL_REVERSE;

Cuando trabajamos con índices locales, perdemos la facilidad del REBUILD NOREVERSE.

Utilizar índices invisibles y creación online es la forma más transparente de realizar este cambio en entornos críticos de 24/7.

Hoy analizaré un caso real (los que me gustan!) donde el mecanismo de Dynamic Remastering (DRM) causó un micro-delay de casi un segundo, demorando transacciones críticas.

El síntoma: El evento de espera "fantasma"

Al revisar la ASH (dba_hist_active_sess_history) debido a una demora puntual de menos de 1 segundo, detecto algo que me llama la atención.

SYS@cdbxxx1> SELECT
    event,
    count(*) as total_capturas,
    round(avg(wait_time+time_waited)/1000, 2) as avg_wait_ms
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN TO_TIMESTAMP('22/02/26 06:13:00', 'DD/MM/YY HH24:MI:SS')
                      AND TO_TIMESTAMP('22/02/26 06:14:00', 'DD/MM/YY HH24:MI:SS')
GROUP BY event
ORDER BY 3 DESC;


EVENT								 TOTAL_CAPTURAS AVG_WAIT_MS
---------------------------------------------------------------- -------------- -----------
gcs drm freeze in enter server mode					      1      919.47
LGWR worker group ordering						      1       33.48
log file sync								     31       26.52
LGWR any worker group							      2       17.67
									      4 	.75
db file sequential read 						      1 	 .7
buffer busy waits							      1 	.39
log file parallel write 						      2 	.38
rdbms ipc reply 							      1 	  0


Evento: gcs drm freeze in enter server mode

Tiempo de espera: 919.47 ms (¡Casi 1 segundo!)

¿Qué estaba pasando internamente? (La traza de LMON)

La traza del proceso LMON nos da la respuesta. El sistema detectó que ciertos objetos tenían una carga de lectura/escritura que no era óptima para su ubicación actual y decidió "remasterizarlos" (mover la gestión del objeto de un nodo a otro).

*** 2026-02-22T06:13:24.101236+01:00 (CDB$ROOT(1))

* DRM RCFG called (swin 0)
* kjfcdrmrfg: cap sync timeout at 3 * default (752 -> 489 secs, res limit 7518552)
Begin DRM(29029) (swin 0)
 AFFINITY pdb 3 tsn 13 object id 720963, * -> 2 obj size:7333
 AFFINITY pdb 3 tsn 12 object id 720969, 1 -> * obj size:449893
 AFFINITY pdb 3 tsn 11 object id 720996, 1 -> * obj size:217838
 AFFINITY pdb 3 tsn 52 object id 731023, * -> 2 obj size:92115
 AFFINITY pdb 3 tsn 13 object id 731026, * -> 2 obj size:6331
 AFFINITY pdb 3 tsn 13 object id 731027, * -> 2 obj size:12668
 AFFINITY pdb 3 tsn 13 object id 731028, * -> 2 obj size:5780
 AFFINITY pdb 3 tsn 13 object id 731029, * -> 2 obj size:6685
 AFFINITY pdb 3 tsn 13 object id 731030, * -> 2 obj size:6077
 AFFINITY pdb 3 tsn 13 object id 731031, * -> 2 obj size:5386
 AFFINITY pdb 3 tsn 13 object id 731032, * -> 2 obj size:7677
 AFFINITY pdb 3 tsn 13 object id 731033, * -> 2 obj size:5352
 AFFINITY pdb 3 tsn 13 object id 731034, * -> 2 obj size:3425
 AFFINITY pdb 3 tsn 13 object id 731035, * -> 2 obj size:4113
 AFFINITY pdb 3 tsn 13 object id 731036, * -> 2 obj size:3602
 AFFINITY pdb 3 tsn 13 object id 731037, * -> 2 obj size:7983
 AFFINITY pdb 3 tsn 13 object id 731038, * -> 2 obj size:5376
 AFFINITY pdb 3 tsn 13 object id 731039, * -> 2 obj size:3714
 AFFINITY pdb 3 tsn 14 object id 329632, * -> 2 obj size:295
 AFFINITY pdb 3 tsn 13 object id 731040, * -> 2 obj size:5576
 AFFINITY pdb 3 tsn 13 object id 731041, * -> 2 obj size:7776
 AFFINITY pdb 3 tsn 13 object id 731042, * -> 2 obj size:2757
 AFFINITY pdb 3 tsn 13 object id 706860, 1 -> * obj size:131057
 AFFINITY pdb 3 tsn 13 object id 690745, * -> 2 obj size:634
 AFFINITY pdb 3 tsn 51 object id 733055, * -> 2 obj size:4095
 AFFINITY pdb 3 tsn 14 object id 447506, * -> 2 obj size:257
 AFFINITY pdb 3 tsn 13 object id 718971, * -> 2 obj size:1709
Max cumultv sz 2624716 sz limit  4294967295 pk cnt 27 total objsz 1005504
 individual max sizes [ 1005504 2624716 ]
 Estimated time 6.2 secs  (avgtime 0.9 secs, avgsize 384055)
* drm freeze
 drm (29029) freeze step (window 1) - posted lmses/lmds for mtobe
 drm (29029) freeze step (window 1) - apifrz = true
 drm (29029) freeze step (window 1) - all lms procs frozen
* drm sync 1
* drm cleanup
* kjfclmsync: lmses complete parallel work in step 0.33.0
* drm sync 2
* drm replay
* kjfclmsync: lmses complete parallel work in step 0.35.0
send ftd(35) to 2:
* drm sync 3
* drm fix writes
* kjfclmsync: lmses complete parallel work in step 0.37.0
* drm sync 4
* drm end
* window 1 time 0.9 secs)

* DRM RCFG called (swin 0)
* kjfcdrmrfg: cap sync timeout at 3 * default (768 -> 489 secs, res limit 7673832)
* drm freeze
 drm (29029) freeze step (window 2) - posted lmses/lmds for mtobe
 drm (29029) freeze step (window 2) - apifrz = true
 drm (29029) freeze step (window 2) - all lms procs frozen
* drm sync 1
* drm cleanup

*** 2026-02-22T06:13:25.234977+01:00 (CDB$ROOT(1))
* kjfclmsync: lmses complete parallel work in step 0.33.0
* drm sync 2
* drm replay
* kjfclmsync: lmses complete parallel work in step 0.35.0
send ftd(35) to 2:
* drm sync 3
* drm fix writes
* kjfclmsync: lmses complete parallel work in step 0.37.0
* drm sync 4
* drm end
* window 2 time 1.0 secs)

window 1 time 0.9 secs: Exactamente los 919 ms que capturó el ASH

El momento del "Freeze"

Lo más crítico de la traza es cuando Oracle congela los procesos LMS (los encargados de mover los bloques de datos por el interconnect):

* drm freeze drm (29029) freeze step (window 1)
* apifrz = true 
* all lms procs frozen

¿Por qué es esto un problema? Cuando los procesos LMS se congelan para reorganizar las afinidades de los objetos, toda la comunicación de bloques entre nodos se detiene. Si tu aplicación está intentando leer un dato que está en el otro nodo en ese instante, la sesión se queda colgada en el evento gcs drm freeze.

Los objetos afectados: Identificando a los culpables

Cruzando los datos de gv$policy_history y dba_objects, veo que el sistema estuvo moviendo afinidades de particiones críticas:

select h.*,o.object_name, o.SUBOBJECT_NAME 
from gv$Policy_History h, dba_objects o
where h.data_object_id = o.data_object_id 
and o.object_id IN (564682, 391009, 504609, 626248, 716966, 720969, 720996) 
and  TO_DATE(EVENT_DATE, 'MM/DD/YYYY HH24:MI:SS') BETWEEN TO_DATE('02/22/2026 06:00:00', 'MM/DD/YYYY HH24:MI:SS') AND TO_DATE('02/22/2026 07:00:00', 'MM/DD/YYYY HH24:MI:SS')
order by TO_DATE(EVENT_DATE, 'MM/DD/YYYY HH24:MI:SS') desc;

   INST_ID POLICY_EVENT           DATABASE_ID TABLESPACE_ID DATA_OBJECT_ID TARGET_INSTANCE_NUMBER EVENT_DATE               CON_ID OBJECT_NAME                                                                                                                      SUBOBJECT_NAME                                                                                                                  
---------- ---------------------- ----------- ------------- -------------- ---------------------- -------------------- ---------- -------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------
         1 initiate_affinity                3            12         720969                      2 02/22/2026 06:15:37           0 TABLA1                                                                                                                    SYS_P16222                                                                                                                      
         1 initiate_affinity                3            51         716966                      2 02/22/2026 06:15:37           0 TABLA2                                                                                                                     SYS_P16177                                                                                                                      
         1 initiate_affinity                3            11         720996                      2 02/22/2026 06:15:37           0 TABLA3                                                                                                        SYS_P16226                                                                                                                      
         1 push_affinity                    3            14         564682                      2 02/22/2026 06:05:37           0 TABLA4                                                                                                                        SYS_P15690                                                                                                                      
         1 push_affinity                    3            14         504609                      2 02/22/2026 06:05:37           0 TABLA4                                                                                                                        SYS_P15471                                                                                                                      
         1 push_affinity                    3            14         391009                      2 02/22/2026 06:05:37           0 TABLA4                                                                                                                        SYS_P15123                                                                                                                      
         1 push_affinity                    3            14         626248                      2 02/22/2026 06:05:37           0 TABLA4                                                                                                                        SYS_P15914                                                                                                                      

El sistema "empujó" (push_affinity) la gestión de los objetos hacia la instancia 2.

El "Culpable" Inesperado: El Job de Estadísticas

En nuestro caso real, tras investigar los horarios y el module de las sesiones, descubrimos al responsable. No era un error de la aplicación, sino el Job automático de estadísticas que entró por el nodo 2. La tormenta perfecta

• La Aplicación está trabajando intensamente en el Nodo 1, leyendo y escribiendo. Oracle ha establecido la afinidad de esos objetos en el Nodo 2 para optimizar el rendimiento.

• El Job de Estadísticas se lanza desde el Nodo 2. Para calcular las estadísticas, el Nodo 12empieza a pedir masivamente bloques .

• El Conflicto: El DRM de Oracle ve que el Nodo 2 ahora tiene una actividad brutal sobre esos objetos. Consulta su parámetro gcaffinity_ratio y dice: "Oye, el Nodo 2 está pidiendo esto mucho más que antes, voy a mover la maestría del objeto del Nodo 1 al Nodo 2".

• El Resultado: Durante ese cambio de "dueño", se produce el GCS Freeze. La aplicación en el Nodo 1 se detiene en seco durante 919 ms esperando a que el Nodo 2 termine de reclamar la propiedad de los datos.

El "Secuestro" de la Afinidad

Lo que ocurrió en este caso es un secuestro de afinidad. Las estadísticas engañaron al DRM haciéndole creer que el nodo donde se ejecutaban era el más importante. El freeze de 919 ms fue el precio que pagó la aplicación mientras Oracle le "quitaba" las llaves de la tabla para dárselas al proceso de estadísticas.

Opciones de Ajuste Fino (Tuning) del DRM

Si decides mantener el DRM activo para aprovechar la optimización del Interconnect, pero quieres evitar los freezes causados por procesos como las estadísticas, tienes estos tres niveles de configuración:

El "Filtro de Ruido" (_gc_affinity_ratio)

Este es el parámetro que determina cuánta "presión" debe ejercer un nodo remoto para robarle la maestría a otro.

Valor por defecto: 50.

Ajuste recomendado: 1000 o superior.

Efecto: Al subirlo a 1000, el proceso de estadísticas tendría que realizar muchísimas más solicitudes que la aplicación para que el DRM considere que vale la pena mover el objeto. Esto hace que el sistema ignore "picos" de trabajo de mantenimiento y se mantenga fiel a la aplicación OLTP.

La "Ventana de Paciencia" (_gc_policy_time)

Controla cada cuánto tiempo (en minutos) Oracle evalúa si debe remasterizar objetos.

Valor por defecto: 10.

Ajuste recomendado: 60.

Efecto: Si tu job de estadísticas dura 30 minutos, pero la ventana de evaluación es de 60, el job terminará antes de que el DRM decida que el cambio de maestría es necesario. Evitas el freeze simplemente siendo más paciente.

El "Límite de Agresión" (_gc_affinity_limit)

Define el número mínimo de accesos necesarios para que un objeto sea siquiera candidato a DRM.

Ajuste recomendado: Incrementar el valor actual (puedes ver el actual en V$GC_POLICY_MODIFICATIONS).

Efecto: Evita que tablas pequeñas o medianas sean movidas de nodo constantemente por consultas aleatorias o jobs rápidos, reservando el DRM solo para objetos donde el ahorro de tráfico sea masivo y justificado.

Segmentación y Afinidad de Servicios

Si tu entorno tiene múltiples aplicaciones, la solución no es solo mover las estadísticas, sino separar las cargas de trabajo por nodos. De esta forma, el DRM deja de ser un problema para convertirse en un aliado silencioso.

Segmentación de Aplicaciones

Imagina que tienes la App A y la App B. Si ambas conectan a ambos nodos, el Interconnect será un caos de tráfico cruzado.

Nodo 1: Configurado como PREFERRED para el servicio de la App A.

Nodo 2: Configurado como PREFERRED para el servicio de la App B.

El lugar de las Estadísticas en un entorno segmentado

En este escenario, tienes dos opciones inteligentes para el mantenimiento:

• Alineación Total: Lanzas las estadísticas de las tablas de la App A en el Nodo 1, y las de la App B en el Nodo 2 Resultado: El DRM no se inmuta. Los bloques ya están donde deben estar. Es la opción más eficiente en red.

• Nodo de Mantenimiento Dedicado: Si prefieres no cargar los nodos donde están las Apps, puedes usar un tercer nodo (si lo tienes) o un nodo con menos carga. Pero aquí debes usar el tuning de parámetros (_gc_affinity_ratio) para que el DRM no intente "robar" la maestría de las tablas hacia el nodo de mantenimiento.

Conclusión

El DRM es una herramienta de optimización, pero es ciega. No sabe qué proceso es más importante; solo ve volumen de tráfico. Si dejas que las estadísticas corran en el nodo donde menos impacto tendrá, el DRM castigará a tu aplicación para favorecer a un proceso de mantenimiento.

En este artículo veremos un ejemplo práctico, donde implementaremos un recurso llamado monitorizacion_app que lanza un sql que se ejecuta de forma persistente en la BBDD.

Concepto de Recurso de Clúster

Un recurso de clúster en Oracle es cualquier elemento que se puede gestionar mediante Clusterware y tiene:

• Un script de acción que Clusterware ejecuta (start, stop, check, status).

• Dependencias de otros recursos o servicios.

• Posibilidad de moverse entre nodos (relocate).

• Parámetros de reinicio automático y timeout.

• Control de permisos de usuario y ejecución segura.

En este ejemplo, el recurso ejecutará un script que lanza un procedimiento PL/SQL en la base de datos de forma persistente. La finalidad es que va informando una tabla con datos de consultas muy recurrentes de monitorización (métricas de negocio, sesiones conectadas, etc ) a modo de caché (evitamos llamadas recurrentes mismos usuarios pidiendo la misma información) y guardando un histórico en el tiempo para análisis de tendencias.

Preparación del Script de Monitorización

Nuestro script /scripts/monitorizacion_resource.sh tiene las siguientes características:

Ejecutado por el usuario grid, pero con permisos sudo para ejecutar como oracle.

• Controla la inicio, detención, check y status del monitor.

• Interactúa con la base de datos a través de SQLPlus.

• Guarda logs separados por nodo (monitor_app_.log).

• Puede matar sesiones activas si el recurso se detiene.

Ejemplo de invocación manual:

/scripts/monitorizacion_resource.sh start
/scripts/monitorizacion_resource.sh stop
/scripts/monitorizacion_resource.sh status
/scripts/monitorizacion_resource.sh check

Crear el Servicio Oracle

Antes de crear el recurso de clúster, crearemos un servicio asociado a la base de datos, que será la dependencia de nuestro monitor

srvctl add service -db BASEDEDATOS -service MONITORIZACION \
    -role primary -preferred node1 -available node2 \
    -pdb PDB_APP -stopoption IMMEDIATE

srvctl start service -db BASEDEDATOS -service MONITORIZACION

Este servicio será usado por el monitor para conectarse a la base de datos.

Crear el Recurso de Clúster

Lógica Principal: El script redirige errores al log y luego gestiona la acción solicitada:

Start

• Limpia el log.

• Verifica si el monitor ya corre en BD.

• Lanza el procedimiento PL/SQL USUARIO_MONITORIZACION.pkg_monitor.monitor_main_loop en background con nohup.

• Espera a que la sesión aparezca en la BD, confirmando que el monitor está activo.

Stop

• Lista todas las sesiones activas.

• Mata cada sesión con kill_session_db.

• Verifica que no queden sesiones residuales.

Check

• Realiza hasta 3 intentos para comprobar que el monitor está corriendo.

• Retorna 0 si está activo y 1 si no.

Status

• Lista todas las sesiones activas.

• Retorna 0 si hay sesiones y 1 si no.

Dentro del paquete de monitorización indentificamos el módulo para ser capaces de ubicar exactamente las sesiones mediante (ejemplo): DBMS_APPLICATION_INFO.SET_MODULE('MODULO_MONITOR', 'capture_metrics');

Además, para que sea persistente, el paquete ejecuta en bucle el sql
LOOP
-- Ejecuta la captura de métricas
.....................
-- Espera de X segundo
DBMS_SESSION.SLEEP(C_SLEEP_CAPTURE);

END LOOP;

Código:

#!/bin/bash
# Script para Clusterware monitorizacion_app
# Ejecutado por usuario grid con sudo a oracle

ORACLE_HOME="/u01/app/oracle/product/19.xx"

# Ruta de log local al nodo
HOSTNAME=$(hostname -s)
LOG_FILE="/scripts/logs/monitor_app_${HOSTNAME}.log"

touch "$LOG_FILE" 2>/dev/null || true
chmod 664 "$LOG_FILE" 2>/dev/null || true

# Identificadores únicos para nuestro monitor
MODULE_NAME="MODULO_MONITOR"

# Credenciales
DB_USER="USUARIO_MONITORIZACION"
DB_PASSWORD="xxxxxxxxxxx"
DB_TNS_SERVICE="MONITORIZACION"

ACTION="$1"

# --- FUNCIONES ---

# Ejecutar SQL y devolver resultado
run_sql() {
    local sql="$1"
    sudo -u oracle /bin/bash -c "
        export ORACLE_HOME='$ORACLE_HOME'
        export PATH=\"\\(ORACLE_HOME/bin:\\)PATH\"

        sqlplus -S \(DB_USER/\)DB_PASSWORD@$DB_TNS_SERVICE <<'EOF'
SET FEEDBACK OFF
SET HEADING OFF
SET PAGESIZE 0
SET VERIFY OFF
SET TRIMSPOOL ON
SET LINESIZE 32767
$sql
EOF
" 2>/dev/null
}

# Verificar si el monitor está corriendo en BD
is_monitor_running_db() {
    local sql="
SELECT 'RUNNING:'||s.inst_id||':'||s.sid||':'||s.serial#||':'||s.process
FROM gv\$session s
WHERE s.username = UPPER('$DB_USER')
  AND s.module = '$MODULE_NAME'
  AND ROWNUM = 1
;
"

    local result
    result=\((run_sql "\)sql")

    if echo "$result" | grep -q "^RUNNING:"; then
        echo "$result" | sed 's/^RUNNING://'
        return 0
    else
        return 1
    fi
}

# Detener sesión en BD
kill_session_db() {
    local inst_id="$1"
    local sid="$2"
    local serial="$3"

    local sql="ALTER SYSTEM KILL SESSION '\(sid,\)serial,@$inst_id' IMMEDIATE;"

    run_sql "$sql" >/dev/null
    return $?
}

# Obtener todas las sesiones del monitor
get_all_monitor_sessions() {
    local sql="
SELECT
    s.inst_id||':'||s.sid||':'||s.serial#||':'||s.process
FROM gv\$session s
WHERE s.username = UPPER('$DB_USER')
  AND s.module = '$MODULE_NAME'
;
"

    run_sql "$sql"
}

# --- LÓGICA PRINCIPAL ---

exec 2>>"$LOG_FILE"

case "$ACTION" in
start)
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Iniciando monitor..." >&2

    # Limpiar log solo al inicio
    echo "=== MONITOR INICIADO \((date '+%Y-%m-%d %H:%M:%S') ===" > "\)LOG_FILE"

    # Verificar si ya está corriendo en BD
    if session_info=$(is_monitor_running_db); then
        IFS=':' read -r inst_id sid serial process <<< "$session_info"
        echo "[$(date '+%Y-%m-%d %H:%M:%S')] Monitor ya está corriendo en BD:" >&2
        echo "  Instancia: \(inst_id, SID: \)sid, Serial#: $serial" >&2
        exit 0
    fi

    # Iniciar el proceso
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Ejecutando procedimiento de monitorización..." >&2

    # Lanzar proceso en background usando nohup
    nohup sudo -u oracle /bin/bash -c "
        export ORACLE_HOME='$ORACLE_HOME'
        export PATH=\"\\(ORACLE_HOME/bin:\\)PATH\"
        export LD_LIBRARY_PATH=\"\\(ORACLE_HOME/lib:\\)LD_LIBRARY_PATH\"

        sqlplus -S \(DB_USER/\)DB_PASSWORD@\(DB_TNS_SERVICE <<'SQL_EOF' >> \"\)LOG_FILE\" 2>&1
SET SERVEROUTPUT ON SIZE UNLIMITED

BEGIN
    USUARIO_MONITORIZACION.pkg_monitor.monitor_main_loop;
EXCEPTION
    WHEN OTHERS THEN
        DBMS_OUTPUT.PUT_LINE('[' || TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS') || '] ERROR: ' || SQLERRM);
        RAISE;
END;
/
SQL_EOF
    " >/dev/null 2>&1 &

    # Esperar y verificar registro en BD
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Esperando registro en BD..." >&2

    for i in {1..10}; do
        if session_info=$(is_monitor_running_db); then
            IFS=':' read -r inst_id sid serial process <<< "$session_info"
            echo "[$(date '+%Y-%m-%d %H:%M:%S')] Monitor funcionando:" >&2
            echo "  Instancia: \(inst_id, SID: \)sid, Serial#: $serial" >&2
            exit 0
        fi
        sleep 3
    done

    echo "[$(date '+%Y-%m-%d %H:%M:%S')] ERROR: No se registró en BD después de 30 segundos" >&2
    exit 1
    ;;

stop)
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Deteniendo monitor..." >&2

    # Obtener todas las sesiones
    sessions=$(get_all_monitor_sessions)

    if [ -z "$sessions" ]; then
        echo "[$(date '+%Y-%m-%d %H:%M:%S')] No hay sesiones activas" >&2
        exit 0
    fi

    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Sesiones encontradas:" >&2
    while IFS= read -r session_line; do
        [ -z "$session_line" ] && continue
        IFS=':' read -r inst_id sid serial process <<< "$session_line"
        echo "  Instancia: \(inst_id, SID: \)sid, Serial#: \(serial, Process: \)process" >&2
    done <<< "$sessions"

    # Matar cada sesión 
    while IFS= read -r session_line; do
        [ -z "$session_line" ] && continue
        IFS=':' read -r inst_id sid serial process <<< "$session_line"
        echo "  Matando: Instancia \(inst_id, SID \)sid, Serial# \(serial", Process: \)process >&2
        kill_session_db "\(inst_id" "\)sid" "$serial" 
    done <<< "$sessions"

    sleep 2
    if remaining_sessions=\((get_all_monitor_sessions); [ -n "\)remaining_sessions" ]; then
        echo "[$(date '+%Y-%m-%d %H:%M:%S')]  Aún hay sesiones después de KILL SESSION:" >&2
        while IFS= read -r line; do
            IFS=':' read -r i s se p <<< "$line"
            echo "  Instancia: \(i, SID: \)s, Serial#: \(se, Process: \)p" >&2
        done <<< "$remaining_sessions"
    else
        echo "[$(date '+%Y-%m-%d %H:%M:%S')] Todas las sesiones eliminadas" >&2
    fi

    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Comando stop completado" >&2
    exit 0
    ;;

check)
    # Clusterware: exit 0 si está corriendo, 1 si no
    # Intentar varias veces con pausas cortas
    max_attempts=3
    wait_seconds=5

    for attempt in \((seq 1 \)max_attempts); do
        if session_info=$(is_monitor_running_db); then
            IFS=':' read -r inst_id sid serial process <<< "$session_info"
            echo "[\((date '+%Y-%m-%d %H:%M:%S')] Monitor corriendo (Intento \)attempt/\(max_attempts) - Instancia: \)inst_id, SID: $sid" >&2
            exit 0
        fi

        if [ \(attempt -lt \)max_attempts ]; then
            echo "[\((date '+%Y-%m-%d %H:%M:%S')]  Check falló (Intento \)attempt/\(max_attempts), reintentando en \){wait_seconds}s..." >&2
            sleep $wait_seconds
        fi
    done

    echo "[\((date '+%Y-%m-%d %H:%M:%S')] Monitor no corriendo después de \)max_attempts intentos" >&2
    exit 1
    ;;

status)
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Estado del monitor:" >&2

    sessions=$(get_all_monitor_sessions)

    if [ -n "$sessions" ]; then
        echo "Sesiones activas:" >&2
        while IFS= read -r line; do
            IFS=':' read -r inst_id sid serial process <<< "$line"
            echo "  Instancia: \(inst_id, SID: \)sid, Serial#: \(serial, Process: \)process" >&2
        done <<< "$sessions"
        exit 0
    else
        echo "No hay sesiones activas" >&2
        exit 1
    fi
    ;;

*)
    echo "Uso: $0 {start|stop|check|status}" >&2
    exit 1
    ;;
esac

Crear el Recurso de Clúster

El recurso se crea mediante crsctl:

crsctl add resource monitorizacion_app \
-type cluster_resource \
-attr "ACTION_SCRIPT='/scripts/monitorizacion_resource.sh', \
DESCRIPTION='Proceso persistente de monitorización', \
START_DEPENDENCIES='hard(ora.BASEDEDATOS.MONITORIZACION.svc)', \
STOP_DEPENDENCIES='hard(ora.BASEDEDATOS.MONITORIZACION.svc)', \
RESTART_ATTEMPTS=5, \
CHECK_INTERVAL=30, \
START_TIMEOUT=60, \
STOP_TIMEOUT=60, \
HOSTING_MEMBERS='node1 node2', \
PLACEMENT='restricted', \
CARDINALITY=1, \
ACTIONS='START,user:oracle STOP,user:oracle CHECK'"

Explicación de los parámetros:

Asignar Permisos de Ejecución al Recurso

crsctl setperm resource monitorizacion_app -u user:oracle:r-x

Esto permite que Clusterware ejecute el script como el usuario oracle de manera segura.

Gestión del Recurso

Una vez creado, puedes:

# Iniciar
crsctl start resource monitorizacion_app

# Parar
crsctl stop resource monitorizacion_app

# Verificar estado
crsctl status resource monitorizacion_app

Pruebas Reales de Dependencias y Relocalización del Recurso

Una vez creado el recurso monitorizacion_app y vinculado mediante dependencia hard a un servicio de base de datos, realizamos pruebas para validar:

• Que el recurso bloquea el stop del servicio si está activo

• Que las dependencias se respetan

• Que el recurso puede moverse correctamente entre nodos

• Que el kill de sesión se ejecuta correctamente

• Que el estado final queda consistente

Validación de Dependencia Hard

Intentamos parar el servicio asociado:

srvctl stop service -d BASEDEDATOS -s monitorizacion -i BASEDEDATOS1
PRCD-1316 : fallo al parar los servicios monitorizacion para la base de datos BASEDEDATOS
PRCR-1132 : Fallo al parar los recursos mediante un filtro
CRS-2974: no se ha podido actuar en el recurso 'ora.BASEDEDATOS.MONITORIZACION.svc' en el servidor 'node1' porque sería necesario parar o reubicar el recurso 'monitorizacion_app', pero no se ha especificado el indicador de forzado apropiado


crsctl status resource monitorizacion_app
NAME=monitorizacion_app
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on node1

Relocate Manual del Recurso

Mueve dependencias:

crsctl relocate resource monitorizacion_app -n nodo2

Attempting to start 'ora.BASEDEDATOS.MONITORIZACION.svc' on 'nodo2'
Start of 'ora.BASEDEDATOS.MONITORIZACION.svc' succeeded
Attempting to stop 'monitorizacion_app' on 'nodo1'
Stop of 'monitorizacion_app' on 'nodo1' succeeded
Attempting to start 'monitorizacion_app' on 'nodo2'
Start of 'monitorizacion_app' on 'nodo2' succeeded

-- Secuencia de eventos
crsctl status resource monitorizacion_app
NAME=monitorizacion_app
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on nodo1

crsctl status resource monitorizacion_app
NAME=monitorizacion_app
TYPE=cluster_resource
TARGET=ONLINE
STATE=OFFLINE

crsctl status resource monitorizacion_app
NAME=monitorizacion_app
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on nodo2

-- Veremos en el alertlog
(3):KILL SESSION for sid=(2855, 32280):
(3):  Reason = alter system kill session
(3):  Mode = KILL HARD SAFE -/-/-
(3):  Requestor = USER (orapid = 309, ospid = 810697, inst = 1)
(3):  Owner = Process: USER (orapid = 150, ospid = 3169885)
(3):  Result = ORA-31

Parada y arranque

crsctl stop resource monitorizacion_app

-- Veremos en el alertlog
(3):KILL SESSION for sid=(2855, 32280):
(3):  Reason = alter system kill session
(3):  Mode = KILL HARD SAFE -/-/-
(3):  Requestor = USER (orapid = 309, ospid = 810697, inst = 1)
(3):  Owner = Process: USER (orapid = 150, ospid = 3169885)
(3):  Result = ORA-31

crsctl start resource monitorizacion_app

Ejemplo registro log

-- Ejemplo arranque
more /scripts/logs/monitor_app_nodo1.log
=== MONITOR INICIADO 2026-02-03 22:02:08 ===
[2026-02-03 22:02:08] Ejecutando procedimiento de monitorización...
[2026-02-03 22:02:08] Esperando registro en BD...
[2026-02-03 22:02:12] Monitor funcionando:
  Instancia: 1, SID: 3320, Serial#: 54019
[2026-02-03 22:02:12] Monitor corriendo (Intento 1/3) - Instancia: 1, SID: 3320
[2026-02-03 22:02:42] Monitor corriendo (Intento 1/3) - Instancia: 1, SID: 3320
[2026-02-03 22:03:12] Monitor corriendo (Intento 1/3) - Instancia: 1, SID: 3320
[2026-02-03 22:03:42] Monitor corriendo (Intento 1/3) - Instancia: 1, SID: 3320
[2026-02-03 22:04:12] Monitor corriendo (Intento 1/3) - Instancia: 1, SID: 3320
[2026-02-03 22:04:42] Monitor corriendo (Intento 1/3) - Instancia: 1, SID: 3320
[2026-02-03 22:05:12] Monitor corriendo (Intento 1/3) - Instancia: 1, SID: 3320

-- Ejemplo parada


[2025-12-10 12:51:19] Deteniendo monitor...
[2025-12-10 12:51:19] Sesiones encontradas:
  Instancia: 1, SID: 5197, Serial#: 59722, Process: 3928045
  Matando: Instancia 1, SID 5197, Serial# 59722, Process: 3928045
ERROR:
ORA-03114: not connected to ORACLE


BEGIN
*
ERROR at line 1:
ORA-00028: your session has been killed
ORA-06512: at "SYS.DBMS_SESSION", line 435
ORA-06512: at "USUARIO_MONITORIZACION.PKG_MONITOR", line 236
ORA-06512: at line 2


[2025-12-10 12:51:21] Todas las sesiones eliminadas
[2025-12-10 12:51:21] Comando stop completado
[2025-12-10 12:51:21]  Check falló (Intento 1/3), reintentando en 5s...
[2025-12-10 12:51:26]  Check falló (Intento 2/3), reintentando en 5s...
[2025-12-10 12:51:31] Monitor no corriendo después de 3 intentos

Ventajas de Esta Configuración

• Persistencia: El monitor se asegura de que siempre haya una sesión activa.

• Alta disponibilidad: Puede moverse a otro nodo si falla el nodo actual.

• Integración con servicios: Solo arranca si el servicio de base de datos está disponible.

• Control total: Inicio/parada manual, chequeo de estado, reinicio automático.

Conclusión

En nuestro caso necesitábamos que el proceso sobreviviese a relocalizaciones del servicio y que no dependiese de un cron externo. Después de probar varias alternativas ( job scheduler, etc.), la opción de recurso gestionado por Clusterware resultó ser la más limpia operativamente.

Permite:

• Ejecutar scripts críticos vinculados a servicios.

• Gestionar fallos y reinicios automáticos.

• Mantener alta disponibilidad y control operativo.

select sum(bytes/1024/1024/1024) Gb from dba_segments where segment_name='TABLA';

        GB
----------
94,0537109


select sum(bytes/1024/1024/1024) Gb from dba_segments where segment_name='INDICE_TABLA'

        GB
----------
95,1396484

La tabla está particionada y tiene volumetrías similares en cada partición.

En entorno replicado comprobamos si recuperamos el espacio después de un rebuild:

SET SERVEROUTPUT ON
DECLARE
    v_sql VARCHAR2(1000);
BEGIN
    FOR rec IN (
        SELECT index_name, partition_name
        FROM dba_ind_partitions
        WHERE index_name = 'INDICE_TABLA'
          AND index_owner = 'PROPIETARIO'
        ORDER BY partition_name
    ) LOOP
        v_sql := 'ALTER INDEX PROPIETARIO.' || rec.index_name || 
                 ' REBUILD PARTITION ' || rec.partition_name || 
                 ' ONLINE';
        DBMS_OUTPUT.PUT_LINE('Ejecutando: ' || v_sql);
        EXECUTE IMMEDIATE v_sql;
    END LOOP;
END;
/

Ejecutando: ALTER INDEX PROPIETARIO.INDICE_TABLA REBUILD PARTITION SYS_P15950 ONLINE
Ejecutando: ALTER INDEX PROPIETARIO.INDICE_TABLA REBUILD PARTITION SYS_P16003 ONLINE
Ejecutando: ALTER INDEX PROPIETARIO.INDICE_TABLA REBUILD PARTITION SYS_P16051 ONLINE
Ejecutando: ALTER INDEX PROPIETARIO.INDICE_TABLA REBUILD PARTITION SYS_P16091 ONLINE
Ejecutando: ALTER INDEX PROPIETARIO.INDICE_TABLA REBUILD PARTITION SYS_P16160 ONLINE
Ejecutando: ALTER INDEX PROPIETARIO.INDICE_TABLA REBUILD PARTITION SYS_P16173 ONLINE


PL/SQL procedure successfully completed.
Elapsed: 00:52:08.117

select sum(bytes/1024/1024/1024) Gb from dba_segments where segment_name='INDICE_TABLA'

        GB
----------
57,2919922

Vemos que recuperamos ~38 GB. Investigo para ponerle cara.

1. Índice y estructura de la tabla

Tabla con tipos de datos

Índice B-tree particionado denominado INDICE_TABLA sobre (ITEM, EVENT_DATE).

En primera instancia compruebo si hay bloques no ocupados. Nos vale con una partición, todas son similares.

SET SERVEROUTPUT ON
DECLARE
    v_total_blocks      NUMBER;
    v_total_bytes       NUMBER;
    v_unused_blocks     NUMBER;
    v_unused_bytes      NUMBER;
    v_last_file_id      NUMBER;
    v_last_extent_block NUMBER;
    v_last_used_block   NUMBER;
BEGIN
    DBMS_SPACE.UNUSED_SPACE(
        segment_owner             => 'PROPIETARIO',
        segment_name              => 'INDICE_TABLA',
        segment_type              => 'INDEX PARTITION',
        total_blocks              => v_total_blocks,
        total_bytes               => v_total_bytes,
        unused_blocks             => v_unused_blocks,
        unused_bytes              => v_unused_bytes,
        last_used_extent_file_id  => v_last_file_id,
        last_used_extent_block_id => v_last_extent_block,
        last_used_block           => v_last_used_block,
        partition_name            => 'SYS_P16051'
    );

    DBMS_OUTPUT.PUT_LINE('Partición SYS_P16003:');
    DBMS_OUTPUT.PUT_LINE('  Total Blocks : ' || v_total_blocks);
    DBMS_OUTPUT.PUT_LINE('  Unused Blocks: ' || v_unused_blocks);
    DBMS_OUTPUT.PUT_LINE('  Unused Bytes : ' || ROUND(v_unused_bytes/1024/1024,2) || ' MB');
END;
/

Partición SYS_P16003:
  Total Blocks : 2247296
  Unused Blocks: 0
  Unused Bytes : 0 MB

Observaciones clave

1. No hay espacio no utilizado:

   • DBMS_SPACE.UNUSED_SPACE devuelve 0 unused

   • La fragmentación no es PCTFREE ni filas borradas.

2. Splits de leaf nodes no se monitorizan directamente en Oracle:

   • No hay vista que liste “splits ocurridos”.

   • Solo se puede estimar a partir de diferencias entre bloques reales vs bloques teóricos.

3. Rebuild recupera el espacio:

   • Compacta los leaf nodes y reduce los 50/50 y 99/1 parcialmente llenos.

   • Reducción observada en este ejemplo: ~38 GB.

Investigamos splits

Tipos de split en Oracle 19c

Antes de nada explico los distintos tipos de split en Oracle.

50/50 Split

• La nueva clave no es la mayor del bloque → bloque viejo y bloque nuevo ~50 % llenos.

• Ocurre cuando varias filas tienen el mismo ITEM y se insertan fechas intermedias (EVENT_DATE).

Bloque inicial (capacidad 5):

I1-2026-02-10
I1-2026-02-11
I2-2026-02-09
I2-2026-02-10
I3-2026-02-08

Insertamos I2-2026-02-09.5 → split 50/50

Bloque viejo        Bloque nuevo
I1-2026-02-10      I2-2026-02-09.5
I1-2026-02-11      I2-2026-02-10
I2-2026-02-09      I3-2026-02-08

99/1 Split

• La nueva clave es la mayor → bloque viejo ~99 % lleno, bloque nuevo casi vacío.

• Minimiza desperdicio y ocurre con fechas crecientes.

Bloque viejo inicial (ITEM I1):

I1-2026-02-10
I1-2026-02-11

Insertamos I1-2026-02-12 → split 99/1

Bloque viejo        Bloque nuevo
I1-2026-02-10      I1-2026-02-12
I1-2026-02-11

Conceptos clave de ocupación de bloques

• ROWID: 6 bytes por fila, puntero físico.

• Overhead de entrada: ~3 bytes (flags, punteros, longitud de clave).

• Tamaño promedio de entrada de índice: avg_index_entry_size = 20 bytes

• Ajuste para ramas internas: +10 % → 22 bytes/fila

• Factor de ocupación máximo post-rebuild: 95 %

Para el tamaño promedio de entrada de índice calculo cúanto debería ocupar cada entrada:

SELECT ROUND(AVG(vsize(ITEM) + vsize(EVENT_DATE) + 6 + 3)) AS avg_index_entry_size
FROM PROPIETARIO.TABLA partition(SYS_P16160);

avg_index_entry_size
--------------------
20

Y con ésta fórmula calcularíamos los bloques teóricos:

blocks_teoricos = num_rows * avg_index_entry_size / (db_block_size * block_occupancy_factor)

Comparando con bloques reales obtenemos el espacio extra generado por splits.

Análisis de MB recuperables

Tener en cuenta que es una tabla donde se inserta constantemente, los valores son superiores a la primera estimación de espacio puesto que se ha realizado posteriormente (pasamos de 95Gb de volumetría de tabla a 109Gb aprox)

-- ===============================================
-- Script para estimación de MB recuperables
-- ===============================================

-- Variables
VAR block_size NUMBER
VAR avg_index_entry_size NUMBER
VAR block_occupancy_factor NUMBER

EXEC :block_size := 8192;               -- tamaño del bloque en bytes
EXEC :avg_index_entry_size := 22;       -- bytes por fila (clave + ROWID + overhead de rama)
EXEC :block_occupancy_factor := 0.95;   -- factor de ocupación realista post-rebuild

-- Formato de salida
COLUMN partition_name FORMAT A15
COLUMN num_rows FORMAT 999,999,999
COLUMN blocks FORMAT 999,999,999
COLUMN blocks_teoricos FORMAT 999,999,999
COLUMN diff_blocks FORMAT 999,999,999
COLUMN size_mb FORMAT 999,999.99
COLUMN est_mb_recover FORMAT 999,999.99
COLUMN occupancy_pct FORMAT 999.99

-- Fragmentación por partición ajustada
SELECT 
    i.partition_name,
    i.num_rows,
    s.blocks,
    ROUND(i.num_rows * :avg_index_entry_size / (:block_size * :block_occupancy_factor)) AS blocks_teoricos,
    s.blocks - ROUND(i.num_rows * :avg_index_entry_size / (:block_size * :block_occupancy_factor)) AS diff_blocks,
    ROUND(s.bytes/1024/1024,2) AS size_mb,
    ROUND((s.blocks - ROUND(i.num_rows * :avg_index_entry_size / (:block_size * :block_occupancy_factor))) 
          * :block_size / 1024/1024,2) AS est_mb_recover,
    ROUND((i.num_rows * :avg_index_entry_size) / s.bytes * 100,2) AS occupancy_pct
FROM dba_ind_partitions i
JOIN dba_segments s
  ON i.index_name = s.segment_name
 AND i.partition_name = s.partition_name
 AND i.index_owner = s.owner
WHERE i.index_owner = 'PROPIETARIO'
  AND i.index_name = 'INDICE_TABLA'
ORDER BY i.partition_position;

-- Total del índice ajustado
SELECT 
    ROUND(SUM(s.bytes)/1024/1024,2) AS total_size_mb,
    ROUND(SUM(i.num_rows * :avg_index_entry_size)/1024/1024,2) AS total_used_mb,
    ROUND(SUM((s.blocks - ROUND(i.num_rows * :avg_index_entry_size / (:block_size * :block_occupancy_factor))) 
              * :block_size)/1024/1024,2) AS total_est_mb_recover,
    ROUND(SUM(i.num_rows * :avg_index_entry_size)/SUM(s.bytes)*100,2) AS total_occupancy_pct
FROM dba_ind_partitions i
JOIN dba_segments s
  ON i.index_name = s.segment_name
 AND i.partition_name = s.partition_name
 AND i.index_owner = s.owner
WHERE i.index_owner = 'PROPIETARIO'
  AND i.index_name = 'INDICE_TABLA';

PARTITION_NAME      NUM_ROWS       BLOCKS BLOCKS_TEORICOS  DIFF_BLOCKS     SIZE_MB EST_MB_RECOVER OCCUPANCY_PCT
--------------- ------------ ------------ --------------- ------------ ----------- -------------- -------------
SYS_P15950       435,119,799    2,328,320       1,230,036    1,098,284   18,190.00       8,580.34         50.19
SYS_P16003       418,392,746    2,390,144       1,182,751    1,207,393   18,673.00       9,432.76         47.01
SYS_P16051       409,281,521    2,247,296       1,156,994    1,090,302   17,557.00       8,517.98         48.91
SYS_P16091       414,177,258    2,487,936       1,170,834    1,317,102   19,437.00      10,289.86         44.71
SYS_P16160       435,751,783    2,511,744       1,231,823    1,279,921   19,623.00       9,999.38         46.59
SYS_P16173       330,935,423    2,032,512         935,519    1,096,993   15,879.00       8,570.26         43.73



TOTAL_SIZE_MB TOTAL_USED_MB TOTAL_EST_MB_RECOVER TOTAL_OCCUPANCY_PCT
------------- ------------- -------------------- -------------------
       109359         51270             55390,59               46,88

Teniendo en consideración los conceptos clave detallados anteriormente:

Resultados resumidos por partición

Totales:

• Tamaño actual: ~109 GB

• Tamaño usado: ~51 GB

• Tamaño recuperable: ~55 GB

• Ocupación global: 46 %

Conclusión

Tras analizar el comportamiento del índice B-tree sobre (ITEM NUMBER, EVENT_DATE DATE), podemos relacionar todos los elementos observados y entender claramente el origen de la fragmentación.

En primer lugar, descartamos causas clásicas:

• No existen DELETEs ni actualizaciones que reduzcan cardinalidad.

• DBMS_SPACE.UNUSED_SPACE devuelve 0 bloques sin uso por lo que no hay espacio sin formatear dentro del segmento.

• El PCTFREE no explica una ocupación cercana al 46 %, ya que incluso tras un rebuild Oracle puede llenar los leaf nodes hoja hasta ~90–95 %.

Por tanto, la diferencia entre:

• ~109 GB de tamaño real

• ~51 GB de tamaño teórico necesario

• ~55 GB recuperables tras rebuild

no puede atribuirse a espacio no utilizado, sino a leaf nodes parcialmente ocupados generados por splits.

El análisis del patrón de inserción explica el fenómeno:

• ITEM (NUMBER) no es consecutivo.

• EVENT_DATE (DATE) es creciente dentro de cada ITEM.

• El índice está ordenado por (ITEM, EVENT_DATE).

Esto provoca una combinación de comportamientos:

• Cuando se insertan claves intermedias dentro del rango de un mismo ITEM, se producen splits 50/50, dejando dos bloques aproximadamente al 50 % de ocupación.

• Cuando la nueva clave es la mayor dentro del bloque (fecha creciente al final), se producen splits 99/1, que también introducen bloques parcialmente vacíos.

A gran escala (cientos de millones de filas por partición), la acumulación de estos splits explica matemáticamente la ocupación observada (~44–50 %).

Además, Oracle no proporciona una vista que permita monitorizar directamente cuántos splits han ocurrido. El único modo práctico de detectarlos es indirectamente, comparando:

• Bloques reales del segmento

• Bloques teóricos necesarios según el tamaño medio de entrada

Cuando la desviación es estructural, homogénea entre particiones y coherente con el patrón de inserción, la explicación más sólida es el comportamiento interno del B-tree ante splits de leaf nodes.

En definitiva:

La fragmentación observada no es un síntoma de corrupción ni de mala configuración, sino una consecuencia natural del algoritmo de mantenimiento del B-tree bajo un patrón específico de inserciones.

El rebuild no “arregla un problema lógico”, sino que simplemente recompone los leaf nodes eliminando el espacio generado por años de splits acumulados.

Antes de entender qué hace el script de clonado, es importante comprender cómo modela ORDS una API internamente.

ORDS no trabaja con “endpoints sueltos”, sino con una jerarquía bien definida.

El diagrama resume esta estructura:

Módulo
 └── Template (ruta)
      └── Handler (método HTTP)
           └── Parámetros

Por ejemplo:

/JsonConsulta/v1
/JsonConsulta/v2

El nombre del API y del recurso se mantiene, y lo único que queremos cambiar es la versión (v1, v2, etc.) en nuestro caso.

El problema es que ORDS no permite clonar un endpoint desde la consola web.

Cuando un endpoint tiene:

• SQL complejo

• Múltiples parámetros

• Lógica probada en producción

Copiarlo a mano para una nueva versión es lento y propenso a errores.

Para resolver esto, se puede clonar directamente el endpoint desde el diccionario de ORDS, usando PL/SQL.

Objetivo del script

Este procedimiento:

• Clona un endpoint ORDS existente (v1) a una nueva versión (v2) o simplemente copiarlo con un nombre nuevo.

• Mantiene el mismo módulo

• Copia handlers, SQL y parámetros

• Evita duplicados (puede ejecutarse más de una vez sin romper nada)

Está pensado especialmente para entornos donde se quiere evolucionar una API sin tocar la versión anterior.

Script completo de clonado de endpoint ORDS

Para tener el proceso controlado conectamos con el propietario del esquema ORDS.

Variables principales

v_module_name := 'nombremodulo'; 
v_template_src := 'nombretemplateorigen/vx';
v_template_dst := 'nombretemplatedestino/vx';

• Módulo ORDS donde existe el API

• Template origen (endpoint actual)

• Template destino (nueva versión)

SET SERVEROUTPUT ON

DECLARE
    v_module_id       NUMBER;
    v_template_exists NUMBER;
    v_handler_exists  NUMBER;
    v_param_exists    NUMBER;

    -- Nombre lógico del módulo
    v_module_name     VARCHAR2(100) := 'nombremodulo';

    -- Template origen y template destino (clonado)
    v_template_src    VARCHAR2(100) := 'JsonConsulta/v1';
    v_template_dst    VARCHAR2(100) := 'JsonConsulta/v2';

BEGIN
    -- Obtener el ID del módulo ORDS
    SELECT id
    INTO v_module_id
    FROM user_ords_modules
    WHERE name = v_module_name;

    -- Crear el template destino si no existe
    SELECT COUNT(*)
    INTO v_template_exists
    FROM user_ords_templates
    WHERE module_id = v_module_id
      AND uri_template = v_template_dst;

    IF v_template_exists = 0 THEN
        ORDS.DEFINE_TEMPLATE(
            p_module_name => v_module_name,
            p_pattern     => v_template_dst,
            p_priority    => 0,
            p_etag_type   => 'HASH',
            p_comments    => 'Clonado desde ' || v_template_src
        );
        DBMS_OUTPUT.PUT_LINE('Template ' || v_template_dst || ' creado.');
    ELSE
        DBMS_OUTPUT.PUT_LINE('Template ' || v_template_dst || ' ya existe.');
    END IF;

    -- Clonar todos los handlers (GET, POST, etc.)
    FOR src_handler IN (
        SELECT h.method,
               h.source_type,
               h.source,
               h.items_per_page,
               h.mimes_allowed,
               h.comments
        FROM user_ords_handlers h
        JOIN user_ords_templates t ON h.template_id = t.id
        WHERE t.module_id = v_module_id
          AND t.uri_template = v_template_src
        ORDER BY h.id
    ) LOOP
        SELECT COUNT(*)
        INTO v_handler_exists
        FROM user_ords_handlers h
        JOIN user_ords_templates t ON h.template_id = t.id
        WHERE t.module_id = v_module_id
          AND t.uri_template = v_template_dst
          AND h.method = src_handler.method;

        IF v_handler_exists = 0 THEN
            ORDS.DEFINE_HANDLER(
                p_module_name    => v_module_name,
                p_pattern        => v_template_dst,
                p_method         => src_handler.method,
                p_source_type    => src_handler.source_type,
                p_items_per_page => src_handler.items_per_page,
                p_mimes_allowed  => src_handler.mimes_allowed,
                p_comments       => 'Clonado desde ' || v_template_src,
                p_source         => src_handler.source
            );
            DBMS_OUTPUT.PUT_LINE(
                'Handler ' || src_handler.method || ' creado.'
            );
        ELSE
            DBMS_OUTPUT.PUT_LINE(
                'Handler ' || src_handler.method || ' ya existe.'
            );
        END IF;
    END LOOP;

    -- Clonar los parámetros de cada handler
    FOR src_param IN (
        SELECT p.name,
               p.bind_variable_name,
               p.source_type,
               p.param_type,
               p.access_method,
               p.comments,
               h.method
        FROM user_ords_parameters p
        JOIN user_ords_handlers h ON p.handler_id = h.id
        JOIN user_ords_templates t ON h.template_id = t.id
        WHERE t.module_id = v_module_id
          AND t.uri_template = v_template_src
        ORDER BY h.method, p.name
    ) LOOP
        SELECT COUNT(*)
        INTO v_param_exists
        FROM user_ords_parameters p
        JOIN user_ords_handlers h ON p.handler_id = h.id
        JOIN user_ords_templates t ON h.template_id = t.id
        WHERE t.module_id = v_module_id
          AND t.uri_template = v_template_dst
          AND p.name = src_param.name
          AND h.method = src_param.method;

        IF v_param_exists = 0 THEN
            ORDS.DEFINE_PARAMETER(
                p_module_name        => v_module_name,
                p_pattern            => v_template_dst,
                p_method             => src_param.method,
                p_name               => src_param.name,
                p_bind_variable_name => src_param.bind_variable_name,
                p_source_type        => src_param.source_type,
                p_param_type         => src_param.param_type,
                p_access_method      => src_param.access_method,
                p_comments           => src_param.comments
            );
            DBMS_OUTPUT.PUT_LINE(
                'Parámetro ' || src_param.name ||
                ' (' || src_param.method || ') creado.'
            );
        ELSE
            DBMS_OUTPUT.PUT_LINE(
                'Parámetro ' || src_param.name ||
                ' (' || src_param.method || ') ya existe.'
            );
        END IF;
    END LOOP;

    COMMIT;
    DBMS_OUTPUT.PUT_LINE('Clonación del endpoint completada.');

END;
/

Ejemplo salida:

Template JsonConsulta/v2 creado. 
Handler JsonConsulta/v2 [GET] creado. 
Parametro parm1 para método GET creado. 
Parametro parm2 para método GET creado. 
Parametro parm3 para método GET creado. 
Parametro parm4 para método GET creado. 
Parametro parm5 para método GET creado.
Parametro parm6 para método GET creado. 
Parametro parm7 para método GET creado. 
Parametro parm8 para método GET creado. 
Parametro parm9 para método GET creado. 
Parametro parm10 para método GET creado. 
Parametro parm11 para método GET creado. 
Clonación completada exitosamente. 
PL/SQL procedure successfully completed.

¿Qué hace realmente este script?

A alto nivel, el procedimiento reproduce internamente lo que haríamos a mano en ORDS, pero de forma segura:

• Usa las vistas USER_ORDS_* para leer la definición actual del API

• Replica exactamente:

  • La ruta del endpoint (solo cambia la versión/nombre)

  • Los métodos HTTP

  • El SQL asociado

  • Todos los parámetros y binds

• Comprueba siempre si algo ya existe antes de crearlo

Esto permite ejecutar el script varias veces sin riesgo y mantener un versionado limpio y controlado.

¿Por qué hacerlo así y no a mano?

✔ Evita errores copiando SQL
✔ Permite versionado limpio de APIs
✔ Es repetible y controlado
✔ Suple una limitación real de la consola ORDS

Especialmente útil en:

• Entornos de pruebas

• Versionado de APIs

• Cambios controlados antes de producción

Conclusión

Aunque ORDS es una herramienta potente, no todo se puede hacer desde la consola web.

Conociendo su diccionario interno y las APIs PL/SQL (ORDS.DEFINE_*), es posible automatizar tareas avanzadas como el clonado completo de endpoints.

Este procedimiento convierte una tarea manual y propensa a errores en un proceso seguro y limpio.

Y como refrexión personal, poner botón para clonar un endpoint desde la consola web por lo que vemos no debería ser tan complejo implementarlo.

Recientemente, investigamos un caso donde el sistema presentaba picos de CPU cíclicos (cada media hora exacta). En esta entrada, detallo cómo identificamos al responsable y el procedimiento para estabilizar el entorno.

1. El hallazgo: Investigando con OSWatcher (OSW)

Todo comenzó analizando los datos históricos de OSWatcher. Al revisar los archivos de procesos (ps), detectamos un patrón recurrente. Varios procesos de Perl ejecutados como root realizaban modificaciones de inventario con el flag -collectall de forma persistente:

[grid@rac-node-001 oswps]$ grep -i collectall *.dat
rac-node-001.internal_ps_25.11.30.2200.dat:root   13603   9521  19 13.6  S 22:09:28 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/agent/... -collectall
rac-node-001.internal_ps_25.11.30.2200.dat:root   16113   9521  19 36.2  S 22:10:00 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/product/19.26/... -collectall
rac-node-001.internal_ps_25.11.30.2200.dat:root  138557 134853  19  7.2  S 22:39:27 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/agent/... -collectall
rac-node-001.internal_ps_25.11.30.2200.dat:root  140654 134853  19  8.7  S 22:39:58 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/product/19.26/... -collectall
rac-node-001.internal_ps_25.12.01.1500.dat:root   69691  65697  19  6.1  S 15:09:29 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/agent/... -collectall
rac-node-001.internal_ps_25.12.01.1500.dat:root   72082  65697  19  7.3  S 15:10:00 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/product/19.26/... -collectall

2. Anatomía del problema: El árbol de procesos

Para entender el origen, mapeamos la jerarquía del demonio de TFA (Trace File Analyzer). Identificamos que el disparador era una tarea de "redescubrimiento" automática:

Estructura del proceso:

• TFA Daemon (Java TFAMain): El proceso padre persistente.

  • tfactl rediscover -mode lite -auto: El comando encargado de buscar cambios en el entorno.

    • tfactl.pl rediscover: El script de ejecución.

      • tfactl.pl directory modify ... -collectall: Las tareas finales que impactaban en la CPU al escanear directorios de inventario (DB, Agentes, etc).

Revelando la Jerarquía: ¿Quién consume mi CPU?

Para entender por qué el servidor presentaba picos de carga, no basta con ver un proceso suelto; es necesario entender la relación padre-hijo. Utilizando los datos de OSWatcher (OSW) y rastreando los PIDs (Process IDs) mediante ps -ef, logramos reconstruir el árbol genealógico del culpable.

La Raíz: El Demonio TFA

Todo nace del TFA Daemon (PID 2616695 en nuestro caso), con el proceso Java (oracle.rat.tfa.TFAMain) que corre como root. Este demonio mantiene varios hilos vivos para monitorizar eventos , pero el "ruido" venía de su rama de descubrimiento.

El Descenso: De Java a Perl

Al investigar el PID padre, vimos cómo el demonio invoca una cadena de comandos para realizar el mantenimiento del inventario:

1. El Iniciador: El demonio lanza un script shell tfactl rediscover.

2. La Capa Python: Este a su vez llama a un componente empaquetado (tfactl.egg) que gestiona la lógica de AHF.

3. El Motor Perl: Finalmente, la ejecución recae en scripts de Perl (tfactl.pl), que es donde se realiza el trabajo pesado de interacción con el sistema de archivos.

El "Fumigador": El proceso collectall

El punto crítico aparece en los procesos hoja (los últimos de la rama). Identificamos múltiples procesos Perl ejecutando: tfactl.pl directory modify <path> -collectall -private

Estos procesos son los que escanean recursivamente directorios críticos como:

• El inventario del Agente de Enterprise Manager (/u01/app/oracle/agent/...).

• El inventario del Home de la Base de Datos (/u01/app/oracle/product/19.26/...).

• Etc.

Representación del Árbol de Ejecución

Así es como se ve la cascada de ejecución que capturamos durante el pico de consumo:

TFA Daemon (PID 2616695) – TFAMain (Java)
└─ sh tfactl rediscover (PID 9325)
   └─ python tfactl.egg rediscover (PID 9370)
      └─ sh tfactl.tfa rediscover (PID 9485)
         └─ tfactl.pl rediscover -mode lite -auto (PID 9521)  <-- El "Scheduler"
            ├─ tfactl.pl directory modify ... -collectall (PID 13603)
            ├─ tfactl.pl directory modify ... -collectall (PID 16113)
            └─ java CommandLine rac-node-001:listtfausers (PID 9617)

3. Comandos útiles de diagnóstico

Durante la resolución, estos fueron los comandos clave para entender qué estaba pasando "bajo el capó":

• Consultar la frecuencia actual: tfactl get rediscoveryInterval (En nuestro caso, devolvió 30m, confirmando ejecuciones cada media hora).

    [root@rac-node-001 ~]# tfactl get rediscoveryInterval
    .------------------------------------------------------.
    |                      rac-node-001                    |
    +----------------------------------------------+-------+
    | Configuration Parameter                      | Value |
    +----------------------------------------------+-------+
    | Rediscovery Interval ( rediscoveryInterval ) | 30m   |
    '----------------------------------------------+-------'
  

• Revisar logs de actividad: Los logs de AHF son vitales. Se encuentran en nuestro caso (separación de roles): /u01/app/grid/oracle.ahf/data/<hostname>/diag/ahf/tfactl.log.

• Verificar ayuda y límites: En la documentación oficial vemos que el intervalo acepta minutos (m), horas (h) o días (d), con un máximo de 1 día. Documentación

Conclusión del análisis: Este árbol nos confirmó que no estábamos ante un error o un proceso "zombie", sino ante una tarea de mantenimiento programada de AHF (rediscover -mode lite) que, por configuración por defecto, era demasiado agresiva para nuestro entorno.

4. El desafío de la programación (Scheduler)

Al no existir un comando para deshabilitar el proceso o para fijar una hora exacta (ej. las 03:00 AM), tuvimos que entender el funcionamiento del timer de TFA. El contador es relativo: comienza a contar desde que el servicio se inicia o desde que se modifica el parámetro.

5. La Solución: Sincronizando el intervalo al máximo

Decidimos reducir la frecuencia al mínimo posible estableciendo el intervalo en 24 horas para todo el cluster:

[root@rac-node-001 ~]# tfactl set rediscoveryInterval=24h -c
Successfully set rediscoveryInterval=24h

[root@rac-node-001 ~]# tfactl get rediscoveryInterval 
.------------------------------------------------------.
|                      rac-node-001                    |
+----------------------------------------------+-------+
| Configuration Parameter                      | Value |
+----------------------------------------------+-------+
| Rediscovery Interval ( rediscoveryInterval ) | 24h   |
'----------------------------------------------+-------'

Nota importante: Al aplicar el cambio con el parámetro -c (cluster-wide), TFA lanza inmediatamente un rediscover sincronizado en todos los nodos. Esto es ideal porque nos permite "resetear" el contador de 24 horas en el momento exacto en que ejecutamos el comando.

6. Verificación en los Logs

Confirmamos la ejecución en los logs de ambos nodos justo tras el cambio: [2026-01-21 10:04:40 CET] INFO - Executing command ... rediscover -mode lite -auto [2026-01-21 10:04:48 CET] INFO - Process completed execution with exit code 0

Conclusión

Si sufres picos de CPU causados por AHF, no intentes deshabilitarlo, busca el ajuste para la métrica concreta.

La estrategia ganadora es:

1. Elegir una ventana de baja carga.

2. Configurar rediscoveryInterval=24h -c.

3. Si necesitas una hora fija, reinicia el servicio TFA (tfactl restart) en ese horario.

Con esto, hemos pasado de 48 picos de CPU diarios a solo 1, manteniendo el sistema monitorizado pero estable.

El problema aparece cuando necesitamos entender su comportamiento o afinar su ejecución (por ejemplo, en entornos RAC) y descubrimos que no existe opción alguna para modificarlo desde la consola de OEM.

Qué es AWR Warehouse?

AWR Warehouse es un componente de Oracle Enterprise Manager que permite centralizar la información histórica de rendimiento (AWR) de múltiples bases de datos en un único repositorio.

En lugar de consultar los datos AWR directamente en cada base de datos (con la retención limitada que tenga configurada):

• Extrae periódicamente los snapshots AWR de las bases de datos monitorizadas.

• Los almacena en un esquema dedicado dentro del repositorio de OEM.

• Permite análisis históricos de largo plazo, comparativas entre sistemas y reporting avanzado.

Esto es especialmente útil cuando:

• Necesitamos análisis de rendimiento de meses o años atrás.

• Queremos comparar varias bases de datos o entornos.

• La retención local de AWR es reducida por motivos de espacio.

¿Cómo se alimenta AWR Warehouse?

La información no llega sola. CAW depende de una serie de jobs internos del repositorio OEM que se encargan de:

• Lanzar procesos de extracción.

• Conectarse a las bases de datos monitorizadas.

• Recoger los datos AWR necesarios.

• Cargarlos en el warehouse de forma centralizada.

En entornos RAC, el lugar donde se ejecuta este job sí importa:

• Puede afectar a la carga de una instancia concreta.

• Puede condicionar la conectividad hacia determinadas bases.

• Puede influir en el rendimiento general del repositorio OEM.

El objetivo es:

Controlar en qué instancia del RAC se ejecuta el proceso de extracción de AWR Warehouse, asegurando un comportamiento más predecible y alineado con nuestra arquitectura.

Aquí es donde entra en juego la necesidad de modificar el INSTANCE_ID del job, algo que OEM no permite hacer desde interfaz, pero que sí es posible a nivel de base de datos.

El Job interno identificado

Tras investigar, identificamos el job interno implicado:

MGMT_CAW_EXTRACT_JOB

Se trata de un job propiedad de SYS, gestionado por DBMS_SCHEDULER, y completamente oculto a nivel de interfaz gráfica.

Este job actúa como orquestador de la extracción, y su correcta ejecución es crítica para que los datos de rendimiento lleguen al warehouse.

¿Se puede modificar desde OEM?

No.

OEM no permite modificar este job desde la interfaz. No hay opción para cambiar atributos como la instancia en la que se ejecuta, ni su planificación.

Así que la única vía posible es actuar directamente contra la base de datos.

Modificando el Job directamente en base de datos

En nuestro caso, el objetivo era forzar la ejecución del job en una instancia concreta del RAC. Para ello, utilizamos el paquete DBMS_SCHEDULER y modificamos el atributo instance_id:

BEGIN
 DBMS_SCHEDULER.set_attribute(
 name => '"SYS"."MGMT_CAW_EXTRACT_JOB"',
 attribute => 'instance_id',
value => '2'
 );
END;
/

Puntos importantes a tener en cuenta:

• El job pertenece al esquema SYS, por lo que es necesario tener privilegios adecuados.

• El nombre debe ir completamente cualificado y entrecomillado.

• Este tipo de cambios no están documentados oficialmente, así que conviene aplicarlos con criterio y siempre en entornos controlados.

Monitorización de la ejecución

Una vez aplicado el cambio, pasamos a monitorizar el comportamiento real del job. Para ello, consultamos la vista DBA_SCHEDULER_JOB_RUN_DETAILS:

SELECT instance_id,
 log_date,
 owner,
 job_name,
 status,
 run_duration,
 output
FROM DBA_SCHEDULER_JOB_RUN_DETAILS
WHERE job_name = 'MGMT_CAW_EXTRACT_JOB'
ORDER BY log_date DESC;

Esta consulta nos permite ver:

• En qué instancia se ejecuta realmente (INSTANCE_ID)

• Cuándo se lanza (LOG_DATE)

• Duración y estado de cada ejecución

• Salida del job, muy útil para confirmar si hay generación efectiva de datos

Comportamiento observado

Aquí viene una de las claves más interesantes:

El job se ejecuta cada 3 horas.

Sin embargo, la extracción real de datos solo se produce cada 24 horas (configurado desde la interfaz)

Es decir:

No todas las ejecuciones implican una carga efectiva de información en el AWR Warehouse.

Esto explica por qué, aun viendo ejecuciones frecuentes, no siempre observamos actividad de generación de datos.

1. Preparar un Database Link

Para que la standby pueda consultar la primaria, necesitamos un database link privado:

1. Crear entradas TNS :

PDB_XXXXXX_PRI=
    (DESCRIPTION_LIST=
      (LOAD_BALANCE=off) (FAILOVER=on)
          (DESCRIPTION= (CONNECT_TIMEOUT=15)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
             (ADDRESS_LIST= (LOAD_BALANCE=on)
                (ADDRESS=(PROTOCOL=TCP)(HOST=racscan-pri.xxxxx.xxx)(PORT=1521)))
                  (CONNECT_DATA=(SERVICE_NAME=mant.xxxxx.xxx)))
           (DESCRIPTION= (CONNECT_TIMEOUT=15)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
                (ADDRESS_LIST= (LOAD_BALANCE=on)
                    (ADDRESS=(PROTOCOL=TCP)(HOST= racscan-stb.xxxxx.xxx)(PORT=1521)))
                         (CONNECT_DATA=(SERVICE_NAME=mant.xxxxx.xxx))))

2. Desbloquear el usuario SYS$UMF:

ALTER USER "SYS$UMF" IDENTIFIED BY sysumf ACCOUNT UNLOCK;

3. Crear el database link desde la primaria:

CREATE DATABASE LINK lnk_to_pri
CONNECT TO SYS$UMF IDENTIFIED BY "sysumf"
USING 'PDB_PRIMARY';

4. Verificar la conexión desde Standby:

SQL>  select * from dual@lnk_to_pri;

D
-
X

2. Generar la tarea SQL Tuning

Desde OEM la tarea automática se llamará como:

SQL_TUNING_STDBY_xxxx

• Pertenecen a SYSTEM.

• Desde la standby, se pueden consultar mediante DBMS_SQLTUNE.

  

  

3. Generar el reporte desde la standby

Podremos ver resultados desde OEM o consultar desde BBDD:

SET SERVEROUTPUT ON SIZE UNLIMITED

DECLARE
l_report CLOB;
BEGIN
l_report := DBMS_SQLTUNE.report_tuning_task(
task_name => 'SQL_TUNING_STDBY_xxxx,
type => 'TEXT',
level => 'TYPICAL',
section => 'ALL',
owner_name => 'SYSTEM'
);
DBMS_OUTPUT.put_line(l_report);
END;
/

• type => 'TEXT' devuelve un reporte legible en consola.

• section => 'ALL' incluye todo el detalle del tuning.

• owner_name => 'SYSTEM' permite acceder a tareas de otro usuario.

4. Guardar el reporte en un archivo

SPOOL sql_tuning_report.txt

DECLARE
l_report CLOB;
BEGIN
l_report := DBMS_SQLTUNE.report_tuning_task(
task_name => 'SQL_TUNING_STDBY_xxxx',
type => 'TEXT',
level => 'ALL',
section => 'ALL',
owner_name => 'SYSTEM'
);
DBMS_OUTPUT.put_line(l_report);
END;
/

SPOOL OFF

Esto genera un archivo sql_tuning_report.txt con todas las recomendaciones, índices sugeridos y sugerencias de reescritura.

Beneficios de usar SQL Tuning en Standby

• Ejecutar tuning sin impactar la primaria

• Compatible con Active Data Guard

• Permite optimizaciones periódicas desde standby

• Acceso a recomendaciones completas incluso si la tarea fue ejecutada en la primaria

Nota: Siempre usar database links privados y privilegios mínimos necesarios (SYS$UMF).

A continuación se muestra el procedimiento completo para activar y revisar las trazas del autostats job de manera controlada y segura.

1. Crear la tabla de log temporal

Primero, creamos una tabla en el esquema SYS que almacenará la información de trazas.
La estructura se basa en la tabla interna SYS.STATS_TARGET$:

create table sys.stats_target$_log
as
select t.*, rpad('X',30,'X') session_id, 1 state
from sys.stats_target$ t
where 1=0;

Esta tabla se crea vacía (where 1=0) y contendrá los registros generados por el proceso de autostats durante la traza.
El campo session_id se rellena con una cadena de prueba (rpad('X',30,'X')) y el campo state con valor 1 para simular la estructura de datos.

2. Habilitar la traza para DBMS_STATS

A continuación, habilitamos el tracing a nivel global.
El parámetro 'trace' de DBMS_STATS.SET_GLOBAL_PREFS permite activar diferentes niveles de detalle mediante la suma de bits.
En este caso, se activan múltiples niveles para obtener información completa, incluyendo la del autostats job:

exec dbms_stats.set_GLOBAL_PREFS('trace', 4+8+16+32+128+512+1024+2048+32768);

Esto incluye trazas para:

• Operaciones internas de DBMS_STATS

• Ejecución del autostats scheduler job

• Seguimiento detallado de las decisiones de estadísticas sobre objetos

• Procesamiento de targets y resultados de cálculo

3. Permitir la ejecución del autostats job

Una vez activada la traza, dejamos que el job de autostats se ejecute normalmente.
Es importante tener en cuenta que no es necesario ejecutar el job desde la misma sesión en la que se activó la traza.
El tracing se aplica de forma global mientras el parámetro esté activo.

4. Desactivar la traza

Cuando hayamos recopilado suficiente información, debemos desactivar las trazas inmediatamente para evitar un consumo excesivo de recursos o un log innecesariamente grande:

exec DBMS_STATS.SET_GLOBAL_PREFS('trace',0);

Y finalmente, eliminamos la tabla temporal que creamos al inicio:

drop table sys.stats_target$_log;

5. Localizar los archivos de traza

Podemos buscar los archivos generados por DBMS_STATS en el sistema de archivos con un comando similar a:

find /ruta_trace -type f | xargs grep 'DBMS_STATS'

Esto nos ayudará a identificar los ficheros de traza donde Oracle ha registrado la información de depuración.
Generalmente, los archivos se encuentran bajo el directorio de diagnóstico (ADR) del Oracle Base.

6. Analizar las tareas más lentas del autostats job

Además de las trazas, es posible identificar qué fases o tareas dentro del autostats job consumen más tiempo utilizando las vistas DBA_OPTSTAT_OPERATIONS y DBA_OPTSTAT_OPERATION_TASKS.
La siguiente consulta permite desglosar el detalle de cada tarea, su duración y tipo de objeto afectado:

SELECT 
    ta.opid,
    ta.TARGET_TYPE,
    ta.TARGET,
    ta.STATUS,
    TO_CHAR(ta.START_TIME, 'YYYY-MM-DD HH24:MI:SS') AS START_TIME,
    TO_CHAR(ta.END_TIME, 'YYYY-MM-DD HH24:MI:SS') AS END_TIME,
    ROUND((CAST(ta.END_TIME AS DATE) - CAST(ta.START_TIME AS DATE)) * 24 * 60, 2) AS DURATION_MINUTES,
    ta.ESTIMATED_COST,
    ta.notes
FROM 
    DBA_OPTSTAT_OPERATION_TASKS ta,
    DBA_OPTSTAT_OPERATIONS op
WHERE
    ta.start_time > (SYSDATE - 15)
    AND ta.opid = op.id
    AND op.operation = 'gather_database_stats (auto)'
ORDER BY 
    ta.START_TIME DESC;

Con esta consulta podemos identificar:

• Qué objetos están tardando más en el proceso de gather stats.

• Cuánto tiempo dura cada tarea.

• El tipo de objeto (tabla, índice, esquema, etc.).

• El coste estimado y notas del optimizador.

Esto resulta especialmente útil para detectar cuellos de botella o objetos que bloquean la ejecución del autostats job.

7. Recomendaciones

• Realiza este procedimiento solo bajo supervisión o en entornos controlados si se trata de producción.

• Desactiva siempre el tracing al finalizar para evitar logs innecesarios.

• Conserva los archivos de traza para su análisis conjunto con Oracle Support si estás trabajando en un SR.

• Usa la consulta de tareas para priorizar el ajuste de estadísticas en los objetos más costosos.

Conclusión

El uso del tracing en DBMS_STATS combinado con el análisis de las vistas de operaciones permite comprender en profundidad el comportamiento del autostats job en Oracle.
Gracias a estas herramientas, puedes detectar las fases más lentas del proceso, identificar qué objetos requieren atención y mejorar el rendimiento del mantenimiento de estadísticas en entornos críticos.

En este artículo te cuento un caso real que me encontré al trabajar con la vista DBA_HIST_SYSSTAT y cómo lo resolví gracias al parámetro oculto CONTAINER_DATA introducido a partir del bug 31142749.

El síntoma: consultas AWR lentas sin motivo aparente

Estaba trabajando en una consulta para calcular el número de transacciones por segundo a partir de las estadísticas AWR.
El SQL utilizaba DBA_HIST_SYSSTAT y DBA_HIST_SNAPSHOT con filtros muy concretos por SNAP_ID, DBID e INSTANCE_NUMBER. A pesar de ello, la ejecución era muy lenta:

A pesar de que esta consulta debería completarse en segundos, la ejecución tardaba varios minutos.
El plan de ejecución reveló la causa:

|* 17 | EXTENDED DATA LINK FULL | AWR_CDB_SYSSTAT |

Este paso era el responsable del mayor coste y retraso.

La causa: el bug 31142749 y las vistas con extended data link

El problema está relacionado con el bug 31142749 – QUERY ON ALL_ARGUMENTS SLOW IN 19.6 PDB

Para identificar los objetos que son susceptibles de provocar planes de ejecución con operaciones costosas como EXTENDED DATA LINK FULL, especialmente cuando se consultan desde una PDB sin ajustar el parámetro CONTAINER_DATA :

SELECT object_name, object_type, sharing
FROM dba_objects
WHERE sharing = 'EXTENDED DATA LINK';

La solución: usar el parámetro CONTAINER_DATA

Oracle introdujo el parámetro oculto CONTAINER_DATA a partir del parche 31142749 (incluido desde 19.10 RU - Enero 2021).

El parámetro CONTAINER_DATA controla el comportamiento de las consultas sobre objetos con extended data links tanto en aplicaciones comunes como en el diccionario de datos. Su valor determina qué datos devuelve una consulta cuando se ejecuta desde una PDB (pluggable database):

Formas de aplicarlo

Usar un hint en la consulta (solución más rápida)

En mi caso, el rendimiento se solucionó inmediatamente añadiendo este hint:

/*+ OPT_PARAM('container_data' 'current_dictionary') */

El plan de ejecución cambió y el paso EXTENDED DATA LINK FULL desapareció.

Cambiarlo a nivel de sesión

Para no modificar cada consulta individualmente:

ALTER SESSION SET CONTAINER_DATA=CURRENT_DICTIONARY;

También puedes usar un trigger de logon para aplicarlo automáticamente:

CREATE OR REPLACE TRIGGER set_container_data
AFTER LOGON ON DATABASE
BEGIN
  EXECUTE IMMEDIATE 'ALTER SESSION SET CONTAINER_DATA=CURRENT_DICTIONARY';
END;
/

Cambiarlo a nivel de instancia (permanente)

Puedes configurarlo en el spfile y reiniciar la base de datos:

ALTER SYSTEM SET CONTAINER_DATA=CURRENT_DICTIONARY SCOPE=SPFILE;

Resultado: mejora inmediata del rendimiento

Tras aplicar el hint OPT_PARAM o ajustar la sesión, las consultas sobre DBA_HIST_SYSSTAT pasaron de tardar minutos a ejecutarse en segundos.

El plan de ejecución dejó de mostrar EXTENDED DATA LINK FULL, eliminando el acceso innecesario a datos del root.

Conclusión

Si trabajas con vistas AWR o del diccionario en una PDB y notas un rendimiento inesperadamente bajo, revisa el plan de ejecución.

Si ves un paso EXTENDED DATA LINK FULL, probablemente estés afectado por el bug 31142749.

La solución es aplicar el parámetro CONTAINER_DATA con el valor CURRENT_DICTIONARY, lo que restringe el acceso a datos del contenedor actual y evita un coste de ejecución innecesario.

En esta entrada te muestro cómo hacerlo paso a paso.

¿De dónde salen los datos?

Oracle guarda en la vista DBA_HIST_SYSSTAT distintos contadores acumulados. Para el caso que nos interesa:

user commits → número de commits ejecutados por los usuarios.

user rollbacks → número de rollbacks ejecutados.

Estos valores son acumulativos desde que se inició la instancia. Para obtener la actividad en un intervalo debemos calcular el delta (diferencia entre snapshots consecutivos).

La consulta

/* ---------------------------------------------------------
   Calcular transacciones por segundo (TPS) desde AWR
   usando las métricas de DBA_HIST_SYSSTAT y DBA_HIST_SNAPSHOT
   --------------------------------------------------------- */

WITH snaps AS (
    SELECT s.dbid,
           s.instance_number,
           s.snap_id,
           -- Redondeamos el inicio del intervalo al minuto
           TRUNC(s.begin_interval_time, 'MI') AS snap_time,
           -- Diferencia de tiempo entre snapshots (en segundos)
           (EXTRACT(DAY FROM (s.begin_interval_time - LAG(s.begin_interval_time) 
                               OVER (PARTITION BY s.dbid, s.instance_number ORDER BY s.snap_id))) * 86400) +
           (EXTRACT(HOUR FROM (s.begin_interval_time - LAG(s.begin_interval_time) 
                               OVER (PARTITION BY s.dbid, s.instance_number ORDER BY s.snap_id))) * 3600) +
           (EXTRACT(MINUTE FROM (s.begin_interval_time - LAG(s.begin_interval_time) 
                               OVER (PARTITION BY s.dbid, s.instance_number ORDER BY s.snap_id))) * 60) +
           (EXTRACT(SECOND FROM (s.begin_interval_time - LAG(s.begin_interval_time) 
                               OVER (PARTITION BY s.dbid, s.instance_number ORDER BY s.snap_id)))) 
             AS interval_sec
      FROM dba_hist_snapshot s
),
stats AS (
    SELECT t.dbid,
           t.instance_number,
           t.snap_id,
           -- Calculamos delta para commits y rollbacks
           GREATEST(NVL(t.value - LAG(t.value) 
                           OVER (PARTITION BY t.dbid, t.instance_number, t.stat_name ORDER BY t.snap_id),0),0) 
               AS delta_tx
      FROM dba_hist_sysstat t
     WHERE t.stat_name IN ('user commits', 'user rollbacks')
),
calc AS (
    SELECT sn.snap_time,
           sn.instance_number,
           SUM(st.delta_tx) / NULLIF(sn.interval_sec,0) AS tx_per_sec
      FROM snaps sn
           JOIN stats st
             ON st.dbid = sn.dbid
            AND st.instance_number = sn.instance_number
            AND st.snap_id = sn.snap_id
     WHERE sn.interval_sec IS NOT NULL
     GROUP BY sn.snap_time, sn.instance_number, sn.interval_sec
)
SELECT TO_CHAR(c.snap_time,'YYYY-MM-DD HH24:MI') AS minuto,
       c.instance_number,
       ROUND(c.tx_per_sec,2) AS transactions_per_sec
  FROM calc c
 ORDER BY minuto DESC, instance_number;

Interpretación

Cada fila representa la tasa de transacciones por segundo de una instancia en un minuto concreto.

Si tu base de datos es RAC, verás cada instancia por separado.

Puedes sumar las TPS de todas las instancias para tener una visión global de la base de datos.

Conclusión

Esta consulta es muy útil cuando queremos:

• Ver la evolución de la actividad transaccional en detalle.

• Comparar instancias de un RAC.

• Correlacionar picos de carga con eventos específicos (deploys, cierres contables, etc.).

Con AWR ya tienes todos los datos, solo hace falta un poco de SQL para explotarlos

Esto nos llevó a una pequeña investigación para entender qué ocurría y, finalmente, a mover la ventana de ejecución de los jobs de inventario de parches del agente a una hora menos conflictiva.

Introducción

En los últimos días detectamos un pico recurrente de carga de CPU alrededor de las 15:18 en nuestros nodos de base de datos. Este patrón se repetía casi a diario y afectaba al rendimiento de las transacciones durante unos minutos.

El objetivo de este artículo es explicar:

• Cómo detectamos el patrón.

• Cómo lo diagnosticamos hasta identificar la causa raíz.

• Cómo reprogramamos la tarea para evitar que se ejecute en horario crítico de negocio.

Detección inicial: patrón recurrente en transacciones

Todo comenzó revisando métricas de nuestra base de datos de negocio. Vimos un patrón repetido de demora de rendimiento en torno a las 15:18.

Correlación con el agente de Cloud Control

Al revisar el log del agente en:

$AGENT_HOME/agent_inst/sysman/log/gcagent.log

Vimos entradas exactamente a esa hora:

2025-08-26 15:18:44,807 [GC.Executor... oracle_home_config:PatchFixedBug] xxxxxxxxxxxxxxxxxx

También lo comprobamos en los dos nodos del RAC con:

$AGENT_HOME/bin/emctl status agent scheduler | grep -i oracle_home_config

Resultado:

2025-08-27 15:18:41.788 : oracle_home:OraHomeXX_rac-xxx-001:oracle_home_config
2025-08-27 15:18:42.857 : oracle_home:OraGIXXHome1_1_rac-xxx-001:oracle_home_config

Y justo en ese momento, top mostraba varios procesos perl y java consumiendo >190% de CPU:

PID    USER      %CPU  COMMAND
51242  agent13   190   java
51273  agent13    84   perl
51522  agent13    81   perl

Diagnóstico

Confirmamos así que:

• A las 15:18, el agente de Oracle Enterprise Manager Cloud Control lanza tareas de tipo oracle_home_config:PatchFixedBug, que forman parte de la Configuration Collection.

• Estas tareas ejecutan internamente herramientas como OPatch para recoger el inventario de parches aplicados en cada Oracle Home y en la Grid Infrastructure.

• Esto provoca un pico puntual de CPU, suficiente para afectar a otras cargas sensibles en ese instante.

Cambiando la ventana de ejecución

Para evitar el impacto en horario de negocio, decidimos mover la ventana de ejecución de esos jobs a la madrugada.

Pasos:

1. Listar las tareas programadas del agente:

   $AGENT_HOME/bin/emctl status agent scheduler

2. Identificar las tareas oracle_home_config
   oracle_home:OraGIXXHome1_1_rac-xxx-001:oracle_home_config oracle_home:OraHomeXX_rac-xxx-001:oracle_home_config

3. Reprogramarlas con una nueva hora de inicio donde haya menos afección (ejemplo: 04:45 AM):

   

   Repetir para cada Oracle Home.

4. Confirmar el cambio:

   $AGENT_HOME/bin/emctl status agent scheduler | grep oracle_home_config

[agent13@rac-xxx-002 ~]$ $AGENT_HOME/bin/emctl status agent scheduler | grep -i oracle_home_config
2025-08-27 21:42:55.879 : oracle_home:agent13c1_3_rac-xxx-002.paytef.local_8730:oracle_home_config
2025-08-28 04:30:00.000 : oracle_home:OraGIXXHome1_1_rac-xxx-002.paytef.local_8611:oracle_home_config
2025-08-28 04:45:00.000 : oracle_home:OraHomeXX_rac-xxx-002.paytef.local_6495:oracle_home_config

Resultado

Desde que movimos las tareas, desaparecieron los picos de CPU en horario laboral y no hemos vuelto a ver demoras en tiempos a las 15:18.
La tarea sigue ejecutándose correctamente, pero en una ventana sin carga de usuarios.

Conclusión

Aunque el agente de Oracle Enterprise Manager Cloud Control trabaja de forma desatendida, sus tareas de inventario pueden ser muy pesadas.

Monitorizar patrones horarios y correlacionarlos con los logs del agente permite anticiparse a estos cuellos de botella invisibles y recolocar su ventana de ejecución para que no interfieran con el negocio.

Nuestra aplicación, que utiliza extended strings, comenzó a presentar una elevada cantidad de child cursors en dos sentencias INSERT críticas.

La Investigación y el Diagnóstico

El primer paso fue identificar el origen exacto del BIND_MISMATCH. Para ello, seguimos un proceso meticuloso:

Identificación de los SQL_ID problemáticos: A través de V$SQL y V$SQL_SHARED_CURSOR, localizamos los dos SQL_ID involucrados (xxxxxxxxxxxxx1 y xxxxxxxxxxxxx2).

Para encontrar el motivo de un cursor no compartido:

-- Script Code
set serveroutput on

DECLARE
  v_count number;
  v_sql varchar2(500);
  v_sql_id varchar2(30) := '&sql_id';
BEGIN
  v_sql_id := lower(v_sql_id);
  dbms_output.put_line(chr(13)||chr(10));
  dbms_output.put_line('sql_id: '||v_sql_id);
  dbms_output.put_line('------------------------');
  FOR c1 in
    (select column_name 
       from dba_tab_columns
      where table_name ='V_$SQL_SHARED_CURSOR'
        and column_name not in ('SQL_ID', 'ADDRESS', 'CHILD_ADDRESS', 'CHILD_NUMBER', 'REASON', 'CON_ID')
      order by column_id)
  LOOP
    v_sql := 'select count(*) from V_$SQL_SHARED_CURSOR
              where sql_id='||''''||v_sql_id||''''||'
              and '||c1.column_name||'='||''''||'Y'||'''';
    execute immediate v_sql into v_count;
    IF v_count > 0
    THEN
      dbms_output.put_line(' - '||rpad(c1.column_name,30)||' count: '||v_count);
    END IF;
  END LOOP;
END;

Versions Summary
----------------
BIND_MISMATCH :121 <<<<<<<<<<-----------------
ROLL_INVALID_MISMATCH :2
BIND_LENGTH_UPGRADEABLE :9

Análisis de los binds: La clave fue consultar la vista V$SQL_BIND_CAPTURE para entender la variabilidad en el tamaño de los binds para cada una de las sentencias.

Para el primer SQL_ID: sql

SELECT COUNT(*) AS count,
       position,
       MIN(max_length) AS min_length,
       MAX(max_length) AS max_length,
       datatype,
       CASE 
         WHEN MAX(value_string) IS NOT NULL THEN 'Yes' 
         ELSE 'No' 
       END AS bind_captured,
       '('||MAX(precision)||','||MAX(scale)||')' AS graduation
  FROM gv$sql_bind_capture
  WHERE  sql_id = 'xxxxxxxxxxxxx1'
 GROUP BY position, datatype
 ORDER BY max_length desc;

COUNT(*) POSITION MIN(MAX_LENGTH) MAX(MAX_LENGTH) DATATYPE BIND GRADUATION (PRECISION,SCALE)
======== ======== =============== =============== ======== =============== =================
21 1 22 22 2 No (,)
21 2 32 32 1 No (,)
21 3 2000 2000 1 No (,)
21 4 2000 2000 1 No (,)
21 5 2000 2000 1 No (,)
21 6 7 7 12 No (,)
21 7 22 22 2 No (,)
12 8 2000 2000 1 No (,)
9 8 22 22 2 No (,)
21 9 32 2000 1 Yes (,)
21 10 128 128 1 No (,)
21 11 128 128 1 No (,)
21 12 22 22 2 No (,)
21 13 2000 2000 1 No (,)
21 14 2000 2000 1 No (,)
21 15 32 2000 1 Yes (,)
21 16 2000 2000 1 No (,)
21 17 128 2000 1 Yes (,)

Los resultados mostraron que los binds de tipo VARCHAR2 en varias posiciones variaban entre 32 y 2000 bytes. ¡Este era el culpable del BIND_MISMATCH para la primera INSERT.

High Version Count Due To BIND_MISMATCH ( Doc ID 336268.1 )

Aplicación de la solución: Basándonos en este análisis, aplicamos el evento 10503 con el nivel específico que necesitábamos:

ALTER SYSTEM SET EVENTS '10503 trace name context forever, level 2000';

Resultado: El problema de los child cursors para la primera sentencia INSERT se resolvió por completo.

El segundo problema: Tras el primer éxito, nos enfocamos en el segundo SQL_ID (xxxxxxxxxxxxx2). Repetimos el análisis y descubrimos que sus binds llegaban hasta 16,386 bytes.

Aplicamos el evento con un nivel superior:

ALTER SYSTEM SET EVENTS '10503 trace name context forever, level 16386';

La Limitación

Para nuestra sorpresa, el segundo problema no se resolvió. Al contactar con Soporte de Oracle, confirmaron nuestra sospecha: el evento 10503 tiene una limitación interna y no funciona para binds mayores a 4000 bytes, incluso si se establece un nivel superior.

Conclusión y Lecciones Aprendidas

El diagnóstico es clave: La solución no es aplicar el evento 10503 a ciegas. La consulta a V$SQL_BIND_CAPTURE para obtener el MAX(MAX_LENGTH) de los binds problemáticos es un paso fundamental y no negociable para determinar el nivel correcto.

Solución para binds <= 4000 bytes: Para la primera INSERT, el evento 10503 configurado al nivel preciso (2000) fue la solución perfecta y eliminó el BIND_MISMATCH.

Limitación actual para binds > 4000 bytes: Para la segunda INSERT, chocamos con un muro. Oracle confirmó que no hay solución nativa actualmente y que no hay planes a corto plazo para extender el evento más allá de 4000 bytes.

Reflexión Final

Este caso es un ejemplo perfecto de cómo un enfoque metódico—identificar, diagnosticar y aplicar—nos permitió resolver el 50% del problema. Para el otro 50%, nos topamos con una limitación actual de la base de datos.

Cambio persistente en spfile

Para que el cambio aplique tras reinicios

ALTER SYSTEM SET EVENT= '10503 trace name context forever, level 2000'  COMMENT='High Version Count Due To BIND_MISMATCH' SCOPE=SPFILE SID='*';

Contexto

En nuestro entorno RAC, tenemos habilitado ADG Redirect DML en la base de datos standby. Esta funcionalidad permite que operaciones DML ejecutadas en la standby se redirijan automáticamente al primary.

Es un comportamiento esperado, pero genera un efecto colateral: decenas de archivos de trace por día, cada uno indicando que se ha conectado al primary, por ejemplo:

Connected to primary database target CDBXXX

Este volumen de trazas no representaba un error, pero sí un ruido significativo en nuestros logs, lo que dificulta la monitorización y la identificación de incidencias reales.

Análisis

La base de datos no tenía activado log_archive_trace, que podría controlar algunas trazas relacionadas con archivado.

Datos Relevantes

Durante la fase de análisis, contabilizamos los trace generados por día en la standby:

Fecha        Trace files
2025-06-29    54
2025-07-01    96
2025-07-04    125
2025-07-10    66
2025-07-15    96

Como se puede ver, la cantidad variaba de manera considerable, llegando hasta 125 archivos en un solo día.

Solución Adoptada

No existe un parámetro directo para desactivar estas trazas en el nivel RDBMS mientras ADG Redirect DML esté activo.

La solución práctica fue:

Crear un script de mantenimiento periódico que elimine o archive los trace files en intervalos regulares, utilizando cron en Linux.

Monitorizar los logs para asegurar que no se pierdan trazas relevantes para diagnósticos futuros.

Conclusión

Este caso nos recuerda que ciertas funcionalidades avanzadas de Oracle, como ADG Redirect DML, traen consigo comportamientos secundarios que no siempre están documentados como “configurables”.

En nuestro caso, el sistema siguió totalmente operativo, y la medida adoptada nos permitió mantener la claridad en nuestros logs sin afectar la disponibilidad ni la integridad de la standby.

Tras revisar los logs, nos encontramos con el siguiente aviso preocupante:

<Free memory in the server is 52,928 bytes. There is danger of receiving an OutOfMemoryError.>

Aunque la máquina tenía memoria física suficiente, el proceso OMS estaba alcanzando su límite de heap Java, configurado con un valor bajo.

Diagnóstico

El proceso de OMS se ejecuta como una JVM (Java Virtual Machine), por lo tanto, su uso de memoria está limitado por los parámetros de arranque, típicamente:

-Xms: heap mínimo

-Xmx: heap máximo

Al revisar los procesos activos:

ps -ef | grep oms | grep Xmx

Detectamos que estaba usando un heap máximo de apenas 1740M, lo cual es insuficiente para un entorno de producción con cierta carga.

Solución

Aumentamos el parámetro OMS_HEAP_MAX a 4096M (4 GB), ejecutando lo siguiente:

$OMS_HOME/bin/emctl set property -name OMS_HEAP_MAX -value 4096M

Y aplicamos reinicio.

$OMS_HOME/bin/emctl stop oms -all -force 
$OMS_HOME/bin/emctl start oms

Después del reinicio, confirmamos que el nuevo valor se aplicó correctamente:

ps -ef | grep oms | grep Xmx

Debería mostrar algo como: -Xmx4096M

Recursos del sistema

También confirmamos que la máquina tenía recursos suficientes:

free -m

Resultado:

Mem: 23744 total

Suficiente RAM para aumentar la memoria heap del OMS sin riesgos.

Conclusión

Este caso nos recuerda que:

OEM 13c puede consumir bastante heap según la carga.

Un valor bajo de OMS_HEAP_MAX puede causar errores BEA-310003 y reinicios del OMS.

Es importante revisar regularmente los logs de WebLogic (server.log, EMGC_OMS1.out) y ajustar parámetros JVM según el crecimiento del entorno.

¿Dónde buscar estos logs?

Los logs relevantes del OMS están aquí:

$OMS_HOME/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/

EMGC_OMS1.out

server.log

Y los específicos de OEM:

$OMS_HOME/gc_inst/em/EMGC_OMS1/sysman/log/emoms.log

¿Has tenido problemas similares con OEM? ¿Cuánto heap tenéis configurado en producción?

Referencias y Notas de Soporte

• [MOS 2674369.1] How to Increase the Java Heap Size for the Oracle Management Service (OMS) in OEM 13c

• [MOS 1955854.1] OMS Fails with BEA-310003: Free memory in the server is ... There is danger of receiving an OutOfMemoryError

• Documentación oficial OEM 13c – sección Tuning the OMS Heap Size

• [MOS 1589136.1] How to Modify the OMS Java Heap Size Parameters in Enterprise Manager

• BEA-310003 Error Codes Reference

¡Hoy te presento una solución inteligente! He desarrollado un script que combina el poder de los datos históricos de Oracle AWR Warehouse con la sencillez de un script de shell para monitorizar el crecimiento de los tablespaces y alertarte proactivamente cuando necesiten más espacio.

El Desafío de los Tablespaces y Por Qué Necesitamos Ser Proactivos

Imagina esto: un lunes por la mañana, suena tu teléfono. "¡La aplicación está caída! ¡Error de tablespace lleno!". Es una pesadilla. Los tablespaces, que son las estructuras lógicas de almacenamiento en Oracle donde residen tus datos, crecen constantemente. Las transacciones, la inserción de nuevos datos, la creación de índices, todo consume espacio.

Si no monitorizas este crecimiento, te expones a:

• Caídas de aplicaciones: Cuando un tablespace crítico se llena, las operaciones de escritura fallan.

• Pérdida de datos (temporal)

• Estrés y trabajo reactivo: En lugar de planificar, te ves apagando fuegos urgentes.

La Magia Detrás de Escena: AWR Warehouse de Oracle

Aquí es donde entra en juego el AWR Warehouse (Automatic Workload Repository Warehouse).

¿Qué es AWR?

Es una característica de Oracle que recopila automáticamente estadísticas de rendimiento y uso de tu base de datos en intervalos regulares (snapshots). Guarda datos sobre el uso de CPU, memoria, I/O, SQL más costosos... ¡y también el uso de tablespaces!

¿Qué es AWR Warehouse?

Piensa en ello como un "gran almacén" donde puedes guardar los datos AWR de múltiples bases de datos de tu entorno. En lugar de consultar directamente tu base de datos de producción (que podría tener un impacto en el rendimiento), puedes consultar este almacén centralizado.

¿Por qué es clave para nuestra solución?

Porque nos permite acceder al historial de crecimiento de los tablespaces sin afectar el rendimiento de tu base de datos de producción. Podemos ver cuánto creció un tablespace en el último mes, y esa es la métrica que usaremos para nuestra lógica predictiva.

Os presento mi "Oráculo de Tablespaces"

El script es un pequeño pero poderoso aliado que ejecuta la siguiente lógica:

1. Conexión Segura: Se conecta a una base de datos standby (para obtener la información actual de los tablespaces sin impactar la producción) y a tu AWR Warehouse.

2. Lista los Tablespaces: Obtiene todos los tablespaces que no sean del sistema o temporales.

3. Para cada tablespace, hace magia:

   • Obtiene el espacio actualmente utilizado y asignado (reservado) en MB.

   • Consulta el AWR Warehouse para determinar el crecimiento total en MB del último mes completo.

   • Calcula el espacio libre disponible.

   • ¡La regla de oro! Compara: ¿Es el espacio libre disponible menor que el crecimiento del último mes?

4. Genera Alerta y Sugerencia: Si la respuesta es SÍ, se dispara una alerta. El script no solo te avisa, sino que te propone un comando ALTER TABLESPACE RESIZE para ampliarlo (atención que se trata de bigfile), sugiriendo un tamaño basado en su uso actual más el crecimiento del último mes.

5. Envía el Informe: Consolida toda la información en un correo electrónico detallado.

La belleza de este enfoque es que no usamos un umbral fijo de porcentaje. En su lugar, usamos el patrón de crecimiento histórico del tablespace para predecir si se quedará sin espacio en el futuro cercano, basándose en su ritmo de consumo. Esto es ser verdaderamente proactivo.

Desglose del Script (monitor_tbs_growth.sh)

#!/bin/bash

#-----------------------------------------
# Configuración
#-----------------------------------------
ORACLE_SID_STANDBY="MY_PDB_STBY" # TNS de tu PDB Standby o base de datos de lectura
ORACLE_SID_AWR="MY_AWR_DB" # TNS de tu AWR Warehouse

USUARIO_STANDBY="system"
CLAVE_STANDBY="******" # ¡Ofuscada! Cambiar por tu contraseña real
USUARIO_AWR="system"
CLAVE_AWR="******" # ¡Ofuscada! Cambiar por tu contraseña real

MAIL_DESTINO="dba@mycompany.com" # Cambiar por tu dirección de correo
DEBUG=true # true para debug, false cuando esté implementado en producción

# --- AWR Warehouse Specifics ---
# !!! IMPORTANTE: DEBES CONFIGURAR ESTOS VALORES PARA TU ENTORNO !!!
# DB_TARGET_NAME TNS del target OEM .
# PDB_NAME_TO_MONITOR TNS de la Pluggable Database que quieres monitorizar.
DB_TARGET_NAME="my_cdb_prod"         # Ejemplo: 'my_cdb_prod' o 'oracle_db_name'
PDB_NAME_TO_MONITOR="MY_APP_PDB"     # Ejemplo: 'MY_APP_PDB'


# Variables entorno de BBDD
PATH=/home/nagios/.local/bin:/home/nagios/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
ORACLE_SID=cdboem # El SID del Listener/Instancia que atiende tu AWR Warehouse
ORAENV_ASK=NO
. oraenv -s

export TNS_ADMIN=/home/nagios/tns_admin # Ruta a tu tnsnames.ora

#-----------------------------------------
# Función para depuración
#-----------------------------------------
log_debug() {
    # Redirige los mensajes de depuración a stderr para evitar contaminar stdout
    $DEBUG && echo "[DEBUG] $(date +'%Y-%m-%d %H:%M:%S') $1" >&2
}

#-----------------------------------------
# Verifica conexión SQL
#-----------------------------------------
verifica_sqlplus() {
    local conn_str=$1
    local test_query="SELECT 'OK' FROM dual;"
    log_debug "Intentando conectar a: $conn_str"
    echo "$test_query" | sqlplus -s "$conn_str" | grep -q "OK" > /dev/null
    if [ $? -ne 0 ]; then
        echo "❌ ERROR: Fallo de conexión con $conn_str" >&2
        exit 1
    else
        log_debug "Conexión exitosa a: $conn_str"
    fi
}

#-----------------------------------------
# Obtener tablespaces excluyendo los sistema/temp
# Nota: Esto obtiene tablespaces de la standby
#-----------------------------------------
get_tablespaces() {
    local conn_str="$1"
    log_debug "Obteniendo listado de tablespaces de $conn_str"
    sqlplus -s "$conn_str" <<EOF
SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
SELECT DISTINCT tablespace_name
FROM dba_data_files
WHERE tablespace_name NOT IN ('SYSTEM','SYSAUX','UNDOTBS1','TEMP')
ORDER BY tablespace_name;
EOF
}

#-----------------------------------------
# Obtener crecimiento total del último mes completo desde el AWR Warehouse
# (Usando TRUNC(SYSDATE, 'MM') en SQL para fechas )
#-----------------------------------------
get_last_month_total_growth() {
    local conn_awr="$1"
    local tbs_name="$2"
    local pdb_name_filter="$3"
    local target_name_filter="$4"

    log_debug "Calculando crecimiento TOTAL para '$tbs_name' en PDB '$pdb_name_filter' (Target: '$target_name_filter') para el último mes completo."

    sqlplus -s "$conn_awr" <<EOF
SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
WHENEVER SQLERROR EXIT FAILURE;
WITH
pdbs AS (
    SELECT DISTINCT dbid, pdb_name, con_dbid
    FROM DBA_HIST_PDB_INSTANCE
    WHERE pdb_name = '$pdb_name_filter'
),
all_monthly_snapshots AS (
    SELECT
        s.end_interval_time,
        (tsu.tablespace_usedsize * df.block_size) / 1024 / 1024 AS used_mb_raw,
        df.tsname AS tablespace_name,
        s.dbid,
        p.pdb_name
    FROM
        dwa_hist_tbspc_space_usage tsu -- Usar dwa_hist_tbspc_space_usage si viene de DWA
        JOIN dba_hist_snapshot s ON tsu.snap_id = s.snap_id AND tsu.dbid = s.dbid
        JOIN dba_hist_datafile df ON tsu.dbid = df.dbid AND tsu.tablespace_id = df.ts#
        JOIN dbsnmp.caw_dbid_mapping m ON s.dbid = m.new_dbid
        JOIN pdbs p ON tsu.con_dbid = p.con_dbid
    WHERE
        s.END_INTERVAL_TIME >= ADD_MONTHS(TRUNC(SYSDATE, 'MM'), -1) -- Inicio del último mes completo
        AND s.END_INTERVAL_TIME < TRUNC(SYSDATE, 'MM')              -- Fin del último mes completo (exclusivo)
        AND df.tsname = '$tbs_name'
        AND m.target_name = '$target_name_filter'
        AND df.tsname NOT IN ('UNDO1', 'UNDO2', 'TEMP', 'PDB$SEED')
),
ranked_monthly_usage AS (
    SELECT
        used_mb_raw,
        ROW_NUMBER() OVER (PARTITION BY tablespace_name, dbid, pdb_name ORDER BY end_interval_time ASC) AS rn_asc,
        ROW_NUMBER() OVER (PARTITION BY tablespace_name, dbid, pdb_name ORDER BY end_interval_time DESC) AS rn_desc
    FROM
        all_monthly_snapshots
)
SELECT
    NVL(
        ROUND(
            MAX(CASE WHEN rn_desc = 1 THEN used_mb_raw END) -
            MAX(CASE WHEN rn_asc = 1 THEN used_mb_raw END)
        , 2)
    , 0)
FROM
    ranked_monthly_usage;
EOF
}

#-----------------------------------------
# Obtener resumen de crecimiento anual por mes (para resumen histórico detallado)
# (Usando TRUNC(SYSDATE, 'MM') en SQL para fechas)
#-----------------------------------------
get_monthly_growth_summary() {
    local conn_awr="$1"
    local tbs_name="$2"
    local pdb_name_filter="$3"
    local target_name_filter="$4"

    log_debug "Generando resumen mensual de crecimiento para '$tbs_name' en PDB '$pdb_name_filter' (Target: '$target_name_filter') para los últimos 12 meses."

    sqlplus -s "$conn_awr" <<EOF
SET LINESIZE 300 PAGESIZE 100 FEEDBACK OFF
WHENEVER SQLERROR EXIT FAILURE;
WITH
pdbs AS (
    SELECT DISTINCT dbid, pdb_name, con_dbid
    FROM DBA_HIST_PDB_INSTANCE
    WHERE pdb_name = '$pdb_name_filter'
),
monthly_last_snapshot AS (
    SELECT
        TRUNC(s.END_INTERVAL_TIME, 'MM') AS month_start_date,
        df.tsname AS tablespace_name,
        (tsu.tablespace_usedsize * df.block_size) / 1024 / 1024 AS tablespace_used_mb,
        ROW_NUMBER() OVER (PARTITION BY TRUNC(s.END_INTERVAL_TIME, 'MM'), df.tsname, s.dbid, p.pdb_name ORDER BY s.END_INTERVAL_TIME DESC) AS rn
    FROM
        dwa_hist_tbspc_space_usage tsu -- Usar dwa_hist_tbspc_space_usage si viene de DWA
        JOIN dba_hist_snapshot s ON tsu.snap_id = s.snap_id AND tsu.dbid = s.dbid
        JOIN dba_hist_datafile df ON tsu.dbid = df.dbid AND tsu.tablespace_id = df.ts#
        JOIN dbsnmp.caw_dbid_mapping m ON s.dbid = m.new_dbid
        JOIN pdbs p ON tsu.con_dbid = p.con_dbid
    WHERE
        s.END_INTERVAL_TIME >= ADD_MONTHS(TRUNC(SYSDATE, 'MM'), -12) -- Inicio de los últimos 12 meses completos
        AND s.END_INTERVAL_TIME < TRUNC(SYSDATE, 'MM')               -- Fin de los últimos 12 meses completos (exclusivo)
        AND df.tsname = '$tbs_name'
        AND m.target_name = '$target_name_filter'
        AND df.tsname NOT IN ('UNDO1', 'UNDO2', 'TEMP', 'PDB$SEED')
),
calculated_growth AS (
    SELECT
        month_start_date,
        tablespace_name,
        tablespace_used_mb,
        LAG(tablespace_used_mb) OVER (PARTITION BY tablespace_name ORDER BY month_start_date) AS previous_month_used_mb
    FROM
        monthly_last_snapshot
    WHERE rn = 1
)
SELECT
    TO_CHAR(month_start_date, 'YYYY-MM') AS mes,
    NVL(ROUND(tablespace_used_mb - previous_month_used_mb, 2), 0) AS crecimiento_mb
FROM
    calculated_growth
WHERE previous_month_used_mb IS NOT NULL
ORDER BY
    month_start_date;
EOF
}


#-----------------------------------------
# Obtener el tamaño ACTUALMENTE UTILIZADO del tablespace en MB desde dba_segments.
# Se conecta a la BBDD de standby.
#-----------------------------------------
get_current_tbs_used_size_mb() {
    local conn_str="$1" # Conexión a la BBDD que tiene los segmentos (ej. standby o prod)
    local tbs_name="$2"

    log_debug "Obteniendo tamaño ACTUALMENTE UTILIZADO para tablespace: $tbs_name de $conn_str"
    sqlplus -s "$conn_str" <<EOF
SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
SELECT ROUND(SUM(bytes)/1024/1024, 2)
FROM dba_segments
WHERE tablespace_name = '$tbs_name'
GROUP BY tablespace_name;
EOF
}

#-----------------------------------------
# Obtener el tamaño ACTUALMENTE ASIGNADO (ALLOCATED) del tablespace en MB
# desde dba_data_files. Esto representa el tamaño físico del datafile.
# Se conecta a la BBDD de standby .
#-----------------------------------------
get_current_tbs_allocated_size_mb_from_db() {
    local conn_str="$1" # Conexión a la BBDD (ej. standby o prod)
    local tbs_name="$2"

    log_debug "Obteniendo tamaño ACTUALMENTE ASIGNADO para tablespace: $tbs_name de $conn_str"
    sqlplus -s "$conn_str" <<EOF
SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
SELECT ROUND(SUM(bytes)/1024/1024, 2)
FROM dba_data_files
WHERE tablespace_name = '$tbs_name'
GROUP BY tablespace_name;
EOF
}


#-----------------------------------------
# Proceso principal
#-----------------------------------------
main() {
    local conn_stby="${USUARIO_STANDBY}/${CLAVE_STANDBY}@${ORACLE_SID_STANDBY}"
    local conn_awr="${USUARIO_AWR}/${CLAVE_AWR}@${ORACLE_SID_AWR}"

    verifica_sqlplus "$conn_stby"
    verifica_sqlplus "$conn_awr"

    log_debug "Obteniendo listado de tablespaces desde $ORACLE_SID_STANDBY..."
    mapfile -t tablespaces < <(get_tablespaces "$conn_stby" | tr -d '\r')

    if [ ${#tablespaces[@]} -eq 0 ]; then
        log_debug "No se encontraron tablespaces para monitorear."
        echo "OK: No se encontraron tablespaces para monitorear (excluyendo sistema/temp)."
        exit 0
    fi

    local informe=""
    local alter_commands_generated=""
    local tablespaces_to_alert=()

    for tbs_name in "${tablespaces[@]}"; do
        if [[ -z "$tbs_name" ]]; then
            continue
        fi

        log_debug "Analizando tablespace: $tbs_name"

        current_tbs_used_size_mb=$(get_current_tbs_used_size_mb "$conn_stby" "$tbs_name" | tr -d '[:space:]\r')
        current_tbs_allocated_size_mb=$(get_current_tbs_allocated_size_mb_from_db "$conn_stby" "$tbs_name" | tr -d '[:space:]\r')
        # last_month_growth will now be obtained correctly from the SQL query itself
        last_month_growth=$(get_last_month_total_growth "$conn_awr" "$tbs_name" "$PDB_NAME_TO_MONITOR" "$DB_TARGET_NAME" | tr -d '[:space:]\r')

        log_debug "$tbs_name: Used=${current_tbs_used_size_mb}MB, Allocated=${current_tbs_allocated_size_mb}MB, Last_Month_Growth=${last_month_growth}MB"

        if [[ "$current_tbs_used_size_mb" =~ ^[0-9]+([.][0-9]+)?$ ]] && \
           [[ "$current_tbs_allocated_size_mb" =~ ^[0-9]+([.][0-9]+)?$ ]] && \
           [[ "$last_month_growth" =~ ^-?[0-9]+([.][0-9]+)?$ ]]; then

            # Calculate free space
            free_space_mb=$(echo "$current_tbs_allocated_size_mb - $current_tbs_used_size_mb" | bc)
            log_debug "Free Space for $tbs_name: ${free_space_mb}MB"

            # Check if free space is less than last month's growth
            comp=$(echo "$free_space_mb < $last_month_growth" | bc)

            if [[ $comp -eq 1 ]]; then
                tablespaces_to_alert+=("$tbs_name")

                informe+=$'\n'"--- Tablespace: ${tbs_name} ---"
                informe+=$'\n'"  > Tamaño Utilizado: ${current_tbs_used_size_mb} MB"
                informe+=$'\n'"  > Tamaño Asignado (Reservado): ${current_tbs_allocated_size_mb} MB"
                informe+=$'\n'"  > Espacio Libre Disponible: ${free_space_mb} MB"
                informe+=$'\n'"  > Crecimiento último mes: ${last_month_growth} MB"
                informe+=$'\n'"  > Alerta: El espacio libre (${free_space_mb} MB) es menor que el crecimiento del último mes (${last_month_growth} MB)."

                informe+=$'\n'
                informe+=$'\n'"------------------------------------------------------------"

                informe+=$'\n'"Resumen de crecimiento mensual para $tbs_name (últimos 12 meses):"
                # get_monthly_growth_summary now also uses SQL dates
                informe+=$'\n'"$(get_monthly_growth_summary "$conn_awr" "$tbs_name" "$PDB_NAME_TO_MONITOR" "$DB_TARGET_NAME" | tr -d '\r')"

                # Calculate the suggested resize command
                target_size_calculated=$(echo "$current_tbs_used_size_mb + $last_month_growth" | bc)

                new_size_mb=$(echo "scale=0; if ($current_tbs_allocated_size_mb > $target_size_calculated) $current_tbs_allocated_size_mb else $target_size_calculated" | bc)

                new_size_mb=$(echo "$new_size_mb" | awk '{print int($1)}')

                informe+=$'\n'
                alter_cmd="ALTER TABLESPACE \"$tbs_name\" RESIZE ${new_size_mb}M;"
                informe+=$'\n'"COMANDO SUGERIDO (ejecutar en PDB de producción):"
                informe+=$'\n'"${alter_cmd}"
                alter_commands_generated+=$'\n'"${alter_cmd}"
                informe+=$'\n'
            else
                log_debug "Tablespace $tbs_name tiene suficiente espacio libre (${free_space_mb} MB) para el crecimiento del último mes (${last_month_growth} MB)."
            fi
        else
            informe+=$'\n'"ADVERTENCIA: No se pudieron obtener todos los datos (USADO, ASIGNADO o CRECIMIENTO) para el tablespace $tbs_name."
            log_debug "ADVERTENCIA: Datos incompletos para $tbs_name. Used: '$current_tbs_used_size_mb', Allocated: '$current_tbs_allocated_size_mb', Growth: '$last_month_growth'"
        fi
    done

    if [ ${#tablespaces_to_alert[@]} -gt 0 ]; then
        log_debug "Enviando informe por correo..."
        (
            echo -e "📈 Alerta de Espacio en Tablespaces - ¡Necesitan Ampliación Pronto! 📈\n"
            echo -e "Los siguientes tablespaces tienen menos espacio libre disponible que su crecimiento del último mes:\n"
            echo -e "$informe"
            if [ -n "$alter_commands_generated" ]; then
                echo -e "\n--- Resumen de Comandos ALTER TABLESPACE Generados (para ejecutar en PDB de producción) ---"
                echo -e "$alter_commands_generated"
            fi
        ) | mail -s "🚨 Alerta de espacio en Tablespaces - ${PDB_NAME_TO_MONITOR}" "$MAIL_DESTINO"
        echo "CRITICAL: Informe de alerta de espacio en tablespaces enviado."
    else
        log_debug "No hay tablespaces que necesiten ampliación urgente."
        echo "OK: No hay tablespaces con espacio libre menor que su crecimiento del último mes."
    fi
}

main

Un Ejemplo de su Ejecución (Log Obfuscado)

Aquí puedes ver cómo se vería la salida del script en un entorno de depuración (DEBUG=true).

[xxxxxx@host-monitor-001 plugins]$ /usr/local/ncpa/plugins/monitor_tbs_growth.sh
[DEBUG] 2025-07-31 10:21:08 Intentando conectar a: system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:08 Conexión exitosa a: system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:08 Intentando conectar a: system/******@MY_AWR_DB
[DEBUG] 2025-07-31 10:21:08 Conexión exitosa a: system/******@MY_AWR_DB
[DEBUG] 2025-07-31 10:21:08 Obteniendo listado de tablespaces desde MY_PDB_STBY...
[DEBUG] 2025-07-31 10:21:08 Obteniendo listado de tablespaces de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:08 Analizando tablespace: AUDIT_DATA
[DEBUG] 2025-07-31 10:21:08 Obteniendo tamaño ACTUALMENTE UTILIZADO para tablespace: AUDIT_DATA de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:08 Obteniendo tamaño ACTUALMENTE ASIGNADO para tablespace: AUDIT_DATA de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:09 Calculando crecimiento TOTAL para 'AUDIT_DATA' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para el último mes completo.
[DEBUG] 2025-07-31 10:21:11 AUDIT_DATA: Used=80.38MB, Allocated=600MB, Last_Month_Growth=-8MB
[DEBUG] 2025-07-31 10:21:11 Free Space for AUDIT_DATA: 519.62MB
[DEBUG] 2025-07-31 10:21:11 Tablespace AUDIT_DATA tiene suficiente espacio libre (519.62 MB) para el crecimiento del último mes (-8 MB).
[DEBUG] 2025-07-31 10:21:11 Analizando tablespace: LOG_ARCHIVE
[DEBUG] 2025-07-31 10:21:11 Obteniendo tamaño ACTUALMENTE UTILIZADO para tablespace: LOG_ARCHIVE de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:11 Obteniendo tamaño ACTUALMENTE ASIGNADO para tablespace: LOG_ARCHIVE de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:11 Calculando crecimiento TOTAL para 'LOG_ARCHIVE' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para el último mes completo.
[DEBUG] 2025-07-31 10:21:14 LOG_ARCHIVE: Used=8.63MB, Allocated=1024MB, Last_Month_Growth=71.75MB
[DEBUG] 2025-07-31 10:21:14 Free Space for LOG_ARCHIVE: 1015.37MB
[DEBUG] 2025-07-31 10:21:14 Tablespace LOG_ARCHIVE tiene suficiente espacio libre (1015.37 MB) para el crecimiento del último mes (71.75 MB).
[DEBUG] 2025-07-31 10:21:14 Analizando tablespace: APP_CONFIG
[DEBUG] 2025-07-31 10:21:14 Obteniendo tamaño ACTUALMENTE UTILIZADO para tablespace: APP_CONFIG de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:14 Obteniendo tamaño ACTUALMENTE ASIGNADO para tablespace: APP_CONFIG de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:14 Calculando crecimiento TOTAL para 'APP_CONFIG' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para el último mes completo.
[DEBUG] 2025-07-31 10:21:16 APP_CONFIG: Used=75.81MB, Allocated=100MB, Last_Month_Growth=0MB
[DEBUG] 2025-07-31 10:21:16 Free Space for APP_CONFIG: 24.19MB
[DEBUG] 2025-07-31 10:21:16 Tablespace APP_CONFIG tiene suficiente espacio libre (24.19 MB) para el crecimiento del último mes (0 MB).
... (salida omitida para brevedad, pero seguiría para todos los tablespaces) ...
[DEBUG] 2025-07-31 10:21:36 Analizando tablespace: SALES_DATA_2025
[DEBUG] 2025-07-31 10:21:36 Obteniendo tamaño ACTUALMENTE UTILIZADO para tablespace: SALES_DATA_2025 de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:36 Obteniendo tamaño ACTUALMENTE ASIGNADO para tablespace: SALES_DATA_2025 de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:36 Calculando crecimiento TOTAL para 'SALES_DATA_2025' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para el último mes completo.
[DEBUG] 2025-07-31 10:21:39 SALES_DATA_2025: Used=120324.75MB, Allocated=126700MB, Last_Month_Growth=20241.5MB
[DEBUG] 2025-07-31 10:21:39 Free Space for SALES_DATA_2025: 6375.25MB
[DEBUG] 2025-07-31 10:21:39 Generando resumen mensual de crecimiento para 'SALES_DATA_2025' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para los últimos 12 meses.
... (más output de debug) ...
[DEBUG] 2025-07-31 10:21:47 Analizando tablespace: FILE_STORAGE
[DEBUG] 2025-07-31 10:21:47 Obteniendo tamaño ACTUALMENTE UTILIZADO para tablespace: FILE_STORAGE de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:47 Obteniendo tamaño ACTUALMENTE ASIGNADO para tablespace: FILE_STORAGE de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:21:47 Calculando crecimiento TOTAL para 'FILE_STORAGE' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para el último mes completo.
[DEBUG] 2025-07-31 10:21:47 FILE_STORAGE: Used=110707MB, Allocated=116736MB, Last_Month_Growth=20989MB
[DEBUG] 2025-07-31 10:21:47 Free Space for FILE_STORAGE: 6029MB
[DEBUG] 2025-07-31 10:21:47 Generando resumen mensual de crecimiento para 'FILE_STORAGE' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para los últimos 12 meses.
... (más output de debug) ...
[DEBUG] 2025-07-31 10:22:39 Analizando tablespace: TXN_DATA_2025
[DEBUG] 2025-07-31 10:22:39 Obteniendo tamaño ACTUALMENTE UTILIZADO para tablespace: TXN_DATA_2025 de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:22:39 Obteniendo tamaño ACTUALMENTE ASIGNADO para tablespace: TXN_DATA_2025 de system/******@MY_PDB_STBY
[DEBUG] 2025-07-31 10:22:39 Calculando crecimiento TOTAL para 'TXN_DATA_2025' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para el último mes completo.
[DEBUG] 2025-07-31 10:22:42 TXN_DATA_2025: Used=85135.88MB, Allocated=89700MB, Last_Month_Growth=13935.13MB
[DEBUG] 2025-07-31 10:22:42 Free Space for TXN_DATA_2025: 4564.12MB
[DEBUG] 2025-07-31 10:22:42 Generando resumen mensual de crecimiento para 'TXN_DATA_2025' en PDB 'MY_APP_PDB' (Target: 'my_cdb_prod') para los últimos 12 meses.
[DEBUG] 2025-07-31 10:22:50 Enviando informe por correo...
CRITICAL: Informe de alerta de espacio en tablespaces enviado.

En este log, vemos cómo el script analiza cada tablespace. Por ejemplo:

• AUDIT_DATA: Tuvo un crecimiento negativo (-8MB), lo que significa que el espacio libre actual (519.62MB) es más que suficiente. ¡No hay alerta!

• SALES_DATA_2025: Mostró un crecimiento significativo de 20241.5MB en el último mes, pero solo tiene 6375.25MB de espacio libre. Esto dispara una alerta, ya que el espacio libre es menor que el crecimiento mensual. El script te enviaría un comando ALTER TABLESPACE "SALES_DATA_2025" RESIZE <nuevo_tamaño>M; sugerido.

• FILE_STORAGE: Un patrón similar al anterior, con 6029MB de espacio libre y un crecimiento de 20989MB. También generaría una alerta.

• TXN_DATA_2025: Otro tablespace que necesita atención, con 4564.12MB libres frente a un crecimiento de 13935.13MB.

El Correo Electrónico de Alerta

Cuando se detecta un tablespace que necesita atención, el script genera un correo electrónico con un resumen detallado. Así es como se vería un correo de alerta , similar al que recibirías en tu bandeja de entrada:

Asunto: 🚨 Alerta de espacio en Tablespaces - [Nombre de tu PDB/Base de Datos]

Cuerpo del Correo:

📈 Alerta de Espacio en Tablespaces - ¡Necesitan Ampliación Pronto! 📈

Estimados administradores de bases de datos,

Se ha detectado que los siguientes tablespaces en la base de datos '[Nombre de tu PDB/Base de Datos]' tienen menos espacio libre disponible que su crecimiento registrado en el último mes. Esto indica una necesidad inminente de ampliación para evitar posibles interrupciones en el servicio.

--- Tablespace: SALES_DATA_2025 ---
  > Tamaño Utilizado: 120324.75 MB
  > Tamaño Asignado (Reservado): 126700 MB
  > Espacio Libre Disponible: 6375.25 MB
  > Crecimiento último mes: 20241.5 MB
  > Alerta: El espacio libre (6375.25 MB) es menor que el crecimiento del último mes (20241.5 MB).

------------------------------------------------------------
Resumen de crecimiento mensual para SALES_DATA_2025 (últimos 12 meses):

MES CRECIMIENTO_MB
------- --------------
2025-02        14223.5
2025-03        15952.5
2025-04        17006.5
2025-05       18854.38
2025-06        20241.5

COMANDO SUGERIDO (ejecutar en PDB de producción):
ALTER TABLESPACE "SALES_DATA_2025" RESIZE 140566M;

--- Tablespace: FILE_STORAGE ---
  > Tamaño Utilizado: 110707 MB
  > Tamaño Asignado (Reservado): 116736 MB
  > Espacio Libre Disponible: 6029 MB
  > Crecimiento último mes: 20989 MB
  > Alerta: El espacio libre (6029 MB) es menor que el crecimiento del último mes (20989 MB).

------------------------------------------------------------
Resumen de crecimiento mensual para FILE_STORAGE (últimos 12 meses):

MES CRECIMIENTO_MB
------- --------------
2024-09          0
2024-10          0
2024-11          0
2024-12          0
2025-01          0
2025-02          0
2025-03        384
2025-04       8512
2025-05       20802.88
2025-06      21053

COMANDO SUGERIDO (ejecutar en PDB de producción):
ALTER TABLESPACE "FILE_STORAGE" RESIZE 131696M;

--- Tablespace: TXN_DATA_2025 ---
  > Tamaño Utilizado: 85135.88 MB
  > Tamaño Asignado (Reservado): 89700 MB
  > Espacio Libre Disponible: 4564.12 MB
  > Crecimiento último mes: 13935.13 MB
  > Alerta: El espacio libre (4564.12 MB) es menor que el crecimiento del último mes (13935.13 MB).

------------------------------------------------------------
Resumen de crecimiento mensual para TXN_DATA_2025 (últimos 12 meses):

MES CRECIMIENTO_MB
------- --------------
2025-02       10391.25
2025-03       11487.31
2025-04       12062.13
2025-05       13312.31
2025-06       13935.13

COMANDO SUGERIDO (ejecutar en PDB de producción):
ALTER TABLESPACE "TXN_DATA_2025" RESIZE 99071M;


--- Resumen de Comandos ALTER TABLESPACE Generados (para ejecutar en PDB de producción) ---

ALTER TABLESPACE "SALES_DATA_2025_OFS" RESIZE 140566M;
ALTER TABLESPACE "FILE_STORAGE_OFS" RESIZE 131696M;
ALTER TABLESPACE "TXN_DATA_2025_OFS" RESIZE 99071M;

Por favor, revisen estos tablespaces y consideren aplicar las acciones sugeridas lo antes posible.

Atentamente,

El equipo de Monitorización de Bases de Datos
[Tu Empresa/Organización]

¡Lleva la Gestión de DB al Siguiente Nivel!

Este script no solo te ayuda a evitar interrupciones, sino que te permite planificar tus ampliaciones de tablespaces con antelación, basándote en datos reales y no en suposiciones.

Sin embargo, en entornos donde se utilizan proxy users, he identificado un fallo poco documentado que provoca que la redirección del DML falle aunque esté configurado correctamente.

Contexto: ¿qué es DML Redirect?

Desde Oracle 19c, si activas:

ALTER SYSTEM SET ADG_REDIRECT_DML = TRUE SCOPE = BOTH;

y la standby está en modo READ ONLY WITH APPLY, cualquier DML que ejecutes en la standby se redirige automáticamente al primario. Luego el cambio se aplica en la standby vía redo logs.

Cual es el problema?

Cuando te conectas a la standby mediante un proxy user—por ejemplo, proxy_user[target_user]—y se ejecuta un UPDATE, aparece:

ORA-16397: statement redirection from Oracle Active Data Guard standby database to primary database failed

Pero si te conectas directamente como target_user, el mismo UPDATE funciona sin problemas, redirigiéndose correctamente a la primaria.

Esto sucede a pesar de tener:

ADG_REDIRECT_DML=TRUE en ambas bases (primaria y standby)

Causa del comportamiento

Oracle, en la doc (error ORA-16397), indica que la redirección falla si "el usuario actual y el usuario conectado no son iguales"

Al usar proxy users, la sesión incorpora ambas identidades (proxy + target), por lo que Oracle detecta una discrepancia entre el usuario registrado y el usuario del esquema, bloqueando la redirección DML que debería activar ADG_REDIRECT_DML.

Recomendaciones prácticas

Para operaciones DML que se redirigirán desde la standby, no utilices proxy users.

Conéctate directamente como usuario “al uso“:

sqlplus target_user/password@standby

Asegúrate de que:

ADG_REDIRECT_DML=TRUE.

La standby está en READ ONLY WITH APPLY y con real-time apply activo.

Si el uso de proxy user es imprescindible, redirige estas conexiones al primario o crea un método alternativo (DB link).

El parámetro ADG_REDIRECT_DML activa la capacidad de redirigir DML desde la standby hacia el primario en Active Data Guard, pero no puede operar cuando se usa un proxy user, ya que Oracle detecta una inconsisténcia de identidad y cancela el redireccionamiento.

¿Qué dice la documentación?

Si buscamos ORA‑16397 puede deberse a varias causas:

1. cadena de conexión al primario no establecida ←No es el caso

2. primario no disponible←No es el caso

3. usuario actual ≠ usuario logado

4. redirección DML no soportada para PL/SQL con binds←No es el caso

5. real-time apply no activo ←No es el caso

El único punto que encaja con mi caso es “usuario actual y usuario logado no son el mismo”. Sin embargo, no hay ninguna referencia a proxy users, aunque encajan perfectamente en esa descripción. por lo que es recomendable evitar proxy users en sesiones que requieran redirección DML, usando conexiones directas en su lugar. Un matiz que no está documentado y puede generar confusión, pero que esta implementación ha sacado a la luz.

Hoy quiero compartir un script bash que he desarrollado para procesar esos logs, obtener estadísticas de conexiones por minuto y desglosarlas por servicio. Te explico cómo funciona y por qué puede ser una herramienta útil en tu día a día.

¿Qué hace este script?

• Lee uno o varios archivos listener.log de Oracle, incluyendo posibles rotaciones.

• Filtra las líneas correspondientes a una fecha y rango horario definidos (ejemplo: entre las 08:00 y las 12:00 de un día).

• Extrae la hora exacta (hasta minuto) y el nombre del servicio (SERVICE_NAME) usado en cada conexión establecida.

Calcula y muestra:

• El número total de conexiones por minuto.

• El número total de conexiones por servicio.

• Presenta el resultado ordenado cronológicamente y alfabéticamente para facilitar su interpretación.

¿Cómo funciona el script?

Variables configurables:

• LISTENER_LOG_PATH y LISTENER_LOG_PATTERN para definir dónde están los logs y qué archivos leer.

• FECHA, HORA_INICIO y HORA_FIN para definir el intervalo temporal a analizar.

¿Qué aporta a un DBA?

• Visibilidad precisa: Podrás identificar en qué minutos se producen picos de conexión y si estos corresponden a servicios específicos, permitiendo detectar patrones anómalos.

• Diagnóstico rápido: Al saber qué servicios están más activos, puedes priorizar análisis o acciones sobre aplicaciones concretas.

• Soporte a troubleshooting: Ayuda a relacionar problemas de rendimiento o caídas con la carga real sobre el listener.

• Automatización sencilla: El script se puede integrar en tareas cron para generar informes periódicos sin intervención manual.

#!/bin/bash

# Ruta a listener.log (puedes usar comodines)
LISTENER_LOG_PATH="/path_a_ruta_listener/listener/trace"
LISTENER_LOG_PATTERN="listener*.log"

# Rango horario a analizar
FECHA="20-JUN-2025"
HORA_INICIO="08:00"
HORA_FIN="12:00"

echo "Conexiones por minuto en listener.log entre \(HORA_INICIO y \)HORA_FIN del $FECHA"
echo

# Leer y procesar los logs
cat \(LISTENER_LOG_PATH/\)LISTENER_LOG_PATTERN 2>/dev/null | grep "$FECHA" | grep "CONNECT_DATA" | \
awk -v start="\(HORA_INICIO" -v end="\)HORA_FIN" '
{
  fecha = $1
  hora = $2
  minuto = substr(hora, 1, 5)

  if (minuto >= start && minuto <= end) {
    conexiones[minuto]++

    match($0, /SERVICE_NAME=[^)]+/, svc)
    if (svc[0] != "") {
      split(svc[0], tmp, "=")
      servicio = tmp[2]
      servicio_conexiones[servicio]++
    }
  }
}

END {
  print "Conexiones por minuto:"
  PROCINFO["sorted_in"] = "@ind_str_asc"
  for (t in conexiones) {
    printf "  %s → %d conexiones\n", t, conexiones[t]
  }

  print "\n Conexiones por SERVICE_NAME:"
  PROCINFO["sorted_in"] = "@ind_str_asc"
  for (s in servicio_conexiones) {
    printf "  %s → %d conexiones\n", s, servicio_conexiones[s]
  }
}'

Ejemplo de salida:

[xxxxxxxx@xxx-xxx-xxx ~]$ ./analisis_listener.sh
Conexiones por minuto en listener.log entre 08:00 y 12:00 del 20-JUN-2025

Conexiones por minuto:
  08:00 → 1274 conexiones
  08:01 → 1319 conexiones
  08:02 → 1326 conexiones
  08:03 → 1335 conexiones
  08:04 → 1254 conexiones
  08:05 → 1195 conexiones
  08:06 → 1196 conexiones
  08:07 → 1193 conexiones
  08:08 → 1194 conexiones
  08:09 → 1217 conexiones
  08:10 → 1192 conexiones
  08:11 → 1194 conexiones
  08:12 → 1211 conexiones
  08:13 → 1187 conexiones
  08:14 → 1199 conexiones
  08:15 → 1178 conexiones
  08:16 → 1209 conexiones
  08:17 → 1178 conexiones
  08:18 → 1177 conexiones
  08:19 → 1192 conexiones
  08:20 → 1213 conexiones
  08:21 → 1194 conexiones
  08:22 → 1177 conexiones
  08:23 → 1184 conexiones
  08:24 → 1183 conexiones
  08:25 → 1192 conexiones
  08:26 → 1220 conexiones
  08:27 → 1200 conexiones
  08:28 → 1220 conexiones
  08:29 → 1184 conexiones
  08:30 → 1196 conexiones
  08:31 → 1214 conexiones
  08:32 → 1233 conexiones
  08:33 → 1201 conexiones
  08:34 → 1223 conexiones
  08:35 → 1209 conexiones
  08:36 → 1219 conexiones
  08:37 → 1212 conexiones
  08:38 → 1194 conexiones
  08:39 → 1196 conexiones
  08:40 → 1219 conexiones
  08:41 → 1227 conexiones
  08:42 → 1207 conexiones
  08:43 → 1194 conexiones
  08:44 → 1204 conexiones
  08:45 → 1236 conexiones
  08:46 → 1212 conexiones
  08:47 → 1209 conexiones
  08:48 → 1215 conexiones
  08:49 → 1213 conexiones
  08:50 → 1183 conexiones
  08:51 → 1165 conexiones
  08:52 → 1204 conexiones
  08:53 → 1224 conexiones
  08:54 → 1182 conexiones
  08:55 → 1180 conexiones
  08:56 → 1187 conexiones
  08:57 → 1218 conexiones
  08:58 → 1214 conexiones
  08:59 → 1211 conexiones
  09:00 → 1240 conexiones
  09:01 → 1253 conexiones
  09:02 → 1239 conexiones
  09:03 → 1256 conexiones
  09:04 → 1225 conexiones
  09:05 → 1253 conexiones
  09:06 → 1230 conexiones
  09:07 → 1236 conexiones
  09:08 → 1200 conexiones
  09:09 → 1210 conexiones
  09:10 → 1240 conexiones
  09:11 → 1235 conexiones
  09:12 → 1209 conexiones
  09:13 → 1221 conexiones
  09:14 → 1195 conexiones
  09:15 → 1194 conexiones
  09:16 → 1221 conexiones
  09:17 → 1219 conexiones
  09:18 → 1178 conexiones
  09:19 → 1189 conexiones
  09:20 → 1212 conexiones
  09:21 → 1201 conexiones
  09:22 → 1228 conexiones
  09:23 → 1230 conexiones
  09:24 → 1238 conexiones
  09:25 → 1229 conexiones
  09:26 → 1219 conexiones
  09:27 → 1208 conexiones
  09:28 → 1240 conexiones
  09:29 → 1222 conexiones
  09:30 → 1222 conexiones
  09:31 → 1215 conexiones
  09:32 → 1219 conexiones
  09:33 → 1224 conexiones
  09:34 → 1213 conexiones
  09:35 → 1223 conexiones
  09:36 → 1208 conexiones
  09:37 → 1187 conexiones
  09:38 → 1236 conexiones
  09:39 → 1205 conexiones
  09:40 → 1202 conexiones
  09:41 → 1187 conexiones
  09:42 → 1214 conexiones
  09:43 → 1204 conexiones
  09:44 → 1194 conexiones
  09:45 → 1198 conexiones
  09:46 → 1209 conexiones
  09:47 → 1240 conexiones
  09:48 → 1221 conexiones
  09:49 → 1212 conexiones
  09:50 → 1237 conexiones
  09:51 → 1223 conexiones
  09:52 → 1221 conexiones
  09:53 → 1222 conexiones
  09:54 → 1238 conexiones
  09:55 → 1227 conexiones
  09:56 → 1234 conexiones
  09:57 → 1238 conexiones
  09:58 → 1221 conexiones
  09:59 → 1233 conexiones
  10:00 → 1279 conexiones
  10:01 → 1227 conexiones
  10:02 → 1236 conexiones
  10:03 → 1195 conexiones
  10:04 → 1203 conexiones
  10:05 → 1218 conexiones
  10:06 → 1186 conexiones
  10:07 → 1221 conexiones
  10:08 → 1232 conexiones
  10:09 → 1176 conexiones
  10:10 → 1178 conexiones
  10:11 → 1222 conexiones
  10:12 → 1206 conexiones
  10:13 → 1218 conexiones
  10:14 → 1205 conexiones
  10:15 → 1218 conexiones
  10:16 → 1251 conexiones
  10:17 → 1247 conexiones
  10:18 → 1288 conexiones
  10:19 → 1263 conexiones
  10:20 → 1290 conexiones
  10:21 → 1223 conexiones
  10:22 → 1241 conexiones
  10:23 → 1208 conexiones
  10:24 → 1220 conexiones
  10:25 → 1267 conexiones
  10:26 → 1239 conexiones
  10:27 → 1207 conexiones
  10:28 → 1231 conexiones
  10:29 → 1245 conexiones
  10:30 → 1247 conexiones
  10:31 → 1197 conexiones
  10:32 → 1205 conexiones
  10:33 → 1207 conexiones
  10:34 → 1231 conexiones
  10:35 → 1197 conexiones
  10:36 → 1218 conexiones
  10:37 → 1234 conexiones
  10:38 → 1184 conexiones
  10:39 → 1222 conexiones
  10:40 → 1237 conexiones
  10:41 → 1221 conexiones
  10:42 → 1232 conexiones
  10:43 → 1243 conexiones
  10:44 → 1233 conexiones
  10:45 → 1268 conexiones
  10:46 → 1204 conexiones
  10:47 → 1225 conexiones
  10:48 → 1257 conexiones
  10:49 → 1235 conexiones
  10:50 → 1228 conexiones
  10:51 → 1217 conexiones
  10:52 → 1258 conexiones
  10:53 → 1246 conexiones
  10:54 → 1243 conexiones
  10:55 → 1229 conexiones
  10:56 → 1222 conexiones
  10:57 → 1220 conexiones
  10:58 → 1197 conexiones
  10:59 → 1220 conexiones
  11:00 → 1220 conexiones
  11:01 → 1216 conexiones
  11:02 → 1246 conexiones
  11:03 → 1254 conexiones
  11:04 → 1231 conexiones
  11:05 → 1226 conexiones
  11:06 → 1238 conexiones
  11:07 → 1219 conexiones
  11:08 → 1211 conexiones
  11:09 → 1231 conexiones
  11:10 → 1227 conexiones
  11:11 → 1242 conexiones
  11:12 → 1210 conexiones
  11:13 → 1225 conexiones
  11:14 → 1245 conexiones
  11:15 → 1231 conexiones
  11:16 → 1246 conexiones
  11:17 → 1253 conexiones
  11:18 → 1253 conexiones
  11:19 → 1228 conexiones
  11:20 → 1248 conexiones
  11:21 → 1225 conexiones
  11:22 → 1202 conexiones
  11:23 → 1198 conexiones
  11:24 → 1207 conexiones
  11:25 → 1244 conexiones
  11:26 → 1222 conexiones
  11:27 → 1201 conexiones
  11:28 → 1229 conexiones
  11:29 → 1223 conexiones
  11:30 → 1240 conexiones
  11:31 → 1212 conexiones
  11:32 → 1230 conexiones
  11:33 → 1248 conexiones
  11:34 → 1237 conexiones
  11:35 → 1226 conexiones
  11:36 → 1248 conexiones
  11:37 → 1232 conexiones
  11:38 → 1238 conexiones
  11:39 → 1245 conexiones
  11:40 → 1250 conexiones
  11:41 → 1261 conexiones
  11:42 → 1252 conexiones
  11:43 → 1252 conexiones
  11:44 → 1228 conexiones
  11:45 → 1241 conexiones
  11:46 → 1213 conexiones
  11:47 → 1210 conexiones
  11:48 → 1202 conexiones
  11:49 → 1238 conexiones
  11:50 → 1232 conexiones
  11:51 → 1235 conexiones
  11:52 → 1228 conexiones
  11:53 → 1222 conexiones
  11:54 → 1201 conexiones
  11:55 → 1261 conexiones
  11:56 → 1218 conexiones
  11:57 → 1247 conexiones
  11:58 → 1223 conexiones
  11:59 → 702 conexiones

Conexiones por SERVICE_NAME:
  servicio1.xxxxx.xxx → 18104 conexiones
  cdbxxx.xxxxx.xxx → 309 conexiones
  servicio2.xxxxxx.xxx → 715 conexiones
  servicio3.xxxxxx.xxx → 1847 conexiones
  servicio4.xxxxx.xxx → 55783 conexiones
  pdb_xxx.xxxxx.xxx → 6 conexiones
  servicio5.xxxxx.xxx → 15 conexiones
  servicio6.xxxxx.xxx → 215613 conexiones

Mejoras y personalizaciones

• Añadir un parámetro para filtrar por usuario o IP origen.

• Generar gráficos con herramientas como gnuplot o exportar a CSV.

• Integrar alertas si se detectan picos fuera de lo normal.

Dando rienda suelta a la imaginación y necesidades puede ser tu gran aliado.

La solución más inmediata que muchos aplican es usar la cláusula EXCLUDE=TABLE:"IN ('TABLA_X')" para omitirlas completamente. Pero, ¿es realmente la mejor opción?

En muchos casos, no lo es. Excluir una tabla completamente con EXCLUDE=TABLE implica que ni los datos ni la estructura de la tabla (metadata) estarán disponibles en el dump. Y eso puede traer problemas más adelante, sobre todo si se espera que esa tabla exista en el entorno de destino por dependencias o esquemas consistentes.

La alternativa: exportar solo la metadata

En lugar de excluir por completo una tabla, podemos indicarle a expdp que exporte la estructura pero no los datos. ¿Cómo? Utilizando la cláusula QUERY con una condición que nunca se cumpla, como WHERE 1 <> 1.

Ejemplo práctico

Supón que tenemos un export full como este:

cat expdp_parameters.par

exclude=statistics 
LOGTIME=ALL 
METRICS=Y 
flashback_time=systimestamp 
full=y 
parallel=4 
job_name=EXP_FULL_XXXX 
cluster=N 
QUERY=XXXX.TABLA_1:"where 1 <> 1" 
QUERY=XXXX.TABLA_2:"where 1 <> 1" 
QUERY=XXXX.TABLA_3:"where 1 <> 1"

En este ejemplo estamos diciendo:

"Quiero exportar toda la base de datos (full=y), pero para las tablas TABLA_1, TABLA_2 y TABLA_3, solo exporta la metadata.

Los datos no se exportarán porque la cláusula WHERE 1 <> 1 nunca se cumple."

¿Qué ventajas tiene esto?

• Preservas la estructura de las tablas: columnas, tipos de datos, constraints, etc.

• Mantienes integridad del esquema, especialmente si otras tablas, vistas o procedimientos dependen de la existencia de esas tablas.

• Evitas errores en la importación (impdp) por objetos faltantes.

• Reduces el tamaño del dump al no incluir datos innecesarios.

• Puedes recrear esas tablas vacías automáticamente en el entorno destino, lo cual puede ser muy útil en pruebas, clones o entornos de desarrollo.

¿Cuándo conviene excluir completamente con EXCLUDE=TABLE?

Solo si estás completamente seguro de que:

• No necesitas la estructura de la tabla en el entorno destino.

• No hay dependencias lógicas ni referenciales hacia esa tabla.

• Quieres que no exista en absoluto tras el impdp.

De lo contrario, usar QUERY=... WHERE 1<>1 es la mejor práctica.

Conclusión

A veces, las soluciones más simples no son las más adecuadas. Si necesitas excluir datos de una tabla en expdp pero deseas mantener su definición, usa la técnica de QUERY=... WHERE 1<>1. Evitarás muchos problemas de consistencia y podrás seguir trabajando con estructuras completas sin cargar datos innecesarios.

En algunos entornos Oracle gestionados desde Enterprise Manager Cloud Control (OEM), puede aparecer un error curioso y molesto en el alert log de la base de datos:

WARNING: too many parse errors, count=4390 SQL hash=0xb6a91e8f PARSE ERROR: ospid=3152219, error=904: Additional information: ... sqlid=fa9vmfqvak7ng Current username=SYS

Este tipo de error suele estar relacionado con llamadas automáticas que hace OEM a paquetes PL/SQL internos. En este caso concreto, se trataba del paquete OMC_ASH_VIEWER, que no estaba correctamente desplegado en la base de datos. Ups!!

Diagnóstico

Para confirmar que el error estaba relacionado con el paquete OMC_ASH_VIEWER ejecutamos:

SELECT dbsnmp.OMC_ASH_VIEWER.getVersion() FROM dual;
ORA-00904: "DBSNMP"."OMC_ASH_VIEWER"."GETVERSION": invalid identifier

¿Qué es OMC_ASH_VIEWER?

Es un paquete PL/SQL creado por OEM dentro del esquema DBSNMP, que se utiliza para recolectar datos de:

• Active Session History (ASH)

• AWR y CPU

• Sesiones bloqueadas

• Información de rendimiento en tiempo real o histórico

Este paquete forma parte del plugin oracle.sysman.db.oms.plugin, y se crea automáticamente mediante el job de OEM llamado:

Deploy Database Management PL/SQL Packages

Solución

Oracle ofrece una solución oficial (Doc ID 2769758.1) para este problema:

1. Ejecutar el job desde OEM:

Desde la consola de Enterprise Manager:

• Ir a Enterprise → Job → Activity

• Hacer clic en Create Job

• Buscar y seleccionar el tipo de job: Deploy Database Management PL/SQL Packages

• Seleccionar el target afectado (base de datos o PDB)

• Proporcionar credenciales SYSDBA válidas

• Ejecutar inmediatamente (o programar)

2. Verificación

Una vez desplegado correctamente, la siguiente consulta debería funcionar:

SYS@CDB$ROOT> SELECT dbsnmp.OMC_ASH_VIEWER.getVersion() FROM dual;

   DBSNMP.OMC_ASH_VIEWER.GETVERSION()
_____________________________________
60

Y el alert log ya no mostrará errores de parse.

¿Qué hace internamente este job?

Este job ejecuta scripts como:

• omc_ashv_pkg.sql y omc_ashv_pkg_body.sql: Definen el paquete OMC_ASH_VIEWER en DBSNMP

• priv_grant_omc_ash.sql: Asigna los permisos necesarios al paquete

Esto permite a OEM acceder a vistas como GV$SESSION, DBA_HIST_*, V$SQL, etc., y generar informes y gráficos en el panel de rendimiento.

Conclusión

Este tipo de error puede pasar desapercibido si no revisamos el alert log con frecuencia, pero puede generar carga innecesaria y confusión.

Afortunadamente, la solución es sencilla si sabemos lo que buscamos: verificar y desplegar correctamente los paquetes PL/SQL de gestión desde OEM.

¿Te ha pasado algo similar en tus entornos? ¡Cuéntamelo en los comentarios!