Rotar logs del listener

Nivel del post no aplicainicialintermedioavanzado
SGBD oraclemysqlmariadbMySQL/MariaDBpostgresqlno aplica
Tiempo de lectura aproximado 8min

Cuando una base de datos como Oracle corre en una máquina que además de albergarla, también almacena ingente información y configuraciones de otras aplicaciones, es ideal que hagamos una correcta gestión del espacio para no encontrarnos con alguna sorpresa desagradable en nuestros filesystems o unidades de disco.

De entre las tareas que podemos realizar para esta gestión del espacio, se encuentra el rotado de logs. Esta rotación puede ir desde el sistema operativo (sobre todo, si trabajamos a nivel UNIX/Linux) hasta la base de datos en sí. Hoy vamos a ver como rotar logs del listener en Oracle.

Qué es el log del listener de Oracle

Este fichero log contiene mucha información útil de los equipos que se conectan a nuestra base de datos, como: el programa que se usó para la conexión (por ejemplo, sqlplus), la dirección IP de dicha conexión, el usuario del sistema operativo que se usó en el cliente, etc. Pero además de esta información, también alberga todos los datos cuando una conexión es rechazada (por errores TNS, por ejemplo).

Un ejemplo del contenido de este fichero puede ser el siguiente:

[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ tail -f200 listener.log
24-MAR-2022 09:51:15 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=BBDDPRIMARIA)(CID=(PROGRAM=sqlplus)(HOST=aplicaciones2)(USER=kichi))(INSTANCE_NAME=instancia1)) * (ADDRESS=(PROTOCOL=tcp)(HOST=123.45.67.89)(PORT=41579)) * establish * BBDDPRIMARIA * 0
24-MAR-2022 09:51:15 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=BBDDPRIMARIA)(CID=(PROGRAM=sqlplus)(HOST=aplicaciones2)(USER=kichi))(INSTANCE_NAME=instancia1)) * (ADDRESS=(PROTOCOL=tcp)(HOST=123.45.67.89)(PORT=41581)) * establish * BBDDPRIMARIA * 0
24-MAR-2022 09:51:17 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=BBDDPRIMARIA)(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(BACKUP=BBDDSECUNDARIA))(CID=(PROGRAM=oracle)(HOST=hostfuera01)(USER=webcc-daemons))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.10.05)(PORT=60149)) * establish * BBDDPRIMARIA * 0
24-MAR-2022 09:51:19 * service_update * instancia1 * 0
Thu Mar 24 09:51:33 2022
24-MAR-2022 09:51:33 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=bbdd1)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=LISTENER)(VERSION=186647552)) * status * 0
24-MAR-2022 09:51:37 * service_update * instancia1 * 0
24-MAR-2022 09:51:42 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=BBDDPRIMARIA)(CID=(PROGRAM=etpMain)(HOST=aplicaciones2)(USER=kichi))(INSTANCE_NAME=instancia1)) * (ADDRESS=(PROTOCOL=tcp)(HOST=180.170.160.2)(PORT=48292)) * establish * BBDDPRIMARIA * 0
24-MAR-2022 09:51:42 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=BBDDPRIMARIA)(CID=(PROGRAM=etpMain)(HOST=aplicaciones2)(USER=kichi))(INSTANCE_NAME=instancia1)) * (ADDRESS=(PROTOCOL=tcp)(HOST=180.170.160.2)(PORT=48294)) * establish * BBDDPRIMARIA * 0
24-MAR-2022 09:51:42 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=BBDDPRIMARIA)(CID=(PROGRAM=etpMain)(HOST=aplicaciones2)(USER=kichi))(INSTANCE_NAME=instancia1)) * (ADDRESS=(PROTOCOL=tcp)(HOST=180.170.160.2)(PORT=48296)) * establish * BBDDPRIMARIA * 0
24-MAR-2022 09:51:42 * (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=BBDDPRIMARIA)(CID=(PROGRAM=sqlplus)(HOST=aplicaciones2)(USER=kichi))(INSTANCE_NAME=instancia1)) * (ADDRESS=(PROTOCOL=tcp)(HOST=180.170.160.2)(PORT=48298)) * establish * BBDDPRIMARIA * 0
Thu Mar 24 09:51:43 2022

Como vemos, esta información nos puede resultar muy útil a la hora de identificar problemas de conexión, como un cliente que está realizando conexiones constantes llenando el buffer o el error por el que un usuario no llega a la base de datos. Entonces, ¿por qué no usar el log del listener como un fichero más de auditoría de nuestra base de datos? ¡Claro que vamos a usarlo para monitorizar y auditarla! Solo debemos vigilar su crecimiento (si el servidor recibe muchas conexiones, el fichero crece de manera muy rápida).

Descripción del escenario

El siguiente escenario se desarrolla bajo una instalación de Oracle 11.2.0.4 en un equipo con AIX (UNIX). Los datos sensibles (como direcciones IP, nombres de instancias, etc) han sido falseados.

Bien, pongámonos en situación. Nos llega una alarma a nuestro sistema de monitorización (en mi caso, Nagios). Tenemos un equipo con una alerta de espacio, donde nos indica que el filesystem que alberga la base de datos está al 80%. Nos toca revisar directorios para ver donde podemos liberar. Lanzamos el comando mágico:

[email protected]:/oracle/app$ du -sg *
40.57   grid
0.02    oraInventory
19.65   oracle

Vale, vemos que tanto los directorios del grid como el de la base de datos pueden tener chasca que borrar. Vamos a centrarnos en la base de datos de momento.

[email protected]:/oracle/app$ cd oracle
[email protected]:/oracle/app/oracle$ du -sg *
0.00    Clusterware
0.00    admin
0.00    bds1para
0.01    cfgtoollogs
0.00    checkpoints
9.12    diag
0.00    oradiag_oracle
0.00    oradiag_root
10.05   product
0.47    tfa

Bien, ya tenemos una pista por donde andar, la carpeta diag. Entremos y veamos que hay.

[email protected]:/oracle/app/oracle$ cd diag
[email protected]:/oracle/app/oracle/diag$ du -sg *
0.06    asm
0.01    clients
0.00    crs
0.00    diagtool
0.00    lsnrctl
0.00    netcman
0.00    ofm
0.74    rdbms
8.31    tnslsnr

Ajá, nuestra candidata es la carpeta tnslsnr. Vamos a seguir bajando subdirectorios y obteniendo el tamaño de carpetas/ficheros para rascar espacio.

