Cuando administramos una base de datos Oracle, una gran parte del troubleshooting comienza con una pregunta:

¿Qué está ocurriendo dentro de la base de datos en este momento?

Oracle proporciona las Dynamic Performance Views, conocidas normalmente como vistas V$, que permiten consultar información mantenida por la instancia sobre su estado y actividad.

Algunas de las más importantes son:

V$INSTANCE
V$DATABASE
V$SESSION
V$PROCESS
V$SQL
V$SQLAREA
V$LOCK
V$TRANSACTION
V$SGA
V$SGAINFO
V$PGASTAT
V$SYSTEM_EVENT
V$SESSION_EVENT
V$DATAFILE
V$TEMPFILE
V$LOG
V$LOGFILE
V$ARCHIVED_LOG
V$RECOVERY_FILE_DEST
V$RMAN_BACKUP_JOB_DETAILS
V$DATAGUARD_STATS

Veamos para qué sirve cada una.

1. V$INSTANCE — Estado de la instancia

Probablemente una de las primeras vistas que deberíamos conocer:

SELECT
    instance_name,
    host_name,
    version,
    status,
    startup_time
FROM v$instance;

Nos permite responder rápidamente:

¿En qué instancia estoy?
¿En qué servidor?
¿Está OPEN?
¿Cuándo arrancó?
¿Qué versión ejecuta?

Muy útil como primera comprobación durante un incidente.

2. V$DATABASE — Información de la base

SELECT
    name,
    db_unique_name,
    open_mode,
    database_role,
    log_mode,
    protection_mode
FROM v$database;

Esta consulta es especialmente útil en ambientes con Oracle Data Guard.

Podríamos encontrar:

NAME             PROD
DB_UNIQUE_NAME   PROD
OPEN_MODE        READ WRITE
DATABASE_ROLE    PRIMARY
LOG_MODE         ARCHIVELOG

En un Standby:

DATABASE_ROLE    PHYSICAL STANDBY
OPEN_MODE        READ ONLY WITH APPLY

3. V$SESSION — Sesiones conectadas

Una de las vistas más importantes para troubleshooting:

SELECT
    sid,
    serial#,
    username,
    status,
    machine,
    program,
    sql_id
FROM v$session
WHERE username IS NOT NULL;

Nos permite identificar:

usuarios;
aplicaciones;
sesiones activas;
servidores de origen;
programas;
SQL ejecutándose.

4. Buscar sesiones ACTIVE

SELECT
    sid,
    serial#,
    username,
    machine,
    program,
    sql_id,
    event
FROM v$session
WHERE status = 'ACTIVE'
AND username IS NOT NULL;

Esto puede ser muy útil cuando investigamos:

High CPU
Slow database
Blocking
Connection problems
Performance degradation

Pero recuerda: una sesión ACTIVE no significa automáticamente que exista un problema.

5. V$PROCESS — Procesos Oracle

SELECT
    pid,
    spid,
    pname,
    program
FROM v$process;

SPID permite relacionar Oracle con el PID del sistema operativo.

Por ejemplo:

Oracle Session
      ↓
V$SESSION
      ↓
V$PROCESS
      ↓
SPID
      ↓
Linux Process

Esto resulta especialmente útil cuando detectamos un proceso Oracle consumiendo mucho CPU desde Linux.

6. Relacionar Session con Process

Una consulta muy útil:

SELECT
    s.sid,
    s.serial#,
    s.username,
    s.status,
    s.sql_id,
    p.spid AS os_pid,
    s.machine,
    s.program
FROM v$session s
JOIN v$process p
    ON s.paddr = p.addr
WHERE s.username IS NOT NULL;

Ahora podemos relacionar:

SID
SERIAL#
SQL_ID
OS PID
Usuario
Aplicación
Servidor

Excelente para troubleshooting de CPU.

7. V$SQL — SQL almacenado en Shared SQL Area

Otra vista fundamental:

SELECT
    sql_id,
    executions,
    elapsed_time,
    cpu_time,
    buffer_gets,
    disk_reads,
    sql_text
FROM v$sql
WHERE sql_id = 'SQL_ID';

Permite investigar una sentencia SQL específica.

8. SQL con mayor CPU

Por ejemplo:

SELECT *
FROM (
    SELECT
        sql_id,
        executions,
        ROUND(cpu_time/1000000,2) AS cpu_seconds,
        ROUND(elapsed_time/1000000,2) AS elapsed_seconds,
        sql_text
    FROM v$sql
    WHERE cpu_time > 0
    ORDER BY cpu_time DESC
)
WHERE ROWNUM <= 10;

