Skip to Main Content

Breadcrumb

May 4th

Question and Answer

Tom Kyte

Thanks for the question, Miladin.

Asked: March 23, 2001 - 1:51 pm UTC

Last updated: June 06, 2011 - 12:46 pm UTC

Version: 816

Viewed 50K+ times! This question is

You Asked

I am dealing with very large alert log files .So I would like to
archive one part of the alert file and the keep rest of it.

I am affraid that Oracle will stop writing into alert log.I had this problem before.

Please help.

Thanks in advance.


Miladin




and Tom said...

Oracle always:

opens the alert in append mode
writes to it
closes it


It is safe to "mv" or rename it while we are running. Since chopping part of it out would be lengthly process, there is a good chance we would write to it while you are editing it so I would not advise trying to "chop" part off -- just mv the whole thing and we'll start anew in another file.

If you want to keep the last N lines "online", after you mv the file, tail the last 100 lines to "alert_also.log" or something before you archive off the rest.

Rating

  (25 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Oracle stops to write to alert.log file

A reader, September 02, 2005 - 5:37 am UTC

Tom,

After restarting of Oracle instance on SUSE Linux Oracle stops to write alert log file. I can't see any entries since 2 days (but all other operations are OKay inclusice 20 log switches per day (normally Oracle log each log switch to alert ora). Is there any limits on alert.log file size for Oracle on Suse Linux (currently the file is "only" 1068819 byte).

Tom Kyte
September 02, 2005 - 6:22 am UTC

nope, no limits on the alert log size.

do something that would require a write to it -- like an alter system switch logfile, if it doesn't appear, then something strange is afoot (check permissions and all)

A reader, November 22, 2005 - 11:23 am UTC

Hi tom,
Does every alter system command issued to a database will write a copy of command to alert.log file?
If it is, how can we omit the alter system command been write to alert.log file?
We have 2 set of system parameters we need to change every day, twice a day, and every time we issue the change system will write a copy to alert.log file, thus our alert file become much bigger and bigger, thus we need to find a way to exclude the alter system command from alert log file.
thanks

Tom Kyte
November 22, 2005 - 11:56 am UTC

no, not all. and the ones that do, you cannot stop them.

I seriously doubt the addition of 2 lines per day will be any sort of cause for concern. You are talking about what - less than 800 lines per year.



logrotate

Mark, November 22, 2005 - 1:44 pm UTC

I find the Unix utility logrotate is great for managing alert logs. From "man logrotate":

DESCRIPTION
logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be han­dled daily, weekly, monthly, or when it grows too large.

I have it configured so that when the current alert log exceeds 10MB, it's automatically gzipped at night, during off-hours. Up to five archived alert logs (almost wrote "archived logs" - probably a poor choice of words :)) are kept. Keeps me organized, and the alert logs compress nicely:

> ll alert*
-rw-r--r-- 1 oracle oinstall 6659624 2005-11-22 13:23 alert_zeus.log
-rw-r--r-- 1 oracle oinstall 1396495 2005-11-10 00:13 alert_zeus.log.1.gz
-rw-r--r-- 1 oracle oinstall 612963 2005-10-17 00:11 alert_zeus.log.2.gz
-rw-r--r-- 1 oracle oinstall 781693 2005-07-29 18:50 alert_zeus.log.3.gz
-rw-r--r-- 1 oracle oinstall 559673 2005-09-26 10:15 alert_zeus.log.gz

Mark

Tom Kyte
November 22, 2005 - 4:23 pm UTC

thanks!

What about windows?

Kim Nørby Andersen, November 23, 2005 - 8:34 am UTC

On windows you cannot just move it, since the oracle process has it's hands on it. Is there a default/best practice for truncating the alert_log?

Tom Kyte
November 23, 2005 - 10:07 am UTC

that is not true of the alert log, messages are written to the alert by:

open file
write message 
close file


so as to not lose any in the event of a failure.

C:\oracle\product\10.1.0\admin\ora10gr1\bdump>dir
 Volume in drive C has no label.
 Volume Serial Number is 6450-8D36

 Directory of C:\oracle\product\10.1.0\admin\ora10gr1\bdump

23/11/2005  09:55 AM    <DIR>          .
23/11/2005  09:55 AM    <DIR>          ..
23/11/2005  09:54 AM           185,962 alert_ora10gr1.log
               1 File(s)        185,962 bytes
               2 Dir(s)  16,818,581,504 bytes free


C:\oracle\product\10.1.0\admin\ora10gr1\bdump>sqlplus /

SQL*Plus: Release 10.1.0.4.0 - Production on Wed Nov 23 09:55:04 2005

Copyright (c) 1982, 2005, Oracle.  All rights reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Production
With the Partitioning, OLAP and Data Mining options

ops$xp10gr1\tkyte@ORA10GR1> host rename alert_ora10gr1.log alert_old.log

ops$xp10gr1\tkyte@ORA10GR1> host dir
 Volume in drive C has no label.
 Volume Serial Number is 6450-8D36

 Directory of C:\oracle\product\10.1.0\admin\ora10gr1\bdump

23/11/2005  09:55 AM    <DIR>          .
23/11/2005  09:55 AM    <DIR>          ..
23/11/2005  09:54 AM           185,962 alert_old.log
               1 File(s)        185,962 bytes
               2 Dir(s)  16,818,610,176 bytes free

ops$xp10gr1\tkyte@ORA10GR1> alter system switch logfile;

System altered.

ops$xp10gr1\tkyte@ORA10GR1> host dir
 Volume in drive C has no label.
 Volume Serial Number is 6450-8D36

 Directory of C:\oracle\product\10.1.0\admin\ora10gr1\bdump

23/11/2005  09:55 AM    <DIR>          .
23/11/2005  09:55 AM    <DIR>          ..
23/11/2005  09:54 AM           185,962 alert_old.log
23/11/2005  09:55 AM               186 alert_ora10gr1.log
               2 File(s)        186,148 bytes
               2 Dir(s)  16,818,610,176 bytes free
 

Thanks a bunch

Kim Nørby Andersen, November 25, 2005 - 10:49 am UTC

Thank you so very much.

location of log file

charm, January 25, 2007 - 2:00 am UTC

hi Sir Tom!

I've been using your site everytime I have problems on Oracle programming. I've been trying to use your dbms_job package and the jobs I entered always fails, how can i see the LOG FILE so that I can see where in the file, the job fails. Thanks in advance! More Power!

Thanks,
Charm

bdump growing too fast

Wole, March 13, 2007 - 5:38 pm UTC

Hi Tom,
I bought one of your life changing books "Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions" and i read there that we can rename the Alart.log file. right now am having a little problem. i just got to a company and i found out that the BDUMP had grown to about 50G. of which one of the file "vsdb1_p000_17533.trc" had grown to 20G. i want to know if i rename this file, will oracle create another of it or will it break down my database?

Thanks.




Tom Kyte
March 13, 2007 - 9:02 pm UTC

that is a trace file from a background parallel execution server - if the parallel execute server is still "running", erasing the file will reclaim no disk storage as that erase will just unlink the directory entry.

if that execution server is not running, erasing that trace file will immediately return the allocated space to the file system.

regardless - oracle will not "break down" if you erase this.

Paul G. Matuszyk, March 14, 2007 - 5:21 am UTC

Hi

You are right that if you delete the file it will NOT reclaim the space. I have a good solution for this:
if the file name is ABC.trc
just do:

echo "" > ABC.trc

it will shrink the file and the process will continue to write to it but you will not run out of space!

Regards

Paul G. Matuszyk
Tom Kyte
March 14, 2007 - 7:57 am UTC

no, that won't do anything on most systems either.

if some process has the original ABC.trc open - it will STILL have it open (with all 50gb associated with it) after you do your echo, just you won't be able to see the 50gb file anymore.

wole, March 14, 2007 - 9:32 am UTC

Thanks a lot, you are very great.

Logrotate

wole, March 14, 2007 - 9:41 am UTC

Hi Tom,

I read about Mark on this section where he talked about Logrotate. can you please tell me about it and how i can get to install it on my system in order to make my job easier.

Thanks.
Tom Kyte
March 14, 2007 - 2:00 pm UTC

not really, it looks like a unix utility that may or may not be available on your unix system - you'd want to google around for it I would guess.

logrotate

Mark, March 14, 2007 - 8:51 pm UTC

Wole,

Which OS? If Linux, you may already have it, or you should at least be able to install it using Yum or Apt, depending on the distro. If Windows, you might be out of luck. :)

