Error TNS-12535 when connecting to Oracle database via dispatchers (shared servers).

En la traza del dispatcher se ve el siguiente error:

NS Primary Error: TNS-12535: TNS:operation timed out
 NS Secondary Error: TNS-12606: TNS: Application timeout occurred
kmduicxd: ffffffff7c070560, kmduiflg: 1, circuit: 45c69fdf0
 (circuit) dispatcher process id = (4653a1078, 1), holder = 45e87fcb8
 parent holder = (45e87fcb8)
 user session id = (966, 51)
 serial # = 1
 connection context = ffffffff7c070560
 user session = (4656a8480), flag = (100c0), queue = (5)
 buffers - status = (0, 4)
Client Address = (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=))


Esta mal definido el parámetro  SHARED_SERVER  tiene un valor muy bajo y se tiene aumentar, No se puede hacer una conexión vía shared servers porque no hay disponibles. El error 12535 significa que la conexión da timeout en la cola del dispatcher.

Anuncios

Túnel reverso

Túnel reverso para utilizando una maquina puente redirigir el listener a nuestro puerto local. Imaginemos que tenemos una base de datos en un ared y un cliente en otra y una maquina intermedia con acceso a las dos redes. Para conectarse entre ellas, lo que haremos es abrir un túnel en la maquina con acceso a las dos redes redirigiendo el puerto del listener a un puerto en el cliente:

En la maquina intermedia lanzaremos el siguiente comando:

ssh -f -N -l tutu -R 4494:10.44.34.176:1521 root@159.33.77.17
ssh -f -N -l usuariomaquinaintermedia -R <puertocliente>:<ipbasedatos>:<puertolistener> root@<ipcliente>

 

El tnsnames del cliente los configuraremos de la siguiente manera:

CDB63=
  (DESCRIPTION=
    (ADDRESS=
      (PROTOCOL=TCP)
      (HOST=127.0.0.1)
      (PORT=4494)
    )
    (CONNECT_DATA=
      (SERVER = dedicated)
      (SERVICE_NAME=mibasededatos)
    )
  )

ORA-12157: TNS:internal network communication error

El otro día nos encontramos con problema curioso, desde una máquina solaris comenzaron a fallar todas las conexiones a la base de datos, aparecía ORA-12157: TNS:internal network communication error, después de comprobar que el tnsnames era correcto empezamos a buscar el problema. Lo curioso es que el tnsping funcionaba correctamente

Después de poner trazas en el cliente vimos que se intentaba conectar  a la misma máquina y en ese momento daba error:

2012-04-17 09:59:33.914261 : nttbnd2addr:using 127.0.0.1
2012-04-17 09:59:33.914377 : nttbnd2addr:using host IP address: 127.0.0.1
2012-04-17 09:59:34.361921 : ntt2err:soc 11 error - operation=1, ntresnt[0]=515,
 ntresnt[1]=126, ntresnt[2]=0
2012-04-17 09:59:34.362260 : niotns:niotns failed to create NS ctx, error code 1
2157

Encontramos una nota en metalink (ORA-12157 when using 10g Oracle client while 9i client on same machine connects [ID 1174803.1]) que explica que en a partir del Oracle 10  es necesario hacer un loopback local antes de cualquier comunicación externa y aconsejaba comprobar que la interfaz de loopback estuviera levantada, en nuestro caso parecía perfecta:

ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000

Pero hacienda un traceroute al local host vimos que exstia algún problema:

traceroute 127.0.0.1
 traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
 1  *
2  *
3 *

Comprobando las conexiones existentes vimos que había un numero demasiado elevado de conexiones en uso. Habíamos tenido unos problemas con las conexiones y estas no se estaban liberando correctamente en la máquina, después de reiniciar el servidor,  todo volvió a la normalidad.

 

 

FAILOVER

Es el mecanismo de conectarse a otro recurso cuando la conexión al primer recurso se termina por cualquier circunstancia, los fallos se pueden categorizar en dos grupos:
            Los que se producen en el momento de la conexión inicial

Los errores enmarcados dentro de la primera categoría son fáciles de controlar. Si se intenta conectar a una instancia y esta conexión falla, intenta una conexión posterior a la instancia de respaldo Mientras que tengas instancias de backup configuradas, continúan los intentos de conexiona hasta que tengan éxito. Este proceso recibe el nombre técnico de Connect Time Failover

            Los que se producen una vez que la conexión ha sido establecida con éxito.

En estos casos la aplicación tiene que manejar la reconexión a la instancia de backup y el restablecimiento de la sesión y la continuación de los trabajos comenzados. El nombre técnico de este tipo es failover es “transparent application failover” o TAF.

 Una vez que hemos descrito ambos, en este post nos vamos a centrar en el primero Connection Failover, post posteriores describiremos el TAF:

