Número de sesiones abiertas por cada dblink
Cristina Garcia
Buenos días,
¿Qué tal estamos? ¿Qué tal va el verano? Yo hasta la segunda quincena de septiembre no me voy :'(
Para no perder la costumbre, necesito ayuda.... Estoy atascada y no encuentro la forma de sacar el número de sesiones que abre cada dblink, ¿alguien sabe como hacerlo?
Muchas gracias.
JAP
--
Has recibido este mensaje porque estás suscrito al grupo "FORO_DBA" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a foro_dba+u...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
Principal IT Consultant & CTO
SYSCONFIG Gestión de Sistemas, SLU
www.sysconfig-gs.net
www.linkedin.com/company/sysconfig-gs
Cristina Garcia
En destino
JAP
Cristina Garcia
El nombre del servicio es el mismo.
JAP
Guille Yahoo
Yo lo haria asi:
select program Aplicacion, username
from v$session
where program='ORACLE.EXE'
and username='SAPLINK'
igual tienes que saber como se llama el dblink, pero sino desde la v$session te dara mas informacion y podras afinar.
--
Cristina Garcia
Muchas gracias, si el problema es que el dblink abre las conexiones en la de destino, y no se cierran, y los de aplicacion no quieren tocar el codigo paea liberarlo, por eso quería sacar el número de conexiones que se abría por cada dblink, porque hemos tenido que aumentar el número de conexiones que se permiten y desde was, vaciar el pool. Vamos para hacer el informe y presionar a los de la aplicación.
Muchas gracias! !!
Guille Yahoo
Y porque no matais vosotros las sesiones automáticamente de ese usuario en concreto pasado x tiempo?
Lo podeis hacer desde el profile.
Crear un nuevo profile en bbdd con un determinado tiempo, y Oracle los va cerrando. Ese es el valor idle time.
Por lo general los dblink se quedan abierto aun cuando se cierren las conexiones de las aplicaciones.
Yo lo que hago es matar sesiones después de un tiempo que están inactivas…..
Y para los dblink uso un profile.
Cristina Garcia
La deja snipe y sigue contando como sesión y acaba tirando la bbdd, prefieren asumir el coste de vaciar el pool antes de que se queden sin bbdd
Guille Yahoo
Claro la deja snipe porque luego tienes que forzar tu a matar las snipe.
Te pongo lo que hago yo….
Os creáis un job que corra cada 5 minutos y haga esto…. Vais a matar solo las siped y fuera problemas
SET PAGESIZE 100
SET LINESIZE 3200
spool X:\Sesiones_automaticas_M7P\kill_sniped.sql;
SELECT 'ALTER SYSTEM KILL SESSION '||''''||SID||','||SERIAL#||''''||' IMMEDIATE'||';'
FROM V$SESSION WHERE STATUS='SNIPED';
spool off;
@X:\Sesiones_automaticas_M7P\kill_sniped.sql;
exit
Cristina Garcia
Graciasssss
JAP
insert into tabla_local as select * from tabla@dblink1;
commit;
hace la consulta, devuelve los resultados y se cierra (palabrita del niño jesús)... no se como interviene un servidor de aplicaciones, un middleware o cualquier otra cosa... la única mánera de dejar esa conexión abierta es que la query sobre la tabla remota no termine con lo cual no es un problema del db_link sino del código (y en ese caso, al estar trabajando la consulta el PROFILE en destino no la puede poner en SNIPED ya que está activa. Aunque un PROFILE en origen si podría determinar que no está haciendo nada)...
Por supuesto, si cierras la sesión en la base de datos origen, cierras la conexión a la bbdd remota... perdonadme pero no comprendo el problema... ¿Que was es ese que no cierra las sesiones? ¿La bbdd acaba cayendo por un número excesivo de conexiones o simplemente no acepta más por parámetros de bbdd o limitación de ssoo?
Cristina Garcia
Es un shared dblink.
La bbdd se acaba cayendo porque se excede el número máximo de sesiones. Los programadores tienen mal el código, pero dicen que no lo cambian.
Las conexiones se abren y no se cierran hasta con selects, con un commit se cerrarían, pero como no quieren hacerlo... y son sesiones que están inactivas. Desde was han puesto el vaciado del pool por debajo del número máximo de sesiones, para evitar que la bbdd se caiga, pero esto hace que la aplicación vaya más lenta. Por eso Guille, me ha dicho lo del profile y el job.
JAP
Cristina Garcia
Muchas gracias a vosotros por el cable :-D
JAP iDBA
José Antonio de Pablo Jiménez .
Mira jap, esta es la bbdd de pruebas donde no matamos sesiones, mira como quedan los dblinks cuando son por programas.
<image002.png>
<image003.png>
Guille Yahoo
Exactoooooo tienes razon pero el problema es la peña que no hace caso y no quiere mejorar las cosas.