Mark

Wole, March 26, 2007 - 5:36 pm UTC

Hi Mark,

The OS is Solaris

bdump issue

wole, March 27, 2007 - 11:15 am UTC

Hi Tom,

Sorry to bother you much on this, but have got this problem on my database. My bdump is growing too fast when i ls it. i got this:

-rw-r----- 1 oracle oinstall 799 Mar 14 01:15 vsdb2_m000_10335.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 02:15 vsdb2_m000_13639.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 03:15 vsdb2_m000_15538.trc
-rw-r----- 1 oracle oinstall 798 Mar 14 04:15 vsdb2_m000_18761.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 05:15 vsdb2_m000_21961.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 07:16 vsdb2_m000_28519.trc
-rw-r----- 1 oracle oinstall 796 Mar 14 08:16 vsdb2_m000_1787.trc
-rw-r----- 1 oracle oinstall 797 Mar 14 09:15 vsdb2_m000_4036.trc
-rw-r----- 1 oracle oinstall 797 Mar 14 10:15 vsdb2_m000_7290.trc
-rw-r----- 1 oracle oinstall 798 Mar 14 11:15 vsdb2_m000_10555.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 12:15 vsdb2_m000_13823.trc
-rw-r--r-- 1 root other 648K Mar 14 13:00 bof.log
-rw-r----- 1 oracle oinstall 799 Mar 14 13:16 vsdb2_m000_17106.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 14:15 vsdb2_m000_19277.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 15:15 vsdb2_m000_22513.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 16:15 vsdb2_m000_25807.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 17:15 vsdb2_m000_29100.trc
-rw-r----- 1 oracle oinstall 797 Mar 14 18:15 vsdb2_m000_2406.trc
-rw-r----- 1 oracle oinstall 797 Mar 14 19:15 vsdb2_m000_4643.trc
-rw-r----- 1 oracle oinstall 796 Mar 14 20:15 vsdb2_m000_7884.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 21:15 vsdb2_m000_11122.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 22:15 vsdb2_m000_14411.trc
-rw-r----- 1 oracle oinstall 799 Mar 14 23:16 vsdb2_m000_17671.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 00:16 vsdb2_m000_20909.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 01:15 vsdb2_m000_23082.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 02:15 vsdb2_m000_26484.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 03:15 vsdb2_m000_29588.trc
-rw-r----- 1 oracle oinstall 797 Mar 15 04:15 vsdb2_m000_2917.trc
-rw-r----- 1 oracle oinstall 797 Mar 15 05:16 vsdb2_m000_6159.trc
-rw-r----- 1 oracle oinstall 797 Mar 15 06:15 vsdb2_m000_8381.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 07:15 vsdb2_m000_11674.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 08:15 vsdb2_m000_14906.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 09:15 vsdb2_m000_18121.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 10:16 vsdb2_m000_21379.trc
-rw-r----- 1 oracle oinstall 799 Mar 15 11:15 vsdb2_m000

