miércoles, 3 de febrero de 2021

Cómo se puede identificar la sesión que está utilizando un enlace entre dos bases de datos Oracle

Recibí un mensaje sobre una sesión reanudable en una de nuestras bases de datos que voy a llamar REMOTA. Luego vi el error siguiente en su archivo de alertas:

Wed Feb 03 13:49:24 2021

ORA-1652: unable to extend temp segment by 128 in tablespace                 EDA_TEMP

statement in resumable session 'User EDAPQELNK(720), Session 4321, Instance 1' was suspended due to

    ORA-01652: unable to extend temp segment by 128 in tablespace EDA_TEMP

Confirmé que el usuario que estaba esperando era responsable del uso del espacio.

SQL> l

  1  select a.username, b.sid, b.serial#, a.blocks

  2  from v$sort_usage a, v$session b

  3  where tablespace = 'EDA_TEMP'

  4  and a.session_addr = b.saddr

  5* and a.username = b.username

SQL> /

USERNAME               SID    SERIAL#     BLOCKS

--------------- ---------- ---------- ----------

EDAPQELNK             4321       9823   23592192

SQL>

Ya sabía que EDAPQELNK era el usuario empleado por un enlace que venía de otra base de datos, que voy a llamar LOCAL. Ejecuté el SQL bajo estas líneas en REMOTA. Fue escrito por Mariami Kupatadze, una maestra certificada de Oracle que viene de Georgia. Luego eliminé 65 líneas, dejando una donde la columna LSESSION coincidía con el SID y el SERIAL# de la sesión de EDAQPQELNK:

SQL> l

  1  Select /*+ ORDERED */

  2  substr(s.ksusemnm,1,10)||'-'|| substr(s.ksusepid,1,10) "ORIGIN",

  3  substr(g.K2GTITID_ORA,1,35) "GTXID",

  4  substr(s.indx,1,4)||'.'|| substr(s.ksuseser,1,5) "LSESSION" ,

  5  substr(decode(bitand(ksuseidl,11),1,'ACTIVE',0,

  6  decode(bitand(ksuseflg,4096),0,'INACTIVE','CACHED'),

  7  2,'SNIPED',3,'SNIPED', 'KILLED'),1,1) "S",

  8  substr(event,1,10) "WAITING"

  9  from x$k2gte g, x$ktcxb t, x$ksuse s, v$session_wait w

10  where g.K2GTDXCB =t.ktcxbxba

11  and g.K2GTDSES=t.ktcxbses

12  and s.addr=g.K2GTDSES

13* and w.sid=s.indx

SQL> /

ORIGIN                GTXID                               LSESSION   S WAITING

--------------------- ----------------------------------- ---------- - ----------

Etc

Etc

Etc

sge-mktred-19212      ECOPWPR1.9bcaeeda.9.28.10142748     4321.9823  A statement

66 rows selected.

SQL>

Ejecuté el mismo SQL en la base de datos LOCAL pero esta vez elegí la línea con el mismo valor en la columna GTXID.

SQL> l

  1  Select /*+ ORDERED */

  2  substr(s.ksusemnm,1,10)||'-'|| substr(s.ksusepid,1,10) "ORIGIN",

  3  substr(g.K2GTITID_ORA,1,35) "GTXID",

  4  substr(s.indx,1,4)||'.'|| substr(s.ksuseser,1,5) "LSESSION" ,

  5  substr(decode(bitand(ksuseidl,11),1,'ACTIVE',0,

  6  decode(bitand(ksuseflg,4096),0,'INACTIVE','CACHED'),

  7  2,'SNIPED',3,'SNIPED', 'KILLED'),1,1) "S",

  8  substr(event,1,10) "WAITING"

  9  from x$k2gte g, x$ktcxb t, x$ksuse s, v$session_wait w

10  where g.K2GTDXCB =t.ktcxbxba

11  and g.K2GTDSES=t.ktcxbses

12  and s.addr=g.K2GTDSES

13* and w.sid=s.indx

SQL> /

ORIGIN                GTXID                               LSESSION   S WAITING

--------------------- ----------------------------------- ---------- - ----------

Etc

Etc

Etc

MAIN\GB-DG-18020:1831 ECOPWPR1.9bcaeeda.9.28.10142748     100.39071  A SQL*Net me

Etc

Etc

Etc

18 rows selected.

SQL>

Usé el valor en la columna LSESSION para encontrar el nombre del usuario. FRED no es su verdadero nombre, lo cambié:

SQL> select osuser from v$session

  2  where sid = 100

  3  and serial# = 39071

  4  /

OSUSER

------------------------------

FRED

SQL>

Entonces le expliqué por qué su sesión no hacía nada.