I don't know about the listening log problem

Today, developers have asked me: "The code is not connected to the database occurs." After understanding some basic situations, I hope to get the clue of the problem by viewing the listening log. The first is to determine the storage path of the listening log by the following way:

Lsnrctl for linux:version 10.2.0.4.0-production on 21-jun-2016 21:19:56copyright (c) 1991, Oracle.  All rights reserved. Connecting to (Address= (PROTOCOL=TCP) (host=) (port=1521)) STATUS of the LISTENER------------------------Alias                     Listenerversion                   Tnslsnr for linux:version 10.2.0.4.0-productionstart Date                21-jun-2016 12:02:41uptime                    0 Days 9 hr. Min. sectrace level               offsecurity                  on:local OS authenticationsnmp offlistener Parameter                      File
   /u01/app/oracle/product/10.2.0/db_1/network/admin/listener.oralistener Log File         /u01/app/oracle/product/ 10.2.0/db_1/network/log/listener_rac1.loglistening Endpoints Summary ...

The listening log is used to record the client's connection to the server, and also to record information such as listening for registration and dynamic registration. In the process of viewing the listening log, found that the log file is large, the VI editor opened slowly, had to tail-10000 listener_rac1.log > View.txt way to dump its content, which does not have the developer described the connection not on the record. The section of the log excerpt reads as follows:

21-jun-2016 21:22:13 * service_update * DSDB1 * 021-jun-2016 21:22:13 * service_update * DSDB1 * 021-jun-2016 21:22:33 * ( Connect_data= (SID=DSDB1) (Cid= (program=) (host=__jdbc__) (User=root)) * (Address= (PROTOCOL=TCP) (HOST=198.168.9.53) (port=36304)) * Establish * DSDB1 * 021-jun-2016 21:22:33 * (Connect_data= (SID=DSDB1) (Cid= (program=) (host=__jdbc__) (USER=root)) * ( Address= (PROTOCOL=TCP) (host=198.168.9.53) (port=36303)) * Establish * DSDB1 * 021-jun-2016 21:23:03 * (CONNECT_DATA= (SID =DSDB1) (Cid= (program=) (host=__jdbc__) (User=root)) * (Address= (PROTOCOL=TCP) (host=198.168.9.53) (PORT=36907)) * Establish * DSDB1 * 0

Finding the answer in the process of finding "LISTENER." The log log size cannot exceed 2GB, exceeding the thread that causes the listener listener to be unable to process the new connection. But this kind of problem "only occurs under the old 32bit Linux or Unix system, the real reason is that some 32bit OS comes with the file system does not support more than 2GB files, causing the listening service process (TNSLSNR) Append write log file error". My environment is a 64-bit Linux system Ah, anyway, still want to deal with the large log file (722MB). So what do you do with this file? Can I delete or rename files directly based on the experience of handling alert logs?

Practice has proved that it is not feasible to do so. Although the log file has been renamed, the connection information is still recorded in the renamed log file. What is the correct way to truncate the listening log? In fact, do not need to go to Baidu and Google, only with lsnrctl help can solve the problem (sometimes the built-in support of Oracle Tools is very intimate):

Lsnrctl> helpthe Following operations is Availablean asterisk (*) denotes a modifier or extended command:start               sto P                Status              services            version             reload              save_config         trace               spawn               Change_password     Quit                exit                set*                show*               

That's right. Just use the SET command! How do you use set? You can also continue to help by doing the following:

Lsnrctl> set Helpthe following operations is available after Setan asterisk (*) denotes a modifier or extended command :p assword                    rawmode                     displaymode                 trc_file                    trc_directory               trc_level                   log_file                    log_ Directory               log_status                  current_listener            inbound_connect_timeout     startup_waittime            save_ Config_on_stop         dynamic_registration        

Therefore, the correct way to truncate the listening log should follow these steps:

1. Stop monitoring service process logging: Set Log_status off

2. Renaming or deleting a listening log file

3. Turn on the Listening service process logging: Set Log_status on

Log_file: Used to specify the storage path for the listening log. Normally, after truncating the listening log, the listening service process creates a file named Listener.log under the default path, but in my environment, the Listener log is named Listener_rac1.log, so this command is used. It is also important to note that the Log_file command can only be used correctly when the log_status is on.

There's so much to the truncation of a small listening log, and Oracle's complexity is truly well-deserved! The developer feedback issue was not resolved, but it was not reproduced. Learned some of the past did not pay attention to the knowledge, right when the harvest!  

I don't know about the listening log problem