and going through them one by one, i found out that bof.log is giving this messages continiously:

DG 2007-03-11-18:20:59 0 2 0 Remote Status = ORA-16539
DG 2007-03-11-18:20:59 0 2 0 Flags = 00000084
DG 2007-03-11-18:20:59 0 2 0 REQUEST NOT FOUND:
DG 2007-03-11-18:20:59 0 2 0 Remote site 01001000 sent phase message
DG 2007-03-11-18:20:59 0 2 0 Request ID = 1.1.615287796
DG 2007-03-11-18:20:59 0 2 0 Opcode = CTL_ENABLE
DG 2007-03-11-18:20:59 0 2 0 Root Resource Handle = 00001000
DG 2007-03-11-18:20:59 0 2 0 Phase = END
DG 2007-03-11-18:20:59 0 2 0 Remote Status = ORA-16539
DG 2007-03-11-18:20:59 0 2 0 Flags = 00000084
DG 2007-03-11-18:20:59 0 2 0 REQUEST NOT FOUND:
DG 2007-03-11-18:20:59 0 2 0 Remote site 01001000 sent phase message
DG 2007-03-11-18:20:59 0 2 0 Request ID = 1.1.615287796
DG 2007-03-11-18:20:59 0 2 0 Opcode = CTL_ENABLE
DG 2007-03-11-18:20:59 0 2 0 Root Resource Handle = 00001000
DG 2007-03-11-18:20:59 0 2 0 Phase = END
DG 2007-03-11-18:20:59 0 2 0 Remote Status = ORA-16539
DG 2007-03-11-18:20:59 0 2 0 Flags = 00000084
DG 2007-03-11-18:20:59 0 2 0 REQUEST NOT FOUND:
DG 2007-03-11-18:20:59 0 2 0 Remote site 01001000 sent phase message
DG 2007-03-11-18:20:59 0 2 0 Request ID = 1.1.615287796
DG 2007-03-11-18:20:59 0 2 0 Opcode = CTL_ENABLE
DG 2007-03-11-18:20:59 0 2 0 Root Resource Handle = 00001000
DG 2007-03-11-18:20:59 0 2 0 Phase = END
DG 2007-03-11-18:21:00 0 2 0 Remote Status = ORA-16539
DG 2007-03-11-18:21:00 0 2 0 Flags = 00000084
DG 2007-03-11-18:21:00 0 2 0 REQUEST NOT FOUND:
DG 2007-03-11-18:21:00 0 2 0 Remote site 01001000 sent phase message
DG 2007-03-11-18:21:00 0 2 0 Request ID = 1.1.615287796
DG 2007-03-11-18:21:00 0 2 0 Opcode = CTL_ENABLE
DG 2007-03-11-18:21:00 0 2 0 Root Resource Handle = 00001000
DG 2007-03-11-18:21:00 0 2 0 Phase = END
DG 2007-03-11-18:21:00 0 2 0 Remote Status = ORA-16539
DG 2007-03-11-18:21:00 0 2 0 Flags = 00000084
DG 2007-03-11-18:21:00 0 2 0 REQUEST NOT FOUND:
DG 2007-03-11-18:21:00 0 2 0 Remote site 01001000 sent phase message
DG 2007-03-11-18:21:00 0 2 0 Request ID = 1.1.615287796
DG 2007-03-11-18:21:00 0 2 0 Opcode = CTL_ENABLE
DG 2007-03-11-18:21:00 0 2 0 Root Resource Handle = 00001000
DG 2007-03-11-18:21:00 0 2 0 Phase = END
DG 2007-03-11-18:21:00 0 2 0 Remote Status = ORA-16539
DG 2007-03-11-18:21:00 0 2 0 Flags = 00000084
DG 2007-03-11-18:21:00 0 2 0 REQUEST NOT FOUND:
DG 2007-03-11-18:21:00 0 2 0 Remote site 01001000 sent phase message
DG 2007-03-11-18:21:00 0 2 0 Request

