|
Michael, The problem is open file descriptors. On UNIX/Linux, if you delete a file with an open file descriptor or "handle" from a running process, then the file is deleted, but its contents are not deallocated from the file-system until the process(es) holding open file descriptors finally close them. From your question, I can tell you know all this, but I'm just restating it.... At any rate, I've found that performing a "truncating write" to such files can do the trick of not disturbing the open file descriptor(s) and not deleting the file, but causes space to be deallocated. Try something like: echo "This file truncated by DBA on `date`" > {file-name}where "{file-name}" is the trace file (or alert.log file) in question. The MMON process will still write to the file (and maybe you'll muck up any writes it was doing to the file at the time you truncated it), but since it has its file descriptor open in "append write" mode, it'll start over again from where your write left off. Hope this helps... Tim Gorman consultant - Evergreen Database Technologies, Inc. P.O. Box 630791, Highlands Ranch CO 80163-0791 website = http://www.EvDBT.com/ email = Tim@xxxxxxxxx mobile = +1-303-885-4526 fax = +1-303-484-3608 Yahoo IM = tim_evdbt Hand, Michael T wrote: -- //www.freelists.org/webpage/oracle-lGreetings, This is a HP-UX 11.23 machine with 30 or so 10g & 9i databases on it. The problem was one volume's space maxing out. Found 4 10.2.0.3 db's with 2Gb+ MMON trace files with date stamps over 1 month old. Deleted these files and cleaned house on several others db's. Checking disk space shows the MMON trace file space was not released. I will look into note 422954.1 to try to avoid a recurrence, but in the mean time I would rather not have to shutdown a dozen db's to find the 4 that had the MMON problem. Is there any method for finding which databases have these deleted trace files still open? Is there a way to close out a MMON trace without shutting down the db? Thanks, Mike Hand -- //www.freelists.org/webpage/oracle-l |