Esto puede ayudar a encontrar candidatos responsables de alto consumo de CPU.

Sin embargo, recuerda que los valores de V$SQL son acumulativos para los cursores presentes y deben interpretarse dentro del contexto y ventana temporal apropiados.

9. V$SQLAREA

V$SQLAREA proporciona estadísticas agregadas de SQL compartido.

SELECT
    sql_id,
    executions,
    cpu_time,
    elapsed_time,
    buffer_gets,
    disk_reads,
    sql_text
FROM v$sqlarea
ORDER BY cpu_time DESC
FETCH FIRST 10 ROWS ONLY;

Puede ser útil para localizar SQL costoso.

10. V$LOCK — Locks

Para revisar locks:

SELECT
    sid,
    type,
    id1,
    id2,
    lmode,
    request,
    block
FROM v$lock;

V$LOCK cobra mucho más sentido cuando la relacionamos con V$SESSION.

11. Identificar sesiones bloqueadoras

Una forma sencilla de empezar:

SELECT
    sid,
    serial#,
    username,
    blocking_session,
    event,
    seconds_in_wait
FROM v$session
WHERE blocking_session IS NOT NULL;

Podríamos encontrar:

SID 145
      ↓
Waiting for
      ↓
SID 320
      ↓
Blocking Session

Entonces investigamos la sesión bloqueadora antes de tomar cualquier acción.

12. V$TRANSACTION — Transacciones activas

SELECT
    s.sid,
    s.serial#,
    s.username,
    t.start_time,
    t.used_ublk,
    t.used_urec
FROM v$transaction t
JOIN v$session s
    ON t.ses_addr = s.saddr;

Puede ayudar a identificar transacciones activas y potencialmente grandes.

13. V$SGA — Memoria SGA

SELECT *
FROM v$sga;

Nos muestra componentes generales de la System Global Area.

También podemos consultar:

SELECT
    name,
    ROUND(value/1024/1024,2) AS mb
FROM v$sga;

14. V$SGAINFO — Información detallada de SGA

SELECT
    name,
    ROUND(bytes/1024/1024,2) AS mb
FROM v$sgainfo;

Podemos encontrar componentes relacionados con:

Buffer Cache
Shared Pool
Large Pool
Java Pool
Redo Buffers
SGA Target

15. V$PGASTAT — PGA

Para revisar estadísticas de PGA:

SELECT
    name,
    value,
    unit
FROM v$pgastat;

Es útil durante troubleshooting relacionado con memoria y operaciones de trabajo de procesos.

16. V$SYSSTAT — Estadísticas de la instancia

SELECT
    name,
    value
FROM v$sysstat
ORDER BY name;

Contiene numerosas estadísticas acumuladas de la instancia.

Podemos filtrar:

SELECT
    name,
    value
FROM v$sysstat
WHERE name LIKE '%physical read%';

SELECT
    name,
    value
FROM v$sysstat
WHERE name LIKE '%redo%';

17. V$SYSTEM_EVENT — Wait Events

Una de las vistas importantes para performance:

SELECT
    event,
    total_waits,
    time_waited,
    average_wait
FROM v$system_event
ORDER BY time_waited DESC;

Permite observar estadísticas acumuladas de espera a nivel de instancia.

18. V$SESSION_EVENT — Waits por sesión

Si queremos investigar una sesión específica:

SELECT
    sid,
    event,
    total_waits,
    time_waited,
    average_wait
FROM v$session_event
WHERE sid = 145
ORDER BY time_waited DESC;

Conceptualmente:

V$SYSTEM_EVENT
      ↓
Instancia completa

V$SESSION_EVENT
      ↓
Sesión específica

19. V$SESSION_WAIT

Podemos consultar información de espera:

SELECT
    sid,
    event,
    wait_class,
    state,
    seconds_in_wait
FROM v$session_wait
WHERE wait_class <> 'Idle';

En muchas investigaciones modernas, V$SESSION ya expone directamente varias columnas de wait information, por lo que también conviene revisar allí EVENT, WAIT_CLASS y STATE.

20. V$DATAFILE — Datafiles

SELECT
    file#,
    name,
    status
FROM v$datafile;

Para información administrativa más completa de tamaño/tablespace normalmente también utilizaremos:

DBA_DATA_FILES

La diferencia es importante:

V$DATAFILE
   ↓
Información dinámica/control file

DBA_DATA_FILES
   ↓
Información administrativa del diccionario

21. V$TEMPFILE — Tempfiles

SELECT
    file#,
    name,
    status
FROM v$tempfile;

