DBAsupport.com Forums - Powered by vBulletin
Results 1 to 9 of 9

Thread: deleting trace does not free up o/s space

  1. #1
    Join Date
    Jan 2000
    Location
    *
    Posts
    37

    Question 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

  2. #2
    Join Date
    Apr 2001
    Location
    Brisbane, Queensland, Australia
    Posts
    1,203
    I don't quite understand what you are asking?
    OCP 8i, 9i DBA
    Brisbane Australia

  3. #3
    Join Date
    Jan 2000
    Location
    *
    Posts
    37
    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.

  4. #4
    Join Date
    Jul 2000
    Posts
    119
    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!)
    OCP 8.0, 8i, 9i

  5. #5
    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.
    www.cnoug.org

  6. #6
    Join Date
    Nov 2000
    Location
    greenwich.ct.us
    Posts
    9,092
    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.
    Jeff Hunter

  7. #7
    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).
    www.cnoug.org

  8. #8
    Join Date
    Dec 2002
    Posts
    3
    Cooooooooooooooooooooooool

  9. #9
    Join Date
    Jan 2000
    Location
    *
    Posts
    37
    Thanks much. I'll try that!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width