Conection Failover

Es un mecanismo propio de RAC, pero se puede utilizar en ambientes no RAC cuando se tiene una base de datos en espera configurada. Es simple de configurar, esta configuración se hace a través de los cliente con:

a) Varias direcciones de listener dentro de una descripción (address_list)

b) Múltiples descripciones dentro de una lista de descripciones (description list)

La diferencia es que mientras la primera utiliza el mismo connect data para todas la lista de listeners, la segunda puede utilizar diferentes connect data para cada listener configurado

Ejemplo de  varias direcciones de listener dentro de una descripción:

OCR=           
 (DESCRIPTION=                                  
  (ADDRESS_LIST=                                  
   (ADDRESS= (PROTOCOL=TCP) (HOST=NODE1) (PORT=1521))                                  
   (ADDRESS= (PROTOCOL=TCP) (HOST=NODE2) (PORT=1521))                                  
   (FAILOVER= TRUE))                                  
   (CONNECT_DATA=                                  
    (SERVICE_NAME= OCR)                                                         
   )                                              
  ) 

Por defecto failover esta activado pero se pude desactivar cuando se especifican multiples direcciones. Se puede desahabilitar la opción (FAILOVER=false). Cunado el failover esta deshabilitado, Oracle Net intetara conectarse utilizando la primera direccion y si el intent falla no lo volvera a intentar y generara un error

  Ejemplo de Múltiples descripciones dentro de una lista de descripciones:

 OCR.GHOSH=
   (DESCRIPTION_LIST=
      (FAILOVER=true)
      (LOAD_BALANCE=false)
      (DESCRIPTION=
          (ADDRESS= (PROTOCOL=TCP) (HOST=NODO1) (PORT=1521))
          (CONNECT_DATA=
             (SERVICE_NAME=ocr1))
       )
      (DESCRIPTION=
          (ADDRESS= (PROTOCOL=TCP) (HOST=NODO2) (PORT=1521))
          (CONNECT_DATA=
            (SERVICE_NAME= ocr2))
           )

En el ejemplo anterior está puesto (FAILOVER=true) y (LOAD_BALANCE=false). No es necesario poner (FAILOVER=true), ya que este el comportamiento por defecto, sin embargo, (LOAD_BALANCE=false) no es el comportamiento por defecto, se ha puesto a false para evitar el balanceo de cliente. Cuando el balanceo en el cliente está activado, Oracle Net elige de manera aleatoria la lista de descripciones para hacer la conexión.

Tracear el cliente de oracle

Hoy vamos a explicar como tracear un cliente de oracle que esté utilizando para sus conexiones SQL*NET. Lo primero que hay que hacer es modificar el archivo sqlnet.ora, que se encuentra en el cliente en el $ORACLE_HOME/network/admin, si no se encuentra crearlo.

Hay tres parámetros que determinan el traceado:

TRACE_DIRECTORY_CLIENT = $ORACLE_HOME/network/trace
TRACE_FILE_CLIENT = cli.trc
TRACE_LEVEL_CLIENT = user

Los dos primeros tienen valor por defecto, el de TRACE_DIRECTORY_CLIENT es $ORACLE_HOME/network/trace, El de TRACE_FILE_CLIENT es cli_pid.trc, donde el PID es el id de la sesión. Dado que el TRACE_DIRECTORY_CLIENT y el TRACE_FILE_CLIENT tienen valores por defecto es posible activar las trazas solo con el TRACE_LEVEL_CLIENT. Los valores disponibles para el TARCE_LEVEL_CLIENT son:

off = (equivalente a 0) Sin trazas
user = (equivalente a 4) trazas para identificar errores de usuario
admin = (equivalente a  6) tarzas para identificar problemas específicos de la instalación
support = (equivalente q 16) trazas para enviar al soporte de Oracle

Para comprobar que se está utilizando un sqlnet.ora y tnsnames en concreto y para comprobar la conexión al serbio de Oracle tenemos la utilidad tnsping, el resultado sería algo así:

C:\Documents and Settings\user>tnsping TEST
TNS Ping Utility for 32-bit Windows: Version 10.2.0.1.0 - Production on 21-JUN-2
010 09:36:49
 
Copyright (c) 1997, 2005, Oracle.  All rights reserved.
 
Archivos de parßmetros utilizados:
D:\app\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora
Adaptador TNSNAMES utilizado para resolver el alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = 10.10.10.110) (PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = TEST)))
Realizado correctamente (210 mseg)