Thank-you!

 

This should prove to be helpful.

 

Sam Bootsma

George Brown College

[EMAIL PROTECTED]

416-415-5000 x4933

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: March 4, 2003 2:22 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Listener Hangs

 

This is how you can clean up listener.log w/o taking the listener down.

 

You can copy the listener.log to an archive location, then do the following:

 

cat "/dev/null" and redirect to listener.log file. This will zero the current file and allow other updates to the log from the listener to continue.

 

eg: cp listener.log wherever.log
cat /dev/null > listener.log

 

ls -l listener.log
-rw-r--r-- 1 oracle 0 Apr 5 13:22 listener.log
lsnrctl status
ls -l listener.log
-rw-r--r-- 1 oracle 160 Apr 5 13:22 listener.log

 

Here you can see the listener.log files gets emptied. Doing a 'status' command on the listener
you can see the current tnslsnr process continues to write to the file.

 

By redirecting the output of an empty file '/dev/null' or using a file that may contain the
last 100 lines of the Listener and redirecting to the "listener.log", you keep the same inode
value that tnslsnr process uses to write to the "listener.log".

 

The key is not to remove or move the current "listener.log" while the tnslsnr process is running.
It is ok to copy the file for historical records.

-----Original Message-----
From: Sam Bootsma [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 12:05 PM
To: Multiple recipients of list ORACLE-L
Subject: Listener Hangs

We are running Oracle 7.3.4.5.0 on an IBM/AIX RISC System/6000: Version 2.3.4.0.0. 

 

Yesterday morning our LISTENER process hung.  “ERROR: ORA-12203: TNS:unable to connect to destination”.   We resolved the problem using the following steps: 

a)                               Stop Listener using LSNRCTL utility (this hung – did not succeed in stopping the listener)

b)                               Issue UNIX command kill -9 <process id> to kill the corresponding Listener process. 

c)                               Start the listener using the LSNRCTL utility

 

I checked the alert log and listener log.  I found nothing in either file pointing to what the problem might have been.  However, I did note that the listener.log file was 200 MB in size.  Would the large size of the listener.log file contribute to the Listener hanging?  This problem has occurred 6 to 8 times in the past couple of weeks.  I do plan on starting a new listener.log file.

 

Thanks,

 

Sam Bootsma

[EMAIL PROTECTED]

 

Reply via email to