looking at the timing, i found out that they are generated almost at thee same time.

Can you please help me on this, what do you think is generating this problem and wht can i do to stop it from occuring? and more so do i clean up the message?

Thanks so much for these. You are a great man.
Tom Kyte
March 27, 2007 - 12:00 pm UTC

please file an itar for this.

wole, March 27, 2007 - 11:33 am UTC

Hi Tom,

I searched for this error message and i found that its an
internal error message:

ORA-16539 "Task element not found"

Cause: Internal error.

Action: Contact Oracle Support Services.

what do you think is the cause for this error message?

the original name for the bof.log is drcVSDB2.log.

thanks.
Tom Kyte
March 27, 2007 - 12:01 pm UTC

Action: Contact Oracle Support Services.

response to followup by Paul G.

Chris, May 23, 2007 - 4:25 pm UTC

First and foremost, I just wanted to thank you Tom for this excellent site. It's proven to be a truly invaluable resource for so many of us.

My comment is about Paul's post above. Here's a quick recap:

>I have a good solution for this:
>if the file name is ABC.trc
>just do:
>echo "" > ABC.trc
>it will shrink the file and the process will continue to >write to it but you will not run out of space!


I have tested this extensively on Linux, and believe Paul may be correct. I understand this may seem more of an OS topic, but it also has direct relevance to Oracle, when dealing with management of the alert log. Here are my steps to reproduce:

