deleting trace does not free up o/s space

Is there anyway after stopping a trace and removing the trace file to have oracle release the space prior to the job completing?

Thanks Much

I don't quite understand what you are asking?

There was a trace running on a process that was generating a rather large trace file filling up a directory on the operating system. (Yes, I know that the max_dump_file should have been set smaller but at the point I discovered the problem the directory was 98% full). I stopped the trace and removed the file from the directory, however the operating system (hp/ux 11.0) never recognized the space as being free. I was told by another DBA that the operating system would not actually see the space as being free until the oracle procedure completed. I was looking for a way to force the clean up so that the space would be free because there are other databases that try to write to the same mount point. Does that clarify it any better? In the meantime the job has completed and I have the space back but I am wondering for future reference if there is anything that I could do (besides some preventive measures). I searched metalinks but didn't really find anything that I could apply to the situation. So, I was hoping that someone had a suggestion for me.
Thanks again.

Even I had faced this problem before! Yes Oracle holds on that space till the process finishes and then only releases the space. ( Even I would love to know reason behind it!)

Hi,
Yes, unless the other process stopped, you can actuallly release that space. Try join the v$session and v$process and alter system kill session to release those space.
Another solution will be using echo ''>ora_spid.trc, this should release the space used by the filesystem.
Good luck.

Quote:

---

Originally posted by launchpad
Even I had faced this problem before! Yes Oracle holds on that space till the process finishes and then only releases the space. ( Even I would love to know reason behind it!)

---

It's not an Oracle thing, it's a Unix thing (kind of, anyway). It has to do with how the process opens the file for I/O. If the process opens the file the space in the filesystem is allocated. (My eyes glazed over when my sysadmin started talking inodes and file descriptors...)

Anyway, the space won't get cleaned up until the process dies. If the process is a dedicated process, then it will clear up when the session ends. If the process is a shared server or background process, you're probably looking at bouncing your instance.

Marist,
To free up the space ,to terminate that process is one way, but not the only one.
Look:
oracle@dwdb udump]$ df -k /oracle
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda8 10080488 7721256 1847164 81% /oracle
[oracle@dwdb udump]$ ls -lt largefile
-rw-r--r-- 1 oracle dba 1048576000 Dec 12 20:32 largefile
In another session telnet terminal, i open that file via:
[oracle@dwdb udump]$ more largefile





Here, I wait here.

And in the first session, i clear the file with:
[oracle@dwdb udump]$ echo ''>largefile
[oracle@dwdb udump]$ df -k /oracle
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda8 10080488 6696256 2872164 70% /oracle

Now the space is released, but that session opening the file is still active.

This is useful if you really cannot terminate that process(like a bg process or shared server process).

Cooooooooooooooooooooooool

Thanks much. I'll try that!