点击上方“IT那活儿”，关注后了解更多精彩内容！！！
模拟割接库2节点主机文件系统/trandata 使用率为100%，通过linux命令df –h，查看如下：手动删除部分已经存在的文件后，空间使用率会降下来，但很快又会被占满。使用linux 命令 du - sh 命令查看 /trandata 目录的使用情况如下（此文件系统总容量为256G）：根据这个库的作用（此数据库经常导入导出数据）分析，猜测是有数据库导出进程将目录占满。
但在数据库定义的directory目录下没有发现异常文件。而且当前文件系统下并没有发现大文件，但使用率很高，导致所有人都认为是操作系统问题，而没有往数据库方向想。后面进一步问题分析，有可能是有大文件删除了，但是空间没有被释放，于是使用命令查看：发现进程号为2410的一个进程为expdp进程，此进程为 nohup 后台进程导出dump数据文件到 /trandata/common/distill/cfg 目录下。当前机器使用人较多，猜测导致此问题的原因为先起了一个expdp的进程在主机上导出，由于此目录空间本身就使用率偏高，很快就导致expdp进程进入等待状态。此时相关人员并没有按照正常的步骤去停止expdp进程，反而直接使用rm命令去清理过 /trandata/common/distill/cfg目录，导致dump文件和日志文件都被清除。但是文件号被expdp进程占着，导致文件虽然被删除，但是空间并未被释放。然而数据库泵进程一旦启动，窗口Ctrl + C 或者关闭当前窗口，进程仍然会在后台继续运行，就导致了此文件系统被不断的撑满。根据问题原因，现在再次手动执行杀进程释放文件号即可。根据expdp的进程号：kill -9 2410，然后登录到数据库，查看是否还存在running状态的job。select * from dba_datapump_jobs t;
在任务没有正常结束时，若想停止任务，首先根据数据泵导出或导入的日志找到attach，然后expdp attach=*** 或者 impdp attach=*** 登录后执行kill_job 输入Yes即可。或者参考（How To Cleanup Orphaned DataPump Jobs In DBA_DATAPUMP_JOBS ? (文档 ID 336014.1)）。SELECT o.status,o.object_id,o.object_type,o.owner || '.' || object_name "OWNER.OBJECT",'DROP TABLE ' || o.owner || '.' || object_name || ' purge;'"Drop master table"FROM dba_objects o, dba_datapump_jobs jWHERE o.owner = j.owner_name AND o.object_name = j.job_nameAND j.job_name NOT LIKE 'BIN$%' ORDER BY 4, 2;
DECLARE h1 NUMBER; BEGIN h1 := DBMS_DATAPUMP.ATTACH('前面查出的任务名','用户名'); DBMS_DATAPUMP.STOP_JOB (h1); END; /