[email protected]:/oracle/app/oracle/diag$ cd tnslsnr
[email protected]:/oracle/app/oracle/diag/tnslsnr$ du -sg *
8.31    bbdd1
[email protected]:/oracle/app/oracle/diag/tnslsnr$ cd bbdd1
[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1$ du -sg *
4.91    listener
3.40    listener_dg

Bien. Llegados a este punto vemos que las carpetas que nos aparecen corresponden al listener de la base de datos y al del dataguard. Miremos la primera.

[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1$ cd listener
[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener$ du -sg *
0.00    alert
0.00    cdump
0.00    incident
0.00    incpkg
0.00    lck
0.00    metadata
0.00    metadata_dgif
0.00    metadata_pv
0.00    stage
0.00    sweep
4.90    trace
[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener$ cd trace
[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ du -sg *
4.90    listener.log

¡¡PREMIO!! Aquí tenemos el gordo de la lotería. El fichero .log del listener pesa casi 5Gb. Toca rotar el fichero.

Vale, rotemos el log

Ahora que conocemos la teoría y el escenario donde vamos a trabajar, debemos remangarnos y ponernos mano a la obra.

Hasta la versión 18, Oracle no dispone de una herramienta interna que haga esta rotación por nosotros, por lo que como DBA debes realizar esta tarea usando tus manitas. Disponemos de tres métodos para realizarla, pero solo uno es el correcto o, mejor dicho, el adecuado.

Parar la base de datos

Este método es el más drástico y, obviamente, no es el recomendado. Hablamos de parar toda la base de datos para hacer una simple rotación de logs.

Este escenario se podría contemplar si estamos hablando de un entorno que no está en producción (véase Preproducción/QA, Pruebas/Test o Desarrollo/Development) y donde nuestra base de datos solo debe estar levantada en un determinado horario (quizás, de 08:00am hasta las 20:00pm) ya que fuera de este nadie va a acceder a ella.

Pero en producción, esta opción queda totalmente descartada.

Parar el listener

Otro método drástico, aunque un poco menos que el anterior, es la parada del servicio del listener.

Debemos tener en cuenta que esta opción nos mantiene la base de datos levantada, pero no permitirá conexiones desde fuera. Es decir, cualquier usuario conectado a la máquina que actúa como servidor de la base de datos podrá acceder, pero no así aplicaciones y/o usuarios externos a la máquina. Y esto en un entorno de producción, obviamente, queda también descartado.

Rotación online

Oh, si. Este es nuestro método querido y amado. Consiste en hacer un rotado en caliente, sin que afecte a usuarios y/o aplicaciones que trabajen contra nuestra base de datos.

Suena bien, ¿verdad? Pues así vamos a explicarlo a continuación.

Como rotar logs del listener de Oracle online

Vale, si recordamos el escenario planteado al principio del post, habíamos buceado entre carpetas y ficheros hasta encontrar el log del listener, cuyo peso era de casi 5Gb. Pues vamos a solucionarlo. Te recomiendo tener abiertas dos sesiones de ssh (o dos ventanas, según el sistema operativo donde te encuentres y su interfaz gráfica): una para usar la herramienta de Oracle y otra para manejar el fichero viejo con el SO.

*Recuerda tener cargado el profile de base de datos correcto antes de realizar esta operación*

Haciendo uso de la herramienta lsnrctl vamos a establecer nuestro listener y a poner el estado del log a off.

[email protected]$ lsnrctl
LSNRCTL> set current listener listener
El listener actual es listener
LSNRCTL> set log_status off
Conectándose a (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
listener parámetro "log_status" definido en OFF
El comando ha terminado correctamente

Bien, ahora debemos acudir a la sesión ssh (o ventana de la consola) y manejar el fichero. Las opciones son varias: podemos renombrarlo con la fecha actual (para tener referencia de hasta que día llega), ponerle una coletilla solo para eliminarlo al reactivar el log, comprimirlo y moverlo a otro FS… Eso ya a gusto del consumidor (o de las directivas de retención de ficheros que tengas).

En mi caso, lo renombro con una coletilla para eliminarlo en cuanto se cree el nuevo log.

[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ mv listener.log listener.log_old
[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ ls -l
total 10284200
-rw-r-----    1 oracle   oinstall 5257840385 Mar 24 10:09 listener.log_old

Volvemos a la primera sesión (donde estamos con Oracle) y reactivamos el log.

LSNRCTL> set log_status on
Conectándose a (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
listener parámetro "log_status" definido en ON
El comando ha terminado correctamente

Si listamos una vez más el contenido del directorio, veremos que tenemos un nuevo listener.log además del renombrado anteriormente. Como he mencionado antes, yo procedo a borrarlo.

[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ ls -l
total 10284208
-rw-r-----    1 oracle   oinstall       2533 Mar 24 10:10 listener.log
-rw-r-----    1 oracle   oinstall 5257840385 Mar 24 10:09 listener.log_old
[email protected]:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ rm -f listener.log_old

Y con esto, hemos terminado nuestro proceso de rotado online del log del listener.

Conclusión

Como ves, rotar el log del listener de Oracle online no es nada complicado. Solo tenemos que apagar el status unos segundos mientras renombramos el fichero, para volver a levantarlo y que todo siga su curso. Lo que hagas con el fichero una vez renombrado, es decisión tuya o de la política de retención que quieras aplicar.

Lo mejor de todo es que esta tarea tiene infinitas posibilidades: programar un script que haga una comprobación cada X tiempo del tamaño del log y si este supera, por ejemplo, 1Gb, se realicen las tareas de apagar el status, renombrar el fichero, levantar el status, comprimir el log antiguo y moverlo a otro FS. O puedes montar un script que haga este rotado diariamente para almacenar el log de cada día durante 180 días (por ejemplo).

Cuéntame que te ha parecido este proceso en la caja de comentarios que tienes abajo. Y si ya compartes la entrada en redes sociales, me haces un gran favor para que más gente conozca este portal.

Recuerda que puedes suscribirte a la newsletter de Como ser DBA justo en el pie de página. Solo te mandaremos un correo para avisarte de que hemos publicado una nueva entrada.

Hasta la próxima, ¡un saludo!

Compartir entrada en RRSS

SUSCRÍBETE A NUESTRA NEWSLETTER

Si quieres estar al tanto de todas las nuevas publicaciones, suscríbete a esta lista de correo para recibir en tu mail los nuevos posts publicados. ¡Así no te pierdes nada!

pablo_delgado_avatar.jpg

Pablo Delgado Flores

Auténtico apasionado por la informática, especialmente por las bases de datos, administración de sistemas y desarrollo web.

Empecé a trabajar como técnico informático mucho antes de obtener una titulación oficial (sysadmin). Actualmente trabajo como DBA Oracle, aunque manejo otros motores como MySQL/MariaDB, PostgreSQL y Amazon Redshift.

También escribo sobre informática en general en mi web Pablo Delgado Flores, la terminal de Linux/Unix en #Sudosu y  desarrollo web con Woocoomerce/WordPress en DesarrolloWoo.

Subscribirse
Notificar de
guest
0 Comentarios
Comentarios en línea
Ver todos los comentarios