It will take two windows. Steps of which are identified below. I am using the Bash shell:

[ window 1 ]
jaclyn:/# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              16G   14G  2.0G  87% /

The thing to note here is the amount of free space. 2.0G in this case. Let's simulate a 1G log file:

[ window 1 ]
jaclyn:/# dd if=/dev/sda of=temp.txt bs=8192 count=131072

This may take a few minutes, depending on the speed of your machine. In the meantime, you can verify fuser actually works in another window:
[ window 2 ]
jaclyn:/# fuser -v /temp.txt
                     USER        PID ACCESS COMMAND
/temp.txt:           root      17409 F.... dd

From this we can see the dd command has the file open for writing (that's what the capital F in access refers to)

Now wait for dd to finish:
[ window 1 ]
jaclyn:/# dd if=/dev/sda of=temp.txt bs=8192 count=131072
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 190.562 seconds, 5.6 MB/s

Check the free space now (should be 1G less):
[ window 1 ]
jaclyn:/# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              16G   15G 1018M  94% /

And it is (now only 1018M or ~1G). Please keep in mind I am the only one on this system, and not performing any other tasks.

Here I have a small routine in C that will open a file read/write, and print out it's size and the SEEK_END position every 5 seconds:
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>

int main(int argc, char **argv) {

 int fd;
 unsigned pos;
 struct stat stats;

 if (argc != 2)
  exit(1);

 if ((fd = open(argv[1], O_RDWR)) == -1) {
  perror("Error in open()");
  exit(1);
 }

 while(1) {
  if ((pos = lseek(fd, 0, SEEK_END)) == -1)
      perror("Error in lseek()");
  else
      printf("lseek to %u\n", pos);


  if (fstat(fd, &stats))
      perror("Error in fstat()");
  else
      printf("size = %u\n", stats.st_size);

  printf("\n");

  usleep(5000000);
 }
}

Compile and start the program:
[ window 1 ]
jaclyn:/# gcc open_and_seek.c
jaclyn:/# ./a.out temp.txt
lseek to 1073741824
size = 1073741824

lseek to 1073741824
size = 1073741824

Let this run in window 1, and now truncate the file in window 2:
[ window 2 ]
jaclyn:/# > /temp.txt

Let's now go back and look at window 1:
[ window 1 ]
lseek to 0
size = 0

lseek to 0
size = 0

Also try this in window 2:
[ window 2 ]
jaclyn:/# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              16G   14G  2.0G  87% /

The space is indeed reclamed, and fuser will prove the file is still open for writing:
[ window 2 ]
jaclyn:/# fuser -v /temp.txt
                     USER        PID ACCESS COMMAND
/temp.txt:           root      17433 F.... a.out


It may also be interesting to note exactly what ` > <file> ' does:

jaclyn:/# strace -e trace=open /bin/bash -c '> /test.txt' 2>&1 | grep test.txt
open("/test.txt", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3


Apparently opening for truncation (O_TRUNC) directly affects other processes that already have this file open. I should also note that if you remove or delete the file, then the behavior is as Tom suggested -- that is, the space will not really be freed until all file handles are released.

moving logs

A reader, June 02, 2011 - 1:33 am UTC

Do I have to shutdown my Database to move/delete/rename
listerner.log/alert files/trace files or can I just remove them while my Database is up and running?

I read somewhere on windows you must shutdown your server, whereas on unix one can simple remove it.
Tom Kyte
June 02, 2011 - 9:01 am UTC

it depends. If something is writing to them - eg: you have a trace file being written to by a given session - you typically cannot "move" that file. The session will continue writing to a file you cannot see anymore - the mv'ed file will be truncated.

It would be safest to schedule a move of files like that until a period of inactivity, a maintenance window.


Various log files.

djb, June 02, 2011 - 9:10 am UTC

On Windows we shut down the listener, rename the log file with the date and then restart the listener. These can either be zipped up to save space as they can grow very large, or retained for a period in case they are required and then deleted by a batch job on a regular basis.

For the alert log, this is appended into an alert.his file nightly, while the database is running, and then deleted. Oracle simply creates a new alert.log if one doesn't exist the next time it needs to write to one.
Tom Kyte
June 02, 2011 - 9:15 am UTC

just beware that you are likely loosing alert entries that way.

It would probably be better to:

a) mv the alert log
b) then append

You can still "lose" an entry - but the window of opportunity for the lose is a lot smaller than your current approach.

Alert logs

djb, June 02, 2011 - 9:34 am UTC

The systems this is done on aren't 24/7 so the chances of losing an entry at the time this is done (overnight) are quite small. But you are right, there is still a chance so I'll adapt it to 'mv' then append as you suggest. It will also make me have a consistent approach if I have to do this on any systems in full time use in future. Thanks for the suggestion.

Alert logs and listener logs

A reader, June 03, 2011 - 8:39 am UTC

There are some questions about how to manage alert and listener logs on Windows. Please allow me to share my experiences. These observations are 10g specific and for Windows only.

a) On Windows, listener keeps the log file locked for writing so deletion/renaming of listener log file is not possible at OS level while the listener is running. However, Oracle allows me to change the listener log file name without shutting down the listener.

lsnrctl set log_file '<new log file name>'

Once I set a new name for log file, listener will start writing to new file and previous log file can be archived.

b) Alert log is not continuously locked for writing so it can be renamed/deleted at OS level anytime. There is no need to shutdown database. If the current alert log is moved to an archive, Oracle will create a new one when it needs to write something to alert log.

c) Other trace files in bdump and udump destinations. Most times these files are not locked and can be moved to zipped archive. Sometimes, couple of files cannot be deleted as these are locked by Oracle processes. In such case, there is no option but to restart the database. Sometimes I have seen trace files grow to like 60-70+ GB and take up entire disk space. Mostly this happens when some process within database has gone zombie and is writing to the trace file like crazy. Most times, as soon as I restart the database, the GB sized file disappears on its own, otherwise I delete is manually. No editor that I know of can open a 70GB trace file.

Hope this helps.
Tom Kyte
June 06, 2011 - 9:00 am UTC



c) you can control the max dump file size

ops$tkyte%ORA11GR2> show parameter max_dump

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
max_dump_file_size                   string      unlimited

ADR

Albert Nelson A, June 06, 2011 - 4:57 am UTC

Hi Tom,

With Oracle's Fault Diagnosability Infrastructure added in 11g, do we have a way to implement archiving of trace files, alert log files, etc using ADR commands alone? If not now, is it in pipeline for a future release?

Thanks and Regards,

Albert Nelson A.

Windows Alert log names

DJB, June 06, 2011 - 9:55 am UTC

In Windows we often get the alert log name concatenated eg FM1FM1alert.log, which causes a new fm1alert.log to be created. I seem to remember an explanation as to why this happens but I can't seem to trace it now. Anyone have a link to it ? It was an Oracle note, as I remember.

To: Albert Nelson A

A reader, June 06, 2011 - 12:17 pm UTC

With ADRCI PURGE command, this can be done. I have not tested it out yet.

http://download.oracle.com/docs/cd/E11882_01/server.112/e16536/adrci.htm#BABBHGFC

Tom Kyte
June 06, 2011 - 12:46 pm UTC



use this link:

http://docs.oracle.com/docs/cd/E11882_01/server.112/e16536/adrci.htm#SUTIL700

(i hate links that have # B in them :( that is what I use to denote 'begin bold'..)

Thanks

Albert Nelson A, June 06, 2011 - 10:33 pm UTC


Listener log deletion

Abhishek Kumar, August 30, 2012 - 3:33 am UTC

For dealing with big listener files without shutting down the database . We can do the following.

lsnrctl set log_status off
then

mv listener.log new_dir/.

lsnrctl set log_status on.

Then if you need the listenr.log file in the new directory can be deleted.

Daniel, April 12, 2013 - 10:25 am UTC

Unix filesystem identify a file by inode not by filename. Oracle will continue write to renamed alert log until database is restarted.

In Unix based OS the file need to be emptied after the file is backed up.

shell$> >alert.log