ORACLE11G Listener log Listener.log file too much processing

The monitoring logs and warning logs for Oracle 11g are all in the/opt/oracle/app/diag/tnslsnr/machine name/listener directory

Where the warning log is in the alert directory, the listening log is under the trace directory. The log files generated under the Listener directory are larger and are the main objects of cleanup. In the Listener directory, the listening log is a file named Listener.log, and the warning log log.xml, the log every 11M or so will be divided into a log_xxxx.xml log, gradually accumulate.

Is there no need to truncate the listening log files for maintenance? The answer is in the negative. Of course, the Listening log files (Listener.log) are cleaned regularly, and if you do not clean up regularly, you will encounter some of the following problems:

1. The Listening log file (Listener.log) is getting bigger and larger, taking up additional storage space. (Of course, now store the price of cabbage, not bad for that few grams of space.) But we still have to be in the spirit of craftsmen, excellence.

2. Listening log file (Listener.log) has become too general to bring some problems: the LISTENER.LOG log size cannot exceed 2GB, exceeding causes the listener listener to be unable to process the new connection.

3, the Listening log file (Listener.log) becomes too large, to write, see some performance problems, trouble.

First, a single instance:
$ find $ORACLE _base-name Listener.log
/opt/oracle/app/diag/tnslsnr/testdb/listener/trace/listener.log

LSNRCTL> show
The following operations are available after show
An asterisk (*) denotes a modifier or extended command:

rawmode                            displaymode                        
rules                              trc_file                           
trc_directory                      trc_level                          
log_file                           log_directory                      
log_status                         current_listener                   
inbound_connect_timeout            startup_waittime                   
snmp_visible                       save_config_on_stop                
dynamic_registration               enable_global_dynamic_endpoint     
oracle_home                        pid  

LSNRCTL> show log_file
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxx)(PORT=1521)))
LISTENER parameter "log_file" set to /opt/oracle/app/diag/tnslsnr/testdb/listener/alert/log.xml
The command completed successfully

show log_status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxx)(PORT=1521)))
LISTENER parameter "log_status" set to ON
The command completed successfully

show log_directory
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxx)(PORT=1521)))
LISTENER parameter "log_directory" set to /opt/oracle/app/diag/tnslsnr/testdb/listener/alert
The command completed successfully

Monitoring is currently in a normal state, the log function is also open, and then a thought, the original log file size is full

Processing:

1: Stop the log first

LSNRCTL> set log_status off
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxx)(PORT=1521)))
LISTENER parameter "log_status" set to OFF
The command completed successfully
LSNRCTL> exit

2, to the directory/opt/oracle/app/diag/tnslsnr/wskjdb/listener/trace
MV Listener.log Listener.log.bak

3. Open log

LSNRCTL> set log_status on
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxx)(PORT=1521)))
LISTENER parameter "log_status" set to ON
The command completed successfully

4. Reload the Listener

LSNRCTL> reload
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxx)(PORT=1521)))
The command completed successfully
LSNRCTL> exit
LSNRCTL> show log_status 
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxx)(PORT=1521)))
LISTENER parameter "log_status" set to ON
The command completed successfully

5. Regenerate new log in directory, compress save
$tar czvf listener.log.bak.gz listener.log.bak

6, delete the original log:
rm -rf listener.log.bak

Second, in a RAC environment, you need to switch to a grid user to query the listening log
#su-grid
LSNRCTL command-line mode

set current_listener listener_scan1
set log_status off
cat /dev/null > listener_scan1.log
set log_status on
cat listener_scan1.log

Third, by using crontab to regularly clean:
Using a timer to clean up the listening log file is actually similar to the above, with the following script:

$listener_log.sh
#!/bin/bash

data_name=`date +‘%d%m‘`

cd /opt/oracle/app/diag/tnslsnr/wskjdb/listener/trace
lsnrctl set log_status off
mv listener.log /tmp/listener.log.$data_name
lsnrctl set log_status on
lsnrctl reload

Make crontab tasks:
0 1 * * * /home/oracle/listener_log.sh > /home/oracle/listener_log.log 2>&1

Execution time and retention policy can be self-made, through the crontab can get rid of manual operation, through the system to perform maintenance operations automatically.

ORACLE11G Listener log Listener.log file too much processing

Alibaba Cloud Hot Products
Elastic Compute Service (ECS)	Dedicated Host (DDH)	ApsaraDB RDS for MySQL (RDS)	ApsaraDB for PolarDB(PolarDB)	AnalyticDB for PostgreSQL (ADB for PG)
AnalyticDB for MySQL(ADB for MySQL)	Data Transmission Service (DTS)	Server Load Balancer (SLB)	Global Accelerator (GA)	Cloud Enterprise Network (CEN)
Object Storage Service (OSS)	Content Delivery Network (CDN)	Short Message Service (SMS)	Container Service for Kubernetes (ACK)	Data Lake Analytics (DLA)
ApsaraDB for Redis (Redis)	ApsaraDB for MongoDB (MongoDB)	NAT Gateway	VPN Gateway	Cloud Firewall
Anti-DDoS	Web Application Firewall (WAF)	Log Service	DataWorks	MaxCompute
Elastic MapReduce (EMR)	Elasticsearch