Muy útil para revisar los archivos asociados a temporary tablespaces.

22. V$LOG — Online Redo Logs

SELECT
    group#,
    thread#,
    sequence#,
    bytes/1024/1024 AS size_mb,
    members,
    archived,
    status
FROM v$log;

Podemos encontrar estados como:

CURRENT
ACTIVE
INACTIVE

Esta vista es muy importante para administración de redo y Data Guard.

23. V$LOGFILE — Miembros de Redo Log Groups

SELECT
    group#,
    type,
    member,
    status
FROM v$logfile
ORDER BY group#;

La relación es:

V$LOG
   ↓
Redo Log Group

V$LOGFILE
   ↓
Physical Members

24. V$ARCHIVED_LOG — Archive Logs

SELECT
    thread#,
    sequence#,
    first_time,
    next_time,
    applied,
    deleted
FROM v$archived_log
ORDER BY sequence# DESC
FETCH FIRST 20 ROWS ONLY;

Esta vista es especialmente importante para:

RMAN
Data Guard
Archive troubleshooting
Recovery

25. V$ARCHIVE_DEST_STATUS

Para revisar destinos de archive:

SELECT
    dest_id,
    status,
    target,
    destination,
    error
FROM v$archive_dest_status
WHERE status <> 'INACTIVE';

Si Data Guard deja de transportar redo, esta puede ser una de las primeras vistas a revisar.

Presta especial atención a:

STATUS
ERROR
DESTINATION

26. V$RECOVERY_FILE_DEST — Fast Recovery Area

SELECT
    name,
    ROUND(space_limit/1024/1024/1024,2) AS limit_gb,
    ROUND(space_used/1024/1024/1024,2) AS used_gb,
    ROUND(space_reclaimable/1024/1024/1024,2) AS reclaimable_gb,
    number_of_files
FROM v$recovery_file_dest;

Esta consulta es muy útil cuando recibimos alertas relacionadas con:

FRA
Archive Logs
RMAN
ORA-19809
ORA-19815

27. V$RECOVERY_AREA_USAGE

Para conocer qué está consumiendo la FRA:

SELECT
    file_type,
    percent_space_used,
    percent_space_reclaimable,
    number_of_files
FROM v$recovery_area_usage;

Podemos encontrar:

ARCHIVED LOG
BACKUP PIECE
IMAGE COPY
FLASHBACK LOG

Esto permite responder:

¿Qué está consumiendo el espacio de la FRA?

28. V$RMAN_BACKUP_JOB_DETAILS — RMAN

Una de mis favoritas para Production Support:

SELECT
    session_key,
    input_type,
    status,
    start_time,
    end_time,
    elapsed_seconds
FROM v$rman_backup_job_details
ORDER BY start_time DESC;

Permite revisar rápidamente:

COMPLETED
FAILED
COMPLETED WITH WARNINGS

Para investigar un backup nocturno fallido, puede ser un excelente punto de partida.

29. V$SESSION_LONGOPS — Operaciones largas

SELECT
    sid,
    serial#,
    opname,
    sofar,
    totalwork,
    units,
    ROUND(sofar/NULLIF(totalwork,0)*100,2) AS pct_complete
FROM v$session_longops
WHERE totalwork > 0
AND sofar <> totalwork;

Puede mostrar progreso para determinadas operaciones largas, incluyendo algunas operaciones de RMAN y otras tareas instrumentadas por Oracle.

30. V$DATAGUARD_STATS — Data Guard

En un Physical Standby:

SELECT
    name,
    value,
    unit
FROM v$dataguard_stats;

Presta especial atención a:

transport lag
apply lag
apply finish time

Una consulta muy útil:

SELECT
    name,
    value,
    unit
FROM v$dataguard_stats
WHERE name IN ('transport lag','apply lag');

31. V$DATAGUARD_STATUS

Para eventos relacionados con Data Guard:

SELECT
    severity,
    error_code,
    message,
    timestamp
FROM v$dataguard_status
ORDER BY timestamp DESC;

Puede ayudar a correlacionar problemas de transporte y recuperación.

32. V$MANAGED_STANDBY

Tradicionalmente muy utilizada para observar procesos de un Physical Standby:

SELECT
    process,
    status,
    thread#,
    sequence#
FROM v$managed_standby;

Dependiendo de la versión, también debes conocer:

V$DATAGUARD_PROCESS

para observar procesos de Data Guard.

33. V$STANDBY_LOG

Para revisar Standby Redo Logs:

SELECT
    group#,
    thread#,
    sequence#,
    bytes/1024/1024 AS size_mb,
    status
FROM v$standby_log
ORDER BY thread#, group#;

