Recuerde que una vez que el número de sesión de Oracle causada por excesivo número de procesos distintos en última instancia conducir a problemas de limitar el cliente no puede conectarse

RAC súbitamente alerta, se informará al cliente al intentar conectar: ​​ORA-12520: TNS: escucha no pudo encontrar manejador disponibles para el tipo de error del servidor solicitado.

Ahora terminar el proceso de solución para un proceso rápido en el encuentro posterior este problema.

1. Inicie sesión en el servidor, utilizando sqlplus / as sysdba puede encontrar el acceso a la base de datos.

2. Comprobar el registro de alertas, el registro ha encontrado mensaje de error: ORA-00020: número máximo de procesos (2000) excedido, determinando de este modo el número de proceso es super.

ruta de registro de alerta se puede encontrar sql:

seleccionar * de gv $ diag_info donde nombre como 'Alerta%%'

3. Determinar el problema del usuario de Oracle,

seleccione t1.inst_id, t1.username, count (*) de GV $ t1 sesión de
 unirse gv $ t2 proceso de t2.addr = t1.paddr y t2.inst_id = t1.inst_id
 grupo por t1.inst_id, t1.username orden 3 desc

Se puede encontrar es demasiado número de conexiones de usuario xxxx causados.

4. Impedir que los usuarios volver a establecer una nueva conexión.

Dependiendo del grado de control del cliente para elegir un enfoque flexible. Si usted tiene el control absoluto sobre el programa cliente, el problema del programa puede ser detenido, en circunstancias normales, el problema será resuelto.

Escogí el camino de la cerradura de usuario, haga lo siguiente SQL:

alter usuario xxxx bloqueo de cuenta;

5. En este punto vemos la sesión gv $, encontraron que la conexión se ha establecido todavía.

seleccionar * de $ gv sesión donde nombre de usuario = 'XXXX'

6. limpiar estas conexiones.

En este momento, no utilice sesión de matanza sistema alter, porque después de mis pruebas de seguimiento encontró que si el problema no se cierra el programa cliente, una red de conexión se establece el cliente y el servidor Oracle ha permanecido en este momento, incluso si matamos sesión, el proceso de todavía no se dará a conocer, que dará lugar a gv $ vista de sesión y gv $ visión de proceso de la relación perdida, lo que llevó a la hora de encontrar a cabo la sesión de usuario correspondiente a esos procesos.

Directamente sistema interrumpir procesos en la sesión correspondiente en el nivel del sistema operativo.

XXXX se puede encontrar utilizando la siguiente cuenta de SQL de la sesión correspondiente ID de proceso del sistema:

seleccione t1.inst_id, t1.sid, t1.serial #, t1.username, t2.spid系统进程Identificación de GV $ t1 sesión de
 unirse gv $ t2 proceso de t2.addr = t1.paddr y t2.inst_id = t1.inst_id
 donde t1.username = 'XXXX'

7. acabado ocupado por encima de proceso de la operación a descender. Entonces tenemos en cuenta el programa para comunicarse con el cliente detiene el problema y luego a bloquear la cuenta fueron restaurados.

Durante todo el camino para matar a una sesión dada comandos del sistema operativo correspondiente, este método es muy violento, no use tanto como sea posible.

ps-ef | grep LOCAL = NO | grep -v grep | awk '{print $ 2}' | xargs kill -9

 

 

 

Después de que el problema se ha resuelto, yo uso pitón que hacer una pequeña prueba en la biblioteca reproduce el problema, de la siguiente manera:

# ! / Bin / python 
# - * - coding: UTF-8 - * - 
importación cx_Oracle como co
conn = co.SessionPool ( ' XXXX ' , ' XXXXXXXXX ' , ' xxxx ' , min = 1, max = 5.000 )

un = []
 para i en rango (5000 ):
     de impresión (i)
     trato :
        ccc = conn.acquire ()
        a.append (ccc)
    excepto Excepción como e:
         print (e)
        time.sleep ( 20)

 

Anteriormente.