# Monitorizar QC en GV$SESSION

Tengo un escenario donde queremos monitorizar información de sesiones **entrando en juego paralelismo**.

¿Qué me dice el sentido común? ¿Queremos monitorizar en un **monitor de sesiones activas** procesos slave o los coordinadores? En nuestro escenario no tiene sentido duplicar sesiones en el monitor atendiendo a slaves. **Queremos el proceso principal**, el que coordina o si no es paralelo la sesión activa.

Para ello me he valido de la siguiente consulta:

```plaintext
SELECT
    a.inst_id,
    a.sid,
    a.username,
    a.machine,
    a.program,
    a.state,
    a.module,
    a.sql_exec_start,
    a.blocking_session,
    a.serial#,
    b.spid,
    a.action,
    a.resource_consumer_group
FROM
    gv$session a,
    gv$process b
WHERE
    ( a.paddr = b.addr )
    AND ( a.status LIKE 'ACTIVE' OR a.blocking_session IS NOT NULL )
    AND a.sql_exec_start IS NOT NULL
    AND a.username IS NOT NULL
    and a.inst_id=b.inst_id
    AND NOT EXISTS (
        -- Discrimino los slaves
        SELECT 1
        FROM GV$PX_SESSION px
        WHERE px.SID = a.SID AND px.SERIAL# = a.SERIAL# AND px.INST_ID = a.INST_ID and px.qcinst_id is not null
    );
```

Ubicamos PID en el nodo que aplica y discriminamos slaves, **queremos solo una entrada por padre**.

Por qué he tenido ésta inquietud? Porque aunque las consultas entre por un DOP contenido por Resource Manager con máximo paralelismo de 1, la consultas por GV$, en mi caso en un RAC de 2 nodos, siempre van a mostrar dos sesiones activas debido al siguiente comportamiento:

> When you query a GV$ view one PX server is allocated on each instance, these PX servers are not counted against parallel\_max\_servers so they do not effect the number of PX servers that can be used by statements accessing other objects.
> 
> Oracle controls and maintains all aspects of PZ processes. Setting parallel\_max\_servers to 0 will not prevent Oracle from starting PZ processes in a RAC environment if a GV$ query is issued. Setting parallel\_force\_local to TRUE does not restrict PZ operations to a specific instance. PZ processes are always used for gv$ queries regardless of any parallel\_\* parameter setting.

En resumen, el límite de DOP de 1 no aplica ni se puede contener para las GV$, en mi caso siempre abre 2 sesiones (una por nodo). Duplicando de esta manera sesiones activas en el monitor de sesiones.

Si queremos descartar las sesiones que consulten una GV$ adaptamos la consulta de la siguiente manera:

```plaintext
with paralelas as (
        SELECT px.sid,px.inst_id, pp.serial#
        FROM GV$PX_SESSION px,
        GV$PX_PROCESS pp
        WHERE px.SID = pp.SID 
              AND px.INST_ID= pp.INST_ID 
              and (px.qcinst_id is not null or pp.is_gv='TRUE')
)
SELECT 
    a.inst_id,
    a.sid,
    a.username,
    a.machine,
    a.program,
    a.state,
    a.module,
    a.sql_exec_start,
    a.blocking_session,
    a.serial#,
    b.spid,
    a.action,
    a.resource_consumer_group
FROM
    gv$session a,
    gv$process b
WHERE
    ( a.paddr = b.addr )
    AND a.sql_exec_start IS NOT NULL 
    AND a.username IS NOT NULL
    AND a.sid != (
        SELECT
            sys_context('USERENV', 'SID')
        FROM
            dual
    )
    and a.type = 'USER'
    and a.inst_id=b.inst_id
    AND NOT EXISTS (
        SELECT 1
        FROM paralelas par
        WHERE par.sid = a.SID 
              AND par.INST_ID = a.INST_ID 
    )
ORDER BY
    upper(a.machine),
    upper(a.program);
```