Muy importante para arquitecturas con Data Guard.

34. V$ASM_DISKGROUP — ASM

Si trabajamos con ASM:

SELECT
    name,
    state,
    type,
    total_mb,
    free_mb,
    usable_file_mb
FROM v$asm_diskgroup;

Nos permite observar capacidad de disk groups como:

+DATA
+FRA
+RECO

Normalmente esta consulta se realiza desde el contexto/instancia ASM y con los privilegios adecuados.

35. V$PARAMETER — Parámetros

SELECT
    name,
    value,
    isdefault,
    issys_modifiable
FROM v$parameter
ORDER BY name;

Para uno específico:

SELECT
    name,
    value
FROM v$parameter
WHERE name = 'sga_target';

También podemos utilizar SQL*Plus:

SHOW PARAMETER sga_target

36. V$SPPARAMETER

Permite observar valores almacenados en el SPFILE:

SELECT
    name,
    value
FROM v$spparameter
WHERE value IS NOT NULL
ORDER BY name;

Esto nos ayuda a entender la diferencia entre:

V$PARAMETER
    ↓
Valores efectivos de la instancia

V$SPPARAMETER
    ↓
Valores almacenados en SPFILE

Las vistas V$ que deberías memorizar primero

Si estás comenzando con administración Oracle, yo empezaría por estas:

Vista	¿Para qué la utilizaría?
`V$INSTANCE`	Estado de la instancia
`V$DATABASE`	Estado, rol y modo de la DB
`V$SESSION`	Sesiones y conexiones
`V$PROCESS`	Procesos Oracle/OS
`V$SQL`	SQL y estadísticas
`V$SQLAREA`	SQL agregado
`V$LOCK`	Locks
`V$TRANSACTION`	Transacciones
`V$SGAINFO`	Memoria SGA
`V$PGASTAT`	Memoria PGA
`V$SYSSTAT`	Estadísticas de instancia
`V$SYSTEM_EVENT`	Wait events globales
`V$SESSION_EVENT`	Waits por sesión
`V$DATAFILE`	Datafiles
`V$LOG`	Redo log groups
`V$LOGFILE`	Redo members
`V$ARCHIVED_LOG`	Archive logs
`V$ARCHIVE_DEST_STATUS`	Archive/Data Guard destinations
`V$RECOVERY_FILE_DEST`	Capacidad FRA
`V$RECOVERY_AREA_USAGE`	Uso de FRA
`V$RMAN_BACKUP_JOB_DETAILS`	Backups RMAN
`V$SESSION_LONGOPS`	Operaciones largas
`V$DATAGUARD_STATS`	Data Guard lag
`V$DATAGUARD_STATUS`	Eventos Data Guard
`V$STANDBY_LOG`	Standby Redo Logs
`V$ASM_DISKGROUP`	Capacidad ASM
`V$PARAMETER`	Parámetros actuales

Una metodología para Production Support

Supongamos que recibimos una alerta:

“Oracle Database has high CPU utilization.”

En lugar de reiniciar la base de datos, podemos investigar:

HIGH CPU
   ↓
¿Instancia correcta?
   ↓
V$INSTANCE
   ↓
¿Quién está conectado?
   ↓
V$SESSION
   ↓
¿Sesiones ACTIVE?
   ↓
V$SESSION
   ↓
¿Qué SQL ejecutan?
   ↓
SQL_ID
   ↓
V$SQL
   ↓
¿Quién consume CPU?
   ↓
V$PROCESS ↔ OS PID
   ↓
¿Existen waits?
   ↓
V$SESSION / V$SESSION_EVENT
   ↓
¿Locks?
   ↓
V$LOCK / blocking_session
   ↓
¿SQL problemático?
   ↓
Plan / estadísticas / workload
   ↓
Mitigación
   ↓
Root Cause Analysis

Esta es la verdadera utilidad de las vistas V$.

No se trata de memorizar:

SELECT * FROM v$session;

Se trata de aprender a relacionar información:

Linux PID
    ↕
V$PROCESS
    ↕
V$SESSION
    ↕
SQL_ID
    ↕
V$SQL
    ↕
Wait Event
    ↕
Database Resource

Cuando entiendes estas relaciones, Oracle deja de parecer una “caja negra”. Puedes seguir el problema desde el servidor → proceso → sesión → SQL → recurso → causa raíz.

Para cerrar tu artículo, usaría esta pregunta:

Cuando una base Oracle comienza a degradarse, ¿cuál es la primera vista V$ que consultas?

Las vistas V$ de Oracle Database que todo administrador debería conocer