Listener no Arranca (tcp.validnode_checking, tcp.excluded_nodes)

Este es un caso de incidencia real acontecida en un entorno HP-UX aunque posteriormente tambien se reporto en un AIX, entiendemos que se puede producir en cualquier otro S.O.

Por los motivos que sea se debe reiniciar un listener ya sea por opertavia automática o de forma manual.
La cosa es que no vuelve a levantar debidamente, reportando un error similar al siguiente:

LSNRCTL> START
Starting /oracle/app/oracle/product/920/bin/tnslsnr: please wait…
TNSLSNR for HPUX: Version 9.2.0.6.0 – Production
System parameter file is /oracle/app/oracle/product/920/network/admin/listener.ora
Log messages written to /oracle/app/oracle/product/920/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.177.6.32)(PORT=1521)))
Error listening on: (ADDRESS=(PROTOCOL=ipc)(PARTIAL=yes)(QUEUESIZE=1))
No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.177.6.32)(PORT=1521)))
TNS-12546: TNS:permission denied
TNS-12560: TNS:protocol adapter error
TNS-00516: Permission denied
HPUX Error: 13: Permission denied

La solución pasa por revisar el fichero sqlnet.ora dicho fichero es posible que contenga los siguientes parametros:
tcp.validnode_checking = yes
tcp.excluded_nodes = ( aaa.es, bbb.com ,...)

Si lo encontramos tenemos dos opciones:

1. Tenemos prisa, no podemos esperar; cambiamos el parametro tcp.validnode_checking =no o comentamos ambos.

2. Podemos revisarlo con cierta "tranquilidad", se deberia probar si desde el host del listener podemos resolver los nombres indicados en tcp.excluded_nodes, quitando de la lista los no accesibles.

Una vez realizadas las dos acciones y tras guardar los cambios de sqlnet.ora; podriamos iniciar el listener sin dicho error.

Ficheros de traza y dump

¿Se está llenando el filesystem (o carpeta para windows) en el que se generan los ficheros de traza y dumps de Oracle y no sabéis que hacer?

Lo primero que haremos es mantener la calma y no lanzarnos a borrar ficheros como posesos ya que podríamos perder información importante que nos puede ayudar a solucionar un problema mayor que el propio hecho de que se nos llene un filesystem. En función del espacio que nos quede en el disco procederemos a comprimir los ficheros o a moverlos a otra ubicación por si nos fuera necesario consultarlos más adelante.

Al inicio de estos ficheros de traza ( .trc ) tenemos una serie de información que nos será muy útil para localizar el proceso que ha generado dicho fichero. Uno de los "campos" que más información nos va a dar es el "campo" MODULE_NAME. En nuestro caso hemos podido ver que la aplicación de monitorización del sistema es la que estaba provocando la generación de estos ficheros de traza.

En la versión 11g tenemos la aplicación ADR (Automatic Diagnostic Repository) que nos permite definir la gestión que queremos realizar de estos ficheros de traza y por lo tanto definir el número de días que queremos guardar. Está claro que cuando se produce una generación masiva de ficheros de traza con un tamaño importante deberemos aplicar otras medidas que ahora explicaremos.

La limpieza automática de los ficheros de traza y ficheros dump la realiza el proceso MMON y se basa en los valores que tenemos definidos en ADR. Para ello tenemos 2 atributos que podemos definir:

• LONGP_POLICY (long term): por defecto este atributo tiene un valor de 365 días y se encarga de gestionar incidentes y avisos del Health
• SHORTP_POLICY (short term): por defecto este segundo atributo tiene un valor de 30 días y se encarga de gestionar los ficheros de traza y dump

Para ver estos valores y/o modificarlos utilizaremos adrci. A continuación os mostramos algunos comandos útilies:

1. Ver los valores actuales: show control

ADRCI: Release 11.1.0.7.0 - Production on Fri Mar 7 01:17:20 2014

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

ADR base = "/u02/shared_admin1/PANDORAP"
adrci> show control

ADR Home = /u02/shared_admin1/PANDORAP/diag/rdbms/pandorap/PANDORAP:
*************************************************************************
ADRID                SHORTP_POLICY        LONGP_POLICY         LAST_MOD_TIME                            LAST_AUTOPRG_TIME                        LAST_MANUPRG_TIME                        ADRDIR_VERSION       ADRSCHM_VERSION      ADRSCHMV_SUMMARY     ADRALERT_VERSION     CREATE_TIME                              
-------------------- -------------------- -------------------- ---------------------------------------- ---------------------------------------- ---------------------------------------- -------------------- -------------------- -------------------- -------------------- ---------------------------------------- 
188366471            2                    3                    2014-03-06 22:15:42.214130 +01:00        2014-02-27 01:28:51.843695 +01:00        2014-03-06 20:58:54.281200 +01:00        1                    2                    65                   1                    2010-02-01 15:48:44.829787 +01:00       
1 rows fetched

adrci>

2. Modificar los valores actuales: set control 

adrci> set control (longp_policy = 60) el valor informado es el número de días que queremos mantener

adrci> set control (shortp_policy = 15) el valor informado es el número de días que queremos mantener

3. En el caso que queremos realizar un borrado de ficheros de traza utilizaremos el comando purge. En el siguiente ejemplo borraremos los ficheros más antiguos de 7 días

adrci> purge -age 10080 -type TRACE (en este caso el valor informado son minutos)

Este post ha sido confeccionado a partir de la información extraida del siguiente enlace: http://gavinsoorma.com/2010/09/purging-trace-and-dump-files-with-11g-adrci/

--
reconoce tus errores, antes de que otros los exageren - Andrew Mason, CEO of Groupon