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:
oracle@bbdd1:/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 2022Como 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:
oracle@bbdd1:/oracle/app$ du -sg *
40.57 grid
0.02 oraInventory
19.65 oracleVale, 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.
oracle@bbdd1:/oracle/app$ cd oracle
oracle@bbdd1:/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 tfaBien, ya tenemos una pista por donde andar, la carpeta diag. Entremos y veamos que hay.
oracle@bbdd1:/oracle/app/oracle$ cd diag
oracle@bbdd1:/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 tnslsnrAjá, nuestra candidata es la carpeta tnslsnr. Vamos a seguir bajando subdirectorios y obteniendo el tamaño de carpetas/ficheros para rascar espacio.
oracle@bbdd1:/oracle/app/oracle/diag$ cd tnslsnr
oracle@bbdd1:/oracle/app/oracle/diag/tnslsnr$ du -sg *
8.31 bbdd1
oracle@bbdd1:/oracle/app/oracle/diag/tnslsnr$ cd bbdd1
oracle@bbdd1:/oracle/app/oracle/diag/tnslsnr/bbdd1$ du -sg *
4.91 listener
3.40 listener_dgBien. 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.
oracle@bbdd1:/oracle/app/oracle/diag/tnslsnr/bbdd1$ cd listener
oracle@bbdd1:/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
oracle@bbdd1:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener$ cd trace
oracle@bbdd1:/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.
oracle@bbdd1$ 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 correctamenteBien, 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.
oracle@bbdd1:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ mv listener.log listener.log_old
oracle@bbdd1:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ ls -l
total 10284200
-rw-r----- 1 oracle oinstall 5257840385 Mar 24 10:09 listener.log_oldVolvemos 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 correctamenteSi 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.
oracle@bbdd1:/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
oracle@bbdd1:/oracle/app/oracle/diag/tnslsnr/bbdd1/listener/trace$ rm -f listener.log_oldY 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!
