首先数据文件删除文件系统空间不释放的问题不只出现在Linux平台，所有平台都可能有这样的问题。这里只是在Linux平台做一些测试，其他平台类似；其次只有将数据文件存放在文件系统中才会有此类问题，如果数据库存放在ASM中也不会有类似的问题，这篇文章的目的是对相关问题进行总结，熟悉一些工具和方法，这是比较重要的。
写这篇文章是因为客户有一套数据库，AIX 6.1，数据文件存放在文件系统中，在使用DROP TABLESPACE UNDO INCLUDING CONTENTS AND DATAFILES删除了UNDO表空间之后，文件系统空间没有得到释放。如何解决问题就成了写这篇文章的初衷。
空间没有释放我们可能是通过df命令看确认的，当我们用du去扫描目录的大小可能会发现df和du两个命令看到的空间使用情况是不同的，可能差别很大，下面这篇MOS文章说明了原因：
'du' and 'df' tools report different space utilization (文档 ID 457444.1)
In this Document
Applies to:
Linux OS - Version Oracle Linux 4.4 and later
Linux x86-64
Linux x86
Linux Kernel - Version: 4.4 to 5.3
Symptoms
The 'du' (/usr/bin/du) and 'df' (/bin/df) command output displays conflicting space utilisation values, for example:
# df -k /
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda6 9288792 8672768 144120 99% /
# du -xsh /
2.1G /
In the example above, 'df' reports 8.6 Gb to have been used on the root (/) filesystem, whereas 'du' reports only 2.1 Gb to have been used.
Cause
The 'df' command reports how many disk blocks are used, whilst 'du' traverses the filesystem and reports the actual number of blocks used (directory by directory), including any relating to files in use by processes.
In most cases, space utilisation values returned from 'df' and 'du' will be consistent. However, the potential exists for a running process to delete a large file, say. In this instance, according to 'du', the large file no longer exists, so the blocks associated with the deleted file are not reported. With the process still running, and with an open file descriptor still held against the deleted file, 'df' continues to track and report all disk blocks used, including those associated with the deleted (phantom) file. In this situation, the disk space associated with the deleted file will only be relinquished back to the system when the process completely releases the deleted file's descriptor or the process terminates (either gracefully or killed).
Solution
The solution is to identify and stop (or kill) the process that continues to hold a file descriptor open for the deleted file. To do so, run the lsof command (/usr/sbin/lsof | grep deleted) as root to identify the holding process, for example:
# lsof | grep deleted
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
cannaserv 3825 canna 0u CHR 136,0 2 /dev/pts/0 (deleted)
vmware 4295 root 6u REG 253,0 6770 13074503 /tmp/vmware-root/ui-4295.log (deleted)
vmware-re 4316 root 6u REG 253,0 6770 13074503 /tmp/vmware-root/ui-4295.log (deleted)
vmnet-nat 4448 root 0u CHR 136,0 2 /dev/pts/0 (deleted)