vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Michael Raschepkin <rm@DELETE.IT.artelecom.ru> wrote >Alexander Moeckel wrote: >> with HP-UX I use a shell script: >> cp listener.log listener_`date +%Y%m%d_%H%M`.log >> echo "" > listener.log >> >> Oracle has problems, if the logfile is deleted or renamed. No new file >> will be created before you restart the listener or instance. With the >> echo the content of the file will be deleted, not the file himself. >thanks a lot. > >it's very strange because alert<SID>.log is filled ok when recreated. listener.log has nothing to do with alert.log. So you won't see entries in alert.log when there are troubles with your listener. To copy the listener logfile as Alex described above is one good solution. If there is not enough space left in your Oracle_Home to do a copy of the old listener logfile you can do this to make sure the old inode will be used further and the last entries in your old listener.log are stored: tail -100 listener.log > listener.log_old > listener.log regards Eve |
| |||
| > > > >it's very strange because alert<SID>.log is filled ok when recreated. > > listener.log has nothing to do with alert.log. So you won't That's not what he says. He is making a comparison between the listener.log, which is not recreated when deleted, and the alert.log, which is. The explanation is quite easy. As I said before, the listener.log is not recreated, because the file is not being closed. The program tnslsnr keeps a file descriptor open to the inode that represents the file. The alert.log is NOT being kept open. For every singles write to the file it is opened before, and closed afterwards. If oracle doesn't find the alert.log when trying to open it, it is created instead. regards, Peter |
| ||||
| "Peter van Rijn" <p.vanrijnREMOVE@THISzhew.nl> wrote in message news:<uvr1t27shk401a@corp.supernews.com>... > The alert.log is NOT being kept open. For every singles write to the file it > is opened before, and closed afterwards. If oracle doesn't find the > alert.log when trying to open it, it is created instead. Hi, Peter, alert_SID.log is kept open all the time by background processes (see below). No server process (shadow process) writes to this file. /app/oracle/admin/pdev/bdump>fuser alert_pdev.log alert_pdev.log: 5937o 5935o 5933o 5931o 5929o 5927o 5925o 5923o 5921o 5919o /app/oracle/admin/pdev/bdump>ps -fp 5937,5935,5933,5931,5929,5927,5925,5923,5921,5919 UID PID PPID C STIME TTY TIME CMD oracle 5933 1 0 Sep 29 ? 320:22 ora_snp1_pdev oracle 5923 1 0 Sep 29 ? 31:26 ora_lgwr_pdev oracle 5937 1 0 Sep 29 ? 517:32 ora_snp3_pdev oracle 5927 1 0 Sep 29 ? 2:12 ora_smon_pdev oracle 5931 1 0 Sep 29 ? 383:58 ora_snp0_pdev oracle 5929 1 0 Sep 29 ? 0:01 ora_reco_pdev oracle 5935 1 0 Sep 29 ? 440:20 ora_snp2_pdev oracle 5925 1 0 Sep 29 ? 11:06 ora_ckpt_pdev oracle 5921 1 0 Sep 29 ? 5:20 ora_dbw0_pdev oracle 5919 1 0 Sep 29 ? 0:01 ora_pmon_pdev Yong Huang |