¿Qué es V$SESSION?
La vista V$SESSION es la base de toda la información relacionada con el estado actual del sistema:
- ¿Cuántas sesiones hay actualmente corriendo en la base de datos?
- ¿Qué consulta se está ejecutando?
- ¿Cuánto tardan en ejecutarse estas consultas?
V$SESSION es el primer lugar cuando DBA comienza a buscar información relacionada con el rendimiento e información de la ejecución de las consultas, un DBA puede llegar a consultar un centenar de veces al día esta vista, así que arrojemos un poco de luz sobre esta vista.
A efectos prácticos este artículo está basado en una base de datos Oracle 11g, usaremos:
- V$session: para una estancia sencilla.
- GV$session: para una instalación en cluster (RAC).
Listado de las sesiones ejecutándose
Lo primero que un DBA busca en nuestra vista favorita es la lista de sesiones de usuario de bases de datos. Hay dos tipos de sesiones de base de datos, principalmente background y sesiones de usuario. La sesión background se utiliza para la funcionalidad básica de la base de datos como dbwr, arch, smon, pmon etc. La sesión del usuario es la sesión que realiza las operaciones del usuario.
Cada vez que se conecta a los datos se crea una sesión en la base de datos para realizar sus operaciones. Un DBA puede ver fácilmente esto consultando la vista de sistema V$SESSION.
Actualmente sólo hay una sesión de usuario en ejecución.
SQL> select count(*),type from v$session group by type;
COUNT(*) TYPE
---------- ----------
1 USER
49 BACKGROUND
En el caso del entorno RAC, DBA debe utilizar GV$SESSION en lugar de V$SESSION.
SQL> select count(*),type,INST_ID from gv$session group by type,inst_id;
COUNT(*) TYPE INST_ID
---------- ---------- ----------
21 USER 1
48 BACKGROUND 1
49 BACKGROUND 2
17 USER 2
Supongamos que tenemos dos nodos RAC, la instancia 1 tiene 21 usuarios y 48 sesiones en background, mientras que la instancia 2 tiene 17 usuarios y 49 sesiones en background. Esta información es útil cuando se produce el siguiente error "ORA-00020: maximum number of processes (%s) exceeded" error. Puede utilizar la consulta siguiente para identificar qué usuario está creando un número alto de sesiones.
SQL> select SID,USERNAME,COMMAND,PROCESS,TERMINAL,PROGRAM from gv$session where type='USER';
SID USERNAME COMMAND PROCESS TERMINAL PROGRAM
---------- ------------------------------ ---------- ------------------------ ------------------------------ --------
16 SYS 47 17978 oraagent.bin@dbarm2 (TNS V1-V3)
19 DBSNMP 0 1234 unknown JDBC Thin Client
25 SYSMAN 0 1234 unknown OMS
26 DBSNMP 0 1234 unknown JDBC Thin Client
- SID es la ID de la sesión,
USERNAME es el nombre del usuario de la base de datos.
- Process es el número de proceso.
- Terminal es el nombre del sistema que esta ejecutando la consulta.
- Program muestra el nombre del programa que esta usando la consulta.
Terminal y Program son los campos más importantes para encontrar las sesiones culpables de los errores ORA-00020.
Es una lista del uso de la vista V$SESSION, he enumerado algunos de ellos aquí. Por favor, comparte en los comentarios si sabéis más.
Encontrar sesiones bloqueantes
Una queja común al administrador de la base de datos por el usuario es "mi conexión de la base de datos es muy lenta". En este caso DBA debe comprobar dos cosas O toda la base de datos se está ejecutando lento o Sólo una sesión de usuario es lenta. Para comprobar el estado completo de la base de datos, DBA puede utilizar Top Command, Watcher de OS e Informe AWR.
Si está seguro de que sólo una sesión única se está ejecutando lento entonces V$session o gv$session es el lugar perfecto para empezar. He visto muchos casos en los que una sesión está bloqueando otra sesión debido a transacciones no confirmadas.
SQL> select sid, username,command,status,program,sql_id,BLOCKING_INSTANCE,BLOCKING_SESSION,WAIT_CLASS from gv$session where BLOCKING_SESSION is not null;
SID USERNAME COMMAND STATUS PROGRAM SQL_ID BLOCKING_INSTANCE BLOCKING_SESSION WAIT_CLASS
---------- ---------- ---------- -------- ------------------------------------------------ ------------- ----------------- ---------------- ---------------
47 SCOTT 6 ACTIVE sqlplus@database.example.com (TNS V1-V3) 2rbwgj3zdsnus 1 34 Application
En el caso anterior, el usuario scott no recibía ninguna respuesta de su consulta. Comprobé utilizando la consulta anterior en la que "BLOCKING_SESSION" muestra el detalle de la sesión que está bloqueando la sesión de usuario SCOTT. Los campos:
-
SID,
- USERNAME,
- COMMAND,
- STATUS,
- PROGRAM y
- SQL_ID
son detalles del usuario SCOTT, BLOCKING_INSTANCE significa en qué instancia se está ejecutando la sesión de bloqueo, BLOCKING_SESSION es el ID de sesión de la sesión de bloqueo.
Ahora el siguiente plan de acción para DBA es comprobar lo que está causando que la sesión 34 bloquee la sesión de scott. El DBA puede utilizar la consulta siguiente para averiguar los detalles de la sesión 34.
SQL> select sid,username,command,status,program,sql_id,BLOCKING_INSTANCE,BLOCKING_SESSION,WAIT_CLASS from gv$session where sid=34;
SID USERNAME COMMAND STATUS PROGRAM SQL_ID BLOCKING_INSTANCE BLOCKING_SESSION WAIT_CLASS
--- ---------- ---------- -------- ------------------------------------------------ ------------- ------------
34 SCOTT 3 INACTIVE sqlplus@database.example.com (TNS V1-V3) 17d40vwcct4g6 Idle
Sin embargo, podría haber muchas razones para este tipo de problema. Uno de ellos lo he discutido aquí.
