RE: Disk space did not release
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <ecandrietta@xxxxxxxxx>, "'David Roberts'" <big.dave.roberts@xxxxxxxxxxxxxx>
- Date: Sun, 18 May 2014 12:30:32 -0400
The remaining space probably has some file handle still holding it open. So
the inodes are unlinked and unless you really muck around the file will be
gone when whatever is holding it open stops holding it open. Then the
additional free space should re-appear.
Under some circumstances with NFS mounts there can be a lag in updating the
details of the file system contents in a race condition safe way. Every case
of this I have ever seen can be resolved on demand by an umount and mount
operation. Some errors may spew and/or you may have an additional wait for
the umount if something has this open. If you have any software overlay on
your filesystems that preserves deleted things you may have to empty your
trash.
Other folks have already detailed how to figure out file handles and owning
processes.
That's all I can think of right now.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Eriovaldo Andrietta
Sent: Sunday, May 18, 2014 9:53 AM
To: David Roberts
Cc: howard.latham@xxxxxxxxx; marko.sutic@xxxxxxxxx; ORACLE-L
Subject: Re: Disk space did not release
Thanks for answers,
Some time after removing manualy the data file, I see more free space in
disk
Filesystem Size Used Avail Use% Mounted on
/dev/f1/fold1 493G 141G 352G 29% /l/disk67
Only 13gb more instead of 20gb that was the file size removed.
Regards
Eriovaldo
2014-05-18 9:21 GMT-03:00 David Roberts <big.dave.roberts@xxxxxxxxxxxxxx>:
This is a little speculative, but I'm sure I will be corrected if this
doesn't work!
If the file is unreleased as it appears, then if you have permissions go
under /proc and look in each fd(?) directory for a file with the appropriate
size.
the /proc/<process id>/fd directory that this file resides in will reveal
the process id of the process that is holding the file open.
ps -ef | grep <process id> should reveal the process that is holding the
file open.
Logically this should be an oracle process, where you can follow the advice
previously given, however if it isn't an oracle process than you have
something else to investigate!
It can be useful before deleting a file to do an
fuser <filename>
to see what processes have a file open before you attempt to delete it.
Dave
On Sun, May 18, 2014 at 11:59 AM, howard.latham@xxxxxxxxx
<howard.latham@xxxxxxxxx> wrote:
And you may need to restart database , a x nix quirk
----- Reply message -----
From: "Marko Sutic" <marko.sutic@xxxxxxxxx>
To: <ecandrietta@xxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx"
<oracle-l@xxxxxxxxxxxxx>
Subject: Disk space did not release
Date: Sun, May 18, 2014 11:34 AM
Hello Eriovaldo,
you should run "DROP TABLESPACE TEMP2 INCLUDING CONTENTS AND DATAFILES;" to
drop file and release space on disk.
Now you have to delete file manually to release space on disk.
Regards,
Marko
On Sun, May 18, 2014 at 12:18 PM, Eriovaldo Andrietta
<ecandrietta@xxxxxxxxx> wrote:
Hi friends,
I had a temporary tablespace TEMP02 in the instance.
I ran:
$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/f1/fold1 493G 154G 339G 32% /l/disk67
After it I ran :
select * from dba_temp_files;
I got the file : /l/disk67/app/oracle/oradata/instance_name/temp02.dbf
I ran:
drop tablespace TEMP2;
So I immediately ran
$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/f1/fold1 493G 154G 339G 32% /l/disk67
and the spaces was not released. It keeps with 339G Avail
The SO is Linux
The database is 11g
What is wrong ?
Disk space should be released immediately?
Regards
Eriovaldo
Other related posts:
